SNES design questions for flash cart construction

[barawn]

Hi everyone:

After nearly taking a sledgehammer to my few remaining SNES games when they refused to work, and utterly sick of hacking apart games and replacing them with one-shot EPROMs, I've put my mind to actually building a SNES flash cart.

Yes, I know that tototek sells one for $70. No, I don't want theirs. For one, I don't know how it works, and for two, there are far more elegant ways to deal with a secondary chipset (like the DSPs or the SuperFX chips) than a T-connector. There are also extraordinarily cool things you can do if you think about it - if you look and see what's been done for the GBA, you get an idea. There's also the sick, sick possibility of having a CompactFlash socket, an old 72-pin SIMM socket (DRAM, because CF is too slow for direct access), and an FPGA on a cart, and having every game you own on one cart that never fails because you never remove it from the system.

I've currently got a design pretty far along that I think will work (well, if it doesn't, it's possible to *make* it work), but I have a bunch of questions. Emulator authors might actually know some of this stuff, which would help me a lot.

1) The SNES memory maps I have show the DSP, SuperFX, etc. as being at 0x3000-3FFF from banks 00-3F, but the DSP emulation page I found (http://users.tpg.com.au/trauma/dsp/dsp1.html) lists it as 00-1F:6000-7FFF in Mode 21, and 20-3F:8000-FFFF or 60-6F:0000-7FFF in Mode 20, depending on the size. Which one's right? I'm not too thrilled about having to map the DSP into ROM memory space (20-3F:8000-FFFF) depending on the game size. It's just another flipflop and a few logic gates, and there should be enough space left in the PLD for it, though, so maybe it isn't that bad.

2) Is there any similar documentation about the SuperFX's memory map?

3) Has anyone else ever tried to hook up DRAM to a SNES to act as ROM? The old game copiers usually looked like they had DRAM and a floppy drive/CD-ROM/whatever. The only issue I can think of is the refresh cycles - as there's no way to tell the SNES "wait a second, the data will be there in a moment" as far as I can tell. I was thinking you could probably key off the system clock and either a) do a refresh if no ROM access occurs or b) do a hidden refresh cycle if a ROM access occurs. With that, the DRAM refresh should be hidden pretty effectively. What happens during the WRAM refresh period? i.e., can the processor access the ROM during the WRAM refresh? If not, I can just key off of the WRAM refresh interval and use that if it's frequent enough.

4) What happens when the SNES accesses regions that aren't "internal" in most memory maps, but are not standard ROM areas? Does it still generate a bus cycle, or does it need to be enabled somehow? I'm wondering because I'm wondering if I can use those areas for "extension" modules (like the CF card) that I'll build support for in the bootloader. Also, I don't suppose there's any way to alter the bus cycle timing (insert wait states, etc.)? I didn't see anything like that in the register documentation, so I'm guessing it's limited to the Slow and Fast access modes.

Right now, the design actually looks like it might be pretty cheap (~$60-70). I think I found a sleazy way of getting the flash chips for very cheap - there's a JEDEC standard flash SIMM that Cisco routers use, and an 8MB part is *really* cheap on eBay (as low as $7.50). With a tiny bit of hacking, it should be relatively easy to turn it into a 64Mb x 8 part by wiring the 4 bytes of the data bus together and using the 4 Chip Enable lines on the JEDEC standard as individual chip selects, along with a '138 decoder. The 80-pin SIMM connector is samplable from Molex, and is cheap anyway.

Plus, I can always reuse the flash module for another gaming system (like, oh, the Genesis), so it's perfect.

It is possible (though it would be *hell*) to breadboard out the design as well, since you can get all of the parts in a DIP package, which would pull it down to the cost of parts ($20-30!). I'm not that psychotic, so I'll burn the money for the board.

Anyway, if anyone's interested in helping, I'd be grateful as well. I can handle the hardware hacking no problem, but the software's going to take me some time to learn. If there are any experienced SNES assembly guys, it'd be a great help writing the bootloader and any extensions that I might need. I could probably handle it on my own, but it would probably be extremely kludgy and ugly.

