7800 Development

[EricBall]

The DPPH & DPPL registers give the 16 bit address of the first display list list entry. Each DLL entry follows the previous in memory. Each DLL entry contains a 16 bit address of the first entry in the display list used for OFFSET+1 lines (the DLL "zone"). (Each display list entry follows the previous in memory.) Each direct mode display list entry contains a 16 bit address of the bottom right sprite data. The current OFFSET value is added to the high byte of the bottom right address to get the address of the current line sprite data. After each line, the current OFFSET value is decreased, unless it is zero in which case MARIA uses the next DLL entry.

 

Each sprite uses one (or more) display list entries. Sprites wider than 32 bytes need more than one entry in a single display list. This is also try for sprites which wrap around horizontally. Sprites which span more than one DLL zone (typically 8 or 16 lines), either because they are tall or moving vertically, need more than one display list entry in multiple display lists. Dynamically building display lists is a lot of work and takes a lot of time.

[EricBall]

With the renewed interest in 7800 Development, I've created Atari 7800 Programming with the info I previously had in the Atari 7800 Programming wiki. If anyone is interested in contributing (or culling info from AA) please let me know.

[DracIsBack]

Nice to see this back, Eric! Great resource. Looking forward to seeing it grow, now that a new flux of 7800 coders have come on the scene since this originally was done.

[GroovyBee]

With the renewed interest in 7800 Development, I've created Atari 7800 Programming with the info I previously had in the Atari 7800 Programming wiki. If anyone is interested in contributing (or culling info from AA) please let me know.

 

With the advent of G2F and 160C in the "NES vs" colour section the nod should now go to the 7800 when displaying static screens. Mind you, I don't think the stock NES could do an 8way scroller like my game Dungeon! at 25 colours per scan line either.

[kamakazi]

Too bad that the link can't be posted to the top page.

[gdement]

With the renewed interest in 7800 Development, I've created Atari 7800 Programming with the info I previously had in the Atari 7800 Programming wiki. If anyone is interested in contributing (or culling info from AA) please let me know.

 

With the advent of G2F and 160C in the "NES vs" colour section the nod should now go to the 7800 when displaying static screens. Mind you, I don't think the stock NES could do an 8way scroller like my game Dungeon! at 25 colours per scan line either.

 

There's a few parts of the NES vs 7800 analysis I disagree with. It was originally posted in the forum, and at the time I thought about responding with my own version but I didn't.

 

As far as colors per line goes, unless I'm mistaken the NES can display up to 16 colors in the background and another 16 on the sprites, so 32 colors on a scanline is possible. Those numbers might not be exactly right, I'd have to review the programming specs which I haven't looked at in forever.

In practice though, that's unlikely to happen since each sprite and background tile can only use 3 colors. The 7800's advantage is that it supports 12 color sprites, but those can't be used often so it's a minor advantage.

I don't think 8-way scrolling is an issue with an appropriate mapper chip.

[DracIsBack]

As far as colors per line goes, unless I'm mistaken the NES can display up to 16 colors in the background and another 16 on the sprites, so 32 colors on a scanline is possible.

 

I think that's the SMS ...?

 

I'm glad Eric posted this again. It was a great effort when it was done (hadn't really been done before in a formal fashion, IIRC) and there have been some advances and new experts appear to add to it.

[EricBall]

With the advent of G2F and 160C in the "NES vs" colour section the nod should now go to the 7800 when displaying static screens.

I think both of those graphics modes fall into the same class as the Amiga Hold-and-Modify (HAM) mode - great for static, pre-rendered graphics, not very useful for an actual game. (Then again, Tower Toppler uses artifact color intelligently, so never say never.) Also, I'm not sure that similar effects couldn't be generated on the NES.

 

Mind you, I don't think the stock NES could do an 8way scroller like my game Dungeon! at 25 colours per scan line either.

Umm... The NES PPU has a total palette of 25 colors: background + 4 sprite palettes of 3 colors + 4 tile palettes of 3 colors. Each sprite could use any of the 4 sprite palettes and each group of 2x2 8x8 tiles could use any of the 4 tile palettes. So it's certainly possible to use 25 colors on a single scan line. 8 way scrolling would require extra RAM in the cartridge, but it's fully supported in hardware.

Edited September 16, 2010 by EricBall

[gdement]

