RE: U11 on a C64 board 250466

I am not sure exactly what that model is, I couldn't find a schematic on
Zimmers for it, but I will assume that it is the C-64C or what we used to
call the C-64CR which we took to mean cost reduced internally, the
half-height board.

If that is the one you are talking about then I can tell some of the
background of where CBM was with regard to DRAMS and the thought processes
that went along with it.  The C64C was done by an engineer out of the
Tokyo office by the name of A. Katayama. He also liaised on the TED and
C128 series and so was "in the loop" when it came to a system designed
around correct DRAM timings from the start (TED) and what could be done to
make the VIC chip live better with DRAMs (C128).

So with regards to the question itself, I doubt that there would be
anything in the logic to accommodate a part that pushes a margin such as
too fast; it would happen often in the numbers CBM produced so it wouldn't
be anyway a trend or batch would necessitate a change for a while, a logic
change wouldn't accommodate a mixed batch (1 out of 8, 7 out of 8) which
if it worked in those cases we would just make the change for as the
better logic, There wasn't any methodology for "if this fails then rev the
board", especially since the bigger source of issue was still the VIC
chip. If something failed it was faster to recycle than scrap (Christmas
time) and cheaper to limit repairs what could be done in a few minutes.

So with all of that said, we assumed that an unknown state propagated in
0ns, actually -.5ns once you fudged for pin capacitance and layout
differences.  This assumes that the engineer is not just thinking in terms
of 1's and 0's but also the intermediate unknown state of X.  The best
designs assume that the moment X hits one of the inputs that the outputs
may have a certain amount of X in them.  So in theory we wouldn't have
something that was too fast for the design, we expected the worst already
in that direction. It was also common place for a vendor to ship us all
parts of speed or faster if we let them for them to make their quotas, it
cost them more and we didn't care.

So without seeing the schematic I would assume it was multiplexer logic to
accommodate different control or MA line configurations.

With regard to a gated R/W, that is a good observation that the TED had
this feature and that it was desired.  My memory is that in the C64 we
used to wrap the signal back through the PLA to create a pseudo-latched
version.  It all comes down to the fact that the DRAMs were based on RAS
and the processor on Phi.  We were at the limit on making RAS look more
like Phi due to things like RAS Precharge Time and other setup and hold
times.  Whereas address lines were latched, the /WE on a DRAM is
asynchronous to the point where you could start a cycle as a read and then
flip around and write without changing the addresses or strobes, I.E. a
fast Read-Modify-Write.  There were times when you could "lie" to the IC's
but the /WE has to be kept honest.

We also learned what DRAMS did when abused to some extent, one of the IC
guys, Dave Andreas, had been a memory designer and once in response to a
question he related how doing what I had asked would cause internal
collisions in the DRAM as buffers would fight each other with the array in
the middle.  We also used to test for nearest neighbor bleed and
substrate/ground poisoning as layout and noise were as prevalent as logic.

Bil Herd
-----Original Message-----
From: owner-cbm-hackers@musoftware.de
[mailto:owner-cbm-hackers@musoftware.de] On Behalf Of Gerrit Heitsch
Sent: Saturday, April 07, 2012 1:23 PM
To: cbm-hackers@musoftware.de
Subject: U11 on a C64 board 250466

Hello,

this was already discussed on the forum64.de, but since not everyone is
reading that, I'll post it here too.

If you take a look at a C64 board with the assy number 250466 (aka 'B3'),
you'll notice that it uses 64Kx4 DRAMs and has an unused spot named U11
(plus C27 for the decoupling cap) next to the DRAMs. There is also J3 next
to it.

I always wondered what this was for and finally got around to check it out
and map the signals. Another forum member determined that the pinout
matches a 74LS139. J3 determines whether R/_W from the CPU is directly
connected to the RAMs or routed through the 74LS139.

The other signal supplied to the decoder (enable is tied to GND) is PHI0
and the ouput used will only go LOW if PHI0 is HIGH and R/_W is LOW,
effectivly making sure that only the CPU can write to the RAM and a VIC
read cycle  will always be a read cycle even if R/_W from the CPU takes a
bit longer to go HIGH again (which it does).

I did put a 74LS139 at U11 (if you want to do it, you need to tie pin
13-15 to GND, otherwise they are floating), added C27 and cut J3, the
board still runs as if nothing changed.

To me it suggests the board designer suspected that some RAMs might be too
fast and interpret a VIC read cycle following a CPU write cycle as another
write cycle and wanted to make sure this cannot happen. Most RAMs don't
seem to need it as I haven't seen a 250466 with U11 populated and
repairing one with faster RAMs (100ns) still doesn't cause problems.

This circuit does remind me of the GATE IN signal on the 8501 CPU in the
264 series.

The later C64 boards (250469, using the 64pin PLA) no longer connect R/_W
from the CPU directly to the DRAMs, they run it through the PLA, making me
assume that this circuit (or similiar) was integrated there.

Anyone here ever run into 'new RAM too fast' problems with a C64 board?

  Gerrit


       Message was sent through the cbm-hackers mailing list

       Message was sent through the cbm-hackers mailing list