Talk:83Plus:Ports:2E - Revision history

FloppusMaximus at 16:55, 10 March 2006

2006-03-10T16:55:19Z

Jim e: forgot sig

2006-03-10T10:33:27Z

forgot sig

Jim e at 10:32, 10 March 2006

2006-03-10T10:32:54Z

Show changes

Dan Englender: Program to help play with ports

2006-03-09T20:02:29Z

Program to help play with ports

FloppusMaximus at 19:00, 9 March 2006

2006-03-09T19:00:43Z

Jim e at 16:19, 9 March 2006

2006-03-09T16:19:26Z

CoBB: a pat on the shoulder

2006-03-07T15:29:24Z

a pat on the shoulder

Jim e: Major rewrite for this port info page will be needed.

2006-03-07T13:02:29Z

Major rewrite for this port info page will be needed.

New page

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.

{| WIDTH=590 BORDER=1 CELLPADDING=2 CELLSPACING=2 STYLE="page-break-before: always"
|-
| WIDTH=55 HEIGHT=27 | Port 29
| WIDTH=55 | Port 2E
| WIDTH=75 | ld (ix+0),0
| WIDTH=75 | ld (*),a
| WIDTH=75 | ld a,(*)
| WIDTH=75 | ldi
| WIDTH=75 | out (1),a
| WIDTH=105 | NO OPCODE
|-
| WIDTH=55 HEIGHT=31 | 14
| WIDTH=55 | 44
| WIDTH=75 | 19
| WIDTH=75 | 13
| WIDTH=75 | 13
| WIDTH=75 | 16
| WIDTH=75 | 11
| WIDTH=105 | 0
|-
| WIDTH=55 HEIGHT=31 | 14
| WIDTH=55 | CF
| WIDTH=75 | 19
| WIDTH=75 | 13
| WIDTH=75 | 13
| WIDTH=75 | 16
| WIDTH=75 | 11
| WIDTH=105 | 0
|-
| WIDTH=55 HEIGHT=31 | 16
| WIDTH=55 | 44
| WIDTH=75 | 20
| WIDTH=75 | 14
| WIDTH=75 | 13
| WIDTH=75 | 17
| WIDTH=75 | 11
| WIDTH=105 | 0
|-
| WIDTH=55 HEIGHT=31 | 16
| WIDTH=55 | 54
| WIDTH=75 | 23
| WIDTH=75 | 16
| WIDTH=75 | 15
| WIDTH=75 | 20
| WIDTH=75 | 13
| WIDTH=105 | 1
|-
| WIDTH=55 HEIGHT=31 | 16
| WIDTH=55 | 64
| WIDTH=75 | 23
| WIDTH=75 | 17
| WIDTH=75 | 17
| WIDTH=75 | 19
| WIDTH=75 | 13
| WIDTH=105 | 1
|-
| WIDTH=55 HEIGHT=31 | 16
| WIDTH=55 | 75
| WIDTH=75 | 26
| WIDTH=75 | 19
| WIDTH=75 | 19
| WIDTH=75 | 22
| WIDTH=75 | 15
| WIDTH=105 | 2
|-
| WIDTH=55 HEIGHT=30 | 17
| WIDTH=55 | FF
| WIDTH=75 | 26
| WIDTH=75 | 19
| WIDTH=75 | 19
| WIDTH=75 | 22
| WIDTH=75 | 15
| WIDTH=105 | 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.--[[User:Jim e|Jim e]] 05:02, 7 Mar 2006 (PST)

← Older revision		Revision as of 16:55, 10 March 2006
Line 384:		Line 384:
	One last thing, based on the relative position of the ports I suspect port 2d has a similar effect of some type.		One last thing, based on the relative position of the ports I suspect port 2d has a similar effect of some type.
	--[[User:Jim e\|Jim e]] 02:33, 10 Mar 2006 (PST)		--[[User:Jim e\|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. [[User:FloppusMaximus\|FloppusMaximus]] 08:55, 10 Mar 2006 (PST)

← Older revision		Revision as of 10:33, 10 March 2006
Line 383:		Line 383:

	One last thing, based on the relative position of the ports I suspect port 2d has a similar effect of some type.		One last thing, based on the relative position of the ports I suspect port 2d has a similar effect of some type.
		+	--[[User:Jim e\|Jim e]] 02:33, 10 Mar 2006 (PST)

← Older revision		Revision as of 20:02, 9 March 2006
Line 149:		Line 149:
	:::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.		:::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. [[User:FloppusMaximus\|FloppusMaximus]] 11:00, 9 Mar 2006 (PST)		:::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. [[User:FloppusMaximus\|FloppusMaximus]] 11:00, 9 Mar 2006 (PST)
		+
		+	::::In a rare speck of free time I whipped up a [http://wikiti.denglend.net/stuff/TEST168.8XP 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. --[[User:Dan Englender\|Dan Englender]] 12:02, 9 Mar 2006 (PST)

← Older revision		Revision as of 19:00, 9 March 2006
Line 128:		Line 128:

	::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. --[[User:Jim e\|Jim e]] 08:19, 9 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. --[[User:Jim e\|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. [[User:FloppusMaximus\|FloppusMaximus]] 11:00, 9 Mar 2006 (PST)

← Older revision		Revision as of 16:19, 9 March 2006
Line 126:		Line 126:
	....sigh... I have a feeling that I am the only one in the world that would actually care about this.--[[User:Jim e\|Jim e]] 05:02, 7 Mar 2006 (PST)		....sigh... I have a feeling that I am the only one in the world that would actually care about this.--[[User:Jim e\|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. ;) [[User:CoBB\|CoBB]] 07:29, 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. ;) [[User:CoBB\|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. --[[User:Jim e\|Jim e]] 08:19, 9 Mar 2006 (PST)

← Older revision		Revision as of 15:29, 7 March 2006
Line 125:		Line 125:

	....sigh... I have a feeling that I am the only one in the world that would actually care about this.--[[User:Jim e\|Jim e]] 05:02, 7 Mar 2006 (PST)		....sigh... I have a feeling that I am the only one in the world that would actually care about this.--[[User:Jim e\|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. ;) [[User:CoBB\|CoBB]] 07:29, 7 Mar 2006 (PST)