RE: U11 on a C64 board 250466

You hit it on the head, the processor doesn't stick around long enough to
drive high before going Hi-Z.  And ANY pullup that doesn't get warm takes
way to long to be valid for anything.

I found out that people counted on every bad thing the C64 did, the Currah
Speech Cartridge used the glitch IO/Sel lines to latch the R/W line after
what I would have called the end of the cycle.  I know this because I had
to put the glitches back in (c'mon an IO strobe not clock qualified ??) to
be compatible.  They bought me a nice dinner though afterwards.

-----Original Message-----
From: owner-cbm-hackers@musoftware.de
[mailto:owner-cbm-hackers@musoftware.de] On Behalf Of Gerrit Heitsch
Sent: Monday, April 23, 2012 3:47 PM
To: cbm-hackers@musoftware.de
Subject: Re: U11 on a C64 board 250466

On 04/23/2012 08:57 PM, Bil Herd wrote:
> 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.

No, it's the last board before that. It already used the 64Kx4 DRAMs but
still the 656x-VIC and the 24pin ROMs. A rather bad scan of the schematic
can be found here:


http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/c64/252278-1.g
if

You can see J3 there (somewhere between the RAM and ROM), but not U11.

This board has a part number of 250466.


> 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.

I was refering to the R/_W signal, as delivered from the CPU going high to
low very fast but taking its sweet time the other direction. And since VIC
doesn't drive R/_W high on its part of the cycle (TED does that, according
to the datasheet), my idea was that a VIC read cycle directly after a CPU
write cycle might be seen by the DRAM as another write cycle since R/_W is
still on its way up, especially if the DRAM used is a faster than normal
one. Maybe I should try an 80ns 41464 and see if that breaks things. 100ns
still work.


> 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.

The old C64 with the 28pin PLA did that only for the R/_W to the 2114
color RAM, the DRAM had its _WE directly tied to the R/_W from the CPU.
Maybe wasn't meant to be done that way but since it worked it wasn't
changed.

The newer C64 with the 64pin PLA (board 250469) no longer did that, they
route the _WE signal for the RAM through the PLA. The presense of U11 and
J3 suggests that someone thought to include something like this for the
250466 board already but it was never used.

The old PLA having _CAS routed through it also meant that CAS, as seen by
the RAM, will go high after RAS goes high at the end of the cycle.
The DRAM doesn't seem to care but my SRAM-adapter does, had to use RAS and
CAS or'ed as the SRAM _CS signal for it to work properly with the 55ns
SRAM I used.

  Gerrit


       Message was sent through the cbm-hackers mailing list

       Message was sent through the cbm-hackers mailing list