Oh, sorry.
I thought that i clarified already that i don't use DOS installers for drivers and such.
Just edit config.sys by hand. That's why i don't have such lines in Windows' system.ini

So you put device=c:\um8673.sys into the config.sys, but what file do you edit to set the speed, e.g. Speed 16, 17, etc ? I assume those speeds are MByte/s values?

A command line argument on the same line.
Something like /d0:17.
Not around the rigged contraption atm, but that is covered in the readme.txt from the driver archive.

OK, thanks. I'll check the readme.

I did a bit more testing with the onboard IDE port on the Biostar board. As it turns out, it is detecting my 32 GB Sandisk card properly. The "P014" it reports for the size is truncated. I guess they only left space for 4 digits. "P014" = "32014" megabytes. I'm still confused as to when a software is referring to a megabyte or a mebibyte. It seems like 1,048,576 bytes used to be called a megabyte, but then it was changed to a "mebibyte" 1999, however I don't think this naming convention popularised until much later. Thus I was expecting the size to be CF card size to be 30,529.8 MByte rather than 32,014 MByte.

Nonetheless, Win95c doesn't boot from my CF card when attached to the MB's IDE port. W95 boots when connected to the Promise Ultra100 controller. What could be causing this? I suspect it is because the W95 partition is outside of the 8 GB boundary. I am able to boot into NT4 on my 32 GB CF card when its attached to the MB's IDE port. While in NT4, I used the "dd" command to create another boot sector of my W95 partition, but I still could not boot to the W95 partition via NT's boot loader. Disk I/O error.

I got to thinking there must be some slight differences in how the MB vs. the Promise are reading the partition scheme. I decided to take my 120 GB Maxtor HDD (of which the the 32 GB CF card is a clone of), connect it to the Promise card, connect the CF card to the MB's IDE port, then run Norton Ghost. Perhaps if I have the CF card connected to the MB's IDE port at the time of the clone, things will just work out. I boot up Norton via the floppy disk and Norton, unfortunately, sees my CF card as only 8024 MByte. As this number is smaller than the data size on the Maxtor, it cannot clone.

pshipkov wrote on 2021-06-26, 16:50:

maxtherabbit wrote on 2021-06-26, 15:02:

The SiS 496 IDE driver did the same, however they work on Windows 95 and 98. Obviously not NT compatible

I never had to do SIS 96# drivers so far.
Do you see any advantage there ?

No, in fact they were slower than the default Windows 95 IDE driver 🤣

They were intended for use with Windows 3.1. Here yall go if you want to try them out

Finally getting somewhere with I/O speed on this thing! I was able to install a Promise SATA-150 PCI adapter and hook up a old 120GB SSD.

feipoa wrote on 2021-06-27, 12:23:

Nonetheless, Win95c doesn't boot from my CF card when attached to the MB's IDE port. W95 boots when connected to the Promise Ultra100 controller.

I'm having a bizarre issue where the PS/2 mouse doesn't work in DOS when booting from the Promise card. When booting from the onboard IDE (with the Promise card and its drive still in the system) the mouse works fine. I wonder if this is a BIOS incompatibility? Or perhaps a bug in cute mouse?

feipoa wrote on 2021-06-27, 12:23:

I did a bit more testing with the onboard IDE port on the Biostar board. As it turns out, it is detecting my 32 GB Sandisk card properly. The "P014" it reports for the size is truncated. I guess they only left space for 4 digits. "P014" = "32014" megabytes. I'm still confused as to when a software is referring to a megabyte or a mebibyte. It seems like 1,048,576 bytes used to be called a megabyte, but then it was changed to a "mebibyte" 1999, however I don't think this naming convention popularised until much later. Thus I was expecting the size to be CF card size to be 30,529.8 MByte rather than 32,014 MByte.

Ah, of course, large volumes are often displayed incorrectly in these old BIOSes and programs, because of limited screen space. I don't pay much attention to glitches like this as long as things are functional and as expected.
I don't remember ever hearing the word "*ebibyte" but simply put: one side (the storage device manufacturers) count in decimal numbers, where byte to kilobyte is 1*1000 and so on, while the other side (operating systems, programs, etc) operate in binary numbers where everything is based on 2^n. So byte to kilobyte is 1*1024 and so on. Anyhow.
So, depends on who displays what - we see discrepancy in size.

