Sunday, 29 September 2019

Minstrel Keyboard now with Overlay PCBs

Introducing another keyboard option for the Minstrel ZX80 Clone.
I added a tactile switch keyboard option to the Minstrel last year, which looked very nice, but there was limited space around each key.
There was only space for one letter or number, no keywords or graphics characters. When I did a similar thing for the Commodore PET, the spacing was a little larger and there were no keywords to fit in, so I was able to fit the normal and shifted symbols in around each key.
I do have membrane overlays for the ZX80/81 which stick over a ZX81 membrane keyboard, in various colours and BASIC versions. As there is no visible switch element, there is space for all the artwork, keywords, symbols etc.
The new overlay PCBs combine the best of all those options.
These sit on top of the switches on the tact switch keyboard, with the switch plungers poking through the holes in the PCB, and with each switch surrounded by all the various keywords and graphics.
I planned to use quite tall switches, but I found they were a little weird to type on, so I found some nice switches that were just tall enough to poke through with the PCB sitting directly on top of the switches.
They can just rest the overlay PCB on top, so you can swap them around if you want to use both versions of BASIC. I have produced a blue PCB, with the keywords for ZX80 4K BASIC (PRINT "" is O shift Y shift Y).
And also a white PCB with keywords for ZX81 / ZX80 8K BASIC (PRINT "" is P shift P shift P). You can also bolt them to the base PCB if you are happy you want to stick with one version or the other.
The tact switch keyboard is available separately from my Tindie Store.
And you can order one or both overlay PCBs with that, and the Minstrel Tactile Switch Keyboard is available with blue or now also green solder mask, to match the main Minstrel boards.
The overlay PCBs are now also an option on the Minstrel ZX80 clone with Keyboard listing.
And finally, they have been added as an option to the main Minstrel ZX80 clone page.

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

Sunday, 22 September 2019

How the VIC20 Works

