Mad-1 discrete logic replacement-new thread

Starting a new thread -- I am trying to make a cartridge and I'm stuck at the decoder.

I have the SRAM save part worked out such that I don't think I need that aspect of the decoder.
(planning on using a max795T. -OR- a FRAM, there's even a "MRAM" now. Fast, nonvolatile and specs say it's unlimited read/writes! Very cool but also only low voltage. :/ ) And thanks to Jim for pointing me in the right direction on the cic.

I've read the older posts about this subject and frankly, I didnt find a clear answer.

I just want to be able to have a circuit that functions like the mad 1 (minus the SRAM save part) that can decode 1 or 2 flash roms and 1 SRAM. I spent all day with a 1A3M cart with the mad removed and jumpers to a 74LS139 and trying to connect similar functions (I.e. OE is mad pin 4, 74ls139 is pin 1, etc...) but I didn't get it to work. I'll post my pinout tomorrow...maybe that'll shed some light.

So if there is a functional equivalent, please let me know.

Thank you
Mark

Well how did you want to decode the ROMs exactly? HiROM or LoROM? Something mixed? It all depends on what memory you are wanting to use. I think a truth table has been posted for the MAD-1 in the past. With that and some 74 series chips you could likely make your own MAD-1 equal. In general what exactly is the end goal?

Thank you for responding. My end goal is to be able to make a repro cartridge without special Nintendo chips. I would love a combo circuit for hi or low rom, 64m capacity (2 x 32m) save ram -- up to 1m (question: is 1m even necessary? I think 95% games use the 64k). I would be fine with a pic - something I could program that would also perform the decoding functions.

I have a good direction to go forward with a power supervisory circuit for save ram (or a nv ram)

I have seen truth tables listed, but as I am still learning, I don't understand how to apply the truth tables to actual chips/circuits.

I noticed that the 1or2-A3B & J carts use the LS139 decoder. I tried playing around with that today -- adding jumpers to bring the A20 and 21 address lines to the cart edge connector but I can't get anything above 1m to run.

I have seen on some "commercial" repo carts that a cpld is used for decoding.
I would be open to hiring someone to make a pic or a working schematic, of which I would incorporate into my design and I would also freely make available to whoever wanted it also. Anyone want the job?

Thanks
Mark

What do you mean without special chips? I think there already is a clone of the CIC chip. That's the only "special nintendo chip" in cartridges. The MAD-1 is just a specialized IC by Nintendo for decoding addresses and enabling MaskROMs or SRAM and handling battery backup stuff. All of that can be achieved by off the shelf parts. But it made sense for them to just make their own IC back then.

Games were made that use 2, 8, and 32 kilobytes of SRAM. I think the only games that have 64 kilobytes are Super FX titles. That would be 16kbit, 64kbit, and 256kbit. Although I think there is some japanese title that uses alot of SRAM.

Anyway they already have made 3 or 4 cartridges you can load nearly every game on. The PowerPAK, SD2SNES, and Super EverDrive to name some.

What I mean about "special chips" are non custom chips made by Nintendo.

I am all for pics! I recently learned about assembling the cic hex into a pic. So if there was a pic alternative for the Mad1, I'm all for that.

The 64k SRAMs are widely used I the 1A3M, 1J3M 2A3M, BJ3M, 2A3B, and other variants carts. The "3" being the 64k designations.

The super fx carts use 256k and 512 k SRAMs.

Edit: I am aware (and own) several of the repo carts including the SD2snes, ever drive, powerpak, and 1 other. My goal is to learn how any why they work. Building one of my own is more for learning and to see how it's done.

I have made all kinds of adapter for cartridges (see my YouTube) but I have never made a cart. The Mad1 is really the one area that I don't know how to get around.

Mark

I'll try the teaching you to fish vice feeding you fish approach...

I couldn't find the original thread I stole this from, so apologies on that. I gave up after a few mins, but you're apparently familiar with all those MAD threads so perhaps you can help me credit the author.

This isn't Hi or Lo Rom. But, if you have the truth table for the LS189 and the MAD you should be able to figure out how this circuit differs from the MAD logically. Ignore all the fancy circuitry for the SRAM /CE and battery backing. Pretend the '189's pin 13 is connected directly to Vcc and pin9 is connected to your NVRAM's /CE line. Once you see the differences in the truth tables see if you can re-arrange this circuit, add more '189's or whatever you need to make it act like hi/lo ROM. Then get more complicated and try to add 2 ROMs if that's what you really need, 1 ROM will be a bit simpler so I'd start there.

I haven't done this myself, but I will say you should be able to accomplish your goal using (multiple?) 189's only, might not be the most efficient but you can make practically any combonational logic you want with that chip. Go for efficiency after you figure out what's going on.

No cash's truth tables make the most sense to me and give you the pinouts and everything clearly. If you're new to truth tables I suggest using his. You should be able to find plenty of good sources for how truth tables work online if needed.

That came from Magno.

It's a 139, not a 189 for clarity to others reading this.

Thanks for the tips. I'll check them out.

Mark


Edit: that circuit is a lo rom. The "A" denotes that. The first #1 says its a single rom, A - lo, next #1 means it uses a 16k SRAM, the B means it doesn't use the mad1.