feipoa wrote on 2021-06-27, 12:23:

Nonetheless, Win95c doesn't boot from my CF card when attached to the MB's IDE port. W95 boots when connected to the Promise Ultra100 controller. What could be causing this? I suspect it is because the W95 partition is outside of the 8 GB boundary. I am able to boot into NT4 on my 32 GB CF card when its attached to the MB's IDE port. While in NT4, I used the "dd" command to create another boot sector of my W95 partition, but I still could not boot to the W95 partition via NT's boot loader. Disk I/O error.

The safety measure is to be mindful of the plethora of limitations with different class retro hardware and setup the partitions topology accordingly.
So here is my formula for MS operating systems:
512Mb FAT16 primary partition contains DOS, Win9x and NT4. This way everything is accessible from DOS and gives extra flexibility for hacking around. So if something bad happens on Windows levels i can quickly step down to DOS for repairs, etc. Now, this is based on habit from the old days and less of a problem today, since everything lives in CF card that can be quickly connected to modern day computers.
4Gb FAT32 for Win9x applications, games, etc.
4Gb NTFS partition for NT4 apps, swap
4Gb NTFS partition for data, backups, etc.

A variation of this that keeps 9x and NT4 separate:
512Mb for for DOS and Win95x, also NT4 boot loader.
1Gb NTFS for NT4, swap
4Gb FAT32 - win9x apps, games
4Gb NTFS - nt4 apps
4Gb NTFS - data, backup, etc.

This was usually accompanied (back then) by a second drive with linux and backups of the OS partitions.

Old programs and games were much more portable, so the separation between OS partitions and APPS/GAMES partitions was beneficial because it minimized the need for reinstallations.
While NT4 is resistant to bloat (if user is somewhat responsible), the Win9x deteriorates rather quickly in performance and stability upon fresh setup, so reinstalling the OS was a popular sport. Luckily both OSes can be quickly "reimaged" - setup things once, then copy the OS directories to another place. Then restoring to functional state was simply deleting the existing directories and copy the backups in their place.

feipoa wrote on 2021-06-27, 12:23:

I got to thinking there must be some slight differences in how the MB vs. the Promise are reading the partition scheme. I decided to take my 120 GB Maxtor HDD (of which the the 32 GB CF card is a clone of), connect it to the Promise card, connect the CF card to the MB's IDE port, then run Norton Ghost. Perhaps if I have the CF card connected to the MB's IDE port at the time of the clone, things will just work out. I boot up Norton via the floppy disk and Norton, unfortunately, sees my CF card as only 8024 MByte. As this number is smaller than the data size on the Maxtor, it cannot clone.

Maybe consider what i proposed above for partitioning.

@maxtherabbit
These are some fat numbers for 486 class rust.

Thanks for the slow drivers. 😉

PS2 mouse + Promise ultra133 or fasttrak controllers + Biostart UUD = works here, but i think you are on SiS 496 hardware, right ?

pshipkov wrote on 2021-06-27, 17:41:

@maxtherabbit These are some fat numbers for 486 class rust. […]
Show full quote

@maxtherabbit
These are some fat numbers for 486 class rust.

Thanks for the slow drivers. 😉

PS2 mouse + Promise ultra133 or fasttrak controllers + Biostart UUD = works here, but i think you are on SiS 496 hardware, right ?

Indeed. Are you using cute mouse driver?

feipoa wrote on 2021-06-27, 12:23:

OK, thanks. I'll check the readme.

I did a bit more testing with the onboard IDE port on the Biostar board. As it turns out, it is detecting my 32 GB Sandisk card properly. The "P014" it reports for the size is truncated. I guess they only left space for 4 digits. "P014" = "32014" megabytes. I'm still confused as to when a software is referring to a megabyte or a mebibyte. It seems like 1,048,576 bytes used to be called a megabyte, but then it was changed to a "mebibyte" 1999, however I don't think this naming convention popularised until much later. Thus I was expecting the size to be CF card size to be 30,529.8 MByte rather than 32,014 MByte.

