Great project! Kudos for figuring out all that stuff on your own. Assuming you are actually reading these comments, a few suggestions:
* C compilers that can target 16 bit x86 usually have support for "far pointers", which are 32 bit wide pointers consisting of both a 16 bit segment and a 16 bit offset. You should be able to use that instead of your assembly wrappers. This allows you to directly access screen memory in C, i.e. letting the compiler do the job of setting up the segment registers, which also has the great benefit of not having to push, write, and pop ES for every byte (if you copy a block into screen memory for example, the compiler only needs to set up the destination register once).
* The IVT is correspondingly also a list of FAR pointers. It's a common 16 bit x86 concept. The CPU knows about them, they are also more generally used for far jumps and far calls.
* As others have said, just pick one of the many, many available text mode font ROMs.
* I'm curious how compatible that AMD Elan is to actual PCs. Probably a lot, since by that time PCs were kind of the x86 standard, though not necessarily. The earlier 80186 with its integrated peripherals (interrupt controller etc.) was very incompatible, for example. Shouldn't impede your project, just dictates how easily you can run DOS programs overall.
Since the article assumes familiarity with the DDX3216 (or the lack of need thereof), I had to look it up: the DDX3216 was released in 2002, assuming this Sound on Sound review is contemporary: https://www.soundonsound.com/reviews/behringer-ddx3216
More background information: the Behringer brand has always very intentionally targeted the budget-conscious customer. One way they have achieved their low price targets has been to straight-up clone competitors’ products, building them with cheaper components and cheaper labor.
But they also do their own R&D, both within, erm, “familiar” physical form factors and in totally novel designs. I have no idea if this product is specifically inspired by any other studio-in-a-box, but my gut reaction is that no other competitor in this space would have sourced a damn 386-compatible CPU for such a product line in 2002.
My guess is Behringer got a great deal on some second-source manufacturer’s last stock of 386s (maybe in bankruptcy?), and only that kind of deal would have enabled Behringer to enter this market.
If anyone has a more informed take, I would love to waste time reading about the history of this thing!
but my gut reaction is that no other competitor in this space would have sourced a damn 386-compatible CPU for such a product line in 2002.
These days ARM and Linux seems to be the go-to, but DOS and embedded x86 has a long history stemming from the glory days of the IBM PC architecture and the openness of its software ecosystem. You could easily write and test your application on a PC (perhaps with additional peripheral card(s) that would be integrated into the target) and then directly run the binary on the target device.
The requirements for DOS are much less than for true PC-compatibility, which is why there were many "DOS-compatible" x86 machines in the early days, but they soon fell out of favour as the truly IBM PC-compatible clones took over.
I found this part of the process unusual:
In total my final font-header-file is about 22kB but it was a great relief to use AI for this dumb task. Google Gemini produced a nice font for my BIOS. On individual characters I had to fix some pixel-errors
Instead of simply searching for one of the numerous font-dumps that exist on the Internet, which will already be 100% correct for all of CP437? The CGA font would be a good match (and the one he ended up using looks like it), but there are plenty of other 8x8 fonts available.
> Instead of simply searching for one of the numerous font-dumps that exist on the Internet
On the other hand I enjoy reading about all the things people are recreating with LLMs, since it gives an idea of what's not just possible, but actually practical, in case I ever need something similar.
(This may be a short-lived preference though, if it gets to the point where just about anything within reason is practical.)
It's one thing to use an LLM to create something new, but to get it to regurgitate an imperfect version of something that already exists and is easily found, and then have to spend time fixing it, hardly seems like a good use.
Cool project! This reminds me of Chis Noeding's YouTube Channel, where he's been posting his progress on running custom firmware on the newer Behringer X32 mixers - https://www.youtube.com/@pcdimmer
Using x86 in embedded products is not new, especially older ones from the 90s, it was extremely common actually to run DOS or VXworks or QNX. It's all over industrial products. In fact Intel still shipped 386 CPUs until a few years ago.* It's cool and all but if we wrote blog posts about all of them you'd be set for the next 10 years.
* Supposedly 2007 but that does not sound right for embedded customers unless Intel built a lifetime supply.
This is standard practice for low-volume legacy parts. A single production run will often yield enough parts for months or even years of demand; once demand gets low enough, the manufacturer will just sell what's left of the last batch, and discontinue the part when that runs out.
If there wasn't enough demand ~20 years ago for Intel to continue manufacturing the part, it's far less likely that there's enough demand now to justify designing, manufacturing, and qualifying a new part to replace it.
Wafer.space slots can support around 4-500,000 transistors in 1x1 titles, usually reserved for 1000 dies. The 386 (non SLC version) had 275,000. In theory this could be manufactured at 180nm/130nm https://wafer.space/
The DDX3216 was such a nice piece of tech to work with, sure it had its flaws, but compared to what else was out there the value was just insane for the time.
* C compilers that can target 16 bit x86 usually have support for "far pointers", which are 32 bit wide pointers consisting of both a 16 bit segment and a 16 bit offset. You should be able to use that instead of your assembly wrappers. This allows you to directly access screen memory in C, i.e. letting the compiler do the job of setting up the segment registers, which also has the great benefit of not having to push, write, and pop ES for every byte (if you copy a block into screen memory for example, the compiler only needs to set up the destination register once).
* The IVT is correspondingly also a list of FAR pointers. It's a common 16 bit x86 concept. The CPU knows about them, they are also more generally used for far jumps and far calls.
* As others have said, just pick one of the many, many available text mode font ROMs.
* I'm curious how compatible that AMD Elan is to actual PCs. Probably a lot, since by that time PCs were kind of the x86 standard, though not necessarily. The earlier 80186 with its integrated peripherals (interrupt controller etc.) was very incompatible, for example. Shouldn't impede your project, just dictates how easily you can run DOS programs overall.
It's 100% PC/AT compatible, a "PC-on-a-chip" type SoC.
More background information: the Behringer brand has always very intentionally targeted the budget-conscious customer. One way they have achieved their low price targets has been to straight-up clone competitors’ products, building them with cheaper components and cheaper labor.
But they also do their own R&D, both within, erm, “familiar” physical form factors and in totally novel designs. I have no idea if this product is specifically inspired by any other studio-in-a-box, but my gut reaction is that no other competitor in this space would have sourced a damn 386-compatible CPU for such a product line in 2002.
My guess is Behringer got a great deal on some second-source manufacturer’s last stock of 386s (maybe in bankruptcy?), and only that kind of deal would have enabled Behringer to enter this market.
If anyone has a more informed take, I would love to waste time reading about the history of this thing!
These days ARM and Linux seems to be the go-to, but DOS and embedded x86 has a long history stemming from the glory days of the IBM PC architecture and the openness of its software ecosystem. You could easily write and test your application on a PC (perhaps with additional peripheral card(s) that would be integrated into the target) and then directly run the binary on the target device.
https://en.wikipedia.org/wiki/AMD_%C3%89lan
https://en.wikipedia.org/wiki/Nokia_9110_Communicator
I found this part of the process unusual:
In total my final font-header-file is about 22kB but it was a great relief to use AI for this dumb task. Google Gemini produced a nice font for my BIOS. On individual characters I had to fix some pixel-errors
Instead of simply searching for one of the numerous font-dumps that exist on the Internet, which will already be 100% correct for all of CP437? The CGA font would be a good match (and the one he ended up using looks like it), but there are plenty of other 8x8 fonts available.
On the other hand I enjoy reading about all the things people are recreating with LLMs, since it gives an idea of what's not just possible, but actually practical, in case I ever need something similar.
(This may be a short-lived preference though, if it gets to the point where just about anything within reason is practical.)
* Supposedly 2007 but that does not sound right for embedded customers unless Intel built a lifetime supply.
This is standard practice for low-volume legacy parts. A single production run will often yield enough parts for months or even years of demand; once demand gets low enough, the manufacturer will just sell what's left of the last batch, and discontinue the part when that runs out.
https://www.cpushack.com/2013/01/12/the-intel-80186-gets-tur...