USBDDOS not working on an AMD system with an Asus M4A88T-M/USB3 motherboard

[volkertb]

I've just tried testing it on a different machine, and it failed. Although it bears mentioning that this was on an installation with SBEMU already loaded. (This installation is based on the SBEMU USB image that is automatically created on each release by GitHub Actions, so including Jemmex, HDPMI32i and SBEMU.) Perhaps that isn't supported yet?

The command hang for a while, then gave an error and showed a command prompt again, but it was no longer responsive to keyboard input, and the system had to be restarted.

See the screenshot below:

I also retried this without lh, but that didn't make any difference, and it crashed in the same way.

I still have yet to try it with a debug-enabled build, as you suggested, or without having SBEMU loaded first.

To give you more info about the CPU and motherboard chipset of this system:

Output of cat /proc/cpuinfo:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 6
model name      : AMD Athlon(tm) II X2 250 Processor
stepping        : 3
microcode       : 0x10000c8
cpu MHz         : 800.000
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save
bugs            : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400 spectre_v1 spectre_v2
bogomips        : 6027.05
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 6
model name      : AMD Athlon(tm) II X2 250 Processor
stepping        : 3
microcode       : 0x10000c8
cpu MHz         : 800.000
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save
bugs            : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400 spectre_v1 spectre_v2
bogomips        : 6027.05
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

Output of lspci:

00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] RS880 Host Bridge
00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI bridge (ext gfx port 0)
00:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI bridge (PCIE port 2)
00:0a.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 5)
00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:12.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller
00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller (rev 3c)
00:14.1 IDE interface: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 IDE Controller
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller
00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI Bridge
00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Link Control
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 430] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF108 High Definition Audio Controller (rev a1)
02:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

Originally posted by @volkertb in https://github.com/crazii/USBDDOS/issues/5#issuecomment-1872052804

[volkertb]

With a debug-enabled build that I built locally, I recorded a video of the output, since a lot of debug logging scrolled past the screen before it ultimately failed in the same way as the non-debug-enabled build:

https://github.com/crazii/USBDDOS/assets/518023/99a7b7ff-f15a-47cf-b880-2e29efeb2dcc

At the end of the video, you can hear me mashing on the keyboard, but as you can see, the system doesn't respond to any keyboard input at that point, in addition to no longer being able to read from the C: driver it was booting from.

[volkertb]

Also, here is the output of lsusb -t for this same motherboard:

/:  Bus 09.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/3p, 12M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/3p, 12M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/3p, 12M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 12M
        |__ Port 1: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 2: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 3: Dev 7, If 0, Class=Wireless, Driver=btusb, 12M
        |__ Port 3: Dev 7, If 1, Class=Wireless, Driver=btusb, 12M
        |__ Port 3: Dev 7, If 2, Class=Vendor Specific Class, Driver=, 12M
        |__ Port 3: Dev 7, If 3, Class=Application Specific Interface, Driver=, 12M
    |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 2: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 3: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
    |__ Port 5: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M
    |__ Port 5: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/3p, 12M
    |__ Port 3: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
    |__ Port 1: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 1: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M
    |__ Port 1: Dev 2, If 2, Class=Audio, Driver=snd-usb-audio, 480M
    |__ Port 1: Dev 2, If 3, Class=Audio, Driver=snd-usb-audio, 480M

[volkertb]

As I mentioned here, the same problem occurred when I tried to load USBDDOS without having SBEMU loaded.

[volkertb]

Trying both /HID and /DISK (so LH D:\USBDDOSP.EXE /HID /DISK) instead of just /HID got the same result. The C: drive couldn't be accessed anymore.

I'm now going to try it with just /DISK, so without /HID.

[volkertb]

I just tried it with only /DISK (without /HID), and I got the exact same result, and C: wasn't accessible anymore either.

I'm now going to try it without HDPMI32i loaded, but with both /HID and /DISK options enabled.

By the way, I'm testing all of this in a recent bootable SBEMU USB image from the SBEMU releases. Initially I tested it with SBEMU loaded, but all other tests I've tried since so far have been without SBEMU loaded.

[volkertb]

Okay, that was pretty pointless, since it just resulted in Load error: no DPMI - Get csdpmi*b.zip.

Even just running USBDDOSP.EXE /? to get the help info would result in that error, so that binary actually requires a DPMI host.

@crazii How useful would it be to retry this with a different DPMI host, one that does not have the port-trapping API of your HDPMI32i fork? Would USBDDOSP fall back to supporting port-trapping in real mode only? And would it help troubleshooting this issue? Ultimately, the whole point is for the tool to support both real mode and protected mode applications, right?

