12 replies to this topic

[EricBall]

As per supercat's suggestion in my 7800 cycle counting blog entry, herein find an alternate version of my sample 7800 display list builder using the unloved (zp,x) addressing mode.

The main advantage is a surprising savings of 25 cycles per sprite (161 versus 186), although some/all of this may be lost when wrap around is added. The disadvantage is the routine requires 2 bytes of zero page RAM per display list.

I've also added the dummy 5 byte sprite header to set Write Mode which was missing from the first skeleton.

07/04/29 EDIT

I discovered when I went to update my bouncing ball demo to use the (zp,x) display list builder that my skeleton code had a few problems. I've now completed the updates to the demo (attached).

Attached Files

•  balldem2.zip   8.68K   137 downloads

Edited by EricBall, Sun Apr 29, 2007 6:33 PM.

[Schmutzpuppe]

EricBall, on Fri Mar 30, 2007 9:28 PM, said:

As per supercat's suggestion in my 7800 cycle counting blog entry, herein find an alternate version of my sample 7800 display list builder using the unloved (zp,x) addressing mode.

The main advantage is a surprising savings of 25 cycles per sprite (161 versus 186), although some/all of this may be lost when wrap around is added. The disadvantage is the routine requires 2 bytes of zero page RAM per display list.

I've also added the dummy 5 byte sprite header to set Write Mode which was missing from the first skeleton.

Thanks for sharing Eric.
Personally I prefer a "static" dll because it's easier to handle and entries outside the visible area doesn't eat any cycles but I guess there are circumstances where you better use a more dynamic model.

[EricBall]

Schmutzpuppe, on Sat Mar 31, 2007 8:50 PM, said:

Personally I prefer a "static" dll because it's easier to handle and entries outside the visible area doesn't eat any cycles but I guess there are circumstances where you better use a more dynamic model.

The code isn't all that dynamic. The start address of each display list is fixed in memory. (A truely dynamic DLL/display list builder would build the display lists one after the other. But that would be a whole 'nother level of space versus speed.) About the only "dynamic" part of the DLL is the code creates the visible portion on the fly as part of initialization. Yeah, the whole DLL could be coded in ROM, then copied to RAM but I'd rather leverage the pointer array needed for the display list builder.

[Gorf]

The 7800 has always interested me...can I run this sample
on an emu? I only have one 7800 and really do not want to
modify it. I am looking for a cheap on to mod. too busy
with Jag coding and some contract work but would love to
mess with this machine. I love to do a space shooter of
some sort.

Edited by Gorf, Mon Apr 2, 2007 8:11 PM.

[supercat]

EricBall, on Fri Mar 30, 2007 2:28 PM, said:

...using the unloved (zp,x) addressing mode.

Incidentally, Asteroids 2600 seems to use the (ZP,X) addressing mode quite a bit, and makes quite a few stray memory accesses. I don't know if there are any circumstances where those accesses could hit $xFF8/xFF9, but they trip up 0840 banking. Interestingly, they don't usually crash it, but instead cause fully-but-recoverable glitches.

[EricBall]

Gorf, on Mon Apr 2, 2007 10:10 PM, said:

The 7800 has always interested me...can I run this sample on an emu? I only have one 7800 and really do not want to modify it. I am looking for a cheap on to mod. too busy with Jag coding and some contract work but would love to mess with this machine. I love to do a space shooter of some sort.

No, it's not a complete runnable sample. The intent was to provide some skeleton code that other 7800 programmers could use to get a head start.

[mimo]

Gorf, on Tue Apr 3, 2007 3:10 AM, said:

The 7800 has always interested me...can I run this sample
on an emu? I only have one 7800 and really do not want to
modify it. I am looking for a cheap on to mod. too busy
with Jag coding and some contract work but would love to
mess with this machine. I love to do a space shooter of
some sort.

I'd love you to do a space shooter

[EricBall]

See EDIT and new attachment in the first post.

The demo isn't perfect. You will notice the balls slow down once a number of them get onscreen. This is because the display list builder plus the position updates are taking longer than a screen to complete. I also noticed some graphics glitches when playing on real hardware which I believe are caused by MARIA using a display list entry which is in the middle of being updated. Unfortunately, I can't think of an easy way to prevent this.

The ball graphics are a quick conversion from Puzzle Bobble. I'm sure some hand tweaking would improve the look. There also may be some value in changing the code to cycle the animation differently than just basing it on the horizontal position.

[Bruce Tomlin]

EricBall, on Mon Apr 30, 2007 11:20 AM, said:

The demo isn't perfect. You will notice the balls slow down once a number of them get onscreen. This is because the display list builder plus the position updates are taking longer than a screen to complete. I also noticed some graphics glitches when playing on real hardware which I believe are caused by MARIA using a display list entry which is in the middle of being updated. Unfortunately, I can't think of an easy way to prevent this.

You would need to do double buffering on the display lists. At the very least the individual DLs need to be double buffered. Maybe the DLL would need it too, if Maria happens to read the DL address while it is being udpated. But if the low byte of the address is the same, then Maria will see either one or the other, both valid.

[EricBall]

Bruce Tomlin, on Sun May 6, 2007 11:41 PM, said:

You would need to do double buffering on the display lists. At the very least the individual DLs need to be double buffered. Maybe the DLL would need it too, if Maria happens to read the DL address while it is being udpated. But if the low byte of the address is the same, then Maria will see either one or the other, both valid.

True, double buffering the DLL/DLs would avoid this issue, but at a significant cost in terms of RAM/display list length and display list builder code complexity / size. I was more thinking of something based on a DLI routine which would flag which display list MARIA is reading at any one time.

Of course, the other alternative is to avoid updating the display lists during active video.

[Bruce Tomlin]

You could also just change the low byte of the DL address, and have some kind of circular buffer arrangement where there were, say, 8 or 16 DLs per 256-byte page, with only one left open for writing at any time.

[supercat]

Bruce Tomlin, on Tue May 8, 2007 7:52 PM, said:

You could also just change the low byte of the DL address, and have some kind of circular buffer arrangement where there were, say, 8 or 16 DLs per 256-byte page, with only one left open for writing at any time.

Perhaps, though one often wants to update many display lists "simultaneously" (especially if there are many objects that can move among them). If one has a practical means of only doing half of the display lists at a time, then no such buffering is needed. Simply wait for vblank, do all the display lists on the BOTTOM half of the screen, then wait for mid-screen, then do all the display lists on the TOP.

[vdub_bobby]

Schmutzpuppe, on Sat Mar 31, 2007 5:50 PM, said:

... and entries outside the visible area doesn't eat any cycles ....

Does this mean that you can change write mode during a scanline at no Maria cycle cost, by using a dummy indirect-mode header that is positioned off screen? Because that would be cool...

Edited by vdub_bobby, Fri Mar 14, 2008 2:45 PM.