I did my Computer Science degree in the mid to late 1990's and it was always 1024 kilobytes to a megabyte then. I do remember kibi and mebi prefixes being mentioned, but they certainly weren't in common use at the time. As far as I'm concerned they can retcon what the hell they like, but 1024 bytes will always be a kilobyte and 1024 kilobytes a megabyte to me.

maxtherabbit wrote on 2021-06-27, 18:43:

pshipkov wrote on 2021-06-27, 17:41:

@maxtherabbit These are some fat numbers for 486 class rust. […]
Show full quote

@maxtherabbit
These are some fat numbers for 486 class rust.

Thanks for the slow drivers. 😉

PS2 mouse + Promise ultra133 or fasttrak controllers + Biostart UUD = works here, but i think you are on SiS 496 hardware, right ?

Indeed. Are you using cute mouse driver?

yes

pshipkov wrote on 2021-06-27, 17:39:

Maybe consider what i proposed above for partitioning.

I am trying to avoid reinstalling all my programs and games. Of all the dozens of systems I have setup, my IBM 5x86c-133 is the most decked out. To reinstall fresh would take a lot of time and dedication. There is no computer task I hate more than setting up software. Yeah, some folders can be copied over, but not all. Plus all the OS optimisations. Many games have some kind of check to see if the folders were copied over and won't work unless it was installed straight from a CD-ROM. While there may be some cracks for that here and there, looking for and testing them would already take more time than just reinstalling the game from CD. At any rate, I am hoping this XTIDE BIOS will just let me use my Maxtor 120 GB HDD without issue.

megatron-uk wrote on 2021-06-27, 19:53:

As far as I'm concerned they can retcon what the hell they like, but 1024 bytes will always be a kilobyte and 1024 kilobytes a megabyte to me.

Agreed

Biostar MB-8433uud-A rev.2 and rev.3.1, part 2 - 180MHz (3x60)

Introduction:

Been thinking for a while to examine the 486 space above the common 160MHz ... and finally getting to it.

Some of the late AMD's Am5x86 133MHz rated CPUs are capable of reaching 180, or even 200 MHz.
Usually they require active cooling in the form of Peltier element + big heatsink/fan to lower the operational temperature for the processor to run at 180/200MHz.
This approach can cause water condensation and icing. Measures must be taken to prevent that for long-term stability.
Alternatively, some very rare CPUs can run on air cooling only - these are the best option, obviously.

Based on my (still limited) sampling rate ~3 out of ~10 AMD 133MHz rated CPUs have good chance to go beyond the 160MHz.
Some of them may require 4V for that.
So far i have been testing with these guys:
1 BGC, requires 4V
1 ADZ, requires 3.45V (now belongs to @Annonumous Coward)
1 ADW, requires 3.45V <- this one can pass all tests at 180MHz on air cooling only, except the LightWave3D rendering (which is very sensitive, so no surprise really) !
1 ADW, requires 4V
It is interesting to observe how different motherboards "prefer" different CPU models (limited to ADZ/ADW mostly) at different voltages, but that will become more obvious in following posts.

Ok, back to the motherboard in question:

Test configuration:
CPU: AMD-X5-133ADW 180Mhz (3x60), 3.45V, Peltier 5V, heatsink+fan
RAM: 128Mb EDO 50ns
L2 CACHE: 256Kb 15ns
VGA: Matrox Millennium MGA-2064W-R3 / 3D Labs Permedia 2V
HDD: Sandisk Extreme 32Gb 50Mb/s CF, through the on-board IDE adapter
OS: Windows 95 OSR2