I *really do* plan on building this, incidentally. The code for the PLD which does the address translation is pretty much done (lacking any 'extension' or 'support for whacko ROMs' support) and I'm trying to layout the board now. It's a fairly crowded board, and I'm trying to do it in two layers, so it's taking a bit, but it'll get done.

[anomie]

Sounds interesting. Don't know how feasible, but interesting.

1) The SNES memory maps I have show the DSP, SuperFX, etc. as being at 0x3000-3FFF from banks 00-3F, but the DSP emulation page I found (http://users.tpg.com.au/trauma/dsp/dsp1.html) lists it as 00-1F:6000-7FFF in Mode 21, and 20-3F:8000-FFFF or 60-6F:0000-7FFF in Mode 20, depending on the size. Which one's right? I'm not too thrilled about having to map the DSP into ROM memory space (20-3F:8000-FFFF) depending on the game size. It's just another flipflop and a few logic gates, and there should be enough space left in the PLD for it, though, so maybe it isn't that bad.

Basically, the cart can 'see' every memory access the S-CPU makes. It is expected not to respond to those that the internal circuitry (PPU, APU, CPU registers, WRAM). So a game coule well put ROM into $3000-$3FFF in banks $00-$3F and use $00:8000-$FFFF for a DSP if it really wanted to. Certain chips (SA-1, S-DD1, and SPC7110 come to mind, but that may be incorrect) provide the ability to map different ROM banks into various portions of the memory map like most NES games do, and it appears the SA-1 will even allow the game to change the NMI and IRQ vectors on the fly (normally this is ROM). And conversely, note that many games will try to write to ROM as a copy-protection measure, and will check that SRAM is mirrored as they expect...

The only reason things are mildly sane is that most games use the MAD-1 chip to map memory, which gives you what you'll find in many "memory map" documents. And most of the rest implement a map more-or-less similar to the MAD-1's for whatever reason.

What happens during the WRAM refresh period? i.e., can the processor access the ROM during the WRAM refresh? If not, I can just key off of the WRAM refresh interval and use that if it's frequent enough.

Well, the processor is halted for 40 master cycles every scanline, which we've theorized is the WRAM refresh period. Presumably during this time you can see a signal on cart connector pad 33 ("REFRESH"). So it's 40 cycles for refresh, then 1320 or 1328 (usually alternating) for execution.

4) What happens when the SNES accesses regions that aren't "internal" in most memory maps, but are not standard ROM areas? Does it still generate a bus cycle, or does it need to be enabled somehow?

There are two address busses: Address Bus B handles $2100-$21FF in banks $00-$3F and $80-$BF, and Address Bus A handles everything else. In either case, the cart can see every access on every address bus, and (except maybe the $4000-$437F registers) it can even spy on whatever gets returned over the data bus. Anything not mapped internally is fair game for the cart to respond to. It seems the cart can even respond to a read on what is otherwise a write-only register, considering certain breakage on UFO copiers...

Also, I don't suppose there's any way to alter the bus cycle timing (insert wait states, etc.)? I didn't see anything like that in the register documentation, so I'm guessing it's limited to the Slow and Fast access modes.

Nope. The S-CPU sets the access times, about the best you could do would be to try to hold the clock signal to pause the processor. The usual route seems to be having the ROM send a command then poll a 'ready' bit. Or the IRQ line is exposed on the cart connector, but I don't know if that means the cart can cause an interrupt or just watch for them.

Remember, Slow versus Fast only applies to $8000-$FFFF in banks $80-$BF and all of banks $C0-$FF, everything else is 6, 8, or 12 master cycles regardless of the setting. I suppose if you respond to anything in 6 then you're safe for 8 or even 12.

[barawn]

Sounds interesting. Don't know how feasible, but interesting.

Well, the only "iffy" part is the flash SIMM, and I still need to order that. Right now the PLD code works in simulation, so the address remapping at least works. That's not a problem. The board is fully layed out, though I have one issue in that I don't know which SNES connector pad is /CS and which is /OE. I saw on fruity site (CR) that The Dumper mentioned that those two typically get reversed... in siudym's documentation, "/CE" goes to ROM /CE and RAM /OE, which seems wrong (that would be an /OE line, not a /CE line, as /OE and /CE for a ROM are the same thing), whereas "/OE" either goes to the ROM's /OE or the address decoder, which seems like a sane thing for "/CE" to do.

