Hi again Andrew!
(Note: This is a repost. In the first try I attached a Z26 screenshot
GIF and I fear it doesn't make it through the SPAM filters of the list.
If the first version comes through anyway, search for ***** in _this_
mail, where I changed something important!)
> Here's a newer version. The target display (top right) is now functional,
> and you can move 'cubes' around (only the one at top left at start-up,
> though). This demo so far is all background. As soon as I can find my
> manual... I'll start tackling sprites.
Are you sure you sent the correct binary?
On Z26 I experience timing problems and the target display seems to be
random, more or less.
> Source code is included in this post
> (enjoy!), and as you can see I seem to have HEAPS of processing time
> available for sprites, etc., during the kernal display.
I spent some hours yesterday reading & tweaking it, really a great job
so far.
(I was even stunned by some DASM features I didn't know like REPEAT -
REPEND)
Some thoughts:
Sooner or later you'll have to do ROM optimisation. For example I found
you're using a complete 256 byte table with the numbers from 0 to 255.
It's only acessed for incrementing by 3:
lda next+3,x
cmp #8*3 ;PFSIZE
bcs nn
jmp nexlin0
Just replace that with:
inx
inx
inx
cpx #8*3 ;PFSIZE
bcs nn
jmp nexlin0
You might need to skip one of the NOPS in the code above that to fix the
timing. Philosophical question: Are 2 cycles worth 256 Bytes of ROM?
***** Besides, you could rearrange your whole data in a way that you can
do a decrementing loop, with a dex,dex,dex,bne sequence you'd would have
exactly the same number of cycles than in your original sequence
:-)*****
The code for drawing the 6 top and bottom lines is copied 6 times in the
ROM. It can easily be put in a subroutine. (You can't do that with the
more timing critical action-field, of course.)
I tried these two things yesterday, freeing nearly 1K of ROM space!!
For the RAM issues: It'd of course be easy to free lots of RAM, if the
blocks would *teleport* instead of *move*
Even if they'd only move vertically and teleport horizontally would free
38 Bytes.
But you've still ~ 40 bytes RAM left, I think this might be enough for
the sprites anyway.
Another thing: I bet that the blank lines in both PF frames will cause
you lots of troubles sooner or later. You'll see that, when running out
of ROM, this effect will steal lot's of prescious cycles...
At the moment it just wastes some hundreds of Bytes, but I guess you'll
need 'em soon :-)
(Maybe it'd already help a lot to change the PF pattern only every three
lines instead of every line, just popped to my mind. Judging from your
6x6 pixel PF resolution, a single line PF update is such a great waste
of cycles & ROM...)
I hope you don't take this as criticism about your programming style
(which it isn't), it's just some (maybe helpful) thoughts to keep you
going :-)
Can't wait for the next update,
greetings,
Manuel
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
