enthusi Posted February 19, 2020 Share Posted February 19, 2020 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. Quote Link to comment Share on other sites More sharing options...
laoo Posted February 19, 2020 Author Share Posted February 19, 2020 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
laoo Posted February 20, 2020 Author Share Posted February 20, 2020 (edited) @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 Quote Link to comment Share on other sites More sharing options...
Cyprian Posted February 20, 2020 Share Posted February 20, 2020 does the test code start from the same address in both versions? maybe one of them pass the page boundary earlier Quote Link to comment Share on other sites More sharing options...
42bs Posted February 20, 2020 Share Posted February 20, 2020 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. Quote Link to comment Share on other sites More sharing options...
laoo Posted February 20, 2020 Author Share Posted February 20, 2020 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
laoo Posted May 5, 2020 Author Share Posted May 5, 2020 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 1 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.