Difference between revisions of "Talk:83Plus:Ports:2E"

Revision as of 12:00, 9 March 2006

Okay I did more research into port 2e, it does not affect the CPU clock speed at all. It still runs at either 6mhz or 15mhz. The effects of this port makes it appear that the clock has slowed down, rather reads and writes to the memory have slowed. Please bare with me, it's rather difficult to explain.

On whim I decided to test the accuracy of opcodes tstates. I set up the SE timers to run on the CPU clock. Between setting the clock and reading the clock I would be able to calculate the tstates of any given opcode. Here is the code.

   xor a          ;clear
   out ($30),a
   out ($31),a
   ld a,$80       ;cpu clock
   out ($30),a
   xor a          ;no looping, no interrupt
   out ($31),a
   ld a,100       ;countdown from 100.
   out ($32),a
   ;---OP CODES HERE!!!---
   in a,($32)     ;read ticks since write
   ld l,a
   ld a,90
   sub l          ;from writing to reading is 10 clocks
   ld l,a         ;I adjust so the output gives me only the tstates of the opcodes
   ld h,0
   bcall(_disphl)

The code above simply display the number of tstates in the given space. 'Nothing' renders an answer of 0, NOP renders 4, ld a,($8000) renders 13, jp c,$ when NO CARRY renders 10. I've tested enough to assume that this working correctly.

I will state my findings based on my inputs.

For the 83+SE the default value of port 2E is 44. The default value of port 29 is 14. Port 2E and the LCD delay ports are linked. I used only a range of a few opcodes on each test. They were:

   ld (ix+0),0            ;ix=ramaddress
   ld (ramaddress),a
   ld a,(ramaddress)
   ldi                    ;hl=ramaddress, de=ramaddress, bc=1
   out (1),a              ;a=100
   "NULL"                 ;NO OPCODE!!

Here is a table of the tested opcodes, and some of the trials. I excluded most due to the fact they did not show relevant info. The values under ports 29 and 2e are the contents of the ports at given trial. the values under the opcodes are the return TStates. NOTE: Although no opcode should always return a value of 0, the difference is probably because of writing to port 32 prior and reading port 32 after. So take that into consideration when you look at the other tstates in the given trial.

When bit 1 of port 29 is set and 2e is default, all writes to the ram take 1 extra tstate per byte.

When bit 1 of port 29 is set and 2e contains 74, all reads and writes to the ram take 1 extras tstate per bytes.

The other information on seems rather confusing...

Also my test only occurred on an 83+SE, at 6mhz, and all other ports at default. I made no tests for the 84+SE yet. Also I'd like to note that i believe timers based on the cpu clock are correct, I timed these instructions be hand to verify that. Finally all code occurred in the ram, as did reads and writes.

So I post this on the discussion page due to the fact I lack a certain bit of knowledge on how memory is access on this system. What exactly goes on between the micro controller and the cpu? (though the SE cpu is in the micro controller) Is there a memory clock or is it based on the cpu clocks? I really don't the info to explain the effects when port 2e contains 54 or 64. I'd hope some one else can shed some more light on the subject.

....sigh... I have a feeling that I am the only one in the world that would actually care about this.--Jim e 05:02, 7 Mar 2006 (PST)

Just remember that someone has to implement all this, and that someone wouldn't want to backtrack after realising that the implementation is based on a fundamentally wrong model. ;) CoBB 07:29, 7 Mar 2006 (PST)

The one thing that is throwing me off about this though is LDI under 54 and 64. I would have thought the oposite would have true, but of course this isn't going to be that simple...Further I have know idea why ti feels this is important, if anything imagine this breaks backwards compatibilty with some programs, specifcally cpu timing based. For some godawful reason TI decided to take every avenue to slow down the 84. The LCD, it's delaying hardware, the mem delaying, disabling hi-speed mode in graphing, and some deal of code changes from the 83+ that is specifically for slowing the calc. Anyway, I hate this port. --Jim e 08:19, 9 Mar 2006 (PST)

One possible explanation follows. Remember that, in addition to the instruction you're testing, additional delays are being added during the IN A,($32). So here's the breakdown:

Instruction   Machine Cycles                                 Added Clocks
ld (ix+0),0 : OCF OCF  OR OR      IO  MW      [OCF OR PR]    1  4  4  7
ld (*),a    : OCF      OR OR          MW      [OCF OR PR]    1  3  4  6
ld a,(*)    : OCF      OR OR  MR              [OCF OR PR]    0  2  4  6
ldi         : OCF OCF         MR      MW      [OCF OR PR]    1  4  3  6
out (1),a   : OCF      OR                PW   [OCF OR PR]    0  2  2  4
; none      :                                 [OCF OR PR]    0  1  1  2

Now, count up the total operations according to which CPU status lines are low during the memory request:

Instruction   M1,RD   RD   WR   Added Clocks
ld (ix+0),0   3       3    1    1  4  4  7
ld (*),a      2       3    1    1  3  4  6
ld a,(*)      2       4    0    0  2  4  6
ldi           3       2    1    1  4  3  6
out (1),a     2       2    0    0  2  2  4
; none        1       1    0    0  1  1  2

So it looks like we get the writing delay every time. We then get an additional delay for opcode fetch (M1) reads if bit 4 is set, and we only get a delay for non-opcode-fetch (non-M1) reads if bit 5 is set.

Unfortunately I don't have my SE with me at the moment, so I can't check any of this. As to why they would do it, your guess is as good as mine. FloppusMaximus 11:00, 9 Mar 2006 (PST)