And conversely, note that many games will try to write to ROM as a copy-protection measure, and will check that SRAM is mirrored as they expect...

Yah, I had read about both of those copy protections. Luckily it's not easy to compensate - I'll just qualify the ROM chip select (CS_ROM - this is what the MAD chip puts out) off of /WR. A write means no CS, which means no luck for them.

How many SRAM sizes are there out there? I've only seen 32K and 256K (for DOOM and Mario Paint, if memory serves) If I only need to support two RAM sizes, then RAM mirroring is trivial. If I need to support a half-dozen, then that's a pain.

The only reason things are mildly sane is that most games use the MAD-1 chip to map memory, which gives you what you'll find in many "memory map" documents. And most of the rest implement a map more-or-less similar to the MAD-1's for whatever reason.

Ah ha. That makes sense. Well, right now I've got the MAD-1's memory map implemented, then, with all the correct mirroring. I might have to tweak things on a per-game basis, but I might even set up the board so that it can reflash the address decoding PLD if it runs into a really screwed up game.

Well, the processor is halted for 40 master cycles every scanline, which we've theorized is the WRAM refresh period. Presumably during this time you can see a signal on cart connector pad 33 ("REFRESH"). So it's 40 cycles for refresh, then 1320 or 1328 (usually alternating) for execution.

Bleah, that's not quick enough for an external DRAM refresh. OK, so for DRAM I'll need to sneak in refreshes when the processor's not accessing.

That'll take some work. I wonder how the copier systems do it. Hmm.

There are two address busses: Address Bus B handles $2100-$21FF in banks $00-$3F and $80-$BF, and Address Bus A handles everything else. In either case, the cart can see every access on every address bus, and (except maybe the $4000-$437F registers) it can even spy on whatever gets returned over the data bus. Anything not mapped internally is fair game for the cart to respond to. It seems the cart can even respond to a read on what is otherwise a write-only register, considering certain breakage on UFO copiers...

OK, good, then I'm doing the right thing by only enabling the ROM in the portions of the address space that a MAD chip normally enables or the chip is wired to.

Coming from a world where address spaces are very rigorously separated, this didn't make a whole lot of sense to me. Thanks a lot!

As a bonus, this means I can map *gigantic* amounts of memory into the SNES's address space for use in the bootloader. Terrific!

[anomie]

though I have one issue in that I don't know which SNES connector pad is /CS and which is /OE. I saw on fruity site (CR) that The Dumper mentioned that those two typically get reversed... in siudym's documentation, "/CE" goes to ROM /CE and RAM /OE, which seems wrong (that would be an /OE line, not a /CE line, as /OE and /CE for a ROM are the same thing), whereas "/OE" either goes to the ROM's /OE or the address decoder, which seems like a sane thing for "/CE" to do.

Hrm... Unfortunately, my docs don't use "/OE", "/CS", or "/CE".

If "/OE" means "/RD", i have that on pad 23. Pad 49 i have labeled as /CART, which gets set for accesses to the "traditional" ROM areas, I suppose this could be called "chip select" or "/CS"? There's also /WRAM on pad 32, which is set when the SNES is accessing WRAM.

Yah, I had read about both of those copy protections. Luckily it's not easy to compensate - I'll just qualify the ROM chip select (CS_ROM - this is what the MAD chip puts out) off of /WR. A write means no CS, which means no luck for them.

Nifty. BTW, how are you planning to handle the CIC lock?

How many SRAM sizes are there out there? I've only seen 32K and 256K (for DOOM and Mario Paint, if memory serves) If I only need to support two RAM sizes, then RAM mirroring is trivial. If I need to support a half-dozen, then that's a pain. :)

It'll probably be a pain. While it could always be lying, there's a byte in the internal "header" that can choose from 0, 16 kilobit, 32 Kb, 64, Kb, and so on. And yes, there are ROMs with 0 that require the MAD-1 "SRAM" areas to be unmapped to pass copy-protection checks.

