What you're saying makes sense. Maybe running PCIset before Windows boots is an option.

But first, what about some benchmarks to compare hard drive performance with a different machine with (known to be working) UDMA? Are you using a Compact Flash adapter? I have a few and some don't support DMA (Windows 98 -> Device Manager -> Disk properties -> Configuration). Did you enable that option?

tauro wrote on 2024-01-03, 18:51:

What you're saying makes sense. Maybe running PCIset before Windows boots is an option.

But first, what about some benchmarks to compare hard drive performance with a different machine with (known to be working) UDMA? Are you using a Compact Flash adapter? I have a few and some don't support DMA (Windows 98 -> Device Manager -> Disk properties -> Configuration). Did you enable that option?

I don't have another machine right now with a 44 pin IDE header that I can test with. I am using an IDE to SD card adapter with it and it claims to support UDMA ATA-33. I am using WinXP Fundamentals for Legacy PCs on this thin client and in device manager it says my primary IDE channel device 0 is using multi word DMA mode 2.

I tried using WPCREDIT and if I change offset 31 from bit 0 to bit 1, no problem. The text of the datasheet is:
Pri Drive 0 UltraDMA-Mode Enable Method
0 Enable by using “Set Feature” command..... def
1 Enable by setting bit-30 of this register

I assume this means if the bit is 0, then the option to enable it will be done through the BIOS so I changed it to 1 instead.

Then when I change offset 30 to bit 1, that should enable the UDMA mode but then the computer freezes. I am wondering if it freezes because such a setting should not be changed while the OS is running? Kinda worried if I use something like WPCRSET or PCISET, my computer would not even boot. Hmmm, what to do, what to do.

SD to IDE adapters can be a source of problems.

The ones I tried were not compatible with NTFS because of some hard coded limitation of the microcontroller, they would only work reliably with FAT32.

If I were you I'd get a regular IDE hard disk and see how well it performs.

Maybe the SD to IDE adapter is what's holding you back.

geiger9 wrote on 2024-01-03, 20:19:

Then when I change offset 30 to bit 1, that should enable the UDMA mode but then the computer freezes. I am wondering if it freezes because such a setting should not be changed while the OS is running? Kinda worried if I use something like WPCRSET or PCISET, my computer would not even boot. Hmmm, what to do, what to do.

If you're worried of losing files make a backup.

I'd try editing those raw values on DOS and then booting Windows 98 to confirm they work at all. If you prefer XP, then it's trickier, but you can use GRUB4DOS to chainload the desired disk/partition. I used this method in conjuction with SETMUL to overclock a VIA CPU and then boot XP.

tauro wrote on 2024-01-03, 21:27:

SD to IDE adapters can be a source of problems. […]
Show full quote

SD to IDE adapters can be a source of problems.

The ones I tried were not compatible with NTFS because of some hard coded limitation of the microcontroller, they would only work reliably with FAT32.

If I were you I'd get a regular IDE hard disk and see how well it performs.

Maybe the SD to IDE adapter is what's holding you back.

Nah I have used a few different compact flash adapters and a slew of different compact flash cards and all they all experienced the same bottleneck when I ran benchmarks. I do have a 44 pin 2.5 IDE drive from a laptop that I tried out of curiosity but it performed worse than the compact flash adapter. It would not have been a permanent solution anyway as this is a thin client. The solution has to be either a CF card or an SD card. Well, I suppose I MIGHT be able to get a SATA SSD in there and just tape the drive to the top of the chassis but to use a SATA drive in this thing would take a lot of foolin'.

I'm going to continue researching flipping these bits in the VT8231. It's not so much files I'm worried about. I'm worried that if I flip these bits permanently (WPCREDIT is just temporarily until you reset the machine) then my whole system will be borked and it won't boot.

Perhaps someone could save me a lot of time: Is this whole journey pointless? Can you even change such a register to enable UDMA while the OS is loaded? Is this the kind of setting that has to be set near or when the BIOS is loaded?

