Jump to content
EricBall

sample 7800 source code using (ZP,X)

Recommended Posts

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).

balldem2.zip

Edited by EricBall

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
...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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 :cool:

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
... 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

Share this post


Link to post
Share on other sites

Amazing how much is learned over time, as well as the variety of approaches and techniques that can be applied. 

Here is a similar end result, but with 101 sprites and no flickering or slowdown of movement:

 

 

7800basic is a fantastic piece of software.  The above is just one example.

Much of the explosion in 7800 game development is a strong testimony to it.

  • Like 4

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...