Next I will probably try DR-DOS (or rather SvarDOS). It even has its own UMB provider included.
So I installed
SvarDOS. I first installed it in Virtual Box. It is
important to choose manual partitioning of the drive since the SvarDOS installer will otherwise format the drive as FAT32 and that's not supported on 8086. In FDISK disable FAT32 support. I recommend to install with the complete
repo archive. After installation, copy all the *.svp files to some place on the disk, so you can install stuff afterwards. I then exported the Virtual Box VDI to a raw image, e.g.:
Bash:
VBoxManage clonehd SvarDOS\ \(DR\ DOS\)/SvarDOS\ \(DR\ DOS\).vdi svardos.img --format raw
You can then flash svardos.img to the CF card and copy some more absolutely necessary files to the disk, like the CH375 driver.
Once in SvarDOS, I tried all of the UMB providers, but they all either did not boot to the shell or the UMBs wouldn't even be shown by MEM. I had some success with the DRHIMEM driver:
Code:
pkg install repo\drhimem.svp
Then add a line like this to CONFIG.SYS:
Code:
DEVICE=C:\DRIVERS\DRHIMEM\HIMEM.SYS /CHIPSET=RAM /USE=D000-EFFF
Or D000-F000 would probably also work. The problem is that the same bug I described earlier will still happen under DR-DOS as well: If you actually load something into the UMBs, every time something tries to use the speaker, the system will hang. We investigated the issue in
this Github thread and it turns out that it's very easy to trigger by a typical read-modify-write cycle of IO port 61h, which is commonly used to program the speaker. The 3rd bit (bit 2) must be 0 to enable the UMBs. The documentation falsely claims it's controlled by port 60h, while in reality, it's port port 61h. Now when you read 61h, you appear to get a hardwired 1 (even though there is a flip-flop that could return the current state!) and writing back that 1 on port 61h as 99.9% of DOS programs would do, will disable UMBs and cause a lockup once some TSR or DOS interrupt from the UMB kicks in. So this would basically be a bug in the CPLD, that cannot be fixed without reprogramming it. Perhaps it has already been fixed and we just got old revisions? But then, you can pretty much explain this behavior just by reading the schematics from their website.
So unless we get the CPLD source code and there is some undocumented way to force the bit in question low or ignore the UMB-enable-flag when reading port 61h, there is very little we can do about it. I can't think of a way to fix this in software, other than hand-patching each and every program that uses the speaker and possibly other IO ports as well. Or trapping on each and every instruction to clear the flag, which could work on the V30 at least. UMBs just appear to be broken on the Pocket 8086, for all practical purposes at least.
