cc7800, a C compiler dedicated to the Atari 7800

[KrunchyTC]

Is 160x224 an optimal resolution for most 7800 games? or do lots of games need more processing time during vblank?

Edited May 9 by KrunchyTC

[+karri]

224 lines is a compronize between NTSC and PAL. Both machines can show the playfield without large margins.

[Trebor]

To add a bit to the NTSC perspective...  Under a traditional NTSC CRT display, the display resolution is typically denoted as 240p.  There is, on average, 8 scanlines 'cropped' from the top and bottom portions of the screen.  240 - 16 = 224. 

 

Consequently, many NTSC 8-bit and 16-bit consoles advertised the 224p as part of the main or available number of lines of resolution, even when the system actually outputs 240p or some other value.

 

A great test thread was created on this topic a while back:

 

http://atariage.com/forums/topic/261266-testing-crt-screen-size/#entry3676087

 

It also confirm the majority average of ~224 visible lines for NTSC:

From a retail title perspective, the two titles that utilize exactly 224 lines to completely show the intended display (if centered properly) are from Froggo - Tank Command and Water Ski.

16 hours ago, KrunchyTC said:

Is 160x224 an optimal resolution for most 7800 games? or do lots of games need more processing time during vblank?

As karri mentioned, indeed, NTSC and PAL can show the playfield without large margins.

 

From @RevEng post:

 

The actual output resolution of the 7800 MARIA graphics chip for NTSC is 243 lines and PAL is 293 lines.  

Depending on code efficiency and how much 'action' is on the screen will better determine if 224 lines is optimal for any game.

 

Also, just because any giving title utilized a certain number of scanlines, does not mean the system could not handle more.  The difference between retail Ms. Pac-Man and Donkey Kong, and Ms. Pac-Man under Pac-Man Collection Remastered Edition, as well as Donkey Kong PK, demonstrate this very nicely.

 

Any critical/statistical information needs to avoid the outskirts of the display though, as clearly there is a significant number of NTSC CRT displays that show considerably less than 224 lines.  RevEng's Screen Safe is excellent for this demonstration:

 

[+bsteux]

I'll just add to what has already been said before that computation on the Atari 7800 doesn't rely as extensively on Vblank timing as on that Atari 2600. You can make some computations when Maria is displaying the screen, and with double buffering you can even prepare the next screen drawings in a "modern" way. And as you (your code running on the CPU) are not responsible for drawing the screen, you can even extend computations on several consecutive screens. Not all games need to handle 60 fps...

 

[KrunchyTC]

5 hours ago, bsteux said:

I'll just add to what has already been said before that computation on the Atari 7800 doesn't rely as extensively on Vblank timing as on that Atari 2600. You can make some computations when Maria is displaying the screen, and with double buffering you can even prepare the next screen drawings in a "modern" way. And as you (your code running on the CPU) are not responsible for drawing the screen, you can even extend computations on several consecutive screens. Not all games need to handle 60 fps...

 

I see, thanks for informing me on that

[KrunchyTC]

7 hours ago, Trebor said:

To add a bit to the NTSC perspective...  Under a traditional NTSC CRT display, the display resolution is typically denoted as 240p.  There is, on average, 8 scanlines 'cropped' from the top and bottom portions of the screen.  240 - 16 = 224. 

 

Consequently, many NTSC 8-bit and 16-bit consoles advertised the 224p as part of the main or available number of lines of resolution, even when the system actually outputs 240p or some other value.

 

A great test thread was created on this topic a while back:

 

http://atariage.com/forums/topic/261266-testing-crt-screen-size/#entry3676087

 

It also confirm the majority average of ~224 visible lines for NTSC:

From a retail title perspective, the two titles that utilize exactly 224 lines to completely show the intended display (if centered properly) are from Froggo - Tank Command and Water Ski.

As karri mentioned, indeed, NTSC and PAL can show the playfield without large margins.

 

From @RevEng post:

 

The actual output resolution of the 7800 MARIA graphics chip for NTSC is 243 lines and PAL is 293 lines.  

Depending on code efficiency and how much 'action' is on the screen will better determine if 224 lines is optimal for any game.

 

Also, just because any giving title utilized a certain number of scanlines, does not mean the system could not handle more.  The difference between retail Ms. Pac-Man and Donkey Kong, and Ms. Pac-Man under Pac-Man Collection Remastered Edition, as well as Donkey Kong PK, demonstrate this very nicely.

 

