This is one I said I wasn't going to do. I have a lot of respect for the BBC, and I'd rather have a working BBC than a keyboard. It is also a very large case, so it's a bit bulky to use as a keyboard. It does, however, have a very nice mechanical keyboard, with it's trademark red function keys.
I've had a few requests for them, so I thought it was about time I did one. I've also had something sitting around for a while which will resolves my objections.
This is a Viglen case for a BBC. It's in too poor condition to use, the plastic supports for the internal metalwork are all snapped off, some parts are missing, and the front is cracked. The idea with these is that the case replaced the top case of the BBC. The keyboard was then moved into a separate unit.
This is also in bad shape, but other than needing a good clean, it's mainly the paper label which is the problem. That would make a nice keyboard. Inside, it is just the standard BBC keyboard, with a nice curly cord extending the normal 17 pin connector.
Most of the USB keyboards I've built in the past have been simple matrix, so that can be connected to the controller to set the rows and scan the columns. The BBC is quite different. It has circuitry on board to drive the columns and read the rows. 4 of the outputs from the BBC are latched into a 74LS161, then to a 7445 binary to decimal converter, which drives the columns. The rows are fed into a 74LS251 8 channel mux to select the row to read. There is also a 74LS30 nand gate which gives a signal if any of the keys on the current column are pressed.
There are also three LEDs (originally Motor, Caps Lock and Shift Lock), and a special key, Break, which is wired to the 6502 reset line. To drive this keyboard, I could remove the logic and drive the matrix directly, but there's no reason to do that, I can just use them in the way they were intended.
A bit of extra coding is required, but nothing too taxing. The '163 can be used as a counter, but it's wired in direct mode, so just set the row number and pulse the clock line. Reading the rows just required setting the address of the row in the '251 mux. The '30 could be used to check if keys are pressed, the BBC uses this so it doesn't waste time scanning rows separately. The USB controller doesn't have anything better to do, so I just ignore that and scan all the time.
Later BBC keyboards have a speaker mounted to them, seems a shame not to use it. The BBC makes two beeps on startup, so I've emulated those on power up. It wasn't right without them. It is an 8 ohm speaker, so I can't drive it directly from the microcontroller, as the output pins are limited to 40mA. I was going to use a simple transistor amplifier, but I though I'd try a series resistor. 220 ohms in series takes it to 228 ohms, which on 5V should draw 22mA. That was loud enough, so I just left it with that.
The keyboard in the Viglen case was an older one without a speaker, so I fitted a small piezo speaker. to that one.
With that installed in the case, the keyboard bolts over the top.
I need to cut some black paper, or spray it black, but other than that it's finished.
Most of the key mapping was reasonably straightforward, although I did notice the circuit diagram in the user manual had the 9 and I keys the wrong way around. The only unusual keys are Break, which I've set as Ctrl+Alt+Delete, Copy which I've mapped to Ctrl+C and Shift Lock which is now the Windows key. The LEDs are mapped to the three normal keyboard LEDs, Num Lock, Caps Lock and Shift Lock, and change accordingly.
The desk clock used an 8x2 LCD, but I went for something different for this, the display from an Nokia 5110 phone. These are 84x48 graphical LCDs using the Philips PCD8544 controller. These is a simple interface, but it runs at 3,3V. I followed the guides on the Adafruit site to use a 4050 as a level converter and drive this from an Arduino Uno.
The plan for this is to run from 2x AA batteries, so the 4050 will not be required, and the LCD can be connected directly. As usual with these things you can't have everything, so it's 'cheap, lower power, accurate - pick two. In this case, it's cheap and low powered, so I'm running the ATmega328P with it's internal 8MHz RC oscillator, divided down to 1MHz, As with the previous clock, I'm using a 32768Hz watch crystal on a timer interrupt to count seconds.
The crystal is hidden under the chip socket, and that's all that's required for the final unit, one display, the watch crystal, 4 buttons and one 100nF decoupling capacitor on the back. The switches and display lines are wired to the nearest pin on the ATmega328P, as usual switched to ground and using the internal pullup resistors.
I've used a three pin connector for power, the centre pin is the blue backlight which isn't currently used, but could be wired up if required, obviously reducing battery life
Normally it just shows the date, but the yellow button switches into date / time mode so the time can be set. The other buttons increments day/month/year or hours/minutes/seconds, depending on mode.
I also build a portrait version, to be used on a different project.
So far testing has shown this may be out by a few seconds a day. That's not ideal for a clock, but this is to be paired with an analogue clock movement, so will mainly be used to show the date. In which case, it should be fine as long as it changes date around midnight and not at three o'clock in the afternoon.
Since there is no battery backed real time clock, it will not remember the time. I've added a function to write to the EEPROM when it changes at midnight. This is checked on power on, so the date will be correct and just the time will need to be set when the batteries are changed. The EEPROM has a limited life of 100,000 writes, so storing the time would wear it out too soon.
The Commodore Pet 4032 is now complete, and ready to use, I just need to get some software on there.
I have some Pet software on 8250 style floppy disks, but have yet to repair the 8250 drive. For other Commodore computers, I use the SD2IEC which plugs into the IEC port and provides easy access to .PRG and .D64 files.
The Pet doesn't have an IEC port, so unfortunately, I can't use that. It does have IEE488, which is parallel, and is what the IEC serial interface was based on. I have a few ideas for an SD card based solution, but for the moment, I'm relying on the cassette ports, and the recently refurbished Datasettes. Looking around, I found this page, where the author had used a Commodore 64 to assist in the transfer process.
The idea was to load the program into the Commodore 64, and then save it to tape. The tape could then be loaded on the Pet. Not quite as straight forward, as the load addresses are different, so there is a series of steps to follow on the Pet.
NEW - clears existing programs
0 REM - start a new program with line 0
LOAD - load the program
SYS 1024 - start the system monitor program
M 0401 0408 - display memory from address 0x0401 to 0x0408
cursor up and change the line to start :0401 01 08 - this points to 0x0801, the address where the code from the C64 was loaded
X - exit the monitor
0 - remove line 0 and relocate the rest of the code
SAVE "name" - save the program to tape
It looks a bit of a faff, but once you've done it a few times, it's quite quick.
To get programs on the C64, I added a directory to the SD2IEC SD card and copied on a selection of Pet .prg files. After a few successful transfers, I wondered if I could cut out the step of saving to tape on the C64, rewinding it and then loading it into the Pet. The cassette port is quite simple, It is a 12 pin connector, but the top and bottom rows are the same, so it's only 6. Would have been nice if they had reversed the bottom row, so the connector could go either way up, but never mind. The connections are as follows;
5V - permanent 5V supply
Motor - switched unregulated 9V
Read - data in
Write - data out
Switch - connect to GND when play (or any of the other keys) is pressed
So there is a data in and a data out, both TTL level, both pretty much direct to PIA I/O pins. All the analogue stuff is handled in the datasette. So can I just connect them together? It turns out no. Whether by design or mistake, the signals are inverted. I inverted the signal using a 74LS04 inverter and fed the inverted signal into the Pet.
Bingo, it worked. I wanted to make a lead up, and didn't think I would fit a 14 pin chip into the plug, so I tried a simple NPN transistor inverter, and that also worked fine,
It actually gave a slightly cleaner signal than the TTL gate did as it was pretty much full swing on the supply rails (top is output, bottom is input, both 2V per division).
I built this up into a cable, with the components wired directly to the plug. I used a 2N3904 but any NPN transistor should do. The emitter is wired to 0V. The base is wired via a 1K resistor to the write output of the C64. The collector is connected to the read input of the Pet, and pulled high via a 10K resistor to 5V.
The switch input on both plugs is wired to 0V.
And that's it. I found 15 way D connector hoods were a close fit. The screw holes didn't match, so these are just held on with cable ties.
With the cable in place, it simplified the process as I could load the program on the C64. Setup the Pet with 0 REM and then LOAD and as soon as I start the SAVE on the C64, it loads on the Pet. Then just sort out the load address as above and save to cassette.
Another nice thing about the Pet is that is has two cassette ports, the rear is port 1, the side is port 2. So I can do LOAD (which is short for LOAD "",1), and then when finished, SAVE "name",2. So no unplugging is required for the whole transfer process.
Finally some new software, here I'm trying some of the newly written Pet games from Revival Studios.
These are now free downloads. I particularly like Down, a very simple but fast and addictive game. Too fast in fact to be able to take any decent photos. Sorry.
Update: This doesn't seem to work with some machine code only programs, and ones that load at unusual addresses. Bit it's fine things like space invaders, fire, blitz etc. Also watch out for ones that include the 'killer poke' code 'POKE 59458,62'. That normally appears at the start of the code, so just remove the offending code before saving. On early Pets, it can speed up the video. This isn't required on the later CRTC based pets, where it causes monitor to lose vertical sync, generating a bright spot or line which could damage the monitor after a while.
This is one of the original Commodore Datasette drives I got with the 4032 long ago.
I love the plaited cables on these. I don't know if they were supplied like that, as I haven't seen any others like these. They appear to be three pieces of speaker cable plaited together.
Also unused for 20 years, all these needed was a general clean up, a new belt and a head clean and they worked fine.
The other was the same, just a different plug. The DYMO labels are original by the way.
The same design was used with early VIC20s, black and grey replaced by white and gold, and the addition of a tape counter (like the imperial Daleks in Remembrance of the Daleks, apart from the tape counter that is)
The white seems to sit better with the Pet, and the tape counter is useful. These also seem a lot more solid that the later 1530 Datassettes (or C2N, they seem to use the name interchangeably).
During the testing, I've been using a tape with space invaders on it. It is a good game, and has sound and reasonable graphics. But mainly because last time I was working on a Pet, I tried various methods to transfer from a PC to tape, and this was the only one that transferred successfully.