Both are disabled in options.h by default since they push the RAM usage over the limit resulting in corrupted LCD output.
Global log outputs all info to OSCR_LOG.txt in the root of the SD.
no-intro calculates the CRC32 of a Gameboy ROM and if found in the database renames it to no-intro naming scheme.
Added support for SD Card Add-on to use RTC for Creation/Modification Date/Time stamps.
Added code to support RTC such as startup, automatically updating time based on date compiled, and allowing for any script to add a Date/Time stamp.
In option.h add // in front of #define fastcrc and remove // in front of #define slowcrc to change CRC32 calculation to slow.
// Define CRC method for dumping N64 ROMs
//#define fastcrc //crc will be calculated during dumping from memory
#define slowcrc // crc will be calculated after dumping from SD card
Uncomment #define clockgen_installed in options.h and switch CLK1 switch to ON position. With Adafruit clockgen the eeprom now runs at the correct 2Mhz.
Thanks to skaman.
The code does a deeper sanity check of the header data when initializing the cart. It avoids having to constantly press buttons to reinit the cart. Carts can still not initialize the MBC properly but that's normal for the WonderSwan. Clean the pins on the cart and check that the cart and adapter are seated properly. If the cart doesn't unlock immediately, then let the sketch run for a bit. For stubborn carts, a power cycle might be necessary.
The sketch fixes a few typos, removes some trailing spaces, and adds another ROM size (used by Benesse Pocket Challenge V2 carts).
The code change only affects readCHR(). It shortens the check to a single byte but that is enough to identify the four VRC4e carts. The original list of VRC4e carts that I referenced only showed Boku Dracula-kun and Tiny Toon Adventures. I found out that all four of the Mapper 23 VRC4 carts use the VRC4e submapper. Mapper 23 includes VRC4f but there are no known examples (BTW, VRC4f = VRC2b).
IMPROVEMENTS:
Added read/write support for all Serial EEPROM cart types (Acclaim Type 1, Acclaim Type 2, Capcom, Codemasters, EA, and Sega). Capcom EEPROM code is untested but should work the same as Sega EEPROM code.
Fixed SRAM code to handle all SRAM types.
Added identification of SRAM carts that have bad headers.
Added support for Super Street Fighter 2.
WARNINGS:
Serial EEPROM writes take time to complete.
Serial EEPROM support was tested using Serial Output only. Support using the OLED Display might require some timing adjustment as display_Update() on Serial translates to delay(100).
ADDITIONAL NOTES:
I've included a save file for NBA Jam T.E. Rev 0.
NBA Jam T.E. Rev 0 has faulty code that will erase the EEPROM when the cart is played on the console. The solution proposed by the publisher was to play the cart with two different sets of initials (XXX, NBA) to initialize the EEPROM. The included save file was created after doing this special initialization. My tests of the EEPROM show that it will still erase after the special initialization.
I did some additional tests and found a potential solution. Write the included save file to the cart. Play the cart on the console as normal. Create new saves as needed. When done playing, HOLD THE RESET BUTTON DOWN BEFORE TURNING THE CONSOLE OFF. YMMV.
Sometimes the Gameshark will lock itself up, in this case it helps if you put a 6102 game into the Gamesharks slot and then put both into the Cart Reader and just start dumping the rom as if it was a game.
For some reason I can only read or write the first 128KB while the second 128KB remain 0x00.
You might have to re-calculate your homebrew rom's checksum if you had to trim it down to 128KB. In this case you can use chksum64.exe out of the libdragon devkit. Not sure if this is needed though.
And yes by "SST29LE010 N64 Repro" I'm jokingly referring to the Gameshark.
I wanted to turn the Gameshark into an import adapter using Lac's boot emu but the boot emu just restarts itself since the Gameshark isn't switching to the top cart slot.
Sometimes the Gameshark locks up, then you have to plug a 6102 cartridge into the Gamebuster's top slot and then connect both to the cart reader and read the rom. After that it should be accessible again.
Don't use this to update your working Gameshark since you can't read nor write the whole 256KB right now.
But if you have a broken one, have fun. :)
I tested this with a Gameshark V2.0
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
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."
