Cloning a Commodore PET-2001

[GK]

I need to program a bunch of Microchip (previously Atmel) AT27C256R-45PU / AT27C512R-45PU parallel I/O, 5V, DIP, OTP EPROM ICs from supplied binary files.

Any recommendations for a reliable and cheap USB (not parallel port) programmer? This one linked below looks promising perhaps, but the AT series chips aren't specifically listed, just generic 27C32, 27C256, etc...... the old ultraviolet erasable types. Can anyone advise if these are cross-compatible?

http://www.ebay.com.au/itm/High-Speed-USB-TL866CS-Universal-Programmer-Support-All-BIOS-Multifunctional-/180926954184?_trksid=p2385738.m2548.l4275

Thanks.

[German_EE]

Yes, they are cross compatible, the only difference between an OTP PROM and an EPROM is the quartz window. Just make sure that your code is 100% correct because with OTP devices mistakkes are costly.

[BrianHG]

You can always try some of the modern flash pin-pin compatible equivalents if they are supported by the programmer.  Or, like I once did, static ram equivalents, with the VPP pin which would have been for the eprom pulled & a lithium coin cell added to the IC with dual schottkey diode.  Of course, these tricks are just for development until you switch to a prom.

[GK]

Yes, they are cross compatible, the only difference between an OTP PROM and an EPROM is the quartz window. Just make sure that your code is 100% correct because with OTP devices mistakkes are costly.

OK thanks, that's what I figured.

[GK]

You can always try some of the modern flash pin-pin compatible equivalents if they are supported by the programmer.  Or, like I once did, static ram equivalents, with the VPP pin which would have been for the eprom pulled & a lithium coin cell added to the IC with dual schottkey diode.  Of course, these tricks are just for development until you switch to a prom.

