Hello matt and everybody,
I checked the sample.a65 program on the CD and noticed that it has the same
timing errors. So everybody else: better not use it as a model for your own
code.
I also checked your (matt) code and noticed, that you are doing the overscan
(accidently ?) right. The loop, where you wait for 32 lines does this. You
could replace it with a routine that sets up the Tim64T timer with #35 (for
NTSC; #42 for PAL) and waits for it to expire. This way you could do some
game logic between the setup and the waiting.
The routine that claims to do the overscan (between the TOP: label and the
next BNE @1) is completely obsolete. All it does is filling a couple of
ports with zero. This is stupid, because this way you have to reset things
like the backgroundcolour again in every frame. You don't even have to call
it once, before the first frame, because writing zeros to all ports is
allready done by the very first loop in your code.
I think, you could speed up the loop that fills the RAM with zeros a bit(in
case you need to use it in a more timing critical place) by replacing the
STA 0,X with a PHA. Because the stackpointer points to the end of the RAM
and is only one byte large, pushing zeros 256 times to the stack would
cause the stackpointer to be the same as before and all the ports and the
RAM to contain zeros.
In your matt.a65 program you use ADC #1 a couple of times. They could be
replaced by INC for speed reasons. But I think you allready know that.
Also your programs are so small, that you could make them 2k instead of 4k,
before you post them.
For everybody, who wants to make matt's programs at least display right:
You can easyly replace the second LDA #$05 line in all his sourcecodes
with a LDA #43 line (LDA #53 for PAL) and recompile them with ASM6502.EXE
from th CD.
I hope this is at least a little bit helpfull to some of you.
Ciao, Eckhard Stolberg
2stolber@xxxxxxxxxxxxxxxxxxxxxxxxx
