N64 flash board

[gorgyrip]

hi,
a friend of mine has one of this. this board will soon be mine. I know you can program it with a gang writer, but i want to know if someone knows a way to program this cart without a gang writer. a schematic or something will be verry useful.
thanx

[kammedo]

hi,
a friend of mine has one of this. this board will soon be mine. I know you can program it with a gang writer, but i want to know if someone knows a way to program this cart without a gang writer. a schematic or something will be verry useful.
thanx

There you have a nice project for your christmas holidays :P.
I have a flash cart also, but i dont think it will be easy to reverse.

[Calpis]

I'm sure it's EXTREMELY easy to reverse if you can build a DIY cart reader that can simply read and write to the cart. This isn't a project for newbies though since you'll have to design/build your own cart interface.

Probably the ASIC is only there to interface the flash to the cart bus, and decode ROM/SRAM so the only thing you have to think about is writing the cartridge.

This is easy because there's either a "cart writable?" register that unlocks /WE so the gang writer can program the cart or there's nothing at all. If there is a register to unlock /WE and you don't know how to figure it out, you can cut the track from the ASIC to /WE and jumper /WR from the cartridge connector directly to the Flash chips. Once you can write to the Flash, you only need to read the datasheet to find the programming algorithm that brand uses.

[marshallh]

I'd have a look at the design of the flash cart itself - are the flash ROMs managed by an ASIC, or do they share the data bus and trigger on high address bits?

It's possible to do by yourself. It will depend on how much experience you have with digitial electronics.

I can explain to you how the n64 PI bus works (cartridge interface). The timing is fairly simple, though the address/data lines are multiplexed.

The hardest part is figuring out the scheme the cart used to write directly to the flash ROMs. Ideally, you would borrow a flash gang writer, and put a logic analyzer on the cart bus. But you just have to think and use what you have.

[gorgyrip]

thax for your replyes. i don't have experience to design such a device to dump or write a flash board or a n64 cart. but if someone has a schematic of this device i can build it. :)
this flash board has the game 40 winks on it. i will have it next week i think.
See the pictures.

[kammedo]

I'm sure it's EXTREMELY easy to reverse if you can build a DIY cart reader that can simply read and write to the cart. This isn't a project for newbies though since you'll have to design/build your own cart interface.

Probably the ASIC is only there to interface the flash to the cart bus, and decode ROM/SRAM so the only thing you have to think about is writing the cartridge.

This is easy because there's either a "cart writable?" register that unlocks /WE so the gang writer can program the cart or there's nothing at all. If there is a register to unlock /WE and you don't know how to figure it out, you can cut the track from the ASIC to /WE and jumper /WR from the cartridge connector directly to the Flash chips. Once you can write to the Flash, you only need to read the datasheet to find the programming algorithm that brand uses.

Even if he knows absolutely _nothing_ of electronics? :P

[Calpis]

don't have experience to design such a device to dump or write a flash board or a n64 cart. but if someone has a schematic of this device i can build it. :)
I don't think there's a free design on the internet and I'm not so sure that someone would share one since it can effectively be used as a "linker" in a commercial project. Also the device would require more wires than is sensible to use without a PCB and PCBs are expensive and time consuming to get. I also guarantee you'll need electronics skills to troubleshoot the thing once it's built, nothing ever works the first time even if you're positive it's supposed to.

Besides, without a doubt it will cost you less time, energy, money (yes even money!) and frustration to just buy a Gang Writer. A couple years ago I remember them selling for ~$100!


Even if he knows absolutely _nothing_ of electronics? :P
Of course not, but he asked to build it :confused:

[gorgyrip]

I have experience with soldering and with PCBs. I worked with smd electronics. I've replaced the rom in a gameboy color cart with am29f032 TSOP40. i also made a programmer on PCB for this cart based on atmega8515, and with usb connection through ft232bl. but it wasn't my design. what i'm trying to say is that if someone can help with the schematics, i can build it. thanx again

[Calpis]

Can you program? If so, I can whip up an unguaranteed-extremely-cheap circuit that should do what you need but it will probably take *forever* to read/program a cartridge.

[gorgyrip]

sorry, i can't program.

[kammedo]

sorry, i can't program.

xD There you go. Im offering myself to do that! You need me?

[gorgyrip]

YES!!! Plese help me. i don't care if will take an hour to program it. i live in romania so i'm realy lucky i found suck a cart and i'm sure i will never find a gang writer. any help is very appreciated.

[kammedo]

