Re: U11 on a C64 board 250466

From: Gerrit Heitsch <gerrit_at_laosinh.s.bawue.de>
Date: Mon, 23 Apr 2012 21:46:59 +0200
Message-ID: <4F95B1B3.2080002@laosinh.s.bawue.de>
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.gif

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
Received on 2012-04-23 20:00:30

Archive generated by hypermail 2.2.0.