Bleah, that's not quick enough for an external DRAM refresh. OK, so for DRAM I'll need to sneak in refreshes when the processor's not accessing.

What frequency does an extrenal DRAM require?

OK, good, then I'm doing the right thing by only enabling the ROM in the portions of the address space that a MAD chip normally enables or the chip is wired to.

Coming from a world where address spaces are very rigorously separated, this didn't make a whole lot of sense to me. Thanks a lot!

PM me an email address if you'd like a copy of what docs I have on the memory mapping.

[barawn]

If "/OE" means "/RD", i have that on pad 23. Pad 49 i have labeled as /CART, which gets set for accesses to the "traditional" ROM areas, I suppose this could be called "chip select" or "/CS"? There's also /WRAM on pad 32, which is set when the SNES is accessing WRAM.

Yah, that's what I was using as a /CS. What do you have as pin 54? It's /WE on most of the docs I've seen. It's what's connected to the /WE on SRAM.

Brief explanation of an SRAM-style interface: you typically get either 2 or 3 control signals. One is a chip select (CS, or chip enable, CE), one is a write enable (/WE) and one is a read enable (/RD, or output enable, /OE). On newer chips /OE and /WE are combined into a R/~W (read, not write) line, as you can't read and write at the same time.

Hmm. Seems like I was thinking a bit too traditional on this. Let me see if I can figure this out:

1: Read from ROM address: /CART goes low, /OE goes low /WE stays high.
2: Write to ROM address: /CART goes low, /OE stays high, /WE goes low.
3: Read from any other address: /OE goes low, /WE stays high.
4: Write to any other address: /OE stays high, /WE goes low.

Is this right?

Well, if that's true, then I can take the easy method of ignoring /CART, and just using /OE as my /CS for the ROMs, and using a NOT-ed /WE as my /OE for the ROMs. Ooh, and I've already got an inverter right by the connector, too! The ROMs will be protected from writes so long as /OE and /WE never go low at the same time, and if their CS is generated by
(!/OE & /WR), that's guaranteed. (Obviously I'll have to do something else for the bootloader code, when I want to *program* the flash, but I'll think about that later. I might even have an extension board program the flash by itself, and just use the SNES for a GUI.)

I can then create the /CS for the SRAM by (!/OE or !/WE) along with an address qualifier. I'm amazed that bad things didn't happen on an original SNES which just created a /CS for SRAM based on address timings. There must've been tons of glitches on /CS. I wonder if people occasionally lost save games on Super Mario World (which used a purely address-based /CS using an 74LS139).

Nifty. BTW, how are you planning to handle the CIC lock?

Two ways (well, one right now, but I need to implement the second one) - you can either cannibalize an old cart for a CIC chip, which is really easy, or plug in a cart on an extension board which will pass the CIC pins along.

Honestly, cannibalizing an old cart is cheap and easy. I just bought 2 SNES carts for $0.50/each, and the CIC chips are DIP pins. DIP chips are simple to desolder if you don't care about the board. Ignore all the tutorials you've seen online - the easiest way is to just take a hacksaw to the board. Cut out around the chip, cut down the middle of the board under the chip, then cut out between each pin (diagonal cutters will work well for that part). Then you can just run a soldering iron along each pin, and poof, off comes the chip.

The problem most people have with desoldering DIP parts is the fact that they think they need to remove all of the solder in order to get the part off. That's true, but only if you care about the board. Desoldering each individual DIP leg is easy. It's the fact that they're all connected to a board that makes it difficult.

Of course, there are also guidelines on the Web on how to disable the CIC chip on the SNES altogether just by lifting pin 4 of the CIC chip onboard the SNES.

I guess if I get really silly in the future I could try to emulate the CIC chip itself, but that's a) difficult, and b) DMCA-dangerous, even though I think I'm safe on that one as it was developed pre-DMCA.

t'll probably be a pain. While it could always be lying, there's a byte in the internal "header" that can choose from 0, 16 kilobit, 32 Kb, 64, Kb, and so on. And yes, there are ROMs with 0 that require the MAD-1 "SRAM" areas to be unmapped to pass copy-protection checks.

