Seems like a much cheaper V2 would be just as good for a fast 486 no?

maxtherabbit wrote on 2021-09-04, 02:20:

Seems like a much cheaper V2 would be just as good for a fast 486 no?

I think he's trying to save a PCI slot with the V3.

Good CPU can do 200 MHz reliably once below 10-5 C, but for long term stability icing has to be dealt with.
It was early days for me with Peltier assisted cooling - i was still figuring things out and wanted to see if can achieve the above.
Tried varying Peltier efficiency by adjusting input voltage in the range of 5-12 V and heatsink size, but quickly burned two elements.
If heat exchange gets under some threshold, Peltiers rapidly overheat and if you don't notice it soon enough they burn-out.
It may be my clumsiness and lack of understanding at the time, but it didn't feel the Peltiers acted in a gradual fashion. That is inconclusive of course.
It is kind of hard to explain without writing a lengthy post with the if-then details.

BTW, on a related note - 486DX5 CPU running at 4V (required for 200MHz) and 12V Peltier on top need heatsink with 3 or more copper pipes transferring heat to the fins block. Heatsink with 2 pipes or some of the older design brick coolers are not enough and things overheat.

My recent focus was to go below 5V.
Again - results are inconclusive, but if under that voltage the Peltier seems to be just not working.
I could read online about how these cheap peltiers are constructed and function, but too lazy for that. Varying heatsink and fan requires less brain activity and is easy/quick to do. So didn't continue on the electric path.
For now my focus is on completing the PC. Pretty sure will get the itch about Peltier voltages at some point later.
Been thinking to try that Alaris Cougar + BL3 board fully stable at 100MHz. This will need below ambient temperatures, so there is a strong incentive to better understand these cheapo Peltiers.

Max, what is V2 ?

Just realized what V2 is. Heh.
Initially I was going for a bulky heatsink which blocks 2 of the 3 PCI slots. Also, found that affordable Voodoo3 unexpectedly.
Since then switched to compact cpu cooling solution. The 3 PCI slots are available again, but V3 still seems like the better option than MGA+v2.
Simpler cables, no noisy picture, more compact inside the case, probably slightly faster ‐ cannot verify of course, but voodoo1 delivers one third less frames per second on the same machine, for example.
Also, voodoo2 cards seem to be in the range of $150++ on eBay these days. That gives me a pause ...

I tested gf2 mx400. I actually think it is the better place compared to V3, but not fully stable at 180MHz.
Found cheapo mx440, will see if it does any better.

I doubt the Voodoo3 is any faster than the Voodoo2 on a 486, but it would be interesting to test this and put some numbers to it.

Most of the Voodoo2 cards I have tested offered a very clear display on pass-through when paired with a Matrox G200 and one of those really beefy VGA pass-through cables. The exception seems to be my recent experience with this, perhaps lower quality (?), pair of Voodoo2 cards: Noise on pass-through of a Voodoo2 card

On the one hand, you'd probably want to consider best compatibility with earlier glide games as they are the ones that would most likely actually play any good on a 486. On the other the 2D compatibility and speed of Banshee and Voodoo 3 are meant to be top notch.

Did a quick search but didn't find any numbers related to v2/v3 on 486 class hardware. Most people are vague when it comes to any details, even very coarse ones.
Anyone who has these two cards and dx5@160 or cx586@120 based system can easily confirm if v3 brings any advantage in a data starved pipeline.

BTW, the Banchee core (Windows GDI accelleration) in V3 is better by about 5-10% than the usual champs in this area - mga, g200, etc.
Not that it makes any difference to user. More like another bragging point.

BitWrangler, do you know which game titles are problem for v3 ?
My understanding is that Voodoo3 is pretty much higher clocked v2 rendering pipeline, but with 32-bit textures handling internally and 16-bit dithered on the way out, or something like that.
The two should be fairly compatible, no ?

use one of these instead of the passthrough with voodoo cards and there is no quality loss ever
https://www.extron.com/product/vsw2vgaa
(<$20 on ebay)

but if the voodoo 2 is equally expensive now I guess what's the point 🤣

I suspect they (V2 & V3) offer identical performance. I have a system setup with a Voodoo3, a Cyrix 5x86-133/4x on a SiS 496 chipset. I suppose I can test it, but it is a little messy because I think I need to uninstall the Voodoo3 drivers, install a Matrox + drivers, then install Voodoo2 drivers. After test, uninstall matrox, Voodoo2, reinstall Voodoo3. Unless, however, I can run a Voodoo3 along side a Voodoo2, and if so, how does GLQuake know which card to use?

