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 bite written (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.
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.)
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.
* 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 bite written (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 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...