Couple of notes:
- From the bunch of PCI VGA adapters, assuming at least some rough and loose period correctness, MGA and Permedia seem to be the fastest in DOS - depends on which test you ask. MGA is fastest in Windows GUI.
- 50ns EDO RAM allows to almost reach the tightest BIOS timings. All settings on max, except DRAM Read WS = 1 and IBC DEVSEL# Decoding = Medium (that last one is mandatory for anything over 33MHz FSB).
- Initially i got the system stable with single 64Mb RAM module, but later increased that to 128Mb. In this configuration the modules have to be in banks 3 and 4, otherwise things get unstable. Over 128Mb RAM - cannot complete post.
- this is one of the most picky motherboards when it comes down to L2 cache chips. For now i have it stable with selected 9 chips (256Kb), but reserve the right to move it to single bank 512Kb in the coming days. If perf characteristics improve, will update the post.
- UMC's IDE DOS drivers hard hang the system when running at 180MHz unless settings get lowered a lot. At that point disk speed gets worse than running without driver.

Left the system crunching for several hours on 3D rendering and then round of DOS interactive graphics with the mentioned above configuration - 5V Peltier + headsink + fan + side fan + enclosing the rig = no water condensation !

SpeedSys:

benchmark results

Video showing quick run with the untidy test contraption.
The heatsink is massively oversized for both 5 and 12V Peltier, half that size will be perfectly fine, especially at 5V.

What PCI divisor are you using?

Are you using 2-1-1-1 for the L2 at 60 MHz FSB? If so, what do your SRAM chips look like?

Are you using the "EDO enable" feature in the BIOS? I've never found EDO faster than FPM on this board. Do you have a photo of your 50 ns EDO stick?

If the chips are stable at 3.45 V with air cooling, why the peltier?

I was about to point you to the provided video in my previous post but noticed that the link was broken.
Fixed it. Take a look. All answers of your questions are there.
Notice the 5V line to the Peltier.

feipoa wrote on 2021-07-04, 14:23:

What PCI divisor are you using?

1:1

feipoa wrote on 2021-07-04, 14:23:

Are you using 2-1-1-1 for the L2 at 60 MHz FSB? If so, what do your SRAM chips look like?

Yes 2-1-1-1 at 60MHz. Check the video - it shows the chips.

feipoa wrote on 2021-07-04, 14:23:

Are you using the "EDO enable" feature in the BIOS? I've never found EDO faster than FPM on this board. Do you have a photo of your 50 ns EDO stick?

In general the board ticks slightly faster with FPM memory, but FPM cannot do 180 with tightest timings reliably. 50ns EDO is required for that. EDO support has to be enabled, otherwise no boot. So, some thread-off there.

feipoa wrote on 2021-07-04, 14:23:

If the chips are stable at 3.45 V with air cooling, why the peltier?

With the two AD* CPUs if the system is used for casual computing, gaming, etc., no Peltier is needed, but if you push it harder it will eventually break.
I have a "complete long-term stability" disorder for retro hardware, so it bugs me if things are not 100% there, at least for some of the "projects" i see important in some way - such as this one.

---

Picture of the EDO RAM:

Pardon my delay, my vehicle work took a lot longer than expected.

We seem to have a similar disorder lol.

Indeed, the video was not available when I asked my questions.

Really curious about that 2-1-1-1 at 60 MHz. How was the stability in Windows 9x or NT4 with that setting @60MHz?

feipoa wrote on 2021-07-08, 22:14:

Pardon my delay, my vehicle work took a lot longer than expected.

Is it rolling again ?

feipoa wrote on 2021-07-08, 22:14:

We seem to have a similar disorder 🤣.

Plenty of mental cases around here.
Is cute ...

feipoa wrote on 2021-07-08, 22:14:

Indeed, the video was not available when I asked my questions.

Really curious about that 2-1-1-1 at 60 MHz. How was the stability in Windows 9x or NT4 with that setting @60MHz?

These boards are super picky about l2 cache, especially obvious if you push them.
As you probably remember, initially I had trouble with them, but your notes motivated me to take a closer look.
Managed to find 9 chips that do it. They also need to be in a specific configuration. You don't just place them in the sockets in arbitrary order. Since then the system was rock stable at 160mhz, but I expected trouble at 180, surprisingly it was a stroll in the park on all levels.
One of those rare success stories with retro junk.

Will try in one of the next days to upgrade to 512kb l2 cache without compromising stability. Will see how that goes. The few brief attempts didn't go well so far.

What I'd really like is an SRAM tester that can determine if the memory will function reliably at a higher speed than indicated n the silkscreen.