On a different topic, do you think a SCSI2SD v6 device connected to a AHA-1542C (ISA) would be any faster than PIO-4 IDE/CF on the UUD? When I did some timedemo testing with GLQuake on NT4, I've noticed very brief stutters w/HDD access, perhaps every 10 seconds. I don't recall this when I used the Promise Ultra100 PCI adapter. Thus I got to wondering if using an ISA SCSI card might assist in this regard.

Here's some inspiration to get you to cache mod your UUD. You can see I've added a 4-pin header to the PCB surface. jumpers off = 512K double-banked. jumpers on (1-2, 3-4) = 1024K. The unpleasant aspect is JB welding on the 4-pin header. For this reason, I picked two boards which already have flaws - one has a QFP ground pin missing from the UM8886BF, the other has some bodge wires on the Super I/O.

Max, how does this thing work ? Manually switching between inputs, or some clever signal detection ?

---

About drivers - voodoo drivers will probably overwrite the same files, so it will be necessary to reinstall them.
Otherwise drivers can coexist and are auto-detected upon hardware change.
Give it a spin when you have a moment. Will be interesting to see what the result is. It can be a quick GlQuake test only.

---

No chance ISA SCSI to outdo on-board IDE controller. In theory ISA maxes out at 8Mb/s. Ok, let's say 10Mb/s with overclocking the bus. Any SCSI advantage is capped. At best it will match the on-board controller.
But something does not sound right in what you are seeing over there. There is no HDD access at runtime in Quake.
I can fresh confirm this, because just yesterday put the LDS 180MHz rig through an extreme stability grinder - for 2-3 hours crunching on 3D rendering and GlQuake in parallel. With 128Mb RAM there was no disk access the entire time for both processes - at least the yellow LED on the CD-IDE adapter never lit.

---

+1
Looking good.
Let's talk 1024Kb UUD soon. 😀

it detects an active sync pulse on h sync, so when the voodoo 2 turns on it automatically switches to that input (when multiple inputs have active sync it goes to the higher numbered one)

pshipkov, do you really want another clutter box on your desk and to connect this device each time you pull out a system? Just get a quality pass-through cable. I thought all pass-through's were the same, that is noisy, until I found some fat mofos.

Since the UMC driver doesn't work with CF cards above 8 GB, my transfer rates are slower than yours, typically about 5700 KB/s in PIO mode. Take a CF or SD card on SCSI-ISA, I bet it can top that 5700 KB/s speed while taxing the CPU less. I think there is merit for benchmarking this. I've got my money on the ISA SCSI.

You don't have any IDE access whatsoever in GLQuake's timedemo in NT4 w/UUD? What if you drop the RAM to 128 MB and don't use any sort of magic pseudo DMA driver?

Notice how on the first UUD board I have socketed every DIP. I can't remember why I did that, but I must have been troubleshooting something. I also swapped all the caps. The issue with broken LPT and serials was fixed recently as well. I'd like to ditch the masking tape but don't want to use hot glue for the wires. I also don't want to use strong glue like jb weld for the wires. Any recommendations for temporary glue for the bodge wires - perhaps Elmer's contact cement? Or maybe just some kids Elmer's white paper glue?

The extron is higher bandwidth than the onboard switch ic period. Doesnt matter how nice of a pass through cable you use. You will notice a difference running 1600x1200 on the 2d card I promise

feipoa wrote on 2021-09-04, 22:25:

pshipkov, do you really want another clutter box on your desk and to connect this device each time you pull out a system? Just get a quality pass-through cable. I thought all pass-through's were the same, that is noisy, until I found some fat mofos.

Why i am considering it ?
The lengthy explanation - for 100% stability LS D needs 3-1-2 L2 cache timings. This makes it slightly slower than Biostar UUD in DOS. So, i was calculating - if UUD really can do 100% stable at 2-1-1-1 L2 cache and if there is no perf difference between UUD+Voodoo2 and LSD+Voodoo3, given the CPU limited 3D interactive graphics, then i will probably go with UUD at the end.
But spent the time today to fine-profile UUD and at 2-1-1-1 it will eventually crack - very rarely, but happens. I kind of expected it - similar to LSD it can fail under heavy load. So, when UUD is running with 2-2-2-2 or 3-1-1-1 for complete stability, the status quo of SiS being clock-to-clock faster than UMC is maintained, so LSD comes on top, by hair.
Will swap the 15ns ones on UUD with 10ns and spin it again, but the last time i did that there was no observable difference.
Will do the same for LS D - swap the 10ns with 8ns ones.
At this point i am not convinced it is the L2 cache chips quality, but more like the overall system stability.
So, UUD has one more chance to surprise me, if it manages - Max's suggestion will come-in handy, despite the added clutter. Voodoo screen noise is not cool.

