Re: Pot on Language card: what for?

[mjmahon@aol.com (Michael J. Mahon)]

David Empson wrote:

Hi, David--it's always good to hear from you.

>Michael J. Mahon <mjmahon@aol.com> wrote:
>
>> Linards Ticmanis asked:
>> 
>> >another stupid question. I have two II+ language cards, the standalone
>> >versions that do their own refresh and that don't need a cable to one of
>> >the RAM chips on the II+ motherboard.
>> >
>> >Those cards have one pot each on the PCB. What does this pot do? Adjust
>> >refresh cycle time maybe? Which way would you have to turn it for slower
>> >refresh, if that is the case?
>> 
>> I would hope not!  The least I would expect of on-card generated refresh
>> is that it is synchronous with the Apple bus, so it could refresh in the
>> video access time slot, and always appear ready to the processor.
>
>The card could be using the bus clock to synchronize the refresh cycles
>so that they occur during the "video" portion of the CPU cycle, but
>still using an on-card timer to control the refresh rate.

That synchronization will take a couple of flipflops to do reliably.  It's
almost always easier and better to stay synchronous.  Use the 1MHz
Phi1 or Phi2 to count and clock the accesses.  These "video slots" are
guaranteed not to interfere with the processor, and the video never
accesses card memory.

>A "normal" DRAM refresh selects an entire row, which refreshes several
>locations at the same time.  The refresh circuit needs to count through
>all of the available columns and get back to the first column in time to
>satisfy the refresh timeout of the DRAM.  (Or is it the other way
>around?  No matter, the explanation works either way.)

Yes, you got it right.  Late refresh causes increasing DRAM unreliability.
The only reliable thing to do is at least meet the chips' refresh spec.

>This is typically in the order of 2 milliseconds, so with 128 columns
>and 128 rows (16Kbit), a refresh access cycle is required about once
>every 16 microseconds.
>
>Using an RC circuit to implement a delay for this might have saved
>adding another chip to the card.

I doubt it--see above.  A hex counter is also one chip.  That could
easily pre-scale the 1MHz clock by 16:1, if desired.  Again, note
that the bus is available at 1MHz without any processor interference,
so little (except some power) would be saved by going slower.

>The Apple II's innovative use of the video access cycles means that it
>can get away without any explicit refresh cycles.

Hmmm.  I would have said that the Apple II's innovative design uses
the video access cycles to transparently refresh the memory without
any interference with the processor.

>                         The video accesses
>are considerably faster than the requirements for refreshing DRAM.

Actually not.  The refresh "revisitation rate" is set by the vertical scan as
well as the horizontal.  When you see the "venetian blind" effect when
a hi-res picture loads, you are seeing the number of times within a field
that all rows are refreshed (128 consecutive bytes accessed).  Since
the video field is about 16ms long, it's necessary to go non-linear to get
the "revisitation rate" up to spec.

>Having said all that, I'm starting to doubt it myself.  It would be
>easier to use Phi0 or Phi1 as a clock for the refresh counter.
>
>Some other possible explanations for the pot:
>
>- A voltage adjustment for fine tuning a power supply input to RAM chips
>(older DRAM typically requires at least two supply voltages, +5V and
>-12V if I remember right).

Wow--such a designer should be shot.  The Language card was made
with standard 4116s.  By the time it came out 16K DRAMs were the
sweet spot, and standardization flourished.  ;-)

>- A delay adjustment to precisely control access cycle timing (e.g. to
>ensure that the data bus driver is enabled after the DRAM is outputting
>valid data).

Again, lock and load!  I'm sure you agree that this would be a most
unfortunate design.  The appropriate delay for any well-designed card
would be quite predictable, and would be fixed.

>- A delay adjustment or power supply threshold to ensure that the card
>operates predictably at startup (seems less likely - RESET would serve
>for this).

Indeed.

David, I think we are in agreement that this is either not a refresh adjustment
or it is not a very well-designed card, or both.  ;-)

-michael

 Email:  mjmahon@aol.com
 Home page:  http://members.aol.com/MJMahon/