Open volkertb opened 8 months ago
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.
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
As I mentioned here, the same problem occurred when I tried to load USBDDOS
without having SBEMU
loaded.
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
.
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.
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!
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.
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.
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.
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:
Thanks and Happy new year! it's Jan/01/2024 here in the morning already. :)
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.
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.
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?
No, usbddos don't need any port-trapping. That is needed only for the Retrowave OPL driver.
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.
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?
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.
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
:Output of
lspci
:Originally posted by @volkertb in https://github.com/crazii/USBDDOS/issues/5#issuecomment-1872052804