Category: CBM 4016

Filthy and with some corrosion.

Washed with soapy water and blew out and allowed to dry.

I worked on this in parallel to the set to work of unit 1.  The process was much the same as for Unit 2.

The power wiring was a little different to the other unit and also different from the schematic.  In particular, the switch and fuse were after the filter.  I changed it to be the same as the other unit.

Other than that, the process was much the same as for Unit 2.

The capacitor was reformed on a DC supply and the transformer voltages were checked before connecting the processor board.

All earth points were stripped of paint and checked.

I had tried the unit one board previously, so I knew that it was not working.  I had previously replaced the processor because the legs were corroded.  (Later I tried cleaning it up, but it still did not work.)  I also replaced the GPIB buffers as they were also corroded.

I did the set to work of the Unit 1 board in the already completed Unit 2 chassis.

The screen was not scanning, so I disconnected it.

There are lots of things that could go wrong, and this board is a little more challenging than the other one because most of the larger ICs are soldered down.  This makes it difficult to just swap them out.  On the plus side, the socketed ICs tend to be more corroded than those that are soldered in.

The power supplies were good, the clock was good, and the reset was good. 

The most likely cause of failure was RAM, but there had been no RAM failures on the other board.  I probably should have just replaced the lot, but you don’t learn much doing things that way and the thought of cutting out 16 RAM chips didn’t fill me with joy.  I did it the hard way.

It’s relatively easy to see when the ROMs are accessed.  The 6502 resets to FC00, which is in the kernal (sic) ROM.  The webs suggested that the kernal calls an initialisation routine in the Edit ROM at E000.

It’s in here:

http://www.zimmers.net/anonftp/pub/cbm/src/pet/pet_rom4_disassembly.txt

The vector at FC00 jumps to FD16. The call to E000 is made at FD1B just after the stack is initialised.  This listing shows the edit ROM, but there are many edit ROMs.

This one seems to match reasonably well with the 50Hz 80 column ROM used in this board:

https://github.com/sjgray/cbm-edit-rom/blob/master/disassemblies/edit-4-80-DIN-50Hz-324243-01-disassembly-sjg.txt

Using this I could use the scope to read the address lines on the ROM one at a time to get the address. (it’s moments like these when a logic analyser would be handy but there’s not much that can’t be done with a good scope and some time.)  I added a reset button (between UD16-2 and ground) and the timing is repeatable with respect to the reset (which can be conveniently picked up on pin 40 of the processor).  This is partly because the system is so slow (1us per bus cycle) that there is time for both an access and a refresh. Not all machines are so deterministic.

CAS cycles (R10) identify accesses to RAM.   Accesses to VIA/PIA are trickier because they use multiple chip selects.  They are tucked into the E800 to EFFF space next to the Edit ROM, which is only 2k.  The other ROMs are nominally 4k.

The map is here:

https://www.zimmers.net/cbmpics/cbm/PETx/petmem.txt

I looked for where the processor seemed to lose its way and used ROM addresses to work out where execution was in the ROM. 

Suspecting RAM I looked for the first time there was a critical RAM read eg a subroutine return which I expected to be two back to back reads – it turned out to be three.  Similarly, I expected a call to be two writes, but they are always one read and two writes.  I still don’t understand this, but maybe the penny will drop one day.

Sure enough, the first return was just before the processor went rogue.  Checking the call and the return showed that the data read from RAM was very different to that written.  Very different.  Either there were a lot of dead RAM chips or something more systematic going on.

