Commodore PET 2001 Repair - Garbage screen with noise

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Here we have a Commodore PET 2001 board in for repair.

A common fault with the Commodore PET series of computers is a screen full or garbage, a random assortment of characters. This is normally perfectly static and stable, and is usually caused by a ROM or RAM fault. The PETs video circuitry runs independent of the CPU and displays on the screen whatever is in the first 1000 bytes of video RAM from 0x8000 to 0x83E7. At power on, this is random, and on most early PETs, you get a brief flash of that at power on. Once the CPU starts running code, the video RAM is filled with the space character and the screen is cleared. If the CPU cannot run due to a ROM or RAM fault, the screen remains full of garbage.

This board has an unusual fault, it is showing a screen full of random characters but with snow or noise. This noise happens on the 2001 when the screen RAM is being updated at the same time as it is being read. Later PETs got around this by adding latches into the circuit.

In this case it appeared the CPU was running, and the snow, the moving pattern of white dots over the screen indicated something was up with the logic that writes to the display RAM. If the video RAM is socketed, a quick test you can do is to run it without video RAM. If all is well with the circuitry for reading the video RAM, you will get a chequer board effect, as the data lines float high and all characters are read as 0xFF (displayed as ▞ - a black and white photograph of a slice of Battenberg cake).

I temporarily installed a ROM/RAM board set to the PET test ROM. This alternates between displaying a screen showing the full character set, and a screen full of G or B characters (based on testing the first 1K of RAM, G for good, B for bad for each byte). This changes every couple of seconds, so it a good test here as I can probe for a signal which pulses every couple of seconds.

Tracing through the switching logic the signal was there up until one of the 74LS157 multiplexors. Here the output was stuck high, so was stuck in read mode. Write mode is controlled separately, and was being enabled correctly, so it was trying to read and write and the same time.

I noticed one of the three multiplexors had already been replaced. These do have a habit of failing, so since two out of three had now failed, I took the precaution of replacing the third as well.

With the 157s replaced, power back on and we have a boot screen.

1102 bytes free isn't ideal. Looks like it's got 2K of RAM, so there is a fault in the third pair of RAM chips. These are the original MOS 6550 RAM. Not particularly reliable, neither is the 6540 ROM. These chips have lots of enable lines, which means by a clever arrangement of which address lines go to the enable pins, you can setup a bank of 16 chips in parallel without any other logic, although all it would have needed was a 74LS138.

The problem is these enables often fail, and the RAM gets enabled over more of the address space than it is meant to. The same RAM is used as the video RAM, and here they are enabled all the time, so you can get away with using RAM with faulty enable lines as video RAM. Here I was lucky and was able to swap those over and get the full 8K working.

I ran the RAM test several time, and left it running for a while and repeated it, and it's passing all the tests. It's not a permanent solution, but I will leave it to the owner,  by the looks of the writing on the top of all the chips, he has already been swapping chips around.

My advice of 6540 and 6550 chips remains the same. If you plan to use the machine a lot, and you have a working set of chips, remove them and put them away safely for Sunday best. For general use, get a ROM/RAM board - now available from my Tindie Store.

Not only does it save wear on those chips, it reduces power consumption (from 3A down to 1A), and you get to select the RAM size up to the full 32K and the BASIC version, 1, 2 or 4.

2022 Update: The redesigned small version of the PET ROM/RAM boards are still available from  TFW8b.com 

Commodore Amiga 600 and 1200 USB keyboard kit

I have had few requests for USB keyboard kits for Amiga 600s and 1200s, so here they are.

The A600 and A1200 are very different from the Amiga 500. The A500 had a keyboard controller board on the back of the keyboard, and a serial interface to the mainboard. The Amiga 500 USB keyboard controller I built for that was a lot simpler in hardware terms, but a bit more effort to implement the serial protocol in the microcontroller.

The A600 and A1200 have no keyboard controller, and just a simple membrane connection to the mainboard. These have more connections and a smaller pitch than any of my previous USB keyboard controllers, so I have made a custom board.

The A600 cable is 30 way and the A1200 is 31 way, with a slightly different pinout.

 I found matching 30 way sockets for the A600, but I have not been able to get 31 way sockets, so I have used 32 way sockets for the A1200, just make sure the cable is aligned to the left of the connector.

The board mounts on the back of the keyboard using some self adhesive pillars. The cable on the LED board is not long enough to reach, so I supply a short extension cable.

