Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Yet Another Mapper question

Reply to topic
Author Message
  • Joined: 24 Mar 2023
  • Posts: 15
Reply with quote
Yet Another Mapper question
Post Posted: Fri Mar 24, 2023 10:54 pm
Hi everybody,

I've spent the last few days learning a lot about how the bank switching worked on the SMS/GG. This is personal curiosity here, I don't have the skills to actually put this to use! But there's something I'm confused about and it's gonna bug me until I get it.

I understand how the standard mapper decides that slot 2 should be mapped to on cartridge RAM, but I don't understand how it's actually addressed. Let me explain where I'm confused.

A0-A13 are connected to the Z80, the mapper, the ROM, and the on-cartridge RAM. Any address bits the Z80 manipulates, all 3 cartridge ICs will see. So far so good.

Assuming RAM is mapped to bank 2, then, whenever the mapper sees an address in the range of 8000H - BFFFH, it knows that it needs to set the appropriate write or read pin of the RAM IC so that it sees the address pins and says "oh hey that's me".

But what's the ROM chip doing at this time? The ROM and the RAM can't both respond to the address pins, right? But if the ROM isn't being accessed while the RAM is being accessed, wouldn't the game hang? Are games programmed in such a way that everything they're going to need in that 16KB chunk just lives in the Z80 memory? What's going on here?
  View user's profile Send private message
  • Joined: 24 Mar 2021
  • Posts: 120
Reply with quote
Post Posted: Fri Mar 24, 2023 11:23 pm
The SMS memory map is already divided between the cart and the system RAM. This is more of the same.

It's defined that the system RAM will respond when: /MREQ is low and A15 is high and A14 is high and the control bit in port$3e is high.

