OK, it seems that it reads VBR correctly as it displays correct volume label and at least one dir entry. As I cannot open mapped disk with a disk editor I can't see closer. Some debug prints could help. I was able to recompile sources so I could try something when have a time.
It's weird, I guess that dos reads the rootdir sector by sector and if usbddos would read the sector correctly dos should diplay at least 16 dir entries not only the one. I don't know what all sector dos tries to read when just executing dir x: command. I would need to trap what sectors are requested and then compare their content if reads what is expected. Maybe writting all this to a file in some usbddos read sector function - requested CHS and sector content...

RayeR wrote on 2026-06-15, 21:36:

OK, it seems that it reads VBR correctly as it displays correct volume label and at least one dir entry. As I cannot open mapped disk with a disk editor I can't see closer. Some debug prints could help. I was able to recompile sources so I could try something when have a time.
It's weird, I guess that dos reads the rootdir sector by sector and if usbddos would read the sector correctly dos should diplay at least 16 dir entries not only the one. I don't know what all sector dos tries to read when just executing dir x: command. I would need to trap what sectors are requested and then compare their content if reads what is expected. Maybe writting all this to a file in some usbddos read sector function - requested CHS and sector content...

There is a sector offset point to the beginning sector of the partition, it could be the offset is incorrect.

It seems MTRRLFBE reads some un-owned memory and then used them as LDT descriptors, base/limit etc to create new selectors. it runs OK without parameters. with "info" it won't work.
Is there any code reading win9x host memories like LDT tables? I'm not sure it's currently going the win9x path or not. I removed the windows installation check (fake win9x env) to ensure a pure DOS environment, still the same.

RayeR wrote on 2026-06-15, 13:24:

I'm not sitting at my home PC now but it may be a code setting up a callgate to execute rdmsr/wrmsr in ring 0. I implemented this hack to work also under v86 mode (emm, win9x too).

That explains a lot. BTW I've added rdmsr/wrmsr handling when exception occurs, the instruction is done in ring0 and return (not supposed to do so, it's unsafe). Maybe dmsr/wrmsr can be executed directly on detection vpdmi. detection vdpmi is something like detection emm386, with an extra signature.

Maybe some mismatch of CHS geometry? Maybe it tries to read flashdisk with different CHS than it was formatted. I usually format the disk under DOS with enabled USB legacy support of my BIOS...

I went through the code of mtrrlfbe:
when it just runs without params it does nothing interestinig. Once MTRR is requested to set then I call vesa_mtrr_set_mode() that calls grhlp_setup_ring0_callgate() that calls __dpmi_allocate_ldt_descriptors(1) it maps GDT to LDT deskriptor with DPL=3, next another __dpmi_allocate_ldt_descriptors(1) to alloc another LDT deskriptor nex another one __dpmi_allocate_ldt_descriptors(1) fo CS alias nex another one __dpmi_allocate_ldt_descriptors(1) fo callgate, setting up calggatte deskriptor and finally put_descriptor(ldt_selector, callgate_selector, &callgate_descriptor) to set CallGate deskriptor to LDT
when program exits it frees all:
__dpmi_free_ldt_descriptor(callgate_selector); // deskriptor CallGate
__dpmi_free_ldt_descriptor(cs_alias_selector); //deskriptor CS alias
__dpmi_free_ldt_descriptor(ldt_selector); // deskriptor LDT
__dpmi_free_ldt_descriptor(gdt_selector); // deskriptor GDT
Some VM86 mons can accept priveleged instructions and some don't so I did this universal solution. Unil VDPMI appeared it run under every VM86 mon I tried and I though it's bullet proof enough unil GDT remains writtable - not a case of Windows NT-based...

EDIT: I added some debug prints to USB_MSC_DOS_InstallDevice() and USB_MSC_ReadSector() but I can see only read sectors call at init phase not TSR (when DIR command is called), maybe I need to modify other place...

Anyway parsing of MBR and VBR seems to be OK:

1MBR CHS: 2/255/63, partition start CHS: 0/32/33, LBA 2048
2VBR HS: 255/63, 4 sectors per cluster, 8 reserved, 2048 hidden, 512 root entries (32 sect.)
3root dir start at LBA: 2176
4entry #0 - volume label "MR_SD32MB"
5entry #1 - LOCALE
6entry #2 - COMMAND.COM
7...
8
9H:\USBDDOS.SRC\MAKE\OUTPUT>usbddosp.exe /disk
10No driver found at port: 5 for device (class 0b/00/00 smartcard), skip
11MSC_ReadSector: dev=291ac, sect=0, cnt=1
12partition 0 - LBA start: 2048
13FAT partition found (type: 14)
14MSC_ReadSector: dev=291ac, sect=2048, cnt=1
15Sector per FAT: 60, 60, FATs: 2 - OK
16Sector per cluster: 4 - OK
17Reserved sectors: 8 - OK
18RootDirCluster7.0+: 414e204fh - bad
19Label7.0+: ¸àŽÀ‰î‰ï¹ - bad
20Label4.0: MR_SD32MB  - OK
21Serial7.0+: 7c00bdd8 - bad
22Serial4.0: ac8edda8 - OK
23VBRSector: 2048 - OK
24RootDirs: 512 - OK
25USB Disk 'Generic Mass Storage Device' mounted as drive N:.
26
27C:\>dir n:
28
29 Volume in drive N is MR_SD32MB
30 Directory of N:\
31
32LOCALE	     <DIR>	   01-04-14   4:56p
33	1 file(s)	       0 bytes
34		      10,618,880 bytes free

RayeR wrote on 2026-06-16, 00:52:

I went through the code of mtrrlfbe:
when it just runs without params it does nothing interestinig. Once MTRR is requested to set then I call vesa_mtrr_set_mode() that calls grhlp_setup_ring0_callgate() that calls __dpmi_allocate_ldt_descriptors(1) it maps GDT to LDT deskriptor with DPL=3, next another __dpmi_allocate_ldt_descriptors(1) to alloc another LDT deskriptor nex another one __dpmi_allocate_ldt_descriptors(1) fo CS alias nex another one __dpmi_allocate_ldt_descriptors(1) fo callgate,

Very interesting indeed, 😁. I put some log and indeed it's reading the content of GDT, by creating a descriptor pointed to the linear address of core GDT, the 112 bytes is the size of GDT (probably it have gotten the linear address & limit through SGDT). however that memory is not readable nor even writable by clients. To provide better protection and avoid crashes due to bugs, some memory are not even directly writable by core itself, it has to alt the page-table before any writes. 🤣

I ran MTRRLFBE in win98se and it's OK, but for only once there was a freeze with tiny artifacts on screen when exit command.com from full screen mode, I have to hard reset the machine. but its probably related to mode switch and graphics driver bugs.

RayeR wrote on 2026-06-16, 00:52:

EDIT: I added some debug prints to USB_MSC_DOS_InstallDevice() and USB_MSC_ReadSector() but I can see only read sectors call at init phase not TSR (when DIR command is called), maybe I need to modify other place...

Yes, there seems no sector reads on "dir", do you have any cache driver installed? SMARTDRV or something?

RayeR wrote on 2026-06-16, 00:52:

[…]
Show full quote

Copy code to clipboard

1Sector per FAT: 60, 60, FATs: 2 - OK

FATs: 2, what is it, is that total FATs? If yes, then it is incorrect and prevent DOS reading more FATs or sectors.

UPDATE:

SBEMU changes:
1.improve SFX/OPL mixing.
2.eanble IF on updating sound buffer. (VIF cannot be simply enabled, will be improved later)

