ooooh, full AT enermax PSU, don't see that every day ^^

do you plan to use the EEPROM programmers eventually?

also 486 boards with intel chipset seem to be a rare breed too.

6.22 doesn't sound that bad.

imi wrote on 2020-06-12, 22:01:

ooooh, full AT enermax PSU, don't see that every day ^^

do you plan to use the EEPROM programmers eventually?

also 486 boards with intel chipset seem to be a rare breed too.

A bit of an odd system indeed, that's what decided me to create a building in the first place. Intel boards always do seem to be reliable and we'll build. On the other hand it won't be the fastest, since the maximum FSB is 33MHz and my IBM PS/Valuepoint still seems faster (DX/2-66 as well, S3-805 onboard)

The previous owner got it from his employer, and there it was actually in service since 1995 up to about a month ago now, so I figured it has to be build of quality components only.

For the programmers I don't have much use now, but I may get to that some time. There are a few computers that I could test with a newer bios version or something like XTIDE to get large disk support.

First things first, the Dallas was dead and was in need of repair. Without it, there's no way the bios can save it's config.

I took out the motherboard (again) and got my cutting tools to expose the Dallas' leads to the internal battery. As I explained before, I did not want to resolder the whole Dallas.

(I know a lot of you know how to do this, but here's my procedure)
When there leads were exposed and the - lead was cut thru, I took me multimeter to checkvoltages:
+ to lower - lead: zero volts.
+ To upper - lead: 1.24 volts (should be around 3 volts).
No wonder the system have me a battery failure error.
Cutting the - lead is needed to decouple the internal battery (which will remain there until the end of time).

I blew out the dust, cleaned stuff with 96% medical alcohol and went on.

Then I took my soldering iron, a CR2032 holder and some random wires, some soldering tin (lead free I discovered) and soldered the leads to both the Dallas and the CR2032 holder, protect the soldered joints by shrink tube and stuck the wires and battery holder to the Dallas with carpet tape.

Reinstatalled the motherboard and put in a CR2032 battery, reconnected and.....

No battery error any more!

Now I can set the system up 😀

PS. Please don't ask for a photo of me solder joints, I just reinvented the word "blob".

And took a little time to benchmark some graphics cards.
Bios settings: stock, as there is nothing to change at all...
Same 70ns memory
Good old LAN card
64MB compactflash, loaded with MS-DOS 6.22 and Phills benchmark compilation.

VGA cards tested:
- Video Magic pci-V864 (V864 1MB)
- Diamond Stealth 64 Video Vram (V968 4MB)
- Elsa Winner 1000/T2D (Trio64 DX 2MB
- Hercules Terminator 3D/DX (Virge DX 4MB
- Matrox Millennium MGA 2064W Storm (4MB)

Basically these are the only PCI graphics cards I have for a 486 computer, besides another Trio64 and two virges. Not going ot ISA. The PCI TNT2 might blow into pieces?

Surprisingly there is almost no difference in performance.
Somehow the Trio64 and Virge don't finish all vesa tests...
The MGA did a little better in PC Player vesa mode... But that's it.
See attachments for results, not gonna type them out :p

So far the Diamond might be my first choice because:
- build in 1995 would match the year this machine is put into service (bios date is 1994)
- benchmarks are the same in DOS mode but in Windows environment the higher resolution and colour depth may be welcome (and video acceleration?)
The 2MB upgrade module looks awesome: solid as a rock!
- I've got two more of this exact same card in stock

Any thoughts on graphics?

--

Something weird I noticed: my motherboard only has one IDE connector, obviously for two drives.
Bios will let me set 4 drives. So I need a secondary IDE controller in my system (or at least one without standard IRQ that messes with onboard one)
Might a sound card with IDE do?

waterbeesje wrote on 2020-06-14, 22:32:

And took a little time to benchmark some graphics cards.
[...]
Surprisingly there is almost no difference in performance.

All of your graphics cards are faster than the PCI host of the mainboard. You might want to check if you have options like "PCI write buffer" and/or "PCI burst writes" in the chipset setup, and enable them.

Edit: removed comment about IDE, because that comment applied to a different board - I mixed up threads.

mkarcher wrote on 2020-06-14, 22:54:

waterbeesje wrote on 2020-06-14, 22:32:

And took a little time to benchmark some graphics cards.
[...]
Surprisingly there is almost no difference in performance.

All of your graphics cards are faster than the PCI host of the mainboard. You might want to check if you have options like "PCI write buffer" and/or "PCI burst writes" in the chipset setup, and enable them.

Edit: removed comment about IDE, because that comment applied to a different board - I mixed up threads.

Early Intel chipset PCI performance is not the great . I wonder if something like FASTVID would help on a PCI 486 .

darry wrote on 2020-06-15, 02:34:

mkarcher wrote on 2020-06-14, 22:54:

All of your graphics cards are faster than the PCI host of the mainboard. You might want to check if you have options like "PCI write buffer" and/or "PCI burst writes" in the chipset setup, and enable them.

Early Intel chipset PCI performance is not the great . I wonder if something like FASTVID would help on a PCI 486 .

FASTVID (and similar programs) tell the processor that it may merge consecutive writes to video memory into larger write cycles (USWC = uncached speculative write combining), so the processor does not do single 32-bit write cycles, but uses burst writes at the native FSB width. This requires a processor that is able to do USWC, so at least an AMD K6 or an Intel Pentium Pro. FASTVID does not work on a 486 processor. While the enhanced 486DX4 with write-back cache supports burst-writes at least, it only does so with a compatible north bridge and only in cachable areas, so even on the latest Intel 486 processor, USWC memory access is unsupported. Also the native FSB width is just 32 bits, so the advantage of merging write cycles into 64 bit FSB cycles (which the K6 and Pentium Pro do in USWC mode) is not applicable on Socket 3 systems.

Chipset options contains two options: one involves memory usage by ISA stuff, the other one gives me 0.4fps higher performance on 3D bench and PC player Vesa. No changes in other benchmarks.

This system being not the fastest is correct as even my IBM PS/Valuepoint with S3-805 onboard (VLB) gets results in the same league, slightly higher in some benches. Something with early, immatue PCI I guess?
But hey, this one seems to be made to be reliable so who gives about speed 😜 and if I really need something faster, I'm going the Pentium/K6 road.

mkarcher wrote on 2020-06-15, 05:46:

darry wrote on 2020-06-15, 02:34:

mkarcher wrote on 2020-06-14, 22:54:

All of your graphics cards are faster than the PCI host of the mainboard. You might want to check if you have options like "PCI write buffer" and/or "PCI burst writes" in the chipset setup, and enable them.

Early Intel chipset PCI performance is not the great . I wonder if something like FASTVID would help on a PCI 486 .

FASTVID (and similar programs) tell the processor that it may merge consecutive writes to video memory into larger write cycles (USWC = uncached speculative write combining), so the processor does not do single 32-bit write cycles, but uses burst writes at the native FSB width. This requires a processor that is able to do USWC, so at least an AMD K6 or an Intel Pentium Pro. FASTVID does not work on a 486 processor. While the enhanced 486DX4 with write-back cache supports burst-writes at least, it only does so with a compatible north bridge and only in cachable areas, so even on the latest Intel 486 processor, USWC memory access is unsupported. Also the native FSB width is just 32 bits, so the advantage of merging write cycles into 64 bit FSB cycles (which the K6 and Pentium Pro do in USWC mode) is not applicable on Socket 3 systems.

Thank you. This explains it more succintly and clearly than anything I had read so far on the subject .

mkarcher wrote on 2020-06-15, 05:46:

darry wrote on 2020-06-15, 02:34:

mkarcher wrote on 2020-06-14, 22:54:

All of your graphics cards are faster than the PCI host of the mainboard. You might want to check if you have options like "PCI write buffer" and/or "PCI burst writes" in the chipset setup, and enable them.

Early Intel chipset PCI performance is not the great . I wonder if something like FASTVID would help on a PCI 486 .

FASTVID (and similar programs) tell the processor that it may merge consecutive writes to video memory into larger write cycles (USWC = uncached speculative write combining), so the processor does not do single 32-bit write cycles, but uses burst writes at the native FSB width. This requires a processor that is able to do USWC, so at least an AMD K6 or an Intel Pentium Pro. FASTVID does not work on a 486 processor. While the enhanced 486DX4 with write-back cache supports burst-writes at least, it only does so with a compatible north bridge and only in cachable areas, so even on the latest Intel 486 processor, USWC memory access is unsupported. Also the native FSB width is just 32 bits, so the advantage of merging write cycles into 64 bit FSB cycles (which the K6 and Pentium Pro do in USWC mode) is not applicable on Socket 3 systems.

When I'm going to setup all software, I may get into using fastvid, univbe and perhaps some othert tools to check if it runs, if performance benefits and if it's useful at all.

As said, I don't expect anything to happen on a 32b fsb with 32b graphics cards. Translating native to native only involves a little overhead without any benefits.
In case 16b code is used by the CPU (for whatever unknown reason) it may be beneficial and we'll all see improved benchmark numbers 😀

Seems strange to have such a big case for what a standard case could support. Usually these full towers had SCSI and multiple HDD's
If it was me I'd use the onboard IDE and attach the CD drive off the soundcard especially if your keeping it more or less a 95 build.
But I also feel like working to the limits of onboard IDE is what gives it some of its character.

If you already have a DX2 (or 3) then at least one needs upgrading! POD83 is another choice and can be had for ok prices if you wait.
at least one of your 486's needs to be Dos/Win3x (exact dos version is up to you but I'm a traditionalist and would go 6.22)
Win98 is asking alot of a 486. Win95 is a better option for a 486. but no matter which OS you choose a 486 is always going to spend most its time at the command prompt.

chinny22 wrote on 2020-06-16, 15:58:

Seems strange to have such a big case for what a standard case could support. Usually these full towers had SCSI and multiple HD […]
Show full quote

Seems strange to have such a big case for what a standard case could support. Usually these full towers had SCSI and multiple HDD's
If it was me I'd use the onboard IDE and attach the CD drive off the soundcard especially if your keeping it more or less a 95 build.
But I also feel like working to the limits of onboard IDE is what gives it some of its character.

If you already have a DX2 (or 3) then at least one needs upgrading! POD83 is another choice and can be had for ok prices if you wait.
at least one of your 486's needs to be Dos/Win3x (exact dos version is up to you but I'm a traditionalist and would go 6.22)
Win98 is asking alot of a 486. Win95 is a better option for a 486. but no matter which OS you choose a 486 is always going to spend most its time at the command prompt.

Indeed this size case is a bit overkill for the hardware I'm going to use (for now). Simply I don't have any smaller case.
Going SCSI has come up to me. I do have 2 or 3 SCSI controllers for PCI, but I don't really have suitable hard drives and CD-ROM. Only some old-school tape device.

On the other hand, this is what I can come up with now. This may change while I'm building Bakbeest.
- On-board IDE: 1 IDE hard disks and 1 IDE-to CF thingy
- Soundcard: CDROM drive and ZIP drive; (master/slave) should work as well. Maybe an LS120 drive instead of the ZIP...
- DITTO 800 drive, connected to the FDD controller next to the two existing floppy drives (if I can find it)

As for the CPU upgrade: I hope to find e DX/4 for cheap to replace this DX/2. The motherboard also supports a DX/4-100 at 3.3v
Sure, I am going to look into my 486 collection to see what could be upgraded when I come along a nice CPU. This is my collection at the moment:
- nameless LIFF board (ISA only; DX-50; 8MB 60ns). Able to utilize a DX/2 but for now I think a DX is cool enaugh.
- (can't remember the brand) socket 2 board (TGUI9420 VLB; DX/2-66; 8MB 60ns). Quite maxed out on the DX/2.
- Aquarius MB-4DUVC-2 (CL VLB; I/O VLB; DX/2-66 (32MB 60ns). Wil be able to utilize a DX/4 or maybe unofficially even a 5x86.
- IBM PS/Valuepoint 466 (integrated S3 805; DX/2-66; 12MB). Maxed out at CPU.

But that's not for now.

First things first, I need some kind of sound card
What I have laying around:

- ExpertMedia MED2000 (AD Soundport; 4 CDROM controllers!): Could be the one?
- some Crystal 4237B: Could be the one?
- IBM Mwave: just nah. Only when the casing says IBM.
- Sound Blaster 32 CT3620: Hanging note bug? Of should I ignore that and chose this one?
(and probably 6 or 7 ISA cards without IDE support)

Which one would you choose?

(and now I'm gonna dig for a hard disk)

Just to be clear wasn't questioning your choice of the case but the original system builder.
Full tower case would have added to the initial cost. Good for you (as long as you have the space) as its more rare/interesting .

Hanging not bug isnt an issue unless your using external midi device, and if you are you have another 486 to use anyway.
But assuming you have another dos rig with an AWE already I'd say go with something different either the ExpertMedia or Crystal 4237B:

chinny22 wrote on 2020-06-19, 16:04:

Just to be clear wasn't questioning your choice of the case but the original system builder. Full tower case would have added to […]
Show full quote

Just to be clear wasn't questioning your choice of the case but the original system builder.
Full tower case would have added to the initial cost. Good for you (as long as you have the space) as its more rare/interesting .

Hanging not bug isnt an issue unless your using external midi device, and if you are you have another 486 to use anyway.
But assuming you have another dos rig with an AWE already I'd say go with something different either the ExpertMedia or Crystal 4237B:

I'm gonna stuff it with hardware any way, so this tower may come in handy 😀
For the hard drive I've chosen a Quantum Fireball TM 1,28 GB. Not really period correct, but other drives didn't just do it:
Some Seagate 420MB I'm planning to put into my DX50 (no LBA support) and a seagate 840 MB that has the dual drive emulation (I'll keep it for a system without LBA too).

I remember having a soundcard in my 386 DX-40 that has the ability to run as primary or secondary IDE port, but the bios does not see a secondary IDE. Maybe the Crystal will end up the that rig and the secondary IDE can be used for both a hard drive and cd rom in this system. Maybe I'll even add a sluggish Bigfoot drive then. If that does not work in gonna put in the Sound blaster 32 if the hanging note bug won't occur (as I don't have one inside a computer at the moment).

Memory.
There already was 16MB of ram in this system. After testing some unidentified ram modules I had laying around I decided to max out the system. It now have 64MB of ram. In benchmarks there is a slight improvement in scores (around 2% over 5 benchmark cycles).
I tested with both 60 and 70ns ram, both FP and EDO... No difference noted.

Also external cache seems to run at 30ns (internal at 15ns) as is usual with a DX/2-66 (or DX33, SX33, DX/4-100, DX/5-133...)
The boards FSB is a to 33MHz already maxed out (to keep PCI working I guess)...
So why did they put in 15ns cache any way???

Also I had some tests with fastvid. Performance gain is zero.

And software: I already have installed MS DOS 6.22 and Windows 3.11 fw, without drivers yet.

Testing 30 previously untested ram sticks took a bit of time... And as long as the sound card is not sure yet I might switch around. Switching drivers too often in Windows is never a good idea, so Windows drivers will come later on.

I got into sound cards yesterday. The Sound blaster 32 didn't really fit well, all kinds of collision with cables and headers. Besides, the IDE cable for the CDROM would be exactly at the CPU cooler, blocking airflow. So I'll stick with a shorter card.

I did test the card from my 386 computer which saus uit van be set as primairy or secondary IDE. Putting it as secondary didn't work as I hoped. Bios will detect primary master as drive C, secondary master as drive D (not E). When I put in a primary slave (CF card) bios will hang on post when detecting drives.
Putting it as primary will get me to new adventures as well...

So next was the Crystal CS4237. Supposed to have a fine opl3 clone, has always provided me reasonably good sound so I'll stick to that one.

Next up is Windows 3.11 giving me issues. Could you help me on these?

On boot I use a slightly modified version of Phills boot menu from the starter pack.
Ctmouse loads and put the mouse driver to com 2 (that's where the Logitech mouse is).
When I start Xtreme Gold the mouse does what it is expected to do. This mouse works fine on various other computers as well.
When I setup Windows the mouse gets detected as Logitech (standard Windows drivers) but will not respond to movement at all. Any suggestions?

Also when Windows loads with default VGA driver, it boots just fine. When I set up the driver for Diamond Stealth 64 Vram all I get is a black screen.
Standard svga modes will refuse to work gunning me an error, returning to command prompt.
Note that my graphics card is a Diamond Stealth 64 Video Vram... Are these that much different for drivers?
Which drivers should I use instead?

Also gonna put a Zip250 drive in, at the same IDE port as the CDROM. I don't have any media for it but it just looks cool and the colour matches perfectly.

Personally I replace stock HDD with ide to CF converters. For testing a converter that stick directly into the mobo, for more permanent computers I use one that stick out the end of the case. I believe it is more convenient to transfer data and more reliable in the long run. Those old drives can be failures waiting to happen.

Just my stuiver 😉

db

The CF to IDE is already part of the system 😀
Primary master is the good old rotating noisy hard disk, and primary slave is the CF adapter. When the system is up and running I'm gonna make a full backup to CF and store at my (fairly modern) home server.

I just can't let go the good old rattling sound of an actuator 😀

This setup is pretty standard for all my machines with IDE.

That said: my XT class computers all still run mfm/rll, edsi or XTA except my Philips p3105 where the Miniscribe 8425x died... And data transfer mostly is done by laplink to my K6-3+ machine.

Windows is getting me crazy on the mouse, my perfectly well working Logitech three button mouse just won't be initialised by Windows.
Besides I don't seem to find ant good Windows 3.11 driver that works with my S3 968 graphics card, besides standard VGA.
So I deleted Windows 3.11 for now, going to try it some later again. Perhaps with another mouse and other graphics card.

Browsing for some more info about the Ninja board, I came across SETARIES.EXE by Tiido. It gives the 420EX chipset a little boost.
Just curious I tested it and it seems to speed up the system by about 5% overall, 0.5% to 8% depending on which benchmark I run.
My command line parameters:
SETARIES /P1111 /M11100 /81 /161
Toggling the /C parameter freezes the system...

According to cachechk memory speeds up too. (And cachechk takes loooooong to get all 64MB ram)

CPU 66MHz
L1: 15.4ns (unchanged)
L2: 30.0ns (unchanged)
Main memory: 38.1ns (was 40.1ns)

Benchmark results:
3Dbench 1.0: 50.0fps (was 47.6)
3Dbench 1.0c: 48.1fps (was 47.3)
Chris 3D VGA: 32.9fps (was 32.4)
Chris 3D svga: 9.9fps (was 9.5)
Pc player VGA: 11.4fps (was 11.0)
Pc player svga: 4.7fps (was 4.4)
Quake low: 7.8fps (was 7.5)
Speedsys: 25.08 (unchanged)