N64 flash board

can someone provide me with the specifications of a N64 cart please?
(what kind of memory is used in it, pinout of the cart, etc.)
thanks

 

pit, take a look at this page.
http://www.crazynation.org/N64/n64_cart_info.htm

 

thanks gorgyrip

ok so a 32 bit address bus, having 2 latches of 16 bits? and the eeproms are 16 bit wide?
then READ acts as /OE? think I could make a writer for this in vhdl
(or even something like Nand flash -> N64)

 

The EEPROM are 1-bit wide serial EEPROM. The ROMs are 16-bit wide (custom of course) Mask ROM, if that's what you mean.

Right the address bus is 32 bit, two latches of 16-bits to specify the base address, but the address is incremented after a R/W for relatively quick <=512 byte access.

Just like almost anything else, /RD should be connected to /OE, and /WR to /WE, and an address decoder to /CE.

 

Here's a little diagram that might clear things up:

Note this was drawn for someone else who had less experience in electronics than most.

 

marshallh: do you know how /CE is decoded inside the ROMs? I'm curious how two-ROM games are mapped and if there's mirroring. It'd be weird for Nintendo/Macronix to make ROM masks specifically for the second half of a particular sized game. I'm sort of tempted to build a read/writer myself to do this sort of simple testing

I'm confused. Are the address latch signals active high or low? If you interpret the diagram to be initially high, and latches are loaded on the falling edge, then they should be named /ALEL and /ALEH. If the signals are initially low and are raised high for latching, it seems like the address latch signals are inappropriately named (and thus my ugly paint picture is wrong.) Perhaps really ALE_L = "address latch enable" and ALE_H = "address latch low/high"? In that case the logic would be: ALE_L = ALE && !nALL/ALH and ALE_H = ALE && nALL/ALH.

 

Sounds practicable to me. My two cents on that. Which other sense would the second ALE signal make?

PS : marshall, do you have any more examples about N64 bus Pulse Width, Page size, latency etc? I remember you having told me some time ago you have a bus analysis...

 

You're right, both address latches are active low so I suppose I mislabeled them. Whoops

I haven't ever seen a two-rom cart, but I'd guess Nintendo would integrate address mapping inside the first ROM to avoid adding a external mapper chip.

The first 4 bytes that the N64 reads are part of the 4k cart header - if you look on the crazynation page, you'll see what they mean. When the N64 boots, the 4k cart header contains a small assembly program to transfer the first 1MB of ROM straight to RDRAM, and run it. By changing the third byte to 0xff in Extreme-G, I increased the pulse width, and this initial transfer took much longer, about 5 seconds. The game ran fine, just loaded slower. However other games like XG2 crashed while playing their intro, DMAing stuff as it played (like audio) but it was not fast enough.
I have some more notes on this that I'll have to dig out from some irc logs.

 

Everyone has been labeling them that so I've assumed for a while they're active high, which is strange for a control signal.

I'm pretty sure all non-2^n-sized and 512M carts have two ROMs. Looking at Pinchy's page I think the ROMs have an external /CE signal since /RD is connected twice. That would mean that /RD is gated and only active during cartridge access

Connect them to the parallel port, those are LPT signal names.

Yes, those are right. I don't think you'll need to reset the carts but maybe...
I thought of some other uses of the spare pins: the ability to read/write the cart's EEPROM and maybe do tests on the CICs. (this will take another 74244 and more resistors)

 

Yep i confirm that. From my researches, the PI Latency / Pulse Width / Page Size / Version (?) are used to configure the PI. You can have two of such configurations, one corresponding to one domain. Which means you can have two devices with different latences (and thus pulse widths), page size, versions (for example a ROM and a - oh surprise! - 64DD) attached to the Bus and can access them without needing to setup the whole configuration every time.

Long story short, the N64 bus is some kind of configurable IC which interprets signals based on the its configuration (bum ).

 

What exactly are we talking about regarding pulse width? Time (1/f) or duty cycle?

