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.
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
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.
Okay now you're someplace without internet but you have your 128GB workstation laptop with a 24GB GPU. Still waiting to work on a project that has assets "online if you just search"?
Or are you going to make a font by hand? From memory?
Not everything has to be done the way you think it needs to be done.
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.
There is a precedence for embedding x86 in music hardware. Roger Linn's original LM-1, LinnDrum and Linn 9000 (http://studiorepair.com/gallery/Linn/9000/index.htmlhttps://www.elektronauts.com/t/the-seminal-groovebox-linn-90...) were full 8088 PCs with custom cards. Successor MPC60 designed by Roger Linn for Akai was powered by Intel 80186. Final Linn's sampler, the legendary Akai MPC3000 is based on SOC form (NEC V53) of NEC V33, a 80186 compatible with microcode replaced by hardwired logic giving it clock for clock performance of 286 and immunity from Intel Microcode lawsuits.
The Sequential Prophet X is another modern synth with a full-blown x86 PC running inside it. You can see the mainboard in this video: https://www.youtube.com/watch?v=Q8QDCocnt0M
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/
But then you would have to redo the whole layout and design of the chip right? Surely you can’t just scale the mask and manufacture the same chip at different scales and everything still works?
Check out the Intel Quark, it was a <50mhz x86 that was resized and re-done on a smaller feature fab and runs on a watch battery (its a bios battery), a full x86 SOC!
I dont know what feats of engineering went into it, it is discontinued, but it is a very tiny x86
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.
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.
I'm curious how compatible that AMD Elan is to actual PCs.
It's 100% PC/AT compatible, a "PC-on-a-chip" type SoC.
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
The Github page that the article links to at the bottom is Chris Noeding. Thus they are the same.
[dead]
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.
Okay now you're someplace without internet but you have your 128GB workstation laptop with a 24GB GPU. Still waiting to work on a project that has assets "online if you just search"?
Or are you going to make a font by hand? From memory?
Not everything has to be done the way you think it needs to be done.
but you have your 128GB workstation laptop with a 24GB GPU
...which has a VBIOS you can extract the font from.
Just one? Even your standard Linux install will contain a couple dozen such fonts.
Most likely, the goal here was copyright laundering.
There’s a bunch of free character roms as well.
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.
https://en.wikipedia.org/wiki/AMD_%C3%89lan
https://en.wikipedia.org/wiki/Nokia_9110_Communicator
There is a precedence for embedding x86 in music hardware. Roger Linn's original LM-1, LinnDrum and Linn 9000 (http://studiorepair.com/gallery/Linn/9000/index.html https://www.elektronauts.com/t/the-seminal-groovebox-linn-90...) were full 8088 PCs with custom cards. Successor MPC60 designed by Roger Linn for Akai was powered by Intel 80186. Final Linn's sampler, the legendary Akai MPC3000 is based on SOC form (NEC V53) of NEC V33, a 80186 compatible with microcode replaced by hardwired logic giving it clock for clock performance of 286 and immunity from Intel Microcode lawsuits.
It's coming to an end due to the proliferation of cheap ARM boards. I think the Korg Kronos is the last holdout using a standard x86 PC mainboard now.
The Sequential Prophet X is another modern synth with a full-blown x86 PC running inside it. You can see the mainboard in this video: https://www.youtube.com/watch?v=Q8QDCocnt0M
I know, but it's been discontinued 2 years ago. As far as I know only the Kronos is still available new.
Fascinating, thank you!
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.
> 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.
Since they are out of patent, curious if anyone would be willing to manufacture it again.
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/
But then you would have to redo the whole layout and design of the chip right? Surely you can’t just scale the mask and manufacture the same chip at different scales and everything still works?
Check out the Intel Quark, it was a <50mhz x86 that was resized and re-done on a smaller feature fab and runs on a watch battery (its a bios battery), a full x86 SOC!
I dont know what feats of engineering went into it, it is discontinued, but it is a very tiny x86
The Quark core lives on as a control processor inside Intel CPUs - https://pbx.sh/intelme_talk.pdf
A lot of SoCs in monitors have a 186-compatible core:
https://www.cpushack.com/2013/01/12/the-intel-80186-gets-tur...
I found a 386 compatible linux image: https://github.com/hatonthecat/linux_distro_tests/commit/816... It's a floppy image, although there are other bootable isos in on of the other folders.
I went into this think "Oh another mini x86 board, thats cool". I was not expecting a mixing deck to pop up. Very nice.
Will it run Doom?
same number of characters, 386 is more informative than x86
[flagged]
Its practically media-archeology yes
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.
[dead]