New Programmer Questions

[Roy]

Hello, new 7800 programmer here. (Though I have a decent grasp on assembly itself.) Like others, I am trying to understand how the system displays graphics. I have a pretty good idea how the data should look, but in code samples I am looking at, there's a few things I am having a hard time visualizing. I'll use this same thread for any questions I may have in the future.

 

PasteBin link here

 

First, I commented a bunch of address locations with data from the build DLL section. Purely to help me see whats going on. Does all of this make up an entire screen where they essentially point to display list entries? Sorry if I am not making much sense, still getting a grasp on assembly jargon.

 

Second, What is the section of code labeled "add DL end entry on each DL" for exactly? I know it adds an entry to the end of each DL, but I don't quite see how the code works here. I guess that dlpnt variable is throwing me off. I was under the impression that a DL was made of either 4 or 5 bytes. (Address low, palette, width, etc...)

 

Last, I don't quite understand how a sprite defined in a display list moves on the Y axis. I have read a lot of documentation, but much of it is still over my head.

 

Sorry again if I am not making much sense. My first assembly experience was on the NES, and it's display method was radically simpler. (To me anyway.) Thanks for taking your time to read this!

[PacManPlus]

Hello and Welcome!

 

To answer your questions quickly (I'm still setting up my office at home after having just moved):

 

- A list of DLs (called a Display List List, or DLL) defines the screen (including vertical blank areas). You must define 243 scanlines for NTSC. Approximately 192 of those scanlines are 'seen' on the screen, some games use more, but the 'standard' was 192. (For PAL, it's 293 scanlines to be defined). Short answer, you were correct in your assumption.

 

- A DL *is* made of 4 or 5 bytes, but it has to know when to stop reading data. The DLEND variable in that example keeps track of the end of the display list so it can place zeros to terminate the DL (zeros in the first two entries of a display list marks the end).

 

- Moving a sprite vertically was one of the most difficult things to wrap my head around when learning this. Think of it as adjusting the beginning address of a sprite definition to only show the portion of the sprite that you need in a particular display list. For example, if you have two display lists, both 8 scanlines high, and you have a sprite that starts on scanline 2, you would have to adjust the high byte of the sprite that the DL is pointing to so it only displays the first 6 scanlines of the sprite. You will very quickly see why 'holey DMA' is useful here. Also, remember that the sprites are held 'upside-down', so the afore mentioned adjustment is actually the opposite of what you would think.

 

I hope this helps.

 

Bob

[Roy]

Thanks for the reply, Bob!

 

I think I got what your saying about vertical movement. I guess my thinking was that DL's had to be 'static'. I'll keep going over the code and see what I can figure out!

[Rybags]

Read up on "holey DMA" - the sprite layout is such that each scanline's data is +256 from the previous.

In conjunction with holey DMA, that allows a sprite to be finely positioned vertically within the DL zone with the required top/bottom parts blanked out.

[EricBall]

https://sites.google.com/site/atari7800wiki/graphics-programming/display-lists

https://sites.google.com/site/atari7800wiki/graphics-programming/vertical-motion

http://www.atarimuseum.com/ahs_archives/archives/pdf/videogames/7800/gcc1702b_maria_specs.pdf

 

The display list is a sequence of display list entries which are either 4 or 5 bytes long, depending upon the 2nd byte. The end of the list is indicated by an entry where the 2nd byte is zero. (i.e. the display list end entry is 2 bytes).

[Roy]

Thanks for the replies everyone. I think I figured it out.

 

Since a sprite can exist in only one or two zones as a time, you need two entries to cover both. The second entry needed if the sprite does not fit in the first zone. The holey dma is needed when the sprite address is adjusted, so the display list entry does not start displaying a totally different piece of sprite. When the sprite completely fits into the new zone, the second display list entry is no longer needed, so the code skips that section until the sprite enters a new zone.

 

Is this thinking correct? If so, that was way less complicated than I though it to be.

[Rybags]

A sprite in such terms of occupying >1 zone is sort of an abstract concept. In theory a sprite could take the entire screen vertically.

Think of zones as fixed areas e.g. 8 or 16 pixels high. Holey DMA is needed whenever the sprite isn't hard up against the top of the zone.

 

It's up to the program to determine which DL zones require entries for a given sprite. Given that most people will work in areas that work out to be powers of 2, it makes calculating/determining stuff simple since the 6502 bit manipulation instructions can do a lot of the work.

 

Bob has put up source code for a whole bunch of games he wrote, having a look at that stuff could be helpful.

[Roy]

Okay, thanks for the clarification. Things are beginning to make a bit more sense.

[EricBall]

A display list describes the sprites on a number of lines (typically 8 or 16). The pointer in the display list entry points to the last line of the sprite, with each previous line being on the next page in ROM. So if the sprite moves down a line, the pointer is adjusted to bottom line + 256. Then an entry in the next display list with a pointer = bottom line - 256 * (number of lines in zone - 1). "Holey DMA" is so you don't have to waste ROM space for the lines above and below the sprite.

 

Building (or updating) the display lists is a non-trivial thing to do efficiently. Just like the kernal of a 2600 game, there is value in ensuring all data structures in a 7800 game are arranged to make building display lists as efficiently as possible.

[Roy]

Bumping my year old thread for a new question!

 

For anyone using CA65, what does your .cfg look like? I was attempting to write my own, but the .map showed that everything was not in the right spot and the file ended up too small...

 

I'm coming back to coding for the Atari after getting a bit more experience under my belt with the NES and feel ready for a new challenge. Thanks in advance to anyone who can help!

 

EDIT:

 

Scratch that just got it working.

Edited February 12, 2015 by Roy

[Roy]

Sorry for bumping my thread again, but I finally made some progress.

 

I decided to start from scratch using CA65, and going over all the information provided by these forums, I can finally display sprites and understand how DL & DLL's work. (For the most part. Still have a lot to learn) I would be using 7800basic, but I find I have far more fun with assembly.

 

Next, I need to make my display lists dynamic instead of hard-coded routines.

 

Here's a working .a78 file: 7800demo.a78

All it does is display two sprites, and move them horizontally.

 

Though I have a question about the blue ship I made. In its display list, I'm using direct mode to specify where the graphics are, but no matter what I set the width to (This is where it specifies how many bytes to read, right?), it also shows the enemy ship sprite to the right of it. Any ideas why?

 

Thanks again to everyone who helped me a while back!

 

Edit:

 

Never mind, I seem to have fixed my issue. Seems in the DL entry for bytes to fetch, it was reversed. Like to fetch 4 bytes with the palette 0, I would use #$1C instead of #$04 like I originally did... I don't quite understand this, but it works. Found out using the MESS debugger and editing the DL entries by hand.

 

I also added dynamic DLs for the player and one enemy ship, and uploaded the new .a78 file.

7800demo.a78

Edited February 19, 2015 by Roy

[RevEng]

Never mind, I seem to have fixed my issue. Seems in the DL entry for bytes to fetch, it was reversed. Like to fetch 4 bytes with the palette 0, I would use #$1C instead of #$04 like I originally did... I don't quite understand this, but it works. Found out using the MESS debugger and editing the DL entries by hand.

$100-$04=$1C, which is how you need to represent the width to Maria. I believe the idea is that it's a two's complement negative number.

 

Check out the 7800 Software Guide if you haven't already.

[Roy]

Thanks for the reply, I actually printed that document yesterday. That thing has been my 7800 bible so far, thanks for writing it by the way! Like you said, its way easier on the eyes.

[Roy]

Got another question for you guys...

 

For a few days I have been having trouble with my graphics being corrupt and random garbage being drawn on the bottom of the screen in MESS and the prosystem emulator along with sound messing up once and a while. I was looking around, and thought maybe I was having timing issues (I think?) when I came across people talking about DLIs.

 

I added a DLI at the beginning and end of my DLL, and to see if I was putting code in the right place I incremented a debug variable to look at in the memory viewer in MESS. Before I added any additional code, it seemed some graphic glitching on my main screen disappeared, but the graphics I purposely coded in were still scrambled. I burned my program to an eprom to see what happened on real hardware, and the game runs flawlessly! (Fixed at the time of writing, just emulator header issues.)

 

Question is: How did adding two DLIs that do nothing except increment a value, fix random junk being drawn to the bottom of the screen? I'll post the ROM I'm working on. This time, all I have is a title screen that plays music from Ms Pac Man. (I borrowed the sound engine from Atari's source code) When you push up, it kills the music and jumps to the 'playing' section of the game. Ignore the Facility 15, just a silly fake company.

 

The first version is before I added the DLIs and the second one is without. Both have the header, so you'll need to strip it before thrown into an eprom. I can't seem to fix the header issue, so I'm posting a 48KB file that runs fine without the emulator corrupting graphics. I'm perfectly running it on a Ballblazer eprom cart with a bit of code modification.

 

Thanks for any insight. I'm stumped how this 'fixed' my glitching.

 

EDIT: Warning, horrible audio screeching will be heard, but sounds fine on real hardware.

7800demo DLI.a78

7800demo NO DLI.a78

Edited March 1, 2015 by Roy

[Roy]

Just felt the need to post an update regarding my program...

 

First, which is still confusing, I don't know why the DLI fixed my issue with the graphics. I have merely accepted that it is fixed and I'll find out why in the near future.

 

Next, I have a lot of under the hood routines in place for handling sprites and "waves" of enemies. This was one of the harder things to program, and it's still only a quarter(ish) of the way done! I have to also thank CPUWIZ again for helping me with other issues here and there and getting my program to work better with the MCP Dev cart. I also implemented a protection routine to detect single or double button pushes after learning of the danger of hardware damage.

 

Finally, I have all my needed visual assets finished. Here is the scope of my little project:

 

This will be a simple shoot em' up that features few enemy types and 4 bosses. So far, I have been only using direct graphics mode, so i don't think I'll have any backgrounds to keep you entertained. The focus is on mechanics anyway. I want to stick to using only 32KB and assuming I have any space left, I'll try to implement some crappy pokey music. I really don't like announcing and showing off unfinished projects, as many of us have seen threads eventually die from the programmer losing interest. However, I'm working with a friend who is helping with sound, which is taking off a huge workload for me. Considering everything here, I feel this will be finished sometime during the summer, since I only work on this in spare time. Once this is done, I'll keep expanding on the game and making something better. (XM!) :drools:

 

What I have attached is not much of an upgrade visually from my previous post, but is far more elegant (using this word very loosely. I have spaghetti code. ) under the hood. Pressing a fire button on the main screen takes you to the play-field where you will see a swarm of enemies. No collision yet. Pressing both buttons will just rapidly reset the game. It's purpose is to take me back to the MCP BIOS screen to be reprogrammed. Oh, I also totally screwed up the music, so please turn down your volume. It's worse than last time.

 

Thanks for reading my long-winded post! I'll have some more exciting things to play with next time.

7800POKEYdemo.bin

[RevEng]

I think your random garbage was due to the header not actually being present on your on your a78 files - they're exactly 48k, instead of 48k+128 bytes. If I run my 7800basic header inspection program on it, it returns garbage values for key things like rom size.

 

I added a header to your 7800demo NO DLI.a78, and now it plays great in MESS, without garbage.

 

7800demo NO DLI.a78

 

Adding your DLI probably just shifted some ROM around so the -128 byte offset had an effect elsewhere.

 

Anyway, nice start. Keep up the good work!

[Roy]

Thanks for the reply!

 

Ah, my bad. The recent one was being put directly to the Dev cart, so I forgot to add the header. I think, not at home at the moment...

 

Strange, could have sworn the nodli rom had the header. Must have been me tearing into the code and messed something up in an early test.

Edited April 1, 2015 by Roy

[Roy]

Another update! This time I have a lot of the underlying structure in place. I can spawn waves of ships by altering a few bytes of data, specify when a boss shows up, and added a scrolling background that needs a little graphical glitching worked out. (you'll see it near the top when enemies pass through) Still no custom music, but replaced that horrible noise from before with Ms Pacman music again as placeholder.

 

Up next, once I have some glitches ironed out, I'll add the ability to shoot and get shot at, add a collision system, EXPLOSION routines, change the background for the boss, make a better title screen, and a bunch of other standard features. (pausing, score system, etc...)

 

Let me know if you have any problems displaying the game, I think I have the headers right this time.

7800demo.bin

[Trebor]

Displays exactly as described

[Roy]

Good to hear! Man, hearing that title music makes me cringe every time. I may disable sound altogether until I have some decent music!

 

Also, if you stick around for 16 enemies, you'll see one of the bosses slide in from the side. As you saw, holding both fire buttons resets the game. This is actually to boot me back to CPUWIZ's devcart bios. Handy for hardware testing, but annoying in emulators.

 

Since posting, I have already fixed all my background glitching. Turns out moving the scrolling routine into the display interrupt makes a world of difference! Off to add features now.

 

Edit:

Attached a ROM that I feel is a better showcase of the current project. More stability, ram properly cleared. (d'oh!) This one tested in Prosystem Emulator, the most up-to-date MESS, and actual hardware.

7800demo.bin

Edited April 22, 2015 by Roy

[Trebor]

Good to hear! Man, hearing that title music makes me cringe every time. I may disable sound altogether until I have some decent music!

 

Also, if you stick around for 16 enemies, you'll see one of the bosses slide in from the side. As you saw, holding both fire buttons resets the game. This is actually to boot me back to CPUWIZ's devcart bios. Handy for hardware testing, but annoying in emulators.

 

Since posting, I have already fixed all my background glitching. Turns out moving the scrolling routine into the display interrupt makes a world of difference! Off to add features now.

 

Edit:

Attached a ROM that I feel is a better showcase of the current project. More stability, ram properly cleared. (d'oh!) This one tested in Prosystem Emulator, the most up-to-date MESS, and actual hardware.

 

Thank you!

 

Just one minor thing. The 7800 ROM files you're posting with the header are typically listed as *.a78 files.

It helps in avoiding confusion with 7800 ROM files that are without headers, which are listed as *.bin.

[Roy]

Ah forgot about that, thanks! I'll do so for the next one.

[RevEng]

It's looking really good, Roy. Keep on going!

[Jinks]

It's looking really good, Roy. Keep on going!

Great work!! The graphics are extremely impressive!! This needs pokey sound!

[Trebor]

The scrolling background and boss look fantastic. Keep up the awesome job, Roy!