Having issues with LoROM PCB's

Last summer, I built myself a few of these FlashROM modules with the hope of converting a couple of donor carts into simple dev carts. I built one on a HiROM board (SHVC-1J3M-11) that works fine, but I can't for the life of me get a LoROM board to so much as boot. Right now, I'm trying an example from PvSNESLib, which I had previously modified to run on my HiROM board, so I know the ROM is good, but it just doesn't boot. I've built 3 different LoROM boards (SHVC-1A3B-13, SHVC-1A3M-11, SHVC-1A3M-30), and none of them work. I've even tried flashing the original game ROM to the cart, and even that won't boot. Can anybody think of any reason why none of my LoROM boards will boot? Should I be doing something different with the ROM before flashing? I've tried mirroring the ROM to fill out the full 32Mbit chip or just flashing it directly, and it doesn't seem to make any difference. I'd really like to get these LoROM boards working, but I'm just kind of at a loss right now...

Let's start with some of my assumptions:

1) This is essentially a daughterboard that plugs into where the maskrom normally is on the cartridge. You are using donor boards that have only one mask rom chip.

2) You just load a (headerless) rom image onto the flash chip with no trickery involved. Just a straight copy in regards to A0..A22 on the flash chip.

3) You let the board's address decode circuitry decide what to do with A15 and beyond coming from the SNES CPU, in regards to how it generates the \CE and \OE signals.

4) If the spot for the chip is the smaller (shorter, less pins) version of the maskrom chip, you are tieing or pulling down these most significant address lines low (not leaving them floating) on your daugterboard (in relation to the flash chip).


Are any of these assumptions incorrect? Which of these are incorrect, and how should they be stated as to what you have?

1) Yes, all of my donor boards are single maskROM boards

2) Yes, the ROMs are headerless and I just load them directly. I have tried mirroring the ROM to the upper banks just in case an open bus on the donor board was to blame, but I didn't interleave the ROM or any other trickery.

3) The 29F032B is wired up to the maskROM pins just the way you'd expect if the rest of the circuitry was removed, everything else on the daughterboard simply connects a microcontroller to the address and data lines for in-circuit programming. So no address re-mapping or anything of the sort.

4) All of the donor boards I've used have had the full 36-pin footprint, so I have connected all of the pins. I can't confirm whether or not the upper address lines are actually connected to anything on the donor board (some smaller games will leave these open bus), but I typically mirror the ROM to the upper address banks anyway (e.g. testing the SHVC-1A3M-30 board using a Zelda:LttP ROM, I just copied the ROM 4 times since it's 1MB).

Is your pin 35 (a22) connected? If so, you might try floating that pin or grounding it....


Mark

A22 isn't connected to anything on the daughterboard. I tried grounding it, but no change. I'm kind of grasping at straws here, and I'm a bit tired, but it wouldn't have anything to do with LoROM not having A15 connected, would it? That happens before the address decoder, right? The maskROM pinout shouldn't be affected by it, should it?

What decoder are you using? Mad1 or something else?

Depends on the board, I have 3 of them. The 1A3M boards use a MAD-1, the 1A3B boards don't (139? I don't have them in front of me at this moment...)

If you game rom is bigger than 8 megbits, then it wouldn't work on the 1A3"B" boards....

Otherwise, it should work on the 1A3"M" carts up to 32mbits..... But

Have you verified that just a regular rom works on that cart? Sometimes the traces break right at the solder pads where the mask rom mounts.

You're exactly correct that in regards to how A15 works. The mask rom chip itself isn't aware of any addressing gap, and the existing decoder and LoROM or HiROM wiring handles where the SNES CPU sees the data in its memory space.


I too am at a loss as to what could be wrong. It should work based on everything you're doing.

1) Since you have other circuitry onboard, is all of it in the HI-Z state when being powered from the SNES? I see you have the address lines taken care of. How does this "HWB" exactly work? Are you forcing it high or low, or are you relying on software in the ATMEGA chip to set it high or low?

2) Just humor me. When the SNES powers up with this cartridge in, the ATMEGA chip also powers up. What does it try to do when it powers up? Could something unintended be happening with PB0..PB7 to mess up the SNES's data bus? Same thing with or PC6 or PE6. Do some pins start as outputs that later get set to inputs?**

** I'm specifically wondering about MOSI (PB2) that is also tied to D2 of the data bus.

3) Does "AVR Reset" need pullup or pulldown?

Your schematic shows you've thought about this stuff, but maybe look at what the microcontroller should or shouldn't be doing and see if that matches reality.

EDIT 4) OH! What's going on with \WE and \RESET on the flash chip??? Are these guys getting pulled up to +5V? if the AVR is doing it, there's obviously a delay time. You'd be better off with some resistor pullup in the long run.

One thing I'd like to mention is that I've had exactly the same issues with a straight AM29F032 adapter board from BuyICNow on LoROM boards (1A3M-30 I believe), which is weird...

1) I'll have to look at the code to see what the Atmega pins are doing, I believe the octal latches are Hi-Z when they aren't in use, but that would be up to the code also. HWB is an I/O pin that is used as an output in this design, with a pull-up resistor (don't remember off the top of my head what it's being used for). However, it also has a special use in that if it's held low during reset, the AVR executes its bootloader code rather than the normal code. The bootloader can be used to reprogram the AVR over the USB interface. However, because of the external pull-up, it won't be low during reset unless intentionally pulled low.

2) I'll have to read the code to answer that. However, it's weird, because as I've said, my HiROM boards have no issue with this daughterboard.

3) I'm pretty sure the AVR_RESET has an internal pull-up. In any case, the pin is active-low, so it would need to be held high in order to operate correctly.

4) I assume they rely on the microcontroller for pull-ups, again, I'd have to check the code. I'll see if I can pull them high manually and see if that helps.