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 Yesterday, 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 Yesterday, 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 Today, 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 Today, 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 Today, 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 Today, 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 Today, 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 Today, 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 Today, 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 Today, 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 Today, 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 Today, 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 Today, 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 Today, 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 Today, 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 Today, 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 55 minutes ago:

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 43 minutes ago:

crazii wrote on 55 minutes ago:

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 🤣