VDPMI changes:
1.support v86 program reading cr0
2.fix int67h crash
3.fix DPMI function 0503: memory resize bug. (1+2+3) makes stargunner runs.
4.Ctrl+Alt+Del fix: jump to BIOS reset entry directly, instead of return to BIOS keyboard handler. keyboard handler behaves differently on handling warmboot, it is OK on my PCs but reportedly not working for others, now reported working.
5.bugfix on memory range overlap check
6. fix VIF/VIP state bugs, this increase stability.
7.add RDMSR/WRMSR support for DPMI clients, now FastVid set MTRR properly without crash.
8.add MTRR check on DPMI function 0508: Map Device in Memory Block, function 0800: Physical Address Mapping.
the DPMI spec requires those functions to disable page cache. VDPMI will read the MTRR registers and if the address has write combine enabled, page cache won't be disabled, to make write combine working.
9. add readme: VDPMI.txt

the updated binary is put on github:
https://github.com/crazii/SBEMU/releases/tag/ … pmi_pre_release

crazii wrote on 2026-06-16, 12:41:

UPDATE: […]
Show full quote

UPDATE:

SBEMU changes:
1.improve SFX/OPL mixing.
2.eanble IF on updating sound buffer. (VIF cannot be simply enabled, will be improved later)

VDPMI changes:
1.support v86 program reading cr0
2.fix int67h crash
3.fix DPMI function 0503: memory resize bug. (1+2+3) makes stargunner runs.
4.Ctrl+Alt+Del fix: jump to BIOS reset entry directly, instead of return to BIOS keyboard handler. keyboard handler behaves differently on handling warmboot, it is OK on my PCs but reportedly not working for others, now reported working.
5.bugfix on memory range overlap check
6. fix VIF/VIP state bugs, this increase stability.
7.add RDMSR/WRMSR support for DPMI clients, now FastVid set MTRR properly without crash.
8.add MTRR check on DPMI function 0508: Map Device in Memory Block, function 0800: Physical Address Mapping.
the DPMI spec requires those functions to disable page cache. VDPMI will read the MTRR registers and if the address has write combine enabled, page cache won't be disabled, to make write combine working.
9. add readme: VDPMI.txt

the updated binary is put on github:
https://github.com/crazii/SBEMU/releases/tag/ … pmi_pre_release

Did some tests with the updated VDPMI.
- Stargunner now works with proper sound.
- Tyrian 2000 works correctly with /PVI=0 (keyboard is now responsive).
- Jazz Jackrabbit works fine. I think it never had any issue with VDPMI, though I only just tested it.

I think it's DOS4GW not playing well with VDPMI. So far games that don't have sound (and will break sound in other protected mode games) all utilized DOS4GW.

crazii wrote on 2026-06-16, 06:03:

Very interesting indeed, 😁. I put some log and indeed it's reading the content of GDT, by creating a descriptor pointed to the linear address of core GDT, the 112 bytes is the size of GDT (probably it have gotten the linear address & limit through SGDT). however that memory is not readable nor even writable by clients. To provide better protection and avoid crashes due to bugs, some memory are not even directly writable by core itself, it has to alt the page-table before any writes. 🤣

"however that memory is not readable nor even writable by clients" - you mean esp. under VDPMI?
I'm not sure if general protecting GDT under DOS is good idea. I think that in good old DOS times it was allowed to write anywhere and surely there are more DOS apps that do similar tricks. E.g. I saw that CPUSPD utility also installs a callgate...

crazii wrote on 2026-06-16, 06:03:

Yes, there seems no sector reads on "dir", do you have any cache driver installed? SMARTDRV or something?

I use Jack's UIDE caching driver loaded in config.sys so I guess it doesn't know anything about mapped USB disks that was loaded far later. Even there must be seen the sectors read first to fill the cache. It's evident that it readed some sector belongs to rootdir as it displayed the directory named "LOCALE" but I couldn't trap this read so I asked if there's some another code for TSR part that do also sector reading that I missed.

crazii wrote on 2026-06-16, 06:03:

FATs: 2, what is it, is that total FATs? If yes, then it is incorrect and prevent DOS reading more FATs or sectors.

Yes there are usually 2 FATs - primary and backup copy followed one by one. As I saw 99.9% of DOS formatted disks use 2 FAT copies so I don't see anything wrong with that...

