🚀 go-pugleaf

In article <900302202...@en.ecn.purdue.edu> zaw...@EN.ECN.PURDUE.EDU
(Paul J Zawada) writes:

>> Not strictly true.  A common modification on the old IBM PCs is
>> to replace the 8088 with a NEC V-20 or similar ship and the crystal
>> with a faster one.  Thus a 4.77MHz machine might clock up to 8Mhz or
>> more instead.  This modification costs about $20.  

> Well... This doesn't always completely work....  Sure, you can replace an
> existing processor and crystal with a faster combination, but all you are
> doing is increasing the speed of the bus clock, which can cause more
> problems.  If the rest of the circuitry (logic, memory, etc.) in the computer
> can't handle the faster speed, the processor will end up sitting
> idle waiting on the rest of the computer.  (At the very least...)

Well, I agree with the thrust of what Paul is saying, but...

There seems to be a general misunderstanding extant that the memory chips
somehow tell the processor what speed they are, and can slow down the CPU.
** THIS IS NOT TRUE **

The CPU puts the address up, then some time later that only depends on the
CPU's internal timing it samples the data lines.  IF THE MEMORY WAS TOO SLOW
AND DIDN'T GET THE DATA UP IN TIME, TOUGH NOOGIES, *NOBODY NOTICES*!!!

That means you get *Bad Data* and your application crashes or prints absurd
numbers at you.


Sooo...  The CPU does *NOT* "sit idle waiting on the rest of the computer".
It really does go faster!  And produces nonsense data or crashes out.

Nuf Sed?

-- 
Sig     DS.L    ('ZBen')       ; Ben Cranston <zb...@Trantor.UMD.EDU>
* Network Infrastructures Group, Computer Science Center
* University of Maryland at College Park
* of Ulm

Ben Cranston writes:


There seems to be a general misunderstanding extant that the memory chips
somehow tell the processor what speed they are, and can slow down the CPU.
** THIS IS NOT TRUE **

The CPU puts the address up, then some time later that only depends on the
CPU's internal timing it samples the data lines.  IF THE MEMORY WAS TOO SLOW
AND DIDN'T GET THE DATA UP IN TIME, TOUGH NOOGIES, *NOBODY NOTICES*!!!

That means you get *Bad Data* and your application crashes or prints absurd
numbers at you.

--------------------

Actually this is not strictly true either.  A lot depends on the
architecture.  For example, the 68000 architecture requires that the
memory acknowledge the access request before the operation continues.
Alternatively, many processors have a ``wait-state'' line where the
memory can tell the processor to execute wait states until the memory
is ready.  Thus a memory system can syncronize with the processor by
slowing it down.

--
Fred Gilham    gil...@csl.sri.com 
"The culture of any period is a mixture of that which docilely caters
to passing whims and fancies and that which transcends these things --
and may also pass judgement on them."  -- Stanislaw Lem

In article <GILHAM.90...@cassius.csl.sri.com> gil...@csl.sri.com (Fred Gilham) writes:
>>
>>Ben Cranston writes:
>>
>>There seems to be a general misunderstanding extant that the memory chips
>>somehow tell the processor what speed they are, and can slow down the CPU.
>>** THIS IS NOT TRUE **
>
>Actually this is not strictly true either.  A lot depends on the
>architecture.  For example, the 68000 architecture requires that the
>memory acknowledge the access request before the operation continues.
>Alternatively, many processors have a ``wait-state'' line where the
>memory can tell the processor to execute wait states until the memory
>is ready.  Thus a memory system can syncronize with the processor by
>slowing it down.
>
	The key here is "memory system".  In general, in order to have
either the DTACK setup used by the M68000 or the wait-state setup used
elsewhere work properly, something external to both the memory and the
processor determines the amount of time between a request for data from
the processor and the response of the memory.  This is usually a dip
switch or a decoding PAL and some one-shots.  The memory (in my experience,
anyway) does not itself know how fast it is (exp. since this is often
determined by empirical testing and not by design -- the fastest chips in
the lot are 80ns, some of the rest are 100ns, and the ones that don't make
that speed in testing get print "-120" printed at the end of their number).

Russell G. Brown - rbr...@cs.cornell.edu - Cornell University Computer Science

rbr...@elli.cs.cornell.edu writes:
	The key here is "memory system".... The memory (in my experience,
anyway) does not itself know how fast it is....
----------

This is correct.  I didn't read the original article carefully enough.



--
Fred Gilham    gil...@csl.sri.com 
"The culture of any period is a mixture of that which docilely caters
to passing whims and fancies and that which transcends these things --
and may also pass judgement on them."  -- Stanislaw Lem

In a fit of anal-retentive self-righteousness I wrote:

> The CPU puts the address up, then some time later that only depends on the
> CPU's internal timing it samples the data lines.  IF THE MEMORY WAS TOO SLOW
> AND DIDN'T GET THE DATA UP IN TIME, TOUGH NOOGIES, *NOBODY NOTICES*!!!

In article <GILHAM.90...@cassius.csl.sri.com> gil...@csl.sri.com
(Fred Gilham) writes:

> Actually this is not strictly true either.  A lot depends on the
> architecture.  For example, the 68000 architecture requires that the
> memory acknowledge the access request before the operation continues.
> Alternatively, many processors have a ``wait-state'' line where the
> memory can tell the processor to execute wait states until the memory
> is ready.  Thus a memory system can syncronize with the processor by
> slowing it down.

This is quite true, however, it will be the memory controller that does one
of these two things, not the memory chips themselves.  In all the personal
computers (i.e. those in which uneducated users will be buying and inserting
memory chips of different speeds) there is no separate memory controller.
The memory access logic is integrated with the processor on the CPU card.

There may well be memory cards where a dip switch or other configuration
setting can tell the memory to ask for additional time, but in any case it
will definitely be more than just putting in the faster chips.  There is
no way for the memory controller to know how fast the chips are unless you
tell it somehow.

Just replacing 150ns chips with 70ns chips will not make your computer run
any faster...
-- 
Sig     DS.L    ('ZBen')       ; Ben Cranston <zb...@Trantor.UMD.EDU>
* Network Infrastructures Group, Computer Science Center
* University of Maryland at College Park
* of Ulm

>There seems to be a general misunderstanding extant that the memory chips
>somehow tell the processor what speed they are, and can slow down the CPU.
>** THIS IS NOT TRUE **
>
>The CPU puts the address up, then some time later that only depends on the
>CPU's internal timing it samples the data lines.  IF THE MEMORY WAS TOO SLOW
>AND DIDN'T GET THE DATA UP IN TIME, TOUGH NOOGIES, *NOBODY NOTICES*!!!

some memory systems (I can't speak for specific memory CHIPS) have programmable
wait states that hold off the processor (or any other bus master) after they
get a read or write request.  this is to allow mixed-speed memory in the
same system, i.e. a memory card could have a gaurenteed access time of
100nS and another cheapie that you bought mail-order could have 200nS, and
if the bus, processor and memory cards support the notion of wait states,
accesses to the two cards will provide the correct results, although the
latter card will take longer to provide the data.  this happens most often
in 386 systems that use a mix of 32-bit and 16-bit memory cards; usually the
16-bit cards have a multiple wait-state generator that is used to allow the
card's operation on a (faster) bus (and to take into account the differences
between 16-bit and 32-bit accesses).

mike bender
sun