Well not to be an ass but using my common sense it prob lights a Red light if something is wrong with the system.
Yeah Dark seraph91 thats near to the real thing. You just stuck it in your n64 and the cartidge tests if the console is okay, if not the led is blinking different error codes depending of the fault in the console. Thats what i know of this thing, i just don't know which codes mean which fault :shrug:.
Apparently, its a JTAG interface which lets you update the firmware in it (aka the testing software).
I shelled out the money for one of those suckers, and it arrived last week. I opened it up, and impressively, the damn thing seems to be a sort of flash cartridge. Back: http://moogle-tech.com/diagnostic/n64tc_back.png Front: http://moogle-tech.com/diagnostic/n64tc_front.png The back side of the board has a 13x2 pin header that comes out the back of the cartridge, an Altera FLEX EPF8636AQC160-4 FPGA, a standard CIC-NUS-6102 chip, and a small 8-pin chip marked BU9850. The front side of the board has four Sharp LH28F016SUT-70 flash ROM chips and an Altera EPC1213 LC20 chip (a "Configuration Device", presumably sends config data to the FPGA). Interestingly, there is an unpopulated spot right next to the FPGA for a 5x2 pin header. The FLEX 8000 series of FPGA from Altera has a JTAG interface that is traditionally accessed via a 5x2 pin header. I've also uploaded a screenshot of every test mode in the cartridge to my webspace, http://moogle-tech.com/diagnostic/SDC10006T.JPG through SDC10037T.JPG If you want to see a video of the test, I've uploaded one to http://moogle-tech.com/diagnostic.mpg Lastly, since the video doesn't have any audio, I recorded the audio tests separately and uploaded them here: http://moogle-tech.com/audiotest.mp3 If anyone has any questions, I'll be happy to answer them. EDIT: As an aside, I'm *trying* to figure out how to dump the cartridge so that I can use it to test the N64 implementation in MESS. Obviously it'd be for my own private use, as I don't intend to support piracy. However, my Doctor V64 (which I use to run test code on my N64) is unable to dump it. It's able to detect that the cartridge is a 64Mbit cart, but it ends up dumping blank data. I'm almost wondering if the FPGA on the board only unlocks ROM access if it's satisfied that it's an N64 attempting to access it.
Wow, very good post. Thanks for the info :thumbsup: I have always been curious of those carts as well.
As far as I know, the software on it can be uploaded via it's JTAG interface. Any intresting finds already? Did you manage to dump it? I was thinking to get one too.
If it was mine I'd populate that 2x5 pin header and try reading it with the Altera software - the freeware version should be able to do what you want. You can set a security bit in those FPGAs (prevents reading) but they might have forgotten... Failing that you could probably just desolder the flash chips to dump them but it's not exactly trivial! I would expect the FPGA to unlock the flash chips for writing when used with a flash-cart writer or similar, rather than having the data flow through it, but then again I'm not sure what they'd need one for in the first place. Definitely interesting Stone
They could be using the FPGA as a mapper, who knows? The Jaguar flashcarts worked similarly, they had a GAL in them which handled all the reprogramming logic. On those you had to put the Jag in a special mode (accessed through the dev BIOS) and then you could squirt data into it from a PC. Pain in the arse to make it work, though... As for the N64 one, you could try deliberately breaking a trace in a working unit to see if the cart can pick it up / what it did if it did detect a fault? Stone
I don't know if I'd call it a mapper, but without a doubt the FPGA implements the address counter... It's not likely that the cart is made for actually flashing games or any other software to it, probably the program is on Flash because it was cheaper than developing a making a mask ROM for a few test carts, after all the FPGA is needed for the top interface anyway (whatever it does). There's not a lot that can be probed from the cart slot so the test connection must just relay data to another test device.
Its actually intresting that even with a bottom slot unit the N64 doesn't get recognized by the test cart.
Sorry for being so incommunicado, my day job is really eating up most of my time. Actually, that's pretty much exactly what I plan on doing. At some point either this week or next I'm going to be posting the cartridge off to Australia to have it taken care of by Guru, who handles pretty much all of the PCB dumping for the MAME team. He's got the surgeon-hands necessary to desolder and resolder the flash ROMs, has taken care of much more difficult challenges without issues, and apparently they're of a type that he can pretty much do in his sleep. Yeah, I'm considering asking Guru to throw a header on there as well and then not worry about fitting the PCB back into the surrounding cartridge, just for kicks. As for CIC issues, I'm not entirely convinced of that. It has a 6102 type CIC, which is the same type used in Super Mario 64 and very nearly every other N64 game. I'll do that in a month or so, depending on whether or not I get a quarterly bonus. I already have two N64s, but one of them is my main N64 and the other is already going to be having its major chips decapsulated so as to confirm or disprove my theory that the PIF is actually a microcontroller with embedded ROM, which will ultimately destroy the PCB itself.
But it doesnt work with it, right? The DocV64 connects from the bottom, meaning from Domain 2 instead of Domain 1 - for what we know the cart could be in Domain 3 as well (althoug that sounds incredible). A friend had the same kind of problems with some flash carts, dumping them with the V64 didn't work.