Oh neat, how does the OPL3 interface with the CS4237B?

ExplodingLemur wrote on 2023-07-14, 04:04:

Oh neat, how does the OPL3 interface with the CS4237B?

The CS4237 provides an interface for an external synthesiser; it provides address decoding and all bus-related "glue logic", activating the external OPL3 when required, and handling forwarding data from the bus to the OPL3 and in the other direction. Sound is connected, in analogue form, through a DAC and amplifier, to one of the inputs on the CS4237. We haven't really discussed that aspect in detail, but I suspect he routed it to the LINE interface of the CS4237, as Crystal intended; this provides the best compatibility and flexibility. To be clear, the LINE input is not what one would normally think of as "the line-in", which is referred to as AUX in Crystal-speak, so you're not compromising an additional input for this feature.

640K!enough wrote on 2023-07-14, 05:56:

ExplodingLemur wrote on 2023-07-14, 04:04:

Oh neat, how does the OPL3 interface with the CS4237B?

The CS4237 provides an interface for an external synthesiser; it provides address decoding and all bus-related "glue logic", activating the external OPL3 when required, and handling forwarding data from the bus to the OPL3 and in the other direction. Sound is connected, in analogue form, through a DAC and amplifier, to one of the inputs on the CS4237. We haven't really discussed that aspect in detail, but I suspect he routed it to the LINE interface of the CS4237, as Crystal intended; this provides the best compatibility and flexibility. To be clear, the LINE input is not what one would normally think of as "the line-in", which is referred to as AUX in Crystal-speak, so you're not compromising an additional input for this feature.

Bah, I just noticed I'd used LINE for line-in and Pi/wavetable, and AUX1 for the external FM input! Changing this now, thanks for saving my ass (again)! 😁

Hello Eivind,

Somehow my head doesn't feel right 😀. You are using Vortex86EX SOM-128-EX and Crystal CS4237B... But SOM-128-EX doesn't support DRQ0, DRQ3, DACK0, DACK3. How did you manage to solve this?

Vridek wrote on 2023-07-20, 09:47:

Somehow my head doesn't feel right 😀. You are using Vortex86EX SOM-128-EX and Crystal CS4237B... But SOM-128-EX doesn't support DRQ0, DRQ3, DACK0, DACK3. How did you manage to solve this?

You're right, the Vortex86EX only has a single DMA channel (DRQ1,DACK1) exposed on its stripped-down ISA bus. Thing is though, you only need a single DMA channel for the CS4237B.
Hope your head's feeling better! 😉

Update:
Finally got the last components in stock @ JLC, and ordered the third prototype. This one was panelized with 4 FM synth boards to save on cost.
Also made room for an optional 0.91" I2C-controlled OLED display to be attached directly to the board because why not. Could be used for debugging purposes, showing system info or whatever.

Amazing. Well done.

Eivind wrote on 2023-07-20, 09:57:

You're right, the Vortex86EX only has a single DMA channel (DRQ1,DACK1) exposed on its stripped-down ISA bus. Thing is though, you only need a single DMA channel for the CS4237B.

I suspect that will be fine for this design's intended use cases, but with only one DMA channel, you give up the possibility of full-duplex audio functionality. You can do half-duplex at best, with priority given to playback on the CS4237.

640K!enough wrote on 2023-07-21, 19:28:

Eivind wrote on 2023-07-20, 09:57:

You're right, the Vortex86EX only has a single DMA channel (DRQ1,DACK1) exposed on its stripped-down ISA bus. Thing is though, you only need a single DMA channel for the CS4237B.

I suspect that will be fine for this design's intended use cases, but with only one DMA channel, you give up the possibility of full-duplex audio functionality. You can do half-duplex at best, with priority given to playback on the CS4237.

It was my understanding that this would only affect simultaneous WSS playback and capture of audio, and the only drawback would be higher CPU usage because of the single DMA channel available. Is this correct? What, if any, real-world limitations would this pose, given that the CPU is very fast for an ISA-card era computer?

Eivind wrote on 2023-07-21, 19:37:

It was my understanding that this would only affect simultaneous WSS playback and capture of audio, and the only drawback would be higher CPU usage because of the single DMA channel available. Is this correct? What, if any, real-world limitations would this pose, given that the CPU is very fast for an ISA-card era computer?

I haven't actually validated this, so we're working under the assumption that my interpretation of the datasheet is correct, and that the datasheet itself is accurate (for once). Firstly, since WSS and SB modes are mutually-exclusive, and SB mode doesn't allow any such thing (in the time of DSP 3.x), we only need to discuss WSS mode.

I don't see any reason that you couldn't do simultaneous recording and playback via PIO, though CPU usage would definitely be higher in that case. If the software is designed only to handle digital audio via DMA, the datasheet seems to suggest that you can only do either recording or playback at any one time, and priority is given to playback. Whether you could try to use any software tricks to implement quasi-full-duplex functionality by repeatedly re-programming the registers and initiating new DMA cycles in FIFO-sized chunks isn't clear, but I'm not sure what you would gain over PIO at that point.

I wouldn't expect anyone to be using such a machine to place voice or video calls, nor use it for any other application requiring full-duplex audio capabilities. In terms of real-world limitations, I would say they are effectively non-existent. In the worst case, if someone did try a voice call, it would operate much like a push-to-talk type of communication interface, where you can only speak or listen at any one time. For gaming or even simple audio recording, it shouldn't pose any problems. With the Orpheus cards, most configurations that I have seen don't even assign a capture DMA channel; for those who do, it is usually more out of a lack of understanding of what is being configured, than a genuine need for it.

