Purpose of MAD-1 and 74139 logic for single ROM boards?

Hello everyone! Longtime lurker, first time post.

I am working on reverse engineering a SNES cartridge as a personal project to learn a bit more about how the system works. For the most part, I understand how the cartridges work, with the exception of the MAD-1 chip/74139 seen on earlier boards. This chip should be a decoder to tell when the SNES wants to work with the ROM or the SRAM, and enable the corresponding chip. I am confused though- it seems that the connector pinout has pin 49 for ROM /OE (/CART) and pin 54 for RAM /OE (/WR). These lines should both be high and then dropped when the system wants to read from the respective chip. What is the purpose of the decoder chip then? I understand it's use for games with multiple ROM, but for games without it, I can't understand the purpose, especially since it's connected to RAM /CE, which I thought that p54 was dedicated to doing.

From romlabs, I also saw that some of the pins of the MAD-1 are connected to A21, A22- what is the reason for this? Are those connections related to the operation of the decoder? Is the SNES sending hardware requests on those lines?

Thanks for all the help and knowledge nested on these forums!

As a note, I see a lot of this diagram passed around, originating from warosu, some online board
The connections for the 74139 kind of make sense, with /WR used to enable writes on the RAM, and /RD for /OE on ROM and RAM. However, I've seen some users here say that this diagram isn't necessarily correct, so I'm not sure if this is a good resource to use. I'm also confused by the stray caps littered around the board- are these for buffering the power to the chips when the system is reset/powered off? What other purpose do they serve? With some of them at 70nF, I can't imagine they're particularly useful.

How I interpret Game Pak slot pin descriptions from Fullsnes:

• Pin 49 is ROM select. This is low when the address bus is pointed anywhere in the upper half of banks $00-$3F and $80-$BF and all of banks $40-$7D and $C0-$FF.
• Pin 54 is write. This is low when the CPU is writing anywhere, including to peripherals in conventionally "ROM" space and (I think) internal WRAM.
• There is no pin dedicated to enabling cartridge RAM, which in HiROM games is conventionally located at $3x6000-$3x7FFF and in LoROM games is conventionally in bank $70.

Yes, the "bypass capacitors" or "decoupling capacitors" are for stripping AC transients out of the DC power supply. You usually see 100 nF of decoupling near each IC's +5V pin and tens to a few hundred μF near the edge connector.

Okay, so since there is no pin dedicated to enabling cartridge RAM, we use the decoder to enable RAM when pointing at external WRAM space, and this is done on A21 and A22?

Also, what do you mean when writing to 'conventionally "ROM" space'- are you referring to the cartridge, or the ROM itself? I was under the impression there were no writable areas in ROM- hence read-only.

Thanks for the tip on the capacitors!

The circuit generating the ROM select signal at the cartridge edge doesn't know whether the memory behind that address is ROM, RAM, or MMIO. Take the SNES PowerPak for example: it emulates ROM using RAM by first copying an executable from the CF card into RAM. In addition, some coprocessors are mapped in parts of ROM space.

I understand the purpose of the chip now. I think I just had some core misunderstandings on the edge connector roles.

Regarding the role of specific address pins in enabling/disabling the ROM and RAM, do you have any ideas about why those pins (A21/A22) are used for controlling the decoder?

