Might be a BIOS ROM that's starting to lose its bits? But then I think XT IDE should bypass it... Maybe some cap is failing?

With things like corruption I’d probably look for faulty memory or the check the speed at which the isa bus is running.

what a nice board....

Vendest wrote on 2025-02-10, 13:28:

Going back the 386 system.
I installed XTIDE on a NIC to bypass the bios, it worked for couple of days then same issue again.
XTIDE would report corrupted C drive information.

The problem is that there are many revisions of XUB.
Here's an old one with the old LBA algorithm that worked fine for me.
Re: IDE disk-on-module + 386

Edit: If it's a hardware problem, maybe it helps checking caps and reduce ISA bus frequency (or add waitstates).
Also, sometimes diodes can become faulty, too. Checking them might be recommended, too.

Just spotted a mention about CF adapters and grounding the ALE signal causing I/O probs in this thread Trident VGA card prevent boot devices from being recognized might be something to look into

Are you using Fdisk on an MSDOS 6.22 system?

The only way I can get a drive to work is by doing that, plus a "format c: /q /s". /s puts on system files (a command.com).

If that doesn't work there must be some hardware fault.

Another thing to consider is longevity of flash storage, when treated like a 512b/sector ata device.

This is especially true of media that is qlc instead of slc, which is basically 'all commodity flash'.

I'd go so far as to suggest that XUB should detect for CF and SDcard devices, and assume 4mb alignment by default for them, in regard to how int13 should cache and commit writes, but the makers of xtide may disagree, for compatibility reasons.

Preface:

CF and SDcard devices have a very small internal sram cache, and a hardware level 'erase block size', which is specific to each CF or SDcard. The first 'erase block' of these media tends to have better write life than the rest of the medium, because this is where the FAT gets stored, which is frequently updated. Even still, the actual erase block size tends to be around 4mb in size in contemporary flash devices, so if your partition structure is NOT aligned to this, you will be prematurely wearing this special bit of the flash media with amplified writes.

Basically, the flash media has to internally read the entire erase block into its internal sram cache, incorporate your tiny 1 sector write, erase the entire erase block, then re-write the whole thing, every time old-school single sector transfer modes are used.

The XUB could, in theory, reduce this stress by caching and dispatching writes in 'friendlier' chunks, but this would be different from the behavior needed/expected for spinning rust.

There is a great deal of black magic voodoo involved in setting up an *ideal* FAT volume on a flash based device, which dos' FDISK does not give control over. Sadly, DOS is also a picky primadonna about 3rd party partitioning and formatting, more often than not.

The 'industry compromise', was to put the partition table and boot block in this special 'heavy duty' bit of disk, usually the first 4mb, then start the first partition at 4097kb location. (JUST after this block ends)

DOS does not create partitions this way, and typically puts the first partition at the very start of the disk, just after the boot block. This is because spinning rust aligns at 512 BYTE boundaries, and NOT the 4096 KiloByte boundaries found on most contemporary flash devices.

'Device suddenly not bootable' and 'suddenly wont retain new partitions!', when applied to flash devices, usually matches up with the poor thing having the entire boot block, partition table, and other goodies CONSTANTLY erased and re-written, when the FAT gets updated, because of how flash actually works under the hood.

Again, I feel having XUB detect flash media, and dispatch writes in more sensible bursts would be an obvious mitigation, but keeping the 1st partition aligned with 4mb is a golden rule as well.

Another, is to select a larger FAT cluster size. THIS is the *real* reason the SDCard assn wants you to use ExFAT. It allows for cluster sizes as big as 4mb, or larger, which forces the OS to dispatch medium friendly writes. FAT16 does not like clusters larger than 16k, if memory serves. Windows also, hates large clusters on the boot volume. (It presumes spinning rust, after all)

Just be mindful of these things, and do the best you can to accomodate these needs when putting flash in a legacy system.

😁

Vendest wrote on 2025-02-10, 13:28:

