Would MiSTer ever be able to run a Neo Geo core?

[nightshadowpt]

Hi,

The question is in the title.

Would the MiSTer ever be able to run a Neo Geo core, if it is ever done?

Or would it require a bigger/more powerful FPGA?

Cheers,

[Newsdee]

I think its unknown at best and no at worst.

There is no full FPGA neo geo core anywhere yet, and it has been commented that the console needs a lot of fast RAM access which would be better served by having four memory banks.

[cvenditti]

Furrtek is working with a DE1 on but it is only for "preservation and education"
https://www.patreon.com/furrtek

As Newsdee said the issue is with the RAM bandwidth to access the roms data.
Maybe someday

Cyril

[Sorgelig]

so, if it works on DE1, then it will fit in DE10-nano as well. Though need to check about the RAM.
Basically DDR3 is pretty fast if used in burst mode, so it depends on core design.
MiSTer has 3 types of RAM: BRAM, SDR SDRAM, DDR3 - so even if one type is not enough, then combining these 3 i believe will be sufficient.
May be tell to developer to look at MiSTer project as a better alternative to DE1. Especially MiSTer provides additional services absent in bare dev board.

[Sorgelig]

Ok, after checking the Wiki, NeoGeo is pretty much similar to Sega Genesis by architecture.

Total 224KB RAM can directly fit into BRAM, so no complex shared access is required. I don't know how big are NeoGeo cartridges. Wiki tells about up to 800Mbit (100MB), but i think 99% of games use not more than quarter of that. If 32MB will be enough, then SDRAM can be used. Otherwise DDR3 with 256MB (actually can be much more) can be used for cartridges like i did in Genesis core.

So, the whole project should fit without problems and still many resources will be unused.

[cvenditti]

I was in touch with Furrtek for something else, I will try to contact him about that.
That will be so amazing to have a Neo Geo core
Cyril

[Newsdee]

That would indeed be amazing!

[furrtek]

I'm only using my DE1 for research as a logic analyzer or a signal generator, I never meant to make the project run on it.
From the beginning the goal is to be able to run actual cartridges. That requires a large amount of I/Os, which most FPGA dev boards lack.

System RAM isn't a problem, it's not that large (as noted).
Storage space for games shouldn't be a problem either since no games are over 90MB and most of them fit in 32MB (as noted also):


The crucial difference is that Genesis carts have 1 bus while those for the NeoGeo have 5.

I tried to summarize the maximum bandwidth requirements, hoping I didn't make mistakes:
Sprite graphics: 91.55Mbps
Fix graphics: 22.89Mbps
Main CPU program: 45.78Mbps
Sub CPU program: 7.63Mbps
Audio data: 1.13Mbps

Total: 169Mbps

The real challenge I'm seeing is the need to interleave all those random accesses while keeping latency under the limits for each.
Honestly, I want to stay focused on the core itself. I don't want to start hacking up the original logic to solve timing problems only caused by the use of SDRAM (at least for now).

[Sorgelig]

Well, DDR3 should be more suitable then. Still many games require more than 32MB according to your histogram. Graphics and audio use sequential access and pretty easy mapped to burst access to hide the latency.
I don't know architecture of NeoGeo carts, but since they have separate buses for each device, they should have separate ROM chips for each bus. So, it's possible at the load stage to separate CPU data from AV data. CPU data will go to SDRAM (which should fit on any cart), while AV data to DDR3. Thus pure stream data will be separated from random access data. DDR3 on DE10-nano has 25.6Gbps bandwidth - should be enough

I think project can have universal version of the core where both real cart and virtual can be used. Just like MSX project having dedicated FPGA board with cart slot and port to MiSTer with virtual carts only. Most users won't access to real cartridges and would like to use a virtual ones.

[ijor]

The crucial difference is that Genesis carts have 1 bus while those for the NeoGeo have 5.
I tried to summarize the maximum bandwidth requirements, hoping I didn't make mistakes:
...
Total: 169Mbps
The real challenge I'm seeing is the need to interleave all those random accesses while keeping latency under the limits for each ...