The VIC20 is a great little machine, and quite a simple machine, particularly the later cost-reduced version.
Inside the earlier VIC20 machines, it looks like there is quite a lot going on, but it's mainly a load of 2114 static RAM chips.
The later machine replaced most of these with two 6116 SRAM chips, leaving only three 2114s (for old times' sake).
The simplicity of the machine did leave a few compromises when it came to address mapping, but this was meant to be an entry level machine. If you wanted 32K, you could buy a Commodore PET or CBM.

Schematics

Various schematics for the VIC20 are available on the net. The ones on zimmers.net have the pages split in half, so for reference, these are the joined up versions I put together, with a little bit of tidying up and attempts to correct the misalignment present in the original scans.
Page 1 covers the 6502, VIC, clock and bus buffers.
Page 2 covers power supply, reset, IO and address decoding.
Page 3 covers the ROM and RAM.

VIC chip

You could say the heart of the machine is the 6502 processor, but that is relegated off to the side, and the real star of the show is the VIC chip, the 6560 (for NTSC) or 6561 (for PAL). This gives the machine it's name, although it wasn't actually designed for it, having been designed several years earlier but failed to find an application. The VIC generates the video output, which is tied to the dot clock for the different video standards. The original version of the VIC20 (2 pin power connector) had different boards for PAL and NTSC versions, these had different clock crystals (14.31818 MHz for NTSC, 8.867238 MHz for PAL),
There were also differences in the supporting circuitry, the PAL version had an additional 74S74 chip to divide the clock down by two to give 4.43618 MHz. The later CR machines used the same board, and used a 4.43618MHz crystal on PAL machines to avoid the need for the extra divide by two stage. The VIC chips output the main system clock, divided by four on PAL machines to give 1.108 MHz, and divide by 14 to give a slightly slower 1.022 MHz on NTSC machines. More info on this in previous blog posts converting a PAL VIC20-CR to NTSC and vice versa.
Unusually for machines of this era, the video output was composite video. UHF TV output was only possible with an external RF modulator box supplied with the machine. The VIC chip outputs chrominance and luminance separately, so with a slight modification, it is also possible to get S-Video out of a VIC 20. That is really only beneficial if you have a suitably vintage S-Video monitor.
To do that, disconnect the C (chrominance) output from the Y (luminance) path, that leaves the previous composite video output now being luminance, and chrominance can be fed via a low value capacitor (1nF?) and an impedance matching resistor (75Ω). You could modify the 5 pin connector to have chrominance at pin 1 to match the early Commodore 64s.

Reset

The VIC20 uses the good old 555 timer to generate a clean reset pulse of 1.6 seconds. This is fed via a 7406 open collector buffer, to allow external reset via the user port, IEC port or cartridge port.
More on this (and other reset circuits) in a previous blog post on an Oric 1 repair.

Power

None of the VIC20 range used dynamic RAM, so there was no need for -5V or 12V rails required by the usual 4116 chips. The static RAM chips 2114s and 6116s are 5V only, so the VIC20 was a mostly 5V machine. The only part that needed more than 5V was the datasette port that needed 9V. The power circuitry went back to the early Commodore PETs, and had a 9V AC input, rectified to give 9V DC (ish) and then regulated down to 5V. The regulator inside the early model Commodore PET was a 7805 TO3 device which gets rather warm.
The redesign for the CR used the Commodore 64 style power supply. This still provided 9V AC for the datasette and the userport, but regulated the 5V in the external power supply (although these are not considered to be reliable these days).

Address decoding

Most of the address decoding in the VIC20 is handled by splitting the 64K address range of the 6502 microprocessor into eight 8K chunks. These are split as follows:

Block
Address Range
Use
0
0000 - 1FFF
Internal 1K RAM
Cartridge RAM1,RAM2,RAM3
Internal 4K RAM
1
2000 - 3FFF
Cartridge BLK1
2
4000 - 5FFF
Cartridge BLK2
3
6000 - 7FFF
Cartridge BLK3
4
8000 - 9FFF
Character ROM, I/O 0 and Colour RAM
Cartridge I/O2,I/O3
5
A000 - BFFF
Cartridge BLK5
6
C000 - DFFF
BASIC ROM
7
E000 - FFFF
KERNAL ROM

Four (and a half) of those blocks are not implemented within the VIC20 (shown in blue), and are assigned to the cartridge port. RAM1, RAM2 and RAM3 are 1K allocations within block 0. I/O 2 and I/O 3 are 1K blocks within block 4. BLK1, BLK2, BLK3 and BLK5 are four full 8K blocks.

Block 0

Block 0 contains the internal RAM, and important areas of RAM that are always present, and forms the  BASIC working area and screen memory as follows:

Address Range
Size
Use
0000 - 00FF
256 bytes
Zero page
0100 - 01FF
256 bytes
Stack
0200 - 03FF
512 bytes
BASIC variables
0400 - 07FF
1K
RAM1 (cartridge slot)
0800 - 0BFF
1K
RAM2 (cartridge slot)
0C00 - 0FFF
1K
RAM3 (cartridge slot)
1000 - 1DFF
3.5K
BASIC User area
1E00 - 1FFF
512 bytes
Screen Memory

The zero page and stack are important to the 6502 so there always needs to be RAM at these locations if you want to make use of the faster zero page op codes, and any subroutine jumps need a stack. There is a 3K gap within this range that can be filled via the cartridge port. This confuses things quite a bit, and you end up with three different arrangements of the memory map, expanded, 3K expansion and 8K (or more) expansion (see later)

Blocks 1,2 and 3

Blocks 1, 2 and 3 are mapped to the cartridge port. There you can install RAM and / or ROM. RAM must start in block 1, then blocks 1 and 2, then blocks 1,2 and 3 if it is to be recognised by BASIC. Other combinations can be used by your own assembly language programs, but BASIC will not count memory if there is a gap. These blocks are normally used in combination with block 5, to provide one or more additional 8K blocks of code. As far as we know, Cheese and Onion is the only game which uses all of blocks 1, 2, 3 and 5.

Block 4

Block 4 is used for IO and the screen colour RAM as follows:

Address Range
Size
Use
8000 - 8FFF
4K
Character ROM
9000 - 93FF
1K
I/O 0 (VIC and VIAs)
9400 - 97FF
1K
Colour RAM
9800 - 9BFF
1K
I/O 2 (cartridge slot)
9C00 - 9FFF
1K
I/O 3 (cartridge slot)

The 4K character ROM is generally 901460-03, but there may be regional variations for other character sets. The colour RAM is a single 2114 chip, 4 bits by 1K, so only bits 0-3 are implemented. The VIC chip uses either the top or bottom half of that depending on the amount of system RAM installed (see later). I/O 2 and 3 are assigned to the cartridge port to use for external I/O devices. I've never seen those implemented as RAM, but I suppose there is nothing stopping you adding a further 2K of RAM within this I/O range, if you wanted to squeeze the maximum out of the VIC20. BASIC wouldn't see it, but you own assembly language could. The I/O 0 range is split up further for the VIC and the two VIA chips.

Address Range
Size
Use
9000 - 900F
16 bytes
VIC
9110 - 911F
16 bytes
VIA #1 (userport)
9120 - 912F
16 bytes
VIA #2 (keyboard)

VIA#1 is used mainly for the userport, and VIA#2 for the keyboard. The other I/O functions, the joystick port, IEC port and datasette port are split between the remaining pins on both chips.The decoding is not complete here, so the VIAs are mirrored throughout the I/O 0 range. VIA#1 is enabled on all addresses in the I/O 0 range where A4 is high, and VIA#2 where A5 is high, so there are addresses where both chips are enabled. I've not seen this used in practaice, but you could save time if you were writing to both chips at the same time during initialisation using say 9130-913F, although, any read operations would cause bus conflict. Quite a lot of potential range is wasted there, as only 48 bytes of a possible 1024 are used, but it saves a number of logic chips that would have been required for tighter decoding.

Block 5

Block 5 is an 8K block assigned to the cartridge port. If a ROM chip is present which starts with the correct predefined header, BASIC execution will jump to the start address defined in the header, this allows autostart cartridges to be used. Most ROM cartridges use a ROM in block 5 to start their code, often with an additional ROM in one of the other 8K banks on the cartridge slot  It is also possible to install RAM in this address range, and if a ROM image is copied into the RAM, it will also autostart, but be aware that some cartridges will detect if they are running from RAM, and may refuse to continue.

Block 6

Block 6 is the BASIC ROM. This cannot be paged out or replaced from the cartridge port, so any routines in the BASIC ROM are always available. There appears to have only ever been one release, 901486-01.

Block 7

Block 7 is the KERNAL ROM (although it also contains various bits of the BASIC code). This is also fixed and cannot be paged or replaced. It is normally socketed, as there are different KERNAL ROMs for each region (901486-06 for NTSC, 901486-07 for PAL). They also seem to be a more common failure than many other chips.

Moving Targets

If that all seemed to make sense, then let me confuse you a little. In order to make use of the extra 3K or 8K or more RAM, some things are moved around when these are installed, to leave the largest available continuous run of RAM available to BASIC.


Unexpanded
3K
8K
16K
24K
32K
Screen Memory 
1E00-1FFF
1000-1FFF
Screen Colour
9600-97FF
9400-95FF
BASIC Memory
1000-1DFF
0400-1DFF
1200-3FFF
1200-5FFF
1200-7FFF
BASIC bytes free
3583
6655
11775
19967
28159

Quite a few things to note here:
  • The screen and colour RAM move when 8K or more is installed. 
  • The 3K space in block 0 is not used by BASIC when 8K or more is installed.
  • The BASIC start address changes each time.
  • RAM in block 5 is not counted by BASIC
  • The internal RAM is multiplexed with the VIC chip, so it can't access external RAM
The BASIC RAM space needs to be continuous, so RAM in block 5 is not available directly for BASIC storage, but can be used by assembly language programs. The same is true for the 3K in block 0 if there is also RAM in block 1. BASIC programs will generally cope with this movement, as long as there is enough RAM to load the program itself. Assembly language programs depends on the programmer. In some cases, they will use the BASIC variables stored in zero page which indicate where the various memory ranges start, so will cope with changing RAM configurations. Others hard code screen and colour RAM addresses, so will fail to work if designed for unexpanded / 3K and are run on an 8K machine, or vice versa. When I hit this issue when running programs I keep thinking they should have arranged it better so it didn't move, but if you are stuck with the 5K internal RAM and have to cope with 3K or 8K expansions I couldn't come up with anything better, other than maybe moving the video RAM up into block 4?

Decoding hardware

The address decoding is fairly simple, and uses mainly 74LS138 three to eight line decoders.
I have seen quite a few machines where these chips have failed. Possibly because some of their pins are directly connected to the cartridge port, so could have been damaged by inserting or removing a cartridge when the power was on (particularly at an angle), or just static from the carpet.
The decoding of block 0 uses another 74LS138, providing chip selects for three 1K blocks on the cartridge port and the internal RAM chips (part numbers shown for VIC20-CR).
One of the problems we occasionally hear with the VIC20 Penultimate Cartridge is 'it doesn't work, but my VIC20 works fine when it's not plugged in'. Generally we assume that the PU cartridges work because I don't think we have actually had a faulty one come back. The 74LS138 at UC5 failing is a common cause of that. This is as good a place as any to describe my normal testing plan. What usually happens is one of the external block lines is stuck high or stuck low, so it's either never enabled (so code is missing) or always enabled (yay! bus conflicts). If the user has access to any other cartridges, I suggest they try out a selection as different types use different combinations of blocks, so that might narrow down the problem.

Cartidge Type
Blocks Used
Examples
Simple 4K/8K
5
Avenger, Radar Rat Race, Omega Race
Atari 16K
1,5
Centipede, Dig Dug
Standard 16K
3,5
Defender, Robotrol, Pole Position
Text Adventure
1,2
Adventureland, Pirate's Cove, The Count

Any of those that work prove those blocks are working. Any that fail indicate one or more bad block enable lines. More on this in a previous VIC20 Repair blog post. You will see the Scott Adams' Text Adventure cartridges do not sit in block 5. This is apparently due to a shortage or space, they couldn't fit in the header and bootup code required, so the user had to type a SYS command to start the game.

Accessories

These days, I don't think a VIC20 is complete without a Penultimate+ Cartridge and an SD2IEC.
The VIC20 is also still enjoying new releases and new hardware developments. There are still many VIC20 fans out there.
This week saw the release of these two new cartridges from The Future Was 8 bit, Nibbler and Future Fighter.

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

Sunday, 15 September 2019

Commodore SX-64 Repair and 1541 Diagnostics

It seems recently I've had a run of repairs which have turned out to be fairly straightforward, some like last week's C116 repairs are worth writing up as they are interesting machines, the rest are the same old usual suspects on the same old machines, so I've not written any of the up. This one however, qualifies as it's another interesting machine.
The Commodore SX-64, a Commodore 64, 1541 and a monitor, all in a box with a handle on. What Commodore described as an 'executive computer'. Something the busy executive has someone lug around for them so they can do their work by the pool.
This one isn't going to help our executive file his expense claims, it's showing nothing but a grey screen. This is in fact a black screen, with the brightness turned up.
To double check this, there is the same 8 pin DIN monitor connector as the Commodore 64 on the back, so plugging in an external monitor shows the same, a black screen. The disk drive is not spinning up either, so there is something more than just a monitor fault. A quick check with the Dead Test cartridge also showed a black screen, so time to look inside.
Looking on the back, it looks like quite an early one, late 1983, but I'm not sure how long these were in production for.
Inside the SX64, you are presented with the inside of the monitor as well as the computer and disk drive side, so as ever, use a little common sense and don't test voltages on the monitor with your wet fingers.
Leaving the monitor side well alone, it's a little difficult to access the rest, but my first test was to measure the supply rails, and the 5V rail wasn't there. Something was pulling it down and probably getting very warm. I didn't leave it on for too long, to check for hot chips, instead I dismantled it a bit further to gain access to the boards.
The first board, the one that sits along the whole right hand side of the unit, is the CPU board. This contains a large part of the Commodore 64 side of the machine. There is a nicely heatsinked VIC II chip, ceramic by the looks of it, and it's associated circuitry.
There is 64K of DRAM and it's mux chips. These are a common cause of that sort of thing, and you would often find one chip baking hot, shorting out one of the supply rails. I hope it's not that, as it will be difficult to test without making up some extension cables.
In the centre are the main chips, the CPU, the PLA, the SID and three ROM chips. The standard C64 BASIC and character ROM, and a modified SX-64 KERNAL in the centre.
There is a board plugged into this at right angles, this contains the IO side of things, the two 6526 CIAs, and various other miscellaneous parts including the 7406 IEC buffer. The round silver can top left is a 60Hz oscillator that is used to generate the time of day signal which is normally derived from the AC mains. That is not a cheap part, and they could have used mains reference on the SX-64, perhaps there was some plan to run the SX-64 from batteries?
To rule a few things out, I thought it would be easier to try these chips one by one, in a known working C64 board. I skipping the 2564 EPROM for the moment, as that is a non-standard pinout.
The ROMs, the PLA and the CPU, and all were found to be working. The machine had arrived for repair accompanied by a PLA chip on some foam. This was apparently the original chip, and has been removed by a previous owner in an attempt to fix the problem. I also verified that it wasn't working.
Whilst I had the C64 board on the test bench, I thought I would test the SID, make sure that was working, then I could leave it out of the system until I had finished testing. But when I tested the SID on the C64, I got a black screen. I measured the 5V rail and it was low, I touched the chip and it was very hot. Oh dear, it seems the SID was dead, and was causing the black screen.
I reassembled things without the SID and it booted straight away. I ran through the Dead Test again, and all passed. I think it is possible that the previous faulty PLA might have caused the SID to burn out, or it could just have overheated itself.
I'll switch back to the external screen captures at this point, as they are easier to see. I'm running a modified version of the Diagnostic ROM at this point, which knows about the SX-64. The Fails on the IO chips are due to the missing SID and the lack of loopback plugs.
So that's all working nicely. Back to BASIC, and interesting to note seeing these side by side that the SX-64 KERNAL uses the same colour scheme as the Dead Test and Diagnostics cartridges, rather than the less readable blue on blue colour scheme that the standard C64 uses
The keyword was initially a bit unresponsive, but after a bit of use, most of the keys have come back into operation. Could probably do with a full cleanup if any of those don't come back.
Time to test the disk drive. The light comes on, a good start.
It seeks, but doesn't read anything. I wasn't sure that this point if the drive was at fault, or the IEC circuitry, so I disconnected the IEC bus from the internal drive (the two six pin connectors are the IEC bus, and are wired in parallel).
There is a user port and IEC port in the same style as the Commodore 64, so I plugged in a standard SD2IEC drive and tried that out. (Note there is no cassette port on the SX-64, so you need to specify the Userport connector when ordering).
That worked fine, so the problem was the drive.
The drive inside the SX-64 is pretty much a standard 1541 drive, rearranged to fit in the SX-64 case. It's not very easy to access though, as the drive mechanism is blocked by the 'glove box' that fits above it.
I tried a few tests using the 1541 Test/Diag cartridge (by World of Jani, available from TFW8b.com). This has a good selection of utilities to diagnose issues with Commodore disk drives, which all run from the cartridge.
I started out with a few tests, but it was clear it was failing everything.
It does look like you have to remove everything to access the drive, but a handy tip is to unclip the two studs on the front sides of the 'glovebox', this allows it to be flipped upwards.
With that raised, you can access the head and the rails of the disk drive mechanism.
The head is on the bottom side of the disk, and there is a sprung clip above you can lift to access the head. I've propped it up here to get a better view.
Oooh, nasty.
That might explain why it couldn't read anything.
After a good clean, it's looking a lot better.
I also used some Molykote lubricant on the drive rails to allow them to run free.
Back to the 1541 Test/Diag cartridge to repeat the tests. I started with the performance test, that starts with a format and then various read and write exercises.
That all passed, so this is looking good.
I also tried the alignment test, that showed 100% on track and not too bad on the half track reads.
You can also do all sorts of fancy stuff such as the sector viewer.
The last test I did was the speed test, which was also within acceptable tolerance.
I noticed when putting the machine back together, that the strobe marks on the bottom of the drive flywheel are visible through the slot for the keyboard connector, so you could do it that way if you prefer.
The drive appeared to be working, but I wanted to do some further testing, so I again unplugged the IEC bus from the internal 1541 drive and plugged in an SD2IEC. I wanted to use the two together, but both start off as ID 8, so I will change the SD2IEC drive to ID 9. To do that, use the following command: OPEN1,current address,15,"U0>"+CHR$(new address):CLOSE1
This will last until the power is removed. To make it persist, use this command: OPEN1,new address,15,"XW":close1
Note the drive is already drive ID 9, so you need to send this second command to the new address.
With the SD2IEC now as drive 9, I reconnected the original drive, plugged in the Epyx Fastload cartridge and booted up CBM Command to give the drive a work out.
This identified the two drives correctly, and was able to copy files back and forth.
I also tried writing a D64 image from the SD2IEC to a real floppy disk in the internal drive. That takes a while, but completed with no problems.
This was obviously for testing purposes only....
Oh dear, I can't possibly play this without a SID. I had sourced a replacement SID chip, so time to put everything back together.
To prevent further issues, I fitted some heatsinks to the SID and PLA chips.
Time to try that again. Much better, sounds great.
With everything all back together, I thought I'd finish the testing with the new Ms. Rodman cartridge.
That's running well, a nice portable games machine. Only slightly easier to carry around than a full size arcade cabinet.
Just clearing up the test bench, and I noticed, for a machine with an internal disk drive, I seemed to use rather a lot of cartridges in this repair.

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