I tried few other things, swapping the PSU with a known good PSU, reducing amount of RAM to 4MB, limiting cache size from 128kb to 32kb, enabled/disabled FPU... nothing seemed to help.

I must also state that both A: and B: floppy disk drives work well. Read/write without issues.

IDE on these mobos is pretty much tied to ISA for the most part so any issues with the ISA bus could cause the problems you have. Overclocking as well, obviously so if you are not doing it on purpose make sure your ISA clock divider is set properly in BIOS.

Some of the 74 series chips that drive ISA lines could be dying, that won't show up on any usual tests and glitches might be rare enough that you wouldn't spot them on the frequently refreshed screen during game but IDE writes are a bit more permanent.

Or it could be some old DOS virus, these things were quite often destructive (though rarely on purpose) so make sure it's not happening after you run a particular program or a game. Maybe scan all the executables with some AV, you might need an older version that can deal with DOS better than new tools.

Thanks a lot for the information, giving me some hints.
Most chips including the bios are not socketed which makes it difficult to check the 74s and bios. Will get some tools to remove the chips if needed.
Referring to a possible issue with the Trident VGA card, I tried with another graphics card Realtek RTG3106 but that did not improve the situation.
I was however able to measure the clock speed of the ISA bus on B20 pin and read a solid 10MHz, oscillating up to 10.04MHz and 10.08MHz punctually.
It is puzzling considering the user manual mentions "Bus I/O Clock 8MHz for maximum compatibility with add on cards"
Will continue checking based on previous comments.

Vendest wrote on 2025-02-12, 11:06:

I was however able to measure the clock speed of the ISA bus on B20 pin and read a solid 10MHz, oscillating up to 10.04MHz and 10.08MHz punctually.
It is puzzling considering the user manual mentions "Bus I/O Clock 8MHz for maximum compatibility with add on cards"

Based on photos from TRW your mobo looks more like Biostar MB-1333UCG than UCQ. I think the clock generator is one of the things that changed between the two. According to the jumper manual at https://theretroweb.com/motherboard/manual/31865.pdf that mobo can do 66MHz or 80MHz. 386 divides the clock by two so that gives you 33 or 40MHz options. If the ISA clock divider is permanently set to 8 then it would result in 8.25MHz for 66 and 10MHz for 80 - and that perhaps explains the 10 you get? So my next move would be to close JP17 to reduce the CPU clock to 66 and see if that also affects the ISA. And if it does, will it work now and be stable.

That really was a helpful insight, thanks.
I found something interesting while checking the clock speed.

JP17 closed - CPU speed 33MHz - clock divider set to 4 in bios - I get 8.33MHz on the ISA bus vs calculated 8.25MHz.
JP17 open - CPU speed 40MHz - clock divider set to 5 in bios - I get 10MHz vs. calculated 8MHz.
This is where it gets strange with CPU speed set to 40MHz:
- During POST memory count, I read a stable 8MHz
- During POST right after the memory count (when it checks for drives), the clock signal changes to 10MHz.
It only happens when the CPU is set to 40MHz. (default settings)
Out of curiosity I checked with clock divider set to 6, I read stable signal 6.7MHz till after POST.

I removed the Cyrix 487 to confirm the readings and therefore was able to rule out any issues with it.

The IDE still does not work with JP17 closed, but I think there is a more serious issue with the clock signal.

That looks like a BIOS bug. Or perhaps somebody was trying to improve performance this way (and sales).
The difference between 8.25 and 8.33 is a minor one. This mobo seems to be using a clock chip that generates required frequency from a single crystal resonator, probably via a PLL. Unlike dedicated generators that are exactly 66 or 80 MHz, this approach might be producing something close but not exact. If the 66 was actually 66.6(6) then you'd get the 8.33 as a result. It also provides a very small "overclock" since any 33MHz rated 386 will accept the CLK2 being just 1MHz higher with no issues.

If your IDE controller still isn’t working at 8.33mhz then your corruption issues probably aren’t related to that.