Well, that might not be so bad. I'll have to see how much space an 8-bit latch takes up. I'm hoping not to cross into the 128MC size until I need DRAM.

What frequency does an extrenal DRAM require?

Depends on the density of the DRAM, actually. But as a ballpark...

Typically, you need 2048 CAS-before-RAS cycles every 128 ms. Doesn't matter if you do them all at once or spread out over a bunch, but obviously 40 clock cycles isn't enough to do 2K CAS-before-RAS cycles.

For 60 ns DRAM (which you'll find in old, good quality 72-pin SIMMs):

Read cycle is 110 ns, and a CAS-before-RAS cycle is 100 ns.

Hmm, I thought the CBR cycle was longer. Hmm. I wonder - if I get the data back in ~225 ns, is that fast enough? I think it might be. You said 6 clock cycles is the fastest? That's 279 ns.

OK, easy enough. Just key the refresh off of the master clock. If a cycle happens during that clock, there's still enough time for a refresh to occur, followed by a normal access.

Well, that makes my life easier for the next version!

Oh, you mentioned that some areas are 12-cycle waits? Which ones are those?

[anomie]

What do you have as pin 54? It's /WE on most of the docs I've seen. It's what's connected to the /WE on SRAM.

I have it as "/WR", sounds like the same thing. "Write" versus "Write Enable" or something like that.

1: Read from ROM address: /CART goes low, /OE goes low /WE stays high.
2: Write to ROM address: /CART goes low, /OE stays high, /WE goes low.
3: Read from any other address: /OE goes low, /WE stays high.
4: Write to any other address: /OE stays high, /WE goes low.

Is this right?

For reads/writes to WRAM areas ($0000-$1FFF in banks $00-$3F and $80-$BF, and all of $7E and $7F), /WRAM goes low. /WRAM is pad 32, BTW. The internal WRAM of course responds to all these addresses, so about all you'd need is to make sure you never respond to those addresses. Otherwise, it sounds right to me.

I'm amazed that bad things didn't happen on an original SNES which just created a /CS for SRAM based on address timings. There must've been tons of glitches on /CS. I wonder if people occasionally lost save games on Super Mario World (which used a purely address-based /CS using an 74LS139).

Couldn't say.

I guess if I get really silly in the future I could try to emulate the CIC chip itself, but that's a) difficult, and b) DMCA-dangerous, even though I think I'm safe on that one as it was developed pre-DMCA.

Pre-DMCA doesn't help you, I think.

Oh, you mentioned that some areas are 12-cycle waits? Which ones are those?

$4000-$41FF in banks $00-$3F and $80-$BF. There are only 2 (known) internal CPU registers in that whole region, at $4016 and $4017, everything else reads open bus.

[adventure_of_link]

I guess if I get really silly in the future I could try to emulate the CIC chip itself, but that's a) difficult, and b) DMCA-dangerous, even though I think I'm safe on that one as it was developed pre-DMCA.

Let me ask some questions:
1. the CIC-chip is AKA the Region Lockout chip, right?
and 2. How is emulation of a CIC chip a DMCA danger?

[barawn]

I guess if I get really silly in the future I could try to emulate the CIC chip itself, but that's a) difficult, and b) DMCA-dangerous, even though I think I'm safe on that one as it was developed pre-DMCA.

Let me ask some questions:
1. the CIC-chip is AKA the Region Lockout chip, right?
and 2. How is emulation of a CIC chip a DMCA danger?

The CIC chip is also a copy-protection device. It guarantees that I can't make a working copy of Super Mario World and sell it.

If I emulate the CIC chip, I'm circumventing a copy-protection device. That's DMCA dangerous, in my mind.

[adventure_of_link]

Oh, ok then, thanks barawn. I didn't think SNES'es featured copy protection.

[barawn]

OK, I'm very confused now.

According to the SNES-Kart documentation, /RESET goes low on a ROM area read.

I had figured that /RESET was a hard-reset line. I was also hoping there was a soft reset mechanism as well, but I haven't been able to find it.

Does /RESET go low on a ROM area read? Does anyone know? Also, is there a way to trigger a soft SNES reset?

Otherwise, I need to figure out a way to start a cartridge after one has already started. If anyone's got any ideas, I'd be grateful. I'd imagine it might be just as simple as jumping to a boot address in ROM, but there might be some initialization that I don't know about.

[anomie]

I had figured that /RESET was a hard-reset line. I was also hoping there was a soft reset mechanism as well, but I haven't been able to find it.

/RESET is a reset output. The only input comes from the switch on the front of the SNES.

Otherwise, I need to figure out a way to start a cartridge after one has already started. If anyone's got any ideas, I'd be grateful. I'd imagine it might be just as simple as jumping to a boot address in ROM, but there might be some initialization that I don't know about.

Unfortunately, it's not easy. Basically, you must manually reset everything that needs resetting, then swap ROM images and jump to the address pointed to by the word at $00:FFFC. Another idea would be to display a "Please press RESET to begin play" message, swap ROM images, and STP.

The list of things needing resetting includes: all CPU registers, the MXDI&E flags, probably many PPU and CPU registers, and probably WRAM, VRAM, OAM, and CGRAM (and not to 0 necessarily). Going the STP route will take care of some but not all of these.

In either case, you could be really tricky and map some registers in the $00:21XX range that return $DB (STP) or $6C $FC $FF (JMP ($FFFC)), and as a side effect disable the boot ROM (and these magic registers, in case some ROM depends on them being unmapped). Kind of like how $2137 as a side effect latches the PPU's H/V Counter.

[barawn]

/RESET is a reset output. The only input comes from the switch on the front of the SNES.

OK, that's not a problem. Do you know if it's a real /RESET output - that is, it goes low when the cartridge is reset, and only then? The SNES-Kart documentation seems to suggest it goes low on every ROM access, which seems very bizarre... and makes it not a /RESET.

Unfortunately, it's not easy. Basically, you must manually reset everything that needs resetting, then swap ROM images and jump to the address pointed to by the word at $00:FFFC. Another idea would be to display a "Please press RESET to begin play" message, swap ROM images, and STP.

The list of things needing resetting includes: all CPU registers, the MXDI&E flags, probably many PPU and CPU registers, and probably WRAM, VRAM, OAM, and CGRAM (and not to 0 necessarily). Going the STP route will take care of some but not all of these.

In either case, you could be really tricky and map some registers in the $00:21XX range that return $DB (STP) or $6C $FC $FF (JMP ($FFFC)), and as a side effect disable the boot ROM (and these magic registers, in case some ROM depends on them being unmapped). Kind of like how $2137 as a side effect latches the PPU's H/V Counter.

Thanks for the 00:FFFC information. I had been trying to look for that before and never found it. Processors often start from the last word in their address space, but I'm glad to confirm it.

Actually, the "jump to an address, have it return JMP FFFC and disable the bootloader" is a great idea, though I'll store the JMP FFFC in the boot ROM, and have the logic PLD just watch for the address. Better than what I was planning on doing, which was loading a portion of the boot ROM into RAM and executing from there - which I have no idea if it would even work.

Is there a decent description of the SNES's initial state somewhere?

Incidentally, the SRAM masking turned out to be easier than I thought. Should be able to select from 16 kbit SRAM to 1 Mbit SRAM. I don't think any game uses more than 256kbit.

[anomie]

OK, that's not a problem. Do you know if it's a real /RESET output - that is, it goes low when the cartridge is reset, and only then? The SNES-Kart documentation seems to suggest it goes low on every ROM access, which seems very bizarre... and makes it not a /RESET.

I highly doubt it's weird like that. The reset switch connects into the CIC chip, which 'holds' reset to the reset to the rest of the system until it finishes validating the CIC in the cart. The CIC's reset output goes to S-PPU2, which has two reset outputs: one to S-PPU1 and one to everywhere else, including the cart connector and the expansion port. I don't see how it would go low every ROM access, maybe it's talking about /CART?

Thanks for the 00:FFFC information. I had been trying to look for that before and never found it. Processors often start from the last word in their address space, but I'm glad to confirm it.

Actually, the "jump to an address, have it return JMP FFFC and disable the bootloader" is a great idea, though I'll store the JMP FFFC in the boot ROM, and have the logic PLD just watch for the address. Better than what I was planning on doing, which was loading a portion of the boot ROM into RAM and executing from there - which I have no idea if it would even work.

It would work, and probably wouldn't even cause too much trouble.

Is there a decent description of the SNES's initial state somewhere?

Not really, even we don't know it that well. About the best you could do would be to look at what ZSNES, snes9x, and other emulators do, unless you want to go so far as to load test ROMs onto a real SNES to read off the various parameters (you're actually fairly well equipped to do so, the rest of us mostly use copiers which will reset the SNES to their own idea of the right values).