So games' ROMs already have to not drive the data bus when the system RAM is busy.
In games with a mapper, the mapper is responsible for enabling cart RAM, or cart ROM, or neither, depending on the address bus and other control signals. (In games without a mapper, there's already a signal on the card edge for this called /M0-7)

The important part is that this decision has to happen on every single memory access. There is no "and now this peripheral is enabled" - at all times, multiple things have to figure out which part should be listening to writes and which part should be responding to reads.
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 594
  • Location: London, UK
Reply with quote
Post Posted: Sat Mar 25, 2023 12:04 am
Great answer from lidnariq! OP, just wanted to pick up on one thing specifically you mentioned in your question that is maybe causing some confusion:

MossDragoon wrote
But if the ROM isn't being accessed while the RAM is being accessed, wouldn't the game hang?


Not quite sure what you mean here. The processor can only ever be attempting to access one memory address at a time and (except in the case of more interesting scenarios where some memory shadows some other memory) that generally means either ROM or RAM but not both. e.g. when the processor is reading or writing RAM the ROM is simply not active - that's totally normal.
  View user's profile Send private message Visit poster's website
  • Joined: 23 Jan 2010
  • Posts: 412
Reply with quote
Post Posted: Sat Mar 25, 2023 12:18 am
BTW i would like add a question: Lets talk about Embed Extra RAM.
Which practical benefits with this Extra Ram? Of course i know that it will increase more memory to system but what a game can achieve with more RAM?
  View user's profile Send private message
  • Joined: 24 Mar 2023
  • Posts: 15
Reply with quote
Post Posted: Sat Mar 25, 2023 12:49 am
willbritton wrote
Great answer from lidnariq! OP, just wanted to pick up on one thing specifically you mentioned in your question that is maybe causing some confusion:

MossDragoon wrote
But if the ROM isn't being accessed while the RAM is being accessed, wouldn't the game hang?


Not quite sure what you mean here. The processor can only ever be attempting to access one memory address at a time and (except in the case of more interesting scenarios where some memory shadows some other memory) that generally means either ROM or RAM but not both. e.g. when the processor is reading or writing RAM the ROM is simply not active - that's totally normal.


Thank you for the answer lidnariq!

Will, you're right in that this is where I get confused. It's my understanding that every device on the address bus can see what it's currently doing at all times, and individual ICs need to know when they need to do something with that address and when they don't.

But you've both kinda answered my question and confirmed what I thought must be the case, even if I didn't quite get how that worked: if the mapper knows that the device that should be accessed is the ram, then it's the ram that gets accessed and the ram alone. In other words, CE for the ROM would be pulled high so that it "stops listening" to the bus for a minute/until it's directly spoken to by the mapper.

Does that sound right?
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 594
  • Location: London, UK
Reply with quote
Post Posted: Sat Mar 25, 2023 1:54 am
MossDragoon wrote
In other words, CE for the ROM would be pulled high so that it "stops listening" to the bus for a minute/until it's directly spoken to by the mapper.

Does that sound right?

Broadly, yes that's right. It isn't always (or only) the CE pin per se that is controlled by the address decoding. In particular when dealing with ROMs that will never be written it's common to decode to the OE / RD pin since bus contention only happens when two devices try writing at the same time. Practically any number (somewhat dependant on the logic technology) can freely read at the same time.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 594
  • Location: London, UK
Reply with quote
Post Posted: Sat Mar 25, 2023 1:57 am
segarule wrote
BTW i would like add a question: Lets talk about Embed Extra RAM.
Which practical benefits with this Extra Ram? Of course i know that it will increase more memory to system but what a game can achieve with more RAM?

Well, if it has a battery attached to it you could store player data on the cart...
  View user's profile Send private message Visit poster's website
  • Joined: 24 Mar 2023
  • Posts: 15
Reply with quote
Post Posted: Sat Mar 25, 2023 2:17 am
willbritton wrote
MossDragoon wrote
In other words, CE for the ROM would be pulled high so that it "stops listening" to the bus for a minute/until it's directly spoken to by the mapper.

Does that sound right?

Broadly, yes that's right. It isn't always (or only) the CE pin per se that is controlled by the address decoding. In particular when dealing with ROMs that will never be written it's common to decode to the OE / RD pin since bus contention only happens when two devices try writing at the same time. Practically any number (somewhat dependant on the logic technology) can freely read at the same time.


You know, I meant to write OE, but I was looking at the schematic for Phantasy Star's SRAM and accidentally wrote CE instead :D

There aren't any games that read two different ICs at the same time though, are there? Unless the address lines are split between them, I guess...

Questions for later though. I think I have enough to continue my thought experiments.

Thanks again! Maybe now I can sleep :P
  View user's profile Send private message
  • Joined: 23 Jan 2010
  • Posts: 412
Reply with quote
Post Posted: Sat Mar 25, 2023 9:06 am
Last edited by segarule on Sat Mar 25, 2023 9:35 am; edited 1 time in total
willbritton wrote
segarule wrote
BTW i would like add a question: Lets talk about Embed Extra RAM.
Which practical benefits with this Extra Ram? Of course i know that it will increase more memory to system but what a game can achieve with more RAM?

Well, if it has a battery attached to it you could store player data on the cart...
In some cases, no. Terminator and The Flash have extra 8kb and no use backup save. The problem is that i dont see, at start, nothing special with those games that is required more embed RAM .
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Sat Mar 25, 2023 9:10 am
Generally the level layout is in the extra RAM.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 594
  • Location: London, UK
Reply with quote
Post Posted: Sat Mar 25, 2023 11:04 am
Last edited by willbritton on Sat Mar 25, 2023 11:11 am; edited 1 time in total
MossDragoon wrote
You know, I meant to write OE, but I was looking at the schematic for Phantasy Star's SRAM and accidentally wrote CE instead :D

Haha it does get confusing. The CE mnemonic is one that is used fairly inconsistently, particularly in SMS parlance. Sometimes it seems to mean "activate the chip right now" and sometimes it is just gating the access.
At least OE almost always implies whether or not to drive a tri-state output buffer.

MossDragoon wrote
There aren't any games that read two different ICs at the same time though, are there? Unless the address lines are split between them, I guess...

Again, not totally sure what you mean by this. The CPU (under instruction from the game code in the cartridge) will be either reading or writing a single address or doing niether at any given time.

If the CPU is writing, in theory two devices could be listening concurrently. For example, I suppose a cart RAM could be shadowing data written to the SMS onboard RAM - a bit like a main RAM backup. Definitely possible although I think unlikely that any known game does this because it would require the mapper to protect against accidental read contention in hardware. If you were building your own mapper you could do it.

If the CPU is reading, it's highly unlikely that two devices attempting to simultaneously respond is a desired scenario. The only thing I can think of is if the data bus is split between two or more different devices, e.g. D0-D3 are driven by IC1 and D4-D7 are driven by IC2. In that case it's fine and both would share the same decoding logic.
Incidentally, that is a common set up when combining static RAM into wider memories. For example in the original SMS the VRAM was implemented as two 8-bit static RAMs with one attached to the high byte of the VDP's data bus and the other attached to the low byte. Thus we get a 16-bit memory system.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 594
  • Location: London, UK
Reply with quote
Post Posted: Sat Mar 25, 2023 11:10 am
segarule wrote
willbritton wrote
segarule wrote
BTW i would like add a question: Lets talk about Embed Extra RAM.
Which practical benefits with this Extra Ram? Of course i know that it will increase more memory to system but what a game can achieve with more RAM?

Well, if it has a battery attached to it you could store player data on the cart...
In some cases, no. Terminator and The Flash have extra 8kb and no use backup save. The problem is that i dont see, at start, nothing special with those games that is required more embed RAM .

I guess in general it's a tradeoff between:

- peak RAM capacity requirement
- time taken to copy and / or decompress data from the ROM into RAM
- cost of the extra RAM

So in Maxim's example of level data, perhaps the cost of extra RAM is low enough to justify the quicker level load speed which might otherwise compromise the game performance. Feels like performance is usually one of the first ceilings you hit with games, assuming that your assets are reasonably sized and bankable. As others point out, ROM can be considered somewhat infinite, and as you point out 8K of RAM seems like plenty, and mostly we think in terms of peak usage there; so performance seems to be to be the next likely culprit!
  View user's profile Send private message Visit poster's website
  • Joined: 23 Jan 2010
  • Posts: 412
Reply with quote
Post Posted: Sat Mar 25, 2023 12:36 pm
Maxim wrote
Generally the level layout is in the extra RAM.


Quote
I guess in general it's a tradeoff between:

- peak RAM capacity requirement
- time taken to copy and / or decompress data from the ROM into RAM
- cost of the extra RAM

So in Maxim's example of level data, perhaps the cost of extra RAM is low enough to justify the quicker level load speed which might otherwise compromise the game performance. Feels like performance is usually one of the first ceilings you hit with games, assuming that your assets are reasonably sized and bankable. As others point out, ROM can be considered somewhat infinite, and as you point out 8K of RAM seems like plenty, and mostly we think in terms of peak usage there; so performance seems to be to be the next likely culprit!

Both explanations help me to clarify more. Thanks!
  View user's profile Send private message
  • Joined: 24 Mar 2023
  • Posts: 15
Reply with quote
Post Posted: Sat Mar 25, 2023 5:59 pm
willbritton wrote
MossDragoon wrote
You know, I meant to write OE, but I was looking at the schematic for Phantasy Star's SRAM and accidentally wrote CE instead :D

Haha it does get confusing. The CE mnemonic is one that is used fairly inconsistently, particularly in SMS parlance. Sometimes it seems to mean "activate the chip right now" and sometimes it is just gating the access.
At least OE almost always implies whether or not to drive a tri-state output buffer.

MossDragoon wrote
There aren't any games that read two different ICs at the same time though, are there? Unless the address lines are split between them, I guess...

Again, not totally sure what you mean by this. The CPU (under instruction from the game code in the cartridge) will be either reading or writing a single address or doing niether at any given time.

If the CPU is writing, in theory two devices could be listening concurrently. For example, I suppose a cart RAM could be shadowing data written to the SMS onboard RAM - a bit like a main RAM backup. Definitely possible although I think unlikely that any known game does this because it would require the mapper to protect against accidental read contention in hardware. If you were building your own mapper you could do it.

If the CPU is reading, it's highly unlikely that two devices attempting to simultaneously respond is a desired scenario. The only thing I can think of is if the data bus is split between two or more different devices, e.g. D0-D3 are driven by IC1 and D4-D7 are driven by IC2. In that case it's fine and both would share the same decoding logic.
Incidentally, that is a common set up when combining static RAM into wider memories. For example in the original SMS the VRAM was implemented as two 8-bit static RAMs with one attached to the high byte of the VDP's data bus and the other attached to the low byte. Thus we get a 16-bit memory system.


You say you're not sure what I mean, but again go on to describe exactly what I was driving at with my layman vocabulary. Kudos to you for that!

Data lines is what I should've said, not address lines. This is all starting to make sense to me now.
  View user's profile Send private message
Reply to topic



Back to the top of this page

Back to SMS Power!