LSS10999 wrote on 2026-06-16, 14:49:

I think it's DOS4GW not playing well with VDPMI. So far games that don't have sound (and will break sound in other protected mode games) all utilized DOS4GW.

I haven't test VDPMI with real SB card yet, I think this problem will be fixed.

RayeR wrote on 2026-06-16, 15:38:

"however that memory is not readable nor even writable by clients" - you mean esp. under VDPMI?
I'm not sure if general protecting GDT under DOS is good idea. I think that in good old DOS times it was allowed to write anywhere and surely there are more DOS apps that do similar tricks. E.g. I saw that CPUSPD utility also installs a callgate...

Yes. under VDPMI. I'm not sure either. I tend to fix the exceptions by simulate the behavior than to give open access to GDT, as a "hard fix" for specific programs.

RayeR wrote on 2026-06-16, 15:38:

I use Jack's UIDE caching driver loaded in config.sys so I guess it doesn't know anything about mapped USB disks that was loaded far later. Even there must be seen the sectors read first to fill the cache. It's evident that it readed some sector belongs to rootdir as it displayed the directory named "LOCALE" but I couldn't trap this read so I asked if there's some another code for TSR part that do also sector reading that I missed.

No, there is only one piece of code that reads a sector. maybe the initial reads partially read the root entries too?

crazii wrote on 2026-06-16, 16:13:

Yes. under VDPMI. I'm not sure either. I tend to fix the exceptions by simulate the behavior than to give open access to GDT, as a "hard fix" for specific programs.

I probably can modify MTRRLFBE and my other tools to detect VDPMI and behave differently under it but I guess there are other programs that are abandoned and nobody would recompile them.
I guess that various DOS extenders are also one that may have need to manipulate GDT, maybe some obscure DOS demos/intros hacking unreal mode and similar... at least I would add some commandline switch that enables/disables GDT protection to debug such cases...

crazii wrote on 2026-06-16, 16:13:

No, there is only one piece of code that reads a sector. maybe the initial reads partially read the root entries too?

I added a printf at the 1st line of USB_MSC_ReadSector and got only this 2 reads that I posted above:
MSC_ReadSector: dev=291ac, sect=0, cnt=1
MSC_ReadSector: dev=291ac, sect=2048, cnt=1

But maybe if printf doesn't work in TSR mode for some reason?

RayeR wrote on 2026-06-16, 16:31:

I probably can modify MTRRLFBE and my other tools to detect VDPMI and behave differently under it but I guess there are other programs that are abandoned and nobody would recompile them.
I guess that various DOS extenders are also one that may have need to manipulate GDT, maybe some obscure DOS demos/intros hacking unreal mode and similar... at least I would add some commandline switch that enables/disables GDT protection to debug such cases...

Yes. I read the source code of SoftMPU years ago and it will hack EMM386 too. There're probably pretty more.

RayeR wrote on 2026-06-16, 16:31:

I added a printf at the 1st line of USB_MSC_ReadSector and got only this 2 reads that I posted above: MSC_ReadSector: dev=291ac, […]
Show full quote

I added a printf at the 1st line of USB_MSC_ReadSector and got only this 2 reads that I posted above:
MSC_ReadSector: dev=291ac, sect=0, cnt=1
MSC_ReadSector: dev=291ac, sect=2048, cnt=1

But maybe if printf doesn't work in TSR mode for some reason?

I assume you used serial terminal because you said about it earlier. generally it is not always safe to do printf in TSRs. but cprintf "\n\r" could be better.

crazii wrote on 2026-06-16, 16:46:

I assume you used serial terminal because it said about it earlier. generally it is not always safe to do printf in TSRs. but cprintf "\n\r" could be better.

OK, I can change it to serial output if it's better for TSR. What's the name of serial print function?
BTW when I logged with the precompiled debug version via serial terminal there was not any debug outputs after TSR loaded when I exec DIR command but probably there was not such debug prints in code...

RayeR wrote on 2026-06-16, 16:58:

crazii wrote on 2026-06-16, 16:46:

I assume you used serial terminal because it said about it earlier. generally it is not always safe to do printf in TSRs. but cprintf "\n\r" could be better.

OK, I can change it to serial output if it's better for TSR. What's the name of serial print function?
BTW when I logged with the precompiled debug version via serial terminal there was not any debug outputs after TSR loaded when I exec DIR command but probably there was not such debug prints in code...

I've no idea yet, those changes are from downstream fork, sorry 🤣

I checked the USBDDOS source just now, the downstream fork just turned on a switch "#if 0" to "#if 1" to output COM. It's in dbgutil.c: DBG_Logv().
Sorry it was too late last night that I didn't check the source.

I enabled serial debugging in makefile and added DBG_Log() at 1st line of USB_MSC_ReadSector() but I still cannot see any more sectors read on terminal, it's really strange - the TSR part must disable debugging some way or go different code path or TSR is not runing and DOS just reads some residual data from memory...

static BOOL USB_MSC_ReadSector(USB_Device* pDevice, uint32_t sector, uint16_t count, void* buf, size_t size)
{
DBG_Log("MSC_ReadSector: dev=%p, sect=%lu, cnt=%u\n", pDevice, sector, count); // rayer
printf("MSC_ReadSector: dev=%p, sect=%lu, cnt=%u\n", pDevice, sector, count); // rayer
if(pDevice == NULL)

Last serial terminal lines after DIR command:
USB: set config 1
EHCI remove default control pipe
USB Removing HCD device
HUB port 5 resetting
HUB port 5 reset 503
USB Free device buffers
USB Free device configs
USB Free endpoints
MSC_ReadSector: dev=2f5bc, sect=0, cnt=1
MSC_ReadSector: dev=2f5bc, sect=2048, cnt=1
Drive Count: 26, Device Count: 11
memory: 001d5000, 00111000
memory: 001e5000, 00111000
Free stub memory 00111000, addr: 00000000 size: 001d0000
Transfer buffer: 00009ca0, PSP: 00009ba0, transfer buffer size: 00004000
TSR size: 256

RayeR wrote on Yesterday, 12:31:

Last serial terminal lines after DIR command: USB: set config 1 EHCI remove default control pipe USB Removing HCD device HUB por […]
Show full quote

Last serial terminal lines after DIR command:
USB: set config 1
EHCI remove default control pipe
USB Removing HCD device
HUB port 5 resetting
HUB port 5 reset 503
USB Free device buffers
USB Free device configs
USB Free endpoints
MSC_ReadSector: dev=2f5bc, sect=0, cnt=1
MSC_ReadSector: dev=2f5bc, sect=2048, cnt=1
Drive Count: 26, Device Count: 11
memory: 001d5000, 00111000
memory: 001e5000, 00111000
Free stub memory 00111000, addr: 00000000 size: 001d0000
Transfer buffer: 00009ca0, PSP: 00009ba0, transfer buffer size: 00004000
TSR size: 256

I'm quite sure those messages are init messages, "Free stub nemory ... TSR size: 256" should be the last messages right before going to TSR.
You can try add com output in driverint (or a similar name), which is the entry code of the DOS driver doing IO request from DOS.

Edit: checked the source, it's called USB_MSC_DOS_DriverINT().

OK I tried put prints to USB_MSC_DOS_DriverINT - it cause TSR crash so only DBG_Log() can be used. On DIR command I can see a lot of calls like this:
USB_MSC_DOS_DriverINT found dev: 2f7bc
MSC DR 4 USB_MSC_DOS_DriverINT cmd: 4
USB_MSC_DOS_DriverINT read

(about 56 reads) and at beginning some

MSC DR 1 USB_MSC_DOS_DriverINT cmd: 1
USB_MSC_DOS_DriverINT mediachk

So it's requested to read from DOS.

Function USB_MSC_ReadSector() is called only from USB_MSC_DOS_InstallDevice() not the TSR handler (as I see in source code) it muste be readed/called different way from TSR part. I need to find it and put more debugs there to see what is read from USB...