Post by audreyhepburn on May 15, 2022 16:37:20 GMT
OK, I never saw that 1 Mega BYTE tweet.
But to be clear, the convention is :
lowercase 'b' = bits (used for ROM capacity and size of games back in the day)
uppercase 'B' = Byte (which everybody has understood even back in the day).
1Mb = 128KB
1MB = 8Mb
People these days seem to mix these up more and more, so I wanted to clarify that first.
(Kind of like how capital 'M' = mega = 1,000,000 - whereas lowercase 'm' = milli = 1/1,000).
'Mapper' is a NES-centric term, and it implies two things:
a) The 'larger address space' mechanism required by the program and CPU in order to address more memory than the CPU can directly address (or signals beyond what the bus provides). You can think of this as 'conceptual, from the program's point of view' - because the program needs to use this specific framework in order to work.
b) The address-decode logic needed for the chips to understand when they are being accessed. You can think of this as 'physical/electrical, electronics between the bus and the chips' - because the chips have to be given instructions.
The PC Engine mostly didn't need mappers during its lifetime because bank-switching was incorporated into the CPU, in order to be able to address up to 2MB (16Mb) directly.
This covers both of the above requirements up to 2MB, as long as the chips can directly use the address lines as all the logic they need.
From the chip's point of view, easy address selection always tries to use directly-accessible lines for chip-select in order to avoid any additional decode logic to get the right signals. Most HuCards used the most-significant address line (A20) as chip select, meaning that the chip is able to address the bottom half of memory (1MB or 8Mb) without additional decode circuitry. But if you try to use multiple chips (i.e. ROM and RAM), they need to know which is 'active' given the same signals, requiriing additional decode logic. If you feel the need to go beyond 1MB (8Mb), you will need a mapper system to cover both points a) and b) above, since the original CDROM system uses some of the top half of memory space for CDROM RAM.
Which brings us to Street Fighter II. This game implements a NES-like system to switch pages of memory in order to access 20Mb (2.5MB) of ROM. I honestly can't see anybody these days writing a game using this type of mapper system for HuCard, because the programmer has to do so much extra work and the existing tools aren't built to handle this for the developer.
So all in all, I'd see benefit to having ROM + RAM on the same card - which would require additional decode circuitry - but would not call the address decoder a 'mapper'.
And I don't see a particular reason to create a card which can address enough ROM-type memory to require a mapper as SF2 does.
...After all that, I don't see that there's enough space in the recess in order to hold Flash + RAM + address decoder.
Ah, thank you for catching that. I initially wrote 1Mb from memory but then when I quoted it I still didn't catch my error.
Well, that's more reassuring. Really hoping I'll be able to get my hands on these before they sell out.