YES!!! Plese help me. i don't care if will take an hour to program it. i live in romania so i'm realy lucky i found suck a cart and i'm sure i will never find a gang writer. any help is very appreciated.

Calpis? marshall?

[Calpis]

This is the simplest / cheapest design I could think of. The chips together should cost under US$8 and after that you only need a 3V power supply circuit and N64 connector.
It's very slow for writing and it's *HELLA* slow for reading (since you'll need to change the port's direction to write the register to toggle /RD). You can however speed up reading to much faster than writing by putting /RD on the last parallel port control line instead of the register.

Make sure it's made with 74HCXXX chips, NOT 74HCT! The chips need to run off 3V. You also need to connect all parallel port GNDs to this device's GND. You may need to put pull-up resistors on all the parallel port lines too depending on your port. You can also replace the 74245 with the 74244 to save some money too.

Edit: Bad schematic!

[gorgyrip]

calpis, thanx for the schematic. tomorrow i will go to buy the parts. but the last time i searched for 74hc374 i only found 74HCT374. maybe tomorrow i'll have better luck. but if i can't find 74hc can i use 74hct with a power supply of 5v to the ic's and 3v to the cart?

[Calpis]

calpis, thanx for the schematic. tomorrow i will go to buy the parts. but the last time i searched for 74hc374 i only found 74HCT374.
Wait! I see a very stupid error in it, the last circuit won't even work. I'll do a better one which is much faster and even more compatible with different parallel ports too.
I changed the latches to 74HC574, they're the same as 74374 but have a different pinout, they should be easier to find.



but if i can't find 74hc can i use 74hct with a power supply of 5v to the ic's and 3v to the cart?
You could do damage to the cart. I don't think it will, but it could.

http://img517.imageshack.us/img517/7083/improvedan6.th.gif (http://img517.imageshack.us/my.php?image=improvedan6.gif)

Kammedo:

Use this if you need it: http://www.beyondlogic.org/spp/parallel.htm
You'll need this DLL if you want to use this in Win XP:
http://logix4u.net/Legacy_Ports/Parallel_Port/Inpout32.dll_for_Windows_98/2000/NT/XP.html

Don't forget that the outputs/inputs of the parallel port can be inverted.
Make sure you allow only ONE 244 input at a time! They're acting as a poorman's MUX.
The registers are loaded on the rising edge of CLK.
Make sure you disable U3 and U4's output before you intend to read the bus!

To access the cart:
1) make everything inactive
2) put most significant byte of address on data port (378), clk U3
3) put next to most sig byte of address on data port, clk U4
4) put xxxx1xxx onto data, clk U1 (to assert ALEH)
5) do steps 2-4 but use least significant bytes and ALEL
If you want to read: assert /RD and choose which nibble to read with U2. Read them all in, de-assert /RD, re-assert it to get the next word etc. (thanks to N64's "burst mode")
If you want to write: put data into U3 and U4, then assert /WR.
De-assert it, put more data into U3 and U4, re-assert /WR etc etc .

Easy!

[marshallh]

That's a pretty neat circuit. The first cart dumper I made was a pic16lf877 running at 3.3v hooked straight to the cart pins and a max3233 level converter. It was danged slow.

The next couple of days I ought to have some decent free time. If I can find the right 74 chips I'll see if I can put something together.

Really reminds me of the flash cart designed by Valeriya pudov a long time ago. I came very close to actually building it

[gorgyrip]

@ Calpis
Thanx for the new schematic
no luck with th HC chips. at the local store they have only HCT and LS. but i found an on-line suplier in romania so i ordered all the necesary stuff. i already have the cart connector and the IC's i think will arrive in 4 or 5 days.

@marshallh
I've seen your schematic at benhack. but you said there the dump was bad and the pic was slow.

[kammedo]

Kammedo:

Use this if you need it: http://www.beyondlogic.org/spp/parallel.htm
You'll need this DLL if you want to use this in Win XP:
http://logix4u.net/Legacy_Ports/Parallel_Port/Inpout32.dll_for_Windows_98/2000/NT/XP.html

Don't forget that the outputs/inputs of the parallel port can be inverted.
Make sure you allow only ONE 244 input at a time! They're acting as a poorman's MUX.
The registers are loaded on the rising edge of CLK.
Make sure you disable U3 and U4's output before you intend to read the bus!

To access the cart:
1) make everything inactive
2) put most significant byte of address on data port (378), clk U3
3) put next to most sig byte of address on data port, clk U4
4) put xxxx1xxx onto data, clk U1 (to assert ALEH)
5) do steps 2-4 but use least significant bytes and ALEL
If you want to read: assert /RD and choose which nibble to read with U2. Read them all in, de-assert /RD, re-assert it to get the next word etc. (thanks to N64's "burst mode")
If you want to write: put data into U3 and U4, then assert /WR.
De-assert it, put more data into U3 and U4, re-assert /WR etc etc .

Easy!

Noted. Will see to do something when i get some spare time.

[gorgyrip]

Hi,
today i recived the flash board and the IC parts.
but there's a problem. they send me only 3 x 74hc574 and they told they don't have the fourth 74hc574 in stock, but in about a week or two they will send it to me. meanwhile i started designing the PCB. it's almost complete. But i have some questions. Where should i connect pin 11 (SELECT) from U3 and pin 11 (INIT) from U4?
and please tell me if i did this right:
/RESET--->/COLD_RESET (pin 20 from n64 cart)
ALEH--->ALEL_H (pin 35 from n64 cart)
ALEL--->ALE_L (pin 33 from n64 cart)
thanx
and for the power supply i'm gonna use the n64 power suplly (3.3v)

[pit]

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

[gorgyrip]

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

[pit]

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)