As far as colors per line goes, unless I'm mistaken the NES can display up to 16 colors in the background and another 16 on the sprites, so 32 colors on a scanline is possible.

 

I think that's the SMS ...?

I've never read any details about SMS graphics.

But what EricBall posted sounds like what I'm remembering. So it's 25, not 32.

 

 

The NES PPU has a total palette of 25 colors: background + 4 sprite palettes of 3 colors + 4 tile palettes of 3 colors. Each sprite could use any of the 4 sprite palettes and each group of 2x2 8x8 tiles could use any of the 4 tile palettes. So it's certainly possible to use 25 colors on a single scan line. 8 way scrolling would require extra RAM in the cartridge, but it's fully supported in hardware.

[DracIsBack]

Just found this but not sure about validity

 

http://ahefner.livejournal.com/11670.html

[Harry_Dodgson]

Let's see if I understand correctly how the Display List and Display List List work. I won't be displaying any code but putting in English basically what I am understanding these do.

 

First, graphics are put in a Display List, so to speak. Without using the OFFSET, it is to my understanding that each raster (or sprite) would need its own DL. When Maria goes to "fetch" the graphics data, it uses a Display List List that will point to the DLs. Is this right?

 

In simple terms, the DL is what happens vertically on the screen (in 8 or 16 line zones). It points to several DLLs which is what happens horizontally on the screen. Therefore for a single level, the DL is usually setup and left alone. The appropriate DLL is rewritten everytime something changes in that zone - If the player moves up from zone 7 to zone 6, he gets removed from the zone 7 DLL and put in the zone 6 DLL. If the player moves right on the screen, the entry in the zone 7 DLL changes to show the new horizontal location. The DLL is created so farthest things are first and nearest are last in line.

[EricBall]

In simple terms, the DL is what happens vertically on the screen (in 8 or 16 line zones). It points to several DLLs which is what happens horizontally on the screen. Therefore for a single level, the DL is usually setup and left alone. The appropriate DLL is rewritten everytime something changes in that zone - If the player moves up from zone 7 to zone 6, he gets removed from the zone 7 DLL and put in the zone 6 DLL. If the player moves right on the screen, the entry in the zone 7 DLL changes to show the new horizontal location. The DLL is created so farthest things are first and nearest are last in line.

Hi Harry. A good explanation except you've reversed DLL and DL. The Display List List entries point to Display Lists which are then used to display several lines. And if a sprite moves between zones the Display List entry for that sprite is put in the appropriate Display List.

[Harry_Dodgson]

In simple terms, the DL is what happens vertically on the screen (in 8 or 16 line zones). It points to several DLLs which is what happens horizontally on the screen. Therefore for a single level, the DL is usually setup and left alone. The appropriate DLL is rewritten everytime something changes in that zone - If the player moves up from zone 7 to zone 6, he gets removed from the zone 7 DLL and put in the zone 6 DLL. If the player moves right on the screen, the entry in the zone 7 DLL changes to show the new horizontal location. The DLL is created so farthest things are first and nearest are last in line.

Hi Harry. A good explanation except you've reversed DLL and DL. The Display List List entries point to Display Lists which are then used to display several lines. And if a sprite moves between zones the Display List entry for that sprite is put in the appropriate Display List.

 

Ooops

[GroovyBee]

The DLL is created so farthest things are first and nearest are last in line.

 

Just to clarify that "farthest" in this context means depth into the screen. If you have two overlapping sprites J and K then sprite K will be displayed in front of sprite J if K's DL entry comes after J's DL entry.

[OldAtarian]

Hey guys!

 

I originally started this thread under another topic. It was suggested that I post it here. Here's what is going on:

 

1st, I'm in the process of learning the 7800 console. I'm not using any emulation...I'm using an actual Atari 520ST and a 7800 console connected to each other by way of printer port and cartridge port. I'm new to assembly and someone has already suggested an online book based on learning the language. The help I have gotten so far has been tremendous and very much welcomed and appreciated.

 

2nd, the person supporting me is sending me actual Atari documentation on programming the 7800...and what I learn I would like to start another thread to post what I've learned (with some secrets kept for myself LOL). I was trying to find any and all information I could find surrounding development for the 7800. If anyone out there including those that have already posted, find or know anything about programming the 7800, please pass on the information.

 

Thanx in advance for the information.

Where do you get a cable that goes between the ST and the 7800 cartridge port?

[GroovyBee]