feipoa wrote on 2021-09-04, 22:25:

Since the UMC driver doesn't work with CF cards above 8 GB, my transfer rates are slower than yours, typically about 5700 KB/s in PIO mode. Take a CF or SD card on SCSI-ISA, I bet it can top that 5700 KB/s speed while taxing the CPU less. I think there is merit for benchmarking this. I've got my money on the ISA SCSI.

Hmm, the UMC IDE drivers work fine with 8Gb and bigger CF cards - that is for sure. At least i can confirm that the driver is fine with up to 32Gb CF cards. Don't have bigger than that, so no idea above that size. Or maybe i don't understand your message correctly ?

feipoa wrote on 2021-09-04, 22:25:

You don't have any IDE access whatsoever in GLQuake's timedemo in NT4 w/UUD? What if you drop the RAM to 128 MB and don't use any sort of magic pseudo DMA driver?

Ah, maybe it is different in NT4, but in Win95 there is no disk access during runtime. I don't use UMC IDE drivers for Win95. Also, don't use the DOS driver since it hangs at 180MHz when disk speed setting is set above 5. At that value the driver slows things down compared to no driver.

feipoa wrote on 2021-09-04, 22:25:

Notice how on the first UUD board I have socketed every DIP. I can't remember why I did that, but I must have been troubleshooting something. I also swapped all the caps. The issue with broken LPT and serials was fixed recently as well. I'd like to ditch the masking tape but don't want to use hot glue for the wires. I also don't want to use strong glue like jb weld for the wires. Any recommendations for temporary glue for the bodge wires - perhaps Elmer's contact cement? Or maybe just some kids Elmer's white paper glue?

What is the difference between UUD revisions 2/3/3.1 ?
Version 2 has capacitor in front of the tag socket. On your photos that cap is gone. Did you remove or it was not there to start with ?
Otherwise the 1024Kb L2 cache mod looks pretty straightforward. I have no idea how you came up with it, but the actual implementation seems to be easy to replicate.

maxtherabbit wrote on 2021-09-05, 00:56:

The extron is higher bandwidth than the onboard switch ic period. Doesnt matter how nice of a pass through cable you use. You will notice a difference running 1600x1200 on the 2d card I promise

Good to know. Thanks.

I don't know if you are considering max's implementation, but perhaps it depends on what resolution you are running? I don't run 1600x1200 on any of my systems. At 1280x1024 w/Matrox G200 and a decent Voodoo2 card & cable, I see no observable difference in image quality when using the V2's passthrough vs. connecting the VGA cable directly to the Matrox. I spent about 10 minutes going back and forth with the implementations and couldn't detect a difference. I took some photos of the screen and also cannot detect any difference in image quality upon viewing the photos. Send me your e-mail via PM if you want the uncut photos. My vision is still 20/20 without corrective lenses.

Perhaps 1024K on the UUD will win the stability race vs. LSD? Not being able to run the floppy drive on the LSD at 66 MHz is a cripple in my mind.

Personally, I wouldn't want to push more than 8 GB on the UUD without XTIDE or a BIOS fix. Have you tried filling up the 32 GB card while in the system? I have one 32 GB card, which as we discussed previously, actually measures correctly in the BIOS if you consider the truncated digits, however my 16 GB card comes up as 8-ish GB. So I feel that the the 32 GB limit may not be fully supported. A cloned 32 GB card from a system with proper 32 GB support won't properly on the UUD when your w95 boot partition is beyond 8 GB. XTIDE fixes this.

My comment was that I think I am going to compare the UUD's onboard IDE-CF vs. AHA-1420C w/SD or CF after narrowing down the NT4 GLQuake HDD access stutter issue.

I will see if w95 exhibits the slight HDD access stutter vs. NT4. It may also be the RAM size. Or perhaps I left the Task Manager open. I need to re-check.

If my memory is correct, I think I listed some differences between the UUD versions in the board's manual. Some have different impedance matching resistors on the clock line, for example, while some have resistor packs near the CPU, others don't, some socketed RTC, etc. When I was updating the v3.0 for the cache mod, I did spot another difference compared to v3.1 but I've already forgotten what it was. The differences are subtle and don't seem all that important.