Also, take a look at these two pictures below. As you can see in WPCREDIT, offsets 0-3 match up fine but then in offset 4-5, there are some bits that should be fixed according to the datasheet but in WPCREDIT, they are the wrong value. In the picture, bit 7 is supposed to be fixed at 1 but my computer is showing 0. Bit 1 is supposed to be fixed at 0 but it's a 1. What is happening here?

Okay one last bump. Just need to document this in case anyone is in the same situation as I am. I don't think my post is THAT far back.

Thanks to some very knowledgeable and kind people on The Retro Web discord server, it would seem that changing the values for these registers while the OS is loaded is too late. It must be done earlier in the boot process.

Also it has been determined that is not simply a matter of using MODBIN to show some hidden menus. The menu settings to enable UDMA just aren't coded into the BIOS. This quoted text here is the final conclusion of one of the users:

in these cases you have to hack that feature back in with custom assembly code. So there's no easy option. well, adding a missin […]
Show full quote

in these cases you have to hack that feature back in with custom assembly code. So there's no easy option.
well, adding a missing item back in is almost impossible. I got limited knowledge of ASM and tried that for like 3 years.
the main problem is that the system.bin doesn't have any room near the items, so there's simply no space to add something back in.
however some award bios got 5 "leftover" items which one can put to good use. that's the way i did it till now
i stored my custom code as ISA or PCI option rom (think of it as a module which for example contains the ROM of some onboard controller). that code read the CMOS and that way i knew which value the "new" item was set to.
however, that option rom is executes after POST, right before OS boot. so that may be too late to change UDMA values.
i've not tried to sneak code into the early boot process yet.

I'm latching on to the part where he says some BIOS have "leftover" items. Perhaps this is the case with mine?

Below is a screenshot of some info on my BIOS that MODBIN displays:

I don't suppose there's anyone here with knowledge of how to write custom assembly language and inject that back into the BIOS? Bear in mind, I have zero idea how long of a process that is. If this is like a month like learning process and coding procedure then I don't expect anyone to jump in and do it for me.

I have tried to sign up for bios-mods.com because on the forum there is a section there with requests such as mine but after 72 hours and after using the activation email, my account is still not validated. Anyone familiar with that site and know what could be going on?

tauro wrote on 2024-01-03, 21:27:

SD to IDE adapters can be a source of problems.

The ones I tried were not compatible with NTFS because of some hard coded limitation of the microcontroller, they would only work reliably with FAT32.

Do you remember what SD to IDE adapters you used?

My experience is that the vast majority of the SD to IDE adapters on the market today all use the same FC1307A chip with the Sintechi firmware v1.2 or 1.3. They should work with NTFS.

However if you are using a system that would benefit from NTFS, you might be better off looking for a Sata bases storage solution instead of using an SD to IDE solution.

douglar wrote on 2024-01-12, 20:41:

Do you remember what SD to IDE adapters you used? […]
Show full quote

tauro wrote on 2024-01-03, 21:27:

SD to IDE adapters can be a source of problems.

The ones I tried were not compatible with NTFS because of some hard coded limitation of the microcontroller, they would only work reliably with FAT32.

Do you remember what SD to IDE adapters you used?

My experience is that the vast majority of the SD to IDE adapters on the market today all use the same FC1307A chip with the Sintechi firmware v1.2 or 1.3. They should work with NTFS.

However if you are using a system that would benefit from NTFS, you might be better off looking for a Sata bases storage solution instead of using an SD to IDE solution.

Yes, I have a few of those "SD35VC0". I'm not sure what's the firmware version or the exact chip (covered by the QC PASS sticker), but it's likely the same.
This guy explains the problems I faced.
Long story short there's a bug in the firmware that corrupts your disk (SD) partition table if you're using other than a FAT32 partition.
The easy solution is to create a dummy FAT32 partition at the beginning, and then create your NTFS, EXT4, etc, partitions after that one.