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.

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.

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.

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).

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.

furrtek wrote: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: 169MbpsThe 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?

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.