Re: [stella] Qb/Demo background animation (very rudimentary)

["Andrew Davie" <adavie@xxxxxxxxxxxxx>]

Thanks to Manuel for the comments.

I checked on Z26 and it was ALL screwy.  Worked OK on PCAE... obviously
timing is a little different in those emulators.  Attached is a new version,
incorporating some of Manuel's suggestions... which also appears to show
similar timing on both PCAE and Z26.

I've totally reworked the display system - its a bit more interesting now,
being modularly divided into subroutines.

Note:  This is still just something I'm playing around with... no finished
product promised :)

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

----- Original Message -----
From: "Manuel Polik" <manuel.polik@xxxxxxxxxxx>
To: <stella@xxxxxxxxxxx>
Sent: Friday, February 02, 2001 10:42 PM
Subject: Re: [stella] Qb/Demo background animation (very rudimentary)


> 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/
>

Attachment: push.asm
Description: Binary data

Attachment: push.bin
Description: Binary data