Test results from Anand’s Tech Page, AlternativeCPU.com and our own initial testing seems to indicate that the R581A cannot run at 100MHz, and that users will have to wait for the Super 7 boards being readied for release. After some additional testing, however, it is possible that the problem is not with the board, but with the CPUs themselves. This was hinted at by Anand when he reported his initial results, but we took things one step further.
We decided to perform some very exhaustive tests, which took over 6 hours of continuous work. These tests utilized two R581A boards, an AGP and PCI video card, 6 different brand/configurations of memory and 7 different CPUs. In addition, we used a hardware diagnostic card called a P.H.D. Plus, which ‘takes over’ control of the motherboard after POST has completed. It does use the CPU, system memory and system BIOS to boot, but actually performs circuit level tests on the motherboard.
Each combination of processor and memory was tried twice – once on each motherboard – to verify results. Every possible BIOS setting was tested, including combinations of settings. We believe that we tried them all, but it is possible that some were missed.
Our first order of business was to make sure that we could actually complete POST at 100MHz. We tested with the following processors: Intel P54C 150MHz (boxed), Intel P55C 166MHz (boxed), AMD K6-233, AMD K6-200, Cyrix 6x86L PR200, Cyrix 6x86MX PR200 and Cyrix 6x86MX PR233. Of these, only the Cyrix PR233 and AMD K6-200 would attempt to initialize Windows. The Intel P54C and Cyrix 6x86L would not even show the video splash screen. The other processors would start to POST, but would hang right about where the PCI devices were being detected.
We settled upon the Cyrix PR233 to perform the memory tests, as that processor seemed to work the best of all. We tried PC66 SDRAM from AMC, Mactrotron, Corsair, Crucial Technology and M Tech (the ones designed for the R534). We also used 50ns EDO from Crucial Technology. Both the AMC and Mactrotron SDRAM had problems with booting, so we eliminated those. The Corsair and M Tech SDRAM worked fairly well, but the Crucial Technology SDRAM seemed to work best, so we decided to use that for all subsequent testing. In addition, the Crucial Technology 50ns EDO worked just about as well as the SDRAM so we decided to use that as well. We had heard that John Howland of Specialty Tech had been able to get the 100MHz speed to run with this EDO memory by disabling the L2 cache, which helped our decision to use this too.
Now we had the most stable set of components (AGP vs. PCI video card did not seem to make a difference at all), so we began to run our tests by changing each BIOS setting one at a time and attempting to boot into Windows. For the most part, changing these settings made almost no difference, except to make things worse in some cases. After many hours of testing, we were just about ready to come to the conclusion that the 100MHz bus was just not working on this board. We also tested every voltage possible for the CPU from 2.3v (no boot) to 3.5v, but again there was no difference.
As a last resort, we put the EDO memory on and disabled L2 cache. Just as John had indicated, the board booted and ran just fine. Curious, we then enabled the L2 cache, and disabled L1 cache. This allowed the board to boot, but it ended up crashing. Upon reboot, we decided to try one more time with both L1 and L2 cache enabled. The experience here caused us to do some further testing, and has persuaded us that the 100MHz bus does actually work, and the limitation is not with the board or chipset at all – or at least that is not the major issue!
After the crash with EDO and L1 cache disabled, we rebooted, as indicated above, with L1 and L2 cache enabled. Upon initialization, Windows indicated that the last session was not shutdown properly and asked if we wanted to boot into ‘Safe Mode’. We just overrode the recommendation and booted straight into Normal mode. Surprisingly, we received the message that we should run ScanDisk to verify our files. We hit enter – and ScanDisk ran completely through it’s process! It then proceeded to boot into Windows, and up popped a screen asking us to install the drivers for the PCI Card device!! Eager to see if this was actually going to work, we hit ‘Cancel’, whereupon a second window popped up to install drivers for a second device. Two more times we cancelled out of the driver installation. After the last ‘Cancel’, the system hung.At this point, flush with excitement, we rebooted the machine (and Ctrl-Alt-Delete worked, unlike previous hangs!), and went through exactly the same scenario, including the hang at the same place. This occured 3 more times (total of 5). In order to determine if this was another 100MHz ‘glitch’ we reset the jumpers to 90MHz and tried again – same results. We set the jumpers down to 66MHz – same results. It appeared that either the registry/files were corrupt or the BIOS had some screwy setting that was causing the hang. In desperation, we cleared the CMOS and tried again. Unfortunately, we never had that much success again. Either some BIOS setting was not written down correctly, or it was all a fluke (5 times in a row!). We had gone into the BIOS between boots to verify that the L1 and L2 cache were enabled, and that memory timings were set to ‘normal’.
After having gone that far, we were not willing to just give up and concede that the 100MHz bus wasn’t working. At this point we put the P.H.D. card on. Since the Cyrix processor would complete POST, we were able to get the diagnostic card up and running – to successful completion! There were no failures at all, including all DMA Controller, DMA Transfer, RAM Tests (including integrity and refresh), System bus, etc. We ran this card for over 30 minutes on the system running at the 100MHz bus without any failures at all!!
Now we were really curious. During the initial tests to determine which processor to use, we had tried the P54C 150MHz CPU at both 1.5 x 100MHz and 2.0 x 100MHz. Neither setting would produce even the video splash screen. Just for grins, we decided to try it at 1.5 x 90MHz. At this setting, the board booted… then hung during POST at exactly the same spot that the P55C 166MHz did at 100MHz! Just a little thinking made us decide that the problems at 100MHz are not just memory and cache speed, but inherent CPU limitations as well. In fact, the CPU may be the real culprit.
Based upon the findings above, we have come to the following conclusions…
- Since the P.H.D. Plus detected no circuit level errors at 100MHz, it appears that the chipset will work at this speed, and the board actually does function at that level.
- Changing memory had only a marginal effect, and though we did not use any PC100 SDRAM, others have indicated that it made no difference in their tests, so we believe that the memory is not the real issue
- The cache chips are 6ns chips, however the Tag chip is 8ns. This may be a part of the problem, but we suspect it is not the entire problem, nor even the most significant.
- The fact that the P54C 150MHz had *exactly* the same problem at 90MHz as other processors had at 100MHz, this appears to us to be the real issue. Since the 90MHz speed has been verified to work by both Anand and Bryan, the problem could *not* have been caused by a poor implementation of 90MHz, but rather that the processor could not function at that bus speed!
Our final analysis, though possibly flawed, is that the reason the 100MHz bus appears not to work on the R581A is because most of today’s processors simply cannot handle the timings at 100MHz. The Cyrix processor was designed to run at higher bus frequencies than either the AMD or Intel processors, which causes us to conclude that this is the reason that it was able to get closest to actually working. Disabling the L2 cache does allow the board to function, however the slower data transfers (wait states) may be working in the CPUs favor when this happens, so that data is not being ‘lost’ when a clock signal is missed by the processor. One exception to the above findings was that the K6-200 seemed to be able to handle the bus speeds almost as well as the Cyrix PR233. It is possible that recent manufacturing lines of the K6-233 are not quite up to par with their ‘original’ lines.
We would welcome information from anyone who might have insight into this situation, or who might be able to verify or dispute our findings. Until we have other information, our conclusion is that the 100MHz bus setting does indeed work on the R581A at the chipset level. The Tag chip may be preventing the Cyrix PR233 and K6-200 from fully initializing Windows, but that would be a relatively simple component for M Tech to replace for future revisions. The bigger issue here, of course, is that our findings seem to agree with Tom Pabst’s initial 100MHz review which indicated that Intel processors could not operate at that speed. He was unable to test the Cyrix processors, and was obviously using an older K6 processor as well. It may well turn out that those wanting a 100MHz system will be stuck with Cyrix until AMD gets their act together.
Be the first to discuss this article!