Where do you get a cable that goes between the ST and the 7800 cartridge port?

 

You also need the 7800 development cart. A few AA members have them. The modern equivalent would be a CC2 or batari's forthcoming H2.

[Mord]

Where do you get a cable that goes between the ST and the 7800 cartridge port?

 

You also need the 7800 development cart. A few AA members have them. The modern equivalent would be a CC2 or batari's forthcoming H2.

 

And I for one will definitely be keeping an eye open for the H2.

[kamakazi]

I'll be keeping my eye on the H2 as well. Groove Bee is right OldAtarian. However, I do remember Best Electronics saying that they had the complete 7800 devkit. But he won't separate them. It's expensive too. If I'm not mistaken...an old parallel cable (male on both ends) is the cable you are looking for. This is one port that seems to be missing from a lot of today's computers since most printers today are USB. You might check with Tiger Direct(dot)Com for a cable or any local computer store. Radio Shack may still have some laying around somewhere...but it is a cable that was replaced with USB technology.

[~llama]

I've been out of the Atari scene for a couple of years, but I've been playing my 7800 a ton lately, and have half a mind to get back into 6502 programming (after a misguided attempt at writing some stuff for the Tandy CoCo).

 

I have an assembler (Bruce Tomlin's asmx), and all the 7800 and 2600 documentation, but I keep seeing references to a C toolchain for 7800 programming... what is this toolchain? CC65 doesn't seem to support the 7800 out of the box. (Or is that just GroovyBee's personal tools, which haven't been publicly released?)

 

Also, are there any differences between the GCC "3600 Software Guide" and the Atari "7800 Software Guide"? If so, which one is more reliable?

 

Anyways, this thread was a big help. Thanks

[nathanallan]

This might help:

 

cablesonline.com

 

there is a huge clearance section most of the time, and male-male parallel cables are always cheap.

[GroovyBee]

I have an assembler (Bruce Tomlin's asmx), and all the 7800 and 2600 documentation, but I keep seeing references to a C toolchain for 7800 programming... what is this toolchain? CC65 doesn't seem to support the 7800 out of the box. (Or is that just GroovyBee's personal tools, which haven't been publicly released?)

 

My CC65 library for the 7800 hasn't gone public yet. There is also a game development library to go along with it and some other command line tools. The game library includes support for sprites, bounding box detection, printing text, BCD score handling, sound effects, music, SaveKey and raw/debounced joystick.

 

Also, are there any differences between the GCC "3600 Software Guide" and the Atari "7800 Software Guide"? If so, which one is more reliable?

 

Neither! You want the GCC MARIA spec here.

[~llama]

My CC65 library for the 7800 hasn't gone public yet. There is also a game development library to go along with it and some other command line tools. The game library includes support for sprites, bounding box detection, printing text, BCD score handling, sound effects, music, SaveKey and raw/debounced joystick.

 

Sounds very useful. I've gone and played a lot of your available binaries--are you using this framework for all your 7800 projects? Because if so, it seems quite powerful.

 

Neither! You want the GCC MARIA spec here.

 

Wow. That is a lot more detailed than either of the other two documents. Thanks for the pointer! Any other docs I need to know about? I went ahead and downloaded every 7800 technical document on the AHS site.

Edited November 17, 2010 by ~llama

[GroovyBee]

Sounds very useful. I've gone and played a lot of your available binaries--are you using this framework for all your 7800 projects? Because if so, it seems quite powerful.

 

My games written in "C" are Wasp!, Worm!, Harry's Hen House, my Halloween themed game and Monster! The others are assembly language using the CC65 assembler. Tempest is a BBC micro port (UK home computer) which was reverse engineered and then an adaptation layer constructed to get it to work on the 7800.

 

Wow. That is a lot more detailed than either of the other two documents. Thanks for the pointer! Any other docs I need to know about? I went ahead and downloaded every 7800 technical document on the AHS site.

 

That is pretty much the only document you need to get going. The Atari 7800 document has errors so its best used as alternate reading material (for a different slant on things).

 

If you get stuck or want or have any questions feel free to post in the 7800 programmers section.

[+Mitch]

Neither! You want the GCC MARIA spec here.

 

There's a slightly later version of it on this page. I did not due a compare to see what changed however.

 

Mitch

[GroovyBee]

There's a slightly later version of it on this page. I did not due a compare to see what changed however.

 

I'd say its a different document entirely .