squid4 wrote:Super Street Fighter II graphic glitches are gone with fpgagen-20181109.rbf but the music and sound still has issues and is very quiet with this game.

I have tried the different Street Fighter II games:

Street Fighter II Special Champion Edition: volume is low, but music and SFX are correct

Street Fighter II Plus: volume is low, but music and SFX are correct

Street Fighter II The New Challengers: volume is very low, SSG seems louder than it should

I do not hear anything that seems obviously wrong in my version (JT12 v0.52). SSG might be a bit louder than it should -which is something we can fix- and FM volume is set very low in these games -but that is software dependent.

YM2612 is a stripped down version of the OPN Yamaha core:

least significant bits of sound thrown away

limited internal dynamic range means that volume must be attenuated by software -as documented by Yamaha-

So overall, unless the sound engineer paid attention to this properly, when porting music from other Yamaha chips the result can be a quieter song. I can imagine two patterns:

Games whose music was programmed using an YM2203 equipped Japanese computer (FM towns, PC88 or similar)

Games that are ported from arcade, where an YM2151 was used

In both these cases, volume parameters needed special attention when porting the music to YM2612. And I think that -probably for schedule reasons- this detail was often overlooked.

In summary, I don't think there is much we can do. We could add a volume control on the OSD for very quiet games, but core developers rejected this option before because this would be the only core with that option. So I think you are left to your desk top amplifier.

squid4 wrote:jotego, is there a download for the 0.52 version. I think the one at https://github.com/mist-devel/mist-bina ... es/fpgagen is 0.51. I'll do some more testing when I get the later version. Thanks for your amazing work on this FM beauty, it sounds incredible.

This is the last synthesis I made. Note that this is not an official release from the FPGAgen system level developers.

With Jotego 0.52 sound engine is near perfect.The difference with 0.51 version is almost indistinguishable.

But Slingshot core has improvements for Turbo OutRun Sky and support interlaced mode.I never thought of having such a faithful Genesis Core, at this point I would not be surprised about a possible SuperNes Core with same quality.

DanyPPC wrote:I never thought of having such a faithful Genesis Core, at this point I would not be surprised about a possible SuperNes Core with same quality.

I think NeoGeo will come first. Although because of the sheer size of some NeoGeo ROMs I don't think we'll be able to get all games working. At least in MiST, maybe MiSTer has a bit more external memory.

A Japanese guy made a SNES implementation, but he wouldn't share his code. So it doesn't really count.

Ah, so some years, and it'll be ready Being serious: I don't understand why he wants even 2 SDRAMs, the DE10-nano has plenty of BRAM for all internal RAMs of the Neo-Geo (if the specs on wikipedia is correct - it's almost the same amounts as Genesis).And these numbers are suspicious:LSPC2: 532 LCNEO-B1: 130 LCNEO-C1: 58 LCNEO-ZMC2: 46 LCIs it really has a working video display processor or how's called on that machine? The VDP of the Genesis is 3 times bigger than the sum of this.

Just out of curiosity, which bandwidth requires the ROM? Access needs to be cycle accurate? Otherwise, the DDR can be used, may be using some internal cache in the worst case. I was surprised to find out how efficient the DDR access from the FPGA side is.

slingshot wrote:Being serious: I don't understand why he wants even 2 SDRAMs, the DE10-nano has plenty of BRAM for all internal RAMs of the Neo-Geo (if the specs on wikipedia is correct - it's almost the same amounts as Genesis).And these numbers are suspicious:LSPC2: 532 LCNEO-B1: 130 LCNEO-C1: 58 LCNEO-ZMC2: 46 LCIs it really has a working video display processor or how's called on that machine? The VDP of the Genesis is 3 times bigger than the sum of this.

LC refers to Logic Cell? Is it like Logic Elements but for the MiSTer FPGA?

The great thing of Furrtek's work is that he has work out schematics for the original VDP of NeoGeo. So if we combine that with the cycle accurate M68000 core from Ijor, and a JT12 version supporting YM2610 (I'm working on it), then we can get something very nice

If it fits in MiST, it will need to take RAM and VRAM out to the SDRAM too. The bandwidth of NeoGeo must be very large by looking at the number of pins and parallel signals in the cartridge (wiki)

jotego wrote:LC refers to Logic Cell? Is it like Logic Elements but for the MiSTer FPGA?

It writes about 3000LCs for the TG68k, and that's about the same on the Cyclone III (MiST). That's why I feel it's too small amount for a serious VDP.NeoGeo has a 24 bit data bus for the VDP, don't know about the VRAM's data bus width, it can be different (like Genesis has a 16bit interface to the VDP, but only 8 bit for the VRAM, width very limited clock, like one 8-bit write/every 2 pixels).

Surely the DDR bandwidth is more than enough. The problem might be the latency. The hardware interface (MPFE) is extremely efficient and the latency is much lower than I expected. But is not fully predictable because you don't control the hardware directly as you do with the SDRAM.

Is the ROM accessed by the 68000 only, or also by some kind of video DMA? If by the 68000 only, then probably it doesn't have to be cycle accurate because the 68000 core they used is not cycle accurate in the first place. And of course that you can use burst and cache, so you will get low latency on most accesses anyway.

But note that using DDR on the DE-10 nano is not that simple. The interface does have some quirks and it needs cooperation from the HPS (Linux) side. We don't care because Sorgelig already sorted out that part for us. It might also make sense to not use DDR if the plan is eventually move to some other board that has SDRAM but not DDR.

I think that the problem with DDR is non-consequitive reads. Like having to read from many different ROMs at the same "time". As you have to prepare the DDR banks again you lose precious clock cycles there. So, even if the memory bandwidth is great for reading data byte after byte; it may not be enough in some old arcade systems. Or maybe there are tricks I don't know about.

jotego wrote:I think that the problem with DDR is non-consequitive reads. Like having to read from many different ROMs at the same "time". As you have to prepare the DDR banks again you lose precious clock cycles there. So, even if the memory bandwidth is great for reading data byte after byte; it may not be enough in some old arcade systems. Or maybe there are tricks I don't know about.

SDR is also burst and row oriented, only that DDR usually has even higher latency. But you can always compensate if the memory and the interface are fast enough.

Let's assume an original slow arcade system, 8-bit based accessing static ram (zero latency) at 2MHz. You have 500ns to return the data. But during that time you can execute a few hundred DDR cycles. So the latency is no real problem. You do waste some DDR bandwidth. But you can implement a cache on internal RAM, use bursts to fill the cache, and that would also compensate the wasted bandwidth.

Of course, more advanced arcade systems typically worked at higher frequencies and had multiple memory channels that could be accessed simultaneously. So it might be more complicated and sometimes not feasible.