[stella] Qb: v0.10

["Andrew Davie" <adavie@xxxxxxxxxxxxx>]

Sometimes you just have to go backwards to go any further forwards.

To go with the extensive changes in the systems, I have upped the version
number by a major increment - we are now v0.10 and holding.

The past few days have been difficult and frustrating.  I've only just 'come
back' to where I was last Friday - well, almost.  There are a lot of
non-functional things, but the best thing is...

I'VE SAVED ***** 500 *****  BYTES OF ROM!

Yeah, half-a-K!  OK, here's what's happened...

1) I bit the bullet and converted the sprite routine to the system as
used/suggested by Thomas Jentzsch.  This was quite a difficult conversion
for me, as it effectively involved a complete rewrite of the entire kernal
(which was already exquisitely timed to 'perfection').  As Thomas pointed
out, what I was doing wasn't all that effective in improving speed, anyway.
It took me a lot of pure hacking to get things working right (and they're
still a bit dodgy), but finally I have sprites again.  Here's the actual
guts...


        ;--------------------------
        ; SPRITE DRAW

        tya                     ; 2
        sec                     ; 2
        sbc SpriteEnd           ; 3
        adc #SPRITE_HEIGHT      ; 2
        bcs .Draw               ; 2(3)

        nop                     ; 2
        nop                     ; 2
        sec                     ; 2
        bcs .skipDraw           ; 3

.Draw
        lda (Sprite),y          ; 5
        sta PLAYER0SHAPE        ; 3

.skipDraw

        ;-->18 cycles used
        ;--------------------------

Thanks once again to Thomas for the suggestion which left me practically
without sleep for two days.  But still, it was a good one.  The new kernal
is very neat-and-tidy.  Unfortunately, the new kernal simply isn't capable
of the nifty colour changes (for the player) which I had just installed in
the old one.  C'est la vie.  I don't miss it so much - and the ROM saving
makes me smile everytime I think of it.

This particular mod saved me about 200 bytes.

2)  As part of the new kernal, I changed the Y register to counting the
scanline.  I noticed that the X register was counting 3 x the 'playfield
row'.  This was pretty logical;  the playfield consisted of 19 rows of 3
bytes each, which were mapped directly onto 3 bytes (horizontal) of the 6
bytes of the screen.  However, when I twisted the memory organisation into 3
columns each 19 bytes long... well, my X-register then could count in
ones... and it could be used to index tables by row.  Cost nothing extra in
the kernel - actually it saved a few bytes, because x only incremented by 1,
not 3.  So, the TargetIndex table was shrunk in size by 2/3rds (38 bytes).
With the code savings, this gave me another 50 bytes.

3) Now, when I'd started on #1, above, I knocked out my three kernals
(drawing the top border, drawing the target area border, drawing the
screen/target area), and started on the main one (MTargetArea).  I got that
working, and figured that the other two weren't THAT different, and tried to
combine all their capabilities into the one.  And, I've 95% succeeded.  The
only thing I haven't managed (yet?) to do is to flash the top/bottom border
of the target area.  Tricky.

But, by dropping the MTargetAreaBorder kernel, I've saved another 256 bytes
or thereabouts (!!)

4) The score is stuffed.  I have no idea why;  I do not recall touching that
code.  It could be a timing thing, but unlikely, as I've isolated that code
so it doesn't cross page boundaries.  Something I'll have to look at
shortly.

5) The timing of the sprite writes appears to have gone wonky on the 2nd
sprite.  I actually LIKE this look/feel... it gives things a little less
regularity.  If I can't fix it, I won't mind too much.  I have *NO IDEA* why
its happening, though - as I appear to be doing my sprite writes at the end
of the scanlines.  There's a few switches at the top of the code which allow
you to set the destination for sprite data - set it to COLUBK to see timing
in colour on the screen itself.

6) I have NOT tested the # lines generated for NTSC/PAL.  That can come
later.  I'm sure there are glitches everywhere, but trust me... this program
has been resurrected from the dead.  Glitches right now are OK.

6) I've actually added a few things, too...

* rudimentary sound.  It appears that Stella is the only emulator to do
sound on my machine.  Can anyone confirm for me that the emulation is fairly
accurate?  Z26 seems to try to use my PC speaker (bizarre), and I'm not sure
what PCAE did.  If you look at the sound code, you'll see I've begun a
fairly simple programmable sound system.  You start a sound, and it will
play its program (loop, duration, etc), until it stops or is overwritten.
That's probably the next major thing to tackle,  anyway.

* auto-moving cubes.  Well, as soon as you have a play, you'll understand
what this is.  It's fiendish, and I'm sure some of you will hate it.
However, it was in the original (though a creature did it, here it is an
invisible creature) - and gives a good difficulty feature for use in the
later levels.  At the moment its turned on at the start, and sometimes makes
things very tricky.


Soooooo,  that leaves me with no RAM (of course!) - there were some VERY
neato overlay RAM tricks used in the kernel to do the target display area
and the blank bit at the right (search for MTA_31 and ZERO and try to figure
out what's happening with those variables and their usage).  And ROM... well
I have about (rough calculation) 675 bytes free!

That is PLENTY to do a few creatures and some snazzy sound!  Wahoo :)

By the way, I was *most impressed* with the sound of Oystron;  I have
something to aim for!  Actually, I'm a sound-dunce... so this will be a
major major challenge for me.

So there we go, successfully through a major major rewrite.  Voila!  As
usual, feedback/comments very welcome.


Regarding Thomas's suggestion about the scoring (or bug), I don't agree - if
you only got a point every time you moved a cube to the correct place, and
lost it when you moved it away... that would set the actual score for each
screen (for cubes) to the number of cubes * points/cube.  I want to
encourage the player to 'cheat' by trying to build up scores by putting
cubes on/off the correct places.  Besides, the bonus is counting down like a
whirlwind anyway... there's little point lazying around.

I've copied this email to Thomas directly... Thomas did you get my
suggestion for your cursor?  Dont' forget, all our postings are archived on
the [stella] website, so if you think you missed anything, there is worth a
visit.

Cheers
A
--
 _  _  _| _ _        _| _    * _                               _  ,
(_|| )(_|( (/_\/\/  (_|(_|\/(_(/_                           ,~' L_|\
                                                         ,-'        \
see my Museum of Soviet Calculators at                  (            \
http://www.taswegian.com/MOSCOW/soviet.html              \    __     /
                                                          L,~'  "\__/
                                                              @--> v

Attachment: qb010.zip
Description: Zip compressed data

Attachment: qb010STELLA.bin
Description: Binary data

Attachment: qb010PAL.bin
Description: Binary data

Attachment: qb010NTSC.bin
Description: Binary data