Any critical/statistical information needs to avoid the outskirts of the display though, as clearly there is a significant number of NTSC CRT displays that show considerably less than 224 lines.  RevEng's Screen Safe is excellent for this demonstration:

 

holy...!

 

that 192 vertical, thats why master system games are so friggin squashed looking with the huge bars on the top and bottom!

[+bsteux]

Hi,

Here is cc7800 v0.2.25. It fixes a big bug with embedded assembler usage. It also introduces the "noholeydma" keyword, that allows the gfx to be put anywhere in memory when holey DMA is disabled (cc7800 otherwise assumes holey DMA is enabled and tries to put gfx data at the right place depending on "holeydma" keyword (when "holeydma" is set, cc7800 assumes is contains sprites, when "holeydma" is not set, cc7800 assumes gfx contains tiles - i.e. sprites that must be aligned on 8 or 16 pixels boundaries).

Have a nice coding !

cc7800-0.2.25-x86_64.msi

[KrunchyTC]

Would Blaster Master be a difficult game to pull off on the 7800? It's quite scrolling intensive.

[+saxmeister]

@KrunchyTC after seeing the demos that some of the great coders here have created as well as released games such as Bentley Bear's Crystal Quest, E.X.O., A.R.T.I., Harpy's Curse, and many more, I really think the 7800 could handle Blaster Master. The big difference would be the chunkiness of the multicolor graphics compared to the NES, but the 7800 can handle the large bosses easier than the NES could.

[Trebor]

4 hours ago, saxmeister said:

@KrunchyTC after seeing the demos that some of the great coders here have created as well as released games such as Bentley Bear's Crystal Quest, E.X.O., A.R.T.I., Harpy's Curse, and many more, I really think the 7800 could handle Blaster Master. The big difference would be the chunkiness of the multicolor graphics compared to the NES, but the 7800 can handle the large bosses easier than the NES could.

The 'Chunkiness' of the 160 modes can be minimized when a pixel/graphics artist understands how to work with the aspect ratio. 

 

Here is an example from @Defender_2600 for a Link sprite.  The top row is an unmodified original, the bottom slender things down.  Very little graphic detail is lost, but the sprite looses much of the 'chunkiness':

Overall, the idea is to design more slender looking sprites while maintaining as much detail as possible, understanding they will be stretched accordingly.  It is art and science combined. 

[CPUWIZ]

26 minutes ago, Trebor said:

The 'Chunkiness' of the 160 modes can be minimized when a pixel/graphics artist understands how to work with the aspect ratio. 

 

Here is an example from @Defender_2600 for a Link sprite.  The top row is an unmodified original, the bottom slender things down.  Very little graphic detail is lost, but the sprite looses much of the 'chunkiness':

Overall, the idea is to design more slender looking sprites while maintaining as much detail as possible, understanding they will be stretched accordingly.  It is art and science combined. 

 

Yep, you can actually go with the rule of 2:1, that's exactly what I did with the MCP logo.  I made it in full resolution, cut the width in half and touched up some pixels.

 

@Trebor I sent you some new pics.

[TIX]

I really love chunky sprites !

without my reading glasses I can hardly tell the difference 😮

 

 

[KrunchyTC]

1 hour ago, TIX said:

I really love chunky sprites !

without my reading glasses I can hardly tell the difference 😮

 

 

That's pretty cool, and chunky! 😂

[+saxmeister]

Believe me, the description "chunkiness" wasn't meant to be bad or something that can't be dealt with. It's just different. I love the chunky look!

[Defender_2600]

On 7/2/2024 at 1:53 PM, CPUWIZ said:

 

Yep, you can actually go with the rule of 2:1, that's exactly what I did with the MCP logo.  I made it in full resolution, cut the width in half and touched up some pixels.

 

@Trebor I sent you some new pics.

 

I love your MCP logo. This rule works with large images, like a title screen, but when converting sprites/tiles that have a 16 pixels wide box, the ideal would be to have a reduction to 12 pixels, when conditions allow it. For tiles you can go up to 10 pixels with the 160B mode, in order to get a perfect conversion of the NES tile map. But with a box that is only 8 pixels wide, you will get the worst possible result, as for example we saw with the 7800 Galaga sprites in 160A.

 

 

 

[Defender_2600]

On 7/2/2024 at 6:35 PM, TIX said:

I really love chunky sprites !

without my reading glasses I can hardly tell the difference 😮

 

 

 

This is the 7800, so you can double the number of colors in your sprite and you will definitely see the difference.

 

[KrunchyTC]

Another question to y'all who have made games for both the 7800, and NES. Does the 7800's design make it harder to make games, or is it on the same level? I would think the NES would be harder considering it's actually got more restrictions.

[+splendidnut]

Making games on either system is very similar; they use the same CPU, the 6502.  Audio and video capabilities are where the two differ.  In regards to video, the 7800s design gives a lot of flexibility in doing screen layouts, but that requires writing more code to setup and handle the display.  The NES is designed to be fairly rigid in that area, but that makes display setup and handling quite a bit easier.  But that's all from a code perspective, the actual graphics capabilities are quite similar.  With audio, the base NES system is more capable than the 7800... but the 7800 audio can easily be expanded with chips in the cartridge.

 

You can pretty much make a game on one of those systems, and port it to the other and get similar results.

[Bakasama]

I'm of the opinion that a lot of 5200/8-bit games can be ported to the 7800 except with more colors or extra features. Like a Megamania port with moving starfield or Gradius/Nemesis port that less slowdown than the NES port.

[Defender_2600]

@bsteux, 

 

someone has inserted a "V61" logo graphic, and is showing it publicly (see end of video). Just to let you know.

 

Spoiler

 

 

Edited September 6 by Defender_2600

[+bsteux]

10 hours ago, Defender_2600 said:

@bsteux, 

 

someone has inserted a "V61" logo graphic, and is showing it publicly (see end of video). Just to let you know.

 

  Reveal hidden contents

 

 

Thank you for the information. It's not a problem on my side. After all at this stage, it's a good advertisement for the Atari 7800 capabilities. And it's nice to see that someone got hold of the source code and could modify it to its needs... Maybe will he be motivated to go further...

[Defender_2600]

1 hour ago, bsteux said:

Thank you for the information. It's not a problem on my side. After all at this stage, it's a good advertisement for the Atari 7800 capabilities. And it's nice to see that someone got hold of the source code and could modify it to its needs... Maybe will he be motivated to go further...

 

This is very kind of you. Personally, I agree when the development is clearly declared "non-profit". But in this specific case a "Brand identity" was applied on code and graphics without our knowledge. This behavior, in addition to being incorrect, is also risky since it is a known IP. I made this public only to clearly state that we are not involved in any profit-making activities, especially after the rumors of the last few days about this R-Type demo. I can also take risks with my graphics but I should not involve other unaware people. Anyway, episode closed, and let's get back to the fun.

 

[l12n]

@bsteux I finally got to play with cc7800 and try to modify some examples.

 

Is there an API doc somewhere? I couldn't find any. The examples are very useful but don't always explain everything, e.g. some tiles have a comment "Generated by sprites7800 based on tiles.yaml" yet tiles.yaml is nowhere to be found. Likewise, trying to modify the parameters of some API such as tiling_init() gives surprising results.

[+karri]

4 hours ago, l12n said:

@bsteux I finally got to play with cc7800 and try to modify some examples.

 

Is there an API doc somewhere? I couldn't find any. The examples are very useful but don't always explain everything, e.g. some tiles have a comment "Generated by sprites7800 based on tiles.yaml" yet tiles.yaml is nowhere to be found. Likewise, trying to modify the parameters of some API such as tiling_init() gives surprising results.

There is another repository called 7800tools. It contains sprites7800 subdirectory.

 

A command like:

sprites7800 something.yaml

will parse the yaml description of the graphics and output the data.

 

The missing data you are looking for is in

7800tools/sprites7800/resources

 

 

[+bsteux]

5 hours ago, l12n said:

@bsteux I finally got to play with cc7800 and try to modify some examples.

 

Is there an API doc somewhere? I couldn't find any. The examples are very useful but don't always explain everything, e.g. some tiles have a comment "Generated by sprites7800 based on tiles.yaml" yet tiles.yaml is nowhere to be found. Likewise, trying to modify the parameters of some API such as tiling_init() gives surprising results.

No, unfortunately the doc is still missing. I'm currently refactoring the examples. In the process, I'll try to add some docs and explanation. In the meantime, don't hesitate to ask for help.