TUT: Slowdown-free Gradius 3: Building SNES SA-1 Conversions

[6t8k]

OK so I just did a quick test, as you got me thinking about the 1 chip issue. I managed to get my working Japanese cart to boot fine on the PAL 1 chip using the adapter. So it looks like there isn't an issue with the game on 1 chips per se. It's looking more and more like the SA-1 chip is the culprit for the issues I was having. I'll do some more testing with the PAL European tour cart on Sunday.

Ah, excellent That should indeed eliminate the 1-chip / 3-chip motherboard difference as a factor for SA-1 patch (in)compatibility.

[Thor87]

Hi @6t8k, but of an update for you.
I have done quite a few bits to try and get the PAL version to work, but to no avail. I'll go over what I have done so far.

I replaced the SA-1 chip with a chamfered edge one. Same boot crash issue where it only shows the white boxes
Swapped the ROM for the original PGA ROM to confirm SA-1 was working OK. Passed this test as the game booted and ran fine
Swapped the ROM for the working Japanese version of Gradius, and this had the exact same booting issue, stuck on the white boxes
Put the ROM chip off the PAL version onto the Japanese version and this runs fine.
Removed the RAM and inspected the pads, but everything looks fine.

So the ROM chips are both working fine on the Japanese build, the SA-1 is working fine but both dot and chamfer behave the same, and the game runs fine with the original ROM chip of PGA European tour on it. The last thing I can try is swapping the RAM off the working Japanese version and seeing if that changes things, as maybe it's a faulty RAM chip. But this has definitely got me very confused.

On the plus side all this soldering practice has really helped improve my soldering skills, which was one of my main aims of this project, so that's a win!

[6t8k]

Hm, that's a pity. While sample size was small, a change in the package coinciding with a change in circuit design, in turn leading to some nuanced changes in behavior, would have been plausible. It's inconvenient if one intends to build a conversion and fishes out a non-working exemplar. But what's more important is that the patches can be improved to work with all of them, so that one wouldn't have to worry about this anymore.

Indications are that officially released ROMs that make use of the SA-1 work with all SA-1 chips. Obviously, the patches do something that official ROMs don't, but comparing the code introduced by the patches with the code of official SA-1 ROMs may be like looking for a needle in a haystack, the cause may be timing-related et cetera. So the next step would perhaps be to logic-analyze the SA-1 pins to get an idea of what happens after the SNES system is powered on, which, given the existence of different SA-1 variants, would also have its own merits with regards to emulation accuracy / preservation. Perhaps the smaller but also affected SA-1 speed test ROM could be a good starting point. The endgame would be an eventual decapsulation, imaging and analysis of the die, as has been done and is striven after regarding other chips, ideally different variants so that they can be compared. But I think chances are good that much could be learned already without this nontrivial and time-consuming procedure.


Just as a note: the old-school way of making (a good share of) games from one region work on a console from the other region, was to disable the console's CIC by lifting pin 4 of the CIC. It was brought to my attention that with SA-1 games, it's different: some exemplars of the SA-1 chip check for the presence of a CIC signal of the correct region (if it's absent or of the wrong region, they refuse to work), while others, apparently, aren't bothered about the lack of a signal and only refuse to work if they detect a signal of the wrong region. This reminded me of the old observation that "there are meant to be 2 versions of [Super Mario RPG] available, one will work on an PAL SNES with the lockout chip disabled, the other won’t. But there’s no way of knowing which is which by looking at the cart" (see here). What was actually going on was/is probably that there are multiple versions of the SA-1 chip, and more games than just SMRPG affected by that variance – but there’s no way of knowing which is which by looking at it. From e.g. your and Arthrimus' findings (all other things being equal, an official ROM worked while a patched one didn't) results that a difference in CIC signal processing did not cause the failure. But maybe differences in CIC signal processing behavior correlate with differences in patch compatibility. Merely another working hypothesis.

A faulty SRAM chip could at this point still be the cause for your PGA European Tour board, if patched Gradius III utilizes more SRAM at the beginning than the former (which should be a good bet: PGA European Tour uses an 8 kByte / 64 kBit chip, and I believe the SA-1 patches transfer quite a lot of stuff into BW-RAM at the beginning), and if only some higher addresses / cells of the chip return garbage data. Unlikely but possible.

[6t8k]

Vitor has released an SA-1 enhanced version of Super R-Type

