Exact CPU cycle timings

[enthusi]

That apply to write as well though and while there is some jitter in the colors it is certainly not 0-15 cycles. But rather the remaining cycles of the interrupted opcode. It would be cool to see your analysis with ROM cart reads in a loop.

[laoo]

Docs says that "The CPU cycle that performed the actual read uses 15 ticks of the clock." I haven't tested it but it could be fun to reset counter each VBL and perform some unrolled code of reading from cart and writing to background color. It could say something about the timings with comparison to reading from RAM.

Edited February 20, 2020 by laoo

[laoo]

@42bs Mystery status still applies

I've converted both test images to LYX format and ran them on AgaCart and they still look the same as previous but different from each other.

I have no idea what is the difference from. The initialization is the same, the code is roughly the same, but the cycling is fundamentally different.

 

laoo_crti.lyx

Edited February 20, 2020 by laoo

[Cyprian]

does the test code start from the same address in both versions?

maybe one of them pass the page boundary earlier

[42bs]

9 minutes ago, Cyprian_K said:

does the test code start from the same address in both versions?

maybe one of them pass the page boundary earlier

At least my test code aligns all test patterns on 256 bytes.

 

[laoo]

   

15 minutes ago, 42bs said:

At least my test code aligns all test patterns on 256 bytes.

 

My test pattern is page-aligned too.

 

I've spotted that in the repo there is a newer version. I've attached it as a AgaCart friendly LYX image

42bs_cycle_check.lyx

 

In each line tere are 32 repetitions of:

 

cycle_check, from bottom there are: inc $8000, inc $ff, adc $ff, nop, 4*$1b, 3*1b, 2*1b, 1*1b

 

 

crti,  from bottom  sequence of 1-8*$03, spacer, inc $8000, inc $ff, adc $ff, nop, $1b, sta $ff, $5c 00 00

 

Relative lengths of rows should be the same, but are not. Especially in 42bs code add $ff is between 3*$1b and 4*$1b and in mine code it is exactly 3*$03 ($03 and $1b are both 1-cycle NOP).

 

Edited February 20, 2020 by laoo

[laoo]

As you can see on attached image the mystery has been eventually solved.

 

 

Frankly it is a little embarrassing.

The explanation is two-fold:

• I forgot about the sequential disable bit in MAPCTL
• no one mentioned anywhere that this register isn't meaningfully readable.

As a result I was trying to be clever and I was setting RAM in vector space using a sequence of

    lda #VECTOR_SPACE
    tsb MAPCTL

Apparently reading it returns value $F0 and above code disables sequential speed-up. In all my productions including Lynx Quest and Mortal Kombat ?

 

Lesson learned. I hope that with this post I was the last Lynx programmer that was caught with it