Ah. Thanks for that info, interesting stuff! Might be doing electrical engineering soon, so hopefully this stuff will become easy!
Not if you do an app handling it all on the ngpc - in short do a quick loader menu for the ngpc. I was basically thinking about having the game loaded to an sram chip on selection from the sd card and the atmega mediating between the console and sram chip.
A microcontroller isn't fast enough to arbitrate access to the RAM, you would have to use logic in addition. 32M of SRAM isn't cheap either (at least $20) or really available off the shelf (you'd have to order production). Since games writeback to the Flash, that'd have to be emulated in the logic too... Just imagine performing a read through a MCU lol: interrupt on /ce read r/w strobes and decode read cpu_address_low write ram_address_low read cpu_address_mid write ram_address_mid read cpu_address_high write ram_address_high read ram_data write cpu_data (really you'd need a MCU with a slave parallel port) All that within 150ns or less
Even if you had the best case scenario (50mhz microcontroller, with one instruction per cycle (ha! not likely)) each instruction will take 20ns. This means the above sequence consumes 300ns. A more likely scenario is that each instruction takes 3-4 cycles. Then you are looking at around 1000ns. Ouch. This is where programmable logic shines. CPLD will probably do it for you here.
Then how about just loading the game to the sram and just "shut off" the atmega on completion? Yeah, maybe this is a dead end idea. A flash chip + usb communication would be best, anywhoo you'd need a microcontroller with uart and a ft232rl chip.
Why would you if retail carts are programmable? Not a very good approach because you couldn't program it in-system. If you use a FTDI chip a microcontroller isn't even necessary in the mix, just logic would be suitable. Almost every application is more elegant without a microcontroller. I really don't see what the problem is with a base-programmer unit; that way you'd A) neither have a CPLD nor MCU in the cart to drain the battery B) not have to manufacture carts. The only complication could be that the flash aren't fully programmable. In that case you'd need standard flash, and either patch the games to expect standard flash signatures or add logic to return the SNK signature.
maybe we should ask krizz to make a flasher/dumper? i gues it would be REALLY cheap to be made and lovely to homebrewers too
Hi Please look over these material. It wishes a useful thing. There is a report that challenges making Flashcart using cart of Crush Roller. http://www.personal.triticom.com/~erm/NGPC/CRoller_Cart.txt http://www.devrs.com/ngp/files/DoNotLink/ Cart of NGPC uses FLASHROM, and seems to be able to release protection by applying the voltage of 12V to the RESET pin according to it. I'm sorry in strange English. :redface:
So we know writing to flash is going to be straight forward, however i was just thinking about how to create working carts. Am i right in thinking the protection method is that the pocket BIOS strobes a generic (to all FLASH memory anyway) request to the flash and it returns it manufacturer id? e.g. 0x98 Toshiba 0xEC Samsung 0xB0 Sharp If something else is returned i assume pocket holts. Looking at the scan posted by NTM am i correct in thinking that the ALTERA EPM3032A provides the logic to detect the read of manufacturer and somehow spits out a valid manufacturer id? Interesting.
Yes but other unlock codes could be changed too, like for erasing. The CPLD doesn't have an oscillator so it can't be TOO complex.
Looking at the source code for PokeLink the flash enable/unlock sequence seems to match the standard FLASH standard. Also after looking at a few emulator sources (seach for - void flashChipWrite()) they seem to indicate that the sequences match the FLASH standard. It would be great if the EPM3032A on the bung is only used to catch calls for the manufacturer id, but i guess that would be too easy, i would love to get my new logic sniffer on that thing and confirm. I would love to pickup a cheat pocket and look into this more but they all seem to be going for silly prices on ebay
Admittedly I'm not familiar with CPLD development. If dumping the data off the chip is possible and will help, I'm more than happy to do what I can. Would something like this help me?
From the datasheet: - Programmable security bit for protection of proprietary designs We can be fairly sure the bung device does indeed 'emulate' a Toshiba chip, its any other logic hackary that remains a mystery.
Very little chance it isn't protected, and even if it weren't you wouldn't be able to do anything with the fusemap but make a clone using the same discontinued part. It couldn't really be analyzed.
nah he said he tried that and it destroyed his flash chip... ok guys, first I apologize for re-igniting the thread, but my search for a means of flashing code to my NGPC has brought me here, and it seems a lot of great discussion took place with no conclusion. so whats up?! :Rock:
Yeah, I'd still like to see this come to fruition. So, do you reckon we can re-flash retail carts, or are we back to building a flash cart? If it means purchasing a Bung Linker to examine next time one shows up, that can be done.
I could do sitting down with a bung linker to confirm the logic i have sketched out, it would be nice to confirm that the CPLD isn't doing more than just patching in the correct manufacturer id. As for the hardware, still waiting on a set of 16MB flash chips to arrive from the US. 4 weeks and counting.
Looks like we may have someone working on it: http://www.digital-circuitry.com/index.htm From what I understand Flavor is working with him on making one.