Good corrections/clarifications. Not the first time magno's handwriting threw me for a loop either on that 3/8

Yeah I knew it behaved similar to the LOROM but it's a little off compared to the MAD-1 because of the smaller ROM size I guess, and lacks the mirroring. That and I never took the time to decode the name, so thanks for pointing that out.

There's a real handy chart that spells out what all the numbers mean... I'll have to look up where I got it (maybe from snescentral.com).

I tried matching functions/pin descriptions to these:
I used a super Mario all stars (2A3B. - 2 roms, Lo, 64k, no Mad1) for testing and comparing. I didn't get anywhere.

Then I tried a 1A3B (some football game) and I still wasn't able to get it to run.

For clarification! I am trying to run a 32m rom on these carts. The "B" carts (non mad1) are all 32 pin 8mbit or smaller cartridges. The 32mbit are 36 pin mask roms (or tsop adapter).
The difference between the 2 are 2 additional address lines (3 really but A22 isn't used) A20 and A21.
Using the existing decoder on these carts, I *thought* a good place to start was to try to add the additional address lines from the rom to the cart edge. Didn't work. This stumps me.

I'm trying to understand why and it's very frustrating. I know I'm not the sharpest knife in the drawer.



Mark

It is, but it sounds like you're trying to find the difference without comparing the truth tables. Forgive me if I'm wrong, but it sounds like you're trying to tackle your project while avoiding truth tables. Bite the bullet! Learn em! Draw your own truth table for the MAD and these carts, compare them, and you should be able to find the difference.

That is next on my to do list.

Thanks

Yep, my '3' is kinda weird XDD
Nice that those "schematics" helped you!

Please correct me if I a wrong here....

The game programs have a header that tells the Snes how big it's size is, where the files are in the roms. Then the Snes try's to retrieve that data via the mad1 - which is hard wired to the cart based on rom, ram configuration. So attempting to run a 32m game file on a cartridge that is " hard wired" to 8m configurations is where things get lost. And even though the additional addresses lines can be jumpered to make a physical connection, the header information would have to be altered together access to the additional addresses?


Am I even close?

The internal header in games is *completely* ignored by the SNES. The only thing that matters are the CPU vectors that must appear in that 00/FFxx area. When the SNES reads data from the cartridge it is entirely up to the electronics in the cartridge to provide a response. Also the SNES doesn't have "files" in the ROM. It's just a binary ROM. Data in the ROM can be anything and anywhere except for the CPU vectors which must be located at a specific spot.

If you're talking about trying to run a 32m game on a retail board that used two 8m mask roms, you'll have issues because of how the board is setup to decode roms. Yes it is "hard wired" for that configuration. But it's relatively easy to modify the setup to allow different sized roms. Again the header information is useless. However emulators and some flash carts and copiers may rely on the header information being accurate! This is no so with an actual cartridge where you can completely leave the header blank or containing data that isn't a header at all.

To bump this thread a little, I have been doing some work on this. I have successfully managed to get a 32Mbit Snes rom (Seiken Densetsu 3) to work and save without using the MAD-1. I wired up a LS139 as the decoder (similar to what is used in FF5), and used a BA6162 chip taken from the backup circuit of a Sega Genesis cart. The game plays perfectly.

There is a slight problem, however...

Over time, and with long periods of use, the data on my SRAM becomes erased. In the 3 save slots in SD3, the first 2 can periodically be erased. The third save slot is always there, and so far has never been erased. I can't seem to figure out what could be causing it. If it were losing power (IE if the BA6162 wasnt kicking over to the battery after powering off the system) it would wipe all contents of the SRAM, wouldnt it?

The other thing I need to mention is that this is using a proto cart that I have designed, so it is not using any Nintendo parts at all. Also, currently there are no resistors on it either, as I didnt add them to my initial testing design. Not sure if not having the resistors between the battery and the BA6162 could be an issue, but the Genesis cart I took it from didnt have any resistors there, only one by the SRAM, which I added to mine.

Any ideas?

Maybe by the time it kicks in it manages to protect the third save file? Just a random guess. Does the erasing problem happen if you always HOLD reset while powering off?

It's kinda difficult to speculate on the problem while also speculating on your how your circuit is wired up. I'd recommend posting your schematic. If you haven't drawn one it's a pretty vital tool to you for figuring out what's going on. It will also help us see exactly what you're doing and gives us a better chance to point you in the right direction.

ISTR that most SNES saves are protected by a checksum, and so if anything is scribbling over the parts of memory that contain any portion of the first two saves, they'll disappear.

i.e. maybe using the '139 doesn't map save RAM to the exact same place?

What voltages do you have on your data lines when powered off ? Should be almost nothing.
Some uIC's have a delay when transitioning between power states to prevent accidental writes

Which SRAM are you using?

Thanks for the reply guys. I do have a schematic that I've drawn out on paper, and as soon as I get a chance I will redraw that on the computer so I can upload it here.

@lidnariq I don't know how the '139 handles Sram, but I did do a copy from how the FF5 cart has it wired, the only thing being different is the BA6162 versus the D2145 3 prong-thingy they have in theirs.

@Mark its the same type of 64k ram found in any SNES cart (in fact, it has been pulled from a known-good cart).

@Mottzilla I havent tried holding reset during power off. I figure if I need to hold down reset for this cart to ensure the save works then I need to find a better option...no one likes having to do that

It is just a quick MSpaint sketch to show the way the BA6162 and the '139 connect with the sram and rom. The lines are just to emphasize whats connected to what. Sorry for the crudeness...

EDIT: Moved schematic. see below.

Here is a link to the datasheet for the BA6162 chip:

http://www.datasheetcatalog.org/datasheet/rohm/ba6129af.pdf

Have you tried running a different game that saves to see if the problem happens on other games?

No I haven't. That being said, I would like to just focus on what might cause this to happen, and a possible fix, before I move on to another game. Because if this method doesn't work for this particular game, then it will most likely happen on others as well, which renders it useless.

A friend of mine said that he has the exact same problem with that game you are using. Maybe a quick reprogram to a different game might be a good idea to see.....

What type of board is he using? Is it a custom board using a different chip decoder or a donor cart with a MAD-1?

I have made this game before using a standard 1J3M board and MAD-1 chip and the game worked without a problem. The only thing that has changed here is the '139 and the BA6162 instead of the MAD-1.

I'll try to find out....

So your circuit is kinda gunked up... You've got multiple chips trying to drive (output) to a single line (wire), pretty big 'No-No' for logic design. When those two chips disagree on what the output value should be they'll output as much current as the can trying to put their voltage on the wire. Who knows that the chip that uses that signal as an input actually sees. I'd say it's not surprising that you're loosing saves in the manner that you're seeing based on your circuit.

First question: What are the signals you're connecting to the 'cart conn'? I can only guess which signal you're using there.

Conflicts you have that must be resolved:
1) '139 pin11 and ba6162 pin5 are both trying to drive the green SRAM CE.

