Verify CRC without dumping

[DerVerruckteFuchs]

Is it possible to verify a ROM's CRC without dumping it to the SD card? This would be very useful to help verify if a game cartridge is legit or not. Given that the cart reader is fairly portable, it would be great to use when shopping around for game carts. Especially in an environment where fake GBA and N64 carts are pretty common. It would be great to avoid dumping a game that has not been purchased (yet, if legit).

[Ancyker]

This is a cool idea. It's not foolproof but it's cool. The GB Operator from Epilogue attempts to do this by seeing if the cartridge can be written to. It might do other things as well, but this seems to be the most common method of detection that it uses at the very least. I don't have many counterfeits to test with, so this may just be my limited sample size.

We could add both a write test and CRC check. Even if the cartridge is legit, a CRC test can be helpful as it might be able to uncover other issues with the cartridge unrelated to being fake. If some of the chips are dying and spit out garbage data the CRC would fail.

However, doing this in the present firmware would require an almost rewrite of many of the cores, especially if trying to avoid using significantly more PROGMEM. I don't think that's worth the time investment. Not because it's not a good idea, but because I'm already rewriting the firmware for a different reason.

I'm not super far along in that yet, so writing the new firmware with these features in mind should add a minimal amount of time to the development of the new firmware for what is, in my opinion, quite a bit of benefit. If I write it from the ground up with these features in mind, which I now plan to, their impact on PROGMEM usage should be negligible.

It might be up to others to add the write test to systems for which I don't have a rewritable cartridge. I don't want to try to blind-write a feature like a write test because for all I know the test I write could erase the cart or something which would not be good. But, I can still write all the cores in a way it can easily be added without much overhead.

This is a good suggestion in my opinion. I did already plan to add the write test, but I had not considered a CRC test. That's a nifty idea, especially since the main reason for the firmware rewrite is to make supporting other hardware versions easier. The #ifdefs are getting a bit unwieldy and the new firmware will make it much easier to read and edit the code and only affect the hardware version(s) you want to affect.

Also, one reason I was already adding the write test to the firmware was that HW7 has an optional built-in battery, making it especially suited for this task. It differs a bit from how HW4 had a battery. When it has one, it does not have a different port for charging and data. It has one USB Type-C port for both data and charging. It's also a dual-role port, meaning the port can both power/charge HW7 or be used to power/charge something else, so you could recharge your phone while you are at a con shopping for games. A bonus if you do that is you can also control HW7 with your phone, letting you omit the display and making it even more portable.

I should mention that HW7 is overkill for what we are doing and the cost of it will reflect that, especially if you want all the features. But, I wanted to make a hardware version that would just be the "final form" of the OSCR. I literally added everything I could think of, it even has Ethernet and HDMI, as well as USB host support. I'm talking with some MiSTer devs and we're trying to add support for being able to dump ROMs and sync saves right to the MiSTer. It won't be full hardware emulation like an Analogue Pocket sadly because the MiSTer doesn't have enough IO pins available to hit the speeds we'd need to hit. But, it should still be pretty cool and some things, like the GB Camera, can likely still be exposed via USB, there will just be some latency in the camera vs real hardware.

That's why I skipped HW6. I plan to go back and make a HW6 that is much more slimmed down and cheaper. It will be based on the RP2040 (the chip the Pi Pico uses) and more DIY and budget-friendly. HW7 is not DIY-friendly at all, not only does it have no through-hole components, but it also has a significant number of leadless and BGA packages, meaning hot air, a reflow oven, or a hot plate is absolutely mandatory if you want to assemble it yourself. HW7 is being designed to be machine-assembled, it's not DIY-friendly. Many of the chips used to give it the cool features it offers only come in BGA or leadless packages, so since this could not be avoided I just went all-in on it.

Currently, I estimate the sale price of HW7 (assembled) to be $200-300 depending on features like the optional battery and optional USB-C DisplayPort alt-mode. That might not sound like much more since currently assembled HW5s go for about $200-250. However, the new SMT version of HW5 should result in assembled HW5s costing around $130-150, and HW6 should cost around $100 assembled despite being better than HW5 in every way imaginable. So, it is actually quite a lot more if you look at it that way.

Anyway, that was quite a bit more info than you were probably expecting. I just wanted to let you and anyone going oh hey that's a cool idea know that I got it covered and you can consider it in the works. :)