I got good at reading the data (during CAS for a write and valid at the riding edge for a read and also the row and column addresses – valid at the falling edge of RAS and CAS respectively.  Everything looked good, so I concluded that nearly all the RAM chips were duds.  And that proved to be the case.  After replacement of the lower 16k the machine came to life with a garbled display that looked a little like a sign on message but not quite.  (I checked the sync timing before reconnecting the monitor.)

After replacing the video RAM, the display improved but was still not right.  It changed with a wiggle of the character ROM.  After cleaning the legs (it is socketed) the display was good.  I could type in and run a program.

I tried some pokes and peeks in the second 16k.  It also had many failures, so it needed the same tedious treatment.  Once the second bank of RAMs was replaced, it worked.

Although the machine was doing quite well there was no chime and there were also issues detecting the datassette button presses.  That sounded like a VIA problem.  I replaced it and all was good.

I connected up the disk drive, and I was able to get a directory listing. 

The 4116 datasheet did indicate that the power should be sequenced correctly to avoid damage.  In particular, the -5V rail should power up before the others and power down after the others.  I checked just to be sure.

Having worked over the metal work and CRT I moved processor board one into its chassis.

Initially nothing appeared on the CRT.  The first problem was the spring which contacts the ground surface of the tube.  It was a little oxidised and bent.  After cleaning and adjusting it was fine.  The display was quite dim though even with the sub-bright and bright at their max.  The issue was that the 400VDC supply was only 200V.  This was because R253 had gone open circuit.  I have replaced it, but it may be a symptom of a bad capacitor – there’s quite a lot of commentary on it on the web eg:

https://forum.vcfed.org/index.php?threads/pet-12-monitor-repair.79319

The motherboard can support 40 or 80 columns.  80 columns is probably best for business applications, but is not so good for games – and most people like games. 

The following steps were required:

1. Move all links – there are three sets.  The instructions are on the PCB assembly diagram.
2. Remove the extra two video RAMs.  It can’t cope with the extras being present in 40 column mode.  I learnt this by experiment.
3. Change the Edit ROM to a 40 column ROM (now just a link on a EPROM adapter).

I’ve put in an EPROM that can hold both 40 column and 80 column ROMs. 

The ROM situation is a little complex. The 4016 has 7 ROM sockets designed for 2332 ROMs.  The Edit ROM is at UD7, but out of the factory is a 2316.  The 2316/32 ROMs

These ROMs have a no ROM feature so they can be disabled.  The machines that I have use some 2532 EPROMs.  These don’t have the disable feature, but are otherwise pin compatible with the 2332 sockets.

The problem is that 2532 EPROM are somewhat uncommon and are complex to program.  I don’t have a machine that can program them.  The closest replacement is a 2732 eprom that is available and that I can program.

They are close but not identical to the 2532.  Fortunately, a kind soul has designed a small PCB to adapt them.

https://github.com/SukkoPera/Open2327RomAdapter

This adapter can be configured to replace either 2364 or 2332 ROMs.  A larger EPROM can be used on the adapter and images selected using switches.

I’m not sure why the designer didn’t add a pin for A12.

I opted for the over-the-top 512.  They are easy to get and have been tested.

A link between pins 1 and 2 is an easy way to select between images at either 7000 (link on) or F000 (link off).  I put the 80 column ROM at F000 and the 40 column ROM at 7000.

For the 40 column ROM, I used edit-4-40-n-50Hz.901498-01.bin.

The disk drive looked awful inside and out and once the loose debris was removed it still looked awful. 

The cover was very corroded and the IEEE-488 connector was broken although the pins were intact.

After a wipe over, a blowout, and a first board wash started to look a little better with the board appearing to be less corroded than the computer boards.

There was no rush to get the drive going because I didn’t have a computer to test it with, and I didn’t have a connecting cable.  I ordered a short GPIB cable from China and an edge connector locally with a view to modifying the standard cable.

PCB corrosion was treated with soapy vinegar and after two passes the board was quite acceptable. The IC legs were in much better condition than those on the computer boards.

The tin can was treated with deoxit over several days and was then cleaned and painted with zinc paint.

The drive was thoroughly cleaned and lubricated.  It had no corrosion and the head carriage moved freely.

The case was processed in much the same way as the computer bases.  See above.  The corrosion was severe enough that filler was required.  I’m at a loss to explain why the case was so corroded but the PCB was good – despite the ventilation slots on the top of the case.

Transformer voltages were checked before power on.  I was surprised to find that the drive started with a spin and then gave a solid light as per the manual.  This was a good sign.

Alas, smoke followed, which is when I realised that there was probably a Rifa hidden away inside the IEC inlet filter.

Although I had a spare filter, it was too large to fit under the wiring cover, so I have reverted to a simple inlet with no filter.  I don’t like doing this, and I will revisit in the future.

I made up the cable by unpicking one of the GPIB connectors and replacing it with an edge connector.  The supplier sent the wrong size, so I had to cut it down to suit (2×12 rather than 2×22).

I made up a 2031 demonstration disk using a greaseweazle and a 40 track drive.  I had trouble doing this via SCP, but it worked fine writing direct.  Initially the drive was unreliable, but after a more exacting cleaning of the head it ran and passed the drive performance test.

Most games were written for 40 columns, so for the 80 column machine to work it has to run in a 40 column compatible mode.  This is done by running a program which effects the changes: CBM4032.

The program was easy enough to find, but I had to put it in a disk image.  As is often the case, there’s an app for that.  I used DirMaster.  Then the image just has to be written with greaseweazle.

I found that sometimes the disk drive stopped working.  When it did, it is because the head carriage was not moving reliably.  My best guess was that there is an intermittent fault in the stepper motor drive circuit.  It did not seem to be the connector.

The soldering on the board looks very good.

When the drive worked it worked very well, so the fundamentals seem good.

I used the scope to have a look at the stepper motor drive signals.  One was not like the others.  The stepper is driven by a quad resistor array FPQ3724.  The transistor at pins 12,13,14 did not seem to be presenting a 0.7V drop in operation.  On the meter it looked fine.  Pin 14 was quite corroded, so perhaps some moisture had got in.  It’s also possible that it had just blown – not unusual. An identical array is quite hard to get so in the short term I’ve patched a BC337 transistor in parallel.  This seems to have resolved the problem for now.