Additionally, I remembered seeing this image a while ago which was on a short tutorial, so no explanation was given as to why they were tying the ROM /CE to A0 (or both demux as well, for that matter). Does that have to do with the fixed top of the stack pointer (https://youtu.be/fWqBmmPQP40?t=399) since A0 will always be low? Similarly, can a trend be found between wanting to read/write data to the RAM/ROM and toggling A21/A22?

Forgot image:

Different boards used different conventions for where one could address ROM or RAM. The specific address lines correspond to how the PCB is laid out, and where the ROM is programmed to expect to find ROM and RAM.

There's nothing magical specifically about A21 and A22.

That is not what's depicted...

The 27C322 always has a 16-bit wide data bus. The SNES cannot use this, it only has an 8-bit wide data bus.

The 74'157 multiplexers take the 16 bits out of the ROM and selects one half or the other for the SNES, according to A0.

I still don't fully understand how a 74139 Demux works for SNES carts. Can someone ELI5 it for me?

So I think I understand the theory behind a chip like the 74139 (it basically allows the SNES to flip between memory banks since the SNES CPU can only "talk" to 8-bits worth of memory at a time, because even though the CPU is 16-bit, the bus is only 8-bit), but reading the datasheets I'm not quite clear how it works.

I'm using this datasheet for reference: http://www.msarnoff.org/chipdb/74139

Why are there 2 separate Enables and Outputs? Is that basically to just to cover bi-directional pathing? Why would you need round-trip demuxing - wouldn't any operation done through the de-muxer one way remain "de-muxed" when that operation was "returned" back to its origin?

Thanks

It's easier to understand if you are aware that posts about 74139 are unrelated to those about 74157.

Let's first define a "multiplexer" before we can describe this part.

A "multiplexer" is a thing that gives one specific output out of many inputs depending on some other inputs. It's kind of like those multi-color pens where you push down on one of the springs, and the tip that comes out corresponds to that one.

Now, in an electrical circuit, you don't physically press a button to get a specific color of ink, but it's a similar idea. Instead, each "selector" connected divides the possible inputs into two halves (because the input can be high or low, nothing else is allowed).

A "demultiplexer" is kind of the opposite. Instead of getting one thing out, you instead put one thing in, and it puts it in the right place. Think of one of those robots that sorts candy by color.

So, specifically in the case of 74'139: You put one thing in (the "enable" signal), you have two things that pick where it comes out (sometimes called "A" and "B", or "A0" and "A1"), and a copy of the "enable signal" appears on the output pin that matches the two pickers. What about the other outputs? Specifically in the case of the 74'139, they stay "high", because that's how they chose to design the part.

Because there are entirely independent demultiplexers inside.

Well they're two sides of the same coin in the sense that one is a multiplexer and the other is a demultiplexer.

There you have found the best and most plausible way to derail things and produce more confusion. Are you doing that intentionally? Multiplexers and demultiplexers are - despite of their similar naming - completely different things. They aren't the same, and they aren't oppostites of each other. They are just different, completely unrelated. And the different ways how they are wired up in the schematics is making them even more different.

Your conclusion about the 8bit databus not being a 16bit databus sounds right, but that applies to the 2nd schematic (the one with the 74157 chips or 74257 or whatever they are called). And that's an extremly rare corner case - pretty much nobody is using that kind of 16bit-only memory chips in snes carts, so best forget about that.

The 1st schematic (with 74139) is not related to 8bit databus issues, the 74139 doesn't even connect to the databus at all. The main purpose of the schematic is to generate different chip enable signals for ROM or SRAM (or neither one) depending on different memory addresses.
The ROM enable should be fairly obvious, right? The SRAM enable is a bit more tricky, it's (mis-)using the second half of the 74139 to merge in the reset signal and another address line, and then somehow passing the final output through the transistor. I don't fully understand that part, but the overall purpose is clearly generating the SRAM enable signal.

Thank you for the explanation - I'm actually reasonably familiar with the functionality of mux/demux as a concept (I've worked in networking and telecommunications for much of my professional life)

I think my real problem is that I don't understand SNES memory addressing well enough. I'm reading through https://en.wikibooks.org/wiki/Super_NES ... memory_map and it doesn't quite make sense. If banks are notated as $00-$FF, that's still only an 8-bit bitmask, so selecting any of those banks requires 8 bits and thus can be done without needing to multiplex.

So in the HiROM memory model, since ROM data is mapped to $00 80 00 - $FF FF FF , if I have a sprite located in my ROM at $FF 00 in, say on page $80 DD and code data located at $F1 00 on page $80 CC, I first need to bankswitch to FF then send tell the CPU to read the contents of memory $00 80 DD, which gets me the sprite I want.

I can't get the code block that I want though, because attempting to read $00 80 CC would get me the contents of the ROM chip at $FF 00 80 CC.

So I have to copy the sprite data somewhere, bankswitch to $F1, then read $00 80 CC which gets me the code I want, and I can then execute this code on my sprite data since I stored it into a space that the CPU can read without needing to bankswitch back to the original ROM location of the sprite, thus allowing me to perform a code operation on sprite data located in separate memory bank that exceeds the directly addressable space that can be mapped at any given time?

