Hardware Questions?

[BladeJunker]

Since I got a 7800 I've been delving into its hardware capabilities but a few areas need clarification. I'm more of a doodler than a coder so use novice terms please.

 

I do like how wide a sprite can get in 160 modes and how the rendering clips directly to the alpha dimension, that is something that is a huge pain in the ass on the NES to do without flickering.

 

 

-Is most of the performance of the 7800 in its graphics chip because the CPUs look the same on the 7800 and 5200?

 

-Is it fair to say the 5200 has more hardware options than the 7800 but is slower? For example the 5200 has 14 modes of screen resolution but the 7800 has 4?

 

-Is high-res bitmap use restricted to vertical zones of isolation or can you just switch back and forth per scanline? It doesn't look you can do what they do on C64 as far as mixing bitmaps.

 

-Is the system memory a bottleneck compared to the 5200 or is added cartridge memory common? Quite a drop from 16 down to 4 no?

 

-Does the 7800 have much memory for keeping graphics ready for use? Like compared to the NES can I use 128X128(64X128) for "tiles" and 128x128(64x128) for sprites?

 

-Does higher res bitmap use come with a drop in color depth by default or is that just a memory limitation to choose that? Like can you choose 320 mode with 4 color bitmaps if you plan not to have a lot of graphics data EG. Text Mode?

 

-Does the 7800 struggle much with scrolling, like lots of sprites or scrolling but not both? Seems like it scrolls well but specs say it has no dedicated hardware for it. Also does it scroll vertically more easily than horizontal like the 2600?

 

Any help on these matters will be most appreciated.

[tdididit]

you should check atari 7800 specification

 

MARIA got tile font based modes and raw graphics modes and large sprites

every got its pluses and minuses.

0 color is always transparent, so you can multiply colors by displaying two tiles lying in same place, every layer can use different color set

 

only limitation is size of Display Lists List (DLL)

 

fonts or sprite data can be placed in ROM so same like in NES you can use two or more banks for tiles animation

 

Scrolling is easy, horizontal by screen offset in DLL, vertical by extra Display List entry

 

A7800 got only 4kB of RAM + 128b of RIOT RAM, all the rest you can find in extra hardware

 

16kB in SG carts

128kB in 8x 16kB banks in XM

Edited February 1, 2016 by tdididit

[BladeJunker]

you should check atari 7800 specification

Can you recommend a good listing, which do you think is best?

 

MARIA got tile font based modes and raw graphics modes and large sprites

every got its pluses and minuses.

0 color is always transparent, so you can multiply colors by displaying two tiles lying in same place, every layer can use different color set

Like layering? I'm pretty comfortable with the default 3-4 colors but I'll think about it.

 

only limitation is size of Display Lists List (DLL)

I've heard that, I'll try to learn more about them.

 

fonts or sprite data can be placed in ROM so same like in NES you can use two or more banks for tiles animation

So I can use an equal amount of graphics as the NES, cool.

 

Scrolling is easy, horizontal by screen offset in DLL, vertical by extra Display List entry

I thought it might be since most examples work well. I guess if it stayed longer we'd have seen a lot more scrolling games.

 

A7800 got only 4kB of RAM + 128b of RIOT RAM, all the rest you can find in extra hardware

RIOT RAM looks pretty good, does it run pretty fast in access speed, equal to the system memory?

 

16kB in SG carts

128kB in 8x 16kB banks in XM

Sorry SG carts? Are we talking about ROM size?

[Mord]

Since I got a 7800 I've been delving into its hardware capabilities but a few areas need clarification. I'm more of a doodler than a coder so use novice terms please.

 

I do like how wide a sprite can get in 160 modes and how the rendering clips directly to the alpha dimension, that is something that is a huge pain in the ass on the NES to do without flickering.

 

 

-Is most of the performance of the 7800 in its graphics chip because the CPUs look the same on the 7800 and 5200?

 

-Is it fair to say the 5200 has more hardware options than the 7800 but is slower? For example the 5200 has 14 modes of screen resolution but the 7800 has 4?

 