I'll be leaving soon, and I won't always have access to this machine. But perhaps the info I already shared with you above already gives you some useful clues. I can continue testing on this machine at some point again.

Once I'm back home, I'll try it on my Mac Mini as well, as you suggested. If I run into any issues on that machine, I'll create a separate issue for it.

Thanks again!

[crazii]

It seems the device enumeration is OK but crashed on removing the unsupported device, probably a coding bug. BTW USBDDOS doesn't need LH. instead it will have no memory fragments without LH. CWSDPMI could theoretically work, but I don't know whether all the DPMI functions needed are supported by CWSDPMI. not tested, may have problems.

[volkertb]

Hmmm... One thing I hadn't tried was to unplug all the non-HID USB devices before booting the image. I don't have access to that machine right now, but I do have access to my Mac Mini now again, so I'll try it on that, and I'll let you know what my findings are. Thanks.

[crazii]

You don't have to, but still you can try it. I've seen unsupported devices: Wireless(class 'ef')/Vendor specific(class 'ff') on my T540p too, it's on the board, and the video camera is attached to the USB hub too. Your recorded video shows a class 'ef'. Just wait a few until I finished the WC build, it's on the last stage.

[volkertb]

Thanks. And no need to rush. It's New Year's Eve over here. I don't know if you will be celebrating tonight (I believe Chinese New Year is a bit later, right?), but nevertheless I wish you all a Happy and Blessed New Year. :slightly_smiling_face:

[crazii]

Thanks and Happy new year! it's Jan/01/2024 here in the morning already. :)

[volkertb]

Unlike the Mac Mini 2011, where all the 4 physical USB ports are wired up to the EHCI controller only while having an unused UHCI controller in the chipset as well, this system apparently has three controllers (EHCI with an OHCI companion controller, as well as an xHCI controller on the PCIe bus), with all low-speed devices automatically routed to the OHCI controller, as you can see in the lsusb -t output that I shared above.

[crazii]

It seems the device enumeration is OK but crashed on removing the unsupported device, probably a coding bug. BTW USBDDOS doesn't need LH. instead it will have no memory fragments without LH. CWSDPMI could theoretically work, but I don't know whether all the DPMI functions needed are supported by CWSDPMI. not tested, may have problems.

Just tested with CWSDPMI on VirtualBox, and it works. Now I'm gonna debug USBDDOS on FreeDOS, as it will crash.

[volkertb]

Just tested with CWSDPMI on VirtualBox, and it works. Now I'm gonna debug USBDDOS on FreeDOS, as it will crash.

How does it work with CWSDPMI, when CWSDPMI does not have the port-trapping API that HDPMI32i has? Or will USBDDOS still work without the API, but for real-mode games only, using just Jemm+QPIEMU?

[crazii]

No, usbddos don't need any port-trapping. That is needed only for the Retrowave OPL driver.

[crazii]

I checked CWSDPMI again, it seems my previous conclusion is incorrect. CWSDPMI won't work because it pre-allocate all XMS for dpmi memory, but usbddosp needs free XMS to work, it simply fails on initialization. I'll check if there's any option for CWSDPMI to limit use of the XMS memory.

Did more test, CWSDPMI works on a clean FreeDOS on my T540p(16G RAM), but it fails on the FreeDOS liveCD with XMS allocation, on a VirtualBox VM with 512M RAM, but still it works on MSDOS on the same VM.

[volkertb]

Oh wait. That sounds similar to a few issues I had with some protected mode games that wouldn't run until I limited the amount of memory that was allocated by Jemm or HimemX. That's why I added the parameter MAXEXT=2097152 to JEMMEX in scripts/build-release-artifacts.sh in the SBEMU project.

Maybe that's related to this? If you reduce the amount of XMS being allocated, and CWSDPMI pre-allocates all of that, then all the free memory above 1MB that was not assigned to XMS should still be available to USBDDOS, since it runs in protected mode, right?

[crazii]

Maybe. USBDDOS always uses xms allocation without checking the available size, it might work if jemm only "report" limited memory but still succeeding in allocation when total request exceeds that limit. This depends on the jemm implementation, since the games just cannot handle that large number of free xms, I believe jemm only limit the reported size but will give more than the limited size if requested.

But, it is not related to the CWSDPMI issue, I didn't use limit on the MS-DOS config with jemmex but it still works, same for the FreeDOS config on the T540p. The FreeDOS live CD uses himemex. It might be related to the returned address, which is too high since there's already many program loaded in the ramdisk.