All revisions have a cap under the TAG, but you need to get a shorter cap if doing the mod. Originally I placed a tantalum on the underside but it would create a high point when the board was on a table, so I then replaced the 10uF electrolytic cap with a 10uF SMD tantalum. The electrolytic was 25 V and the SMD is 6.3 V. I've run it like this for years and have no issues.

feipoa wrote on 2021-09-05, 02:27:

I don't know if you are considering max's implementation, but perhaps it depends on what resolution you are running? I don't run 1600x1200 on any of my systems. At 1280x1024 w/Matrox G200 and a decent Voodoo2 card & cable, I see no observable difference in image quality when using the V2's passthrough vs. connecting the VGA cable directly to the Matrox. I spent about 10 minutes going back and forth with the implementations and couldn't detect a difference. I took some photos of the screen and also cannot detect any difference in image quality upon viewing the photos. Send me your e-mail via PM if you want the uncut photos. My vision is still 20/20 without corrective lenses.

We trust you, no need for email.
That VGA switch seems to be a good and easy solution to noisy picture, if i end up doing something with Voodoo2 and turns out noise is a problem.
Not that hot on Voodoos in general. Good hardware for its time, but packaged as one trick ponies - can do early 3D shmups and that's kind of it.
Too bad GF2 MX400 is unstable. V3 goes in the case now, but i know already that will be looking at other GF/TNT2 options ...

feipoa wrote on 2021-09-05, 02:27:

Perhaps 1024K on the UUD will win the stability race vs. LSD?

That's the hope. To be verified.

feipoa wrote on 2021-09-05, 02:27:

Not being able to run the floppy drive on the LSD at 66 MHz is a cripple in my mind.

LSD has an issue with Gotek usb-floppy adapters in general, not only when running at 3x66MHz.
Somehow unmoved about it. Cannot remember anymore when was the last time i used floppy.

feipoa wrote on 2021-09-05, 02:27:

Personally, I wouldn't want to push more than 8 GB on the UUD without XTIDE or a BIOS fix. Have you tried filling up the 32 GB card while in the system? I have one 32 GB card, which as we discussed previously, actually measures correctly in the BIOS if you consider the truncated digits, however my 16 GB card comes up as 8-ish GB. So I feel that the the 32 GB limit may not be fully supported. A cloned 32 GB card from a system with proper 32 GB support won't properly on the UUD when your w95 boot partition is beyond 8 GB. XTIDE fixes this.

Even i use bigger CF cards on 486 class hardware i don't go above 8Gb on the partitions. In fact i rarely exceed 4Gb.
But have some CF cards with bigger partitions and don't recall them being a problem on 486. So tentative Yes, but reserve the right to retract it. 😀

feipoa wrote on 2021-09-05, 02:27:

If my memory is correct, I think I listed some differences between the UUD versions in the board's manual. Some have different impedance matching resistors on the clock line, for example, while some have resistor packs near the CPU, others don't, some socketed RTC, etc. When I was updating the v3.0 for the cache mod, I did spot another difference compared to v3.1 but I've already forgotten what it was. The differences are subtle and don't seem all that important.

All revisions have a cap under the TAG, but you need to get a shorter cap if doing the mod. Originally I placed a tantalum on the underside but it would create a high point when the board was on a table, so I then replaced the 10uF electrolytic cap with a 10uF SMD tantalum. The electrolytic was 25 V and the SMD is 6.3 V. I've run it like this for years and have no issues.
UUD_tantalum_cap_for_TAG.JPG

Ah, yes. Checked it.

Do you also have stability issues with the GF2 at more modest front-side bus speeds, e.g. 33 MHz?

I have confirmed that w95 doesn't have much or any HDD access while playing GLQuake and there is no brief stutters. These stutters occur in NT4 only and happen on average twice during the timedemo. While running the timedemo in NT4, there is periodic HDD access through the whole run.

Indeed, we have different requirements for HDD sizes.

feipoa wrote on 2021-09-06, 05:02:

Do you also have stability issues with the GF2 at more modest front-side bus speeds, e.g. 33 MHz?

No, but in general something is wrong with the drivers. Tried 5-6 different versions - from 8 to 40-something. OpenGL context cannot be created. Need to test with DX too, but OGL not working is a disqualification by itself.

feipoa wrote on 2021-09-06, 05:02:

I have confirmed that w95 doesn't have much or any HDD access while playing GLQuake and there is no brief stutters. These stutters occur in NT4 only and happen on average twice during the timedemo. While running the timedemo in NT4, there is periodic HDD access through the whole run.

Good to know that you see the same on Win95.

Made a simple app establishing OpenGL context through glut32. Stack trace ends in the driver, but there are no debug symbols, so cannot see past that.