Cloning a Commodore PET-2001

[GK]

The processor board is still a work in progress, but since the video generator board is completed I decided to test it thoroughly by actually programming it. It's handy to know that half the system is functioning properly in its own right before potentially attempting to debug the system as a whole.

I plugged a 40-pin PIC16F874 MCU into the breadboard, wired up the video generator address, data and control lines and wrote quick program to clear (fill all character locations with a blank-space character) and then dump the character set* and write and a short message to the screen. Works perfectly. Next up: the processor board...............................     


* actually only one of two 128-character pages; you only have a choice of one or the other as the PET-2001 isn't able to display both simultaneously.
 

[GK]

It is getting on to 3am now, but it's finally alive! Yoo hoo!

The OS boots and passes all self checks, cursor is blinking waiting for input. The system is currently built to the minimum required hardware to boot the OS, but all that I still need to do now is add the IO. I stupidly bought only one PIA chip (two needed), which is why there is a vacant socket for PIA#2, which handles the GPIB interface, which aside from the PIA itself, will just required a few 75ALS161 IEEE-488 transceiver chips. However my next scheduled task is to interface a PS2 keyboard to the PIA#1 key-scan inputs/outputs with a small microcontroller (a PIC16F84), and to solder up the small additional amount of circuitry associated with the VIA chip to complete the cassette drive interface. At the moment the PIA#1 key-scan interface is just floating, which is why I get the spurious keyboard entry (a graphics character) upon boot up before the cursor. Just a few more hours work and I'll be able to compose/run/save and load programs.   

31743 bytes free! Just imagine the woody that would have given one back in the day! I simplified all of the memory decoding logic to a single 45nS OTP ROM look up-table.     




After this I'm going to do a Tandy TRS-80 with a current production Z80. Already have the ROM (level 1 and level2) binaries, all necessary technical documentation...

[GK]

Apparently not a lot of enthusiasm around here for cloning old computers like the PET? I though being a traditional hardware/discrete logic implementation rather than another boring FPGA port that this would garner more interest.

I've tested the prototype out to the extent that I can say that the hardware details are finalised and am now starting on the PCB layout, which will just be one large board, which I will have professionally manufactured. It's cheaper in quantity so would anyone else out there be interested in building a PET-2001 clone?

I've decided to take a different route with the keyboard interface. My original idea was to put a low-end PIC uC on the board to interface a PS/2 keyboard, but as it turns out such a lowly uC isn't going to cut the mustard. The operations of the PET CPU are interrupt driven by the video generator vertical blanking signal, meaning the keyboard is scanned at the video frame rate (in this case 50 times per second). There are 10 scan lines and the keyboard scan routine is quite slow, taking about 1mS to scan all 10 lines, but the issue is that the matrix is given a single read cycle only several uS after the scan line is updated, even so each scan line is actually active for (a mostly redundant) 100uS or so. This means that the interfacing uC only has several uS to read and decode the BCD for the scan line, look up the correct code in the matrix for the most recently pressed key and apply it the PIA data bus. And that is with a standard 1MHz system clock. In "turbo" mode (which is now finalised at 4MHz) the operation thus described needs to be done within 3uS.

Since a PS/2 keyboard is a bit old hat now, I've decided that a USB keyboard interface would be nice to have as well, but plonking this hardware onto the system motherboard would detract from the "retro" feel of the project, IMO. So what I've decided to to is keep the keyboard interface of the motherboard exactly as per the original PET, broken out to the outside world via a 25-pin DB connector, but additionally sporting +5V power. The keyboard interfacing can therefore be done by an external dongle, but you'll also have the option of plugging in a original PET keyboard if you have one (unlikely) or hacking an old PCB-style keyboard to plug directly into the DB25 by cutting all of the PCB tracks to the key buttons and re-wiring as per the PET matrix.

