Talk:83Plus:Ports:2E
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.
| Port 29 |
Port 2E |
ld (ix+0),0 |
ld (*),a |
ld a,(*) |
ldi |
out (1),a |
NO OPCODE |
| 14 |
44 |
19 |
13 |
13 |
16 |
11 |
0 |
| 14 |
CF |
19 |
13 |
13 |
16 |
11 |
0 |
| 16 |
44 |
20 |
14 |
13 |
17 |
11 |
0 |
| 16 |
54 |
23 |
16 |
15 |
20 |
13 |
1 |
| 16 |
64 |
23 |
17 |
17 |
19 |
13 |
1 |
| 16 |
75 |
26 |
19 |
19 |
22 |
15 |
2 |
| 17 |
FF |
26 |
19 |
19 |
22 |
15 |
2 |
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)
- In a rare speck of free time I whipped up a program to help play with ports 29 and 2Eh. Useful for playing with if you don't want write your own code or have to recompile Jim's a million times.
- Run from TIOS. It takes a low and high value for each port and some code to run, and then runs Jim e's code above and displays to the screen whenever the # of clock cycles changes. I ran it on an 84P and it seems to confirm Jim's table. I haven't had a chance to experiment any more with it. The source is available in the same directory, in case someone would like to modify it (to play with port 2A also, or change the CPU speed, or whatever), and I apoligize in advance for the horrible code. --Dan Englender 12:02, 9 Mar 2006 (PST)
I didn't think there would be a difference between non-opcode fetch and opcode fetch, but it fits perfectly. I did some more testing I think there is enough information to consider this complete now.
For the LCD Ports:
- Bit 0 of the LCD ports (depending on current CPU speed mode) enable the effects of the flash delay controled be 2E.
- Bit 1 of the LCD ports (depending on current CPU speed mode) enable the effects of the ram delay controled be 2E.
For port 2E:
- Bits 0-2 of port 2E affect the flash reads and (attempted) writes.
- Bit 0 adds a clock for every opcode read from the flash.
- Bit 1 adds a clock for every non-opcode read from the flash.
- Bit 2 adds a clock for every (attemped) write to the flash.
- Bits 4-6 of port 2E affect the ram reads and writes.
- Bit 4 adds a clock for every opcode read from the ram.
- Bit 5 adds a clock for every non-opcode read from the ram.
- Bit 6 adds a clock for every write to the ram.
- Bits 3 and 7 are not used in port 2E, though they can be toggled.
I came up with 2 more tables to help define this. ( code is in the ram, ix = ram, hl=ram, de=ram, sp is not altered )
| 29 |
2E |
ld (ix),0 |
ld (ram),a |
ld a,(ram) |
ldi |
out (1),a |
push hl |
pop hl |
NONE |
| 16 |
00 |
19 |
13 |
13 |
16 |
11 |
11 |
10 |
0 |
| 16 |
10 |
22 |
15 |
15 |
19 |
13 |
13 |
12 |
1 |
| 16 |
20 |
22 |
16 |
17 |
18 |
13 |
12 |
13 |
1 |
| 16 |
26 |
25 |
18 |
19 |
21 |
15 |
14 |
15 |
2 |
| 16 |
40 |
20 |
14 |
13 |
17 |
11 |
13 |
10 |
0 |
| 16 |
50 |
23 |
16 |
15 |
20 |
13 |
15 |
12 |
1 |
| 16 |
65 |
23 |
17 |
17 |
19 |
13 |
14 |
13 |
1 |
| 16 |
70 |
26 |
19 |
19 |
22 |
15 |
16 |
15 |
2 |
( code is in the flash, ix = flash, hl=flash, de=flash, sp is not altered )
| 29 |
2E |
ld (ix),0 |
ld (rom),a |
ld a,(rom) |
ldi |
out (1),a |
push hl |
pop hl |
NONE |
| 15 |
00 |
19 |
13 |
13 |
16 |
11 |
11 |
10 |
0 |
| 15 |
01 |
22 |
15 |
15 |
19 |
13 |
13 |
12 |
1 |
| 15 |
02 |
22 |
16 |
17 |
18 |
13 |
12 |
11 |
1 |
| 15 |
03 |
25 |
18 |
19 |
21 |
15 |
14 |
13 |
2 |
| 15 |
04 |
20 |
14 |
13 |
17 |
11 |
11 |
10 |
0 |
| 15 |
05 |
23 |
16 |
15 |
20 |
13 |
13 |
12 |
1 |
| 15 |
06 |
23 |
17 |
17 |
19 |
13 |
12 |
11 |
1 |
| 15 |
07 |
26 |
19 |
19 |
22 |
15 |
14 |
13 |
2 |
Still have some remaining things to note. The code was test in the flash and ram, however at different addresses(bank4000 & bank8000 respectively), so this could in fact be tied with address. Though the stack instructions are still affect. I haven't tested modes 2 and 3 of the speed port, though 0 and 1 had the same effect. I haven't ACTUALLY written to the flash nor do I wish to try.
One last thing, based on the relative position of the ports I suspect port 2d has a similar effect of some type. --Jim e 02:33, 10 Mar 2006 (PST)
- So I guess the next question is, is there any adverse effect to removing these delays? The SE works just fine without them, but perhaps TI made some change to the RAM with the 84+ that requires the additional delay to be added? (There aren't any circumstances when the USB hardware reads or writes directly to RAM, are there?)
- A Flash delay might actually make sense, as the Flash chip takes some time to respond to every command. But I don't think a 1-clock-cycle delay would ever have a significant effect. FloppusMaximus 08:55, 10 Mar 2006 (PST)