I'm doing a CBM PET-2001 clone. Found the complete ROM binary set on the 'net and have deciphered the content. The 2k-8bit character ROM .bin goes straight to chip unmodified. The operating system (BASIC#1) was stored on 7 individual 2k-8bit ROM chips. So there are 7 OS .bin files labeled with sequential addresses. All I have to do is copy them into a single binary file to burn to a single ROM chip.

 

[GK]

Well, I found that a whole EEVblog episode and a gazzilion post thread was already devoted to this device. Thanks for the tip. 

I've got one of these programmers on the way from China, but it might take a couple of weeks to arrive.

In addition to the PROMs I've also got on the way:

1x 65C02 uP
1x 65C21 "PIA"
1x 65C22 "VIA"

....all in 40-pin DIP from the Western Design Center line, bought from Mouser:

http://au.mouser.com/Western-Design-Center-WDC/Semiconductors/Integrated-Circuits-ICs/_/N-6j73k?P=1yzrr9x


So, am I about to become the first around here to build a 6502 system up with these modern issues of the old MOS devices?

Any possible compatibility issues/quirks I need to know about? Am looking forward to getting a retro PET-2001 clone up and running with a 14 MHz "Turbo" button !   

[BrianHG]

I don't know much about the PET, but if it were a Vic-20, or C64, the graphics and sound chips and disk-drive/tape-drive comm ports run from a common master clock which need to stay in sync with the CPU clk and, sound pitch and IO interface, video output scan rate, functions other than parallel interface will all go out the window when in turbo mode.

I know the software emulators make it look easy when turbo-ing emulating these computers, but, they do seek and trap certain addressing events to prevent everything from going all haywire, or, have a control for the degree of backwards compatibility with some apps VS pure speed.

As for the ROMs, if you appropriately address all the files in one larger rom, and properly place them in a 27C128, (total 16kbx8), or 27C256 and properly set the output enable, and tie all the addressees, it will work.  It will also be all to easy to add right in parallel a 1x or 2x 32k  X 8bit static ram as your system memory instead of worrying about D-Ram ras/cas/refresh and ect.  All the pins will be in parallel, except output enable and write-enable.  Since the 8 bit static ram and eprom are both 28 pin 600 mil wide DIP devices and virtually pin-pin compatible, and dirt cheap today.

For 14Mhz with 1clk cycle transactions, not sure if 6502 waits 1 or 2 clocks on bus transactions, go with 70ns devices to get 14Mhz, 1 clock transactions.

[GK]

Serial I/O won't operate in "turbo" mode, that's a given, but there won't be any issues with the video as far as I can see. The 2001 didn't have a sound synth or any dedicated sound circuitry, just a speaker for beeps controlled by a single logic line.

The video circuitry was character based only, 40x25 grid, monochrome, implemented in discrete TTL; no custom IC's.
I've completely redesigned the video circuitry using currently available 74HC logic as much of the TTL used in the original design is now unobtanium.

The video generator essentially runs completely independently of the CPU and the CPU can access the 1000 bytes (40x25) of video memory at any time to program the displayed characters. The vertical sync timing signal from the video generator was sent to the 6502 for synchronisation. The PET had two operating modes for video RAM writing; Fast and Slow. For the former the CPU would just access the video ram asynchronously/randomly, but this would result in glitches in the display if the visible part of the raster was currently active. For the latter the CPU would sit and wait for the vertical sync signal, thus avoiding any visible display artefacts by updating only during the vertical blanking period.

[GK]

Answering my own question, it appears that everything I need to know regarding compatibility between the WDC 65C02 and the original MOS 6502 is detailed here:

http://www.westerndesigncenter.com/wdc/AN-002_W65C02S_Replacements.cfm


This is only a slight pain I guess as a published "modern" chip set 6502 design won't be compatible with NOS '02 processors without incorporating a jumper to deal with pin 1. BE (pin 36) is NC on the original and can just be tied to VDD.

[GK]

As for the ROMs, if you appropriately address all the files in one larger rom, and properly place them in a 27C128, (total 16kbx8), or 27C256 and properly set the output enable, and tie all the addressees, it will work.  It will also be all to easy to add right in parallel a 1x or 2x 32k  X 8bit static ram as your system memory instead of worrying about D-Ram ras/cas/refresh and ect.  All the pins will be in parallel, except output enable and write-enable.  Since the 8 bit static ram and eprom are both 28 pin 600 mil wide DIP devices and virtually pin-pin compatible, and dirt cheap today.

For 14Mhz with 1clk cycle transactions, not sure if 6502 waits 1 or 2 clocks on bus transactions, go with 70ns devices to get 14Mhz, 1 clock transactions.

No, definitely not going to bother with DRAM. SRAM was used in the PET 2001 too. The early serial numbers used MOS 6550 SRAM chips while later revisions used 2114s.
The DIP SRAM chips I ordered for the project have a 15nS specified read time spec. Should be fast enough!
 

[james_s]

The TL-866 programmers that are sold all over the place ought to do what you need. I have one and use it frequently, it works as advertised.

[GK]

Yeah, that's the model I linked to in my opening post. I have one in transit; departed China yesterday evening. The W65C02 and other bits are due tomorrow. To get these bits right before the long weekend with everything else set to go but no programmer to flash the ROMs. Arggggh! So frustrating! I guess I'll have spend this weekend finishing off my Video Pong instead.

[GK]

I think I'll be able to have this PET 2001 clone fully built on perf. board with sockets for the programmable chips before the programmer arrives.

I'm sorting out the master clock 1MHz/"Turbo" switching circuitry now. This manual switch-over isn't necessarily as trivial as it might first appear. I've never played with a 6502, but there is the possibility that it is susceptible to runt clock pulses. Suppose you just asynchronously switch the master clock frequency source while the uP is running. Chances are greater than not that you'll create a runt pulse or two whilst switching over; that is a pulse too short for the uP to properly count. That pulse might be ignored completely by the uP, or, if it's duration is within a critical range, it might only successfully clock part of the uP's internal circuitry, causing a crash/lockup/whatever.

I've designed a preliminary circuit to do the clock frequency switching synchronously, only passing whole cycles of either clock whilst engaging/disengaging, but just pondering the issue I'm curious as to how the master clock circuitry of old 286 and the like motherboards with a "Turbo" switch were designed.

Googling so far isn't delivering answers. Does anyone have any idea or a source of really old "IBM compatible" motherboard schematics showing the clock generation circuitry? Much of these of PCs were constructed out of TTL/CMOS logic, so I presume that may have included the clock generation circuitry.

[GK]

I seem to to mostly talking t myself here  I'm eventually going to layout a single large PCB for this complete PET-2001 clone, but I'm building it up on proto board first to develop the design and iron out any potential bugs first.

Here is the (currently ~3/4 complete) 74HC, 40 column by 25 row character-based video generator. At the moment all that still needs to be wired in is the static screen memory and address/data bus remote-access multiplexing, so right now all I can put on the screen is a single selected character in every character position. I found an old UV-EPROM with a character set already programmed into it, from a video generator project dating back to ~2000, so this is what I currently have plugged into the character ROM socket until my programmer turns up and I can flash the OTP-equivalent PROM with the PET ("PETSCII") character set. Most of the character set in the EPROM is corrupt now as it, although it has spent most of its life in semi-darkness, hasn't had a sticker over the window for who knows how long.

In the photo the eight ROM address lines which select one of the 256 available characters can be seen jumpered to the breadboard, which is how I am currently addressing the displayed character. These lines are about to be soldered to the screen memory SRAM (the empty socket beneath the EPROM) data bus.

The second photo attached below shows the displayed character in reverse field, which is how the PET blinks the cursor.

[GK]

No. I'm reading along. Can you show more about the video circuit.

Sure, but that will have to wait until I'm done soldering it together and testing, after which I will transfer pages of scribbled diagrams to Protel.

Is it your own or did you find it somewhere?

Entirely my own of course.

[Kleinstein]

The 6502 needs rather fast access time. There are no wait states and one memory transfer per clock cycle. So even with 1 MHz clock it needs something like 400 ns access time. With additional bus drivers it might need to be even faster - not a problem at 1 MHz, but possibly a problem at higher speed.

AFAIK the 6502 / 65C02 is only available up to 2 MHz clock speed. There is a faster 16 Bit version, used in the Apple 2G, that can run up to about 8 MHz.

A higher speed might be possible with an FPGA implementation - however this might need level translators for old SRAM.

[GK]

The 6502 needs rather fast access time. There are no wait states and one memory transfer per clock cycle. So even with 1 MHz clock it needs something like 400 ns access time. With additional bus drivers it might need to be even faster - not a problem at 1 MHz, but possibly a problem at higher speed.

AFAIK the 6502 / 65C02 is only available up to 2 MHz clock speed. There is a faster 16 Bit version, used in the Apple 2G, that can run up to about 8 MHz.

A higher speed might be possible with an FPGA implementation - however this might need level translators for old SRAM.

No, no, no, as already mentioned, I'm using the "6502" and associated PIA/VIA chips from Western Design Center. These are not the original NMOS parts, but current-production (yes, really), performance-enhanced CMOS versions. The 65C02 is fully specced to 14MHz. See here:

http://www.westerndesigncenter.com/wdc/


I'm using 15nS SRAM. The ROMs are 45nS. The high-speed bottleneck will be in the video RAM access. I quite significantly simplified the video generation circuitry by addressing 4kb of memory (not all allocations used) directly from the pixel and line counters. This allocates a character position in the screen RAM to every single character space, including the invisible ones during the retrace and screen-border blanking intervals. The original PET circuitry did not work this way as SRAM back then was not free to "waste". The PET video generator had an address counter for the screen memory that operated separately from the pixel and line counters, only incrementing for each displayed character. There was also an attendant temporary address data latch/memory/register, that was necessary as the 40 memory positions for each row of characters has to be cycled through eight times (a character space is eight video lines high), so the return address needed to be updated and temporarily stored every eight video lines.

However, without re-writing the operating system, in my simplified video generator logic, I have to map the 1000 (40x25) individual character positions addressed by the CPU to the correct ones in my video RAM. I'm doing this with a PROM address lookup table. So the 15nS screen RAM is addressed via a 45nS PROM. The address data selector, which grants the CPU screen RAM address access, adds another ~20nS delay, as does the bi-directional data bus transceiver. So I have 15nS+45nS+20nS+20nS = 100nS. Add another 20nS just for safety and maybe another again for setup times and good measure and we can safely handle a memory cycle of 8.3333 MHz. My pixel clock is 8 MHz and this is what I am currently planning to use as my "Turbo"-speed clock.

[GK]

So I have 15nS+45nS+20nS+20nS = 100nS. Add another 20nS just for safety and maybe another again for setup times and good measure and we can safely handle a memory cycle of 8.3333 MHz. My pixel clock is 8 MHz and this is what I am currently planning to use as my "Turbo"-speed clock.

Oops, Make that 7.1 MHz. 8MHz might be skating on the verge, but these are conservative estimates with about worst case 25 deg. C delays. Will just have to wait and see.

[chickenHeadKnob]

As for the ROMs, if you appropriately address all the files in one larger rom, and properly place them in a 27C128, (total 16kbx8), or 27C256 and properly set the output enable, and tie all the addressees, it will work.  It will also be all to easy to add right in parallel a 1x or 2x 32k  X 8bit static ram as your system memory instead of worrying about D-Ram ras/cas/refresh and ect.  All the pins will be in parallel, except output enable and write-enable.  Since the 8 bit static ram and eprom are both 28 pin 600 mil wide DIP devices and virtually pin-pin compatible, and dirt cheap today.

For 14Mhz with 1clk cycle transactions, not sure if 6502 waits 1 or 2 clocks on bus transactions, go with 70ns devices to get 14Mhz, 1 clock transactions.

No, definitely not going to bother with DRAM. SRAM was used in the PET 2001 too. The early serial numbers used MOS 6550 SRAM chips while later revisions used 2114s.
The DIP SRAM chips I ordered for the project have a 15nS specified read time spec. Should be fast enough!

I would go  even further and completely dispense with all the old school eproms, just fill the 64k address space with static RAM and have a modern MCU you are comfortable with act as a system control/boot loader essentially turning the target system into a rom emulated one. Massive convenience for debugging.

[james_s]

I never liked using a modern microcontroller in this sort of retro project. By the time you do that, you may as well just emulate the thing entirely in the microcontroller, or put the whole computer in an FPGA.

[GK]

Yes, the whole point of the project is to clone the PET as directly as possible with current production logic. There will be one modern micro on the board though - a small PIC to interface a PS2 keyboard to the PET's PIA-based key scan I/O.

Incidentally, just from a hobby/tinkering perspective, I'm delighted that a fab-less mob like WDC exists, to supply modern revamps of these old processors and peripherals, but I'm a bit baffled that a professional market exists for the parts at all. I'm sure that there is still a ton of legacy 65XX-based industrial still stuff out there, with an economic viability to keep alive, but none of that old stuff would need replacement parts capable of 7 - 14 times the original clock rates. I wouldn't consider these devices for anything professional, and the worth of 65XX cores for FPGAs seems a bit dubious to me, apart from the niche interest of cloning old computers and arcade games machines with minimal hardware. There might be a lot of geriatric engineer's out there still designing professionally, but just sticking with what they know.

[james_s]

I'd be curious to know also what the market is for these sort of parts. It's possible that it's some sort of government/military/aerospace thing with an extensive existing codebase where certifying a new design is extremely expensive

[GK]

Got the screen memory SRAM wired up along with the address line multiplexing. All that needs to be added now is the octal transceiver chip to buffer the SRAM data bus, the two PROM chips for mapping the character address and a header for address/data/control line breakout to the CPU board.

Until that is done I can't remotely program the display, but at this stage I can see that it all works as when I apply power I get a random garble of displayed characters depending on whatever the contents of the SRAM happens to be.

This part of the project is pretty much a stand-alone character display unit; might be worth describing/self-publishing as a separate project? 

And a funny thing about the old, temporary UV EPROM containing the character set; I reported in my prior post that much of the contents was corrupt. Well that is true, as when I first applied power after soldering up the SRAM I got mostly garbage on the screen. In addition to that the corrupted bytes containing character data were unstable too; I was actually getting randomly flashing characters on screen. Whole bytes were randomly alternating between $FF and the originally programmed values. But something miraculous happened when I removed the blob of Blu-tak covering the glass window, allowing in light - all of the data magically uncorrupted itself! It's completely reliable too. So long as there is a certain amount of light shining on the chip all is fine, but if I progressively block out the light by lowering my thumb towards the window at a certain threshold the data goes whoopie.

[MK14]

The video circuitry was character based only, 40x25 grid, monochrome, implemented in discrete TTL; no custom IC's.
I've completely redesigned the video circuitry using currently available 74HC logic as much of the TTL used in the original design is now unobtanium.

The video generator essentially runs completely independently of the CPU and the CPU can access the 1000 bytes (40x25) of video memory at any time to program the displayed characters. The vertical sync timing signal from the video generator was sent to the 6502 for synchronisation. The PET had two operating modes for video RAM writing; Fast and Slow. For the former the CPU would just access the video ram asynchronously/randomly, but this would result in glitches in the display if the visible part of the raster was currently active. For the latter the CPU would sit and wait for the vertical sync signal, thus avoiding any visible display artefacts by updating only during the vertical blanking period.

I'm surprised that it is NOT 6845 based (which I somehow thought it was). Which was typical of that era (but I may have the dates a bit wrong).
https://en.wikipedia.org/wiki/Motorola_6845

I'd mostly forgotten about the 'Fast' 'Slow' video writing modes. If I remember correctly, even when there is interference, it is mainly/fully being BLACK where it could have been white, rather than a snowy effect, and is quite fast.
So I don't think it is TOO bad, even with the 'artifacts'.

Partly because the screen was not that sharp or easy to read RELATIVELY, compared to other (probably much more expensive), computer/monitor/terminals of that era.
It was OK, and nice, in its own right. But it was possible to get much nicer looking displays, with text which looked more like typewritten print. I.e. less visible pixels and nicer colours etc. It was also a bit shaky as well, even when the text was stationary and nothing was being written to the screen.

tl;dr
I think it was "Cost reduced", and used a cheap black and white crt from a large production TV set, and had other cost saving measures. Which perhaps explain what I mean.
E.g. An expensive computer of that era would have a hard disk, or at least floppies (I know later models of the Pet, did have such things, and plug in ones were available at some point), rather than a built in tape cassette unit.
The keyboard was also on the 'cheap' side, with these small plastic, key like things. Rather than a proper, full sized, mechanical keyboard, of the day, then.

[MK14]

In addition to that the corrupted bytes containing character data were unstable too; I was actually getting randomly flashing characters on screen. Whole bytes were randomly alternating between $FF and the originally programmed values. But something miraculous happened when I removed the blob of Blu-tak covering the glass window, allowing in light - all of the data magically uncorrupted itself! It's completely reliable too. So long as there is a certain amount of light shining on the chip all is fine, but if I progressively block out the light by lowering my thumb towards the window at a certain threshold the data goes whoopie.

Usually covering the UV window, when you are using the EPROM, is important. Otherwise there can be the odd, crash or data corruption, now and then (usually but not always, sometimes they seemed to work fine, WITHOUT any opaque labels etc). But then there was the risk of stray light (especially sunlight) from erasing it over time as well.

So maybe (speculation), the EPROM has exceeded its 10/20 year write retention lifespan, and is actually helped by the stray light, causing some raising of voltages or something.

If it was me, I'd read the data when it works (or get it from a proper source or even write it from scratch), and burn it into a "fresh" EPROM. But I guess UV erasing and rewriting that EPROM may work as well.