Great ! Will look thru Archive org maybe there will be a bit more buried somewhere.

How can you be certain VLB runs at full CPU bus speed? I seriously doubt whoever designed the board would have been crazy enough to do something like that.

Anonymous Coward wrote on 2020-12-31, 06:18:

How can you be certain VLB runs at full CPU bus speed? I seriously doubt whoever designed the board would have been crazy enough to do something like that.

Well, to be absolutely sure I'd need an oscilloscope (which I still don't have), but I have three VLB cards that run stable at 33MHz FSB and below, boot but not stable at 40MHz FSB and fail to boot at 50MHz and above.

That's exactly the same behaviour as they show in a 486 system with VLB at those clocks and zero wait states, so if it walks like a duck and quacks like a duck...

And yes, crazy design on a system with CPUs with intended bus speeds over 50MHz - but that OSC3 socket is there for a reason. The designer clearly intended to have the VLB bus run at its own speed, but someone decided not to spend the few additional dollars to actually allow it to work as intended. That sounds like typical business logic.

Right, got testing this again today and absolutely cannot reproduce. System boots happily with VLB card and FSB at 80MHz...

No idea what's different between today and last night. Played around with J15/16/17. Moving J17 to 2-3 completely stops system from booting, J15 and 16 don't do anything immediately obvious. I then dug out a 25MHz oscillator from an old 286-12 board and stuck that in OSC3. Not able to see any difference there either. I would have assumed J17 switched from system clock to oscillator, but system still freezes with oscillator in place. TBC after New Year.

Non-486 VL implementations are typically not local bus per se (read the CPU is not driving the bus). It is typically a mezzanine bus, just like the PCI. It is asynchronous bus created by the chipset running at VL-Bus compliant speeds.

66 MHz FSB let alone 80 MHz would stretch classic VLB way too far.

We have documented slightly this motherboard on UH19 here : http://www.win3x.org/uh19/motherboard/show/6719

Please keep us updated if you make other discoveries (such as jumper settings, proof of max cache size/max ram size, etc) 😁

Looks like a good board to buy a voltage regulator/ adapter and drop in a k6-2 475 @ 6x80mhz :0

rmay635703 wrote on 2020-12-31, 17:57:

Looks like a good board to buy a voltage regulator/ adapter and drop in a k6-2 475 @ 6x80mhz :0

Hehe, mind reader 😉

It just so happens I have one of those adapters. I also have a spare K6-3 😀

But first things first figure out how the board works. With a bit of luck I intend to test RAM limits and caching limits today. Maybe figure out some of the cache jumpers too, but I'm not sure if I have enough SRAM with correct specs for that.

Edit:
Looks like I have bad cache anyway. Getting memory errors in same place regardless of installed - known good - SIMM(s). Upshot: I now know the board can boot/run on a single SIMM.

Edit2:
Not so sure it's cache. Have disabled L1 and L2 cache, still get the errors. Have tried multiple SIMMs in all SIMM slots and keep errors. Have swapped CPU and keep errors 🙁

Have now also tested with 64MB SIMMs: detected as 16MB. So the memory controller can handle max 16Mb (4Mx4) chip density. That means max RAM is 128MB.

Edit3: mem errors don't occur on second board. Looks board-related. Continuing cache tests on second board, will come back to first one later. I *really* like having two identical boards when trying to figure out obscure stuff.

Edit4:
Now done some work with CACHECHK. Interesting results:
- even with 128MB installed, CACHECHK says CMOS reports 64MB RAM
- figures for L2 and main memory (throughput, clocks, read/write times) identical down to the decimal with both 64MB and 128MB installed - and in WB and WT modes. That looks odd to me.
- with 32MB (single SIMM, 32b wide memory bus instead of 64b), scores are lower, but only 11% lower bandwidth and 12% higher read access time. Write access times essentially the same (1ns longer)

The results for 64MB and 128MB puzzle me, as I'd expect small but measurable differences between WT and WB, and I'd definitely expect a difference between cached (assumption: 64MB) and uncached (assumption: 128MB). I would have expected 128MB to be cached in WT but not WB, so performance from high to low: best 64MB WB, medium 64MB or 128MB WT, worst 128MB WB. Instead: absolutely no difference.

Tests so far performed at 33MHz FSB, 50MHz CPU. Will try to clock up and see what happens.

Edit5:
Figured out some of the cache jumpers: JP11 and 14 are set to 1-2 by default, which gives 256kB. Setting both to 2-3 sets cache to 512kB (either one still reports 256kB). Note that my board came with an 8Mx8 tag, which is only enough for 256kB. To use 512kB, it needs to be swapped for a 32Mx8 tag. Unfortunately my board isn't stable with 512kB, going into a boot loop around start of loading OS. The cache came from a board that used to work perfectly, and is rated to same 15ns as existing cache, but one way or another it's not happy.

Edit6: false alarm. Board is more than happy with 512kB, so long as you have all the legs in the sockets 😉 So, we definitely have the jumpers for 512kB vs 256kB. With 512kB, cachechk results are subtly better than 256kB results at 64MB and 128MB RAM, although probably not noticeably - 8. 6% better - and block sizes up to 512kB are now handled by cache instead of 256kB.

Edit7: have it all running at 66MHz FSB/100MHz CPU now. Trying again to figure out cacheable area, but getting nonsensical results. With 128MB installed, CTCM 1.7a says I have 896MB, while cacheable area is 897MB L1 and 832MB L2. It then hangs at MMOVI... CACHECHK simply doesn't go past 64MB at all, so can't test it with that either. Will probably have to boot into Linux to figure this one out, but that's for another day.

Well, update again:
After wrestling with Grub on different systems I swallowed my pride and just imaged a "floppy" (Gotek) with Smart BootManager. I'm now (veeeeeery slowly) booting into Linux.

While I'm at it I've confirmed that the Adaptec AHA-2840A VLB SCSI controller works on this board, and does so significantly faste than the AHA-1542B ISA SCSI controller I was previously using. Had some very patchy results with PCI SCSI cards, Adaptec AHA-2940U and Dawicontrol DC-974; sometimes the card BIOS didn't initialize at all, other times it did, but failed to find the drive - and that independently of which slot I used. So now with the VLB controller and booting into Linux I wanted to see if it was more a BIOS (mem range) issue or actual PCI/interrrupt issue. But of course, now all cards are behaving fine and I can happily boot with VLB & both PCI cards at the same time with drives on the lot of them. If issues with PCI cards resume, I'll troubleshoot further.

Now to look into cacheable limit...

Another update:
Still haven't figured out cacheable limit. Did try some different CPUs and bottom line: this is one of those boards that refuses to boot with unidentified CPU.

Cyrix 6x86: C0 POST, no boot.
Pentium MMX on Powerleap adapter: no POST at all.
K6/3-450 on Powerleam adapter: C0 POST, no boot.

Then I broke some pins on the adapter, so no more chance to try later CPUs. I don't have any K5 or other early 3.3V non-Intel CPUs for other tests, but looks like P54C is the newest it will run. Maybe will try a Winchip if I can find one...

Maybe someone at Wimsbios could ungimp your bios for non p54 operation?

Bump. Have figured out cache settings for 1024kB (16x 64k x 8 chips with single 32k x 8 tag).

For now I'm finished with messing around with this board - time to put it into a case and enjoy it, which means no more tinkering for now as my AT cases are awful inaccessible little minitowers...

Feel free to post more info if anyone finds it, or questions I might be able to answer.