Configurable PIC? Programmable interrupt controller?

 

You can disregard what I said earlier about the latch enables being active low or high. The truth is that I'm confused now.

Here's a page from a Nintendo patent describing it in better detail:
http://www.google.com/patents?id=Zl4KAAAAEBAJ&pg=PA47&vq=as+rom+may+occupy&dq=6394905+table+3

 

Hey hey hey...we have something here. Where is this quote from, marshall? A chat you had on mIRC? Very intresting

Sorry, my fault, a P too much.
marshall, i can confirm what the irc-guy told you : the Create*Leo*Manager function sets BOTH latency and pulse width to 0xFF...and the 64DD refers to Domain 1.

A short resumee on my personal interpretation :
latency : wait time for something to happen, non-periodical -> first access to disk (if we are referring to 64DD)
pulse width : read / write signal frequency imo
release time : bus release time by pheriperial.

There we go, some light seems to be shading (at least for me)

 

Don't take Nintendo's patents literally, often there are small to significant differences between what is described in the patent and the final product. It does explain everything I wanted to know about the cartridge though! /ALEL and /ALEH are active low but Nintendo calls them "ALEL" and "ALEH" for whatever reason.

Kammedo, do you have a list of the possible values for the configuration bytes? That would make this all very clear.

 

Only thing (that i know for sure) i can say is :
the Leo*Create*manager function sets latency, release and pulse width to 0xFF.

More i dont know up to now, work in progress. Maybe marshall has some more hints?

 

But that's specifically for 64DD access, I wonder what carts are using and what the values equate to. Likely there are only a few valid values to each byte.

 

Hm. In the paper its stated that all multiplier values from 1 to 256 are valid.
Well you know the four bytes at the start of each rom are

A) latency time (0x80)
B) page size (0x37)
C) pulse width (0x12)
D) release (0x40)

So lets suppose the latency is the first-time access untill the read-command is putted low.

That would be (from the paper) : 16 * 128 = 0x10*0x80 = 0x800 ns = 2048 ns

It could be that this number is somewhere.

Note : http://www.crazynation.org/N64/n64_cart_info.htm
this one says measurements based on 100Mhz clock. Isnt N64 94.something?
On that, remember this graph is NOT referreable to the values mentioned before because they have NOT BEEN SET up to this point. It would only make sense if the values at default (ie when you power on the console) are the same as the ones i mentioned above, but if thats the case why the heck then use 4 bytes to put a copy of them in a ROM??
Makes sense only if those values are loaded in the registers at power-up. Hm. No. Doesnt sound credible.

IMO, for how much it may count, the sistem uses default values at startup.
Those values may or may not be the same as the ones in the ROM (makes sense to have those values in the ROM anyway so you know were to get them if needed ), because the N64 HAS to or else it doesnt know how to set up the protocoll to access the ROM.
The pulse width, for example, could be 0x13 instead of 0x12 (300/16 = 18.75 rounded up -> 19), but still, until we dont have certain measurements (based on a certain system clock value) we wont be able to say anything at all.

 

If that were the case, the value would be loaded into a counter to act as a frequency divider, the opposite of multipliers (phase locked loop). I don't think that's the case though, it's not necessary to have such range of values. Probably only a 2 or 3 bits are used to select 4 or 8 speeds.

Are you taking into account endianness and the ROM's word swapping? That's pretty important.

Where are you getting 16ns? I don't think it specifies anything about signal timing. It has to do with how long to wait for valid data. It doesn't matter when /RD is asserted from the address strobe because the cart WILL get it instantly, what matters is how fast the cart can respond with valid data because there is no handshake. If the cart doesn't respond in time, the N64 will read open bus and crash.

He is using a 100MHz logic analyzer to sample data. It's not clear whether this means it can accurately sample signals up to 100MHz (usually 2-10x oversampling for accuracy, meaning 200MHz-1GHz sampling) or if it means signals are sampled 100M times per second. It doesn't really matter because the bus easily is slow enough to measure with 1ns accuracy!

