Jump to content
IGNORED

sample 7800 source code using (ZP,X)


EricBall

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
Link to comment
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.

Link to comment
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.

Link to comment
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
Link to comment
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.

Link to comment
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.

Link to comment
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:

Link to comment
Share on other sites

  • 4 weeks later...

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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
Share on other sites

  • 10 months later...
... 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
Link to comment
Share on other sites

  • 12 years later...

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
Link to comment
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...