florian3 wrote on 2024-01-07, 17:50:

Digikey has a Cliff FCR684204T

Yes, look at that! 😀 Thanks!
Here's what I think might fit on a single bracket:
TRS-style (3.5mm) MIDI out
3.5mm line in
3.5mm line/headphone out + optical out
Female USB-A
DB-15

MIDI-in would have to be through the DB-15, and no microphone in.
This I think would do nicely for me personally.

EDIT: Actually, it looks like the bracket is wide enough that a vertical USB port would fit as well. Then there's definitely room.

I will say that I also really like the idea of the ROM socket on the board for XT-IDE. It's not specifically sound related, but I love the idea of saving ISA slot space. I have a system I have with only 3 ISA slots that I already want to put this card in. 😀

danieljm wrote on 2024-01-08, 21:01:

I will say that I also really like the idea of the ROM socket on the board for XT-IDE. It's not specifically sound related, but I love the idea of saving ISA slot space. I have a system I have with only 3 ISA slots that I already want to put this card in. 😀

Duly noted! 😉

I'm not quite sure what you're planning for this yet, but it sounds like it can offer some interesting and unique possibilities. Having an MCU of some description that can insert itself in the CS4237's bus cycles could potentially allow one to get rid of some of its lingering annoyances. I have been thinking about such a design lately, and budget-permitting, I may take a stab at it at some point. For me, it would have to be a simple, inexpensive design (as much as that is ever really possible); the star of the show would really be what is loaded into the MCU, which, tentatively, would likely be some variant of AVR.

I like the idea of modularity, though, so I would likely end up with an ugly Frankenstein board with mediocre audio quality that exists only for experimentation.

640K!enough wrote on 2024-01-14, 22:52:

I'm not quite sure what you're planning for this yet, but it sounds like it can offer some interesting and unique possibilities. Having an MCU of some description that can insert itself in the CS4237's bus cycles could potentially allow one to get rid of some of its lingering annoyances. I have been thinking about such a design lately, and budget-permitting, I may take a stab at it at some point. For me, it would have to be a simple, inexpensive design (as much as that is ever really possible); the star of the show would really be what is loaded into the MCU, which, tentatively, would likely be some variant of AVR.

I like the idea of modularity, though, so I would likely end up with an ugly Frankenstein board with mediocre audio quality that exists only for experimentation.

Let me try to sum up my goals:
1. Have fun designing the card - the design and build process is (at least it can be) a relaxing hobby, and I mainly want to design something I'd like to use myself.
2. Like you said - I'll try to make it as cheap and accessible as possible.
3. Aim for good audio quality - I'll spend as much time as it takes to get a good layout going, with sensible ground planes and a bit of extra board space around the audio-path capacitors, to accommodate for different types (FG, Muse, whatever).
4. Try to get as much functionality as possible onto a relatively small card.

When I started this thread I thought I could simply use the ATmega1284p to initialize the CS4237 directly, but I'm not sure it's that easy... Can't just hijack the ISA bus, still thinking about this.
Besides running the initialization routine, what other possibilities (if any) did you have in mind?

Eivind wrote on 2024-01-14, 23:23:

Besides running the initialization routine, what other possibilities (if any) did you have in mind?

One thing that is fairly popular with some people here is full jumper-based configuration. An MCU would let you read the desired configuration and apply it at boot, while (potentially) still allowing for the PnP process for those who want it (or drivers that depend upon it). There are a few ways to approach that one.

An MCU can also enable a number of other things that are frequently on the desired feature list, but I am unsure of the feasibility as yet. That is the reason I've been thinking about the CS4237-based Frankenstein board; to allow all sorts of experimentation (and settle some long-standing questions), hopefully without driving costs through the roof. For that purpose, I am willing to compromise on audio quality, while I see what can and can't be made to work.

Eivind wrote on 2024-01-14, 23:23:

When I started this thread I thought I could simply use the ATmega1284p to initialize the CS4237 directly, but I'm not sure it's that easy... Can't just hijack the ISA bus, still thinking about this.

I'm fairly certain that that one can be done, but I wouldn't even think of just spamming the bus during boot. I think you'll find you need a few extra parts to make that one safe and functional. However, any such implementation will need to be thoroughly tested to see how it interacts with the PnP BIOS and existing drivers.

You got away with it last time because you were in full control of the BIOS and boot process, and there was only one device on the resource-constrained bus (and the main CPU was the one doing the "talking").

