• Please review our updated Terms and Rules here

8032-SK Restoration

Had a niggle that they aren't being refreshed properly with PETTESTER working so fast that problems with refresh aren't revealed and just noticed that half of UD3 isn't clocking which means the refresh address lines aren't operating !

The DRAM test system I made for my PET enables checking of the refresh functions, both of the hardware support circuitry and the internal DRAM IC refresh system. This occurs because of the long time frame of loading the entire memory with byte patterns and later inspecting the contents of it with the TIM. It is dead easy to see defective or abnormal memory memory locations. Also it checks stability of the memory locations with alterations to values in adjacent cells. It is interesting, the number of ways in which these internally very complex DRAM IC's can fail. Loading data and quickly retrieving it may seem ok, but the data can fade with a defect in the refresh. The firmware in this project can help you test the DRAM, without the need for the hardware adapter, provided BASIC is running, if not, needs the adapter.

 
Wow, thats a comprehensive beast. Would have found my fault in an instant I think.

Just waiting for the replacement to turn up as I don't have one in my spare bits.
 
Gary,

You've given me an idea to include in PETTESTER Version 5...

Dave

A refresh function test certainly would be a good mod. I thought I had put a long enough loop in when I did a simple mod, but the data sheet for the 2114s says a refresh of 2ms which is quite long really and my simple NOP loop obviously wasn't long enough.

New 74LS393 fitted and machine now fully working

So that was a 6545 CRT controller one DRAM, SRAM, 74S04 a 74LS157 and a 74LS393. Probably all when the mains filter blew when the original owner decided to power it up.
Just noticed, it was last june when I got this machine !

Just got another museum 8032-SK and a vanilla 8032 plus my Hazeltine to focus on now
Then the ACT Sirius 1 and I must get round to powering up the pdp11/73
 
And to finish this thread off, the second SK is also repaired.

It was showing random data during the zero page test, each of the first and second 256 bytes would change randomly even though the data and address bus's were working when accessing the ROM.

It turned out to be eight failed DRAMs, only sign on the scope was every long DI/DO signals

PETEST, NOP and a Tynemouth RAM/ROM are invaluable tools.
 
Ahhhhhhhhhhhhhh

Such is the delight of vintage machines.

SK number two which was working has suddenly developed artifacts on the screen. When you run PETTEST every test passes but extra characters are on the screen and when the text for the memory test is written, characters appear lower down and off to the right and one of those changes with the countdown.

Looks like part of the video memory that has the text is responding to the CRT memory read and putting data on the ESD bus when its not meant to be addressed. So, if the memory read by PETEST is good, then the MUX's must be allowing the BA addresses to get through to select the SRAM's and they must be responding ok, which suggests that the TA addresses are either wrong or the MUX's are making a mess of them.

So CRT or MUX ?
 
It must be coming from the SRAM given that one of the mirrored characters changes with the countdown but memory checks fine in PETTEST

And it increments from $20 rather than $00 but cant quite work it out at the moment.
 
It was a fairly recent Commodore PET repair from what I remember. I'll have a look shortly.

It was fairly close to the end of the thread I think.

Dave
 
Last edited:
It was definitely a low nibble video RAM that was changed to cure the problem I seem to remember. It is annoying that the videos have gone.

Even RAM is the first column (counting from 0). Even, odd, even, odd, ...

Dave
 
Cheers, wasn't sure if columns were numbers 0,1,2 or 1,2,3,4 :)

It looks like a SRAM 'artifact' somehow, strange that the test doesn't complain.
 
Shame I dont have time today to swap it, got to drive to Luton to see son #3. Helensburgh last weekend for #2, Luton this

Mind you, if you thought the inside of the case was dirty of SK number 1, i've just dismantled the keyboard. Should have taken a picture but it was so filthy it needed immediate action !
 
Of course, my PETTESTER is not that good here.

The test patterns I use (repeating sequences of $00 to $FF) are not good at finding addressing faults.

Plus, it writes the pattern sequences to all potential 2K of video RAM, but only checks the first 1K. I had to do this to ensure that the code works on both a 40 and 80 column PET.

This may account for the failure to detect an address or data fault (especially on the READ side) in the upper 1K of an 80 column PET.

I have a much better test for page 0 and 1 RAM, so I may extend this to the video RAM in Version 5. More work to do...

Dave
 
Back
Top