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