N64 flash board

You and I are somewhat saying the same thing; what I thought I expressed pretty clearly was that the bits connected to the address comparator are in ROM, just like the game data. What I was stressing was that the only difference between each ROM mask is the 4 address bits and the game code. You are of course correct in that there is no decoding "glue" logic on the board, but using the 4 bit address comparator, you can probably have only 4 ROMs without changing the IC's mask and adding more bits, which may be the case in later ROMs, but probably not.

Other than that I think you may be confused about how practically every system uses /CE and /OE. /OE is NOT supposed to be decoded by the cartridge/ROM, it's supposed to be provided by the CPU. Since the /RD strobe means the CPU's data buffer's is ready for input, that is always used as a ROM/RAM's /OE, likewise, /WR is always used for a RAM's /WE.

/CE, not /OE, is supposed to always be decoded by address lines. This is supported by the fact that address lines are always stable and decoded within /CE's setup time before /RD and /WR are asserted. When you come across a ROM with only one enable (/CE and /OE), then yeah, you can model it as /CE tied active, and /OE tied to the address decoder. This works, but it's really stupid because as you said, it allows for bus conflicts. Plus, what's worse, is that it wastes power since chips with low-power modes go into standby when /CE is inactive.

N64 ROMs are no exception, they use /RD to know when to output in order to not have a bus conflict. RAM/Flash on N64 cartridges use /WR and they have their own /CE decoder built in too.

Anyways the ROMs *have* been black boxed, we know how they work.

They DO have a 16-bit multiplexed address and data bus. They have two address strobes for the low word and high word, after the address is stable, the console asserts /RD and the ROM's output is enabled on the same lines as the addresses. In addition to the address decoder, they also have an 8-bit address counter to allow for 512-byte "burst" reads like EDO RAM.

The only thing left to be tested is if /CE is decoded like the patent suggests.

 

I understand how standard roms work, these aren't standard roms.

Anyway, I think we're arguing over semantics.

All the chips on the cartridge need to be enabled to decode the address, but only the one that is addressed needs to enable the output buffers. If an external OE exists then it would be anded with the internally generated one, although it might be implied by the state of the multiplexing and doesn't exist as a specific line.

As the chip can be enabled but not have it's output buffers then I think it's better to use OE instead of CE or CS for the internally generated signal name. Nintendo don't agree, but then patents aren't there to make sense.

 

The fact is that the external signal enables output if the internal address-decoded signal allows it to. If you strobe in an undecoded address, you won't get output when you assert the external signal. This makes the external signal perfectly correspond to /OE and the internal to /CE in normal ROM terms, I don't understand why you are so adamant about switching the signals. How do the Macronix SRAM chips get written your way?

 

The WE signal for the SRAM would be generated in the same way that the OE is. WE signals a write, OE signals a read.

Usually when you select a chip it's to say "here comes an address".

I can see what you're saying, but it depends on how the chip actually works. _if_ there are parts that can be kept powered off when the address isn't for the chip then it would save some power by doing so.

If you built a demultiplexor to allow standard chips to be used then it would make sense to generate a CS & that is probably what Nintendo were doing when they wrote the patent. What they got macronix to build, well who knows.

 

But if the address decoder were to generate /OE and /WE and not the console, (which is what you're saying right?) you couldn't R/W to the same address.

It can be used like that with asynchronous static memory but that's not the intention at all. Every CPU outputs the valid address first, waits (long enough for the address decoder's propagation time and /CE to be setup), then asserts /RD or /WR. You certainly wouldn't enable a register (/CE) then let the address decoder asynchronously clock it, talk about a horrible design.

BTW, I found the one good reason to tie /CE active and just use /OE, it's a lot faster. You can speed up access time by nearly half on many ROMs, at the expense of power. That has to be why Neo Geo games do it.

 

kammedo, any news with the software?

 

Ouch. Sorry mate, been freaking busy lately (moving to another country soon so you can imagine!). Will see what i can do!

 

kammedo, there's no hurry. i'm waitting for a empty flash board.

 

I just looked over this thread and realized that ALEL and ALEH should be active-high when used with transparent latches since data is "locked in" at the falling edge, but when used with edge triggered flip flops they should be active-low.

 

.

 

.