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

[Macro]

This might be an impossible idea (I dont' know Neo Geo hardware that well) but presuming it has some sort of sprite ram where it writes sprite numbers / co-ordinates etc, could you not pick up the fact that a sprite will be needed when the write to the ram occurs - that may then allow more time to get it cached before it gets around to drawing it on the screen.

[furrtek]

This might be an impossible idea (I dont' know Neo Geo hardware that well) but presuming it has some sort of sprite ram where it writes sprite numbers / co-ordinates etc, could you not pick up the fact that a sprite will be needed when the write to the ram occurs - that may then allow more time to get it cached before it gets around to drawing it on the screen.

It would be possible, there's indeed a sprite RAM with lists of attributes for each of them. Rather complex logic could be added to make lists of which sprites would appear on each line when their attributes are written instead of waiting for the real video chip to do that 2 raster lines before rendering them.

BUT (there's always a but...): what if the game changes the attributes just before the sprite starts rendering ? Usually VRAM writes happen during the v-blank but it's not uncommon for games to updated the VRAM during active display (because of lengthy calculations or deliberately for raster effects).

Not sure I want to attempt something so involved if it actually doesn't completely solve the problem in the end :/

@Sorgelig: Is there a way for the HPS to retrieve parallel data from a core, like ioctl_download but in the other direction ? Or should I add that or use the "serial port" ? I'd like to be able to save the backup RAM and memory card contents.

[Sorgelig]

@Sorgelig: Is there a way for the HPS to retrieve parallel data from a core, like ioctl_download but in the other direction ? Or should I add that or use the "serial port" ? I'd like to be able to save the backup RAM and memory card contents.

This functionality is already implemented.
Cores use FS option in OSD instead of F. It means HPS will mount the file with the same name as ROM but with extension .SAV (or will create one if absent).
Then core may use sd_* signals to load/save the content. You can check NES,SNES,Gameboy,Genesis where it's implemented.

[bitfan2011]

if you want a great game to test with which is not massive, try Shin Samurai Spirits
that game alone will keep people busy for ages

[furrtek]

This functionality is already implemented.
Cores use FS option in OSD instead of F. It means HPS will mount the file with the same name as ROM but with extension .SAV (or will create one if absent).
Then core may use sd_* signals to load/save the content. You can check NES,SNES,Gameboy,Genesis where it's implemented.

Thanks, I didn't see that.

About the memory size issue: how about using two 64Mx8 SDRAM chips like the IS42S86400F ? That would give 128MiB total without loading the data bus twice, also the chips aren't too expensive and would still be easy to solder. Would wiring the address/control bus in parallel require lowering the clock frequency a lot ? It may be possible to keep it at 96MHz.

There's something I don't get about the occasionally long delays on the DDR3 memory. Is that caused by the embedded controler multiplexing access between the FPGA core and the ARM CPU ? If that's the case, then would it be possible to use FPGA-dedicated DDR/DDR2/DDR3 memory on the extension board ?

[Sorgelig]

About the memory size issue: how about using two 64Mx8 SDRAM chips like the IS42S86400F ? That would give 128MiB total without loading the data bus twice, also the chips aren't too expensive and would still be easy to solder. Would wiring the address/control bus in parallel require lowering the clock frequency a lot ? It may be possible to keep it at 96MHz.

8bit SDRAM will not load twice only data bus while clock, control and address will be still loaded twice. I didn't test such config. Exactly IS42S86400F won't work at required frequency as it consumes a lot 120-180mA. So, the single chip probably will work up to ~80MHz. 2 chips will be even slower. The chip i'm using consumes only 60mA.
2 chips not only load signals twice but routing will be awful in such small space (even with 4 layers) - it will additionally reduce the max clock.
There are probably some more options exist with BGA chips but i don't look at them as it's definitely not DIY friendly cases.

There's something I don't get about the occasionally long delays on the DDR3 memory. Is that caused by the embedded controler multiplexing access between the FPGA core and the ARM CPU ? If that's the case, then would it be possible to use FPGA-dedicated DDR/DDR2/DDR3 memory on the extension board ?

DDR3 is shared between many consumers. There are also refresh cycles. Nothing you can do with it besides the read with burst to the BRAM and read from BRAM at required rate. This usage implies streaming data, not random reads word by word. Although Genesis and TGfx16 work well with ROM in DDR3. For these consoles ROM is not directly accessible by video chips, so latency is not an issue for them as long as integral rate is within required pace.

I don't think DDRx is a viable option for addon. At first: it requires diff signals carefully routed which cannot be done on existing DE10-nano connectors. At second: raw DDRx control is a nightmare. Current internal DDR3 is controlled by hardware giving very simple MPFE (AvalonMM-like) interface. It won't be the same with external DDR memory.

May be it's really would be better to concentrate on NeoGeo CD and <256MBit ROMs first. Then later can think how to support larger ROMs.
I guess NeoGeo ROMs consist on separate blocks where you know which blocks are for graphics and then must go to SDRAM, Other blocks can go to DDR3. This way even some >256MBit ROMs will be supported.

[Sorgelig]

New interesting board from Terasic:
https://www.terasic.com.tw/cgi-bin/page ... 1&PartNo=3
It's very similar to DE10-nano by main functions. It has dedicated separate DDR memory for FPGA. And it's 3 times expensive

P.S: Just single 64MB SDRAM chip gives 512MBit. And if take in account only graphics part, it probably will cover 99% of NeoGeo ROMs. Single 64MB SDRAM is pretty much possible with some chips.

[JimDrew]

New interesting board from Terasic:
https://www.terasic.com.tw/cgi-bin/page ... 1&PartNo=3
It's very similar to DE10-nano by main functions. It has dedicated separate DDR memory for FPGA. And it's 3 times expensive

P.S: Just single 64MB SDRAM chip gives 512MBit. And if take in account only graphics part, it probably will cover 99% of NeoGeo ROMs. Single 64MB SDRAM is pretty much possible with some chips.

It's too bad on the price. But it proves that the Replay 2 will be definitely be worth it's price - and memory won't be an issue with 1 or 2GBs available for the FPGA. Replay 2 will be able to run everything now and in the future.

[kitrinx]

It's too bad on the price. But it proves that the Replay 2 will be definitely be worth it's price - and memory won't be an issue with 1 or 2GBs available for the FPGA. Replay 2 will be able to run everything now and in the future.

Is it going to be cheaper or more available than that dev board sorg linked?

Fortunately, Neo Geo is probably the largest challenge that MiSTer will face in this regard. There's no doubt that more IO pins available would make things nicer, especially for systems like SNES, but sixth generation systems are not realistic for any FPGAs right now, even discounting the effort it would take in implementing them, so really what we're looking at is fifth generation consoles. Most of those are CD based, and things like the N64 have developmental hurtles before we need to worry about hardware.

All things considered, MiSTer's choice in hardware hits a sweet spot between power and low cost of entry that is proving extremely effective at bringing people to the platform, which leads to more development, and so on. Just like a game system, it doesn't matter how much power you have if you don't have good developers making enough stuff for it. If we ever hope to tackle systems complex enough to need collaborative work, having a very popular and accessible platform is going to be more important than super-powerful niche hardware. see: raspberry pi.

But this is not really what this thread is about. The 64mb 99% of ROMs approach seems like the most reasonable solution so far, and an affordable and easy upgrade for people who did not buy clone IO boards.

[jft]

Man, seems there is a huge price jump to go from a 256M chip to 512M (with the Alliance brand anyway, from ~$3.20 to over $10, and Digikey doesnt even have stock ).

Is the concern of multiple chips the power draw it will place on the DE10?
If not, would it be feasible (assuming matching trace lengths with the DE10) to have qty=2 or even qty=4 256M chips on a single RAM board? From a price/availability perspective it is attractive, but from a power consumption/routing perspective, probably not eh?

[ijor]

Exactly IS42S86400F won't work at required frequency as it consumes a lot 120-180mA. So, the single chip probably will work up to ~80MHz. 2 chips will be even slower. The chip i'm using consumes only 60mA...
Single 64MB SDRAM is pretty much possible with some chips.

Did you test the 512Mbit (32x16) Alliance Memory part? : https://www.alliancememory.com/datasheets/AS4C32M16SB

It might worth a try if not. But as you are saying, this part also has much higher power consumption according to the specifications.

The problem with a reduced max frequency is the compatibility with other cores. Even if the slower frequency would be enough for this core, the user would need to swap boards for those cores that require a higher frequency?

Personally I wouldn't mind a BGA solution if performance is better. I do realize it is not DYI friendly.

It's too bad on the price. But it proves that the Replay 2 will be definitely be worth it's price - and memory won't be an issue with 1 or 2GBs available for the FPGA. Replay 2 will be able to run everything now and in the future.

Nice advertising and marketing language! I don't think even Mike would use that style, he is much more modest

[Sorgelig]

Did you test the 512Mbit (32x16) Alliance Memory part? : https://www.alliancememory.com/datasheets/AS4C32M16SB

yep, this is what i've tried. It's harder to make it work at 167MHz than 32MB. On one DE10-nano board i couldn't make it work higher than 130MHz. Another DE10-nano board seems passes 167MHz.
It works with all cores except two. Minimig doesn't work because page addressing on 64MB is different. So need to change the core for 64MB chip.
Archie works strange - it needs around one minute to start to boot. Once it show the booting lines, the rest works ok.

64MB is kind of redundant and much more expensive. Only NeoGeo rises the question about it. Still i think it's better to start with 32MB and make it work reliably.

[Newsdee]

NeoGeoCD would be a great start if it's easier. It has a few games exclusive to it too.

The caveats of the CD are that their drive was super slow so loading times could become unbearable. It was blamed on the slow speed 1x CDROM drive of the first units, and became a little better with the later CDZ console that had a 2x CDROM drive.

Furrtek is no doubt well aware of all this, but for anybody interested here is a discussion on causes of slowdown:
https://wiki.neogeodev.org/index.php?title=Loading_time

It would be interesting to see if it can be improved with an FPGA. I guess loading times and drive seek times could be eliminated to a large extent.

[Sorgelig]

In the beginning of implementation slow loading is an advantage

[furrtek]

Thanks again for all the information.
I'll put aside the idea of getting all games to fit for now and prioritize bugfixes and additionnal functionality.
I'll also consider adding a NeoGeo CD system mode if I can get the DMA chip logic right.

Expect an update this week :)

[Dubon]

https://youtu.be/BmjuC47jTxE

[cvenditti]

https://youtu.be/BmjuC47jTxE

Can you please upload the rbf? I try to compile the full version yesterday but I got errors.
Thank you

[kitrinx]

https://youtu.be/BmjuC47jTxE

Can you please upload the rbf? I try to compile the full version yesterday but I got errors.
Thank you

I have a branch with an updated sys that might be easier to work with:

https://github.com/Kitrinx/Neogeo_MiSTer/tree/neohdmi

You need the main MiSTer binary that goes with it as well as several files in the NeoGeo dir on your sd card:
000-lo.lo
neocd.bin
neo-epo.sp1 (this can be original or universe bios)
romsets.xml (use furrtek's, others probably wont work)
sp-s2.sp1
sfix.sfix
top-sp1.bin

[cvenditti]

https://github.com/Kitrinx/Neogeo_MiSTer/tree/neohdmi

The Lite version works perfectly now.
I still have errors with the full but I fine with the lite

Many thanks to you

[kitrinx]

https://github.com/Kitrinx/Neogeo_MiSTer/tree/neohdmi

The Lite version works perfectly now.
I still have errors with the full but I fine with the lite

Many thanks to you

Sorry, I didn't rename it. With Grabulosaur's scaler there isn't really a lite and full anymore, "lite" is the one you want. Full should just be removed and lite renamed. If Furrtek updates /sys in his project that's likely what you'll see.

[seastalker]

https://youtu.be/BmjuC47jTxE

You need the main MiSTer binary that goes with it as well as several files in the NeoGeo dir on your sd card:

neo-epo.sp1 (this can be original or universe bios)
top-sp1.bin

I am down to finding these two files. I downloaded the latest unibios. Do I rename a particular file to 'neo-epo.sp1'? I have many bios files but can't seem to find an isolated 'top-sp1.bin' file. Should I be looking for an older neogeo or neogeoCD bios? Again is there a file I may have already that I can rename to "top-sp1.bin"?

Thanks and looking VERY forward to trying out the Neo core.

[cvenditti]

I am down to finding these two files. I downloaded the latest unibios. Do I rename a particular file to 'neo-epo.sp1'? I have many bios files but can't seem to find an isolated 'top-sp1.bin' file. Should I be looking for an older neogeo or neogeoCD bios? Again is there a file I may have already that I can rename to "top-sp1.bin"?

Thanks and looking VERY forward to trying out the Neo core.

I did PM you. I will try first without the "top-sp1.bin"

[zomgugoff]

I'm not having any luck getting any games to boot. I have located the listed files, but nothing happens after the files are shown loading. Can the MD5s of the required files be posted?

[DYates69]

I couldn't find the top-sp1.bin file either.

I have found that this core doesn't seem to like larger partitions. Took me ages trying to get it working on a 32GB card then I tried a smaller partition and one of the previous versions worked straight away.

Anyway idea where I can find the top-sp1.bin?

Thanks

[zomgugoff]

I couldn't find the top-sp1.bin file either.

I have found that this core doesn't seem to like larger partitions. Took me ages trying to get it working on a 32GB card then I tried a smaller partition and one of the previous versions worked straight away.

Anyway idea where I can find the top-sp1.bin?

Thanks

I'm pretty sure we can't link BIOS files here, but I can tell you this is a NeoGeo CD BIOS file, and it can be found in MESS BIOS collections.