640K!enough wrote on 2024-01-15, 01:39:

One thing that is fairly popular with some people here is full jumper-based configuration. An MCU would let you read the desire […]
Show full quote

Eivind wrote on 2024-01-14, 23:23:

Besides running the initialization routine, what other possibilities (if any) did you have in mind?

One thing that is fairly popular with some people here is full jumper-based configuration. An MCU would let you read the desired configuration and apply it at boot, while (potentially) still allowing for the PnP process for those who want it (or drivers that depend upon it). There are a few ways to approach that one.

An MCU can also enable a number of other things that are frequently on the desired feature list, but I am unsure of the feasibility as yet. That is the reason I've been thinking about the CS4237-based Frankenstein board; to allow all sorts of experimentation (and settle some long-standing questions), hopefully without driving costs through the roof. For that purpose, I am willing to compromise on audio quality, while I see what can and can't be made to work.

Eivind wrote on 2024-01-14, 23:23:

When I started this thread I thought I could simply use the ATmega1284p to initialize the CS4237 directly, but I'm not sure it's that easy... Can't just hijack the ISA bus, still thinking about this.

I'm fairly certain that that one can be done, but I wouldn't even think of just spamming the bus during boot. I think you'll find you need a few extra parts to make that one safe and functional. However, any such implementation will need to be thoroughly tested to see how it interacts with the PnP BIOS and existing drivers.

You got away with it last time because you were in full control of the BIOS and boot process, and there was only one device on the resource-constrained bus.

Yeah I was thinking I'd need to isolate the CS/MCU from the rest of the bus while doing the initialization, and then attach them when done. A challenge with this is that the Crystal chip exposes so many address lines, in addition to the 8 data lines. This kinda smells like a pin-heavy cpld, if one is to avoid a whole bunch of glue logic chips. Which at first I thought sounds like an overly complex idea, but might not be so bad considering there's lots of glue logic required for the HardMPU and PicoGUS parts as well. Some food for thought this, for sure.

Edit: I think using a CPLD is definitely the way to go, makes for a lot fewer components, and gives me full programmable access to all glue logic, easy to isolate certain lines, etc. I've (briefly) used the AMD/Xilinx XC9500XL series ICs earlier, they're reasonably affordable and available for assembly at JLC, which is always a plus.

Eivind wrote on 2024-01-15, 02:01:

Yeah I was thinking I'd need to isolate the CS/MCU from the rest of the bus while doing the initialization, and then attach them when done. A challenge with this is that the Crystal chip exposes so many address lines, in addition to the 8 data lines. This kinda smells like a pin-heavy cpld, if one is to avoid a whole bunch of glue logic chips. Which at first I thought sounds like an overly complex idea, but might not be so bad considering there's lots of glue logic required for the HardMPU and PicoGUS parts as well. Some food for thought this, for sure.

Edit: I think using a CPLD is definitely the way to go, makes for a lot fewer components, and gives me full programmable access to all glue logic, easy to isolate certain lines, etc. I've (briefly) used the AMD/Xilinx XC9500XL series ICs earlier, they're reasonably affordable and available for assembly at JLC, which is always a plus.

If all you want to do is an early boot-stage initialisation of the CS4237, you might be better off implementing it as an option ROM. That would have it run on the host CPU during boot, eliminating unnecessary complexities like isolating the chip from the bus, and worrying about potential effects on the PnP BIOS features.

640K!enough wrote on 2024-01-15, 18:17:

If all you want to do is an early boot-stage initialisation of the CS4237, you might be better off implementing it as an option ROM. That would have it run on the host CPU during boot, eliminating unnecessary complexities like isolating the chip from the bus, and worrying about potential effects on the PnP BIOS features.

That would be way smarter (and much easier), yes! Thank you! 😁

I'm glad I ordered some CS4237 and OPL3 chips just-in-case when I was inspired by the ITX-Llama. I'd be very interested in building one of these. Also, I agree that at least support for the XTIDE BIOS ROM would be nice. Maybe dual option-ROMs on one EEPROM? Or someone could modify XTIDE to do the Crystal init.

valterb wrote on 2024-01-23, 20:15:

I'm glad I ordered some CS4237 and OPL3 chips just-in-case when I was inspired by the ITX-Llama. I'd be very interested in building one of these. Also, I agree that at least support for the XTIDE BIOS ROM would be nice. Maybe dual option-ROMs on one EEPROM? Or someone could modify XTIDE to do the Crystal init.