2) ba6162 pin2 and cart conn (I assume) are both tring to drive the pink line.

What pin is the pink line connected to on the SRAM? SRAM doesn't generally have a reset pin, I'm guessing this is CE or something. I'm also uncertain on what pin your connecting to on the far right of the SRAM. Sounds like you're connecting SRAM /OE to Flash /CE? and that's being controlled by cart conn /ROMSEL?

It's still a little cloudy on what's actually going on here, but if I make a lot of assumptions I'd guess you might want to try something like this:

Disconnect the pink line from the cart connector. Disconnect the green line from the ba6162. This should let the '139 decode when the SRAM is being accessed by the CPU, and let the 6162 control when to disable the SRAM because Vcc < Vbattery to maintain saves during power down.

I will redraw the schematic as soon as I get a chance and show each line, to the cart connector. My other one is pretty crude, and clearly isnt stating enough info.

The pink line connects the Ba6162 /RESET pin to pin 26 on the SRAM (/RESET) to cart connector 26.

The '139 needs to be connected to SRAM /CE or the game doesnt work. and If the BA6162 isnt connected to Sram /ce the saves are deleted every reset. So i'm not sure how else to wire that...which is why they are connected together.

I will draw a better one, and hopefully that helps out a little better with what is going on in the cart.

Ok, I have put together a (hopefully) clearer drawing. Its still pretty low budget, but I don't really do drawing schematics on the computer very well.

*old, removed*


Let me know if this helps a little better.

From what I see on a regular cart, Sram /CE2 connects to the /RESET pin of the MAD-1, which is connected to the SNES connector /RESET. If you check out the data sheet for the BA6162 (linked a couple posts up) it shows it has a /RESET pin and 2 /CS pins...so its a little confusing as to if I should have that attached to /CS on that chip or to the /RESET pin...

Those reset and CS pins on the 6162 are outputs. You can't just connect it based on the name, you have to connect based on the function. I suggest connecting the 6162 pin3 to the SRAM CE pin. That red wire CANNOT connect to both the '139 and 6162, you should ONLY let the '139 control that signal.

What SRAM are you using? It has two /CE and no CE?

I'm not sure what you mean by /CE and CE...aren't those the same thing? It is just a standard 6264 sram. Data sheet is here:

http://www.buyicnow.com/files/datasheet/STATIC_RAM/343.pdf

It shows its got a /CS1 (pin 20) and CS2 (pin 26). According to what i've found on a standard Hirom cart, is that pin 26 on the sram connected to MAD-1 pin 9, which goes to RESET. So i figured that would be connected to the RESET pin on the 6162...



The reason I didnt do that, while connected to the '139, is that the saves would delete on almost every power down. When I moved the Sram CE to pin 5 it worked alot better.



So what you just said here kind of contradicts the previous quote... So you're saying that the /CE should be connected to the '139 and ONLY that? So connecting the 6162 pin 3 to /CE isnt what I want? That makes me a little confused...

Anything that's always an output can be connected only to inputs.

/CE means "output when 0V"; (no slash) CE means "output when Vcc"

There's a bunch of conventions for things that use the "0 is true" sense: leading /slash, o̅v̅e̅r̅b̅a̅r̅s, #octothorpes, n_negation_prefix.

The two statements are about two separate pins on the SRAM. Let the '139 control the ACTIVE LOW /CE pin. Let the 6162 control the ACTIVE HIGH CE pin.

