mattmct5 wrote:
I am also facing this for quite some don't know how to solve it
FWIW, if you have the OSCR/Sanni Cart Reader, it now supports Vectrex and is reported to dump this correctly. I have someone making the Vectrex adapter for me soon. I find it is a good companion to the Maxflash if you are multi-system dumping. Maxflash dumps a bit differently which can give good info for comparison/verification when you see weird stuff. Its ability to overdump Intellivision turned out to be crucial to me verifying some things.
I did lean on Maxflash for older systems and OSCR for new, but OSCR is almost up to supporting everything Maxflash does. OSCR also relies on database files for many systems, while Maxflash doesn't, so sometimes the Maxflash can reveal a true chip size where the OSCR skips the padding (and vice-versa in some cases). The OSCR does require you to either acquire your own PCB, cart connector, and other parts based on the github info, or find someone selling them, which can be more difficult, especially for obscure systems. At least with Maxflash you can always order the adapters here, so long as the shop is around (while OSCR is open source and could continue with entirely new people if needed). Not talking bad about either, just good companions!
I did run into I think my second issue with Maxflash dumping, on a 32kb 2600 cart. It gives a single byte different than OSCR. The 4th to last byte of each 16kb section matches from Maxflash, while the OSCR gives unique values (with the second one matching Maxflash). It seems like the Maxflash may be reading the wrong bank for a single byte on this cart. I actually found that issue on the OSCR with some sizes but contacted the creator of the script and it was corrected. My only other 32kb cart SHOULD match on those two bytes, so the Maxflash produces a valid dump, but may still be reading the wrong bank, while the OSCR reads that one fine. For this other one, I don't have a public source to verify it against, so I'm just going with the OSCR giving unique values for the 2 bytes, as well as this issue being recently addressed on it, as likelihood that it is correct. Even when it had the issue, it copied values like I see on the Maxflash here, it did not make up a random value, which is what it would be doing if it is incorrect.
Sorry for the long reply, but I figure keeping all my discussion in one thread is best given the amount of activity here being low, rather than hoping for people to reply to may different threads. I'd love to talk to some Maxflash experts.