640K!enough wrote on 2023-07-21, 20:02:

I haven't actually validated this, so we're working under the assumption that my interpretation of the datasheet is correct, and that the datasheet itself is accurate (for once). Firstly, since WSS and SB modes are mutually-exclusive, and SB mode doesn't allow any such thing (in the time of DSP 3.x), we only need to discuss WSS mode.

I don't see any reason that you couldn't do simultaneous recording and playback via PIO, though CPU usage would definitely be higher in that case. If the software is designed only to handle digital audio via DMA, the datasheet seems to suggest that you can only do either recording or playback at any one time, and priority is given to playback. Whether you could try to use any software tricks to implement quasi-full-duplex functionality by repeatedly re-programming the registers and initiating new DMA cycles in FIFO-sized chunks isn't clear, but I'm not sure what you would gain over PIO at that point.

I wouldn't expect anyone to be using such a machine to place voice or video calls, nor use it for any other application requiring full-duplex audio capabilities. In terms of real-world limitations, I would say they are effectively non-existent. In the worst case, if someone did try a voice call, it would operate much like a push-to-talk type of communication interface, where you can only speak or listen at any one time. For gaming or even simple audio recording, it shouldn't pose any problems. With the Orpheus cards, most configurations that I have seen don't even assign a capture DMA channel; for those who do, it is usually more out of a lack of understanding of what is being configured, than a genuine need for it.

Great, thank you very much for this in-depth explanation!
I was never really worried about the lack of a second DMA channel, either from reading the datasheet or from my actual experience with the CS4237 on both the TinyLlama and the ITX prototype - and what you just described seems to substantiate my assumptions nicely.

Btw, with fear of heading down the rabbit hole - this is not the first time you've mentioned inaccuracies in the datasheet; do you feel like elaborating on this...? 😁

Eivind wrote on 2023-07-21, 20:14:

Btw, with fear of heading down the rabbit hole - this is not the first time you've mentioned inaccuracies in the datasheet; do you feel like elaborating on this...? 😁

Unfortunately, it's not just a claim that I can't prove. In some cases, I even went so far as to add warning comments to my code to remind myself of previous disasters, so that I don't repeat the mistakes.

One example is that they will often state that, once configured, certain features can only be changed by removing power from the device. I have found that that is not true, in almost every case.

The other glaring cases are incorrect power-up default values for registers and inconsistent behaviour between cold boot, warm boot and software reset. Getting predictable, consistent performance out of this chip can get interesting. However, if you're just planning to use CWDINIT and the basic Windows drivers, you can probably skip all of the register fun.

I have been thinking about a hardware based virtual CD that does the job of SHSUCDX.
Would you guys think that would be a useful thing for the Tiny Llama project?

ahmadexp wrote on 2023-07-31, 01:18:

I have been thinking about a hardware based virtual CD that does the job of SHSUCDX.

Have you seen this thread? Gotek like Optical Driver Emulator - Is it possible?

ahmadexp wrote on 2023-07-31, 01:18:

I have been thinking about a hardware based virtual CD that does the job of SHSUCDX.
Would you guys think that would be a useful thing for the Tiny Llama project?

It would be more useful than just for this project, especially if it's affordable 😃

Deksor wrote on 2023-07-31, 14:50:

ahmadexp wrote on 2023-07-31, 01:18:

I have been thinking about a hardware based virtual CD that does the job of SHSUCDX.
Would you guys think that would be a useful thing for the Tiny Llama project?

It would be more useful than just for this project, especially if it's affordable 😃

It would indeed be very cool, but I don't think it's in the cards for this particular project, unfortunately - at least not a general version as was described in the thread linked above, because the Vortex86EX doesn't have any physical IDE pins. I think a virtual cd-rom drive could very well be made, since the BIOS is open to tinker with - but it would be something else to get "red book" cd audio working.
A virtual cd-rom drive without this already exists in the form of DOS and Windows programs, as we know.

Might be something to look at as a separate project later on I guess, but I'm way too busy already getting this project over the finish line... 🤪

Just got 5 of these delivered... hopefully I'll get some time later to play around with them and see what's working...
🤞🤞🤞

You could use an iodd ST400 for a virtual CD/DVD and FDD drive.

I didn't know about this and it looks quite sick, however there's a big drawback : no CD audio out either, so the only thing it brings is being able to boot from virtual CDs (and floppy disks). I do wonder if it's possible to hook up a sata cd-rom drive here, some may still have audio jacks or at least the footprint for them. Or an IDE drive with a sata to ide adapter

Update:
I got the PWM RGB LED (red for standby, green for power-on, yellow for HDD activity) working, as well as the HDD activity clicker. I need to experiment a bit further and tune the sound, but very promising so far.
The HDD activity is controlled from hooking into disk routines in the BIOS, so I can be fancy and fine-tune the the frequency, duration, etc based on what kind of disk activity there is; reads, writes, device, lba address etc. Will hopefully be an improvement to static, single sounds based on the HDD LED on other solutions.

Also: the external FM synth module works a treat! Not a ton of difference in sound compared to the CS4237 internal FM synth, but a bit better and clearer I would say.

640K!enough: looks like I hit the output analog voltage pretty accurately, the volume is close to the internal synth, and no clipping! 🎉