Jump to content
IGNORED

Some noob 7800 questions


Recommended Posts

Hello,

 

For the last several weekends, I have been studying the 7800 docs, high quality AA forum posts including (but not limited to!) "HoleyDMA & Atari 7800", "Differences between Atari 2600 and Atari 7800 sprite colors?" and played around with the MAME emulator and the well-known "Atari 7800 sprite sample" demo by Daniel Boris (this demo was extremely helpful by the way).

 

Now that I wrote down RAM/ROM addresses, checked memory dumps with MAME's excellent built-in debugger and memory window, I finally feel somewhat comfortable about DL and DLLs, "holey DMA", storing graphics upside down, etc. I believe I finally understand these concepts and how sprites are stored, displayed and moved. Although I have tons of things to find out and research, next thing on my list is experimenting with the various graphic modes (although I plan to stick with 160 resolution for the time being) and Indirect/Character mode.

 

I am not completely new to 6502 asm. About ten years ago, I did a very simple demo for the NES. I've always liked Atari better and while the Jaguar is my favorite Atari console, I think the 7800 is more suitable for a first project. Right now I am only experimenting and playing, hopefully this will result in a real 7800 project later on.

Some random questions that popped up:

 

1) Sprite demo has DLs that take up to 64 (=40h) bytes for each zone, if I understand the following code correctly:

 

DLPOINTH
.byte $22,$22,$22,$22,$23,$23,$23,$23,$24,$24,$24,$24
DLPOINTL
.byte $00,$40,$80,$C0,$00,$40,$80,$C0,$00,$40,$80,$C0
For the sprite demo I'd think 6 bytes would be enough (at max 1 object per zone=4 bytes + 2 bytes end DL list). Is this assumption/reasoning correct? (I did a quick test and it seemed to work, but would like to double-check if I understand these things correctly)
2) I believe the Sprite Demo is updating the DLs even when nothing's changed. I'd assume that an efficient game will only touch the DLs if something had changed to spare cycles, correct?
3) In 320x1 mode, that I believe Sprite Demo uses, sprites are stored like this:
org $a000
.byte %00111100
org $a100
.byte %00111100
...etc...
I now understand why sprites are stored like this, but it still seems quite wasteful. I wonder whether (in this 320x1 case) i.e. bytes A001 to A0FF can safely be used to store game data?
I have much more questions (for example, I don't know how to implement timers), but first I'll play around more first :)
Thanks for being a great community! When I read the 7800 docs years ago, I thought I'd never master this, but I believe it is in my reach now, thanks to all great posts, articles, tools, sample code etc. on this (and other) sites.
Edited by ArcadeAction
Link to comment
Share on other sites

3) In 320x1 mode, that I believe Sprite Demo uses, sprites are stored like this:

org $a000
.byte %00111100
org $a100
.byte %00111100
...etc...
I now understand why sprites are stored like this, but it still seems quite wasteful. I wonder whether (in this 320x1 case) i.e. bytes A001 to A0FF can safely be used to store game data?

 

Yes, they can safely be used to store game data. If sprite A starts at A000, and then takes up A100, A200, A300, etc, it means the 7800 is completely stepping over A001-A0FF.

 

So if the 7800 is grabbing the sprite at A001, it'll be adding 100 hex to it again for each line of the sprite as usual. So it'll safely grab A001, A101, A201, A301, etc. Think of it as storing the first byte of all the sprites in the graphics bank one after the other from A000 to A0FF. Then the second byte of all the same sprites from A100 to A1FF, etc.

Link to comment
Share on other sites

Q1 & 2 - Building the display lists is one of the great challenges with the 7800. As usual, some tradeoffs have to be made between space (RAM) and speed (CPU cycles).

 

Q1 - Yes, 6 bytes per display list is enough for a single 4 byte display list entry and the 2 byte end of list entry.

 

Q2 - While not rebuilding the entire display list sounds more efficient, it is difficult to accomplish in practice. First, as sprites move vertically they need to be removed from one display list and added to another - which means the remaining entries in the display list would need to be rewritten anyway. (Unless you pad the display list with transparent sprites, which will rob your game of precious CPU cycles due to the additional MARIA DMA.) Second, the extra time and space required to determine whether the sprite needs to be updated and finding it in the list can easily negate the savings of not simply rebuilding the display list.

 

Q3 - Yes, you can certainly use any space not used for sprites for code or other data - just don't let it spill onto the next page. However, I'd start with the assumption you're going to use the entire 2K / 4K block for sprite graphics until you run out of space on the holey DMA pages.

Link to comment
Share on other sites

 

Hello,

 

For the last several weekends, I have been studying the 7800 docs, high quality AA forum posts including (but not limited to!) "HoleyDMA & Atari 7800", "Differences between Atari 2600 and Atari 7800 sprite colors?" and played around with the MAME emulator and the well-known "Atari 7800 sprite sample" demo by Daniel Boris (this demo was extremely helpful by the way).

 

Now that I wrote down RAM/ROM addresses, checked memory dumps with MAME's excellent built-in debugger and memory window, I finally feel somewhat comfortable about DL and DLLs, "holey DMA", storing graphics upside down, etc. I believe I finally understand these concepts and how sprites are stored, displayed and moved. Although I have tons of things to find out and research, next thing on my list is experimenting with the various graphic modes (although I plan to stick with 160 resolution for the time being) and Indirect/Character mode.

 

I am not completely new to 6502 asm. About ten years ago, I did a very simple demo for the NES. I've always liked Atari better and while the Jaguar is my favorite Atari console, I think the 7800 is more suitable for a first project. Right now I am only experimenting and playing, hopefully this will result in a real 7800 project later on.

Some random questions that popped up:

 

1) Sprite demo has DLs that take up to 64 (=40h) bytes for each zone, if I understand the following code correctly:

 

DLPOINTH
.byte $22,$22,$22,$22,$23,$23,$23,$23,$24,$24,$24,$24
DLPOINTL
.byte $00,$40,$80,$C0,$00,$40,$80,$C0,$00,$40,$80,$C0
For the sprite demo I'd think 6 bytes would be enough (at max 1 object per zone=4 bytes + 2 bytes end DL list). Is this assumption/reasoning correct? (I did a quick test and it seemed to work, but would like to double-check if I understand these things correctly)
2) I believe the Sprite Demo is updating the DLs even when nothing's changed. I'd assume that an efficient game will only touch the DLs if something had changed to spare cycles, correct?
3) In 320x1 mode, that I believe Sprite Demo uses, sprites are stored like this:
org $a000
.byte %00111100
org $a100
.byte %00111100
...etc...
I now understand why sprites are stored like this, but it still seems quite wasteful. I wonder whether (in this 320x1 case) i.e. bytes A001 to A0FF can safely be used to store game data?
I have much more questions (for example, I don't know how to implement timers), but first I'll play around more first :)
Thanks for being a great community! When I read the 7800 docs years ago, I thought I'd never master this, but I believe it is in my reach now, thanks to all great posts, articles, tools, sample code etc. on this (and other) sites.

 

 

It's nice to see someone still using me sprite demo code!

 

1. You are right, 6 bytes would be enough for each DL, but I setup the code presuming you would have more then one sprite in a game. To save memory you would want to size the DL's appropriately for your game.

 

2. As Eric pointed out rebuilding only the DL's that change would be tricky. Not only will sprites move from one DL to another, they will often span two DLs. SInce most of the time you won't be able to predict how much needs to be re-built you need to allocate enough time in each cycle for the worst case anyway.

 

3. Yes, you can use the memory for other things, but a lot of it will get filled up with graphics data.

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

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...