320C/320D may actually have uses?

[Flipper]

Running the calculation on doing background tiles recently, and reading what others have to say, you're pretty much not going to do background tiles in

320B. You technically can, of course, but you'll have nothing else on the screen. Not exactly a 'background' when there is no 'foreground'. However, there are ways to make a useful background tile mode.

 

320A:

It works. Set for 2 byte tiles, 16 lines high in your DLL. This gives you 21 (with smooth scrolling) 16 pixel by 16 pixel tiles. The math:

12 (for DL) + 21 * (9 (for gfx data) + 3 (for charmap lookup)) = 264 out of 405 cycles. Plenty to do your own sprites on top.

Problem is...monochrome. The whole line must be the same color. You might be able to live with that, tho.

 

320C:

Unsuitable for same reasons as 320B. Already uses two bytes per 8 pixel tile, requires blitting 40 tiles/line.

 

320D:

Sitting out there is a icky, nasty, horrible 'certain colors in certain columns' mode. That uses one byte per 8 pixel tile. That can be set for 2 byte mode just as the 320A trick. Same performance, 264 out of 405 cycles. And, I was looking at it last night, and I realized that it is not that fundamentally different from the Apple II's graphics, and everyone learned how to deal with that. Odd columns handled one color set, and even columns had another color set. Thus, it should be possible to at least get a background going, and fill in any issues with sprites on top. Unfortunately, I am not nearly enough of an artist to know how to make a tileset that would use 320D mode effectively.

[supercat]

320D:

Sitting out there is a icky, nasty, horrible 'certain colors in certain columns' mode. That uses one byte per 8 pixel tile. That can be set for 2 byte mode just as the 320A trick. Same performance, 264 out of 405 cycles. And, I was looking at it last night, and I realized that it is not that fundamentally different from the Apple II's graphics, and everyone learned how to deal with that. Odd columns handled one color set, and even columns had another color set. Thus, it should be possible to at least get a background going, and fill in any issues with sprites on top. Unfortunately, I am not nearly enough of an artist to know how to make a tileset that would use 320D mode effectively.

 

