Sporniket's B-Side - electronic stuff but not retro

[sporniket]

My new toy to play with fpga

2022-07-24--blinking-colorlight-i9.jpg

This is a "Colorlight i9" module by Muse Lab (official aliexpress link), and its extension board, hosting a Lattice ECP5 "LFE5U-45F" and Network capable with a broadcom chips, meaning "over big enough for years to come" for my needs. The headers for the extension board are provided too, I was too lazy to put them on the picture. All of that for around 71€ before shipping fees, and no programmer to buy like Xilinx and Altera.

You can see an audio PMOD, as my first project will be to make a model of the Microchip AY8930, a sound chip that is the successor of the YM2149/AY-3-8910, and that provides a legacy mode (same registers, same behaviour) and an extended mode (triggered by a special combination of bits on one of the registers). The extended mode allows each channel to have it's noise and envelop generator, instead of a shared one ; the noise generator stacks AND and OR masks to the pseudo random generator (meaning that one can have a totally not random noise generator) ; there is 9 predefined duty cycles for the square wave.

Then I plan to play with video, my goal is to try to have HDMI rendering, at least SDTV definition (720x576p@50Hz), including audio.

After that, crazy projects/fantasies : 

• plug a 68HC000 (because if memory serves me right, it is able to run at 3.3V) to the module loaded with STe chipset (and if I add some DIP-64 extension ports, I could also use some of @exxos H5 plugins (the 3.3V variants obviously)
• plug a DFB1 of @Badwolf (if memory serves me right, I counted that I have just enough pins for that and some serial connection to some other devices) to the module loaded with other Falcon chipset (maybe with DSP if there is an implementation somewhere). (remember those are fantasies, until effective materialization that won't happen before years, if it ever happen)

For now I plan to use Amaranth HDL (previously nmigen), a python lib to build an abstract syntax tree using python-like syntax. A bit quirky on it's on but I can bypass verilog/vhdl, so let's see how far I can go with that.

My fallback plan is use migen and litex framework.

If I really have no choice, I will resolve myself to use verilog (oss-cad-suite provides only verilog, vhdl support requires paid version, and my bias toward vhdl is not that adamant...)

[exxos]

My dream / goal is a new sound system for the H5. Something which can play tracker music without the CPU overhead.

Arcade machines which were z80 based used a sound board to play sampled sounds from a EPROM. Was basic, but it allowed sounds to be played without any CPU overhead. Other than sound selection and play / stop kinda thing.

Problem with tracker tunes is the cpu overhead for volume / pitch / mixing etc etc all could be done in hardware. While the concept is super simple, buying all the parts to playback 8 channels soon adds up :( it would likely need a FPGA because it needs super large counters for the playback address ranges. But I'd rather avoid more complex stuff. But binary counters are not exactly cheap and with a lot if them needed, the PCB would be huge. So undecided on where to go with the project currently.

[sporniket]

Yes, fpga with enough dsp slices would help a lot for the tracker. It also allow to embed a real cpu core, with an embedded replay routine (you could even embed the fx68k core from @ijor to stay with replay routine in 68k asm :D )

And yes, I understand that hardware design is not cheap. :cry:

[exxos]

I did contemplate just using a 68k CPU and just do stuff almost like normal. I mean with 32mhz and fast ram on it, it could reuse a lot of code and be very flexible to what it could do.

[ijor]

Problem with tracker tunes is the cpu overhead for volume / pitch / mixing etc etc all could be done in hardware. While the concept is super simple, buying all the parts to playback 8 channels soon adds up :( it would likely need a FPGA because it needs super large counters for the playback address ranges. But I'd rather avoid more complex stuff.
...
I did contemplate just using a 68k CPU and just do stuff almost like normal. I mean with 32mhz and fast ram on it, it could reuse a lot of code and be very flexible to what it could do.

I can help with the FPGA side if you want/need. But in this case a "modern" MCU with builtin RAM might be a better, or at least simpler, solution?

[sporniket]

My dream / goal is a new sound system for the H5. Something which can play tracker music without the CPU overhead.

Just to be sure, I believe that the Falcon was able to kind of do that by using the DSP ? Or there was some limitation coming from the architecture, like maybe requiring the CPU to transfert RAM data to the DSP ?

[exxos]

Just to be sure, I believe that the Falcon was able to kind of do that by using the DSP ? Or there was some limitation coming from the architecture, like maybe requiring the CPU to transfert RAM data to the DSP ?

Yep. I had a STOS extension which could play tracker music on the DSP. Was awesome .

[mrbombermillzy]

My dream / goal is a new sound system for the H5. Something which can play tracker music without the CPU overhead.

Would using something like a MC56002 be completely out of the question for this?

Same sort of price as the F030 56001, improved speed (among other things), IIRC code compatibility with the '01 (so the old skool F030 DSP coders will be familiar enough coding for it) and wont suffer any price hiking due to association with a Falcon :lol:

[exxos]

Same sort of price as the F030 56001, improved speed (among other things), IIRC code compatibility with the '01 (so the old skool F030 DSP coders will be familiar enough coding for it) and wont suffer any price hiking due to association with a Falcon :lol:

I don't think it is just the DSP though.. I did look into it a few years back and I think you need the DAC and codec or something as well.. I might have a post on the forum *somewhere* about it all.

But it is not just the hardware, I have to assume that absolutely nobody will program for anything which I create. Going with the more classic tracker style coding, one of the demo coders said a few years back he would be willing to adapt a routine for new hardware.. But by the time it actually happens could be a totally different story.

The thing is my hardware would require very little programming to play sounds. If someone was really interested enough, games could even be patched to play sampled sound or music etc.

Worst case is if I do manage the hardware, I can still use it for playing sampled sounds or even music, assuming I have to do the programming myself. I also have to assume that nobody else would even want such a board. So it comes to just being a personal project of mine really mess around with in the future.

OTOH. "one day" When we get a true faster bus speed.. We will have more ram and CPU power to burn anway.. So I'm not really sure it would even be worth doing a new sound system.

If I went with more of a STE style DMA sound system, I could probably add more channels.. I have no idea. I forgot how that all works, but I remember rightly the DMA sound is played during the blank video borders. Which could screw up ST compatibility with screen demos :shrug: even so, with more CPU power being able to do mixing and stuff, and only having stereo output anyway.. More channels could really be pointless anyway.

[sporniket]

My FPGA board has yet to have an accepted implementation with amaranth, so I just took some code from those pull requests, and wrote the minimal code allowing to blink the onboard led.