[Calpis]

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.

[marshallh]

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.

http://img118.imageshack.us/img118/747/n64carttimingaj5.png

[Calpis]

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.

[kammedo]

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...

[marshallh]

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.)

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.

[Calpis]

You're right, both address latches are active low so I suppose I mislabeled them. Whoops ;)
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 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.

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 :(


Hi,
today i recived the flash board and the IC parts.
but there's a problem. they send me only 3 x 74hc574 and they told they don't have the fourth 74hc574 in stock, but in about a week or two they will send it to me. meanwhile i started designing the PCB. it's almost complete. But i have some questions. Where should i connect pin 11 (SELECT) from U3 and pin 11 (INIT) from U4?
Connect them to the parallel port, those are LPT signal names.



and please tell me if i did this right:
/RESET--->/COLD_RESET (pin 20 from n64 cart)
ALEH--->ALEL_H (pin 35 from n64 cart)
ALEL--->ALE_L [FONT=Fixedsys](pin 33 from n64 cart)
thanx

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)

[kammedo]

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.

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 :P).

[Calpis]

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

Configurable PIC? Programmable interrupt controller?

[marshallh]

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


him:
im still not sure of the speed
remember about the first 4 bytes of the rom header is the access speed of the PI
it loads those into the PI interface on boot to set the read write strobe signal speeds and such
i think thats what is done with the DD cart
have you got a dump? load it up and look at the first few bytes

marshallh:
yea, I changed the third byte of extreme-G to 0xff like you said on the cart page, and sure enough took about 5 seconds to load the first meg
the game ran fine, loads were long
on ther other hand, extremeg2 froze during startup

him:
i need to bust out the docs
the other bytes do some of the same
you see how its multiple of 256
the realese time is on x4
latency is what u want to set
that im sure is high on the n64DD
that gives the media time to seek
and thats why changing it didnt have much affect on the game like u saw
coz its just that one wait then the rest of the clocked R/W will be fast

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

[kammedo]

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


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

Configurable PIC? Programmable interrupt controller?

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) :)

[Calpis]

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
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.

[kammedo]

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!

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?

[Calpis]

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.

[kammedo]

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 :P), 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.

[Calpis]

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

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.



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

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



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
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.



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?

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! :D



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??
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.



Makes sense only if those values are loaded in the registers at power-up. Hm. No. Doesnt sound credible.

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.



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 :P), because the N64 HAS to or else it doesnt know how to set up the protocoll to access the ROM.
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.



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.
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 :confused:


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.

[marshallh]

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...

[Calpis]

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 :D A free unit with debugger/pro stuff would be really nice too though...

[kammedo]

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.


marshall replied for me already. Im referring to Big endian non-swapped original MIPS roms.



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! :D


Check the patent marshall posted!





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 :confused:
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.


Check the diagrams - 300 is the "Read Low" signal interval.
You wont be able to get a detailed description from any (at this point) known manual. Believe me. The only thing you get from the documentation are the offsets of the registers, in the rcp.h include file.
Thats it.

[marshallh]

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 :D A free unit with debugger/pro stuff would be really nice too though...

That's what I'm saying, a MCU is by itself too slow. Now if you're designing the CPLD with logic blocks, that may be a problem. But in VHDL it shouldn't be much of a problem at all.I was assuming that a reasonably large CPLD would fit the design, but having not worked with one, it might require a fpga instead.

