RE: C128 'VIC tower' mod board

Thanks everyone. I had not heard of or seen this mod board before. It seems they used it on some early machines. It had nothing to do with the black screen problem, that was a duff MMU.  Rather interesting symptoms, all address lines were pulled high, but data lines were toggling. I had already pulled the ROMs and the Z80/8502 and MMU seemed to be the only chips that touched all 16 address lines. The Z80 seemed to be giving up the bus as it should so I swapped the MMU and it came back to life. 

The data pins on the MMU appear to be only inputs so I guess the 8502 was reading garbage since the address lines were stuck high and outputting garbage on the data bus.

Thanks for your help on what the mod board did. I'm going to do a video on this fix so I can show off the mod at the same time.

Jeff Birt

-----Original Message-----
From: Francesco Messineo <francesco.messineo_at_gmail.com> 
Sent: Thursday, July 9, 2020 10:53 AM
To: cbm-hackers_at_musoftware.de
Subject: Re: C128 'VIC tower' mod board

On Thu, Jul 9, 2020 at 5:48 PM Gerrit Heitsch <gerrit_at_laosinh.s.bawue.de> wrote:
>
> On 7/9/20 5:26 PM, Francesco Messineo wrote:
> > On Thu, Jul 9, 2020 at 5:15 PM Gerrit Heitsch <gerrit_at_laosinh.s.bawue.de> wrote:
> >>
> >> On 7/9/20 3:44 PM, Jeffrey Birt wrote:
> >>> Hi all,
> >>>
> >>> I pulled apart a C128 yesterday that someone sent in with a black 
> >>> screen complaint. Upon investigating I found a small PCB with a 
> >>> 74LS74 perched over top of U29 inside the VIC-2 RF shield box. I 
> >>> toned out how it was wired and discovered it was intercepting 
> >>> /CAS. I posted this on a FB group last night and someone said, 
> >>> ‘that looks like the VIC tower on schematic sheet 310378-4. Sure enough he was correct.
> >>>
> >>> http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/c128/3
> >>> 10378-4-left.gif
> >>
> >> According to the schematics it's intercepting /RAS though.
> >>
> >> It would be interesting to watch /RAS before and after the extra 
> >> circuit on the scope to see what kind of difference it makes.
> >
> > That flip flop is doing basically two things:
> > 1) it lowers the Q  output (/RAS to the RAMs) as soon (with a small
> > delay) as the input /RAS goes low, the "original" /RAS is connected 
> > to the async reset of the FF
> > 2) it raises the /RAS to the RAM at the next rising edge of the /DOT 
> > (I assume it's a dot clock negated?) input (this goes into the FF 
> > clock input).
>
> It cannot raise the output until /RAS on the input is HIGH again. Only 
> then will the rising edge of /DOT do anything.

yes I stand corrected. The rising edge will happen at the next rising /DOT AFTER the "input" /RAS has risen too.

>
>
> > It was probably needed to re-align the rising edge of the /RAS 
> > signal or to lengthen/shorten its duration.
>
> This should lengthen /RAS being low.

yes, it lengthens and re-align the rising edge of /RAS to a rising edge of /DOT, so probably the edge align was the real necessity.

Frank