Xref: utzoo comp.sys.ibm.pc.hardware:3618 comp.sys.ibm.pc.misc:4418 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!zaphod.mps.ohio-state.edu!samsung!crackers!m2c!umvlsi!umaecs!daly From: daly@ecs.umass.edu (Bryon Daly, ECE dept, UMass, Amherst) Newsgroups: comp.sys.ibm.pc.hardware,comp.sys.ibm.pc.misc Subject: Re: DTK Motherboards Message-ID: <11707.275dac3e@ecs.umass.edu> Date: 6 Dec 90 02:26:06 GMT References: <5714@crash.cts.com> <1990Nov20.180552.3474@cec1.wustl.edu> <1990Dec5.015847.21620@watserv1.waterloo.edu> Lines: 108 In article <1990Dec5.015847.21620@watserv1.waterloo.edu>, ssingh@watserv1.waterloo.edu (The Sanj - ISman (iceman)) writes: > I have a question on DTK 386sx boards. I have a PPM 1630. I bought it > in August of last year. I asked for 80 nanosecond RAMs. The board > is supposed to take 120 nanosecond RAMs. I was hoping for zero-wait-states. Sadly, I don't think 80ns DRAMs could give you zero wait states, anyway. If your 386SX is running at 16MHz, that means 16 million cycles per second, or 62.5 ns per cycle. If the machine is capable of generating an access to memory every clock cycle --- (I imagine that a NOP only takes one cycle, so a series of NOP's would generate a series of reads to memory for the next instruction, one read per clock [Note this ignores such concerns a pipelining and word size]) --- then it would want to read memory once every 62.5 ns. If the DRAM speed rating is 80 ns, they could not keep up with this peek access rate. If the CPU tries to access memory, but the RAM is not fast enough to respond before the end of the cycle, a wait state must be added (maybe more than one if the CPU is fast enough and the RAM slow enough.) to the CPU cycles to give the memory a chance to catch up. Note that the wait states are not in the form of an executed instruction such as a NOP; they occur at the deeper, hardware level. On the Intel microprocessor I worked with (8085), there was a wait line on the chip itself ( I think the 8086 is the same). If, after the CPU tries to access memory, the wait line is asserted (presumably by the motherboard memory logic), the CPU will just sit and idle away clock cycles (ie; wait) until the wait line is unasserted, (and thus the data is ready for the CPU to read.) Note also, I don't think that the DRAMS themselves have any capability of saying that they need more time; too slow DRAMS in a motherboard expecting faster ones will probably just not function correctly. Thus it is up to the motherboard to decide when wait states are needed. The motherboard of my 12MHz 286 has a jumper on it which decides how many wait states the CPU will run at. I once placed the jumper in the wrong setting and saw my Norton SI drop from 13.7 to 11.9 or so. > > When I saw that the Landmark rating was only 16 Mhz (not 18 or so), I started > asking questions. > > I was told that the motherboard couldn't handle it. > > Then I was told that I could get zero-wait-states by changing to the > latest BIOS. Supposedly DTK has only changed the BIOS to allow for > zero-wait-states. I've never heard of BIOS deciding on a system's wait states; but that may be the newest thing. Still, check your motherboard for undocumented jumpers (or even documented ones: did you check out the system's manual (for the motherboard) completely? Another thought: talk to DTK themselves, instead of the people you got your system from - they won't know as much about the motherboard (and wait states) as DTK itself would. > > Which brings me to the next question. I looked in Que's "Computer User's > Dictionary" (highly recommended) for the definition of wait state. It > said that these were "programmed into the system" to allow slower memory > to keep up with the CPU. "wired into the system" would probably be a better term > > Presumably this means programmed into the BIOS. But it wouldn't work to > simply insert NOP (do nothing) instructions in the BIOS because the CPU > would be trying to execute the NOP instrutions themselves without any > slowdown. Finally, I came to the conjecture that since I have heard of > the idea of ROM shadowing on video cards to copy video BIOS into RAM for > faster execution, probably how wait states are implemented is that > using ROM chips causes enough of a slowdown to prevent timing problems. > This would cohere well with the idea of BIOS-shadowing offered by many > vendors of PC-compatibles. ROMS are just plain ol' slower than RAMS (for reasons I have yet to discover) The benefit they offer is permanent storage for the BIOS routines (we wouldn't want to load them off a floppy, would we?, especially when the boot up sequence that reads the disk initially is stored in ROM.) The BIOS routines are sometimes copied into RAM, which is faster, to increase the performance of the system. > > First, is my reasoning correct? > > Second, would using the latest version of DTK BIOS on a PPM 1630 with > 80 nanosecond RAMS increase throughput? Does the latest version of > DTK BIOS allow BIOS shadowing? Does anyone have benchmarks available? > > Lastly, what about operating systems like UNIX that bypass the BIOS > entirely, since all operations would be done in RAM, does this mean that > running UNIX would automatically yield better performance? If so, what > about timing problems, if I had used 120 ns. RAMs? Programs not using the BIOS might run faster (since they don't rely on the slow ROM BIOS routines), but actually now, many programs avoid using the BIOS as a matter of course. I.e.: the Turbo C routines for displaying text and graphics default to NOT using the BIOS (in other words, they use direct access to the hardware to perform tasks). > > I know this is a barrage of questions, but I need help in this rather > important decision, and opinions, as you know are often contradictory. > > Any assistance would be appreciated. > > Ice. > Well, I've said my piece. If any hardware guru's out there notice any flaring dicrepencies (or outright untruths) please do correct me. Good Luck, Bryon Daly, ECE grad student at-large daly@ecs.umass.edu --- DISCLAIMER: I tried to speak for my employers, but they told me to shut up!