Download: https://github.com/VitorVilela7/SA1-Root/releases
Side-by-side comparison: https://www.youtube.com/watch?v=cF7DNnyKJYU

It's the first SA-1 patch to use the SA-1 in parallel with the SNES CPU, and to use the SA-1 as the master (coordinator) of the game instead of the SNES CPU. [1] Furthermore, it only requires 32KB of SRAM. [2]

[Josh128]

Awesome! I was asking about that specific game earlier. Will have to slap it on my SD2SNES ASAP.

[Josh128]

Tried the SA-1 modded Super R-Type today, its fantastic! There is no visual slowdown whatsoever in at least the first 3 levels on the default (easy) mode. Curiously though, in level 3 I noticed some audio slowdown in the music track though-- I thought it was just me at first, but I heard it several different times as I was getting my ass handed to me and playing over and over. Very strange that the audio would slow down while the graphics absolutely did not. A bug / side effect of the SA-1 mod perhaps? In any case, it was brief and a non-issue for the most part. Maybe it has something to do with the new coordination hierarchy of the SA-1 vs CPU for this title.

Like Gradius 3, this game is brutal at full speed with no slowdown. Incredible achievement by Vitor.

[Super Joe]

Tried the SA-1 modded Super R-Type today, its fantastic! There is no visual slowdown whatsoever in at least the first 3 levels on the default (easy) mode. Curiously though, in level 3 I noticed some audio slowdown in the music track though-- I thought it was just me at first, but I heard it several different times as I was getting my ass handed to me and playing over and over. Very strange that the audio would slow down while the graphics absolutely did not. A bug / side effect of the SA-1 mod perhaps? In any case, it was brief and a non-issue for the most part. Maybe it has something to do with the new coordination hierarchy of the SA-1 vs CPU for this title.

Like Gradius 3, this game is brutal at full speed with no slowdown. Incredible achievement by Vitor.

It’s indeed quite superb. If only Irem could of treated us to checkpoints ! With the introduction of the SA 1 hacks, these titles now play like proper coin ops from the era.

[6t8k]

That's interesting indeed. It has been updated to v1.1 (apparently 1.0 wasn't declared stable on original HW), do you still encounter that audio phenomenon with that? In any case, it's important that any remaining bugs get relayed to Vitor so he can analyze/fix them.

I'll sooner or later have to build myself a cart, there's no way around it.

[Josh128]

v1.1 is the one I used. I need to play the unhacked original and see if the sound does the same thing in the same area. Its a small deal really, just something I noticed.

I wonder if he'll do any more titles? Trying to think of another that could really use the treatment, he really hit the main ones it seems. Maybe UN Squadron or Axelay could use it in a few areas? Just nitpicking from here on out, those titles arent nearly as riddled with slowdown as G3 / SRT.

[Austin]

Very excited to see Super R-Type getting the SA-1 treatment. Some boss moments in particular are like different fights all together now. I'll probably still play the original when it comes to trying to actually complete the game on the higher difficulties, but I love having the option to play it via the SA-1 conversion as well. Here's to hoping more slowdown-ridden games get the conversion treatment.

[Danexmurder]

I've tried to do this mod using the Shining Scorpion Donor PCB but haven't had any luck. I tried using the SA-1 Origin version but couldn't get it to work. I double checked my work, tested continuity on everything but no dice. The game just hangs at the hash screen. I actually tried it on a second donor board but that didn't work either. The part I'm confused on is during the padding step. After padding it to 4mb I don't understand where to find the hashsum in Ucon64. I did fix it using the --chk command.

The Checksum I get for CRC32 is 0x4c3edb9c

I ripped my own NTSC-U version. I'm wondering if this issue has to do with the padding.

I've tried the game on my 1-chip 01 North American console and my Analogue Super NT but haven't had any luck so far. I'd appreciate some advice. Thanks!

[6t8k]

I've tried to do this mod using the Shining Scorpion Donor PCB but haven't had any luck. I tried using the SA-1 Origin version but couldn't get it to work. I double checked my work, tested continuity on everything but no dice. The game just hangs at the hash screen. I actually tried it on a second donor board but that didn't work either. The part I'm confused on is during the padding step. After padding it to 4mb I don't understand where to find the hashsum in Ucon64. I did fix it using the --chk command.

The Checksum I get for CRC32 is 0x4c3edb9c