So either I just figured out SNES memory mapping and bankswitching in a nutshell or I'm totally off base?

That page is terrible. I don't know what it is with people and the SNES memory map -- there have been I think at least 10 different "attempts" to describe it, and all of them are just downright terrible (many are too verbose because they're trying to cover too many things at once).

For a better understanding of the main two memory modes/layouts -- known as mode 20 (LoROM) and mode 21 (HiROM), which are effectively two separate types of PCBs -- I suggest seeing 3 pictures Tepples drew somewhat recently. One is a "summary" (i.e. general concept of the entire memory space as a whole), the other two are more precise/specific to each mode (these are the two I suggest understanding): viewtopic.php?p=235113#p235113

There are tons of revisions of these PCBs based on what features you want (battery-backed SRAM, etc.), and others which have unique tweaks/etc. applied to them in certain ways (those are a per-game thing, so do not get hung up on them or focus on them; understand the commonplace memory layouts first).

Using that wikibooks page seems to be a bad idea - some of it looks more or less right, but it looks more like a game hacking tutorial, and it's claiming the snes to be organized in 4kbyte pages? There isn't anything in the console or cartridges bound to 4kbyte boundaries, except maybe some pirate copiers were bound to 4kbyte boundaries back in the 1990'ies.
In the snes world, the term "page" is sometimes used to refer to a 256 byte memory area (specifically in case of the cpu's "direct page" addressing mode).

If you are using hirom, then your rom is located at C00000-FFFFFF, aka bank C0-FF. Apart from that, you'll also need to understand the CPU's memory accessing modes, and the consoles's mapping for RAM and I/O ports.

If you are using battery backed SRAM for saving game positions, then you will also need to know how and where to access that memory... and, yes, some carts are using 74139 chops for the SRAM mapping, but that's normally happenig behind your back, and software programmers don't have to care about whether that mapping is done via MAD1 or 74139 or other ways.

Yeah I'm actually quite familiar with the differences between LoROM vs HiROM - I've made repro games using both boards, donors, aftermarket PCBs, etc. I just don't understand *WHY* some games are LoROM vs HiROM, and how the memory address chips factor into the equation, which is what I'm trying to get a better understanding of. I'll check the links you provided, thanks!

Ok so I was way off - I thought the MAD-1 and/or 74'139 chips were required to address portions of memory within a game's ROM even in scenarios when the game uses a single ROM with no SRAM on the PCB. Apparently that is not the case and they are only required when a cart either uses multiple ROM chips and/or an SRAM chip, for switching between the ROMs or enabling write in the SRAM.

I thought it was a function of size - larger games tended to also be longer, so they tended to support saving, so you would often see 16/24/32Mbit games use a MAD-1 or 74LS139, but the demux wasn't necessary for accessing different portions of the ROM, it was just because those games also had SRAM and so the demux was needed in order to enable saving since there wasn't a pin for /WE on the SNES cart edge.

I can't think of anything in the Super NES that uses 4 KiB pages. But VRAM is organized in 4 Kiword (8 KiB) pages, at least according to OBSEL and BG??NBA.


I think it was whatever a particular game's programmers found more convenient. My guess is that HiROM has that nice linear address space, whereas LoROM makes it easier to have DBR pointing at both a table in ROM and the low RAM and PPU registers.

I wouldn't expect either of you to know the answer to this question, so I guess being the "historian" around here I'll have to:

In early days (or rather, as "late" as November 1993), Nintendo's own documentation for mode 20/LoROM indicated it only supported up to 16mbit ROM size. For larger (up to 32mbit), you had to use mode 21/HiROM. I have actual on-paper versions of older manual releases, which is how I know this. Said documentation also did not cover PCB/board types, nor mode 25. This also helps explain in part why things like 24mbit mode 20/LoROM games were "a pain in the butt" for emulation folks as well as some console copiers. This paragraph would make more sense if I could show you the depictions in the latest manual vs. older manual, but obviously I cannot risk doing that. I likewise suspect Nintendo came out with newer PCB revisions that "offered" more addressing space particularly for mode 20/LoROM than previous, but you had to know what PCB board model to request for your game, etc...

So in short: the choice was mainly dictated by ROM size for a long time, followed later by "whatever the programmer's found more convenient".

That made me wonder if mux/demux are used differently in analog telecoms versus digital memory mappers... the first thing I came across was a schematic like this:I had never realized that one could wire a mux & demux in pairs as shown above - now I do better underunderstand why they are called "mux" and "demux".
I guess that kind of circuit would be most useful with analog (de-)multiplexers, allowing to pass four analog inputs to four analog outputs, by using only a single cable (plus some patchwork to ensure that the additional Sel0+Sel1 signals are always the same on both sides (unless one wants to "swap" the signals, eg. passing In0 to Out2)).

Digital (de-)multiplexers could be theoretically used the same way, but I have never seen that in practice (it would be more common to use a serial transfer for that purpose (or just to use four separate wires)).
Instead of pairing mux with demux, digital circuits are more commonly using only either one, for implementing this or that logic trickery. Especially demultiplexers can be used fairly differently with different thinking:Here the 'main input' is usually wired to the Sel0+Sel1 pins, and the original Input pin is merely used as an optional extra feature (some datasheets are referring to it as "/Enable" pin instead of "Input" pin) (some circuits are simply having that pin grounded to make it "always enabled", or, the snes cartridge circuit.is having it wired to /CART (cart memory select) signal, so that's closer to the original purpose where "In" is getting forwarded to "Out'N").


The /OE and /WE signals are called /RD and /WR on the SNES cart edge. The 74139 logic is used for generating the separate /CE chip enables in carts that contain more than one memory chip. like ROM + SRAM.
Or, yes, back then it was also a "function of size": if a game was too large for the "small" ROMs of those days, then they needed to use two or more ROM chips, and generate separate chip selects for each chip.


Technically, tepples' answer has fairly well nailed down the main advantages/disadvantages.
Historically, yes, nintendo's documentation and naming has probably contributed a good bit to confusion about the snes memory map.

The other thing that is making snes memory confusing is the lorom mapping with the 32Kbyte chunks mixed with mirrors of the system area - that can be comfortable for small programs, but it's confusing at first glance, and it does somewhat require a "2-dimensional" memory map with 16bit offset in one dimension and 8bit bank in the other dimension (as opposed to, say, gameboy advance, where you have only one dimension ranging from 0 to FFFFFFFFh).

Hi again- I disappeared because I was busy with other work, but I've had some free time and am returning to the project. I found a really helpful resource:

http://randombazz.blogspot.com/2011/09/ ... oding.html

For me, this really helped me to understand the 74139/138. It definitely helped to write down the truth tables and compare to see what results were wanted by the SNES and how to work backwards from there for creating your own replacement.

Hope this helps!

Also, if anyone has any insight, I don't understand the placement of the transistor in the above warosu picture. I think the main part that confuses me is tying the 5V rails to the base through a reverse bias diode to the base, and another with the 5V rail going to the collector but also the output of one of the demux (can the demux pull this low when the input signals are correct?)

Hi, it might be a late reply to your post, but the transistor should be NPN and not PNP. What happens with this is that collector must be low to select the RAM. For the collector to go low, the emitter needs to be pulled low to make the transistor saturate as its base is pulled up via the 'RST' pin. For the emitter to go low, A20 must be high but A21 and A22 also to enable side 1 of the mux and 'CART' needs to be low to enable side 0 of the mux. Only then it is possible to read and write to the RAM. Therefore, to write/read to the RAM, ADDR bank must be 0x7x or 0xFx but not in the RAM range (7Exxxx-7Fxxxx).

Hi, it might be a late reply to your post, but the transistor should be NPN and not PNP. What happens with this is that collector must be low to select the RAM. For the collector to go low, the emitter needs to be pulled low to make the transistor saturate as its base is pulled up via the 'RST' pin. For the emitter to go low, A20 must be high but A21 and A22 also to enable side 1 of the mux and 'CART' needs to be low to enable side 0 of the mux. Only then it is possible to read and write to the RAM. Therefore, to write/read to the RAM, ADDR bank must be 0x7x or 0xFx but not in the RAM range (7Exxxx-7Fxxxx).