I just reread the description and finally figured out what it means. Really not very clear at all. Basically, it would seem to be pretty much like artifact color, except with a little more control over the exact color hues than one would get with artifacting alone. I would expect that artifacting would tend to dominate the colors produced (e.g. if having even pixels black and odd pixels white would generate a particular hue, having even pixels be a dark color and odd pixels a light color will generate a similar hue; using different colors can change the hue somewhat, but only in very limited fashion.

 

What I'd like to see more would be a practical way to alterate color sets on alternating scan lines. Unfortunately, I don't know any way to do that without typing up the CPU during the display scan. Is there one?

[Flipper]

320D:

Sitting out there is a icky, nasty, horrible 'certain colors in certain columns' mode. That uses one byte per 8 pixel tile. That can be set for 2 byte mode just as the 320A trick. Same performance, 264 out of 405 cycles. And, I was looking at it last night, and I realized that it is not that fundamentally different from the Apple II's graphics, and everyone learned how to deal with that. Odd columns handled one color set, and even columns had another color set. Thus, it should be possible to at least get a background going, and fill in any issues with sprites on top. Unfortunately, I am not nearly enough of an artist to know how to make a tileset that would use 320D mode effectively.

 

I just reread the description and finally figured out what it means. Really not very clear at all. Basically, it would seem to be pretty much like artifact color, except with a little more control over the exact color hues than one would get with artifacting alone. I would expect that artifacting would tend to dominate the colors produced (e.g. if having even pixels black and odd pixels white would generate a particular hue, having even pixels be a dark color and odd pixels a light color will generate a similar hue; using different colors can change the hue somewhat, but only in very limited fashion.

 

What I'd like to see more would be a practical way to alterate color sets on alternating scan lines. Unfortunately, I don't know any way to do that without typing up the CPU during the display scan. Is there one?

 

Mmm, I don't know that I would say artifacting would dominate...it is like almost any console/computer's 320 mode on a standard TV. You are changing colors faster than color clock, and if you ask the decoder in the TV for too much, you will get an artifact. On the other hand, if your colors are close, it works OK most of the time. On the commie there was a nice little grid of which colors could be next to which colors with minimal/slight/severe artifacting. Most of them were classed as minimal.

 

And as to changing colors?

 

On the high color sections of the screen, do one DLL entry per line. You have a limit of 256 or 512 bytes in the DLL, so you can't do a whole screen this way. But this way you just pick which pallettes you use.

 

If you need a whole screenful of line by line color changes...hmm....dunno.

[supercat]

Mmm, I don't know that I would say artifacting would dominate...it is like almost any console/computer's 320 mode on a standard TV. You are changing colors faster than color clock, and if you ask the decoder in the TV for too much, you will get an artifact. On the other hand, if your colors are close, it works OK most of the time. On the commie there was a nice little grid of which colors could be next to which colors with minimal/slight/severe artifacting. Most of them were classed as minimal.

 

If you display two or more pixels of each color next to each other, artifacting won't usually be too bad. But the only way that 320D would allow the display of "extra" colors would be to create patterns of alternating-color pixels. On an NTSC Commodore 64, such a pattern would generate a 4.09Mhz signal (close enough to chroma to produce some artifacting, but not too severe); on the 7800, the pattern would generate a 3.579545Mhz signal.

 

On the high color sections of the screen, do one DLL entry per line. You have a limit of 256 or 512 bytes in the DLL, so you can't do a whole screen this way. But this way you just pick which pallettes you use.

 

If you need a whole screenful of line by line color changes...hmm....dunno.

 

Doing the full screen would be the idea. Is there any way for the processor to force the MARIA chip to start reading the DLL from a new address mid-screen?

[Flipper]

Doing the full screen would be the idea. Is there any way for the processor to force the MARIA chip to start reading the DLL from a new address mid-screen?

 

Well, I would have picked colors that were basically NTSC compatible. Apple used RED/BLUE or GREEN/PURPLE. Those always came through true enough. On the commie, I always liked blue/yellow as a nice pairing.

 

As to forcing it to start a new DLL...hmm. Since the DLL includes VBI, then forcing it to start over again wouldn't do what you want. Which brings to mind...would not the 2600 and 7800 be possibly the only game consoles able to close caption their games? Tho, it would be pointless, I think. What would you print? "Strange explosions..."

 

WSYNC exists in MARIA space. You could just do WSYNC/colors/logic/WSYNC/colors/logic. While that is icky compared to writing a more traditional program, 2600 programmers are often stuck with that, or keeping all game logic in the VBI.

Edited March 29, 2006 by Flipper

[vdub_bobby]

WSYNC exists in MARIA space. You could just do WSYNC/colors/logic/WSYNC/colors/logic. While that is icky compared to writing a more traditional program, 2600 programmers are often stuck with that, or keeping all game logic in the VBI.

I don't think there are any 2600 games that try to display something meaningful and do game logic during the kernel at the same time. Every 2600 game restricts game logic to offscreen time.

[Bruce Tomlin]

Running the calculation on doing background tiles recently, and reading what others have to say, you're pretty much not going to do background tiles in

320B. You technically can, of course, but you'll have nothing else on the screen. Not exactly a 'background' when there is no 'foreground'. However, there are ways to make a useful background tile mode.

That's what I used for Tubes, and there were just enough Maria cycles left to do a pair of 16 pixel sprites, plus a bit more for score and stuff.

 

The real problem is that you have almost no CPU time left. That includes vertical blank handlers, which will only get a few cycles per HSYNC.

 

The Maria is literally The Thing That Ate The CPU when you try to do a nice looking background in a 320 mode.

[Flipper]

Running the calculation on doing background tiles recently, and reading what others have to say, you're pretty much not going to do background tiles in

320B. You technically can, of course, but you'll have nothing else on the screen. Not exactly a 'background' when there is no 'foreground'. However, there are ways to make a useful background tile mode.

That's what I used for Tubes, and there were just enough Maria cycles left to do a pair of 16 pixel sprites, plus a bit more for score and stuff.

 

The real problem is that you have almost no CPU time left. That includes vertical blank handlers, which will only get a few cycles per HSYNC.

 

The Maria is literally The Thing That Ate The CPU when you try to do a nice looking background in a 320 mode.

 

Yeah, that was my great disappointment as I started looking into the 7800. Is there a reason why they didn't sit on the phase 1 clock like commie's VIC chip? My guess would be, though I don't find anything truly confirming or denying this, that it loads DL and DLL entries at faster than CPU clock. That would explain why they NEED to sit in RAM. On the other hand, ROM seems to be accessed at the 1.79MHz, so why didn't they just sit on the silent side of the clock? I don't THINK it's ROM speed, as the Ultimax used the VIC chip to grab chars from ROM, and did on the sly.

[Bruce Tomlin]

That's what I used for Tubes, and there were just enough Maria cycles left to do a pair of 16 pixel sprites, plus a bit more for score and stuff.

Oops, I just realized that I didn't do a whole screen tile-based background. The amount of space taken up by the sprites and status isn't much more than the space where I don't have a background.

 

So the summary is:

 

* 160-pixel mode is low enough resolution to look unattractive compared to any other post-crash console (and the pre-crash ColecoVision), but at least it has a decent color palette

 

* 320-pixel mode doesn't have many colors, takes up almost all of the Maria's time on a scan line if you want to use it for a background, and that causes the Maria to take up much of the CPU's time on a scan line.

[Schmutzpuppe]

Surly the 320 Mode’s have their quirks and disadvantages but nevertheless it’s possible to use them for games.

Tubes and Frogger prove that.

For fullscreen background and some more moving objects a 160 mode normally is the better choice and imho doesn’t look that bad.

There are a huge number of c64 games which looks very good on this resolution.

I also don’t like the fact that MARIA eats up so many CPU cycles but that’s the way it is.

I think if someone would bother to write a game taking the 7800 advantages the result would be quite cool.

[jaybird3rd]

Surly the 320 Mode’s have their quirks and disadvantages but nevertheless it’s possible to use them for games.

Tubes and Frogger prove that.

I believe that One-on-One Basketball also uses one of the 320 modes.

[vdub_bobby]

I believe that One-on-One Basketball also uses one of the 320 modes.

Doesn't look like it to me:

 

EDIT: I take that back. The court is at 320-pixel resolution, Dr. J and Bird are at 160-pixel resolution.

Edited March 30, 2006 by vdub_bobby

[Schmutzpuppe]

EDIT: I take that back. The court is at 320-pixel resolution, Dr. J and Bird are at 160-pixel resolution.

You are right, background looks like 320 but players don't.

Normaly it is not possible to mix 320 and 160 mode within a scanline because the read mode is set in the CTRL!?

[supercat]

EDIT: I take that back. The court is at 320-pixel resolution, Dr. J and Bird are at 160-pixel resolution.

 

The 320 modes have another quirk not yet mentioned: each pair of 320-mode pixels must either have both pixels transparent or neither. It should have been possible to make the "interiors" of the player shapes be 320 mode, but haking the exteriors also be 320 mode would have required a lot of work. Basically, it would require using the processor to create a small bitmap holding the part of the background where the player should be displayed, and then BLITTing the outline of the player into that. For some games ignoring the pixel pairing wouldn't be a problem (note that the Defender arcade hardware has essentially the same restriction) but for One on One basketball, ignoring the issue would likely make things look bad.

[Bruce Tomlin]

Or you could just give up transparency and turn on Kangaroo Mode, like I did with Tubes.

[supercat]

Or you could just give up transparency and turn on Kangaroo Mode, like I did with Tubes.

 

For One on One Basketball that would be really incredibly ugly.

 

Too bad GCC made the various mode thingies writable addresses. What I would have rather seen would have been to have them controlled by "pixels" off around position 200 or so. To switch modes in the middle of processing a line, just include an item in a display list that writes to those pixels.

[Shaggy the Atarian]

I believe that One-on-One Basketball also uses one of the 320 modes.

Doesn't look like it to me:

 

EDIT: I take that back. The court is at 320-pixel resolution, Dr. J and Bird are at 160-pixel resolution.

 

Strange, I decided to try that game out today and the players don't look like that. On the real thing they don't look wide at all so I assume the exaggerated wideness of the players is due to the emulator.

 

http://atari7800.org/screenshots/One_on_Onescreen.htm

 

But I'm no expert on this technical stuff so I'll just end my input there.

[Heaven/TQA]

interesting that the screenshots look different than the emu output...

[vdub_bobby]

That screenshot is from MESS; probably they use square 320-resolution pixels, making pixels at 160-pixel-width pixels twice as wide as they are tall, when really they should be about 1.5 times as wide as they are tall, I believe. Or...?

[Bruce Tomlin]

That screenshot is from MESS; probably they use square 320-resolution pixels, making pixels at 160-pixel-width pixels twice as wide as they are tall, when really they should be about 1.5 times as wide as they are tall, I believe. Or...?

I would say probably it's a MESS bug. It wouldn't be the first bug MESS had with 320 pixel modes. Notice that the scoreboard text is widened too.

[supercat]

Normaly it is not possible to mix 320 and 160 mode within a scanline because the read mode is set in the CTRL!?

 

The 320C mode can be used to combine a two-color 320-dot background with four-color-plus-transparent shapes using two color sets. The foreground shapes will require double DMA bandwidth; because of some annoying quirks in transparency logic, it's possible to make half of a double-pixel be the background color and have the whole double-pixel be opaque, but making the whole double-pixel the background color will make it transparent.

 

The 320B mode is reasonably nice when using Kangaroo mode, but works very poorly in non-Kangaroo mode.

[vdub_bobby]

320A:

It works. Set for 2 byte tiles, 16 lines high in your DLL. This gives you 21 (with smooth scrolling) 16 pixel by 16 pixel tiles. The math:

12 (for DL) + 21 * (9 (for gfx data) + 3 (for charmap lookup)) = 264 out of 405 cycles. Plenty to do your own sprites on top.

Problem is...monochrome. The whole line must be the same color. You might be able to live with that, tho.

Is that math correct? Isn't it 12 cycles for the header and 9 cycles per tile? The doc is confusing, but based on what other people have written, I understood it to be:

Every DMA byte, sprite or tile, takes 3 cycles. Every charmap lookup takes 3 cycles. So two-byte tiles take 6 cycles for the two bytes + 3 bytes for the charmap lookup = 9 cycles per tile.

 

Is that wrong?

Edited March 13, 2008 by vdub_bobby

[Synthpopalooza]

An old thread ... but I have been brewing a technique for utilizing this mode.

 

It involves the color flipping technique used in my Sky Scraper demo, but differently.

 

You double buffer the character set, but as you swap sets, you also swap the two color registers so that they trade the same color values.

 

This will in theory get you 4 colors (3 plus bg) per character at 320 resolution across 8 palettes but with 320A DMA. The interlacing effect occurs across 160 pixel vertical lines so hopefully will not look too horrible. When I get time I will work up a demo.

[PacManPlus]

Looking forward to seeing this. I've yet to see any advantages of using 320C or 320D

[Synthpopalooza]

So ... does anyone have specs on 320D regarding palette layout, which colors are in which columns, etc.? It will help me know what I have to work with.