[barawn]

It would work, and probably wouldn't even cause too much trouble.

Well, the problem is doing the assembly language coding to handle all of that is fairly awful, and a bit beyond me right now.

It looks like I'm going to need to figure out how to do it, though, as there are a few tricks I want to do which will require it. For instance, I'll need to read the header to extract the name and HiROM/LoROM/SRAM size information for each game. But to do that, I'll need to map *them* into the cartridge's ROM space, which means the bootloader code is unmapped. Once it's done reading that info, it'll remap the bootloader into the ROM space. This, of course, isn't a problem if that code is running in RAM, but I don't really understand how to handle that yet.

The first bootloader will probably just have a stupid menu which chooses between BOOT ROM1, BOOT ROM2, BOOT ROM3, and allows you to change HiROM, LoROM, and SRAM size info without reading it from the cartridge, and then as I get better, things'll improve.

But first I need to get it built. Oh well, parts are on the way. Unfortunately I needed to switch PLD versions (Xilinx PLDs give you two extra I/O pins! Ah, thank God!) and the software for that is fairly awful.

[anomie]

This, of course, isn't a problem if that code is running in RAM, but I don't really understand how to handle that yet.

Just copy the relavent code into RAM and JML to it. You could use DMA something like this:

Code: Select all

        rep #$10     ; set X and Y registers 16 bits
        sep #$20     ; set A register (and STZ) 8 bits

        ldx #$0000   ; point register $2180 (WRAM access) at $7f:0000
        stx $2181    ; (reading/writing $2180 accesses the WRAM address
        lda #$7f     ;  pointed to by $2181-3, and incs that address)
        sta $2183

        lda #$00     ; Set up DMA to copy it:
        sta $4300    ; DMA Mode 0, regular increment
        lda #$80
        sta $4301    ; DMA into register $2180
        ldx #Code_Start
        stx $4302    ; Copy from the address Code_Start in ROM
        lda #Code_Bank
        sta $4304    ; in ROM bank Code_Bank
        ldx #Code_Len
        stx $4305    ; Copy Code_Len bytes
        lda #$01
        sta $420b    ; Do the transfer

        jml $7f0000  ; and jump to the code!

Then just make sure your code at Code_Start is compiled expecting an origin of $7f:0000. Or change the value written to $2181-3 to copy it beginning at whatever origin you wish.

BTW, if you want to map registers into the $21xx range and you haven't figured this out yet: The 'xx' part is 8 bits: PA0-PA7 are pads 28, 59, 29, 60, 30, 61, 3, and 34. /PARD is pad 4, and /PAWR is pad 35 (if neither are asserted, then the access is probably over the normal address bus and PA0-PA7 are probably invalid). The data bus is the same as for the normal address bus (this is how SNES DMA works BTW: the SNES sets one address on PA0-PA7 and another on A0-A23, tells one RD and the other WR, and the shared data bus handles the rest). $00-$83 are mapped by the SNES, so you should only use $84-$FF. Be sure to ignore everything on the registers once you start the loaded ROM, or you may break things (see UFO copiers for example).

[talesrom]

if you need some hardware informations about FLASH/EPROM cartridges for SNES, visit: http://nintendoallstars.w.interia.pl/romlab/romlab.htm (www.romlab.prv.pl)

great eprom burner: www.willem.org (cost about 20-40$)