I ripped my own NTSC-U version. I'm wondering if this issue has to do with the padding.

I've tried the game on my 1-chip 01 North American console and my Analogue Super NT but haven't had any luck so far. I'd appreciate some advice. Thanks!

Did you replace the SRAM chip on your game PCB with a 128KByte / 1024Kbit one as needed? Which chip did you use for it?

It's not strictly necessary to correct the SNES-specific internal ROM header checksum as real hardware does not check it. I've mentioned that step mainly for orderliness' sake, you should be able to exclude it as a source of error.* The sha1 hashsum on the other hand, as used in the opening post, provides a generic and convenient way to ascertain that the contents of two files are the same. You can use the crc32 value for the same purpose here.

About the padding (I assume you're using the M27C322 EPROM), the crc32 value I get after padding to 4MB / 32Mbit does not reproduce yours, internal ROM header checksum corrected or not. Before padding, the file should have the following crc32 values/sha1sums:
R= Step & crc32 & sha1 R= Original US Gradius III ROM as read out from your cart & cd973979 & 7e62203a4198e9404eb7b076802c09786e5a63f4 R= After SA-1+Origin patch has been applied & 45611e5e & 48548fac3857a042012d487f1483f7a33fae0ac8
After padding, the values depend on the size the ROM file was padded to.

I've just patched an original US Gradius III ROM with Gradius-III-Origin-USA-v16.bps using Flips, then expanded it to 4MB / 32Mbit using Lunar Expand, and finally corrected the internal ROM header checksum using ucon64 --chk. The resulting sha1sum is now 26ccb6525bb3461d289033bc6e47518b87997ba5 - if you're getting the same then your ROM file should be ok and ready to go onto the cart (of course assuming expansion to 32Mbit as one would do for the M27C322). For obtaining the sha1sum of a given file I've referenced other commands in the opening post like certutil for Windows or sha1sum for Linux, but you can also display it using ucon64 like so: ucon64 --sha1 path/to/your/file.

* If you need it, you can find the internal ROM header checksum near the end of ucon64's output just above the crc32 value. After expansion to 32Mbit, it should read:

Spoiler

Checksum: Bad, 0x71e1 (calculated) != 0x71de (internal)
Inverse checksum: Bad, 0x8e1e (calculated) != 0x8e21 (internal)

before correction and

Checksum: OK, 0x71e1 (calculated) == 0x71e1 (internal)
Inverse checksum: OK, 0x8e1e (calculated) == 0x8e1e (internal)

after correction.

Gradius-III-JPN-v16.bps and Gradius-III-USA-v16.bps (standard SA-1 patch) are by the way unchanged from the previous Gradius-III-JPN.bps and Gradius-III-USA.bps (labelled here as v1.5).

[Danexmurder]

I've tried to do this mod using the Shining Scorpion Donor PCB but haven't had any luck. I tried using the SA-1 Origin version but couldn't get it to work. I double checked my work, tested continuity on everything but no dice. The game just hangs at the hash screen. I actually tried it on a second donor board but that didn't work either. The part I'm confused on is during the padding step. After padding it to 4mb I don't understand where to find the hashsum in Ucon64. I did fix it using the --chk command.

The Checksum I get for CRC32 is 0x4c3edb9c

I ripped my own NTSC-U version. I'm wondering if this issue has to do with the padding.

I've tried the game on my 1-chip 01 North American console and my Analogue Super NT but haven't had any luck so far. I'd appreciate some advice. Thanks!

Did you replace the SRAM chip on your game PCB with a 128KByte / 1024Kbit one as needed? Which chip did you use for it?

It's not strictly necessary to correct the SNES-specific internal ROM header checksum as real hardware does not check it. I've mentioned that step mainly for orderliness' sake, you should be able to exclude it as a source of error.* The sha1 hashsum on the other hand, as used in the opening post, provides a generic and convenient way to ascertain that the contents of two files are the same. You can use the crc32 value for the same purpose here.

About the padding (I assume you're using the M27C322 EPROM), the crc32 value I get after padding to 4MB / 32Mbit does not reproduce yours, internal ROM header checksum corrected or not. Before padding, the file should have the following crc32 values/sha1sums:
R= Step & crc32 & sha1 R= Original US Gradius III ROM as read out from your cart & cd973979 & 7e62203a4198e9404eb7b076802c09786e5a63f4 R= After SA-1+Origin patch has been applied & 45611e5e & 48548fac3857a042012d487f1483f7a33fae0ac8
After padding, the values depend on the size the ROM file was padded to.

I've just patched an original US Gradius III ROM with Gradius-III-Origin-USA-v16.bps using Flips, then expanded it to 4MB / 32Mbit using Lunar Expand, and finally corrected the internal ROM header checksum using ucon64 --chk. The resulting sha1sum is now 26ccb6525bb3461d289033bc6e47518b87997ba5 - if you're getting the same then your ROM file should be ok and ready to go onto the cart (of course assuming expansion to 32Mbit as one would do for the M27C322). For obtaining the sha1sum of a given file I've referenced other commands in the opening post like certutil for Windows or sha1sum for Linux, but you can also display it using ucon64 like so: ucon64 --sha1 path/to/your/file.

* If you need it, you can find the internal ROM header checksum near the end of ucon64's output just above the crc32 value. After expansion to 32Mbit, it should read:

Spoiler

Checksum: Bad, 0x71e1 (calculated) != 0x71de (internal)
Inverse checksum: Bad, 0x8e1e (calculated) != 0x8e21 (internal)

before correction and

Checksum: OK, 0x71e1 (calculated) == 0x71e1 (internal)
Inverse checksum: OK, 0x8e1e (calculated) == 0x8e1e (internal)

after correction.

Gradius-III-JPN-v16.bps and Gradius-III-USA-v16.bps (standard SA-1 patch) are by the way unchanged from the previous Gradius-III-JPN.bps and Gradius-III-USA.bps (labelled here as v1.5).

Thanks so much for the detailed response. I did not swap out the SRAM as I was under the impression that game already had a 128Kbyte SRAM. Seems like that would certainly cause it not to work. I'll get it replaced and report back. From there I'll dig into the Checksum.

[Jon Nielsen]

Hey

First off - thanks for this guide and all the great pictures and infos posted.

I'd done Super R-Type previously because it was easier (not requiring SRAM replacing), but yesterday I finally manned up and did the real deal - Gradius 3 with SA-1 root + origin patch.

Anyway. For reference, the following worked for me:
- using SHVC-1L5B-20 donor (Mini Yonku Shining Scorpion - Let's & Go!!)
- replacing SRAM with 1024kbit module IS62C1024AL-35QLI-TR
- padding the ROM with itself 8 times for m27c322 EPROM instead of using expand tool + header fix (I believe the game won't care since it shouldn't be reading entire 32mbit ROM)
- SA-1 adapter from ThePoorStudentHobbyist - much better quality vias than what I got from an OSHPark order

Works fine. Tested by playing until I wished there were slowdowns

[Jon Nielsen]

Just a note on donors:

I had 1L3B donor (PGA Tour 96, 64kbit SRAM) that was PAL which would defeat the slowdown-free purpose of the mod.

Deciding to use it instead for the Super Mario RPG 50Hz hack I found that while it may have the extra SRAM pads, A13 was not connected to SA-1 pin 103. Being a 256Kbit SRAM game, this would not work.

So anyone attempting to do this with a 64kbit donor may want to connect that line on addition to the extra pads for the 1Mbit module:

Spoiler

[Danexmurder]

I finally had a chance to come back to this and work on it some more. I had another board to use and decided to start from scratch. I double checked everything in ucon64 and after re-patching and padding got the exact same sha1sum that 6t8k posted above for the SA1 origin patch. (Thanks again for the detailed response.)

I replaced the sram with this one.

https://www.digikey.com/en/products/det ... TR/4733138

I then burned my M27C322 chip with the correct .SFC file.

It booted to a black screen. Should I be changing the file extension to .bin? Would that effect anything?

I'm using a Flashcat USB Xport with the Dip42 adapter and have it set to 32mbit.

*EDIT*

I also tried the same thing after changing the file to a .bin and get the same result.

I also put both versions I made into my Super NT to use the copynes and came up with some interesting results.

When the .bin version is read the name is says it is "Gradaus" and is 16kb. I double checked the rom before and after burning. It is 4096kb.

The .SFC version is read with a totally garbled name but it is recognized as a 4mb file. Really strange.

[AndehX]

I'm just trying this out now, with Super Mario World and just getting a blank screen. I assume the 1024Kbit SRAM is required for these to even boot? I'm using 1L3B-02 and 11 with 27C322 and both show the same issue. Is the blank screen normal behaviour when you don't have 1024Kbit SRAM installed?

Edit: Tried with R-Type, which only requires 32KB SRAM, and no dice. Still just a blank screen. I'm programming my 27C322's with a TL866 programmer (with an adapter so I can program 512KB chunks, switching banks between each one)
I've tried padding the rom to 32Mb, and also leaving it at 8Mb, same results. Is padding the rom necessary? Any suggestions would be appreciated.

Edit 2: ok I did a silly. I wrongly assumed that the SA-1 carts i have, had enough SRAM on them to work with r-type. I actually had some 32KB SRAM chips lying around from some game boy carts I was working on, they just so happened to match the SRAM used in the SA-1 carts. Swapped one in and it fired right up.
Off to AliExpress to order more SRAM chips i guess.

[Jon Nielsen]

I'm just trying this out now, with Super Mario World and just getting a blank screen. I assume the 1024Kbit SRAM is required for these to even boot? I'm using 1L3B-02 and 11 with 27C322 and both show the same issue. Is the blank screen normal behaviour when you don't have 1024Kbit SRAM installed?

Edit: Tried with R-Type, which only requires 32KB SRAM, and no dice. Still just a blank screen. I'm programming my 27C322's with a TL866 programmer (with an adapter so I can program 512KB chunks, switching banks between each one)
I've tried padding the rom to 32Mb, and also leaving it at 8Mb, same results. Is padding the rom necessary? Any suggestions would be appreciated.

Edit 2: ok I did a silly. I wrongly assumed that the SA-1 carts i have, had enough SRAM on them to work with r-type. I actually had some 32KB SRAM chips lying around from some game boy carts I was working on, they just so happened to match the SRAM used in the SA-1 carts. Swapped one in and it fired right up.
Off to AliExpress to order more SRAM chips i guess.

It's my understanding that 1024kbit is definitely needed for those hacks which specify it. I've not been able to get Contra, Mega Man X or Super Mario World SA-1 hacks to work. Contra has known issues with real hardware, Mega Man X might also - but I don't know. Super Mario World, however, should work. All have the same symptom though. Black screen as you mention. For SMW I was using v1.40 vanilla patch. Curiously it did start up once out of 20+ tries on various SNES test setups. Contra and R-Type work perfectly.

TL;DR same experience as you, so far "only" Gradius and R-Type have worked without issue.

[AndehX]

I've since gotten them to work. I installed 1MB SRAM and they're working fine. the 1L3B carts require you to manually wire up address line A13 to pin 103 of the SA-1, but that's simple to do.

[ChurchOfSolipsism]

Like Gradius 3, Super R-Type may be the prime candidate for the SA-1 makeover.

Maybe he wants to include safepoints in the middle of the stages to finally make this stupid game playable...

[Jon Nielsen]

I've since gotten them to work. I installed 1MB SRAM and they're working fine. the 1L3B carts require you to manually wire up address line A13 to pin 103 of the SA-1, but that's simple to do.

SMW as well? Which version of the patch, 1.40 or 1.41? Maybe I'll give it another go

[AndehX]

SMW requires the same modifications. Not sure which version im using. Whatever the latest one is.

[Syntax]

Like Gradius 3, Super R-Type may be the prime candidate for the SA-1 makeover.

Maybe he wants to include safepoints in the middle of the stages to finally make this stupid game playable...

Git gud scrub.

[Danexmurder]

Sorry to necro-bump but I thought this info might be helpful for folks.

I was finally able to get this process to work. I was able to make R-Type, Gradius 3, and Super Mario World Carts. It turned out there were two key problems for me.

1. For my Flashcat USB programmer the patched roms HAD to be in .bin format. If I tried to burn .SFC files they wouldn't work.
2. The ram I was using didn't work. When I swapped out for AS6C1008-55SIN (https://www.digikey.com/en/products/det ... IN/4234577) it worked. I was previously using IS62C1024AL-35QLI-TR.

So if you are having problems those are two more areas you can check. Thanks again to everyone in this thread for posting what did and didn't work for them.

[Danexmurder]

I'm just trying this out now, with Super Mario World and just getting a blank screen. I assume the 1024Kbit SRAM is required for these to even boot? I'm using 1L3B-02 and 11 with 27C322 and both show the same issue. Is the blank screen normal behaviour when you don't have 1024Kbit SRAM installed?

Edit: Tried with R-Type, which only requires 32KB SRAM, and no dice. Still just a blank screen. I'm programming my 27C322's with a TL866 programmer (with an adapter so I can program 512KB chunks, switching banks between each one)
I've tried padding the rom to 32Mb, and also leaving it at 8Mb, same results. Is padding the rom necessary? Any suggestions would be appreciated.

Edit 2: ok I did a silly. I wrongly assumed that the SA-1 carts i have, had enough SRAM on them to work with r-type. I actually had some 32KB SRAM chips lying around from some game boy carts I was working on, they just so happened to match the SRAM used in the SA-1 carts. Swapped one in and it fired right up.
Off to AliExpress to order more SRAM chips i guess.

It's my understanding that 1024kbit is definitely needed for those hacks which specify it. I've not been able to get Contra, Mega Man X or Super Mario World SA-1 hacks to work. Contra has known issues with real hardware, Mega Man X might also - but I don't know. Super Mario World, however, should work. All have the same symptom though. Black screen as you mention. For SMW I was using v1.40 vanilla patch. Curiously it did start up once out of 20+ tries on various SNES test setups. Contra and R-Type work perfectly.

TL;DR same experience as you, so far "only" Gradius and R-Type have worked without issue.

Just wanted to report back that Mega Man X SA-1 Does work on a cartridge if you pad it properly. Since it is a 1.5mb rom standard padding won't work. You need to copy the last .5mb of the file in a hex editor making it 2mb. From there you just copy and paste everything making it a 4mb Rom. The dudes over at NesDev helped me figure it out. I was also able to get SMW working just fine on a cart.

https://forums.nesdev.org/viewtopic.php ... 41#p283041

[Jon Nielsen]

Just wanted to report back that Mega Man X SA-1 Does work on a cartridge if you pad it properly. Since it is a 1.5mb rom standard padding won't work. You need to copy the last .5mb of the file in a hex editor making it 2mb. From there you just copy and paste everything making it a 4mb Rom. The dudes over at NesDev helped me figure it out. I was also able to get SMW working just fine on a cart.

https://forums.nesdev.org/viewtopic.php ... 41#p283041

Wow! Thanks a lot for the info. I've just verified this on my SA-1 test cartridge.

Actually I came here just now to check if anyone had tried making a Race Drivin' cartridge.

To be honest I think the donor is better spent on Mega Man X

Speaking if which, did you use a SHVC-1L5B-02 or SHVC-1L5B-20 for your cartridge?

Cheers

[Danexmurder]

Just wanted to report back that Mega Man X SA-1 Does work on a cartridge if you pad it properly. Since it is a 1.5mb rom standard padding won't work. You need to copy the last .5mb of the file in a hex editor making it 2mb. From there you just copy and paste everything making it a 4mb Rom. The dudes over at NesDev helped me figure it out. I was also able to get SMW working just fine on a cart.

https://forums.nesdev.org/viewtopic.php ... 41#p283041

Wow! Thanks a lot for the info. I've just verified this on my SA-1 test cartridge.

Actually I came here just now to check if anyone had tried making a Race Drivin' cartridge.

To be honest I think the donor is better spent on Mega Man X

Speaking if which, did you use a SHVC-1L5B-02 or SHVC-1L5B-20 for your cartridge?

Cheers

I ended up putting a socket into a SHVC-1L5B-20 board that I use to test the eproms once I've burned them. So far I've been successful using that set up for Mega Man X, Contra 3, SMW, R-Type, and Gradius 3. The only one I haven't tried out is Race Drivin.

[Josh128]

I wasnt even aware he had done a MegaMan X conversion. Fairly recent development, I assume?

[Danexmurder]

I wasnt even aware he had done a MegaMan X conversion. Fairly recent development, I assume?

Looks like this one was done by a user named Bosn over at Romhacking

https://www.romhacking.net/hacks/5145/

Based on Vitor's work.

[jd213]

Any specific programmer recommendations for these SA-1 hacks? Did a search and found someone one NesDev talking about one from Aliexpress that could read but not write the ROM: https://forums.nesdev.org/viewtopic.php?t=23754

I can solder OK but never had a programmer before, so not sure what to get. If possible, would like to get one that can also do the ROMs for the Turtles in Time PCB conversion: https://www.arcade-projects.com/threads ... post-61296