N64 flash board

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

Check the patent marshall posted!

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.

 

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.

 

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.

 

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.

 

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.

 

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


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.

 

gorgyrip, pls can you check your PM ?

Thanks a lot

 

still no luck with the last 74hc574

 

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

 

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

 

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!

 

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)

 

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.

 

datasheets of similar roms say -15 means 150ns

 

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

 

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.

 

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.

 

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.

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.