I read the 30 pages of the post to get a feeling of what the project has been through.

It is incredible, you put a lot of effort in this. I enjoyed a lot reading this.

slingshot wrote:Seems this 7010 is a good candidate, it has 2,1 MB of block RAM, VRAM and the 68k RAM can be implemented in it. (the only thing I miss from the Cyclone III, some more BRAM). Maybe you could port the MiSTer version, it also uses BRAM for VRAM and 68k RAM, and DDR3 SDRAM for the ROM.

It was my preliminary idea to port the MISTer version as I consider the Cyclone V and Zynq more or less the "same alternative" but from a different vendor.This Zynq version is a little bit low in BRAM, I think the 7020 would be more resource comparable to Cyclone. Anyway, I think it is enough for the task.

slingshot wrote:There are other cores, which should benefit from some care.

If I can make my board work, I think I will try something with Arcade cores. Maybe most (or all) Mega Tech - Mega Play boards are now very easy to recreate with all the work all you did with this core.

Nemmerle wrote:It seems I always reach the cool projects when things are advanced and I have nothing more to add.

How about starting a X68000 core for Mist/Mister? There is one available but from what I hear is not still usable. You have that and JT51 for the sound. So if you want to have fun and contribute that's a very cool project.

If you want to stick to Xilinx, the ZX-DOS is a continuation of the ZX-UNO project with a larger FPGA. They have plenty of stuff to do there as they port the old 8-bit cores and try to add more stuff to it.

Yes, Titan 2 is worse but real games are much better. I have asked the Titan 2 authors for a VGM file to debug it. But, as for real games v0.52 has no known bugs and all chip features present so it is the recommended version. Nothing left to do I know of.

I am now looking at other chip variants like YM2203 and YM2610 for other platforms so do not expect updates for YM2612 in a good while.

Just uploded a new build, now being conservative, with jt12 0.51. But @jotego, if you prefer it, I can do it with 0.52 - maybe I just trying games where I don't hear the difference I know how this Titan 2 can be frustrating, actually I must break some passing tests to make it run better (probably because of CPU speed differences from the original), so I understand you won't spend hours just for only that one single demo.

Also then new release has interlace support, simulating some fake SRAM and EEPROM (so games depend on them can work, but you cannot save your state), and many bugfixes, hopefully without too many new bugs. There are two new OSD options, please read the usage tips.

The difference between 0.52 and 0.51 is that 0.52 has the correct bit width in the phase increment field. This translates to having correct sounds when the software overflows the frequency value. This is obvious in the title screen of Scooby Doo. You can try loading that with 0.52 and 0.51 and will hear immediately the difference.

DanyPPC wrote:II noticed a strange duplication of the image in interlaced mode, not present on the original MegaDrive. Some screenshots:

What is duplicated here?The interlaced output is more scandoubler than TV friendly now (actually my LED TV doesn't care), that's what I'm aware of, but otherwise do you see any other rendering errors in the VGA output?

jotego wrote:Yes, Titan 2 is worse but real games are much better. I have asked the Titan 2 authors for a VGM file to debug it. But, as for real games v0.52 has no known bugs and all chip features present so it is the recommended version. Nothing left to do I know of.

I am now looking at other chip variants like YM2203 and YM2610 for other platforms so do not expect updates for YM2612 in a good while.

Maybe if you can spend a tiny amount of time more on YM2612 Here I found a link to a vgm (vgz) file for Titan 2, tried in a VGM player, seems legit, contains the soundtrack from 0:45:https://www.youtube.com/watch?v=730XR6Nc89A

slingshot wrote:Maybe if you can spend a tiny amount of time more on YM2612 Here I found a link to a vgm (vgz) file for Titan 2, tried in a VGM player, seems legit, contains the soundtrack from 0:45:https://www.youtube.com/watch?v=730XR6Nc89A

I have run that VGM with my simulation setup. You can hear the output here. Some PCM sounds may be missing as my simulation does not support a special way of PCM streams they use. But you can hear the FM sounds missing in mist/mister with v0.5x.

So it looks like there is not problem with the FM core itself. Probably the sound commands are getting lost somehow. If the software does not obey the BUSY bit, this can happen. Turrican already did something funny because it re-writes the last value without waiting for BUSY. Now the interface implementation is more robust but still, if a new write command comes before the last one got executed, then it will be missed. Same as real hardware. I doubt this demo sounds correctly in a variety of consoles.

Last edited by jotego on Fri Nov 09, 2018 11:00 pm, edited 1 time in total.

slingshot wrote:Maybe if you can spend a tiny amount of time more on YM2612 Here I found a link to a vgm (vgz) file for Titan 2, tried in a VGM player, seems legit, contains the soundtrack from 0:45:https://www.youtube.com/watch?v=730XR6Nc89A

I have ran that VGM with my simulation setup. You can hear the output here. Some PCM sounds may be missing as my simulation does not support a special way of PCM streams they use. But you can hear the FM sounds missing in mist/mister with v0.5x.

So it looks like there is not problem with the FM core itself. Probably the sound commands are getting lost somehow. If the software does not obey the BUSY bit, this can happen. Turrican already did something funny because it re-writes the last value without waiting for BUSY. Now the interface implementation is more robust but still, if a new write command comes before the last one got executed, then it will be missed. Same as real hardware. I doubt this demo sounds correctly in a variety of consoles.

What git revision produced this ogg file? My problem was not missing sounds, but with 0.51, the Titan 2 sounds almost perfect, however with 0.52 there are wrong, harsh sounds from the beginning (almost like with 0.41, when the music "crashed" at the opening scene). I've used 46809cc (tagged as 0.52). Or should add87d5 used instead as a stable version?

slingshot wrote:What git revision produced this ogg file? My problem was not missing sounds, but with 0.51, the Titan 2 sounds almost perfect, however with 0.52 there are wrong, harsh sounds from the beginning (almost like with 0.41, when the music "crashed" at the opening scene). I've used 46809cc (tagged as 0.52). Or should add87d5 used instead as a stable version?

This is version v0.52 on simulation. I tried synthesizing with a different length for busy register and just got a different mess out of Titan 2.

slingshot wrote:Btw, I don't know if you read the Titan 2 tech docs:https://docs.google.com/document/d/1ST9 ... V8saY8/pubIt mentions the busy bit:The YM2612’s busy flag is useless as already documented elsewhere.Don't know why, but probably there's a reason why it is not obeyed.

I didn't know that document. Busy flag is not useless, it is actually very useful. The hardware works like this:

The different operator information for each channel keeps moving in a cyclic shift register. There is only one point where you can write. So when you have data to write, you have to wait until you see the operator you want passing through. That wait is 24 FM clock cycles in my (and some Yamaha) implementation(s). The busy bit is held for 32 FM clock cycles with a blind counter. It is blind because it will always count for 32 cycles even if not so many are needed. Busy bit does not gate writes. You can issue a new write while busy is high and it will get processed. But, a new write before the old one is done will delete the previous one and that data will get lost.

So without checking for the busy bit, you can still get things right as long as you wait for a good amount of time between writes and you're lucky.