The reset pin on the 6162 doesn't have a pull down resistor like the CS pin does. That might be why you're losing saves. That is why I suggested using the pin designed for the function you're trying to perform.

Ok, that does make some sense... I wondered why the SRAM had a /CS and a CS2 pin... Ok, here is the new one:

*old, removed*

I have moved the line that was connected to the /RESET as you suggested to the 6162 pin 3, and so far it seems to be working. The '139 controls the SRAM /CE now, and the 6162 controls the CS2 (which im assuming would be the CE you mentioned). Does this look more accurate?

MUCH better!

So it's working and saving properly so far?

And yes CE = CS2, they are both active high chip enable/select signals just differ in name depending on who wrote the datasheet.

Seems to be! I had a minor screw up in the schematic, because when I switched how the 6162 connected I forgot to tie in the /Reset pin to the cart connector. This was causing me not to be able to use the reset button on the console (push reset, game keeps playing with black screen). Now it seems to be working ok. I even went all psycho on it and pressed reset about a 100 times in a row, just to see what would happen. Saves were kept just fine!

I'm going to be keeping on eye on it for the next couple of days, just to verify that the saves are kept and that the battery isnt draining too quickly.


EDIT: NOPE! Just lost the first save file. damn...i thought it was fixed. It had seemed to work ok before I tied the 6162 pin 2 to cart /RST. Is there some other way I should be wiring that?

DON'T connect 6162 reset pin to the cart reset pin. The two signals should have NOTHING to do with eachother they are BOTH output signals. You're schematic should be good as is

Well how do I get the cart to be able to reset then? Without the 6162 connected to /RST the game keeps playing when the reset button is pressed, and if you power off the system you have to wait a few seconds before turning it back on or the game doesnt boot up.

The SNES generates the reset signal not the cart... So I'm not sure why you think/apparently need the 6162 to reset the SNES. No other SNES carts have 6162's and they all reset just fine. Original SNES carts merely connect the cart conn's reset pin to CS on the SRAM to prevent writing to SRAM during resets.

Do original SNES carts reset just fine?

Yes, other carts reset fine, and so does this cart if it uses the MAD-1. If the /RESET line is left unconnected from the cart connector (cart edge pin 26), the game does not reset at all. So if the RESET pin from the cart doesn't control the reset ability, what does? Can this be connected to the '139 in some way, like it is on pin 9 of the MAD-1?

When you 'disconnect' the cart edge reset pin, you aren't then connecting it to Vcc or something funky are you? You should be able to just leave it floating.

With your multimeter reading 'DC volts' measuring across GND and cart edge /RESET, what does it read when the reset button is unpressed, and pressed while your cart is playing?

I imagine it should read ~5v when not holding reset, and ~0v when holding reset.

Thats what I did. I just didnt connect anything to it. And yeah, couldnt reset the game.

I will have to try and see what it shows in the mulitmeter.

EDIT: Just double checked my pcb, and I had /RESET connected with a via to the SRAM (should've checked that before...crap), so when I disconnected the RESET line from 6162 pin 2 and connected pin 3 to SRAM pin 26, I was actually piping RESET AND CE to the 6162, which must've been what was causing my reset issue. I have cut the trace, and verified it to be working properly now, with the cart RESET line left floating as you suggested.

Thanks for the help guys (especially you INL)!

NP, glad to see you found the issue. So are your saves sticking around long term now?

Yeah they seem to be ok. I have moved it around to multiple systems and the saves stay intact, even with multiple resets, copying back and forth from my Retrode, etc

I have used this method to make 48Mbit games, and they save and work properly as well.

So are you saying that the mad1 is nothing more than a 139 and SRAM back up .... That's it?

I thought there was more to it than that.....


Mark

The first couple Sunsoft mappers were just a couple 7400 series parts in one package. Perhaps the secret sauce is in the SRAM protection circuit.

Honestly, it doesn't appear to be anything special, just look at its pinout. When you look at the early carts, with the LS139 and the D2145U chip (or other variant), they could technically handle most of the games out there that used standard boards. It just made sense for Nintendo to combine the 2 chips together into one, cutting down on costs and space required in the cart.

So far all the HiROM games that I've tested have worked perfectly (up to 48Mbit), and I anticipate no problems when trying this with a LoROM cart, as it should be basically the same setup (aside from slight rewiring on the '139...yet to be tinkered with).

Now the only thing is to find a more feasible battery controller, as the BA6162 is another one of those obsolete parts. Mark had mentioned the MAX795T chip to me before, which would work perfectly, but it is a little expensive at almost $6 each (sometimes they can be found cheaper on eBay). If I find anything super cheap, and easy to come by, I will necro this post to share it.

They aren't obsolete, but do apparently have large minimum qty. Digikey PN BA6162-ND (use the PN if the link doesn't work...) There are quite a few other battery backup chips available though if one knew exactly how to deem a chip worthy. Those MAX795T are pretty spendy given the simple function...

Well thats kind of it. How many people would be willing to buy 2000 of those chips at once? I know I wouldn't

I will try and experiment with a few different kinds, and see what i find. Now that I know the proof-of-concept works, its just a matter of finding something compatible.

The STM795 (equiv of max 795) is a lot cheaper. I think mouser sells them for $2.38 or close to it...

