Jump to content

Recommended Posts

18 hours ago, bizarrostormy said:

To be clear, the 7800’s display resolution is either 160x192 or 320x192.

The 192 figure is more of a safe area recommendation rather than a technical limit.   It is a throw back to 2600 programming under much older displays in which the cut off area was much greater, and visible area much smaller, than newer CRTs of the time during the 7800's heyday.

 

For the NTSC 7800, entire raw output is either 160x240 or 320x240.  How many of those 240 lines can been seen on a (CRT) display or actually put into use, even more so, practical use, is a different matter.   Dependent on the needs and programming code, enough 'MARIA' cycles have to be available for it.

 

Like its contemporary consoles (And even those of the 16-bit generation), 224 is typically the average number of scanlines that are visible under a NTSC CRT.  In harmony with that, there is a great thread on CRT testing via the 2600 console in which the majority of displays in the test averaged 224.2 vertical lines.

 

There are real world examples of well beyond 192 vertical lines being utilized under the 7800.  A couple of examples are the original retail games from Froggo.  Both Water Ski and Tank Command are 160x224.

 

Regarding homebrew titles,  Donkey Kong PK/XM is 160x216.  Froggie offers players the choose of a 'compatible' video mode that plays at 320x216 and a 'full' mode which displays at 320x224.

  • Like 5

Share this post


Link to post
Share on other sites

Thanks! I knew there were more than 192 non-VBLANK lines but didn’t know — and had wondered — what real CRTs would show. I may use that after I declare extra RAM. I like the idea of allowing players to choose. In my case it may even be feasible to let them choose an exact number (within some range) of lines.

 

For christo930, I don’t think this stuff fundamentally affects the answers to your questions about cartridge RAM.

  • Like 4

Share this post


Link to post
Share on other sites

Thanks everybody for the encouragement (and patience). I found more flaws in my fill algorithms but hopefully have addressed them now. I’m hopefully ready to begin that phase of coding.

  • Like 5

Share this post


Link to post
Share on other sites

Development update: I had hoped to finish fill this past weekend. I had it working except in the last, most complicated case, which doesn’t do much unique but combines steps from a bunch of other situations. As I was doing that I realized that something I thought was clever is actually not. So, I am now in the process of undoing my not-so-cleverness, then I’ll fix that last case. The new code will do most of the same fundamental things, just in a different order and with different parameters.

 

I am pleased with the fill performance. The current code has some major inefficiencies but is already in the ballpark of the 5200 version, and much faster than the 400/800 version. I’ll eventually make it faster but this is fast enough for an alpha release.

 

I am still avoiding any schedule promises but getting closer to having something to share.

Screen Shot 2020-06-01 at 6.57.59 PM.png

  • Like 15

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

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...