[Calpis]

If you keep it very simple, I think it can fit into a Xilinx 95108 or Altera 7128, I wouldn't want to try though. Also remember that CF cards use SI units in their size :(

Kammedo: OK, I checked out the patent. If this is accurate, it's clear what everything does:

Latency - Time between address strobe and /RD or /WR
Pulse Width - Time /RD or /WR is asserted
Release - Time between /RD or /WR's rising edge and falling edge.

I don't know what 16ns x 1 - 16ns x 256 is supposed to mean though. I think it's more than 16ns x 256 = 2048ns.

[marshallh]

After looking around for a suitable CPLD based on that suggestion, I can get a spartan-II fpga that does more and better. The only downside is including a configuration PROM, but they're not too expensive. The fpga runs about $15 on digipee.

I think the best plan of action now is to either buy a hi-density Hirose connector for my fpga protoboard so I can use its IO, or go ahead and have the PCB I drew up fabricated for YAN64BU. It's essentially a FX2+SpartanII+SDRAM. It would be easier to add card reading routines onto the existing design.

[Calpis]

If you're going to have USB, why not shoot for a no memory design using the PC as a server? That'd be neat.

[marshallh]

You mean like streaming ROM data in realtime over USB? I don't think that would work, usb2.0 latency is too high.
Now, with something like the FX2's GPIF engine (basically allows direct transfer between usb host/16-bit wide device) it can read/write compactflash and IDE devices with only a timing diagram and a few lines of code, much faster than bit-banging.
Refer to this:
http://pages.cpsc.ucalgary.ca/~walpole/525/FRIESS%20and%20MCNEIL/datasheets/FX2/FX2_IntroToGPIF.pdf (http://pages.cpsc.ucalgary.ca/%7Ewalpole/525/FRIESS%20and%20MCNEIL/datasheets/FX2/FX2_IntroToGPIF.pdf)


If you're talking about just an fpga+sdram+usb on the cart, that's what the design already has.

I'll post the pcb layout I have so far once I get my autorouter working again.

edit: calpis can you hop in IRC? I'll be on all tonight.

[olivieryuyu]

gorgyrip, pls can you check your PM ?

Thanks a lot

[gorgyrip]

still no luck with the last 74hc574 :(

[Infrid]

I haven't ever seen a two-rom cart
http://n64.icequake.net/mirror/tcsr2001.tripod.com/carts/nkte-0/index.htm

why not use a SD instead of a CF? sd card use SPI interface...

[gorgyrip]

finally i received the last 74hc574. in fact, they send me 3 pieces. so now please help with the software.

[gorgyrip]

finally i received the last 74hc574. in fact, they send me 3 pieces. so now please help with the software.

[kammedo]

finally i received the last 74hc574. in fact, they send me 3 pieces. so now please help with the software.


Noted.

Will do in the next days and keep you posted!

[pit]

http://n64.icequake.net/mirror/tcsr2001.tripod.com/carts/nkte-0/index.htm

why not use a SD instead of a CF? sd card use SPI interface...

does the -35 at the end mean tAA = 350ns or does it mean tAA = 35ns?

[marshallh]

does the -35 at the end mean tAA = 350ns or does it mean tAA = 35ns?

I don't think it means either, though 35ns would make more sense for a ROM. (early PC simm ram was around 60-70ns)

[Calpis]

Right certainly doesn't mean either. I actually think 350ns would make more sense than 35ns for a ROM since you'd be hard pressed to find any ROM faster than 70ns.

[pit]

datasheets of similar roms say -15 means 150ns

[pit]

alright! I'm getting 96Mbit of 10ns SRAM :)
I'll keep you guys updated on my usb cart

[smf]

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 :)


All mask roms are created specifically. Nintendo supply the contents and Macronix make them.

It would be possible for the roms to only enable their output buffers when they are addressed.

It's possible that the n64 supplies the OE signal, but that would limit the number of roms if not the size ( the n64 would need to know the size somehow ).

You could also have another chip that keeps track of what address is being accessed, but thats alot of duplicated work & it will cost more.

They could even have inputs on the rom that specified the address. i2c ram chips work like this, to change the address you connect some lines to 5v/ground. But rom is fixed function, it can only be part of a game. This would put up the leg count for no reason.

Basically, if nintendo did anything other than having the roms know at manufacture what address they should respond to then they made a stupid decision that day.

[Calpis]

