byuu's message board

For discussion of projects related to www.byuu.org/


Previous  1, 2
Trying to write to Cx4 ROM from the cart edge 
Author Message

Joined: Wed 09 Feb 2011, 13:29:34

Posts: 425
Post Re: Trying to write to Cx4 ROM from the cart edge
So higan will soon add a new step to the emulation world?

Wed 18 Dec 2013, 14:46:58
User avatar

Joined: Sat 01 Dec 2012, 01:50:23

Posts: 240
Location: Oregon, USA
Post Re: Trying to write to Cx4 ROM from the cart edge
higan already supports the Cx4, I'm pretty sure byuu just wants to test out features of the chip that aren't used by the 2 games that included it in order to fully emulate the chip, even though he has currently emulated all functions actually used by those 2 games.

Wed 18 Dec 2013, 19:05:29

Joined: Wed 09 Feb 2011, 13:29:34

Posts: 425
Post Re: Trying to write to Cx4 ROM from the cart edge
That was my point : accurate emulation everywhere, even where it is not needed. ^^

Wed 18 Dec 2013, 19:42:57
User avatar

Joined: Tue 02 Nov 2010, 01:00:37

Posts: 181
Post Re: Trying to write to Cx4 ROM from the cart edge
qwertymodo wrote:
Even better, pin 27 on the Cx4 seems to be the actual /CE signal.


Congrats. However, don't you think it's a bit weird that they'd have a dedicated #ROM_WE and #ROM_CE? I mean, this sounds like they planned for writable ROM space, something I haven't seen in GB cart at all.

cYa,

Tauwasser

Wed 18 Dec 2013, 20:06:47
User avatar

Joined: Sat 01 Dec 2012, 01:50:23

Posts: 240
Location: Oregon, USA
Post Re: Trying to write to Cx4 ROM from the cart edge
I don't think it's a dedicated ROM /WE, it's just a /WE signal that happens to assert in the ROM address space. byuu has indicated that the Cx4 should support SRAM, so my guess is that it was intended for the SRAM /WE, and we're just lucky enough that it isn't disabled in the ROM address space, most likely because the /CE signals control the address decoding, so there's no need to waste extra logic on decoding the /OE and /WE signals, so they simply track the cart edge /RD and /WR signals. I have not yet confirmed this, but now that I have my PC<->cart interface working nicely, I'll probably set up my spare RMX2 cart for logic probing and start poking around with different read/write commands in various address spaces and see if I can't figure out the last few unknown pins (at least, I hope I can find the SRAM /CE signal, then maybe I can build a custom Cx4 cart with 2 Flash ROM chips and 1 FRAM chip, along with proper test points for any remaining unknown signals, so I don't have to keep tapping chip pins with 30AWG wire-wrap wire to hook up the logic analyzer...

Wed 18 Dec 2013, 22:13:08

Joined: Fri 10 Apr 2009, 15:00:08

Posts: 13668
Post Re: Trying to write to Cx4 ROM from the cart edge
It would have been very amusing had they introduced a SRAM chip in a Cx4 game, and writes to ROM ended up enabling and writing to the SRAM chip.

But I imagine they might have fleshed that out more, possibly with another 74LS chip thrown in there or something, had they decided to make such a board.

Wed 18 Dec 2013, 22:17:13
User avatar

Joined: Sat 01 Dec 2012, 01:50:23

Posts: 240
Location: Oregon, USA
Post Re: Trying to write to Cx4 ROM from the cart edge
byuu wrote:
It would have been very amusing had they introduced a SRAM chip in a Cx4 game, and writes to ROM ended up enabling and writing to the SRAM chip.

But I imagine they might have fleshed that out more, possibly with another 74LS chip thrown in there or something, had they decided to make such a board.

Not so long as the SRAM /CE line is held high when the address is mapped to the ROM. That's the point of the /CE signal. /OE and /WE just indicate whether it's a read or write operation, then the /CE signal selects which chip is actually supposed to respond to that operation. So if you have 2 ROM chips and 1 SRAM chip, they should all have their /OE and /WE signals connected together, and then each have their own separate /CE signal. However, Nintendo realized that for true, read-only operation, it didn't matter if you swapped /OE and /CE, and I've noticed that they do so on "normal" MAD-1 carts almost always. In this instance, with only a single chip, there's no need for a /CS signal, so all reads go to the ROM, hence why the ROM /OE pin is connected to Gnd, and the /OE signal is driving the ROM /CE. They could've grounded the ROM /CE instead and connected the /OE signal to the /OE pin, but maybe the tracing was easier this way... who knows.

Wed 18 Dec 2013, 22:27:52
User avatar

Joined: Tue 02 Nov 2010, 01:00:37

Posts: 181
Post Re: Trying to write to Cx4 ROM from the cart edge
I would have assumed that #WE and #OE don''t just simply track the cart edge. After all, it seems like the co-processor is meant to be able to read ROM data on its own, else it wouldn't need to have the full address bus attached to it.
GB MBCs generally only feature the full address bus when they need to be able to remap every address in it. For instance the GB Camera's MAC-GBD does that for SRAM, presumably because it needs to DMA the captured picture to SRAM. That will also be the reason why I'm unable to dump the ROM, because the MAC-GBD apparently decides after some reads that deasserting #ROM_CE is really cool.
So I'm kind of wondering why your #CE would be asserted for write cycles to ROM. This might run the risk of enabling two chips at the same time, which I think the Cx4 should be interested in avoiding...

qwertymodo wrote:
at least, I hope I can find the SRAM /CE signal, then maybe I can build a custom Cx4 cart with 2 Flash ROM chips and 1 FRAM chip, along with proper test points for any remaining unknown signals, so I don't have to keep tapping chip pins with 30AWG wire-wrap wire to hook up the logic analyzer...


Are you able to look at all (presumed) output pins at the same time, or are you limited to 8 at a time?

cYa,

Tauwasser

Wed 18 Dec 2013, 23:58:55
User avatar

Joined: Sat 01 Dec 2012, 01:50:23

Posts: 240
Location: Oregon, USA
Post Re: Trying to write to Cx4 ROM from the cart edge
Tauwasser wrote:
I would have assumed that #WE and #OE don''t just simply track the cart edge. After all, it seems like the co-processor is meant to be able to read ROM data on its own, else it wouldn't need to have the full address bus attached to it.

You are correct. I neglected that detail. There is probably a priority decoder along the lines of "if the Cx4 wants to read from the ROM for its internal processes, override the /CE, /OE, /WE lines, else track the cart edge signals". It still eliminates the need for an extra address decoding step to determine whether or not to assert /WE depending on whether or not that address was writable. They just handled it by driving the ROM /CE pin with the Cx4 /OE signal, which then only enabled the chip during reads, not during all accesses to valid ROM addresses. Also, it seems like /CE is held low as long as the address is in the valid range, as opposed to /OE, which strobes for every access. That's probably another reason why they used the /OE signal, though it still doesn't explain why they didn't just connect it to the /OE pin and ground the /CE pin instead...

Tauwasser wrote:
So I'm kind of wondering why your #CE would be asserted for write cycles to ROM. This might run the risk of enabling two chips at the same time, which I think the Cx4 should be interested in avoiding...

That shouldn't ever happen, because each chip should have its own dedicated /CE signal, and the address decoding logic should never allow 2 /CE signals to be asserted low at the same time.

Tauwasser wrote:
Are you able to look at all (presumed) output pins at the same time, or are you limited to 8 at a time?Tauwasser

8 at a time, unfortunately. Eventually, I'd love to get my hands on one of these... we'll see how my finances look after Christmas... But even with 8 channels, it should still be possible to get some idea of what the few unknown pins are doing, or at least confirm the pins I already *think* I know. I mean, even with just 3 channels, it was pretty obvious when I had finally figured out pins 27, 51, and 52. What I *don't* know from that is for what addresses pin 27 is asserted low, vs pin 26, vs whatever pin is SRAM /CE, but since I know which addresses those *should* be enabled for, I can test them out and use the limited channels to at least confirm that. If and when I have the ability to sniff 32 channels simultaneously, then maybe I can try something more in-depth. My Salae clone doesn't have the greatest resolution either, so I'm not getting super-accurate timing data, but I can at least see that A occurs before B, etc.

Thu 19 Dec 2013, 01:17:38
User avatar

Joined: Sat 01 Dec 2012, 01:50:23

Posts: 240
Location: Oregon, USA
Post Re: Trying to write to Cx4 ROM from the cart edge
Just for kicks, I wired up an SRAM IC using pin 25 on the Cx4 as /CE, and I'm happy to say it works beautifully. Only thing is, I have a feeling I have my address mapping wrong. This is my address decoder function:

Code:
uint32_t SRAMAddress(uint32_t CartAddress)
{
  return ((CartAddress& 0xfffff) | 0x700000);
}


Can somebody help me with the right address mapping function? In any case, I'm still calling this functional confirmation of the Cx4's SRAM support... yay :)