The power LED is lit whenever the keyboard is plugged in. I have set the floppy and disk activity LEDs to act as scroll lock and num lock. You could drive these from software if you wanted to use them for another purpose.

They keyboard has a built in caps lock LED which shows the current state.

As usual the kit does not include an Amiga or keyboard, you need to provide those yourself, and please try to use a broken one.

The kit does include the USB keyboard controller, the LED cable, mounting pillars and a USB lead, and is available to buy from my Tindie Store.

I also have various single and dual 9 way D to USB joystick adapters that would fit nicely in the A600 or A1200 cases. These allow you to use original 9 way D joysticks (like Zip Stik or Competition Pro etc.) as USB joystick devices, contact me for more info.

Or if you are short of space inside an A600 with a Raspberry Pi and associated items, you can go for a single or dual port USB joystick adapter which sits externally to the case.

If you want to support this blog, you can donate via Patreon or Paypal, or buy something from my store.

---

2023 Update

USB Keyboard Controller Kits are available from my Sell My Retro store (LED cables no longer included as no one appeared to use them):

• https://www.sellmyretro.com/offer/details/62112
• https://www.sellmyretro.com/offer/details/62113

RC2014 Modular Z80 System

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

I'm sure you've all heard of the RC2014, it's a modular Z80 computer system available from seller 'Semachthemonkey' on Tindie. A great little system that makes it easy to build and expand a Z80 based system. (or even a 6502 system as the base is very adaptable).

I've just bought some new boards to add to my RC2014 system, so I thought it would be a good time to revisit the current system and go through all the boards on there before I add the new ones.

Backplane

The system is based on a backplane with a common bus, 40 pins wide, carrying most of the Z80 lines. It uses 40 way 0.1" sockets for the modules to plug into. This is the 'back plane - 8' model where slots 1 and 2 and slots 7 and 8 can have their address and databusses isolated from the main slots, 3-6. This will allow some protection on the bus via resistors or to use split address and databusses for some cards to create ZX81 or ZX Spectrum type systems where the busses are isolated to simplify the screen generation process.

Into the backplane plug a selection of modules. Most are less than the full 40 pin width, and all align with the top of the backplane, pin 1, with the exception of the clock / reset module which hovers around the middle. Full details of the backplane and other modules can be found on the rc2014.co.uk website.

Z80 CPU Module

The heart of the system is the Z80 CPU board. This has little else on there, other than a pullup resistor on the INT line. This is an older board, with inputs not passed to the backplane such as NMI, WAIT and BUSRQ tied high, the later versions have an option to tap these off or tie them high. Full details here. Like all of the other modules here, there is no decoupling on the boards, only on the backplane. I'd like to see the traditional 100nF on each chip, I think that has happened on the later modules.

Clock Module

The clock generator comes on a small separate board. This generates a buffered 7.3728MHz clock. I would have thought it logical to place this on the Z80 board, but I guess there are reasons to separate them. There is also a position for a reset switch, but I deviated from the normal build here and added instead an RC circuit to give a power on reset. There is a reset button on the backplane anyway. Here I found a 74LS04 wasn't up to the job, but a 74HCT04 was fine. Full details here.

8K ROM Module

The Z80 needs some code to run, so it gets that from the 8K ROM module. This has a 27C512 EPROM split into 8 banks of 8K, selected by jumpers. Full details here. As supplied, it came with a version of BASIC adapted from the NASCOM computer by Grant Searle - more details on his site. This is fixed 8K ROM decoded to the address range 0x0000 - 1FFF. There is a later module which allows bank paging, which is one of the new ones I have ready to install.

32K RAM Module

BASIC needs some RAM to run in, so here is 32K of RAM, mapped as 0x8000-FFFF. Again, this is a fixed mapping and a newer board has up to 64K and paging capabilities. Full details of the 32K RAM board here. If I remember correctly, this is another one of the boards where I started with a 74LS32 and changed to a 74HCT32 as I found some RAM chips (the Alliance AS6C62256 shown) didn't work with the LS chip, but other 62256 chips were fine.

Serial IO Module

This final module for the BASIC system provides serial IO. This is based on the 6850 (although the 6350 can be used, as can 6xA50 and 6xB50 variants). These are the only part in this system that are out of production, so are old parts, the 68B50 I got didn't work, but I had a 6850 and that worked correctly. The system 7.3728MHz clock is divided down to get the serial baud rate. Divide by 64 gives 115200 baud. There is space to install a MAX232 and a 9 way D connector for an RS232 compatible port, but the easiest option is to use the FTDI header to connect to a PC via a USB serial adapter. The jumper above also allows the RC2014 to be powered via this connector. The 6850 is accessed at address 0x80 and 0x81 (but is also mirrored from 0x80 through to 0xBF) . Full details here.