Huh? Mask ROMs of the same size all follow the same layout except for the ROM bits. Since I posted that I've looked at the N64 patent which suggests that all the ROMs have a slightly "configurable" /CE decoder based the state of IIRC 4 address lines.

Also what about /OE? /OE is of course supplied by the N64--the /RD signal.

[smf]

Huh? Mask ROMs of the same size all follow the same layout except for the ROM bits.


Well for non multiplexed mask roms that is true, but these aren't. If you're going to go to the hassle of getting macronix to make you a custom rom with multiplexed inputs then you're going to go for the no cost option of having the rom know what address to respond to rather than having an external chip do it. The address input to the rom allows for a 4gb range, it's not like those high address bits are going to be used for anything else. It means you can just connect more and more roms to the n64 without it knowing whats on the cart & not having any expensive glue chips on the cart.

I'm basing this on conjecture and what is logical, nintendo might have made a mistake by putting the address bit comparator on a seperate chip which also has to decode the multiplexing inputs. That would be a really really stupid thing to do.


Since I posted that I've looked at the N64 patent which suggests that all the ROMs have a slightly "configurable" /CE decoder based the state of IIRC 4 address lines.

Also what about /OE? /OE is of course supplied by the N64--the /RD signal.

CE = chip enable
OE = output enable

Some roms have one or the other or both. Although if they have one then sometimes it's called CS.

Here is a datasheet that explains it better for some old and crust 27c64
http://www.ortodoxism.ro/datasheets/nationalsemiconductor/DS010331.PDF

I'm not sure I understand what you say about the n64 patent, what you said implies that the rom knowns what address it needs to respond to. Which is the most logical way of doing it.

In that case, going by standard conventions. A CE signal would trigger the address decoding & all roms would get the same signal from the n64. However you only want one to enable it's output buffers at a time or you'll get a bus conflict, OE would therefore be generated by the mask rom.

There may not be a CE signal because often you just ground them anyway, unless the rom is told to enable it's output buffers it doesn't matter what it does. For example the 2364 to 27c64 adapter for the c64 just ground CE and connect CS to OE. Plus the multiplexing inputs imply that you are talking to the chip.

Ok, I looked at the patent.

"Figure 12 is a block diagram which demonstrates in detail how the address/data 16 bit bus is utilized to read information from a game cartridge ROM and read and write information from a game cartridge RAM. Coprocessor 200 generates an address latch enable high signal which is input to the ALEH pin in Figure 12. Exemplary timing signals for the reading and writing of information are shown in Figures 13 and 14 respectively. The coprocessor 200 similarly generates an address latch enable flow signal (shown in Figure 13) which is coupled to the ALEL pin which, in turn, enables information on address pin 0 to 15 to be loaded into the input buffer 352. Bits 7 and 8 and 11 and 12 from input buffer 352 are, in turn, coupled to address decoder 356.In the exemplary embodiment of the present invention, bits 7, 8 and 11, 12 are decoded by the address decoder to ensure that they correspond to 4 bits indicative of the proper location in the address space for the mask ROM 368. Thus, the mask ROM 368 has a designated location in the AD16 bus memory map and decoder 356 ensures that the mask ROM addressing signals correspond to the proper mask ROM location in this memory map. Upon detecting such correspondence, decoder 356 outputs a signal to one-bit chip select register 360. Turning to Figure 13, when ALEH transitions from high to low, as shown in Figure 12, bits 0 to 6 output from input buffer 352 are latched into 7 bit address register 362. Simultaneously, data from address decoder 356 is latched into chip select register 360 and register 358 is also enabled, as indicated in Figure 12. "

With this explanation it's not even clear that the mask roms address/data are multiplexed, it might only be the cartridge slot. Although googling around some people believe the mask rom address/data is multiplexed.

It's possible that the flash carts use standard chips with external multiplexing, while the retail carts use multiplexed mask roms.

The patent doesn't have to exactly cover what they sold, only what they designed: "In the exemplary embodiment of the present invention"

Whether the address decoder is in the cartridge or the rom is irrelevant for the patent, but would change whether you're enabling the chip or enabling the output buffers.

To clear up all the conjecture we need either a datasheet or reverse engineer the mask roms. The latter wouldn't give us the official names for the pins though.

[Calpis]

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.

[smf]

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,

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.

[Calpis]

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?

[smf]

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.

[Calpis]

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.


Usually when you select a chip it's to say "here comes an 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.

[gorgyrip]

kammedo, any news with the software?

[kammedo]

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!

[gorgyrip]

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

[Calpis]

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.