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.