2600 in 2006

So it was 2600 in 2006. Will it be 7800 in 2007? I don't know very much at all about the 7800. Does it have the ability to do smooth horizontal scrolling? How many players per line?

So it was 2600 in 2006. Will it be 7800 in 2007? I don't know very much at all about the 7800. Does it have the ability to do smooth horizontal scrolling? How many players per line?

 

I'm thinking I may stick with the 2600, though I've been curious about the 7800. To really exploit the capabilities of old machines requires cycle-accurate emulation, and the 7800 just isn't there yet. Besides, the 2600 represents a much larger audience. Still, the 7800 can do some interesting stuff.

 

The 7800 doesn't have a hard limit on the number of players it can draw or the size thereof. Rather, it's limited by the amount of data that can be fetched from memory during a scan line. It's a clever architecture in a lot of ways, but its abilities are severely curtailed by some unfortunate design decisions. It seems like the people at GCC may have been rushed--ironic, given that once completed the 7800 sat on the shelf for a few years.

 

One of my biggest complaints is that the 7800 was designed for 160-wide graphics (same resolution as the 2600) and its ability to handle 320-wide graphics seems to have been an afterthought. There's a hardware line buffer which has five bits per each 160-wide pixel; normally these five bits are used to select one of 25 colors, but there are two modes which split each 160-wide pixel into two parts which different bits from the five. Unfortunately, one of the modes requires that any double-pixel must either have both pixels the same color, or must have one pixel be the 'background' color; it's not possible to have two non-background pixels in the same double pixel. The other mode avoids that limitation, but is limited by the fact that unless transparent objects are disabled (meaning all objects are drawn in an opaque box as in the arcade game "Kangaroo") it's not possible to draw pixels in color 2 or 6 unless they are sharing a double pixel with color 1, 3, 5, or 7.

So it was 2600 in 2006. Will it be 7800 in 2007? I don't know very much at all about the 7800. Does it have the ability to do smooth horizontal scrolling? How many players per line?

Smooth horizontal scrolling is trivial (in 160 res) on the 7800 as each sprite has it's own horizontal position in it's display list entry. It's trickier in 320 res modes both due to the color issues supercat mentions and because the horizontal positioning is only on even pixel boundaries. Vertical scrolling is more difficult, especially with a background. (Though not impossible.)

 

The number of sprites per line is limitted by the number of bytes fetched from RAM/ROM and the space allocated to each display list. My bouncing ball demo can handle 29 sprites (2 bytes each) per line (with no background).

It's a clever architecture in a lot of ways, but its abilities are severely curtailed by some unfortunate design decisions.

Yes/no. I think the biggest problem is the CPU load caused by the display list and shared memory architectures. Putting MARIA on a separate bus would have freed up a huge number of CPU cycles but would have significantly increased the system cost and the CPU cost to create the display lists across the split bus. Given the display list architecture, I don't think there's many questionable design decisions beyond using the TIA for sound. (And that was an Atari cost decision.)

 

On a related note, I find it interesting that Nintendo (which did go with separate CPU & GPU buses and a fixed-function architecture versus the flexible display list) didn't map the CPU to GPU ports to zero page memory.

 

One of my biggest complaints is that the 7800 was designed for 160-wide graphics (same resolution as the 2600) and its ability to handle 320-wide graphics seems to have been an afterthought.

I agree. I think 320 modes happened after GCC went with the 7.16MHz MARIA clock, which probably made it relatively easy to support 320 output. But then they didn't have the transistor budget to double the line RAM, so they had to figure out ways to translate 5 bits into 10 bits of color lookups.

Yes/no. I think the biggest problem is the CPU load caused by the display list and shared memory architectures. Putting MARIA on a separate bus would have freed up a huge number of CPU cycles but would have significantly increased the system cost and the CPU cost to create the display lists across the split bus. Given the display list architecture, I don't think there's many questionable design decisions beyond using the TIA for sound. (And that was an Atari cost decision.)

 

I can see quite a few. To start with some things improvements that could have been improved very cheaply:

• Not using the upper bits of each byte for transparency determination in write mode 2
  
• Making Kangaroo mode a 'global' property rather than allowing it to be set for individual display items
  
• Putting the control byte of each display list item second instead of first, which requires an extra byte of padding for display lists, wastes two cycles per display list, and may have contributed to the extra 2 cycle delay when fetching an extended record.
  
• Delay the start of MARIA writes by one 320-mode pixel.
  

Some other things I would have liked to have seen:

• Give the Maria 64 byte of address space at $20-$3F and $120-$13F. This would allow for a full set of palette registers (32 colors rather than 16) and allow a few more options.
  
• Trigger an extended display list item when the 'size' is over 24 pixels, rather than just when it's 32. This would free up three bits in the control byte. For an end-of-list record, they could set the read mode. For any other record, they could set the Kangaroo mode and "holey DMA" options.
  
• Add a 16-color "320-dot" read mode where one bit of each pixel controls whether a color should apply to both pixels, or only to the one on the right (in which case, the pixel to the left would get its color from the pixel to its immediate left). This would allow for jaggy-elimination on graphics where every colored area is at least two pixels wide, while retaining a nice color palette.
  
• Allow the most significant color bit of each pixel to select the read mode used on the other bits.
  
• Architecture permitting, if the source address MSB is 0, "fetch" blank data at a rate of 1 cycle/byte (I don't know if the Maria needs the three cycles to plot things internally)
  
• Architecture permitting, have an option to use a fast memory cycle for the character data fetch in the character modes (use normal cycles for the shape data). This would require character data to be in RAM but reduce memory bandwidth.
  
• Allow 32-line display list zones.
  
• Allow options for 228 or 227.5 cycles/line and for 262, 263, or 262.5/525 line displays.
  

On a related note, I find it interesting that Nintendo (which did go with separate CPU & GPU buses and a fixed-function architecture versus the flexible display list) didn't map the CPU to GPU ports to zero page memory.

 

I don't know how much benefit there is generally to having MARIA mapped in zero-page. For a game with a very specialized kernel it can be handy, but given that writing to the color registers will cause any pixel currently being output to be "stretched" I don't see much use for real-time register bashing outside of specialized games like Toyshop Trouble.

 

One of my biggest complaints is that the 7800 was designed for 160-wide graphics (same resolution as the 2600) and its ability to handle 320-wide graphics seems to have been an afterthought.

I agree. I think 320 modes happened after GCC went with the 7.16MHz MARIA clock, which probably made it relatively easy to support 320 output. But then they didn't have the transistor budget to double the line RAM, so they had to figure out ways to translate 5 bits into 10 bits of color lookups.

 

I wouldn't mind having only 5 bits per double pixel if it were easier to set them usefully. The transparency handling is a major oops in that regard (though actually it could be nuisancesome even in 160-dot mode).

On a related note, I find it interesting that Nintendo (which did go with separate CPU & GPU buses and a fixed-function architecture versus the flexible display list) didn't map the CPU to GPU ports to zero page memory.

I don't know how much benefit there is generally to having MARIA mapped in zero-page. For a game with a very specialized kernel it can be handy, but given that writing to the color registers will cause any pixel currently being output to be "stretched" I don't see much use for real-time register bashing outside of specialized games like Toyshop Trouble.

Exactly. Unlike the 2600 where the TIA gets hammered during the kernel, the MARIA registers are rarely updated. But for the NES the VPU access registers are not mapped to zero-page even though they get used almost as much as the TIA registers.

 

You're probably right that the display list entry coding could have been done better. Again, it seems like things like indirect & write mode were added on after the original design was completed.

 

I haven't spent lots of time in the 320 modes, so I can't comment on a those design suggestions. But, my guess is 160A was the original design point, with 320A added next and 320B added after. The other modes are just "free" side-effects of those three.

On a related note, I find it interesting that Nintendo (which did go with separate CPU & GPU buses and a fixed-function architecture versus the flexible display list) didn't map the CPU to GPU ports to zero page memory.

Exactly. Unlike the 2600 where the TIA gets hammered during the kernel, the MARIA registers are rarely updated. But for the NES the VPU access registers are not mapped to zero-page even though they get used almost as much as the TIA registers.

 

Actually, it's pretty common to have some Maria accesses during the kernel to change modes mid-screen, etc. But nothing near the bashing the TIA gets. Though I doubt any machine's I/O chips get anything near the bashing the TIA gets.

 

You're probably right that the display list entry coding could have been done better. Again, it seems like things like indirect & write mode were added on after the original design was completed.

 

No, I think those were in there early on, since they're so obviously necessary. More likely the Kangaroo mode was an afterthought.

 

I haven't spent lots of time in the 320 modes, so I can't comment on a those design suggestions. But, my guess is 160A was the original design point, with 320A added next and 320B added after. The other modes are just "free" side-effects of those three.

 

There are two ways data can be put into the line buffer ("write mode"), and three ways the line buffer can be displayed ("read modes"). The write modes pay no regard to how data will be read out, and the read modes pay no attention to how it got in.