As Sorgelig sad, the FPGA in the MiSTer have much more internal RAM than the whole NeoGeo. When you use internal RAM, total bandwidth and the number of buses is not a concern at all. The FPGA can divide internal RAM in many independent buses.

However, if I read the specs correctly, besides 214 KB RAM, it has 512 KB of ROM, and that won't fit in internal RAM. Still, sounds like doable. You probably should be able to accommodate the lower latency channels internally, leaving a few channels to be dealt with external RAM. Even with external RAM, the main problem here is latency, not bandwidth. May be a good case for an SRAM MiSTer expansion board. You can, of course, use other dev boards with built-in SRAM, but they are more expensive.

Anyway, if I understand correctly it has a custom chipset that still need to be reverse engineered, right?

[furrtek]

The system ROM is 1Mb, it could be loaded with the game in CPU memory. It's always mapped at a fixed address.
There's also a 1Mb lookup ROM for graphics, which might be possible to compress.

There are lots of good games above the 32Mb limit yes. The largest ones are those which use encryption for graphics (>1999), the ROM chips are packed full. By the way, these will bring another kind of challenge: replicating the decryption chip. Decrypted romsets do exist though.

CPU data never goes above 64Mb+4Mb apparently.
Reads for audio and graphics aren't really sequencial. Rendering is done in lines so the address will keep changing from tile to tile. When a sprite line is rendered, there are only four 16bit reads done in sequence (actually two 32bits reads on the real hw).
Audio is mostly sequencial for each channel but 7 of them must be interleaved, as they all use the same ROMs.

I have to check again but I believe the tightest requirement for latency is 83ns.

The video chips are completely reverse engineered.

[rittwage]

Somehow the original XBOX is able to emulate it with only 64M of RAM, but maybe they are using some kind of virtual memory system.

[furrtek]

64MBytes ? That's plenty of space.
Also emulation typically takes lots of shortcuts to speed things up.

[Locutus73]

A picture is worth a thousand words.

https://wiki.neogeodev.org



Hi furrtek, glad to see you here.

Regards.

Locutus73

[cvenditti]

If the Neo geo core is ever created be able to fit the MiSTer in a NEOGEO X Dock will be great (might not be the best for the fan exhaust):
https://www.aliexpress.com/item/NEOGEO- ... 80654.html
https://www.aliexpress.com/item/Raspber ... 54497.html
Cyril

[nightshadowpt]

So, from an FPGA perspective it fits, as well as from a memory perspective. That's great news!

What about performance wise? The Neo Geo has several CPU/GPUs ranging from 4Mhz to 24Mhz.

The day we can have a NeoGeo running on FPGA will be a great day indeed.

Thanks to all the developers for their efforts.

Cheers,

[Locutus73]

https://twitter.com/furrtek/status/1083221895087034369

Regards.

Locutus73

[Newsdee]

itshappening.gif

[djsquare]

oh man I can't wait for this! Now I'm glad I didn't end up buying that consolidated MVS I wanted to so badly. This might be a game changer. I think this group of MiSTer hobbyist is about to get a whole lot larger. Wonderful work

[bitfan2011]

butt can it run ... Neo CD games??
muah

[Newsdee]

Let's walk before we can run, dude.

Who knows, if somebody implements a CD-ROM handling for any core it may help towards others. I would image they would implement standard "Red Book" CDROM formats, so at least NeoGeo CD, Sega CD, and PCE CD would be similar to some extent (the data storage part, not the interface with the actual machine)

[Locutus73]

https://github.com/furrtek/Neogeo_MiSTer

Regards.

Locutus73

[hernan43]

It's happening......

[cvenditti]

Can't wait

https://github.com/furrtek/Neogeo_MiSTer

Regards.

Locutus73

[bitfan2011]

support for Universe BIOS would be 1000000% appreciated :]