The RC2014 in use

With all of those plugged in, you can see that two face in the opposite direction to the others. This means the central modules are close, so I have some plastic feet stuck on the back of the RAM card to stop it touching the CPU card. Since all my FTDI cables were bricked by FTDI last year, I am using an Arduino module which does the same job, and that is set to power the whole unit (current consumption is under 200mA, and the USB port can in theory supply up to 500mA).

Connecting up via a serial terminal and switching on, we're into BASIC and away. Without adding any storage, the easy way to get programs onto the system is to paste into the terminal Window. I have had mixed results and usually need to get the terminal program to add a 10mS line delay or a 1mS character delay to avoid corruption when transferring large programs, as there is no flow control in place.

You can then transfer some BASIC programs over to test. It is a pretty generic Microsoft BASIC with most of the usual commands supported. The great thing with a system like this is that if you find there is something missing, go and grab the source for the BASIC interpretor and add your own commands.

RC2014 Mini

Something else I should probably mention at this point is the RC2014 Mini. This is basically all of the above on a single board. It can be used standalone, of there is space to fit a 40 pin connector on the side to add a single module, or a backplane full of modules. This one is also driven via FTDI serial cable, or you can use the RC2014 Universal Micro Keyboard.

That is what that keyboard is meant to be used for, even though I keep using them on my Minstrel ZX80 clones.

So that's the existing modules I have covered, next time I'll be replacing several of those with new ones.

Update:

I have added my own module to the range, a combined Z80, clock and reset module.

2022 Update: RC2014 continues to be very popular, they can now be ordered from the sellers new store z80kits.com 

Z80 M1 signals

During testing of the DivMMC future, one of the aims was that it should work with as many ZX Spectrums as possible. In many cases, the clock line was the most problematic, but we managed to resolve that one (more on that in another blog post).

One thing that we have not been able to address is the M1 line on the expansion bus. This is wired directly to the Z80 and is not used by the internal circuitry of the ZX Spectrum, but is required by the DivMMC circuitry.

The Z80 datasheet describes it above, it is used to indicate specific conditions of IO and Memory request cycles. We have all heard various comments about 'weak M1 lines' etc. being the reason some external devices do not work with some Spectrums. Indeed, this affects not only the DivMMC Future, but things like Sinclair's own Interface 1.

In normal operation, M1 is toggling up and down with all the other signals, between 0V and about 4V, which is well with the specification for a digital pin. In all systems where the M1 line has looked like this, we have seen the DivMMC future work correctly.

I have seen several systems where the M1 line does not look like that. Here it is just noise, floating about 1V. I have tried various options to see if there is any signal there, triggering off IORQ and MREQ instead, but it really is just noise. If it were a weak signal, it could be boosted. But this is just no signal.

Adding a pullup does just that, pulls it up, so it's now floating around 3V, still not doing any good.

I have seen this 'missing M1' on various manufacturers versions of the Z80, GSS, NEC, and even an original Zilog.

When this was replaced with another Z80, the M1 signal was present and the board worked fine.

The same Z80 was then tested in another known working machine and the missing M1 signal had transferred with the Z80.

This isn't like the clock signals, where they are at least present on all boards, albeit barely 1V peak to peak in some cases. There just isn't anything there to work with. I'd be interested in anyone has examples of Z80s with 'weak' M1 line, where there is a valid signal, just running at too low a level, rather than just being noise.

Having seen cases of seemingly identical chips, one with a working M1, one with just noise, I don't think this is a case of corner cutting on Z80 clones. They could have been like this from the start, and the faulty M1 lines not picked during testing (maybe Sir Clive bought a batch of defective ones on the cheap, like he did with the RAM?).

However, if you look at the ZX Spectrum edge connector, M1 (marked as M1L meaning M1 - active low), is right next to the 12V AC line (a point tapped off the DC-DC converter). I wonder how many misaligned joystick interfaces accidentally shorted the 12V AC into the M1 line and killed it?

Given this signal is important for the operation of the external devices, if it's simply not present, then the external devices are not going to work, so you need a new Z80. In all cases where this has been seen, replacing the Z80 has always resulted in a working system.

Brand new Z80 chips are still in production, you can get them from the TFW8b store.