I tried it on my compaq N610c with Simcity2000 but the game crashes right after printing the DOS/4GW message.
Not sure how to debug it further...

EduBat wrote on 2026-04-05, 16:03:

I tried it on my compaq N610c with Simcity2000 but the game crashes right after printing the DOS/4GW message.
Not sure how to debug it further...

Thanks for testing so far! 😃

If it's not too much trouble, you can try creating a debug-enabled build by uncommenting the line `DBGFLAGS = -DDEBUG_SERIAL` and running `make a32ichdg.dll`.

I just realized I should have published the debug-enabled variant along with the non-debug-enabled build in the prerelease. I'll do so soon.

In debug-enabled builds, debug output is sent to the first serial port (COM1:). Be aware that sound output might not work at all if you have an EMM like JEMM, EMM386 or QEMM loaded while testing with the debug-enabled build. (It's a performance issue w.r.t. intercepting I/O while also sending debug output to the serial port.)

So with the debug-enabled version of the DLL, you'd better test it in game only with HIMEM or HIMEMX loaded (or nothing at all), but no EMM managers.

If you managed to get some serial output and you can share it here, that would be much appreciated. Thanks! 🙂

I don't have a system to properly test this, believe it or not, but your effort is very much welcome. I find it amusing we both created drivers for old John Miles libraries, at pretty much the same time. I know how much of an undertaking this is so...all i can say is well done!!

I'm already planning my next step, and i want to create a Windows Sound System digital driver for AIL2.

carlostex wrote on Today, 12:47:

I don't have a system to properly test this, believe it or not, but your effort is very much welcome. I find it amusing we both created drivers for old John Miles libraries, at pretty much the same time. I know how much of an undertaking this is so...all i can say is well done!!

I'm already planning my next step, and i want to create a Windows Sound System digital driver for AIL2.

Thank you for your kind words. But I could not have done this without Claude, honestly. 😅

I had been toying with this stuff on and off for years, but didn't get around to it much. Also I was limited by my limited experience with assembly language programming and hardware driver programming in general.

The major breakthrough of the last few weeks was the assistance of an LLM, specifically Claude Code. I want to be absolutely honest about my use of AI assistance. And most of the code that it generated at my prompting was really hard (and often impossible) for me to review and comprehend at least at the instruction level.

I did perform manual testing myself, and told it to perform certain refactorings w.r.t. portability and future driver development in mind. But part of me still feels a bit guilty about having essentially vibe-coded most of the assembly language code.

That being said, it was really cool to actually hear sound with this driver in SimCity 2000 when I tried it out. Although it crashed very quickly afterwards... 🫠

I did some research, and apparently I can perform some better run-time in-game debugging if I replace the DOS/4GW DOS extender with Causeway, which apparently you can use as a drop-in replacement just like with DOS32A. That, and the Watcom debugger.

My next step is to write an AIL/32 driver (and possibly also a DIGPAK driver) for the virtio-snd paravirtualized sound device, as well as one for HDA.

What will be particularly interesting here will be marrying the assembly language code of the AIL/32 driver skeleton with C code ported from OSS, NetBSD or Linux. I've made some progress with that, though. Thanks in part to some friendly people helping me out with that over on VCFED. (And also some very useful insights from multiple LLMs.) 🙂

digger wrote on Today, 13:05:

Thank you for your kind words. But I could not have done this without Claude, honestly. :sweat_smile: […]
Show full quote

Thank you for your kind words. But I could not have done this without Claude, honestly. 😅

I had been toying with this stuff on and off for years, but didn't get around to it much. Also I was limited by my limited experience with assembly language programming and hardware driver programming in general.

The major breakthrough of the last few weeks was the assistance of an LLM, specifically Claude Code. I want to be absolutely honest about my use of AI assistance. And most of the code that it generated at my prompting was really hard (and often impossible) for me to review and comprehend at least at the instruction level.

I did perform manual testing myself, and told it to perform certain refactorings w.r.t. portability and future driver development in mind. But part of me still feels a bit guilty about having essentially vibe-coded most of the assembly language code.

That being said, it was really cool to actually hear sound with this driver in SimCity 2000 when I tried it out. Although it crashed very quickly afterwards... 🫠

I did some research, and apparently I can perform some better run-time in-game debugging if I replace the DOS/4GW DOS extender with Causeway, which apparently you can use as a drop-in replacement just like with DOS32A. That, and the Watcom debugger.

Well i also used AI, but now i'm curious because you're praising Claude Code a lot. Well i never heard about Claude Code before i only used the normal Claude. My use of AI was sporadic and saved time to write stuff but honestly sometimes it was more harmful than helpful. I had to correct a lot of stuff because AI was screwing up, not reading bits in the correct order for instance and insisting i was wrong and only agreeing after i prompted it was not working. You know how AI goes... Probably AI will be better on a higher level language than asm, for sure. However in a few PROCs AI was very helpful for me, even helping me understand some stuff i wasn't before. So AI was very helpful in building a good base and skeleton but i had to do a lot of correcting and heavy lifting myself. That was when real progress started to show.

I never used Claude Code. How different is it from normal Claude? Is it a paid service? I wonder how much better would it be than normal one, specially for 8086 asm. I think if we had a very specialized 8086 asm and DOS architecture LLM we could probably get much better results.

Claude Code is a coding assistant. I use the command-line TUI variant, which I launch in a shell session beside or inside my IDE. It then has a command-line interface, in which I can enter prompts, and then it will explain things to me if I ask for it, but also it can (if you give it permission) access files in the current folder, analyze them, suggest changes (it will show you diffs) and also apply them for you, and automate other stuff if you want. In a way, it's like your pair-programming with someone.

It probably uses the same (or very similar and perhaps somewhat different trained) models als Claude's general chat, so the difference is mostly in tooling, but I could be wrong.

I believe it's part of a regular Claude subscription. It's included with Claude Pro for sure.

To what extent you let it handle stuff for you, from just explaining and hinting, to have it generate just common boring boilerplate stuff to having it plan and implement complex solutions for your problems, that's up to you to decide and control.

Whatever you let it do, it will ask you permission for it first, unless you grant it broader permissions ("always allow acess to folder or URL x for the rest of this session", etc.)

Claude Code also exists as a plugin for popular IDEs (such as VSCode and JetBrains IDEs), but I prefer to use the TUI client.

If you resist the temptation to just use it as a magic wand, but instead prompt it in a way that is talks you through things and teaches you things, it can both accelerate your development and also improve your skills. But the opposite is true if you let it completely take the driver's seat while you take a nap in the back. Obviously.

There are various models you can choose between, the most powerful one being Opus. But Opus also burns tokens like crazy, so you pay a price for that sophistication. In many cases, Sonnet is considered the sweet spot. (There's also effort modes you can choose between for each model. Higher effort models are slower to respond and burn more tokens.)

I do have to say, that I've been experiencing Claude Code becoming slower and burning through tokens a lot faster than it was just a month ago. A lot of people on-line have been complaining on-line that Claude has been enshittifying lately.