Jump to content
IGNORED

cc7800, a C compiler dedicated to the Atari 7800


bsteux

Recommended Posts

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:

image.thumb.png.3814e53951f68abfda875aad8c0f9306.png

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:

 

  • Like 5
Link to comment
Share on other sites

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

 

  • Like 1
Link to comment
Share on other sites

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 :D

Link to comment
Share on other sites

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:

image.thumb.png.3814e53951f68abfda875aad8c0f9306.png

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!

Link to comment
Share on other sites

  • 2 weeks later...

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

  • Like 10
Link to comment
Share on other sites

  • 3 weeks later...
  • 4 weeks later...

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

  • Like 1
Link to comment
Share on other sites

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':

image.thumb.png.b495d60f57e15e503b4fba239c926d53.png

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

  • Like 3
Link to comment
Share on other sites

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':

image.thumb.png.b495d60f57e15e503b4fba239c926d53.png

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.

  • Like 3
Link to comment
Share on other sites

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.

 

1953224847_KidIcarus7800160BvsNES_XL_.PNG.2b68dd4ed262b13c6e2bf6bea4f84e4c.thumb.png.9ce006d8877feabf58a6d1dd2e7c8ca6.png

 

 

  • Like 2
Link to comment
Share on other sites

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 😮

 

test.gif.f14c986f503ca0b02489e3c2397297fc.gif

 

 

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

 

post-29074-0-83320500-1538367210..png.f7d3a40d0958b3be4321431dfb7030d9.png.e23662bcaabeb6b323f7f4606ec6925b.png

  • Like 6
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...