Jump to content
Sign in to follow this  
Flipper

320C/320D may actually have uses?

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 by Flipper

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
I believe that One-on-One Basketball also uses one of the 320 modes.

Doesn't look like it to me:

post-6060-1143755211_thumb.pngpost-6060-1143755225_thumb.png

 

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

Edited by vdub_bobby
  • Like 1

Share this post


Link to post
Share on other sites

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!?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
I believe that One-on-One Basketball also uses one of the 320 modes.

Doesn't look like it to me:

post-6060-1143755211_thumb.pngpost-6060-1143755225_thumb.png

 

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. :)

Share this post


Link to post
Share on other sites

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...?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 by vdub_bobby

Share this post


Link to post
Share on other sites

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.

  • Like 3

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...