My question about the mad1's is: all the older carts that are 16m (2x8mbit roms) or smaller, they used the 139.
Anything bigger than 16mbit, the mad1 is used. Mario all stars is a good example. While I question if a 139 + max795 = a mad1, I hope this is true.

Au contraire. I have a copy of Mario Allstars here, board SHVC-2A3B-01, which uses 2 rom chips, an LS139 chip.

Pic of board here, using no MAD-1 chip:

http://www.snescentral.com/0/8/8/0881/SHVC-H5-0.jpg

That is my point.... All stars is 16m (2x8) and is not using mad1.
Show me a board that is bigger than 16m using a 139 with SRAM......

Depending on relative costs, something like this simple PNP BJT circuit:might well be cheaper than a "real" battery detection circuit. It could be directly connected to a 6264's +CE input, or an extra 74HC138/9 could be used to convert it for a RAM with only one select.

Power switchover is something I'd need to think about more, but the ba6162 appears fairly simple.

The big difference in behaviors seems to be that the ba6162 provides hysteresis.

Oh I see, I figured you were saying it uses the MAD-1. Later revisions of that board did use it, once Nintendo started using that decoder in all their boards. Also, in all fairness, the SNES didn't really start releasing games larger than 16M until 93-94 (AFAIK), and by then had already come out with the MAD-1.

The functions of the MAD-1, as it looks, is an Address Decoder, SRAM controller, and a (2x) ROM Decoder all built into one. So, if you split the functions between 1 or 2 LS139 decoders and an SRAM controller, all you're doing is using 2-3 chips instead of one...still looks like it was just a space and cost saving measure to me.

Mark, what other functions do you figure the MAD-1 had? Do you see a reason why this setup with the '139 couldn't work?

Perhaps if people would develop high-quality NES games that are long enough to need battery save, bunnyboy might be willing to keep them in stock on retrousb.com.

Perhaps the bigger (over 16 Mbit) games were also later games, manufactured after the MAD-1 was designed. And perhaps it had to do with the fact that PRG RAM had to be decoded specially so as not to overlap PRG ROM.

I know the ba6162 gets more fancy, but shouldn't a pair of Schottky diode should be sufficient?

No, because of the chip select blocking to avoid data corruption. You want to avoid writes during Reset/powerup and powerdown.

Yes anybody can come up with a pullup and pulldown resistor and diode solution, but it would drain the battery much, much faster.

Nintendo learned first-hand of save data corruption on the NES, and I'm sure their management wanted to progress from some boilderplate statement of "hold reset while powering off the unit" to avoid save data corruption. I wonder how many children got into slapping fights because their friend "stupidly" didn't hold reset while powering off

I honestly don't know but I did look at the MAD1 Truth table from NOCASH's site and it didn't look like the 139's truth table.....

Then perhaps the permanent solution is to find some unused area of flash twice as big as the SRAM, copy that area to SRAM on power-on, and copy SRAM to flash whenever the game saves. I say "twice as big" to work around the possibility of power loss while copying.

Please see the rest of my post that INL didn't quote. That concern was, in fact, the first one addressed.

Well, we know empirically the battery protection circuit as used in SNES cartridges is pretty bulletproof as far as powering on and off, except for that obvious problem of shutting off while saving. (Have there really ever been any complaints? I never heard about it from anyone growing up... It was always the little brother going in and deleting something).

Oh yeah, and the SNES Zelda: A Link to the Past does use kind of the method you're talking about (double sized). The SRAM holds two copies of every save file... if it sees the first one as corrupt, it'll try to use the second. I bet there are other games that do that too.

Off the top of my head bugginess causing savegame problems... RPM racing track editor, Stunt Race FX beat the game then play one of the topmost Radio Control tracks (have to select the track while the screen is still scrolling up), Secret of Mana and Secret of Evermore. But whatever. My point is that I've never had a game delete just because I turned the system on or turned it off (outside of the do not shut off power, saving... portion).


copying to flash has its own problems, especially if it also contains a bootloader:

Flash can get corrupted by a bad write on poweroff during a block write sequence or buggy code, then not correctly boot anymore. As evidenced by the N64 Gameshark. (making too many changes to the cheat list, where "too many" is hard to quantify).

