Jump to content
Sign in to follow this  
willbilly

Question about Maria and custom cartridge chips?

Recommended Posts

Hi all,

 

First post in the A7800 forum for me. I'm mostly a TI-99 guy, but the 7800 has interested me since I heard about it from this forum. I think it's a shame it never really had a chance to shine (kinda like my brother's Jaguar and my own Lynx). I've been reading a lot of this forum since then and although I don't have a 7800, I'm pretty interested in getting one and seeing what it can do, and what it could have done.

 

I'm a machinist so I have tons of time to think when I'm doing a production job in front of the lathe. And yesterday I got to thinking about 320B mode and Nintendo's MMCs. From the software guide I gather Maria stops the processor while doing two jobs, assembling the Line RAM and then displaying. Unfortunately, while I understand some of what's happening, I don't understand most and I certainly don't grok it.

 

So I came up with some questions:

 

  • Would it be possible to build an IC to mount in the cartridge that you could offload assembling the Line RAM to, and if you could, would that actually reduce the amount of time Maria has to use Sally's resources?
  • Would that make 320B viable for a full background including sprites?
  • Would it have been possible to do this in 1988-90? I'm trying to find a period correct solution. No ARM shoved into the cart. ;)
Edited by willbilly

Share this post


Link to post
Share on other sites

That's pretty much what I was looking for. The Sally-Maria interface is so quirky though that I don't know if there'd be any bottlenecks or anything like that that would make this idea a non-starter.

Share this post


Link to post
Share on other sites

MARIA has two internal 800 bit Line RAM buffers. While one buffer is being written to, the other is being read to generate the display. So there's no way for a cartridge to change the Line RAM directly.

 

Think of MARIA as a bus-master coprocessor. So at the start of the visible frame, if uses the display list list pointer to walk the display list list, getting the display list pointer for the zone and the number of lines. Each line it halts the 6502 CPU and walks the display list, reading graphics data from memory and writing it to an internal line RAM buffer. Once MARIA reaches the end of the display list, it releases the 6502 until the start of the next line. (Note: it's a little more complex, but this is the basic idea.)

 

Where a cartridge based coprocessor could really help is building the display lists. Imagine something which would allow the 6502 program to use a NES style sprite table and a simple X,Y coordinate for the background which would then automagically provide MARIA with the appropriate DLL and display list entries. That would free up a huge amount of 6502 processor time.

 

Update: I just remembered that MARIA wants the DLL and display list to be in RAM. So the game would need to copy the DLL and display lists from the cartridge to RAM every frame. This would cut into the CPU savings somewhat, but there would still be value.

 

Regarding "Would that make 320B viable for a full background including sprites?" - the main limitation is DMA time, which can't be changed by the cartridge. You can do a full background in 160B/320B/320C, but it severely restricts the number of other sprites which are available.

Edited by EricBall
  • Like 3

Share this post


Link to post
Share on other sites

As well as building display lists, it would theoretically be possibly to draw a tile map or large graphic in RAM on the cartridge, and then have a coprocessor update the graphics definition on the fly to effectively give a bitmap display. It would still be limited by the amount of data MARIA can read in time and the colours set on the palette used.

  • Like 4

Share this post


Link to post
Share on other sites

Aha...DMA time. There's the bottleneck I was expecting. So, if I understand this correctly, MARIA halts the 6502 to read the DLL, determines which display list to generate, goes out and finds all the appropriate elements, then determines what pixels will be in the raster, and finally outputs the raster.

 

Just trying to clear this up so I can theorycraft some more.

Share this post


Link to post
Share on other sites

Aha...DMA time. There's the bottleneck I was expecting. So, if I understand this correctly, MARIA halts the 6502 to read the DLL, determines which display list to generate, goes out and finds all the appropriate elements, then determines what pixels will be in the raster, and finally outputs the raster.

 

Kinda / sorta. The pixel output occurs independently of the display list activities. It's like a traditional double buffer, except on a per-line basis. I'm also not certain whether the DLL entry is fetched every line or only once per zone. But the majority of the DMA time is spent reading the display list entries from RAM and the characters and graphics from RAM or ROM.

  • Like 1

Share this post


Link to post
Share on other sites

Cartridge Tomek is using PIC24 and screen memory is inside PIC ram.

Simply you just have to make Display List for every single line pointing one address e.g. $D500

Nothing more. Use 160B mode then you do not have to worry about zones, holey dma, DL or DLL anymore.
I hope someone will adapt this cartridge for Atari 7800 one day ;)

Share this post


Link to post
Share on other sites

Late to the party. I agree with Eagle here, but also think the enhancement can go further.

 

There's no reason that color registers can't be updated line-by-line 2600 kernel style, for more unique colors than 160B (or whatever mode you choose) would normally allow. In theory it would be possible to slip in some mid-line changes, but Maria's DMA would prevent changes for part of the line.

 

You could also replace the 6502 with a cartridge based ARM CPU - just wait for the console to unlock, send the 6502 a KIL instruction, and then slip into it's shoes by monitoring the halt line.

 

I wouldn't personally code for such a beast. It takes away a lot of Maria's charm.

Share this post


Link to post
Share on other sites
On 11/16/2018 at 6:39 PM, EricBall said:

Update: I just remembered that MARIA wants the DLL and display list to be in RAM. So the game would need to copy the DLL and display lists from the cartridge to RAM every frame. This would cut into the CPU savings somewhat, but there would still be value.

I'm late too, but this issue bugs me... I've read about this requirement in few places but can't find an explanation at the moment why it needs to be in RAM and what does it exactly mean? Could someone point me to some documentation, please? Is it a matter of timing of addressing cartridge area? The documentation I've found only vaguely says that

Quote

A Display List may cross only one page boundary, so it can be no more than 512 bytes long. Additionally, Display Lists must be in RAM, due to the required access time.

 

Edited by laoo

Share this post


Link to post
Share on other sites
5 hours ago, laoo said:

I'm late too, but this issue bugs me... I've read about this requirement in few places but can't find an explanation at the moment why it needs to be in RAM and what does it exactly mean? Could someone point me to some documentation, please? Is it a matter of timing of addressing cartridge area? The documentation I've found only vaguely says that

This requirement appears to have originated purely from Maria's access timing and what memory grades were affordable. Maria reads Display List data pretty quickly for 1984 - and the internal SRAMs are both 100ns to accommodate this. The Mask ROMs on the cartridges were likely far slower.

 

Considering most SRAM and NOR Flashes you can purchase nowadays are usually 70ns or less - it's no longer a requirement. There's been more than a few releases which put Display Lists in both RAM or ROM on a cartridge.

  • Like 2

Share this post


Link to post
Share on other sites
45 minutes ago, TailChao said:

Considering most SRAM and NOR Flashes you can purchase nowadays are usually 70ns or less - it's no longer a requirement. There's been more than a few releases which put Display Lists in both RAM or ROM on a cartridge.

Thank you. This is very concrete answer 😄

Share this post


Link to post
Share on other sites
27 minutes ago, laoo said:

Thank you. This is very concrete answer 😄

No problem, and since I wasn't just late to the party - but completely missed it, let's rewind for a bit...

 

 

On 11/15/2018 at 11:37 AM, willbilly said:

Would it be possible to build an IC to mount in the cartridge that you could offload assembling the Line RAM to, and if you could, would that actually reduce the amount of time Maria has to use Sally's resources?

You can't make Maria render any faster, but you can prepare her consumables to reduce overhead and a mapper can help with this.

 

Splitting Display Lists into separate regions which can be manipulated individually (i.e. a background and foreground) is a plus, much faster than doing it all in software. The biggest assist would be a mapper which could follow Maria's parsing and either replace the lower bits of or perform a full add with each Display List's X-Position entry. This way you could more easily unroll an entire screen of Display Lists in normal (non-character) mode and nudge it horizontally with zero overhead.

 

On 11/15/2018 at 11:37 AM, willbilly said:

Would that make 320B viable for a full background including sprites?

Yes, I believe it's feasible to have 8-way scrolling in 320B and still knock out a reasonable framerate. But it's not trivial.

 

On 11/15/2018 at 11:37 AM, willbilly said:

Would it have been possible to do this in 1988-90? I'm trying to find a period correct solution. No ARM shoved into the cart. ;)

Yes.

Share this post


Link to post
Share on other sites
7 minutes ago, TailChao said:

Splitting Display Lists into separate regions which can be manipulated individually (i.e. a background and foreground) is a plus, much faster than doing it all in software. The biggest assist would be a mapper which could follow Maria's parsing and either replace the lower bits of or perform a full add with each Display List's X-Position entry. This way you could more easily unroll an entire screen of Display Lists in normal (non-character) mode and nudge it horizontally with zero overhead.

These are big topics worth discussing!

If DLL's and DL's could be in area supplied by cartridge which content could be generated online many things should be possible then.  Currently I'm trying to build mental model how Maria can be assisted and what are the restrictions. How about the restriction that a Display List may cross only one page boundary? What will happen? It will wrap and after page N+1 will start fetching data from page N?

Share this post


Link to post
Share on other sites
5 minutes ago, laoo said:

If DLL's and DL's could be in area supplied by cartridge which content could be generated online many things should be possible then.

Yes, and this is exactly the approach I've gone with for the upcoming PMC1 mapper. It's not as elegant as having a full scroll assist as described above - but you can at least unroll a new background while nudging the current one, and the DLX / DLY viewports make that very easy.

 

5 minutes ago, laoo said:

Currently I'm trying to build mental model how Maria can be assisted and what are the restrictions. How about the restriction that a Display List may cross only one page boundary? What will happen? It will wrap and after page N+1 will start fetching data from page N?

Here's the thing about that restriction, it's considerably difficult to reach. Each entry is (at least) four bytes and takes eight cycles to parse, you're going to run out of render time on the current line before you hit 512 bytes of Display Lists.

 

Both this and the similar restriction on DLLs have been on my testing list for awhile because of this. They're just so far out there in normal use.

Share this post


Link to post
Share on other sites
33 minutes ago, TailChao said:

Here's the thing about that restriction, it's considerably difficult to reach. Each entry is (at least) four bytes and takes eight cycles to parse, you're going to run out of render time on the current line before you hit 512 bytes of Display Lists.

My mistake. Of course reaching the limit on Display List is hardly possible and it isn't an issue. I was thinking about Display List List. Such restriction could be problematic because it means that our "Maria Assistant" could not generate separate Display List for every raster line.

38 minutes ago, TailChao said:

Both this and the similar restriction on DLLs have been on my testing list for awhile because of this. They're just so far out there in normal use.

I haven't found any reference to Display List List size limit in the documentation. Is there any?

 

 

Share this post


Link to post
Share on other sites
14 minutes ago, laoo said:

My mistake. Of course reaching the limit on Display List is hardly possible and it isn't an issue. I was thinking about Display List List. Such restriction could be problematic because it means that our "Maria Assistant" could not generate separate Display List for every raster line.

That'd still be 170 unique Display List Lists - so you could at least use it for a portion of the display. Using individual Display Lists for most of the game screen would get around many of the Holey DMA restrictions too, you'd have better clipping granularity. But at that point our "Maria Assistant" would have to be something like a Super FX or SA-1.

 

Of course, that's still within reach - even if it's a bit high ;)

 

 

14 minutes ago, laoo said:

I haven't found any reference to Display List List size limit in the documentation. Is there any?

The 512 byte size is listed in the old Atari manuals for both Display Lists and Display List Lists. I haven't verified whether it actually exists for either.

Share this post


Link to post
Share on other sites

Been thinking about this.  With the process described by TailChao, would it be preferable to use 320A for the larger amount of available colors as well as the lack of placement restrictions? (If I'm doing the math right)

Share this post


Link to post
Share on other sites

320A is only going to net you eight colors over 320B's seven, and then you're stuck with 1bpp draws - but this nearly doubles your fillrate.

 

This was the mode I wanted to use if we were going to shoot for a second title on the hardware, but it's not a performance panacea. If you think you can stylize the graphics well then it's worth a try. Really the biggest restriction with 320B is how many of Sally's cycles will be absolutely decimated by Maria's fetches, so if you have anything with complex physics (for this hardware class anyway) it'll get a little rough.

 

At the end of the day any use of the high resolution modes is going to be more difficult than 160A. But to me the crisp visuals are worth it. Again, still convinced 8-way scrolling in 320B can be done without too much extra junk in the trunk.

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.
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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...