MiSTer FPGA Forum

I've been wondering how much of a challenge it would be to modify this core to create cores for stuff like Capcom's ZN-1/2, Namco's System 11/12, Taito's FX-1A/B and Gnet?

This seems like a project that would come after a mature console core so this is really just a bit of idle thought. However I have been curious about how much of a leap this would be from just the consoles. There are a mountain of classic games across these systems, their implementations in MAME are rough, and the playstation ports are lacking, so it would be cool to see these.

It's hard to find much information online about just how much these boards really differ. At a glance it primarily seems to be the amount of vram and how the games are read. But I am a novice that lacks the necessary knowledge to evaluate this and if things were really that simple there would be multiboards that could play all of them. If anyone more knowledgeable about these systems could touch on this subject I would greatly appreciate it.

The lack of information is why MiSTer and other FPGA core devs buy up old boards, buy owner manuals, decap chips, and document their findings.
And as the boards become less advance there less literature on what in the boards

Late 70s to late 80s had great documentation on what going on with the board, you see wiring diagrams, logic diagrams, ect.
Some game consoles before the NES also had such documentation. The Astrocade console for example had wiring documentation in both the console manual and it's Basic Manual that came with the Cart with Basic on it. The NES going forwards? Unless you can find stuff from a repair shop, for get it.
Time the PSX was about, the boards and systems may as well be a black box.

Capcom ZN-1 - Uses the same CPU, uses Capcom Q Sound, and uses the z80 to control sound. Pretty much all of this ought to be possible. The hardest part would arguably be the ROM loading. However the largest roms for it were 32Mbit so that shouldn't be too bad. however, the extra soundboard for NBA Jam Extreme might complicate things.

Capcom ZN-2 - This was actually a higher performance version of the CPU, might be tough. Same as the ZN-1 other than that.

Namco System 11 - Custom sound chip and cpu, might be a bit tough for that reason.

Namco System 12 - Same processor as the ZN-2 most likely, slightly upgraded PSX CPU for higher bandwidth. It also has a different sound chip than the system 11 and the others, in addition to one of the sound chips from the system 11.

Taito FX-1A - Uses the higher end 48MHz CPU like the System 12 and uses a ym2610B and z80 for sound, in addition to the PSX SPU.

Taito FX-1B - Same higher end 48MHz cpu as the last one, yet another new sound cpu, and uses two dsp's for the sound chips in addition to the psx SPU.

Taito G-NET - This one used compact flash cards, had a save interface, a communication interface, CD PCMCIA interface, etc... so it's pretty beefy.

All in all... I think the most likely ones to make it to the hardware eventually would be ZN-1 and System 11, everything else might be a bit more difficult, with the G-NET being extremely difficult.

Great reply, thanks Aberu.

It seems like some of the later boards were practically different systems entirely. High challenge and since most of the games these would cover have compromised but competent ports I wouldn't expect anything but the more similar systems to draw interest for a long time. Kind of a shame since 90s 3D arcade games are in rough shape from an emulation/preservation standpoint, but it's understandable considering how challenging and poorly understood they are.

The question is if any of those additional hardware will fit in the core and if robert perhaps is interessting about those arcade boards. The core is now about 88-90% consuming the space of the fpga.

german_user wrote: ↑Fri Feb 18, 2022 10:30 am The question is if any of those additional hardware will fit in the core and if robert perhaps is interessting about those arcade boards. The core is now about 88-90% consuming the space of the fpga.

True but you can easily set space free for a potential arcade core, the save state eats up about 20% of the FPGA ressources:

viewtopic.php?f=38&t=3735

Additionally the CD related parts of the core wouldn't be needed as well (estimated by Robert to be about 5% of the FPGA).

Good Point, never thought that this (Savestate) consumes so much. Thought it would be much less....

german_user wrote: ↑Fri Feb 18, 2022 12:04 pm Good Point, never thought that this (Savestate) consumes so much. Thought it would be much less....

As I understand it the content of the savestate is stored on the FPGA.

The size of the savestate component is relative to the memory that needs to be stored temporarily. Savestates require clock enables and a pause attached to these, then the memory state is saved to a file on storage. The space in the FPGA isn't used for permanently storing anything as the FPGA in the DE10-Nano is basically like SRAM, it's all turned to 0's when the power is lost. So the savestate is saved to the MicroSD typically. The space taken he's referring to is used for all the logic to make that savestate file and to save that file.

Older systems with less complex memory and chips would use less logic.

Yes, but the savestate normally had to contain only the full ram(s) of the PSX - that is less than 3 MB at all.
Think the core collect some addional data also. I am not a developer but i think perhaps can a switch for SDcard Slot 2 save some logic in the core for future use if space left gets really small.

Savestate is not only the RAMs, but also all(!) internal registers.
At least that is how software emulators work.

I already use tricks, to only pause at times where nothing is active for GPU, MDEC, CD, GTE, ... to not have to save every register, otherwise savestates would not fit in.

Well he didn't say no...