The Z26 trace file also has a wealth of cycle information, not only opcodes
but sprite positions as well.
A trick I use for most instructions is to count the number of memory
accesses. So LDA (ZP),Y requires
1 cycle to fetch the opcode
1 cycle to fetch the ZP pointer
1 cycle to fetch the LSB
1 cycle to fetch the MSB
1 cycle to fetch the data
(Yes, I know that if the Y offset goes over a page boundary there's another
cycle, but you make sure your tables don't do that.)
For programming I am finding a simple spreadsheet very useful for creating
kernels. Kind of Z26 trace in reverse. I list the 6507 cycle numbers in
one column and pixel positions in the next, then put in the next columns
stuff like playfield starts or where I need to position sprites (with HMOVE
values). Then I can start laying out the instructions in the next column
and easily move them up or down and see where I have spare cycles. It's
also great if you are updating registers on the fly so you can make sure you
aren't updating too soon or too late.
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
