FPGA based 486 integration?

[DMJC]

Any chance of integrating this into: https://github.com/alfikpl/ao486 it's a 486 implemented in verilog. It's got an OPL2 implementation but it's incomplete in the FM synthesis. Since this project is doing OPL3... would it be possible to implement the OPL3 engine on ao486 instead?

[gtaylormb]

Very likely. I'm on mobile right now so hard to navigate the project, but what chip is this implemented on? The biggest hurdle is possibly a synthesizer that supports the chip while also supports SV.

If SV is not supported, the design will have to be converted to verilog. Not a huge deal just additional work.

Greg

⁣Sent from BlueMail ​On Jul 21, 2017, at 8:34 PM, DMJC notifications@github.com wrote:

Any chance of integrating this into: https://github.com/alfikpl/ao486 it's a 486 implemented in verilog. It's got an OPL2 implementation but it's incomplete in the FM synthesis. Since this project is doing OPL3... would it be possible to implement the OPL3 engine on ao486 instead?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

On Jul 21, 2017, 8:34 PM, at 8:34 PM, DMJC notifications@github.com wrote:

Any chance of integrating this into: https://github.com/alfikpl/ao486 it's a 486 implemented in verilog. It's got an OPL2 implementation but it's incomplete in the FM synthesis. Since this project is doing OPL3... would it be possible to implement the OPL3 engine on ao486 instead?

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/gtaylormb/opl3_fpga/issues/10

[DMJC]

Intel EP4CE115

[gtaylormb]

Cool..does the synthesizer support SV?

⁣Sent from BlueMail ​

On Jul 21, 2017, 11:46 PM, at 11:46 PM, DMJC notifications@github.com wrote:

Intel EP4CE115

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/gtaylormb/opl3_fpga/issues/10#issuecomment-317151592

[zephray]

I used to use EP4CE6, its synthesizer support SV.

[sorgelig]

I'm using this OPL3 HDL implementation in my port of ao486 core on MiSTer: https://www.youtube.com/watch?v=li8Dkpv9sHc&t=36s

It's more or less good while it's used as OPL2. Music and games using OPL3 have different bugs in sound. Something related to Amplitude or Phase modulation.

Would be good if this core will implement pipeline processing to reduce LE.

[gtaylormb]

Very cool! Thanks for the link. Do you think the bugs are perhaps related to the rhythm instruments? I need to make some updates there based on updates in the C++ implementation it was based on. It is also the least understood portion of the chip and thus likely to not be as exact.

I have some ideas to reduce LE utilization.

[sorgelig]

It's definitely not related to rhythm mode (actually i don't know any app using rhythm mode). if you can play RAD tunes through your OPL3 module, then look at demo tunes included in RAD v2: http://www.3eality.com/productions/reality-adlib-tracker All three tunes from Louis G. sound very wrong.

When i've used RAD Tracker 1.x which was OPL2-only i heard no problems. Once i've started to use RAD tracker v2 which uses OPL3 features, i start to hear the problems. So, for me the bugs are related to OPL3 features not present in OPL2.

There is another implementation of OPL3 in FPGA: https://opencores.org/project/next186_soc_pc

They use softCPU which does initial data preparation. Main sound synthesis is done in HDL as well. They use state machine to process the channels sequentially, so it doesn't occupy much resources. It doesn't implement rhythm mode at all. Your OPL3 implementation occupies ~5600 ALM (Cyclone V), that implementation ~1600 ALM. Next186 version occupies much more BRAM, though.

Your OPL3 sounds better (if don't count the bugs) - more natural and close to real HW. Next186 has more metallic overtones in some sounds, but so far none serous bugs in implementation found.

[gtaylormb]

I have a feeling the OPL3 issues you are experiencing have something to do with how the second register bank is mapped in your port. I can play OPL3-based music using my imfplay port as well as Walter's ScummVM and DOSBox ports. I'll take a look at some of your older versions that still have the opl3_fpga to see if anything pops up.

Yes the goal of my implementation was accuracy to the original design, not necessarily minimum resources. The resources can be reduced though for sure and I have some ideas I might play around with.

[gtaylormb]

Example playing OPL3 using second register bank: https://www.youtube.com/watch?v=i9vEKyJScYw

[sorgelig]

I did direct replace opl3_fpga with Next186 version without change any mapping. And it start to work as it should work on OPL3. In my core, i can choose OPL2 or OPL3 from OSD. If i switch to OPL2, then OPL3 app will miss a lot of instruments. So, it's clearly visible that OPL3 registers are mapped correctly and basically work.

Please try to play demo tunes from RAD v2 i've posted above.

If you have DE10-nano board then it would be even better as you will be able to use the whole my port of ao486.

[sorgelig]

The is classic DOS game using OPL3. https://www.classicdosgames.com/game/Cybersphere.html Try this game. Go to options menu and listen default music there. You will notice strange loud effect instead of vibrato. I believe it's something to do with 4-operator mode absent in OPL2 and often used in OPL3 music.

[gtaylormb]

Digging up this old thread. Were you using register_file_axi by any chance? That module is untested. I ended up using and modifying the device memory map generated by Vivado (under modules/opl3_fpga_1.0).

I am in Tokyo this year without my ZYBO so I won't get a chance to test out that DOS game you mentioned unless I can get another board.

[gtaylormb]

opl3_fpga has been merged into ao486, closing.