I've been playing around with the crappy Xilinx ISE software, trying to put together a meaningful design for the CPLD. I think I'm pretty close, but I have a few thoughts that might just make me go with discrete glue logic instead;
* The XC9500XL series chips are 5V-input tolerant, but will obviously only output 3.3V. That's fine for TTL-logic (well above 2V), but I can't really find any specs about current drive per pin. That might represent a problem, and if so will likely only manifest itself in certain conditions (this particular mainboard, populated with these particular cards, etc). So potentially hard to debug.
* These Xilinx CPLDs are fairly easy to get hold of as of right now, but it might not last. If I remember correctly, they were gone everywhere during the chip shortage.
* They're not exactly cheap (say, $8-$15, depending on configuration and vendor). You can get a lot of discrete 74-series chips for that price.
* I was initially hesitant of using discrete glue logic because of space constraints, thinking I'd go with all components on one side of the board. However, most of these are super-slim TSSOP variants that can easily be put on the back side.

To your point about EEPROMs - I was actually thinking about using two separate chips, but as you say, one can easily put two ROMs on a single chip - keeping in mind address decoding boundaries and space concerns, obviously. Might make programming harder from DOS, though. Not (yet) familiar with the XTIDE firmware, but it might be possible to modify that as well, yes. I was kinda into the idea that you should be free to put whatever ROM you wanted into the EEPROM though - but I'm not sure what other useful things other than XTIDE one might want...?

Eivind wrote on 2024-01-23, 20:53:

but I'm not sure what other useful things other than XTIDE one might want...?

I put a ROM card in one of my older 486 machines that patches the BIOS to be Y2K compliant. I could see removing the need for that separate card coming in handy.

Ok, so after thinking about this a bit more, here's my revised plan:
- Dropping the HardMPU hardware - I think the PicoGUS should be able to handle intelligent mode MPU-401 just as well (if not better). The only downside is that you have to re-program the RP2040 when switching between GUS and MIDI, but that only takes a couple of seconds using the utility from DOS.
- I'll ditch the CPLD and stick with tried and true discrete smd components.
- Two ROMs, one dedicated to setting up and configuring the CS4237 and one for whatever else (most likely XTIDE option ROM) One flash chip, you can put several ROMs on it.

Schematic and component selection done, currently doing layout and routing...

Nearing completion of the first prototype:

Looks great, looking forward to get one, I always though the pi 2 zero connection was a brilliant idea on the Llama ITX.

Tried experimenting with rounded traces, I think it looks cool:

Almost ready to order the first prototype batch now.

Indeed, looks great! And you're mighty fast in your project! Took me weeks to finish my card two years back.
I actually also tried converting my version into rounded tracks a few weeks ago and that instantly made the DRC and Kicad crash. That issue has been fixed by now, though 😀

On a side note, is DRC ok with this part (that bend on the right, middle side)?
It looks like it might violate the minimum spacing you're having everywhere else ->

MJay99 wrote on 2024-02-19, 10:43:

Indeed, looks great! And you're mighty fast in your project! Took me weeks to finish my card two years back.
I actually also tried converting my version into rounded tracks a few weeks ago and that instantly made the DRC and Kicad crash. That issue has been fixed by now, though 😀

Thanks! I ran the "Round Tracks" plugin (from https://github.com/mitxela/kicad-round-tracks), and it worked pretty well! Had to touch up and adjust like 50 or so tracks that violated the DRC, but it didn't take that long. The (relatively) new "Fillet tracks" option in Kicad is awesome, gone are the days of making or adjusting hundreds of tiny line segments in order to get a smooth curve!

MJay99 wrote on 2024-02-19, 10:43:

On a side note, is DRC ok with this part (that bend on the right, middle side)?
It looks like it might violate the minimum spacing you're having everywhere else ->
drc.jpg

Yep, I've set a minimum track clearance of 5 mils - what you're pointing to there resolves to 5.92 mils, so no issues. 😀

First prototype batch is in production. I had to do a cancel+re-order because JLC doesn't like the trace clearance to be <0.15mm if there is less than 30% copper fill on a layer - which is weird and undocumented. But I got it sorted in any case.
Here's a render of the prototype:

...also, got a couple of nice bags o'caps in the mail this morning:

Now I've gotta make a suitable 3D-printed bracket.