Unfortunately I don't have an old-style keyboard spare to hack right now, so in order to post the demonstration video shown here to youtube I rummaged through my parts and came up with a handful of toggle switches and a single push button. I wired the push button to the PIA keyboard scan IO to assert "Return" and the seven switches to assert "L", "O", "A", "D", "R", "U" and "N", which is all I need to load an run (but not much else!) programs from cassette.

Here it is loading and running Space Invaders. There is about 2.5 minutes of boredom in the middle of this video while the game loads, but I connected a speaker to the cassette drive data output, so, if you happen to be an old fart, you can turn up the volume and reminisce to some old-school computer sounds    

EDIT: My copy of Space Invaders appears to be corrupt (found on the net as a.TAP file, converted to a .WAV file and then recorded to tape); there are some glitches in the graphics and not all of the intro screens/animations appear entirely as they should (which I've deduced from watching other youtube videos of the same game).
 

http://youtu.be/b66FU2z5w5w     

[CJay]

Awhh damnit, shame you're so far away, I've got a few lovely keyboards that have proper keyswitches and would be easily adaptable for this, they weigh a ton and would cost a small fortune to post.

Very impressive project though, I harbour a bit of a desire to build one (but realistically it'll probably never happen)

[SeanB]

If keyboard decoding simply use the fact that a keyboard is slow, and use the micro to drive a crosspoint switch ( or at least a simple one using a pair of CMOS analogue switches to emulate one) that will emulate the key being pressed. As you likely will also have a shift and function modifier key as well simply use another analogue switch, and isolating diodes,  to do the functions, thus emulating the keyboard using a simpler to interface PS/2 keyboard decoder and a slower micro that only has to set the analogue switch inputs and outputs at a human type rate.

[GK]

Awhh damnit, shame you're so far away, I've got a few lovely keyboards that have proper keyswitches and would be easily adaptable for this, they weigh a ton and would cost a small fortune to post.

Very impressive project though, I harbour a bit of a desire to build one (but realistically it'll probably never happen)

Well darn,  that's annoying. An old keyboard to quickly hack would be quite handy right now so that I could give Lunar Lander a whirl 

[GK]

If keyboard decoding simply use the fact that a keyboard is slow, and use the micro to drive a crosspoint switch ( or at least a simple one using a pair of CMOS analogue switches to emulate one) that will emulate the key being pressed. As you likely will also have a shift and function modifier key as well simply use another analogue switch, and isolating diodes,  to do the functions, thus emulating the keyboard using a simpler to interface PS/2 keyboard decoder and a slower micro that only has to set the analogue switch inputs and outputs at a human type rate.

Yep; I actually considered doing essentially this for a second in 74HC logic, but unfortunately it turns out to require a great deal of logic. The gates need not be analogue-switches though (AND gates with the output ORed as per the matrix are fine) which makes the whole thing trivial to implement in a small CPLD, which is what I am about to start right now.

[GK]

I think I'm getting the old-school computer bug. Sifted through my stash of DIP pulls from salvaged digital (computer, etc) boards this morning. Do I have anything particularly exciting here?

[GK]

OMG! The "MBL8088-2" (center-bottom) is an 8 MHz version of the classic Intel MPU as used in the 1st IBM PC. This might be the perfect part for an Altair work-alike on steroids.

[chickenHeadKnob]

OMG! The "MBL8088-2" (center-bottom) is an 8 MHz version of the classic Intel MPU as used in the 1st IBM PC. This might be the perfect part for an Altair work-alike on steroids.

Get an xt motherboard and a NEC v20 chip instead and be able to run both MS-dos and CPM.  For a brief time I had to use such a machine to support legacy CPM based software. It ran seamlessly, a bit better than a real z80/8080 machine.

[GK]

OMG! The "MBL8088-2" (center-bottom) is an 8 MHz version of the classic Intel MPU as used in the 1st IBM PC. This might be the perfect part for an Altair work-alike on steroids.

Get an xt motherboard and a NEC v20 chip instead and be able to run both MS-dos and CPM.  For a brief time I had to use such a machine to support legacy CPM based software. It ran seamlessly, a bit better than a real z80/8080 machine.

Problem with MS-DOS / CP/M is that they're not very functional without a disk drive of some description. An emulator based on compact flash storage would work I guess, but I'm not exactly there yet. A Z84 MPU and an associated bunch of bits currently sits on the shelf for the TRS-80 clone for which I'm still working out the details, to happen once the PET is out of the way. Best not get too far ahead of myself I suppose.... Also, although I can't quite put my finger on exactly why, the advent of MS-DOS marks a time in the evolution of vintage computing where my interest in the old technology suddenly takes a nosedive.

[CJay]

I think I'm getting the old-school computer bug. Sifted through my stash of DIP pulls from salvaged digital (computer, etc) boards this morning. Do I have anything particularly exciting here?

*eyes you with suspicion* Have you been going through my stash?

[GK]

Ha ha, you might be missing a keyboard or two if that was the case.

[@rt]

Apparently not a lot of enthusiasm around here for cloning old computers like the PET? I though being a traditional hardware/discrete logic implementation rather than another boring FPGA port that this would garner more interest.

Not replying doesn’t mean not watching

Just that I don’t have anything to add, other than when I had a 1084S, not only was the front cover intact, but I also had a spare! 

[GK]

OK, with a bit of perseverance I got the lowly PIC16F874 that I had handy to successfully interface the keyboard (running at 4 MIPS). Haven't examined the timing headroom or have tried to optimise the code enough to work in turbo mode yet; have just been working to iron out all of the intricacies of the PS/2 keyboard standard - and what a hodgepodge of a standard it is too. Once the code is finalised I can port it to a faster microcontroller easily enough if necessary.

[GK]

, not only was the front cover intact, but I also had a spare! 

I can't remember what happened to mine; IIRC it disappeared around 1995-1996 or so. Wonder if I'll still be sitting in front of my Samsung LCD in 20 years......

[GK]

Just some playing around here. The PET 2001 wasn't designed with any sound-generation hardware, but a common hack back in the day for games was to use the CB2 pin of the VIA chip (provided at the parallel port) as an audio signal output.

If you set the 6522 VIA "ancillary control register" (ACR) (PET address 59467) to 16_dec, the internal shift register (outputting to pin CB2) is programmed to free run at a clock rate determined by internal timer#2:

2.13.1 Shift Out - Free Running at T2 Rate (100)
This mode is similar to mode 101 in which the shifting rate is determined by T2. However, in mode
100 the SR Counter does not stop the shifting operation. Since SR7 is re circulated back into SR0,
the eight bits loaded into the SR will be clocked onto the CB2 line repetitively.

So you basically have a primitive programmable-frequency (Timer 2 low-byte) arbitrary waveform generator. The shift register (SR) data register is PET address 59466. POKEing this register with a value of 15_dec (00001111) gives you a square wave. 51_dec (00110011) gives you a square wave one octave higher in frequency while 85_dec (01010101) returns one octave higher again.

By doing this in conjunction with programming Timer 2 (PET register 59464) you can actually reproduce musical notes over a few octaves with reasonably good accuracy. Of course the single voice is monophonic so you can't do chords and there isn't any control over the amplitude either, but even this primitive capability sure is better than nothing.

My PET clone is to have a switchable (in/out) audio amplifier based on either an LM380 or an LM386 on-board. Just experimenting with/verifying the functionality of the prototype hardware this afternoon I translated a tune-playing BASIC program from one of my BBC Micro programming books (BBC Micro Sound and Graphics, Mooney) to run on the PET.

The BBC Micro had it's own sound hardware and associated "SOUND" BASIC statement, which the PET obviously lacks, so I had to re-write, substituting SOUND with the appropriate VIA register POKEs and an additional FOR/NEXT loop for the note duration. The DATA array values for the notes were also changed to produce the correct frequencies on the PET. It's a 5 note tune; A (440Hz), B, C, D and G.

The BBC book doesn't tell you what the tune is and I don't recognise it. I'd like to write up a tutorial page on PET sound programing for my website so it would be nice to know. Anyone here recognise it? Here is a digital recording of it in mp3 format, straight from the VIA CB2 pin: https://www.eevblog.com/forum/projects/otp-eprom-programmer/?action=dlattach;attach=340925

[MK14]

It sounds like the classical Laurel and Hardy tune.

[GK]

It sounds like the classical Laurel and Hardy tune.

Ah, I think you're right. I'm not quite vintage enough to recognise that one! 

[GK]

Hmmm, listening a few times again and I'm not too sure. One thing I omitted in my program was a FOR/NEXT loop to implement a brief delay with the sound POKE'd OFF to give a short silence between played notes. Without that I think the tune probably sounds less like it should, especially in parts where the same note is played a couple of times in a row.
     

[GK]

Okay!!, attempt #2. I've modified the program to insert a short silence between played notes, so that the notes don't audibly run in to each other.  It sounds much more musical now. Note that in the original BBC Micro listing this was achieved with the additional empty SOUND statement on program line 190.

The short inter-note silence duration is determined by the new variable MUTE. I mute the audio by toggling the SR data byte between 15_dec (ON) and zero (OFF).

Here is the tune mp3: https://www.eevblog.com/forum/projects/otp-eprom-programmer/?action=dlattach;attach=340954
   

[MK14]

Here you go...

[Bicurico]

Just to shout how fantastic this thread is.

What would be the cost involved in getting the required components and PCB to rebuild your design?

Regards,
Vitor

[GK]

Oh, thanks for the interest. I missed this one - have been busy with other things the past few months. Dunno about total cost - parts alone for what follows were ~$80 AUD. Parts for the motherboard will probably be in the $100-$150 range. Then there is board fabrication, housing, etc.

Getting back to this project again; I've decided to modularise the design. The video graphics generator circuitry complete is now contained on a separate board. Communication to the mother (processor) board is via a 50-pin IDC header. I just finished the PCB layout this morning; will triple check everything over this evening and then send the design off the Elecrow.

The video graphics/character generator is a stand-alone project in its own right; could be used for any other project where you want to implement a retro 50 Hz video display. Except for the DIP EEPROM and (motherboard specific) DIP CPU/PIA/VIA all electronic components are SMD. I didn't endeavor to make the board ultra compact but rather basic to solder and compatible with even the cheapest PCB fab - 10 thou minimum track clearance (20-thou set for the GND polygon pour), all layed out on a 50-thou grid.  1206 passives, all logic ICs are SOIC and it's SOJ for the SRAM rather than TTSOP.

Now onto the motherboard.........

[GK]

Hmm, this project got delayed a bit... I received my video generator board in the post yesterday, having only sent the Gerber files to Elecrow on the 16th. This evening I soldered it up and stitched it into my prototype computer, discarding the original through-hole video generation circuitry built up on prototype board.

Works like a charm. Up until now (due to the crappy construction) my prototype computer continued to suffer the occasional hangup due to signal integrity issues (mostly ground) associated with reading and writing the video RAM, which I never managed to fully resolve in the original build. These signal integrity issued also caused the computer to not boot reliably on each and every power-up in all available versions of BASIC.

Now that I've got the video generation circuitry all built up nice and proper on a properly layed out PCB, all of these issues are now finally resolved. I've been putting the computer through its paces and it refuses to miss a beat. The reason for the huge 50-way ribbon for communications to the motherboard is that every second wire is GND. This video board also serves as the master clock source for the CPU.

I hope to have the motherboard circuitry transferred to a (mostly SMD) PCB within a month or two. In the photo below the smaller proto board with the two DIP40s on it is the current PS-2 keyboard interface.