Anonymous Coward wrote:I would be careful with overclocking the EISA bus. It's meant to run at 8MHz, so if you're increasing the system bus speed to 50MHz without adjusting any dividers, then you're possibly running the EISA slots at 12.5MHz. This is likely not going to be an issue for most ISA cards, and possibly not EISA graphics boards, but I am skeptical that an EISA SCSI controller could tolerate that speed. On my SiS based EISA 486 boards the slots can either be set by a divider or run at a fixed 7.2MHz regardless of system bus speed. I suspect that 7.2MHz is based off the OSC crystal. If you have access to the System Pro user manual, maybe it explains how the bus clock is derived.
Another thing to keep in mind is your RAM. For 50MHz operation I would not consider anything rated less than 60ns.
I think you will be sorely disappointed by the RapidCAD chips under applications that do not use floating point operations. Integer performance is not much better than a stock 386 at the same clock speed. I used to have one, but I sold it because I didn't find it terribly exciting. I think you might have better luck sourcing 386DX to 486DX upgrade modules that have the dingus that taps into the i385 socket. That would let you stuff a 5x86-133 into a 386 socket.
Thanks for your last post. I couldn't put my finger on why the EISA SCSI controller wouldn't play ball... and this will be it. Everything seemed to run fine but the EISA SCSI controller so was why I used the onboard IDE controller. Since Compaq did not intend for the hardware to do anything i'm asking it to do... they had no need to include dividers in the hardware management software (bios) which means you're right, and that any changes made to the FSB will have a direct impact on the EISA bus.
The unfortunate thing about the RAM in this system is that it is proprietary... looking at the RAM card, it does not use standard SIMMS, and means i'm stuck with 80ns for the most part with only a couple 70ns parts I found from a different system. If I felt ambitious I would de-solder some of the DRAM IC's and solder on faster equivalents but there would be no guarantees and I would have to wait a while to replace it should anything go wrong, so 70 / 80ns we are capped.
🤣 Are you joking about the upgrade module!? I would never do that... besides, the two separate 486 CPU boards can load the two 5x86's so there is no need to put them in the 386 CPU board. 386 should remain a 386... if the legs can be stretched out like in this system where the buses are all 32-bit... then that is as far as a 386 system should be pushed, IMO. I know there is no integer benefit from running Rapidcad... though the FPU performance alone is what makes it. Whether or not I go for a dual Rapidcad system remains to be seen and will come down to cost... as the CPU's are not cheap! Also, there are no guarantees it would work, but I would love to see Doom/Quake fps bench scores running on a dual Rapidcad system under NT 3.1 or any other OS that supports it.
feipoa wrote:Can you rebench the system with the SXL2? Is the system entirely stable with the SXL2 at 50 MHz and a 50 MHz FSB? I've never heard of a 50 MHz FSB 386 being stable before. Does the system automatically set the RAM wait states?
When I get the chance, I will do yes. At 50MHz the system get's too hot so I don't keep it on for very long, I can't afford any parts to go on me this early, so was planning on doing all the 50MHz stuff last so that if a part blew, all other testing is already done. There are no options in software to change timings unfortunately. All I can do is change out the hardware OSC's, and mod the software to get the L1 cache enabled.
I have not had the system on for a few weeks nearly... too busy, but when I get the chance, I will run as many tests as I can.
feipoa wrote:Could you run Speedsys and Cachechk? […]
Show full quote
Could you run Speedsys and Cachechk?
Cachechk -d -t6
cachechk -w -d -t6
You may also need to create a little NAND circuit to properly enable the L1 cache on both SXL CPUs. It is a very easy mod. Let me know if/when you need the documentation on this.
Yes please with the documentation. Cachechk I haven't tried yet but will, speedsys I tried to load a number of times though it kept stalling at the memory check. Do you know why it would do this? I though it was because of the different type of non-SIMM RAM i'm using.
feipoa wrote:I noticed that you have one black-top FPU and one grey-top. I heard that the older grey-tops are a little faster per-clock than the black-tops. This is evident using the Landmark benchmark. Some of the newer grey-tops may be slower too. Reference: user Anonymous Coward.
There may be another Cyrix kicking about, I had never heard about this before so will need to investigate more. Anonymous Coward... could you point in the right direction? Thanks
feipoa wrote:Do you have any applications which make use of dual CPUs?
It looks like in the future you will attempt dual AMD Am5x86 CPUs. 3x50 or 4x40? But you are still restricted to Windows NT 3.1? Are there any dual-486 systems which can use NT 4.0 with dual processor support?
Do you plan to dual boot Win95 and WinNT 3.1?
I'm not sure of any individual applications, my understanding of the system is that dual CPU's are run under an OS that supports it and when the primary CPU load / usage runs high as seen in task manager, the OS re-directs new instructions / operations to the secondary CPU. So really it is load dependent and is a question of requirements... most of the time I suspect the secondary CPU may even be redundant unless the system encounters high load situations. You gotta remember that this was a file server back in the day and dealt with LAN traffic from multiple sources and stored information on a number of hard drives, pioneering RAID technology as we know it today. A lot of this is un-chartered territory for me and i'll be learning as I go, and willing to share of course. I just hope that my assertions from what I've already learned are right and that the OS will act like an umbrella for any programs running under it.
Can't comment yet about the 486 part of the project (hardware/software) other than the system will facilitate 2 x 486, I've not done any research as to what else can go and what can't... I'm not very 486 oriented at the best of times, though the more advice / guidance I can receive on the 486 part of things, the better.
Regards to the dual boot, I don't see why not... the only thing with 95 is, there will not be any dual CPU support... but for this you would just boot into 3.1.