6502 Beeb instruction timing tester

[dp11]

Ive obviously got a "special BBC". Thanks for testing.

[dp11]

Turns out may machine matches your machines so I've updated the ssds. I think if anyone else would like to check on real hardware that would useful.

[dp11]

Beebjit also fails some BCD timing tests on a master. I've actually been using beebjit during development of this with tests on real machines and jsbeeb when things didn't quite matchup with various sources of documentation. Nb there are a lot of subtle errors on the internet:)

beebjit is now clean for Master / 65c12 as of GibHub latest master.
I wasn't accounting for BCD cycles in the new 65c12 addressing mode "id".
And there was a terrible, terrible embarrassment for the 65c12 BCD modes "abx" and "aby" -- the incorrect address was being referenced, leading to not only timing errors but also awfully incorrect results. Thanks for helping me catch that.


Cheers
Chris

Wow ! I'm surprised my tiny little program has found extra bugs! It appears the cycle stretching is slightly off for a few instructions ( 65C12timing1M.ssd". This list is generated without your latest fixes.

[scarybeasts]

It appears the cycle stretching is slightly off for a few instructions ( 65C12timing1M.ssd".

I tried to run the latest 65C12timing1M.ssd but the program itself exits back to the BASIC prompt without appearing to have done all its tests. Is there something I could be doing wrong? It also behaves the same way in jsbeeb.


Cheers
Chris

[dp11]

It appears the cycle stretching is slightly off for a few instructions ( 65C12timing1M.ssd".

I tried to run the latest 65C12timing1M.ssd but the program itself exits back to the BASIC prompt without appearing to have done all its tests. Is there something I could be doing wrong? It also behaves the same way in jsbeeb.


Cheers
Chris

Thanks for pointing that out silly error now fixed.

[scarybeasts]

Wow ! I'm surprised my tiny little program has found extra bugs!

This little program is rocking it!

Here's the latest 65C12timing1M.ssd with the latest beebjit:

I'm starting by looking at why STA addrFE,X is too fast, because it's probably the simplest case. The actual instruction executed appears to be:

[ITRP] 3DE1: STA $FCFE,X [A=00 X=01 Y=01 S=F4 F= ZI 1 ] [addr=FCFF val=FF]

The instruction starts 1Mhz aligned, so beebjit takes 6 2MHz ticks: 3 ticks reading opcode and operand, 1 tick calculating +X, and 2 ticks reading $FCFF (1 streched 6502 tick).
Your program is fascinating because it says that's too fast -- this may be a case we don't fully understand the 65c12.

This is one area the 65c12 differs from the 6502, specifically in the "1 tick calculating +X". The original 6502 does a bus read of the uncarried address computation, and it's one of the things fixed in 65c12, e.g. from https://wilsonminesco.com/NMOS-CMOSdif/:
"Indexing across a page boundary caused an extra read of an invalid address, which could cause trouble in some hardware. (CMOS does an extra read of the last instruction byte instead.)"

The above description appears to be holding for LDA addr,X because no differences are noted.
LDA addr,X only takes the full 5 cycles if there is a carry in the address calculation, but STA addr,X always takes 5 cycles. Perhaps the STA also behaves differently for which addresses go out onto the bus.

From your measurement on a real machine, it looks like the "1 tick calculating +X" could be putting a $FCxx address out onto the bus. At that point, we're 3 ticks into a 1MHz aligned starting point. So, any 1MHz stretch would go from 1 tick to 3 ticks, leading to a 2 tick difference. (Your test appears to indicate a 2 tick difference.)

Perhaps this needs a logic analyzer to resolve.


Cheers
Chris

[dp11]

Hands up this is a case I don't understand and I think a logic analyser is going to be needed.

On my master sta fcfe,X takes 8 cycles

But sta fcff,X takes 6 cycles

I wonder if somehow this sequence is upsetting the via timer.

[dp11]

I wonder if somehow &fexx is being read causing another clock stretch where as ffxx wouldn't.

[scarybeasts]

On my master sta fcfe,X takes 8 cycles

But sta fcff,X takes 6 cycles

That's somewhat surprising! I know very little about the $FCxx or $FDxx pages. Is it possible you've got some hardware responding there? 2nd processors, unusual peripherals, etc.

For the tests where page crossings are not incurred, I wonder if it's worth reading / writing from a stretched address that is well defined on all Masters? It should be an address without too many side effects. Candidates that come to mind include $FE00 (6845 register select), $FE4A (VIA shift register).


Cheers
Chris

[dp11]

Nothing special about my master. From the hardware point of view devices can't extend an access cycle. I'll create a test case and see what I can find. Thanks for your findings.

[tom_seddon]

Is ACCCON bit 5 set? This causes accesses to $fc00...$fdff to be routed to the cartridge slots rather than the 1 MHz bus. Apparently all cartridge accesses are 2 MHz, so presumably accesses to this region run at full speed in this case. See app notes 014 and 035: http://chrisacorns.computinghistory.org ... Notes.html

(I've only got a B set up at the moment, so I haven't experimented on real hardware myself just yet...)

--Tom

[hoglet]

Hands up this is a case I don't understand and I think a logic analyser is going to be needed.

I've just done a quick capture using the 6502 decoder.

The debug logs are slightly confusing, because cycles with rdy=0 are discarded early on. But you can infer their presence from gaps in the sample sequence numbers. So in the below traces I've manually added them back in.

On my master sta fcfe,X takes 8 cycles

Code: Select all

001da798  0 9d O 1 1
001da799  1 fe D 1 1
001da79a  2 fc D 1 1
001da79b    rdy=0
001da79c    rdy=0
001da79d  3 ff D 1 1
001da79e    rdy=0
001da79f  4 00 D 0 1

001DA798 : 3DE1 : 9D FE FC : STA FCFE,X     : 5 : A=00 X=01 Y=01 SP=F4 N=0 V=0 D=0 I=1 Z=1 C=0

Whatever address is being output in the cycle "3" is not a repeat of cycle "2", as the data bus value is different, and it's triggering the cycle stretching.

But sta fcff,X takes 6 cycles

Code: Select all

001da89c  0 9d O 1 1
001da89d  1 ff D 1 1
001da89e  2 fc D 1 1
001da89f  3 fc D 1 1
001da8a0    rdy=0
001da8a1  4 00 D 0 1

001DA89C : 3E04 : 9D FF FC : STA FCFF,X     : 5 : A=00 X=01 Y=01 SP=F4 N=0 V=0 D=0 I=1 Z=1 C=0

This case is as expected.

I wonder if somehow this sequence is upsetting the via timer.

It does look like when page crossing occurs, the address put out in cycle "3" is an I/O address, not just a repeat of the high byte in the opcode.

Note, in both cases the decoder reports 5 cycles, since rdy=0 cycles are effectively discarded early on. It would be nice to have an option to include these cycles, but that's tricky given the way the decoder currently works.

If we wanted to see the actualy value on the address bus, I would need to switch over to the beast

Dave

[dp11]

If we wanted to see the actualy value on the address bus, I would need to switch over to the beast

Dave

I think the beast is going to be required, my guess is the LSByte ( &FE) appears as the MSbyte during an extra dummy read. My quick scope trace basically matches your findings. There is now a new sdd 65C12timing1MT.ssd which is a continuous loop of

Code: Select all

loop
	LDA # constant
	STA &FE64
	STA &FE65
	STA &FCFE,X
	STA &FCFE,X
	LDA &FE64
	BRA loop	
	

[dp11]

The plot thickens . I've manually recorded the address bus

Code: Select all

For STA &FCFE,X
Cycle 1 : 2079 Sync high 
Cycle 2 : 207A
Cycle 3 : 207B
Cycle 4 : FCFF
Cycle 5 : FCFF
Cycle 6 : FCFF
Cycle 7 : FCFF R/nW low
Cycle 8 : FCFF R/nW low

[hoglet]

Here's the 6-cycle STA (at &3E04):

Here's the 8-cycle STA (at &3DE1):

So it looks like in the first case, where there is a page crossing, the dummy cycle is reading the opcode.

But in the second case, where there is no page crossing, the dummy cycle is reading the data address that is about to be written.

This seems dodgy to me!

Dave

[dp11]

First of all I'm pleased we are seeing the same behaviour. I'm now wondering if there is a subtle timing difference ( nano seconds) causing IC15 to insert an extra cycle.

[dp11]

Another scope trace

[dp11]

For anyone following FE34 is equal to 8. So the 1MHz bus is directed to the external 1MHz port.
The same waveform occurs with the &FE6E (user via) ( clocked stretched ) so it is nothing special about accessing the 1MHz bus

[hoglet]

First of all I'm pleased we are seeing the same behaviour. I'm now wondering if there is a subtle timing difference ( nano seconds) causing IC15 to insert an extra cycle.

This seems pretty unambiguous on the logic analyzer (especially in timing mode which has a 4ns resolution)

Where there is page crossing, following the STA &FCFF,X instruction (3E04, 3E05, 3E06) the CPU then does a re-read of 3E06 in the 4th cycle, followed by a write of FD00 in the 5th cycle. This is the correct, safe behaviour.

Where there is no page crossing, following the STA &FCFE,X instruction (3DE1, 3DE2, 3D3E) the CPU then does a read of FCFF in the 4th cycle, followed by a write of FCFF in the 5th cycle. This is unsafe.

The addresses are stable ~50ns after the falling edge of Phi0, and remain stable for the whole cycle.

I can't see how this is anything to do with the logic in the Master. It's the CPU that's putting out the "wrong" address. The additional rdy=0 cycles are a direct consequence of this.

So the NMOS bug we thought was fixed CMOS 6502 is only partly fixed.

This is a pretty interesting finding if it applies to all varieties of CMOS 6502.

BTW, the device in my Master is a CMD G65SC12P.

I've just tried with Beeb816, which uses a W65C816, and that's even worse:
- STA FCFF,X does: 3E04, 3E05, 3E06, FC00 (3 cycles), FD00 (2 cycles, write)
- STA FCFE,X does: 3DE1, 3DE2, 3DE3, FCFF (3 cycles), FCFF (2 cycles, write)

So both 8 cycles in both cases.

Dave

[dp11]

Every day is a learning day

Depending on the phase with 1MHz clock sta &fcfe,X can generate either a 7 or 8 cycle access

[dp11]

My CPU matches yours.

[hoglet]

Just for reference, here's what I'm seeing in the two cases with a W65C816:

Maybe this is acceptable, because the 816 as VDA/VPA output to indicate invalid addresses.

Dave

[hoglet]

And the two cases with the G65SC12:

Dave

[hoglet]

Here's a post from Dr Jekyll 2 days ago that mentions this very issue:
http://forum.6502.org/viewtopic.php?f=1 ... 943#p94943

This references a detailed 2018 treatise on dead cycles:
http://forum.6502.org/viewtopic.php?p=62701#p62701

Copy attached here:

6502 Dead Cycles.pdf

(185.31 KiB) Downloaded 26 times

Dave

[dp11]

Test suite updated to check for 7 cycle STA abs,X during 1MHz test

[dp11]

Thanks Dave for all your work on this. I think we can safely say no master emulator currently in existence is correct, but with this info I'm sure this won't be the case for long .

[scarybeasts]

So the NMOS bug we thought was fixed CMOS 6502 is only partly fixed.

This is a pretty interesting finding if it applies to all varieties of CMOS 6502.

BTW, the device in my Master is a CMD G65SC12P.

It's a great finding!
For now, I'm going to specify that beebjit emulates the G65SC12P. We do know that Acorn loved to vary their supply chain (6522, 6845, etc.) so I'd be curious if different types of 65c12 are found in Masters.

From the output of dp11's program, it looks like the same surprise might afflict INC and DEC for the abs,X mode. That's plausible because INC / DEC also always have the "page crossing check" cycle. (The 65c12 was able to speed up ROL / ROR / LSR / ASL for the non-page-crossing case.)

I'll get beebjit updated and then see what's left!


Cheers
Chris

[dp11]

Dave's pdf shows Inc and Dec both have this extra cycle.

[hoglet]

Dave's pdf shows Inc and Dec both have this extra cycle.

Yes, this information was published by Drass and Dr Jefyll of 6502.org in 2018.

[scarybeasts]

I'll get beebjit updated and then see what's left!

The remaining issue with BCD mode ($xx),Y was another beebjit bug.
beebjit is now clean on 65C12timing1M.ssd. I'll have a look at 6502 next to see if there's any problems once I've fixed a few missing opcodes.


Cheers
Chris