Jump to content

Recommended Posts

I recently became aware of the Maria Specs document. Reading through it, I noticed that it states that character maps must be fast RAM, instead of ROM. (even in the slightly later version of the document.)

 

Because this tidbit wasn't in the 7800 Software Guide, I've been accessing ROM based maps, and they appear to be working on real hardware. (though in retrospect, it is technically CC2's SRAM being accessed.)

 

I'm hoping someone has a definitive answer... Did I get lucky with hardware tests, or is the MARIA Specs document wrong on this point?

Link to comment
https://forums.atariage.com/topic/222256-character-maps-in-rom/
Share on other sites

Ok, at least it has the virtue of being tested thoroughly! :)

 

If its not an outright documentation error, maybe there's some kind of access speed difference between the mask ROMs of that era and EPROMs used today.

The same is true of Atari's published games. Maria accesses the character data directly from ROM.

  • Like 1

DLs you most often need to be changable so running from RAM is necesssary in that regard.

 

I've seen it documented somewhere, ROM acccess is slower than for RAM.

 

Remember, Maria runs based on ~ 7.2 MHz clocking. A CPU cycle is either 4 or 6 Maria cycles depending if TIA/RIOT is being accessed.

A similar imposition exists when Maria is doing DMA, it's something like 2 cycles for RAM, 3 for ROM.

 

Of course, Maria has no idea what is being accessed in the cart space so the assumption has to be that it's slow ROM whether it is or not.

In the 7800 Software Guide they define map as the data the DL points to in indirect mode. i.e. the "text" vs the character graphics.

 

I assume it's being used consistently in the MARIA Spec.

That's what I thought. Just wanted to make sure everyone is using the same definition. I myself have always put the maps in RAM.

Indirect mode (aka character or tile mode) is specified by a 5 byte display list entry containing a 16 bit address pointer to the character / tile map in RAM (required?), the number of characters / tiles to display (i.e. bytes to fetch from the pointer) along with the horizontal position, the palette and the write mode flag. Each character / tile byte is used as the LSB for the address of the graphics data (which may be in ROM or RAM); the MSB coming from the CHARBASE register. Either 1 or 2 bytes of graphics data may be fetched per character / tile.

 

As per the second link, MARIA has a different set of timings for graphics data (ROM) versus non-graphics data (RAM) accesses. I don't know whether MARIA changes timings based upon what kind of data is being fetched or the address (like it does to the 6502 for RIOT/TIA accesses). In addition, the cycle count list shows character maps taking 3 cycles - the same as a graphics byte. So it might be possible to put the character map in ROM; but as Rybags noted that's only useful for static data. (Hmmm... for SpaceWar! 7800, I had planned on including a tile based star field in ROM, I can't remember whether I ever tested it.) I wouldn't be surprised if the character maps could be in ROM since that's how you'd likely do a tiled background.

Surely there might be some games out there that use Rom-based characters, although there's little extra effort in copying static stuff to Ram.

 

Of course the timing difference Rom vs Ram if it is the case gives incentive to put as much into Ram as possible.

Also, character mode can be somewhat more DMA intensive since the char code fetches are on every scanline.

I think the reality is, that Maria isn't all that happy with really fast RAM (I think it was a UM61256K-15, Sirius will not work properly on that speed of RAM), so I don't think it matters. Are you wondering if you can gain cycles with placement in RAM vs. ROM? RevEng was just wondering if it is possible, and I say, yes it is. Big time, since I just mapped it to $3000, I think the HSC does map characters into that area as well, come to think of it.

Yes, the query was the # of cycles RAM vs ROM, or I guess a precise term would be what Maria thinks each is because of course RAM can be mapped in the cart area but Maria doesn't know what it actually is.

 

It all gets a bit convoluted since we have the "fast" clocking at ~ 7.2 Mhz, then the various access speeds and the 6502 running at either /4 or /6 speed depending on what it's trying to do.

It's not the CHARBASE which is in question, but the character list pointed to by the display list entry.

 

Also not an issue, I have sprite data mapped to $3000, the display list references them. Is that what you mean?

Also not an issue, I have sprite data mapped to $3000, the display list references them. Is that what you mean?

 

Maybe... are you referring to the graphics data used by a normal direct sprite, or the list of LSBs which are added to CHARBASE to obtain the graphics data (indirect sprite). It's that list of LSBs which are in question (RAM vs ROM).

 

Also not an issue, I have sprite data mapped to $3000, the display list references them. Is that what you mean?

 

Not sprite data, or character data (definitions) but the character map that picks the characters to display has to be in RAM (or at least that is what the docs say)

Well, I have a scroll text in something upcoming, that scroll text defines the characters to display (ASCII - big surprise). I move two "windows" across it, to get 320 scrolling. It and the character data live in ROM.

  • Like 2

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