It's been said that the bus starts at the slowest speed in order to accommodate starting from the slowest memories like N64 ROM. Perhaps normal games could load much faster with other memories like EPROM, DRAM, Flash etc.

Huh? At power-up, they're surely loaded with the slowest speed and the speed is increased once the byte is read from the cart.

The protocol is always the same, the time to wait before registering the data changes. I don't think the default is the same as the cart because the cart is faster than the slowest speed, but it's surely not as fast as it could be.

I don't get where you're getting any of your numbers. What are the units for 300? Where is 16 coming from? Rounding up? A single binary divider can't divide stuff fractionally nor can it round stuff up


I think if the header code is disassembled to gather the configuration registers, it may be possible to gather a real description from a manual.

 

Every single N64 game I know of has the same first four bytes (and for that matter, most of the 4k header is identical, depending on the CIC type)

0x80371240 - first four bytes in every ROM. On byteswapped Doctor V64 ROMs it will be 0x37804012.

It looks like at this standard speed, if one is emulating a ROM, then you have about 1400 ns to latch in the 32-bit address, and 300ns for consecutive word reads, which repeats 256 times for a total of 512 bytes read, per cycle. Then it starts all over again.

Bear with me here, I'm going to diverge.

My original plan for a cheap flash cart was to use a cypress FX2 USB microcontroller. It's basically a 8051 MCU with integrated USB 2.0 capability. I made a PCB with it wired to CompactFlash. I was able to dump N64 carts with it (the second dumper) and read from CF at about 1MB/5 seconds. not fast enough for normal PI cart access. Now, if I had patched the ROMs to load slower, that 40mhz MCU would have been fast enough to read CF and pass data to the PI bus. I didn't get that far though, cause most games wouldn't work like that.

My new proposal: FX2 + CF + CPLD.
FX2 will facilitate read/writes of CompactFlash memory. A very flat file system will be overwritten on the card, say a 2K header/table with ROM offsets and sizes. Then, containing the rom data stored linearly. Special software will have to be used because the FAT will be borked.

The CPLD (I'm looking at a low-end Xilinx tq144 device) will simulate some basic 74 logic to interface between PI requrests and the CF common memory interface.

I have written a simple menu program that shows a list of... homebrew games. I am thinking that for a simple game selection mechanism, the menu app reads from a out-of-bounds cart address. This address is trapped by the FX2 (also wired to N64 PI) which configures the new CF rom offset for the CPLD. Then either the menu app or the flash cart generates NMI reset and boots the new rom.


It works in theory. Back in '99, Valeryia said that CF was fast enough for PI access which is pretty darn slow.


For code testing/debugging, the FX2 will have to do some wear-leveling. Say, you send your test ROM with is 8mbit over USB 2.0 and it's writing to CF. the ROM offset will be moved up each time so that, on a 128mb CF card, you have at least a 100 debugging cycles before the original flash blocks are rewritten. Since cartridges can generate resets, you might not even have to turn on/off your N64 between tests. <me likes that idea

Thoughts are appreciated...

 

If I were to do it, I'd do it entirely in logic (use the CF as a traditional ROM) and I'd put the ROM on the card linearly for speed, I'm not so sure it can be done with a microcontroller since the CF is the bottleneck.

Here's how I understand it has to work:
So once you get the linear address from the latches, it needs to be shifted then loaded into the CF's sector number (like 6x IDE writes?!), then the least significant bits need to be loaded into a counter (clocked at the CF's limit) to crank out reads until the desired base word appears within the normal ROM's timing. What's worse is that if the counter overflows, you have to then increment the sector... that's tricky.

I would rather make yet another DRAM unit since it's fast and pretty straight forward. It will also cost you less gates. I think it'd be cool to even have a really cheap V64 Jr knockoff without a PC link, just a hunk of memory programmable by a writer A free unit with debugger/pro stuff would be really nice too though...