-Is high-res bitmap use restricted to vertical zones of isolation or can you just switch back and forth per scanline? It doesn't look you can do what they do on C64 as far as mixing bitmaps.

 

-Is the system memory a bottleneck compared to the 5200 or is added cartridge memory common? Quite a drop from 16 down to 4 no?

 

-Does the 7800 have much memory for keeping graphics ready for use? Like compared to the NES can I use 128X128(64X128) for "tiles" and 128x128(64x128) for sprites?

 

-Does higher res bitmap use come with a drop in color depth by default or is that just a memory limitation to choose that? Like can you choose 320 mode with 4 color bitmaps if you plan not to have a lot of graphics data EG. Text Mode?

 

-Does the 7800 struggle much with scrolling, like lots of sprites or scrolling but not both? Seems like it scrolls well but specs say it has no dedicated hardware for it. Also does it scroll vertically more easily than horizontal like the 2600?

 

Any help on these matters will be most appreciated.

 

All the performance on the 7800 is in it's graphics chip imo. The 6502C is used to build the Display Lists, but MARIA does the actual displaying.

 

I don't know if system ram is that big of a bottleneck on the 7800 as the 7800 can do quite a bit with what it's got. Having more ram adds to possibilities of course.

 

The 7800 has it's graphics stored in the rom. The only things in ram are the display lists which are very small compared to the graphics themselves. So long as the graphics are available on the cartridge, the 7800 can use it. (I say this for the case of bankswitched roms - the bank with the graphics would have to be currently selected to use those particular graphics.)

 

The higher res/lower palettes is built into the system. It's not limited by the memory. (The Display lists are the same length for both modes) If what you're doing is more text-heavy, going for a 320 mode would be beneficial I'd think.

 

Scrolling on the 7800 is a result of altering the display lists. It would actually impact the sprites less than you'd think. Having a complicated tiled background would affect it more, since the background tiles would be considered just another sprite to plot to MARIA. (That being said scrolling can be annoying to get up and running. I've figured out horizontal scrolling but still have to fix a couple bugs to get a proper, clean, vertical scroll going.

[BladeJunker]

All the performance on the 7800 is in it's graphics chip imo. The 6502C is used to build the Display Lists, but MARIA does the actual displaying.

Okay the CPU is handling the display lists by itself, so the MARIA takes the display burden off the 6502C.

 

I don't know if system ram is that big of a bottleneck on the 7800 as the 7800 can do quite a bit with what it's got. Having more ram adds to possibilities of course.

Had to ask because it sounds small lol. Guess it just depends on the game whether to add RAM.

 

The 7800 has it's graphics stored in the rom. The only things in ram are the display lists which are very small compared to the graphics themselves. So long as the graphics are available on the cartridge, the 7800 can use it. (I say this for the case of bankswitched roms - the bank with the graphics would have to be currently selected to use those particular graphics.)

Alright so that is the how and why about the display lists, interesting. Looks like I don't have to get too concerned about the overall graphics footprint then, sounds like the display shuffle is the challenging part.

 

The higher res/lower palettes is built into the system. It's not limited by the memory. (The Display lists are the same length for both modes) If what you're doing is more text-heavy, going for a 320 mode would be beneficial I'd think.

So that's a default behavior, the 320 sprite will be lower in color always? What happens when the HUD is 320 but the game graphics are 160, is it switching modes back and forth as it renders top to bottom?

 

Scrolling on the 7800 is a result of altering the display lists. It would actually impact the sprites less than you'd think. Having a complicated tiled background would affect it more, since the background tiles would be considered just another sprite to plot to MARIA. (That being said scrolling can be annoying to get up and running. I've figured out horizontal scrolling but still have to fix a couple bugs to get a proper, clean, vertical scroll going.

So the more tile variation in a tilemap together or is it just the changing per row, like would stacks of unbroken lines of the same tile run better? Sounds pretty different than the 5200 and 2600, although I hear the 5200 isn't exactly like the A8s either.

[tdididit]

Can you recommend a good listing, which do you think is best?

 

Like layering? I'm pretty comfortable with the default 3-4 colors but I'll think about it.

 

I've heard that, I'll try to learn more about them.

 

So I can use an equal amount of graphics as the NES, cool.

 

I thought it might be since most examples work well. I guess if it stayed longer we'd have seen a lot more scrolling games.

 

RIOT RAM looks pretty good, does it run pretty fast in access speed, equal to the system memory?

 

Sorry SG carts? Are we talking about ROM size?

 

Specification in attachment

 

in 7800 mode try not use 128bytes of RIOT RAM. it is reserved for 2600 mode

 

SG cart can have 16kB of RAM ($4000-$7FFF), rest is ROM. at $8000-$BFFF bankswitch window (1 from 8 16kB ROM banks), at $C000-$FFFF last 16kB ROM bank

7800_Software.pdf

[Mord]

So that's a default behavior, the 320 sprite will be lower in color always? What happens when the HUD is 320 but the game graphics are 160, is it switching modes back and forth as it renders top to bottom?

 

So the more tile variation in a tilemap together or is it just the changing per row, like would stacks of unbroken lines of the same tile run better? Sounds pretty different than the 5200 and 2600, although I hear the 5200 isn't exactly like the A8s either.

 

Basically yeah, for the sprites. in 160 modes, you have two types. 160A, and 160B. You can use both during the same zone/scanline in this case - you'd change between 160A and 160B in a particular display list entry (for a particular sprite) 160A sprites have 3 colors. 160B combines either palettes 0-3 or 4-7 to give you more color selection. A total of 12 colors + background - 4 entries of the 16 are pointing to the background color (since you're simply combining the palettes.

 

In 320 modes, you have 320A that has 1 color + background, and 320B which has (technically) 3 colors + background, using only palette 0 or 4. Although I've been having trouble with the C1 entries of the palettes. As someone who chose to go with 320B mode for my first game, I'd recommend avoiding it at first. ^_^ (I'm just too determined/stupid to try other modes at this point. )

 

As for tiles, it's just the actual plotting that's eating up your time. Whether they're identical or different. Tiles are generally done using indirect/charactermap plotting, which just takes more prep-time as MARIA will have to do extra prepwork than direct-mode sprite plotting.

[Roy]

There's also a pretty handy wiki full of information here: http://7800.8bitdev.org/

 

Also contains the document tdididit posted. I find myself constantly referring to it.

[+Trebor]

For the extra ambitious or/and curious to see additional practical ways the 320 modes can be applied, Schmutzpuppe provides insight into how they were utilized for Froggie; it includes some code.

 

Within that thread, PAC-MAN-RED showed how the screen colors are configured.

 

For convenience, below is the screen example breakdown in the aforementioned link:

 

 

Here is a video of Froggie in all its 320 glory (Also includes the utilization of POKEY sound).

[BladeJunker]

Specification in attachment

 

in 7800 mode try not use 128bytes of RIOT RAM. it is reserved for 2600 mode

 

SG cart can have 16kB of RAM ($4000-$7FFF), rest is ROM. at $8000-$BFFF bankswitch window (1 from 8 16kB ROM banks), at $C000-$FFFF last 16kB ROM bank

Really hmmm, I'll look into 2600 mode more.

 

Well the SG cart looks pretty versatile, plenty of bank space and options.

[+Trebor]

CPUWIZ has cooked up some awesome cart PCB's for the 7800 in addition to what has been mentioned:

 

MegaCart+ = up to 512K (31 banks at $8000, 1 at $C000) of ROM and 2 x 16K RAM @ $4000

VersaBoard = up to 256K of ROM and 2 x 16K RAM [Among other possibilities]

There are ~500 VersaBoards in Al's possession awaiting some gaming goodness to be placed on them

Bentley Bear's Crystal Quest and Donkey Kong PK, both 144K games with POKEY, have benefited nicely.

[BladeJunker]

Basically yeah, for the sprites. in 160 modes, you have two types. 160A, and 160B. You can use both during the same zone/scanline in this case - you'd change between 160A and 160B in a particular display list entry (for a particular sprite) 160A sprites have 3 colors. 160B combines either palettes 0-3 or 4-7 to give you more color selection. A total of 12 colors + background - 4 entries of the 16 are pointing to the background color (since you're simply combining the palettes.

So that much of 2600/5200 graphics design remains the same the vertical zone isolation requirement, at least it can change as it renders the screen top to bottom. Mostly I noticed in screenshots there weren't any instances of hi-res bitmaps next to low-res bitmaps horizontally. Things like this are what I look for "Don't do that.", " You can't do that." lol.

 

I've been thinking of defaulting to 160A for game graphics and 160B for splash screens. The logic being 160B can concentrate more color into more deliberate images IE. central.

 

In 320 modes, you have 320A that has 1 color + background, and 320B which has (technically) 3 colors + background, using only palette 0 or 4. Although I've been having trouble with the C1 entries of the palettes. As someone who chose to go with 320B mode for my first game, I'd recommend avoiding it at first. ^_^ (I'm just too determined/stupid to try other modes at this point. )

Yeah it looks really hard, I think that's why I've been regarding it as a "picture" or text mode option, reminds me of a mode they have on the Amstrad CPC which is basically like original GB in color depth.

Think of it this way, somebody has to mess around with 320B otherwise what is it there for.

 

It takes some time to get used to double wide pixel graphics, I had a C64 for years but I didn't really practice the art till 2010 and beyond. It's different than a square pixel but there are plenty of standard techniques to using them.

 

As for tiles, it's just the actual plotting that's eating up your time. Whether they're identical or different. Tiles are generally done using indirect/charactermap plotting, which just takes more prep-time as MARIA will have to do extra prepwork than direct-mode sprite plotting.

Well that sounds like it doesn't like tilemaps of any kind lol. I mean how do you get around plotting or making it more efficient?

[BladeJunker]

For the extra ambitious or/and curious to see additional practical ways the 320 modes can be applied, Schmutzpuppe provides insight into how they were utilized for Froggie; it includes some code.

 

Within that thread, PAC-MAN-RED showed how the screen colors are configured.

 

For convenience, below is the screen example breakdown in the aforementioned link:

 

FROGGIE_COLORS.png

 

Here is a video of Froggie in all its 320 glory (Also includes the utilization of POKEY sound).

Yeah I saw that one, really impressive stuff, like wow. I'm not against 320A or 320B but it seems quite particular what you can do with it, like I've seen some impressive C64 hi-res games but it looks hard to find the right balance in performance and graphics. I guess it helps to have something with horizontal lanes being a big part of the design.

[BladeJunker]

CPUWIZ has cooked up some awesome cart PCB's for the 7800 in addition to what has been mentioned:

 

MegaCart+ = up to 512K (31 banks at $8000, 1 at $C000) of ROM and 2 x 16K RAM @ $4000

VersaBoard = up to 256K of ROM and 2 x 16K RAM [Among other possibilities]

 

There are ~500 VersaBoards in Al's possession awaiting some gaming goodness to be placed on them

 

Bentley Bear's Crystal Quest and Donkey Kong PK, both 144K games with POKEY, have benefited nicely.

Wow those are a lot of nice cart options. I've seen plenty of sweet homebrews in the Store here, going to get Frenzy asap, last Colecovision copy I saw was $80 CAD yikes.

 

Looks like any game within this level of throughput is covered with the different cart options. I've been looking at Rolling Thunder on and off, same graphics scale or smaller? All I could decide was to not do a HUD overlay and sharpen up the font. NES port was decent but the 7800 might do bigger sprites.

Regardless the sprites are weird so conversion has been slow on Albatross, skinny and low contrast palette. Also haven't had much luck finding source images of the backgrounds or other sprites. Got so many other things to do but it's been a fun sideline to play with.