Flash does have an unlock sequence to avoid trivial writes, but it still matters where you write as the erase process takes out an entire block at once (so you have to write both the new data and the data you don't want changed back). Flash also has the terrific erase entire chip command that takes a few seconds to complete and can't be stopped.

As for a new game, I don't see why hiding your save file in the flash chip would be inherently bad, if you were careful to select a chip that does have a boot block, or stay out of the block that contains code.
this is an application note that talks about it... just a few pages...
AN1158 Uniform vs Boot Block Flash Architecture

Memblers recommended some "small-sector flash" chips such as the line formerly known as SST39SF. These have uniform blocks about 4K in size. But some of those chips' densities are closer to NES game size than Super NES game size.

Seems likely. The BA6162 compares a fixed voltage (probably a 1.25V temperature-independent reference) against a simple resistor divider, with 100mV of hysteresis. When that's in favor, it uses a Sziklai pair to connect Vcc to Vout. Otherwise, the battery provides power to Vout through a Schottky diode, a self-biased NPN BJT (to relieve current load from the diode?), and some resistors.

For anyone asking "why didn't Big N use a bunch of discretes?": because they could buy battery backup ICs for 30c/, but you have to for $2/. And at $2/ we can get you something pretty good in discretes.

Hey everyone, so I am working right now on how to implement an LS139 and a simple backup circuit to replace the MAD-1 in LOROM games. I have already successfully gotten HIROM games to work properly without the MAD-1 (as mentioned earlier in this thread).

Currently I can get any game 16Mbit and lower to load and save properly. But any game above 16mbit will not even load. Magno has been helping me with this a bit, but we haven't had any luck yet. I can't see why it isn't possible, as the HIROM carts work fine (wired differently of course).

My current '139 wiring design is this (traced this from a Zelda LTTP cart):

1. CART #49|||16. VCC
2. A20 (46) |||||15. '139 PIN 7
3. A21 (47)|||||14. A19 (45)
4. ROM /OE1 ||13. /RESET
5. NC |||||||||12. NC
6. NC |||||||||11. NC
7. '139 #15|||||10. NC
8. GND |||||||||9. SRAM /CE

Now, when I compare this to the MAD-1 in a lorom board I do notice that A15 is hooked up to the MAD-1. I have tried wiring that in place of A19 and /RESET, but no dice. I'm assuming that I need to have A15 involved somehow, but I thought Lorom ignored A15 anyways?

Can anyone help me out?

ROM /OE1 > /RESET ... The ROM's /OE pin is connected to the SNES /RESET pin What??? I must me missing the context here as this makes NO sense.

This list is only a small portion of the connections going on between the ROM, MAD/decoder, SRAM, and cart connector. If you can provide a schematic (pinout listing) which includes the entirety of the board and chips I can probably point you in the right direction. I know... doesn't sound like fun... But you might even realize your mistake yourself if you take the time to draw out the ENTIRE thing. Damn near anything can break the cart, there are 100's of things that have to be done correctly to ensure operation and your short list doesn't come close.

I thought the ||| was supposed to represent the body of the chip.

A15 is very important in a LoRom cartridge memory map when you have backup memory!

With /ROMSEL (/CART) signal going low, you need to distinguish if the access is for the SRAM chip, or for the Mask ROM chip.
With A15 Low, this is an access to SRAM or the special chips.
With A15 High, this is an access to ROM.

Ahh I was wondering why he was using so many pipes...

Eitherway it would still take a sizable amount of my time to draw out the schematic to figure out what's going on.

Even if you decoded the internals of the '139 or at least gave pin names vice numbers... Sorry I'm lazy...

The best way to figure this out is draw the truth table for the schematic you've created, then compare it to the one nocash has provided us with. Sounds like whicker has a pointed out a vital problem.

Yes, sorry that was just to visibly separate the pins on the '139.



Ok, so with how my '139 is currently wired, where would I hook up the A15 so that it works in conjunction with /ROMSEL?


INL, here is a rough schematic...very rough (MSpaint):

EDIT: see below.


Does that shed any more light into this? Sorry if I am being vague here... I'm really trying here! I'm actually signed up for a course at my local IT school so I can learn more about this stuff, but it doesn't start until October

Your schematic doesn't appear to be implementing this yet. You have to disable reads from ROM while A15 is low. The way you connect /ROMSEL directly to the ROM /CE bypasses this required logic.

Ok, I've updated the schematic to show how its wired now. ROM /OE is controlled by the '139 now, and A15 is on the other end. Still no luck.

You didn't actually implement the logic with a15 like we said though, you just implemented some other random logic with a21 & a22...

Your assignment:
Create a truth table for your schematic. nocash already provides the logic table for the actual mad1. So you just have to modify you schematic and the resulting truth table to match. Don't know truth tables? Good news, the internet does and its willing to teach you. Also, don't discount the possibility to add another chip, you can always simplify after its working.

.......Ok, but that's why I asked HOW to implement it. A21 and A22 are required for a 32mbit game, so those have to be hooked up. I've tried changing sides, with the A15 and A19 on pins 2&3, and A21-A22 on pins 13&14. Still didn't work. Seeing as the '139 only has the 2 Address inputs per decoder, how else can it possibly be hooked up??

I will learn the truth tables, but if this is really just a quick thing that I am missing I would really appreciate throwing me an answer. I really just want to get this damn thing working

Remember:



The problem is you're just looking for proper connections with no regard to the logic behind the connections. If you just want the connections I'd suggest referring to schematics of Lo-ROM boards that don't use the MAD1. I'm trying to help you understand the logic behind what you're doing which will be much more beneficial if you take the time to figure it out. We've already pointed you in the right direction.


The quick thing you're missing is the flawed logic we've already pointed out, sounds like now is the perfect time to learn truth tables then! The truth table for the '139 datasheet, and nocash give you the one for the MAD-1. You previously enabled when /ROMSEL was low, but you should only be doing it when /ROMSEL=0 AND A15=1. I don't know how to make the logic more clear, if you can't figure out how to do it with the '139 just add another chip or two or three.

The LoROM wiring I provided work perfectly as proved by so many people who uses my boards. This one is NOT the same you copied in your private message and I don't understand those chages... There must be something else you are missing.

A20 - A21 - A15 are the only address bus lines you should use to activate SRAM and to enable the EPROM, just as Nintendo does with MAD-1 (although it sometimes uses A22 too, but it is not mandatory qhen using only 1 ROM chip).

Yeah Magno i'm not sure what it was...but for some reason that pinout I sent you worked worse than the one I posted here. With that one, I could load and play 16mbit games, but it wouldnt work with my backup circuit. The one I posted here allowed me to save in 16mbit games, but thats all. So i figured this one was closer than what i had previously...and I didn't want to keep flooding your inbox

I am checking through the truth tables, and they are starting to make a little more sense to me. Its late here though...so maybe its just the sleep deprivation talking

BTW, thanks for the "extra" push INL...i keep putting off truth tables because they look crazy, but this will help me out in the long run! Once I have things figured out I'll post my schematic here and maybe you can tell me if I've figured it out correctly

Worked flawlessly in more than 50 boards with 32, 24, 16 and 8 meg ROMs and with 256, 64 Kbit SRAMs:



Absolutely tested and 100% guaranteed.

Well i got it to work, although it does look different than the one you posted magno. I have tested 32mbit games and they play and save properly now, as well as anything down to 8mbit (haven't tested 4mbit games...but im sure they work too). Does anyone see any issues with this setup?

The difference is because Magno's design ties A15 to both inputs of the first decoder, so A15 high enables (active-low) Y3 and A15 low enables Y0. By tying the second input to Vcc, when A15 is high, you enable Y3, and when A15 is low, you enable Y2. Other than that, your decoder is doing exactly the same thing as Magno's.

That's what I figured. Awesome! I think I may have learned to read truth tables a little bit

Magno,
So is the 74xx139 wired the same for hi and lo rom games?

Thanks

No, the 139 wiring is literally the only difference between hi and lo rom games, so it couldn't possibly be the same

That's right. But one more difference between LoROM and HiROM exists: A15 is not routed to MaskROM in LoROM games.

I think I stated that question poorly...
I've been looking at this mad1 replacement just as getafixx has been doing.
I've been looking at an ic switch to change from low to high rom games..
Basically have a few of my favorite games on one cart (hi and lo)

So I guess my question should have been stated (and looks like already answered some) ... With rewiring, the 139 can work on hi rom carts AND lo rom carts with only minimal rewiring?
Or is the re-wiring VERY different?

I'm in the same boat as getafixx, trying to learn about the truth tables but how some of it is explained previously in these posts is MUCH more helpful in my understanding than a truth table by itself.

Thanks to all who have contributed to these posts!

Yes, it is very different; major difference is that /ROMSEL must not be asserted when accesing SRAM in HiROM games.

If you want to do it in a switchable manner, you'd be better off going with a programmable logic chip, like INL's HiLoROM cart that you can find elsewhere in this forum. I really want to figure out how to program a GAL so I can use one of those instead of a full-fledged CPLD like the MAX7000 or the XC9536... ah well...

Unfortunately, all the PALs and GALs I can find are either New-OId-Stock or as expensive as the XC9536L.

I've got a pile of ~20 22V10s I harvested from an ancient Sun deskside computer, but will probably never use them. When I've looked, it was also fairly difficult to dig up the programming mechanism too.

A CPLD would be nice to do the hi/lo switching... but I'm trying to stay with non-programmable, non-specialized devices...
Just using some I.C. switches.... maybe that's craziness.... but I'm real close in my design. Just need an accurate Hi-ROM 139 wiring specs to go forward.


Mark

I.C. switches? Do you mean DIP switches, or do you mean multiplexer chips?

On HiROM, A15 from the edge connector goes to A15 of the rom chip, A16 goes to A16, A17.... and on and on. So you're involving everything from A15 to A22, and more conventionally using the uppermost address lines as chip select.

You still ignore A23
the memory maps into the 64KB pages of banks $40-$7D and $C0-$FF.
the /ROMSEL (/CART) signal is still important to consider, so you don't conflict in bank $7F with Work RAM.

To be in that bank range, A22 is always 1. This is a problem for the reset vector, and interrupt vectors in general, upon powerup, which is at bank $00, of which A22 is obviously 0. So you can't care about A22 being low or high.

So this leaves you with A21...A20... etc.

The $FF:FFFF - $C0:0000 spans 0-$3FFFF, so 4 Megabytes (or 32 megabits might be more familiar).
If you had a quantity of 4 of 1 Megabyte chips, how would you wire up the 74139 decoder?

If you had only 2 of 1 Megabyte chips, how then would you wire it up, to be sure that the CPU still sees the reset vector at $00FFFC–$00FFFD from at one of the ROM chips?


(I'll stop here as I'll admit I don't know how to map the Save RAM into HiROM at this exact moment.)

I am using some multiplexers..... To essentially shift the rom addresses to the hi or lo positions A15-A22.

I think I have a good circuit (need to test) for the hi rom board using a 139.

Using 29F032 flash roms 1, maybe 2..... Not sure yet how many roms, maybe as much as 3 so star ocean can be run on it.


I'm away on vacation so I'm not able to test anything for a short while.
Got to unplug every now and then

Mark

One trick would be to only swap the ROM A15 pin for the upper address bit you need. It would require the rom data to be re-arranged to support though. Another solution would be to program the memory so that A15 is don't care. That would save you quite a bit from needing to shift 8 bits with a mux.

If you want one PCB that supports both Hi and Lo rom you could do it based on placement of the components, and avoid all the switching. Yeah you couldn't actively switch between the two on a single board, but you could do it with one PCB design.

I find two problems with your proposal:

* If you re-arrange A15 and make it the address bus's upper most bit, you would need 64Megs EPROM to make a 32 Meg LoROM game, seeing as A15 = '1' always in LoROM mode.

* You would have to mount two address decoder, since it's impossible to re-use the same 74LS139 footprint to enable the SRAM: to access SRAM in LoROM, /ROMSEL = '0' and in HiROM /ROMSEL = '1', besides the correct wiring for both configuration would need too much input lines for a 74LS139 alone.

I said ROM address pin A15, not SNES. Hi ROM connect ROM A15 to SNES A15, Lo ROM connect ROM A15 to the highest SNES pin you need. You're still ignoring SNES A15 when wiring to the rom address pins. The data would have to be programmed properly to allow for this rearrangement.




You missed my point, you would have a footprint for the Hirom version and a completely separate footprint for the Lorom version (but both on the same PCB). Depending where you placed the '139 would dictate what the board was. One PCB would give both Hi and Lo ROM, but once you soldered the '139 on it's 'stuck' as Hi or Lo. You'd need to assemble a second PCB for the other version. One PCB design for both Hi and Lo, not one assembled PCB for both.

I don't understand what you are trying to explain... I can't see it...





Ok, that makes sense XD

The point is address pin numbers really don't matter if you organize the data accordingly. You don't have to shift SNES A16-A21 to ROM A15-A20 to utilize those 6 address pins when A15 needs to be skipped on the SNES. You can keep SNES A16 connected to ROM A16, and so forth. You just don't connect SNES A15 to ROM A15 obviously, since SNES A15 is 'worthless' to the ROM. So you instead 'rename' the ROM A15 pin to something like ROM A21 and connect that directly to SNES A21. So you're still skipping A15 on the SNES, but instead of shifting every pin, you just move the A15 ROM pin to SNES A21. If you re-organize the data accordingly (or program the cart via the connector) then you don't care what the actual ROM address pin numbers are, (aside from address commands, you'd have to recalculate these)

Once you realize that you really don't have to care about the *number* of the address pin, and treat all address pins as equivalent you can grasp what I'm saying. The whole reason you're shifting all those pins is because you care about the number, stop caring about the number and you don't have to shift them.

Ah, ok, now I get your point. In fact, I do something like you describe here in both programs I made for my boards, but much less complicated than the way you say, because I only "shit" data from lower bits in EPROM data bus [15:0] to upper address space to use EPROM data bus [7:0].

Shitting meaningful data takes real talent

hello friends, before you get started I want to mention that there is a program that transforms rom low to high ("SnesConv")

Reading most of the forum, I can find more information and I have come to this scheme, (using most of the information in this thread and others) the numbers enclosed in square brackets refers to the cartridge pins



but I have several problems
not if it really works, my pic programmer still does not arrive, so I can not try, please, someone could verify that everything is properly connected to where it should go, I would appreciate any help forever, suggestions, among others.

doubts are marked with exclamation marks (?)
in BA6162
VCC OUT should to go a GND ?
BATT 3V is connected to the positive of the battery?

in SRAM
pin1 must conectarce to 5v or pin14?
pin 26 must be connected to A13 or should go to BA6162 pin 26





Finally, I recently learned basic electronics (Ohm law, Kirchhoff's law, etc..) Is not much, please someone, good person who could help

sorry for my bad English
regards


PS: ikari_01 Special thanks for their SuperCIC also thank you very much to Magno, getafixx, infiniteneslives, whicker, lidnariq, qwertymodo, MottZilla, Markfrizb for the help on MAD-1, among other important information in other threads

The BA6162 might be hard to find. I use a MAX795 or a STM795.

Why are you using a 256k SRAM? There are only a few games that use that size SRAM.

I haven't revisited the mad1 replacement with a max795+'139 yet as I have been finishing up other projects Snes related. I think Getafixx and Magno have been on the front line with actual hardware implementation.

hello friend thanks for answering

first clarify that the program called SnesConv truly transforms LowRom games in a HighRom game, I've tried several emulators and works correctly, the only disadvantage is that in a game it weighs 8 Mbits transforms to 16 Mbits as is the case with the game Contra III, however've tried it with Zelda A Link to the Past and does not work (Would have to test compatibility)

I'm using 256kb of SRAM by the fact that the cartridge be as generic as possible, and is compatible with most games that do not require special chip (FX, FX2, CAPCOM, etc.)

place the "BA6162" because I thought it was the only one who could replace the "Reset IC MM1026/6129A/6162", thanks for the tip
then "MAX795 or to STM795" should go well


I hope to find someone who can guide me

regards

Sorry for bumping an old thread but I would like to try my hand at one of these boards and was wondering if this schematic is accurate for a HiRom board? if not what changes need to be made?

hello everbody
think it should not work, since that is still in the testing phase, I need a programmer to accept a am29f032 to continue my research

I recommend to visit the bass's page

regards