If you're still using the old 16bit adapter(the one with the additional pins left and right on the snes cart edge) you can enable the menu again by changing one line in Cart_Reader.ino:
// Enable 16bit flash adapter menu
#define enable_flash16
Some cartridges might have differing versions depending on the region they were released to. In most cases, the IC identifies as something else not presently covered by the current code, but they are ABI compatible with the existent FlashRAM supported types.
This will add support for 29L1100KC-15B0 compatible ICs like the MX29L1101.
These two new entries just forward the user to the flashrom functions inside of flash.ino.
I have only tested custom-made 29F033 repros using original SHVC-1J3M-20 and SHVC-1A3M-30 PCBs as shown here: https://github.com/sanni/cartreader/wiki/Reflashing-SNES-Repros
Apparently the step-up converter needs a little delay before it can provide the 12V VPP.
The verify function still does not work though, I have no clue why.
The first 10 words still do not get written though, not sure if I need something like a setup delay or if my eprom is broken.
Too enable the eprom menu for testing 27C322 flashing change the following lines in Flash.ino:
// create menu with title and 3 options to choose from
unsigned char flashSlot;
// Copy menuOptions out of progmem
convertPgm(menuOptionsFlash, 3);
flashSlot = question_box("Select flashrom slot", menuOptions, 3, 0);
In Cart_Reader.ino line 71 change "boolean n64crc = 1" to "boolean n64crc = 0" to disable the CRC32 check when dumping roms. This is useful if you rather calculate the checksums on your much faster computer. Calculating the CRC32 is enabled by default now and can take quite some time.
- The Fujitsu MSP55LV100S consists out of two Fujitsu MSP55LV512 which themselves are just Spansion S29GL256N flashroms. One flashrom is used for the high byte the other for the low byte.
- You can now browse pages with the Serial Monitor's file browser just like you can with the OLED.
Still have the bank switching error when writing, problem is located at line 2159. I can't switch the bank any time before since I need an uneven bank for the 0x5555 command and I can't switch afterwards or it will be too late and everything will be written to bank 1...
I don't have them myself so I can't test but maybe others can.
Flashrom Programmer: Macronix MX29LV320 and MX29LV640 (connected as 16bit flashrom in 8bit mode)
GBA: Intel 4400L0ZDQ0 (Only using the first 32MB)
N64: Fujitsu MSP55LV100S and Macronix MX29LV640 (Fujitsu might have a different sector size)
Almost the same as Macronix MX29GL128E but sector size and write buffer are half the size.
Data pins 0 and 1 are also swapped and it still needs 5V to erase correctly.
The whole GBA code is currently a little bit buggy, so for dumping roms you propbably should stay on the last somewhat stable release V27D.
Reflashing only seems to work with 5V. Probably out of the same reason why some real carts don't work with V28 ... bad read/write timings.
I also might have broken support for the Intel flashrom I added in the last commit...
There is still a bug left when it comes to resetting the flashrom to read mode since I can't find the datasheet to look up the partition sizes. So it might be that the verifying process fails even though the flashing was successful. In this case remove the GBA repro for a few seconds then just dump the rom and compare if the write really failed.
- It seems like flashroms in the 16bit slot like the 29L3211 were accidentally programmed byte swapped up until now and only the 8bit slot worked correctly.
- You can now program files smaller than the flashrom's size without getting a verification error
- Added the special 29F1601 flashrom taken out of the Nintendo Power SF Memory carts
Also re-enabled blankchecking at least until I know this code works reliably.
Writing 64MB takes 40 minutes. I did not optimize yet so it might become faster in the future.
Thanks once again to skaman:
"The problem occurs because of the bank switch to 0xAA (0xAA * 0x4000 = 0x2A8000). I'm assuming that the code you're using writes the bank to address 0x2000 (or similar) then follows with the flash sequence to program the byte. Since 0xAA is also a flash command, the flash chip misinterprets the bank switch as the flash command and misses the command sequence to write the first byte in the bank."