Sun 19 Jan 2014, 07:39:56

Joined: Fri 10 Apr 2009, 15:00:08

Posts: 13668
Post Re: Trying to write to Cx4 ROM from the cart edge
Neat! Can you execute Cx4 code out of SRAM? I know that's not an easy thing to test (no assemblers out there for it.)

SRAM is mapped to $70-77:0000-7fff. Your decode should be like this:

Code:
uint32_t bus_address(uint32_t addr) {
  return 0x700000 + ((addr & ~0x7fff) << 1) + (addr & 0x7fff);
}


You will be limited to 32Kbit*8 = 256Kbit = 32KByte.

Sun 19 Jan 2014, 07:51:08
User avatar

Joined: Sat 01 Dec 2012, 01:50:23

Posts: 240
Location: Oregon, USA
Post Re: Trying to write to Cx4 ROM from the cart edge
byuu wrote:
Neat! Can you execute Cx4 code out of SRAM? I know that's not an easy thing to test (no assemblers out there for it.)

I don't currently have a development environment set up, and I have no hardware interface for uploading the code while it's in the SNES, so I can't test. However, with this tested, I'm ready to get that 2x8Mbit ROM/256Kbit SRAM dev cart built once I finish tracing the last 5 or 6 signals remaining, so maybe you can try it then.

byuu wrote:
SRAM is mapped to $70-77:0000-7fff. Your decode should be like this:

Code:
uint32_t bus_address(uint32_t addr) {
  return 0x700000 + ((addr & ~0x7fff) << 1) + (addr & 0x7fff);
}


You will be limited to 32Kbit*8 = 256Kbit = 32KByte.

Bingo, that did it. I can write to the full 256Kbit address space and read it back. Tested it with all 0x00, 0x55, 0xAA, 0xFF, and randomly generated data, and all of them came back 100%. Sweet :)

Just because, here's the wiring for this cart (I left ROM #1 on the board and just replaced #2 with SRAM... when I get my 32-pin adapter boards back from SeeedStudio, I'll probably replace ROM #1 with a FlashROM).

Image

Sun 19 Jan 2014, 08:39:45
Previous  1, 2

Who is online

Users browsing this forum: No registered users and 0 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum