mikejmoffitt
Mickey's Coach
- Joined
- Feb 6, 2014
- Posts
- 578
I've expressed disinterest in the [xx]-in-1 carts many times, mostly for their unreliability and inconsistency in build quality, but also for using 3.3V IO on a 5V bus which is bad for both sides in the long term. However, I don't have a better alternative to suggest for finding elusive games to play casually. Burning EPROMs and making "reproductions" (a fancy word for bootleg) is shifty and also time consuming, not to mention expensive.
These days, most systems have Everdrive-esque solutions, where a RAM cart loads an image from an SD card or USB and allows the system to run from that. The MVS and AES don't have such a thing, though. Let's talk about why not. From this point on when I say "RAM Cart" I'm referring to the usage model I described above, with an Everdrive being a popular example*
*not counting the few of them which are true flash carts that reflash themselves when games are selected
The Genesis received the first Everdrive, if I recall, and it's not too complicated as the only bus is the main CPU bus. The system must mostly just emulate a parallel 16-bit ROM, save for the more complicated SSF2 mapper. The NES is one of the more complicated systems to make a RAM cart for because it has two busses (CHR and PRG) as well as memory mappers. In this way, the NES is actually a lot closer to the Neo-Geo than others, because the Neo-Geo has SIX busses (68000, Z80, YM2610-A, YM2610-B, FIX, CHAR)! That's insanity - hundreds of pins of IO! On top of that, very late games had more complicated bank switching schemes and encryption. Even less fun is that most games used the SNK-PCM IC to multiplex the YM2610 busses and use just one set of V Roms. The upside is less ROMs, but the downside is the cartridge becomes a little more complicated.
That said, it's not an impossible task, but it's definitely a lot of work compared to other systems. The easiest way to work around the encryption would be to use decrypted ROM sets, but that still leaves the annoyance of recreating SNK-PCM on an FPGA/CPLD and implementing the few bankswitching schemes that are there.
----------------
Despite writing about all of the difficulties involved, I think it would be a great project.
The 68000 bus would be no problem - fixed P1 ROM, and a very simplistic bankswitching scheme for P2. Since the Neo-Geo has all of the other data (Graphics, sound, etc) on other busses, the P rom doesn't often have to be very big as it's almost entirely just program code.
The FIX and M1 ROMs are probably the easiest, as unlike the C Roms these didn't have to scale up and become huge as games got bigger. These are just simple 8-bit ROMs too.
The V Roms are less fun mostly because of the SNK-PCM ASIC. For a first prototype it would probably be bootstrapped on a modified original board, and then after that it's mostly just a matter of emulating a 16-bit ROM, not too bad.
The CHAR roms are where the fun comes in, because the different bankswitching schemes must be kept in mind. That said, emulating the many ROM chips isn't so bad, as really they just represent concatenation of data across the character ROM address space.
Has anybody worked on such a project and made any progress or have some input on it?
These days, most systems have Everdrive-esque solutions, where a RAM cart loads an image from an SD card or USB and allows the system to run from that. The MVS and AES don't have such a thing, though. Let's talk about why not. From this point on when I say "RAM Cart" I'm referring to the usage model I described above, with an Everdrive being a popular example*
*not counting the few of them which are true flash carts that reflash themselves when games are selected
The Genesis received the first Everdrive, if I recall, and it's not too complicated as the only bus is the main CPU bus. The system must mostly just emulate a parallel 16-bit ROM, save for the more complicated SSF2 mapper. The NES is one of the more complicated systems to make a RAM cart for because it has two busses (CHR and PRG) as well as memory mappers. In this way, the NES is actually a lot closer to the Neo-Geo than others, because the Neo-Geo has SIX busses (68000, Z80, YM2610-A, YM2610-B, FIX, CHAR)! That's insanity - hundreds of pins of IO! On top of that, very late games had more complicated bank switching schemes and encryption. Even less fun is that most games used the SNK-PCM IC to multiplex the YM2610 busses and use just one set of V Roms. The upside is less ROMs, but the downside is the cartridge becomes a little more complicated.
That said, it's not an impossible task, but it's definitely a lot of work compared to other systems. The easiest way to work around the encryption would be to use decrypted ROM sets, but that still leaves the annoyance of recreating SNK-PCM on an FPGA/CPLD and implementing the few bankswitching schemes that are there.
----------------
Despite writing about all of the difficulties involved, I think it would be a great project.
The 68000 bus would be no problem - fixed P1 ROM, and a very simplistic bankswitching scheme for P2. Since the Neo-Geo has all of the other data (Graphics, sound, etc) on other busses, the P rom doesn't often have to be very big as it's almost entirely just program code.
The FIX and M1 ROMs are probably the easiest, as unlike the C Roms these didn't have to scale up and become huge as games got bigger. These are just simple 8-bit ROMs too.
The V Roms are less fun mostly because of the SNK-PCM ASIC. For a first prototype it would probably be bootstrapped on a modified original board, and then after that it's mostly just a matter of emulating a 16-bit ROM, not too bad.
The CHAR roms are where the fun comes in, because the different bankswitching schemes must be kept in mind. That said, emulating the many ROM chips isn't so bad, as really they just represent concatenation of data across the character ROM address space.
Has anybody worked on such a project and made any progress or have some input on it?
