Author Topic: Cloning a Commodore PET-2001  (Read 44167 times)

0 Members and 1 Guest are viewing this topic.

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Cloning a Commodore PET-2001
« on: June 03, 2017, 05:19:27 am »
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.
« Last Edit: April 25, 2018, 12:53:12 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline German_EE

  • Super Contributor
  • ***
  • Posts: 2399
  • Country: de
Re: OTP EPROM programmer
« Reply #1 on: June 03, 2017, 06:46:12 am »
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.
Should you find yourself in a chronically leaking boat, energy devoted to changing vessels is likely to be more productive than energy devoted to patching leaks.

Warren Buffett
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: OTP EPROM programmer
« Reply #2 on: June 03, 2017, 06:52:43 am »
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.
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: OTP EPROM programmer
« Reply #3 on: June 03, 2017, 11:37:14 am »
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.
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: OTP EPROM programmer
« Reply #4 on: June 03, 2017, 11:45:19 am »
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.

 
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
6502 system design.
« Reply #5 on: June 05, 2017, 05:04:20 am »
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 !   
« Last Edit: June 05, 2017, 05:22:07 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: OTP EPROM programmer
« Reply #6 on: June 05, 2017, 05:26:58 am »
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.
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: OTP EPROM programmer
« Reply #7 on: June 05, 2017, 05:45:02 am »
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.


« Last Edit: June 05, 2017, 06:09:34 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: OTP EPROM programmer
« Reply #8 on: June 05, 2017, 08:49:38 am »
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.
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: OTP EPROM programmer
« Reply #9 on: June 05, 2017, 01:52:52 pm »
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!
 
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: OTP EPROM programmer
« Reply #10 on: June 06, 2017, 08:22:47 pm »
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.
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: OTP EPROM programmer
« Reply #11 on: June 08, 2017, 12:09:12 pm »
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.
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: OTP EPROM programmer
« Reply #12 on: June 09, 2017, 11:12:56 am »
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.
« Last Edit: June 09, 2017, 11:14:57 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #13 on: June 10, 2017, 11:58:04 am »
I seem to to mostly talking t myself here  :P 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.



« Last Edit: June 10, 2017, 12:07:04 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #14 on: June 10, 2017, 12:52:03 pm »
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.

Quote
Is it your own or did you find it somewhere?

Entirely my own of course.




Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Online Kleinstein

  • Super Contributor
  • ***
  • Posts: 14080
  • Country: de
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #15 on: June 10, 2017, 01:19:38 pm »
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.
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #16 on: June 10, 2017, 02:05:49 pm »
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.
« Last Edit: June 10, 2017, 02:17:57 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #17 on: June 11, 2017, 12:32:53 am »
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.
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline chickenHeadKnob

  • Super Contributor
  • ***
  • Posts: 1054
  • Country: ca
Re: OTP EPROM programmer
« Reply #18 on: June 11, 2017, 01:04:31 am »
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.
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #19 on: June 11, 2017, 01:22:50 am »
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.
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #20 on: June 11, 2017, 02:18:37 am »
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.
« Last Edit: June 11, 2017, 02:21:54 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #21 on: June 11, 2017, 05:56:55 am »
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
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #22 on: June 11, 2017, 06:07:39 am »
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.



Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: OTP EPROM programmer
« Reply #23 on: June 11, 2017, 06:22:50 am »
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.


 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #24 on: June 11, 2017, 06:39:38 am »
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.
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #25 on: June 11, 2017, 06:44:09 am »
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


According to here: http://www.westerndesigncenter.com/wdc/Chip_Applications.cfm .... amongst others a leading manufacturer of sophisticated mammography equipment is a chip uP user  :o
Gotta be greybeard engineers, or maybe cash-strapped uni's are still teaching microprocessors on 65XX-based development boards. I know the "Microprofessor" Z80-based dev. board, which was already old hat when I learnt on it 18 or 19 years ago now is still being actively manufactured and sold to tertiary institutions.  ::)
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #26 on: June 11, 2017, 06:55:16 am »
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.


Oh, this old EPROM was pulled from a proto board I built 17 years ago. The project in question was a Space Invaders clone, which I never finished as my "CPU" was a 16F874 and I ran out of RAM to store all of the working variables, LOL. I don't think that a sticker has been in place over that window for a good 15 of those 17 years, so it's little wonder that it is operating funky now, if not a miracle that I can still recover the data at all. As a matter of fact that EPROM, on a 1kb page not accessible by my current design, there is the complete Space Invaders character set, including all of the animated aliens, which I copied pixel-pixel verbatim from screen images of the original arcade game. When my programmer arrives I'll read the content and safely file the binary, just for nostalgia, or if I ever feel like rebooting the project.
 
 
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #27 on: June 11, 2017, 07:08:42 am »
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.


Oh, this old EPROM was pulled from a proto board I built 17 years ago. The project in question was a Space Invaders clone, which I never finished as my "CPU" was a 16F874 and I ran out of RAM to store all of the working variables, LOL. I don't think that a sticker has been in place over that window for a good 15 of those 17 years, so it's little wonder that it is operating funky now, if not a miracle that I can still recover the data at all. As a matter of fact that EPROM, on a 1kb page not accessible by my current design, there is the complete Space Invaders character set, including all of the animated aliens, which I copied pixel-pixel verbatim from screen images of the original arcade game. When my programmer arrives I'll read the content and safely file the binary, just for nostalgia, or if I ever feel like rebooting the project.

I see.
Yes, long term (decades) uncovered UV windowed EPROM's, are suppose to be in significant risk of dataloss, I agree!

The original Pet's character Rom had some early block character graphics in it as well. Which is handy, for full 100% compatibility, with some games and stuff. (From my memory), this gave it a 2 x 2 pixels per character graphics capability, for amazing resolution games. The keyboard had those block characters on it, when shifted (or some kind of second key function).

The Pet computer was an amazing revolutionary item in its day. In real terms (it was arguably) the first real PC computer (but I agree, there were OTHERS which could also claim the prize of being FIRST, so it was NOT necessarily the FIRST).

Yes there were others, both before and after it. But they were either ridiculously expensive, and/or so technical only a computer/electronics expert could realistically use it (e.g. Altair 8800) and/or too simplistic/messy to count (e.g. ZX81, using a home TV with its tiny 1K ram and tricky keyboard etc, was more of a toy computer, really, in my opinion).

i.e. The Commodore Pet could be used by a Business or Home, as an early PC computer (WITHOUT any form of internet or similar, at that time). It was great if you could program in Basic, and/or be pleased with the quite extensive, affordable range of software available for it.
Including Chess, games and all sorts of other stuff, including serious business applications software (if I remember correctly, maybe even the Visicalc program, the first ever spreadsheet program).

You could even add sound for your games, by connecting some kind of speakered amplifier to the appropriate connector(s) at the back of the Pet.
« Last Edit: June 11, 2017, 07:14:59 am by MK14 »
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: OTP EPROM programmer
« Reply #28 on: June 11, 2017, 07:08:49 am »
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.


Nope, no 6848; just generic ROM, RAM and TTL. Here is the schematic: http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001/320081-3.gif

The "extended" character set used in the PET was carried, essentially unchanged, over to the VIC20 and C64. The PET's video generator circuitry was about as primitive as a 40x25 character generator can be made. There was no provision for user-defined characters and no bitmapping. The characters stored in the ROM as supplied by CBM were the only things that could be printed to the screen. These limitations were why the character set produced (dubbed "PETSCII") went well beyond the standard ASCII set, with all those extra "graphics" characters useful for drawing pretty displays.

My favorite feature of the PET is the IEEE-488 (otherwise known as GPIB) interface bus. When I get this clone finished I'm going to install it on my bench an put it to actual serious use controlling my test gear.
« Last Edit: June 11, 2017, 01:45:41 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: OTP EPROM programmer
« Reply #29 on: June 11, 2017, 07:32:49 am »
Nope, no 6848; just generic ROM, RAM and TTL. Here is the schematic: http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001/320081-3.gif

The "extended" character set used in the PET was carried, essentially unchanged, over to the VIC20 and C64. The PET's video generator circuitry was about as primitive as a 40x25 character generator can be made. There was not provision for user-defined characters and no bitmapping. The characters stored in the ROM as supplied by CBM were the only things that could be printed to the screen. These limitations were why the character set produced (dubbed "PETSCII") went well beyond the standard ASCII set, with all those extra "graphics" characters useful for drawing pretty displays.

My favorite feature of the PET is the IEEE-488 (otherwise known as GPIB) interface bus. When I get this clone finished I'm going to install it on my bench an put it to actual serious use controlling my test gear.

They have come up with something, apparently very simple and relatively low cost to produce. It certainly did the job at the time, and worked quite well.

The first thing that struck me about it was the 8 MHz crystal. Usually I'm use to it being some weird/complicated frequency, such as 3.579545 MHz or 4.43361875 MHz (yes, I know those are for transmission to TV's for NTSC/PAL), but usually I see funny numbers, such as 12.13643636797 MHz (hypothetical number), because it divides up to eventually make 60/50 Hz with the required number of scan lines and pixels, etc.

(I considered mentioning it, but didn't because ...) The IEE-488 interface, was very useful (and a surprise on the apparently cost optimized commodore Pet computer), for some people. I did not mention it, as I don't think I ever used it, so it was NOT useful to me.
Unless some kind of peripheral devices (e.g. printers) made use of it. I CAN'T remember exactly, but vaguely think that they did.
« Last Edit: June 11, 2017, 07:43:20 am by MK14 »
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #30 on: June 11, 2017, 08:01:18 am »
HP certainly made plotters that had GPIB, or rather HP-IB as they called it. I think there were printers too but I don't know for sure. I'm not sure what Commodore peripherals used it but it seems like there was a disk drive. While generally considered exotic on a computer, GPIB is rather simple to implement, in some cases it was done with discrete logic without even having a microprocessor involved.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #31 on: June 11, 2017, 08:28:59 am »
HP certainly made plotters that had GPIB, or rather HP-IB as they called it. I think there were printers too but I don't know for sure. I'm not sure what Commodore peripherals used it but it seems like there was a disk drive. While generally considered exotic on a computer, GPIB is rather simple to implement, in some cases it was done with discrete logic without even having a microprocessor involved.

I guess that the Commodore PET computer, was such a long time ago (depending on your point of reference), that many of the interface standards, we take for granted these days either did not exist or were in their early days, and so were crazily expensive or otherwise impractical.

GPIB NOT needing to have microprocessors/microcontrollers in the implementation, was probably a very good idea then. Because MPU/MCU stuff, was only gradually beginning to appear, then.

Commodore maybe hoped that the IEEE-488/GPIB interface, would lead to increased sales in market areas they were interested in.

It is all too easy to mock the IEEE-488/GPIB interface, now, with HUGE amounts of hindsight. But back then, maybe it was sensible to think it might take off and/or be useful in some computer sales markets, such as Scientific/Electronic and educational areas.

The Commodore Pet had a nice, solid all-in-one, kind of quality to it. Whereas using separate microcomputers of the time, such as the ZX81 (actually it probably came out a good few years later, I'm NOT 100% sure), were much messier, needing to plug into separate TVs and cassette tape recorders and power supplies. So had lots of messy cables all over the place and did not have the strong/secure/quality feel of the Commodore Pet computer.

With Machine code (Assembly language), it was even extremely powerful/fast/straightforward for the time era, with 8K of Ram. Machine code was practicable in those days, unlike todays, many thousands of hard to remember, complicated X86 (I mean the much later add on 64+ bit (and greater number of bits) instruction sets, such as AVX2) instructions (including all the new/extra ones, such as AVX-512, which is not easily/commonly available yet).
The built in Basic wasn't bad either, and fast enough for many things.
« Last Edit: June 11, 2017, 08:34:14 am by MK14 »
 

Online Kleinstein

  • Super Contributor
  • ***
  • Posts: 14080
  • Country: de
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #32 on: June 11, 2017, 09:12:14 am »
Commodore periphery used the IEEE-488 bus: so there where disk drives, printers and even a hard drive with IEEE-488 interface. At school we used some of those later PETs.

On the computer side there is rather little hardware to make the interface. So it was a sensible decision. So they could use existing periphery and might sell there parts for use with HP computers.

The funny thing was that the disk drives had more processing power than the PET. Some had 2 6502 CPUs (even the 2 MHz version, to get some spare timing) working on a shared memory: one mainly to do the floppy raw signal decoding. I might still have a board from such a floppy.
 
The following users thanked this post: MK14

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #33 on: June 11, 2017, 09:30:13 am »
Commodore periphery used the IEEE-488 bus: so there where disk drives, printers and even a hard drive with IEEE-488 interface. At school we used some of those later PETs.

On the computer side there is rather little hardware to make the interface. So it was a sensible decision. So they could use existing periphery and might sell there parts for use with HP computers.

The funny thing was that the disk drives had more processing power than the PET. Some had 2 6502 CPUs (even the 2 MHz version, to get some spare timing) working on a shared memory: one mainly to do the floppy raw signal decoding. I might still have a board from such a floppy.

Now you mention it, I think I also used such Pets (I used the original Pet as well, originally). I just either did not know, or had forgotten how they all (the devices) connected together in those days. To me it was just PCB edge card connectors, round the back of the Pet, rather than knowing exactly what it was. (This was a VERY long time ago).

The later Pets, with "real" keyboards, were better I guess, at least keyboard wise.

(nothing to do with Pets) RS232, seemed to survive for ages (on PCs), although it was especially slow, especially with the older/original baud rates. 115K was NOT too bad. Usually very robust and reliable as well. Great for electronics (apart from the slowness).

I must admit, I remember using GPIB (IEEE-488), probably for Electronics (NOT related to Pets, I think). But it was a rather a long time ago, and I've forgotten (for now), what I was doing and why (probably for doing tests within Electronics I guess). I vaguely remember it was something to do with a test equipment setup, with some kind of black boxed test instrument receiving the commands. There was a table of values (probably different commands) in a manual. Sending it signals to do something, or similar.
Maybe a signal generator (maybe a Wavetek function generator) ?
« Last Edit: June 11, 2017, 09:43:19 am by MK14 »
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: OTP EPROM programmer
« Reply #34 on: June 11, 2017, 02:52:29 pm »
The first thing that struck me about it was the 8 MHz crystal. Usually I'm use to it being some weird/complicated frequency, such as 3.579545 MHz or 4.43361875 MHz (yes, I know those are for transmission to TV's for NTSC/PAL), but usually I see funny numbers, such as 12.13643636797 MHz (hypothetical number), because it divides up to eventually make 60/50 Hz with the required number of scan lines and pixels, etc.


The PET used a combination of PAL horizontal timing and NTSC (60Hz) vertical timing. In reality, the horizontal (line scan) frequency difference between PAL and NTSC is so small it makes no difference. The major timing difference between the two standards is in the number of lines and the resultant frame rate. NTSC has a lower vertical resolution, so the frame rate is faster. The PAL line rate of 15625Hz is evenly divisible into 8M, while the NTSC rate of 15750Hz would have required an odd-ball crystal frequency of 8.064MHz. The 1MHz clock for the 6502 was derived from this 8MHz clock, and there are probably good reasons for wanting a round figure of exactly 1MHz here (simplified serial baud rate calculations, etc), so a standard 8MHz crystal master clock just makes sense.

8MHz was the pixel clock; a period of 125nS, giving 512 pixels for each complete 64uS (1/15625) line period. The characters themselves consist of an 8x8 pixel grid and for the 40 column display 320 (40x8) pixels (40uS) of those 512 total form the visible portion of each line period. The vertical resolution thus required for the 25 rows of characters is 200 lines. The display is non-interlaced, with ~260 lines total, of which all but the 200 are blanked, for a frame rate very close to 60Hz.

The PET-2001 was provided a video and sync breakout for connection to an eternal 60Hz monitor, but I've not found any evidence that a 50Hz (PAL-timing compatible) version of the motherboard was ever made. Since most users probably would have never used anything but the internal monitor, I guess it's not surprising that CBM never bothered with a 50Hz version. Maybe if you lived in a PAL/50Hz region/country and wanted to connect to an external screen CBM may have offered to internationally ship you a 60Hz one!

Living in a 50Hz land, I've designed my video generator board to operate at a 50Hz (actually 50.08Hz to be precise) frame rate, with 312 vertical lines. This just results in the vertical height of the 200-line visible portion of the display on a 50Hz monitor/TV being a bit less than the original 60Hz one as displayed on a 60Hz monitor/TV. In the final build I will provide line count and vertical synchronization decode logic for both 50Hz and 60Hz field rates, jumper-selectable on board.

One thing to keep in mind though, is that in the 50Hz display mode, the PET will actually run proportionately slower in some operations. The vertical video blanking interval signal interrupts the CPU via one of the two PIA chips and clocks the internal timing module in the single VIA chip. When updating masses of characters on the screen in the "slow" update mode (such as scrolling a screen of text, which requires reading almost all locations of screen memory and writing back to row-shifted positions), the CPU does only what it can fit in during the vertical blanking periods. Also programs using the internal "real time clock" module of the VIA (actually just a presettable counter that overflows after accumulating 24 hours worth of 60Hz cycles) won't keep accurate time with the display in 50Hz mode, as they would have originally been written assuming a 60Hz clock.

I'm not 100% certain yet, but it looks to me like the frame rate processor interrupt is handled by PIA#1 totally independently of the RTC of the VIA. For video RAM writing to operate as it should the processor interrupt must remain locked to the video generator regardless of the frame rate, but I currently cannot see a reason why I cannot simply get around the RTC issue by providing a separate (always) 60Hz clock source for the timer input of the VIA.   
   


« Last Edit: June 11, 2017, 03:07:15 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: MK14

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #35 on: June 11, 2017, 03:24:00 pm »
I see.
Yes, long term (decades) uncovered UV windowed EPROM's, are suppose to be in significant risk of dataloss, I agree!


The funky UV-EPROM behaviour has now been solved! When an EPROM is erased all bytes attain a value of $FF. It appears that all those years of storage in almost complete darkness without the window covered brought my EPROM to the very precipice of total erasure. What I was seeing on the screen (and you are literally seeing the individual bits of whole bytes here), with those bytes randomly alternating between $FF and the programed values were bytes that couldn't make their mind up if they were erased or not! It's curious to note that there was a hysteresis-like effect, where, initially, the application of light through the window for a short time actually restored the unstable data, but guess what? I went out for dinner this evening neglecting to stick that blob of Blu-Tack back over the window and now my EPROM is giving me nothing but $FFs! Well F me, now I'm screwed until my programmer turns up.
   
« Last Edit: June 11, 2017, 03:27:55 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: MK14

Offline SeanB

  • Super Contributor
  • ***
  • Posts: 16272
  • Country: za
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #36 on: June 11, 2017, 06:57:55 pm »
Tip for reading those EPROMS on the edge of erasure is to vary the supply voltage. If it is 4V5 it might read a degraded cell as a logic 1, but if you raise the supply voltage to 5V5 it will likely read it as a logic 0 instead, as the discrimination between logic levels is done with simple comparators and these are sensitive to supply voltage.

Old proper EPROM programmers did have a facility to verify the devices on both 4V and at 6V5, ensuring that the cells were well into the correct region, and would not slowly degrade with time leading to this erratic supply voltage dependancy.  You could either pop out the Vcc pin and supply it from an external supply, using a DIP socket stack for this, or supply the whole programmer from a USB hub and use an external power supply for the hub to up the voltage to give 5V5 on the Vcc pin when enabled.
 
The following users thanked this post: GeorgeOfTheJungle

Offline boffin

  • Supporter
  • ****
  • Posts: 1027
  • Country: ca
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #37 on: June 11, 2017, 07:32:33 pm »
When you get it all working, you can display the easter egg by typing

WAIT 6502,20

(changing the last number changes the quantity)

As for RAM in the PET, the later 2001s (without the builtin cassette) used 4116s,  as I remembering soldering the 2nd row of them in mine.

Lastly, there's a pin on the GPIO that when held low or high (don't remember) and you fire an NMI, it takes to you to a simple ROM monitor.  You should be able to find details about that on the net.  Again, this might be a 2nd series option.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #38 on: June 12, 2017, 12:39:29 am »
I see.
Yes, long term (decades) uncovered UV windowed EPROM's, are suppose to be in significant risk of dataloss, I agree!


The funky UV-EPROM behaviour has now been solved! When an EPROM is erased all bytes attain a value of $FF. It appears that all those years of storage in almost complete darkness without the window covered brought my EPROM to the very precipice of total erasure. What I was seeing on the screen (and you are literally seeing the individual bits of whole bytes here), with those bytes randomly alternating between $FF and the programed values were bytes that couldn't make their mind up if they were erased or not! It's curious to note that there was a hysteresis-like effect, where, initially, the application of light through the window for a short time actually restored the unstable data, but guess what? I went out for dinner this evening neglecting to stick that blob of Blu-Tack back over the window and now my EPROM is giving me nothing but $FFs! Well F me, now I'm screwed until my programmer turns up.
 

Are you sure you don't have the out enable, or chip select, or upper address IO pin on your bread board open?  These CMOS eproms inputs can behave like 74HC logic and my just begin working due to charge on such an IO.  Try partially re-seating your eprom, bend the pinst and re-seat the wiring around it.

Such lemon breadboarding has caused me such headaches in the past.  Usually holding 1 finger on VCC and stroking the eprom IO pins, then once again with you finger on GND might reveal the true nature of your problem which I bet isn't a sensitivity to a little light entering the eprom window.

« Last Edit: June 12, 2017, 12:42:26 am by BrianHG »
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #39 on: June 12, 2017, 12:59:51 am »
Are you sure you don't have the out enable, or chip select, or upper address IO pin on your bread board open?  These CMOS eproms inputs can behave like 74HC logic and my just begin working due to charge on such an IO.  Try partially re-seating your eprom, bend the pinst and re-seat the wiring around it.

Such lemon breadboarding has caused me such headaches in the past.  Usually holding 1 finger on VCC and stroking the eprom IO pins, then once again with you finger on GND might reveal the true nature of your problem which I bet isn't a sensitivity to a little light entering the eprom window.


Totally sure, all the connection are fine. I tried Sean's suggestion of ramping up the supply voltage. 74HC logic is speced to 6V and in some cases won't blow until 9V or so, but I'm not too sure about my Fox crystal oscillator module, so I went to 6V, but it didn't make a difference unfortunately. It looks like the several hours under my strong bench light finally wiped this one clean.
 
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline CJay

  • Super Contributor
  • ***
  • Posts: 4136
  • Country: gb
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #40 on: June 12, 2017, 10:51:00 am »
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.

Overburn it, I.E. if you have a programmer that will allow you to write data to a non blank device, write a copy of the original data to the chip.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: OTP EPROM programmer
« Reply #41 on: June 12, 2017, 11:39:10 pm »
The first thing that struck me about it was the 8 MHz crystal. Usually I'm use to it being some weird/complicated frequency, such as 3.579545 MHz or 4.43361875 MHz (yes, I know those are for transmission to TV's for NTSC/PAL), but usually I see funny numbers, such as 12.13643636797 MHz (hypothetical number), because it divides up to eventually make 60/50 Hz with the required number of scan lines and pixels, etc.


The PET used a combination of PAL horizontal timing and NTSC (60Hz) vertical timing. In reality, the horizontal (line scan) frequency difference between PAL and NTSC is so small it makes no difference. The major timing difference between the two standards is in the number of lines and the resultant frame rate. NTSC has a lower vertical resolution, so the frame rate is faster. The PAL line rate of 15625Hz is evenly divisible into 8M, while the NTSC rate of 15750Hz would have required an odd-ball crystal frequency of 8.064MHz. The 1MHz clock for the 6502 was derived from this 8MHz clock, and there are probably good reasons for wanting a round figure of exactly 1MHz here (simplified serial baud rate calculations, etc), so a standard 8MHz crystal master clock just makes sense.

8MHz was the pixel clock; a period of 125nS, giving 512 pixels for each complete 64uS (1/15625) line period. The characters themselves consist of an 8x8 pixel grid and for the 40 column display 320 (40x8) pixels (40uS) of those 512 total form the visible portion of each line period. The vertical resolution thus required for the 25 rows of characters is 200 lines. The display is non-interlaced, with ~260 lines total, of which all but the 200 are blanked, for a frame rate very close to 60Hz.

The PET-2001 was provided a video and sync breakout for connection to an eternal 60Hz monitor, but I've not found any evidence that a 50Hz (PAL-timing compatible) version of the motherboard was ever made. Since most users probably would have never used anything but the internal monitor, I guess it's not surprising that CBM never bothered with a 50Hz version. Maybe if you lived in a PAL/50Hz region/country and wanted to connect to an external screen CBM may have offered to internationally ship you a 60Hz one!

Living in a 50Hz land, I've designed my video generator board to operate at a 50Hz (actually 50.08Hz to be precise) frame rate, with 312 vertical lines. This just results in the vertical height of the 200-line visible portion of the display on a 50Hz monitor/TV being a bit less than the original 60Hz one as displayed on a 60Hz monitor/TV. In the final build I will provide line count and vertical synchronization decode logic for both 50Hz and 60Hz field rates, jumper-selectable on board.

One thing to keep in mind though, is that in the 50Hz display mode, the PET will actually run proportionately slower in some operations. The vertical video blanking interval signal interrupts the CPU via one of the two PIA chips and clocks the internal timing module in the single VIA chip. When updating masses of characters on the screen in the "slow" update mode (such as scrolling a screen of text, which requires reading almost all locations of screen memory and writing back to row-shifted positions), the CPU does only what it can fit in during the vertical blanking periods. Also programs using the internal "real time clock" module of the VIA (actually just a presettable counter that overflows after accumulating 24 hours worth of 60Hz cycles) won't keep accurate time with the display in 50Hz mode, as they would have originally been written assuming a 60Hz clock.

I'm not 100% certain yet, but it looks to me like the frame rate processor interrupt is handled by PIA#1 totally independently of the RTC of the VIA. For video RAM writing to operate as it should the processor interrupt must remain locked to the video generator regardless of the frame rate, but I currently cannot see a reason why I cannot simply get around the RTC issue by providing a separate (always) 60Hz clock source for the timer input of the VIA.   
 

Thanks, that's amazing!

(sorry for my slow response)

I wondered if the 8 MHz signal was used to make the 1 MHz for the main 6502 system, and it was, so you answered  my question, even before I asked it  :)

So 8 MHz = 8,000,000 / 15625Hz (PAL) = 512 = A nice binary dividable number, and a reasonable number of scan lines (including BLANK ones) to make a picture with. Nice/neat, and 8MHz crystals were probably cheaper (as it presumably was a mass market, popular frequency).

The fact you are aiming for the Commodore Pet, is probably helped because it has few or no (I think), exotic or custom chips in it. Whereas the Commodore C64 (I think), has got a number of custom/exotic chips in it. Such as the graphics and nice sound generators, onboard. I think they must have been "cracked" to an extent, because there are many software emulators available for the C64 and similar computers. So I guess the information is out there, if you wanted to go to the trouble of reproducing them in an FPGA or something. But the Pet doesn't need such hard work, making it a much more sensible choice.

Looking back, I'm amazed that something so slow (1 MHz 6502), relatively speaking and with so little memory, can be so powerful.
E.g. We are at a few GHz rather than 1 MHz, 32/64 bit instead of 8 bits, many instructions per clock cycle instead of one or more cycles per instruction, and many cores rather than a single core etc.
Also 8K (typically) of ram, instead of many gigabytes of Ram.

Yet the space invaders and Chess were nice games, and fairly powerful programs could be run on it.

Anyway good luck with your project  :)
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #42 on: June 12, 2017, 11:57:50 pm »
I see.
Yes, long term (decades) uncovered UV windowed EPROM's, are suppose to be in significant risk of dataloss, I agree!


The funky UV-EPROM behaviour has now been solved! When an EPROM is erased all bytes attain a value of $FF. It appears that all those years of storage in almost complete darkness without the window covered brought my EPROM to the very precipice of total erasure. What I was seeing on the screen (and you are literally seeing the individual bits of whole bytes here), with those bytes randomly alternating between $FF and the programed values were bytes that couldn't make their mind up if they were erased or not! It's curious to note that there was a hysteresis-like effect, where, initially, the application of light through the window for a short time actually restored the unstable data, but guess what? I went out for dinner this evening neglecting to stick that blob of Blu-Tack back over the window and now my EPROM is giving me nothing but $FFs! Well F me, now I'm screwed until my programmer turns up.
 

I would imagine the "Cells" of the EPROM are like tiny capacitors, which have (unfortunately) lost most of their charge, over the decades and maybe because of the uncovered window. So the (part) analogue circuitry that reads them, deciding if it is a logic 1 or 0, is probably having a very hard time, as they are extremely marginal by now, it seems.
So (as other(s) in this thread have said, anyway), the slightest change in temperature, voltage, light level while the UV window is unobstructed and perhaps other things, such as if it is raining or not in Spain and the moon phase of Jupiter's, sixty third moon. All take their toll.
https://simple.wikipedia.org/wiki/List_of_Jupiter%27s_moons

I always hoped that the 10 year data lifetime of EPROMS was a very severe/safe specification. So that in practice they would last considerably longer than this. Otherwise all sorts of older stuff (non-mask ones), would potentially break, and (if the original ROM code data is unavailable), become permanently flummoxed.
E.g. A favourite piece of test gear, losing its calibration and/or programs. Hence becoming a useless unfixable piece of ex-favourite gear, sadly.

I have seen millions of arguments, as to if EPROMS can be erased by allowing "normal" light into its uncovered window. Some people say they left an EPROM outside, for weeks on end, in an attempt to erase it, without an expensive UV eraser. With NO luck, it remains programmed.
While others, say that an uncovered UV window, under florescent lighting, managed to erase itself (unintentionally), after a few weeks of such abuse.

So I don't know who to believe.

There are also rumours (or theories), that poor quality, cheap, EPROM programmers can too weakly or poorly program EPROMS, so that the program/data prematurely erases/corrupts itself. Apparently expensive ones use complicated techniques to both very quickly and yet very reliably program them. E.g. extended voltage ranges to ensure it is done right (as already mentioned in this thread by someone else).
« Last Edit: June 13, 2017, 12:02:02 am by MK14 »
 

Offline daybyter

  • Frequent Contributor
  • **
  • Posts: 397
  • Country: de
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #43 on: June 13, 2017, 02:23:45 am »
There is currently a discussion on the jmp (adr) opcode, which is buggy on the 6502, but fixed in the 65c02 series, it seems. So it might happen, that some software is not 100% compatible with your machine.
 

Offline CJay

  • Super Contributor
  • ***
  • Posts: 4136
  • Country: gb
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #44 on: June 13, 2017, 07:02:52 am »
I have seen millions of arguments, as to if EPROMS can be erased by allowing "normal" light into its uncovered window. Some people say they left an EPROM outside, for weeks on end, in an attempt to erase it, without an expensive UV eraser. With NO luck, it remains programmed.
While others, say that an uncovered UV window, under florescent lighting, managed to erase itself (unintentionally), after a few weeks of such abuse.

There's a note from one manufacturer that discusses the same scenarios you mention above and gives estimated erasure times for them so I'd be inclined to believe them, I linked it in another thread here.

It takes time and you don't get *good* erasure so you often end up with a corrupt bit here and there first, lots of types of window glass do a good job of blocking UV as well so are more/less effective depending where you got your windows from.

Direct sunlight does a better job of corrupting EPROMS.

Fluorescents emit a non zero amount of UV so they'll eventually corrupt an EPROM too.

I saw many years ago an erase timer that constantly read the EPROM until all it got back was $FF, I think it may have been a project in Elektor summer circuits?


So I don't know who to believe.

There are also rumours (or theories), that poor quality, cheap, EPROM programmers can too weakly or poorly program EPROMS, so that the program/data prematurely erases/corrupts itself. Apparently expensive ones use complicated techniques to both very quickly and yet very reliably program them. E.g. extended voltage ranges to ensure it is done right (as already mentioned in this thread by someone else).

Poor programming I believe is related to the algorithm used (fast programming was 'secret sauce' from some manufacturers and algorithms were often under NDA) and possibly limitations of the programming hardware, the tip about reading at different voltages is pertinent, for a chip to be considered production reliable some manufacturers suggest it has to be programmed and verified at a range of voltages.

Microchip publish data about the difference between Production and Development programmers for PICs, I *think* unless proven wrong, that they would probably be applicable to data EPROMs too.
 
The following users thanked this post: MK14

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #45 on: June 13, 2017, 07:15:46 am »
EPROMS were at least "fun", in the past, when they were a lot more commonly used.
I vaguely remember that the extended voltage range is for something like, that if it is programmed at the highest possible voltage, it will be fine at lower voltages. But if it were programmed at a lower voltage, it may be in trouble at higher voltages.
Or maybe it's the other way round, I can't remember the exact details.

Obviously (for non-RETRO projects) Flash is the modern day EPROM at the moment.
Sooner or later (or now if you count FRAM, but it tends to be pricey, a bit fussy and relatively low capacity), I guess something more ideal, will turn up. Which is economically priced, high capacity, low power, fast, extremely long term data-retention, infinite or very high write/erase cycle lifetimes, and easy/straightforward to use.
« Last Edit: June 13, 2017, 07:20:51 am by MK14 »
 

Offline CJay

  • Super Contributor
  • ***
  • Posts: 4136
  • Country: gb
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #46 on: June 13, 2017, 10:08:39 am »
EPROMS were at least "fun", in the past, when they were a lot more commonly used.
I vaguely remember that the extended voltage range is for something like, that if it is programmed at the highest possible voltage, it will be fine at lower voltages. But if it were programmed at a lower voltage, it may be in trouble at higher voltages.
Or maybe it's the other way round, I can't remember the exact details.

Obviously (for non-RETRO projects) Flash is the modern day EPROM at the moment.
Sooner or later (or now if you count FRAM, but it tends to be pricey, a bit fussy and relatively low capacity), I guess something more ideal, will turn up. Which is economically priced, high capacity, low power, fast, extremely long term data-retention, infinite or very high write/erase cycle lifetimes, and easy/straightforward to use.

I dunno, I don't really have an issue with flash for retro, it's all data and the early DIP flash chips were pin compatible so it's not that much of a stretch in my mind.

I still like EPROM and I've just got hold of a really nice, old EPROM programmer so I'm going to dig out all the old ROMs I've got kicking around and read them out, might be informative as to data retention as I've not taken great amounts of care to ensure they were stored well. A lot of them have checksums written on labels or chip bodies.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #47 on: June 13, 2017, 02:26:19 pm »
I dunno, I don't really have an issue with flash for retro, it's all data and the early DIP flash chips were pin compatible so it's not that much of a stretch in my mind.

I still like EPROM and I've just got hold of a really nice, old EPROM programmer so I'm going to dig out all the old ROMs I've got kicking around and read them out, might be informative as to data retention as I've not taken great amounts of care to ensure they were stored well. A lot of them have checksums written on labels or chip bodies.

What's nice about the EPROMS is the way the work flow works with them, which is handy.

E.g. You can have a set with the previous software and/or a known working version nicely labeled up, so that if the unit suddenly starts messing up, you can instantly go back by putting the previous (or an older) version in to see if the hardware has broken, or you have messed up with the software.

The twenty minutes erase time (can be fifteen minutes, or longer than twenty), gives you time to think about what you are doing with the software, rather than rushing through with it and making mistakes. Although you can keep a tiny stock pile of erased EPROMS, ready.

Flash (assuming there is at least a slight in circuit programming capability) can be corrupted, during bad power down, software crashes or even while it is being written (in circuit), and the power switches off too soon or a reset occurs in the middle of it performing writes. Strictly speaking that really shows poor circuit design and/or a lack of enough capacitance to hold the supply rails up, during an unexpected power disconnection or similar, but even so.
Whereas EPROMS are more dependable in that sense. Which is nice.

I think what I'm relatively pleased to see the back of, is the OTP's (One Time Programmable devices). I suppose they are fine for production, as long as the software/data never changes. But for development, they are a pain. Pressuring you to either have extremely few software versions, or seek out complicated ways of getting prototypes to have non-OTP capabilities, such as EPROMS or battery backed-up CMOS SRAM EPROM/OTP simulators or similar.
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #48 on: June 20, 2017, 09:58:54 am »
My programmer arrived today; just flashed the AT27C256 OT PROM with the original PET character ROM images, resurrecting the video generator.

There were two OS versions for the PET-2001, the original, called BASIC#1, being rewritten (and thus dubbed BASIC#2) soon after the machines release to fix a number of bugs, mostly relating to serial I/O operations. The character ROM was slightly different for each version of basic also. Since a single 32 kb PROM will hold both versions of BASIC, I'm going to accommodate both OSs for the greatest software compatibility.

The character PROM has been burnt with both BASIC #1 & #2 character sets. I'll have the MS address bit of both the character ROM and the OS ROM asserted by an "Operating system select" switch.

Here is (just for now) a screen shot showing a random garble of characters from the PET BASIC#1 character set (this crappy TV has a rather poor composite video signal image quality compared to my 1084S). I've got all of the other bits (65C02, VIA, PIA, chips etc) now too. Hopefully by the end of the coming weekend I'll have the operating system booting.





 
« Last Edit: June 20, 2017, 11:13:04 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #49 on: June 22, 2017, 02:21:15 pm »
Just plodding through my design/build................

I've been studying the operation of the 6502 in depth and after perusing lots of home brew systems posted on the internet have come to the conclusion that most constructors out there don't have a clue about properly interfacing a 6502 to non 65XX-family memory/peripherals. I finally stumbled upon this pertinent article (confirming my suspicions) detailing aspects of the 6502's write cycles and timing issues that anyone interested in actually implementing a 6502 system properly really needs to know:

http://www.atarimagazines.com/computeii/issue1/page9.php

Scroll down to "6502 Write timing" for the most important part. To properly implement (so as to not possibly impinge upon setup/hold times of a prior read cycle) the memory !write stobe for non 65XX-family parts you need to NAND a inverted version of R/W with the PH2 clock.

With the super fast WDC65C02, the minimum spec for THW is only 10nS. Suppose you NAND !R/W and PH2 with a 74HC00. That will delay the rising edge of your write strobe (upon which the data is latched) by a gate delay of approx ~20nS - that's 10nS later than the minimum time that the data is guaranteed to remain on the bus! If, for example, you have your system RAM data lines connected directly to the 6502 data bus (that is not buffered by a bi-directional octal transceiver to impart a equal or greater amount of delay effectively adding to THW) then you can probably forget about seeing it working.

These issues can be worked around for sure (I'm using fast 74AC logic to generate my universal write strobe, for minimal delay) and adding (otherwise superfluous) data line buffering for my system RAM just for the added delay to ensure that I meet minimum specs. for all read/write setup and hold times), but you really need to study and understand these specifications to ensure that you're not going to build something that is inherently unstable or occasionally flaky.
 



 
   


 
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #50 on: June 23, 2017, 01:01:16 pm »
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.
 

« Last Edit: June 23, 2017, 01:25:26 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #51 on: July 01, 2017, 05:14:10 pm »
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! ;D 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...

« Last Edit: July 01, 2017, 05:21:30 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
PET-2001 clone running Space Invaders
« Reply #52 on: July 15, 2017, 07:26:22 am »
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 ;D   

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     

« Last Edit: July 16, 2017, 04:24:34 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline CJay

  • Super Contributor
  • ***
  • Posts: 4136
  • Country: gb
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #53 on: July 15, 2017, 07:52:05 am »
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)
 

Offline SeanB

  • Super Contributor
  • ***
  • Posts: 16272
  • Country: za
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #54 on: July 15, 2017, 02:25:59 pm »
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.
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #55 on: July 16, 2017, 02:19:41 am »
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  :D

Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #56 on: July 16, 2017, 02:24:45 am »
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.
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #57 on: July 16, 2017, 02:28:34 am »
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?

Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #58 on: July 16, 2017, 04:12:05 am »
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.
« Last Edit: July 16, 2017, 04:22:43 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline chickenHeadKnob

  • Super Contributor
  • ***
  • Posts: 1054
  • Country: ca
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #59 on: July 16, 2017, 05:45:52 am »
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.
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #60 on: July 16, 2017, 01:39:36 pm »
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.
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline CJay

  • Super Contributor
  • ***
  • Posts: 4136
  • Country: gb
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #61 on: July 17, 2017, 08:42:34 am »
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?
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #62 on: July 18, 2017, 10:05:37 am »
Ha ha, you might be missing a keyboard or two if that was the case.
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: PET-2001 clone running Space Invaders
« Reply #63 on: July 18, 2017, 04:51:15 pm »
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!  :D
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #64 on: July 24, 2017, 11:43:00 am »
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.

« Last Edit: July 24, 2017, 12:18:35 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: PET-2001 clone running Space Invaders
« Reply #65 on: July 24, 2017, 12:24:08 pm »
, not only was the front cover intact, but I also had a spare!  :D


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......
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #66 on: August 12, 2017, 07:21:19 am »
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 16dec, the internal shift register (outputting to pin CB2) is programmed to free run at a clock rate determined by internal timer#2:

Quote
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 15dec (00001111) gives you a square wave. 51dec (00110011) gives you a square wave one octave higher in frequency while 85dec (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



« Last Edit: August 12, 2017, 10:14:25 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #67 on: August 12, 2017, 07:32:33 am »
It sounds like the classical Laurel and Hardy tune.

 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #68 on: August 12, 2017, 07:48:44 am »
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!  :P
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #69 on: August 12, 2017, 08:06:47 am »
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.
     
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #70 on: August 12, 2017, 09:54:45 am »
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 15dec (ON) and zero (OFF).

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

« Last Edit: August 12, 2017, 10:01:13 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #71 on: August 12, 2017, 04:27:10 pm »
Here you go...

 

Offline Bicurico

  • Super Contributor
  • ***
  • Posts: 1707
  • Country: pt
    • VMA's Satellite Blog
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #72 on: August 12, 2017, 05:16:28 pm »
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

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #73 on: November 26, 2017, 02:58:53 am »
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.........



« Last Edit: November 26, 2017, 03:06:37 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: [s]OTP EPROM programmer[/s] PET-2001 clone.
« Reply #74 on: April 25, 2018, 12:49:43 pm »
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.





« Last Edit: April 25, 2018, 01:10:06 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: mikerj, NivagSwerdna

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3233
  • Country: gb
Re: Cloning a Commodore PET-2001
« Reply #75 on: April 25, 2018, 04:16:15 pm »
Fantastic project! I seem to be missing the time and motivation to do this kind of thing these days.
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #76 on: April 25, 2018, 04:19:48 pm »
It's totally cool, although I think if I were going to do it I'd just put the whole thing in a small FPGA, though there is something neat about "real" hardware.

The PET is simple enough that it could probably be put into the same hardware as this http://searle.hostei.com/grant/Multicomp/  I've built all the variations and it works great.
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #77 on: April 26, 2018, 02:45:15 am »
Yeah, that was discussed earlier in the thread. Here I'm just making use of the current production 6502/6521/6522 variants/equivalents currently produced by WDC and sold by Mouser. It's just fun to functionally clone a ~40 year old computer basically the old fashioned way using entirely current production discrete CMOS logic, uP and peripherals.
 
The (Z80) TRS80 model 1 is next on my list. I don't think that there are too many other "mini" computers from the era which can be cloned this way (not requiring NOS chips no longer manufactured).

Given the almost cult following and nostalgia for the 6502, I'm surprised that so far I appear to be the only one around here building a 8-bit machine with the modern WDC 65XX parts.
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #78 on: April 26, 2018, 04:52:00 pm »
That really is pretty cool. The surprising aspect is just how few parts are on that board even using individual components. It's also a bit surprising that in 2018 there is still a current production DIP packaged 6502.
 

Offline LaserSteve

  • Super Contributor
  • ***
  • Posts: 1270
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #79 on: April 26, 2018, 06:56:00 pm »
If you clone the TRS-80, make sure you do an expansion interface. Its pretty much a paperweight without one.
I imagine a CSAVE/CLOADusing wav files is a lot better then using the cassette player.

I wonder if all those trash-80 magazines with their One Line Program competitions are still one line.
A 16K Level II TRS-80 would burn a lot of memory for every new program line. A tradition appeared for writing one line programs to save ram.

Answered my own question about one liners...

Edit, Yep.. Lots of them...

https://www.muppetlabs.com/~breadbox/software/trs80-oneliners.html

I gave my TRS-80 to a Russian immigrant kid in the late 90s, you would have thought I had given him a Mainframe or a Cray given the look on his face.

I still have the "TRS-80 modular furniture system" desk. Yes, the Shack once sold computer furniture.

Steve
« Last Edit: April 26, 2018, 07:09:51 pm by LaserSteve »
"What the devil kind of Engineer are thou, that canst not slay a hedgehog with your naked arse?"
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #80 on: April 28, 2018, 08:43:12 am »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline jthomas

  • Newbie
  • Posts: 5
  • Country: gb
Re: Cloning a Commodore PET-2001
« Reply #81 on: April 29, 2018, 10:35:05 am »
Looking forward to seeing the rest of the schematic! I'd love to have a go at laying out my own single-board PCB for the thing... a clone of a clone if you will :D

I have a possibly silly question about the video section though - what do the two ROMs U117/118 do? The rest of the circuit looks very similar to one I've already built in the past but I can't seem to figure out on my own what their role is in this case.

Just about the only thing I can think of is converting X/Y addressing to straight binary or vice-versa (so as not to leave "holes" of unused memory)... I'd appreciate having it explained to me as not knowing will annoy me!  |O
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #82 on: April 29, 2018, 02:21:40 pm »
Those ROMs just map the 1000 video memory character locations called by the CPUs operating system (40 horizontal characters [columns] x 25 vertical characters [rows] = 1000 character locations) to the ones in the video RAM that actually correspond to those locations on the screen.

In the video RAM there are 14 unused character column positions per horizontal row (40 of 64 used) and there are a total of 39 rows, of which only 25 are used = a total of 2496 memory locations. This is why the video SRAM has a 12-bit address, while the actual video board address bus is only 10 bits.

Using look-up table ROM for this just simplifies the circuitry as you can then just address the video RAM directly from the pixel and line counters while drawing the display. The original PET hardware instead used a separate address counter for the video RAM (that was continuously stopped and started during the visible field) in combination with a required address location memory/latch, and some convoluted logic to control it all. Back in the day it wouldn't have been economical to waste video memory this way, but now we have 256k-bit SRAMs for pennies.

   
« Last Edit: April 29, 2018, 02:27:09 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: jthomas, derree

Offline jthomas

  • Newbie
  • Posts: 5
  • Country: gb
Re: Cloning a Commodore PET-2001
« Reply #83 on: April 29, 2018, 03:05:04 pm »
Thank you for the explanation :D
 

Online ebastler

  • Super Contributor
  • ***
  • Posts: 6206
  • Country: de
Re: Cloning a Commodore PET-2001
« Reply #84 on: April 29, 2018, 04:02:18 pm »
That really is pretty cool. The surprising aspect is just how few parts are on that board even using individual components.

Well, there weren't too many components on the original board.
Combine the RAMs and ROMs into higher capacity ICs, and there are not that many chips left:



 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Cloning a Commodore PET-2001
« Reply #85 on: May 01, 2018, 05:53:03 am »
How about a CoCo clone ? :), the three important chips are sitting in one of my parts drawers since... a couple of years :)

Fantastic work !
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #86 on: May 21, 2018, 01:41:17 pm »
Okaayyyyyyy......

I've basically have the motherboard schematics finished now and drawn up in Protel. I was just about ready to start laying out the PCB Sunday night after "updating"/importing all of the component footprints to the PCB template from the schematics.

However I've made quite a few significant changes to the design over the initial crappy prototype and I just decided that it would be good to see the final circuitry working before committing to the PCB, just because. The changes were primarily regarding the manner in which the data bus from the CMOS W65C02 was buffered to the TTL-level-IO memory and N-version peripherals and the read/write decoding.

So this evening, to save time cooking and eating and all of that, I picked up a whopper with cheese and large fries from Hungry Jacks (burk!) on the way home from work, scoffed it down and then went straight into the shack. It was going to be way too hard to majorly rewire the crappy initial soldered prototype, so I unplugged all of the chips and went for breadboard instead.

Four hours later and I have the computer built to the absolute minimum hardware (nary a wire beyond) required for a system boot. The boot-up message didn't display for me on the initial power-up as I missed the wire from the address decoder to the !CS pin of the system RAM! I hope I'm not coming down with early-onset Alzheimer's disease or something.
 
Tomorrow if I feel like it I'll wire in PIA#1 - that will give me the blinking cursor and allow me to connect up my keyboard interface. Right now though I'm going to bed.

« Last Edit: May 22, 2018, 12:48:51 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: derree

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #87 on: May 26, 2018, 10:13:08 am »
I have finally finished the motherboard PCB layout.

I've added a few features not available in the original PET too. The ROM holds both V2 (sometimes referred to as V1) and V3 (sometimes referred to as V2 or "upgrade") BASIC. The version of BASIC to run is switch-selectable. There is also a RESET button, which saves having to power-cycle when the computer crashes, which it will if you change the position of the BASIC version select switch when the computer is running.

The original PET-2001 used 1/60s "jiffies" as the time interval for updating its software real time clock. The vertical frame rate from the video circuitry was the frequency reference. Since I designed my video generator to operate at a frame rate of 50 Hz, the real time clock will not keep accurate time., so as a work-around I included on the board an accurate 60 Hz clock source. A jiffy clock selector switch permits the CPU interrupt/sync to be taken either from the 60 Hz source or the video vertical frame rate.
However in the 60 Hz mode, the CPU will no longer be synchronized with the video frame rate and the PET's synchronized "snow free" display update mode won't operate without the snow. This is only a minor inconvenience as the 60 Hz switch need only be flicked when you want the PET to accurately measure time, and such applications generally aren't graphics intensive anyhow.
As an aside, AFAICT, the PET's original jiffy clock wasn't all that accurate anyway, as the 60 Hz field/frame must have been a little bit off frequency as it was derived by integer division in the video generation circuit of the 8 MHz master clock. 60 doesn't divide evenly into 8M. I used a stock 3.932160 MHz crystal in my oscillator, which is divided by 2^16 = 60 Hz exactly (a 74HC4060 followed by both halves of a 74HC74).

For sound effects/music there is an LM386 audio amplifier on board with volume control to drive an internal speaker, a source select switch and a -10dBV line-out buffer amp. The 4-pole rotary source select switch positions are OFF, VIA CB2, Cass. read & Cass write. VIA CB2 is for sound effects as demonstrated in this thread previously and the other positions allow you to listen in to either the input or output data streams of the cassette drives.

For the keyboard interface, I elected not to incorporate a PS2/USB interface on the motherboard, keeping the circuitry as per the original PET in this regard.
My PS2/USB keyboard interface will be a separate PCB design which will simply plug into the IDC26 keyboard matrix interface connector on the motherboard as an alternative option to either an original CBM keyboard or one hacked/rewired to suit.

That's all that's interesting that I can think of right now as it's past time for dinner. I'll be giving the whole thing one more thorough checking over again tomorrow. Hoping to have the board to load with bits in a couple of weeks.
       
« Last Edit: May 28, 2018, 05:15:58 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: derree

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #88 on: May 26, 2018, 05:32:02 pm »
Motherboard schematic teasers................



















« Last Edit: May 26, 2018, 05:35:43 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: zitt, derree

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #89 on: June 02, 2018, 12:09:01 pm »
Amazing service from Elecrow. I posted the Gerber files and ordered Sunday evening and the boards arrived Friday (yesterday) afternoon. I wasn't expecting to receive the boards prior to this weekend and haven't organized all of the parts yet, but I just loaded up what I had this afternoon.

Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: dave_j_fan, nad007007, zitt, derree

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #90 on: June 02, 2018, 06:41:28 pm »
That's a nice tidy looking board. Mounting holes in the corners, nice clean traces without any weird angles, looks good.
 

Offline kizmit99

  • Regular Contributor
  • *
  • Posts: 106
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #91 on: June 02, 2018, 08:25:10 pm »
Looking good  :-+
I just wanted to drop a note to say I'm enjoying watching this project progress.  While I don't post much here, I do post on other forums and I know that sometimes when you're updating progress on a long-term build that you can begin to wonder whether or not you're just talking to yourself.  So this is just to let you know that your updates are appreciated.  Thanks for posting!
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #92 on: June 03, 2018, 11:31:33 am »
Thanks for the comments.

I designed the board along the same rules as the video generator board to make it very easy to assemble and trouble shoot and not to cause any hassle with even the cheapest PCB fab. All tracks are routed out on a 50 thou grid spacing. This did make for a rather large board, but I guess a retro clone of a PET just wouldn't be right on anything else  :D
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: derree

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #93 on: June 09, 2018, 06:52:37 am »
Parts arrived yesterday, finished soldering up the motherboard this afternoon. The next step will be to layout a little board for my PS-2 keyboard interface and organise the hardware and connectors, etc, for completing this project into an enclosure. I'm going to assemble the computer into a 2U 19" rack case, with all of the I/O connectors and control switches mounted on the front panel.   

I also need to layout a small PCB for an analogue circuit to interface one of the PETs two digital cassette drive ports to general purpose/standard "mic." and "line-out" signal I/O for loading and saving programs to a non-Commodore audio recording/playback device. I originally thought to install this interface board inside the PETs enclosure, permanently plugged into cassette port #2 on the motherboard, but I now think I'll build up a "deluxe" version of this device as a separate stand-alone project in its own enclosure, as I'll be able to use such an interface to connect my other Commodore computers to external audio recorders too.     
 
I'm eager to get this project done and off the bench now as I have the circuitry for the TRS-80 clone pretty much done on paper now. Should be able to post some preliminary breadboard TRS-80 action in the not too distant future......  :D

« Last Edit: June 09, 2018, 06:55:15 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: zitt

Offline Delta

  • Super Contributor
  • ***
  • Posts: 1221
  • Country: gb
Re: Cloning a Commodore PET-2001
« Reply #94 on: June 09, 2018, 07:03:50 am »
To echo Kizmitt's comments, I haven't posted as I have precisely zero to contribute.  But as a C64 man and a fan of vintage electronics, I have been following with great interest, and think your project is bloody brilliant!
 
The following users thanked this post: GK

Offline kizmit99

  • Regular Contributor
  • *
  • Posts: 106
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #95 on: June 09, 2018, 04:04:04 pm »
I'm eager to get this project done and off the bench now as I have the circuitry for the TRS-80 clone pretty much done on paper now. Should be able to post some preliminary breadboard TRS-80 action in the not too distant future......  :D

Sweet!   :-+ :-+ :-+ Very interested to see where you take that one - I've always had a soft spot for the TRS-80.  It was my first computer (in '78 I think), I did so much hardware hacking on that poor machine it no longer looks anything at all like the original.  Still have it, plus another I bought from a friend sometime in the '90s - both still worked when last powered up (about 12 years ago  :(). 

Recently I used cloning the TRS-80 as a project to get up to speed on FPGAs, the plan is to do up a PCB with that design (and the minimal supporting analog hardware (like the cassette interface)) to get up to speed on where PCB tech is today.  The last time I did a PCB I think the layout and first prototype boards where something like $50K a pop (very early '90s, pretty high density mil-spec board admittedly) - so the thought of getting prototypes for $5 is just astounding to me...  Anyway, looking forward to see your take on the TRS-80!
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #96 on: June 10, 2018, 03:54:05 am »
I thought mention of the TRS-80 might get a bite  :) - that was quite a popular machine back in the day, particularly in America, the home of Radio Shack. I wonder how it compared to the PET?

My most tedious task so far for the TRS-80 project was manually writing the character set binary file. Unlike the PET, the TRS-80 didn't use a generic/jellybean EPROM for the character set, but used a Motorola mask ROM which was factory-programmable with the customers supplied character set.

I couldn't find an image binary file of this ROM on the net, but I did find nice graphic of the individual characters resolvable down to individual pixels. The TRS-80's character set is more primitive than the PET's, but that block graphics mode made it a lot more flexible for games and stuff. It's just a pity that the original designers didn't use the vertical video sync like the PET designers did as a CPU interrupt as a way of generating flicker-free writing to the screen.

I intend to functionally duplicate the whole of the TRS-80 model 1 including the expansion interface (with 48k of RAM total), with the exception of the floppy disc controller as the chip for that function is now only available NOS.

On the topic of character sets, I'm currently working on the documentation for my PET build - here is how I mapped in my PS-2 keyboard interface (as straightforward and logical as practical) the PET's 73 keys/functions to a modern keyboard layout. I've printed this out and laminated it to serve as a handy look-up card/reference when typing, though it's mostly only needed when you need to find a shifted graphics character.

Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: niladherbert

Offline kizmit99

  • Regular Contributor
  • *
  • Posts: 106
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #97 on: June 10, 2018, 04:41:01 pm »
It sounds like you did exactly what I had to do for that font ROM - at least it was only 5x7...  It sounds like you've already done it, but if not I can provide a hex file with the "floating a" if you need it.

My plan for the floppy controller is to emulate the WDC1771 with an Arduino Mega talking to a flash card.

OK, back to your current project...  I'm gonna have to steal your keyboard template idea.  It will beat going back to the vhdl file to figure out where I mapped the Break key :)
 

Online ebastler

  • Super Contributor
  • ***
  • Posts: 6206
  • Country: de
Re: Cloning a Commodore PET-2001
« Reply #98 on: June 10, 2018, 05:33:21 pm »
The (Z80) TRS80 model 1 is next on my list. I don't think that there are too many other "mini" computers from the era which can be cloned this way (not requiring NOS chips no longer manufactured).

How about the Apple I and II? Somewhat similar to the PET, of course. But digging into Wozniak's graphcics design may be worthwhile?
 
The following users thanked this post: niladherbert

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #99 on: June 10, 2018, 05:47:04 pm »
Somebody already did clone the Apple I, not sure about the II, that may be reasonable to try.
 

Online ebastler

  • Super Contributor
  • ***
  • Posts: 6206
  • Country: de
Re: Cloning a Commodore PET-2001
« Reply #100 on: June 10, 2018, 06:24:53 pm »
Somebody already did clone the Apple I, not sure about the II, that may be reasonable to try.

Right, there are a few modern replicas of the Apple I around. However, I think there is a gap between the Briel Replica I (which claims to be functionally equivalent, but uses some more highly integrated ICs than the original, I believe) and the various 1:1 copies of the PCB. (Those are more like "forgeries" than replicas, in my mind. ::)

As to the Apple II, of course there were plenty of clones back in the day!  ;)
 

Offline austfox

  • Regular Contributor
  • *
  • Posts: 154
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #101 on: June 13, 2018, 02:15:59 am »
Just to let you know that I've been following this thread with interest, and would like to purchase the 2 PCBs for the PET if you ordered multiple boards?
 

Online oPossum

  • Super Contributor
  • ***
  • Posts: 1415
  • Country: us
  • Very dangerous - may attack at any time
Re: Cloning a Commodore PET-2001
« Reply #102 on: June 13, 2018, 07:24:16 am »
My most tedious task so far for the TRS-80 project was manually writing the character set binary file.

About 20 years ago I wrote an emulator for the TRS-80 Models I/III/4/100/102/200, and Color Computer 1/2/3/MC10. This was a Windows program and I created a Windows bitmap font for use by the emulator. Attached are the source files that where used to generate the fonts. They contain the font ROMs as C arrays. Converting this to whatever format you need would probably require some trivial C code. There are annotations in the source about where the fonts came from and the quirks they have. I have also attached the ROMs for these systems.


« Last Edit: June 13, 2018, 07:27:01 am by oPossum »
 
The following users thanked this post: MK14, nad007007

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #103 on: June 13, 2018, 12:51:26 pm »
Just to let you know that I've been following this thread with interest, and would like to purchase the 2 PCBs for the PET if you ordered multiple boards?


Hi, I've got five spare sets of the 2 boards, but can you give me a week or two to finish documentation/b.o.m./tesitng, etc?

Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #104 on: June 13, 2018, 12:54:47 pm »
My most tedious task so far for the TRS-80 project was manually writing the character set binary file.

About 20 years ago I wrote an emulator for the TRS-80 Models I/III/4/100/102/200, and Color Computer 1/2/3/MC10. This was a Windows program and I created a Windows bitmap font for use by the emulator. Attached are the source files that where used to generate the fonts. They contain the font ROMs as C arrays. Converting this to whatever format you need would probably require some trivial C code. There are annotations in the source about where the fonts came from and the quirks they have. I have also attached the ROMs for these systems.


It looks like I should have asked here first before compiling my own character ROM binary file!
« Last Edit: June 13, 2018, 01:36:55 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #105 on: June 13, 2018, 01:03:53 pm »
The (Z80) TRS80 model 1 is next on my list. I don't think that there are too many other "mini" computers from the era which can be cloned this way (not requiring NOS chips no longer manufactured).

How about the Apple I and II? Somewhat similar to the PET, of course. But digging into Wozniak's graphcics design may be worthwhile?


I've got the schematics and details for the Apple1, but didn't really find it all that interesting. I hadn't looked at the Apple II until now, but it does look like a very good contender for a clone....... unfortunately though, there are only so many hours in a day. If only I was payed to do this in my day job...........
« Last Edit: June 13, 2018, 01:37:51 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: ebastler

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #106 on: June 13, 2018, 01:36:14 pm »
It sounds like you did exactly what I had to do for that font ROM - at least it was only 5x7...  It sounds like you've already done it, but if not I can provide a hex file with the "floating a" if you need it.

My plan for the floppy controller is to emulate the WDC1771 with an Arduino Mega talking to a flash card.

OK, back to your current project...  I'm gonna have to steal your keyboard template idea.  It will beat going back to the vhdl file to figure out where I mapped the Break key :)


Maybe I should just make provision for an external '1771 emulator to be plugged in? Hm, I will see. Your project sounds interesting. Did you get as far as of yet as testing any or all of your VDHL on an FPGA development kit or the like?

There were some weird design decisions made with the original TRS-80; for example the odd-ball 10.6445 MHz pixel-shifting clock frequency. Perhaps that was a commonly available crystal 40 years ago, but you certainly can't buy a 10.6445 MHz crystal off the shelf today. That high frequency meant that all 384 pixels of a complete row were serially shifted out in just 36uS of the complete 63.13uS line period. Unless displayed on a TV/monitor having a tweakable (expandable) width control for the horizontal picture size, that will result in a fairly squished up display horizontally. Also 10.6445 MHz is pushing the video bandwidth limitation of your typical TV-based display monitor a bit too far and it was a complaint back in the day that the high-resolution video characters were ill-defined and blurry on the screen. Maybe RS just had a preexisting stockpile of 10.6445 MHz crystals to use up?

To mitigate these issues and to avoid having to source a 10.6445 MHz crystal, in my clone design I've lowered the pixel-shifting clock frequency to 8MHz. The master clock source will be a generic 16 MHz oscillator. The CPU clock in the original TRS-80 was 1.774 MHz (10.6445 MHz divided by 6). I'll divide my 16 MHz by 9 for 1.778 MHz, which is more than close enough.

« Last Edit: June 14, 2018, 08:34:59 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #107 on: June 13, 2018, 09:03:39 pm »
It really surprises me that the character ROM image is not already out there somewhere. There are many projects to emulate vintage computers, and other projects to archive ROM dumps from these and related hardware. Couldn't anyone with one of the machines dump the ROM easily enough?
 

Offline kizmit99

  • Regular Contributor
  • *
  • Posts: 106
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #108 on: June 15, 2018, 12:21:34 am »
Did you get as far as of yet as testing any or all of your VDHL on an FPGA development kit or the like?

I had the base system (without the expansion interface) running on a Cyclone IV demo board like this one:


The final design should fit into a Cyclone II, so the idea is to eventually use this board with a custom daughter board:


Wrote a PS2 keyboard interface which memory maps the current set of pressed keys so it appears to be an original keyboard.  Instead of generating the original video signal it outputs a monochrome 800x600 VGA video signal.  Had to duplicate the original cassette audio input with a few analog components, then used an old iphone to feed the cassette audio input.  Definitely a real blast-from-the-past to be running StarTrek.  Haven't been able to make the cassette audio out work to the point I can actually csave anything though.
 
The following users thanked this post: oPossum

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #109 on: June 15, 2018, 06:23:06 am »
Those little Cyclone II boards are great. I have nearly a dozen of them running as various retro computers and 70s arcade games. They're ridiculously cheap, cheaper than buying the bare FPGA. It's a rather old part now but still perfectly adequate for this sort of thing, and making the most of limited hardware is kind of in the right spirit for this stuff anyway.
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #110 on: June 17, 2018, 01:16:09 pm »
I'm been meaning to upgrade from CPLDs to FPGAs in my home workshop for a while now and almost clicked the "buy now" button a couple of times, but just haven't gotten around to it so far; one of those ebay Cyclone dev boards or the like might be a good start.

-----------------------------

Anyone with an suitable reader can pull a 27XX from a vintage computer board and save the contents, but for the Tandy character set ROM you'd have to solder up an adaptor to fit a 27XX footprint and just ground any unused address and data pins. The ROM was a Motorola MCM6670, which was called a "Character generator", but that was just marketing as the part was nothing more sophisticated than a parallel in/out ROM with 5-bit words. The part was packaged in an 18 pin DIP which I don't think was originally socketed in the TRS-80.

-----------------------------------------

I was a bit slack this week end electronic project wise, but late this afternoon a couple of hours before having to attend to my weekly chook and duck poop shoveling chore, I at least made a rudimentary start on the case. I originally planned a 2U case but ended up deciding on 3U. I've finished the PCB layout for the keyboard interface and will etch that soon. The keyboard interface will get mounted on the opposite side panel to the video generator board and a torodial power transformer will get mounted onto the rear panel.

The 3U front panel will give me a healthy amount of room to layout all of the I/O connectors and control switches. Rather than rolling my own front panel labeled with Dymo tape, I've decided to splurge out and get the front panel done by Front panel express and have just downloaded the latest version of their "Front panel designer" software. I should get that out before the end of the working week, but the production and delivery delay will probably stall the completion of this project by another couple of weeks.

While waiting I think I might brush up on my BASIC and write a PET version of Atari Pong  :D

« Last Edit: June 17, 2018, 01:35:54 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline Bicurico

  • Super Contributor
  • ***
  • Posts: 1707
  • Country: pt
    • VMA's Satellite Blog
Re: Cloning a Commodore PET-2001
« Reply #111 on: June 17, 2018, 01:46:14 pm »
WOW!

Reading this thread looks like I am looking over the shoulder of the original PET creators.

I won't try to replicate it, as reason tells me I don't have space, knowledge, time, money and I could use an emulator.

Still, what a joy to look at your project.

 :-+

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Cloning a Commodore PET-2001
« Reply #112 on: June 17, 2018, 04:28:50 pm »
 :-+ Excellent Job!
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #113 on: June 17, 2018, 05:25:47 pm »
I'm been meaning to upgrade from CPLDs to FPGAs in my home workshop for a while now and almost clicked the "buy now" button a couple of times, but just haven't gotten around to it so far; one of those ebay Cyclone dev boards or the like might be a good start.


Well if you do, I've got a pile of random turnkey projects targeted to those boards which you're welcome to play with. Some are my creations, others are stuff I ported from elsewhere. It's an old part but still quite capable. You need a programmer too, the USB Blaster clones that are only a few dollars from China work just fine.
 
The following users thanked this post: GK

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #114 on: August 06, 2018, 09:15:24 am »
.............and I could use an emulator.


Some of us are a little masochistic  ;D
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #115 on: August 06, 2018, 09:39:33 am »
Hi all.

Sorry for the delay in replying to those interested in the circuit boards. Unfortunately I have had a five or six week hiatus from this project due to being busy with far too many other things. I got back into it late this weekend, finally transferring the PS/2 keyboard interface circuitry to a home-etched PCB - works a treat.

I went a little elaborate in the design as I wanted key stroke echoing via RS232 in PS/2 mode and also the ability to control the PET via the keyboard interface via RS232. I haven't coded the latter function yet; that's waiting for a few spare hours.

Pics of the system in its current degree of completion, wired up and operational, attached below. Every thing works perfectly fine so far and the only thing I have yet to fully test out is the GPIB port. I'm currently writing some BASIC test programs and soldering up a GPIB breakout (LED/switch/IO) box.





« Last Edit: August 06, 2018, 12:30:41 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: mathsquid, derree

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #116 on: August 26, 2018, 12:54:24 pm »
OK, outside of chasing women and recovering from a cold I got absolutely nothing done on the project since my last post - until this weekend. I managed to finish my IEEE-488 port test program and finish off the hardware testing.

So here is some babbling about the successful IEEE-488 hardware testing and implementation.

I did finally discover one electrical error in the PCB layout, which fortunately is quite easily rectified (picture attached). I'm not sure how I missed this, but in one of the two 74LS245 octal line drivers/receivers that I am using as receivers in my IEEE-488 port, only six of the eight buffers are used. Instead of grounding the two unused input pins I accidentally grounded the two unused output pins instead. I noticed that this chip was getting a bit warmer than it should. Fortunately the unused input pins, numbers 8 and 9 are inline with pin 10, the ground pin, so fixing the problem is just a solder blob shorting these three pins together. The buffers are non-inverting, so the two unused output pins accidentally grounded rather than left unconnected can just be left as they are.

The long obsolete Motorola IEEE-488 interface chips originally used in the PET were unusual in that a separate receive output pin and transmit input pin were provided for each I/O pin. All IO, as per the original IEEE-488 standard, was open-collector with a resistive (voltage divider) pull-up to approx. 3.5V. Logic low=true. In these Motorola chips the receive output pin simply reflected the logic state of its respective I/O pin regardless of weather the I/O pin was asserted true (low) by either an external device or by the respective transmit input pin being asserted low.

Consequently in the PET there isn't a direction control register of any sort for IEEE-488 communications, but separate output and input register bits for all of the CPU-controlled I/O pins, with the exception of SQR, which is an input only and therefore doesn't have an output register address. There are also two control pins which have no register addresses at all as they have no hardware provision for CPU control. These are RET and IFC. The RET line is electrically tied to ground. This asserts the PET as a permanent host. IFC is asserted by the power-on system reset (555) timer only. There is a total of 16 lines in the IEEE-488 standard - 8 data lines and 8 control lines.

To implement the IEEE-488 interface as per the original PET hardware configuration using current production parts rather than those obsolete Motorola chips, I used a pair of SN75ALS160 as the output line drivers and, as mentioned above, a pair of 74LS245 buffers as the line receivers. The 74ALS160's are wired in uni-directional mode with the active pull-ups disabled. In this mode the I/O are open-collector outputs with an internal resistive pull-up to ~3.5V. The 74LS245's are perfect in this application as line receivers as they have TTL-compatible switching thresholds with hysteresis. They also have special high-impedance inputs courtesy of emitter-follower input buffers, so they will not load the internal resistive pull-ups of the SN74ALS160 operating in open-collector mode.
     
Pictured below is a screenshot of the IEEE-488 test program that I wrote this weekend. The screen is divided into two halves - the left hand side for the output register status/control and and the right hand side for the input register status. The current logic state of a register bit is indicated by the O graphic symbol next to its respective pins name. A logic high (false) is indicated by a solid O while logic low (true) is indicated by a empty O.

The logic state of any IEEE-488 pin can be toggled by pressing the letter key indicated to the left of the pin name listed in the output register table. With the exception of pins ATN and SRQ, with no external device connected to the IEEE-488 port the status of the input register bits on the right hand side of the screen simply reflect the output register status. Basically, there are two ways to make an input register bit show a logic low (true) - by either asserting the pins respective output register bit low (true) or by shorting the pin to ground at the IEEE-488 port. The program I wrote therefore makes for a handy hardware test even without any device connected to the IEEE-488 port - if, when toggled, the logic status of any input register bit does not reflect the logic status of the respective output register bit, then there is a hardware malfunction, either with the output driver or with the input receiver for that register bit's respective I/O pin.

Pins ATN and SRQ are a little special. All other input pin registers are asynchronous and indicate true when their respective I/O pin is pulled low by whatever means. ATN and SRQ however are edge-triggered inputs, their respective register bits being set on a high (false) to low (true) pin transition. In order to give an unambiguous test indication for the operation of these pins in my program, I configured these pins to behave as flip-flops. In the input register side of the screen there is an N key indicated to the left of the ATN input register bit and an O key indicated to the left of the SRQ input register bit. Pressing the N on the keyboard will clear (set high = false) the ATN register bit wile pressing O will clear the SRQ bit. The only way to get either ATN or SRQ to indicate true after being cleared is to assert the respective hardware pin true (low). The SQR pin, as mentioned previously, is an input pin only, so the SRQ I/O pin must be externally forced to ground. ATN however is both an input and an output, so it can be asserted true either by shorting the ATN I/O pin to ground externally or by toggling the ATN output register bit from high (false) to low (true). Once set true both the ATN and SQR registers will remain in that state (indicating that a false-true transition was successfully registered) until manually cleared by pressing the respective clear key.

Oh, and one last thing. The EOI output resister bit is utilised in the PET to serve a secondary hardware function - when asserted true the video screen is blanked! Asserting the EOI I/O line true externally (and thus the EOI input register bit) does not blank the video screen however. It is only the logic state of the EOI line at the input side of the line driver that controls the video blanking. This freaked me out a bit the first time I pressed K on my keyboard whilst running my developing test program, until I remembered the hardware configuration of the EOI line. Oh no! I've killed it!  :P



« Last Edit: September 08, 2018, 10:28:19 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: oPossum, derree

Offline jeffheath

  • Regular Contributor
  • *
  • Posts: 71
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #117 on: August 27, 2018, 06:11:12 am »
Just wanted to say this thread is awesome! :D  I don't quite have what it takes to do a full "modern replica", but I now have some potential ideas involving fpga kits and a dead c64 i have laying around.....
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #118 on: September 08, 2018, 10:37:30 am »
Thanks  :)


A progress update:

I've got the 3U case 90% fabricated and the computer is wired in and operational with its own AC power supply. I have only just finished the front panel design this evening. I will send the design off to Front Panel Express for fabrication this weekend.

When I finally get the panel I'll use it as a template to mark out the mounting holes in the assembled case; then it's just a few more holes to drill and tap and the whole thing will be complete for the final assembly; probably the weekend after next.


EDIT: silly typos have been noticed and corrected.






« Last Edit: September 08, 2018, 11:06:43 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: derree

Offline Bicurico

  • Super Contributor
  • ***
  • Posts: 1707
  • Country: pt
    • VMA's Satellite Blog
Re: Cloning a Commodore PET-2001
« Reply #119 on: September 08, 2018, 11:47:43 am »
So cool!

Reading about your progress is fantastic by its own measure.

Regards,
Vitor

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #120 on: October 02, 2018, 12:32:26 pm »
Well the computer is now finished electrically. Now I just have to mark out and drill and tap the mounting holes for the lid and fashion the last length of 10mm square rod which screws to the inside top of the front panel, but that is enough for this evening.

I'm largely done with the PDF documentation - just need photos of the completed unit to finish it off. Once I'm done with the documentation I intend to publish the whole thing (Gerber files, ROM images, BOM, etc) on a single dedicated page on my website. This will probably take another couple of weeks.


 




« Last Edit: October 02, 2018, 12:37:30 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: SeanB, jeffheath, derree

Offline jeffheath

  • Regular Contributor
  • *
  • Posts: 71
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #121 on: October 02, 2018, 10:05:33 pm »
Nice! Love the neat wiring, and the Altair look. ;D
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #122 on: October 04, 2018, 07:36:12 am »
Thanks.
Hmm, I dunno though - I think it would need a lot more toggle switches to remind me of an Altair  :)
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline martinjaymckee

  • Contributor
  • Posts: 16
Re: Cloning a Commodore PET-2001
« Reply #123 on: October 06, 2018, 06:18:58 am »
Just wanted to chime in on what a cool project this is.  I agree with previous posters about the implementation being beautifully clean and well laid out.  I certainly would love to have something like that in my workshop -- for now I'll have to stick to my Raspberry Pi to control things.  I'm sure your new PET will do well!

Cheers,
Martin Jay McKee
 
The following users thanked this post: GK

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #124 on: October 24, 2018, 11:32:27 am »
OK, I still haven't finished the PET documentation yet. Seems I'm crap at estimating time frames for hobby projects. I've had a diversion, which I just finished loading and testing this evening.

This is the "deluxe" cassette port analogue interface which I mentioned some time earlier in  the thread. Plugged into the PET's (or C64's or VIC20's, etc) cassette port, it allows almost any audio recording/playback device to be used instead of a propriety Commodore "Datasette" for program and data storage. The encoding method Commodore used is polarity sensitive, so provision is provided (for compatibility with other recorders) in both the read and write signal paths to invert the signal. A data bit is represented by a full cycle of a squarewave of a specific period immediately followed by another full cycle of a squarewave, but of of a different period. Which way around the periods are depends on weather or not a 0 or a 1 is being represented and all timings are measured from negative-going edges only.

The "read" signal is bandpass filtered, limited and then sliced by a comparator with hysteresis. This circuitry in practice does a great job of cleaning up and giving successful data transfers with rather crappy/noisy/ringing/low-level playback signals. When data is being properly received in the read signal chain the activity L.E.D. will flash as a constant rate of approx 2.8 Hz. I've been loading and saving programs from and to my crappy Digitech portable voice recorder.

Now I just have to build it into a fancy instrument enclosure.




 
« Last Edit: October 25, 2018, 06:45:23 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: derree

Offline kizmit99

  • Regular Contributor
  • *
  • Posts: 106
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #125 on: October 24, 2018, 11:37:45 pm »
Wow! - that cassette interface is certainly more complicated than the one I'm using for my TRS-80 clone... 
It's not a direct copy of the original.  It's similar, but should be significantly less finicky than the original.



I'm amused that I ended up in a similar place to you on the small voice-recorder to replace the old cassette deck.  (Yes, I'm easily amused  ;))
Anyway, always fun to see more progress.  Thanks for sharing!


 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #126 on: October 25, 2018, 07:54:47 am »
Wow! - that cassette interface is certainly more complicated than the one I'm using for my TRS-80 clone... 


Well,  like I said; "this is the "deluxe" cassette port analogue interface"  :)

When I was prototyping my PET for expediency I soldered together a cassette port audio interface just as simple as yours, but it wasn't entirely reliable. And a mic.-level write signal won't suffice for a line-level input and vice versa. And it wouldn't load at all, let alone with complete reliability, from playback signals getting as bad as this: 

« Last Edit: October 25, 2018, 08:06:08 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline kizmit99

  • Regular Contributor
  • *
  • Posts: 106
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #127 on: October 25, 2018, 02:50:54 pm »
Eek - I didn't notice first time around that you were trying to clean up Mic level inputs.  Not much signal to work with there to begin with!
Out of curiosity, did the original have to deal with Mic levels?  That seems like a pretty formidable task, I would have expected Line level inputs at worst.

Question for you -- are you able to successfully replay data that's been mp3 compressed?  I've been mostly playing with wav encoded files to this point, but having a 5Meg audio file encoding 15K of data seems like a bit of over-kill :)
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #128 on: October 27, 2018, 12:12:20 pm »
Eek - I didn't notice first time around that you were trying to clean up Mic level inputs.  Not much signal to work with there to begin with!
Out of curiosity, did the original have to deal with Mic levels?  That seems like a pretty formidable task, I would have expected Line level inputs at worst.

Question for you -- are you able to successfully replay data that's been mp3 compressed?  I've been mostly playing with wav encoded files to this point, but having a 5Meg audio file encoding 15K of data seems like a bit of over-kill :)


Writing to both mic.-level and line-level inputs; hence the switched attenuator in the write signal chain giving three different write signal levels.
I wanted the read input to work without complaint from a couple of volts down to 100mV input with a adequate safety factor. Bits start dropping out at around 10mV rms, (depending on the signal-to-noise ratio) so that's that spec. met.

The various models of the Commodore "Datasette" all communicate with the computer via TTL-logic signals. All of my recordings so far are in mp3 format - no problems at all.

I finished the unit off and started putting it to use this afternoon . The banana posts on the rear panel connect to the motor-control relay contacts and can be used if desired to auto-switch the motor of an external tape recorder. The "sense" switch tells the computer that play/record have been pressed. This switch is normally just left on to skip "PRESS PLAY ON TAPE" (load) and "PRESS PLAY AND REC ON TAPE" (save).





« Last Edit: October 27, 2018, 12:17:00 pm by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: LapTop006, MK14, kizmit99, derree

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #129 on: November 28, 2018, 10:55:24 am »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: MK14, nad007007, BrianHG, kizmit99

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: Cloning a Commodore PET-2001
« Reply #130 on: November 28, 2018, 12:06:37 pm »
Thanks for the video, and very interesting project.
I'm amazed at how neat, the internal construction of your project is.
It seems to be working very well, and has brought back, found memories to me, by watching the video.
Well done!   :)

One quick question. What is the difference, between the two versions of basic, apparently selectable, by the switches on your unit ?
« Last Edit: November 28, 2018, 12:10:43 pm by MK14 »
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #131 on: November 29, 2018, 07:15:22 am »
The upgraded BASIC gets a big list of bug and limitation fixes, the Bill Gates Easter egg and "Tiny Mon" (TIM), a simple machine language monitor.
Some software written with work-arounds for the original BASIC bugs and limitations might conceivably not work properly with the fixed, "upgraded" BASIC, so I added being able to run both as a feature. Also the character ROM bundled with the original BASIC machines swapped upper and lower case A-Z in the second page of the character set - that being the "alternate" page called the "business" set, as opposed to the "graphics" set that the machine boots up in by default.

 
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: MK14

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #132 on: December 02, 2018, 06:47:39 am »
Finally, the project web page is not yet complete, but all of the technical documentation and design files are posted:

http://www.glensstuff.com/pet2001/pet2001.htm
 
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: MK14, tek2232, kizmit99, derree

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14309
  • Country: fr
Re: Cloning a Commodore PET-2001
« Reply #133 on: December 02, 2018, 05:39:46 pm »
Impressive  :-+
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: Cloning a Commodore PET-2001
« Reply #134 on: December 02, 2018, 06:03:20 pm »
The upgraded BASIC gets a big list of bug and limitation fixes, the Bill Gates Easter egg and "Tiny Mon" (TIM), a simple machine language monitor.
Some software written with work-arounds for the original BASIC bugs and limitations might conceivably not work properly with the fixed, "upgraded" BASIC, so I added being able to run both as a feature. Also the character ROM bundled with the original BASIC machines swapped upper and lower case A-Z in the second page of the character set - that being the "alternate" page called the "business" set, as opposed to the "graphics" set that the machine boots up in by default.

Thanks for that really nice explanation.
It must be real fun, playing around with those different versions, of the PETs Basic roms and things.

You're tempting me, to build your project   :)

Thanks for making it open source and/or available online and here. It makes a very interesting read and/or project to build.

One thing/feature you forgot.
When an early PET was switched off, you could see a white dot, that faded over a number of tens of seconds, in the middle of the (crt) screen. Unfortunately, you seem to have forgotten about it. (If I remember correctly).
Only joking, no you have done a great reproduction job!
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #135 on: December 04, 2018, 10:49:26 am »
Hey, thanks for noticing  :)

As a general rule, once the design files are turned out into the public domain, that's the last you hear from any interested correspondent.

I tipped the project over at Hackaday in a fit of shameless self-promotion. Dunno if it will be worthy though.
 


   
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: MK14, derree

Offline nad007007

  • Contributor
  • !
  • Posts: 19
  • Country: nz
Re: Cloning a Commodore PET-2001
« Reply #136 on: December 14, 2018, 04:42:28 am »
Hi GK

I have emailed JLCPCB.com about my error "Can not identify the board outline" and they suggest to manually enter the sizes of the boards. Now do you have the dimensions for the 3x boards?

Thanks

Regards
Conrad   


 Conrad Larsen
Hi Glen, very cool project. I have up loaded all three Gerber files for pet2001 to JLCPCB.com and i get errors "Can not identify the board outline" this puts the drill holes out. Hope you can help with editing the Gerber? Kind Regards Conrad
Glen Kleinschmidt
Hi. I normally use PCBcart or Elecrow for personal projects, but have not used JLCPCB and have never received a similar complaint from another manufacturer, so am not sure what the problem might be. Might be worth contacting JLCPCB technical support for an explanation?
Conrad Larsen
Hi Glen, do you have the three boards dimension please?

Regards Conrad
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #137 on: December 15, 2018, 10:55:21 pm »
In thou:

Motherboard - 10200 x 6800
Video board - 7100 x 4500
PS2/RS232 board - 5950 x 2100
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: MK14, nad007007, derree

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Cloning a Commodore PET-2001
« Reply #138 on: December 16, 2018, 04:37:01 am »
Hi GK

I have emailed JLCPCB.com about my error "Can not identify the board outline" and they suggest to manually enter the sizes of the boards. Now do you have the dimensions for the 3x boards?

Thanks

Regards
Conrad   


@GK, in the future, when making gerbers in Protel99SE, to make the PCBs gerbers be auto-recognized by JLPCB.com, you need a trace around your PCB on the 'Keep Out' layer, and, also a copy of those traces on the main 'Mechanical Layer 1'.  When generating the gerbers, make sure that the 'Mechanical layer 1' is applied to all greber layers.

With this, many online PCB shops, like some in China who use an all automated online proofing of gerbers before manufacturing like JLPCB will auto-detect the outline of your PCB without issue and auto cut the PCB to that shape.
« Last Edit: December 16, 2018, 04:38:40 am by BrianHG »
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #139 on: December 16, 2018, 06:40:23 am »
In each case I have the board outline defined in the mechanical layer (GM1). From here:

https://support.jlcpcb.com/article/42-how-to-export-altium-pcb-to-gerber-files

Quote
Please make sure you have the clear outline in mechanical layer.

 :-//


In almost 20 years of Protel now an hundreds of boards manufactured, I've never had a request for anything beyond that. Can you define a board shape in 99SE like you can in AD13? I don't know because I've never had to do it before, and right now I have to go out.

Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Cloning a Commodore PET-2001
« Reply #140 on: December 16, 2018, 07:19:40 am »
In each case I have the board outline defined in the mechanical layer (GM1). From here:

https://support.jlcpcb.com/article/42-how-to-export-altium-pcb-to-gerber-files

Quote
Please make sure you have the clear outline in mechanical layer.

 :-//


In almost 20 years of Protel now an hundreds of boards manufactured, I've never had a request for anything beyond that. Can you define a board shape in 99SE like you can in AD13? I don't know because I've never had to do it before, and right now I have to go out.
You are correct.  Yes, I've done PCBs since the early 90s.  However, over the past 27 years, all my gerber files were inspected by a human operator loading the files and seeing the board outline right there on their gerber viewer.  (At the time, my prototype PCBs also cost hundreds of dollars, over a thousand or two for a 4 layer, all made here in North America unlike today's highly all automated shops which would end up being under 100$.)

JLCPCB has no human in the loop when you upload a .zip of gerber files on their website.  Withing seconds, it just shows you a 3D quality rendering of your final PCB, that is if it can determine the PCB outline.  Otherwise, a human would need to do a degree of work.

I'm not sure if it's a quirk with P99se, but all I have done is tell you how I define my PCB outlines in P99se & when I send my P99se .zip gerbers to JLPCB, it instantly reports back my board dimensions and show me a preview of my PCB.


Note than in P99se, it is usual practice that the board outline is defined on the 'Keep Out Layer'.  Using this layer, you draw the shape you like, and you can even create multiple PCB on 1 cad document this way.  I just draw a rectangular trace around the PCB.

The reason I copy and paste my board outline from that layer to the mechanical layer is to have the board outline visible on every gerber file layer.  This makes it obvious to the automatic detection software which JLCPCB uses to find the PCB outline.

I usually send my .zip to JLCPCB as a test before I make a design public since the render they give you on the web page is instant and represent what they and others will give you if others have lazy inspection engineers and just hit the 'AUTO' button on their gerber viewers.


« Last Edit: December 16, 2018, 08:44:22 am by BrianHG »
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Cloning a Commodore PET-2001
« Reply #141 on: December 16, 2018, 07:46:12 am »
Here is an example upload I've done on this site which you can play with / look at the protel PCB / send the .zip to https://jlcpcb.com/quote 's website to see what happens:

Protel project file to inspect / or copy my source PCB in protel, you may play with it and inspect the board outline:
https://www.eevblog.com/forum/projects/free-subwoofer-audio-processor-project-for-forum-members/?action=dlattach;attach=403539
Gerbers (upload these at https://jlcpcb.com/quote ):
https://www.eevblog.com/forum/projects/free-subwoofer-audio-processor-project-for-forum-members/?action=dlattach;attach=403538
Click on 'ADD your gerber file', send the .zip, and all JLCPCB's fields should automatically be filled in.
You should read:
"Detected 2 layer board of 70x100mm(2.76x3.94 inches) ."
and everything else on the web page should have the correct default values...

You can click on 'Gerber Viewer', and, on the new page, use you mouse wheel to zoom in and out.  At the top, you can select which layer of the PCB to view as well as PCB mechanical statistics.  You can also turn ON/OFF each layer, IE silk, drill, outline, copper, which make the PCB.
« Last Edit: December 16, 2018, 08:06:13 am by BrianHG »
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #142 on: December 16, 2018, 09:43:00 am »
You are correct.  Yes, I've done PCBs since the early 90s.  However, over the past 27 years, all my gerber files were inspected by a human operator loading the files and seeing the board outline right there on their gerber viewer.  (At the time, my prototype PCBs also cost hundreds of dollars, over a thousand or two for a 4 layer, all made here in North America unlike today's highly all automated shops which would end up being under 100$.)


Well, I've had these boards (the exact same Gerber files) and a ~dozen other designs made by PCB cart and Elecrow now, and this is the first time there has been an issue.
I just uploaded the Gerber files for the motherboard to JLPCB's viewer. It's having a fit over the alignment/outline of the drill guide.
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Cloning a Commodore PET-2001
« Reply #143 on: December 16, 2018, 10:21:48 am »
Ahhh, ok, just do / try this (I've seen this before with my friend's board miller.) :

Follow my settings in the attached screenshots:

For the Gerbers Films, Select Imperial or Metric, with the highest resolution of 2:5.  For the film coordinates, use the relative origin.  (This means the coordinates used in the gerber file places 0.0 X 0.0 at the position of your set origin marker in your PCB.)

I usually use the bottom left corner of the PCB.

Now for the NC Drill settings. 
Use the same units and resolution as the Gerber File settings, and
!!! Use " Reference to relative origin " just like the Gerber Films so that your drill hole has the exact same coordinates as the pads on your Gerber Film which is also now set to the same reference relative origin.

This used to be aligned manually by the tech at you PCB manufacturing shop, so, the NC drill used to never have to match the coordinates of the gerber film.

See my PCB screenshot for relative origin position...
« Last Edit: December 16, 2018, 10:27:07 am by BrianHG »
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #144 on: December 16, 2018, 11:02:41 am »
This used to be aligned manually by the tech at you PCB manufacturing shop,


It still is I'd guess, it's probably just that JLPCB here are trying to be too smart in their on-line automated quoting system.

I made sure to follow the Elecrow guide here (as this is who made my boards):

https://www.elecrow.com/wiki/index.php?title=How_to_export_gerber_files_from_Protel

Note that they demand neither a keep out nor a mechanical layer and say nothing about the NC Drill file origin having to match the copper layers.

Also 2:4 format is specified for the copper layers and 2:3 for the NC Drill. 2:5 is beyond the manufacturing capabilities of a lot of these cheap fabs. Do you think it is wise to default to 2.5 for both? A manufacturer might balk if the format resolution of the submitted Gerber files exceeds their manufacturing abilities.


I think I'll just re-upload my Gerber *.zip folder with a .txt "readme" giving the board dimensions. That should be enough if required to get anyone out of trouble and I can't magically and simultaneously accommodate the possible quirks of every manufacturer out there.
 
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Cloning a Commodore PET-2001
« Reply #145 on: December 16, 2018, 11:35:12 am »
Ok, nothing wrong with their instructions except they are missing the 'Advanced Tab' in the Gerber Film settings.

To change your current gerbers settings without changing anything else, all you need to do in protel99se is open your .cam file: ' CAM Outputs for ************.cam ' file.  (Not the CAM directory...)

Once open, double click on 'Gerber output 1'.
Now you can make changes to any of your gerber settings you like.
Same for 'NC Drill output 1'.

(you may also right click in the middle of the white blank window and 'Insert BOM' file, or 'Insert Pick and Place' file which will be included when you generate your gerbers.)

Once you make the relative origin change, press 'F9' to re-generate your cad files with the new settings.

This may be important as some users may wish to mill your PCB in one of those cheap desktop Chinese PCB miller which require the film and NC drill to have the same coordinates, otherwise the user has to edit the gerber or NC drill files.  Also, JLCPCB may have a 100% automated setup, with direct optically exposed PCBs, meaning, those purchasing your PCB from them will get PCBs which look like the web photo if there isn't a knowledgeable person in the loop who inspect the files and recognizes the error before manufacturing.

     As for the film resolution, I choose 2:5 for both since today, some of my footprints are designed in metric, others designed in imperial.  Making both the gerber film and NC drill high res, with equal precision just ensures on the PCB manufacturer's side, when their software/hardware converts your gerber/drill file's units to their machine's internal units, I just want to cover the finest possible accumulated rounding errors as units may be converted back and forth a number of times since my foot print and it's placement in protel.  But, yes, 2:5 is at least guaranteed above their machine's final resolution... except, on a fine BGA board with 1 mil micro-vias I made a few years back, there was a difference where 2:3 has a few vias off center.  Since then, I've always used 2:5 for both and never had a problem since.
     We don't need to save processing time and shrink file size today to the 2:3 resolution like we did for slower hardware back in the late 80s, early 90s.
« Last Edit: December 16, 2018, 11:57:51 am by BrianHG »
 

Offline RJSV

  • Super Contributor
  • ***
  • Posts: 2102
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #146 on: December 25, 2018, 04:52:54 am »
   AH Come-on, folks,  name Jeri Ellsworth I'm pretty sure,  (sorry to be so abrupt, exxcuse,) Well from what I read, she implemented an entire Commodore C64 using FPGA logic.  I'm not up to date,  now, but Jeri produced a multi-game clone, around 2004, of a bunch of C-54 classics.   Also included a TV set driver, in the hand-held, so it was a stand-alone system.
   I love working with the 6502, register rich, primative some ways, but with some really inspiring indexing and pointer power !
A C-64 with 256 bit colors, would be nice.
   please look up Jeri Ellsworth for her Engineering projects, if you care to,  thanks
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #147 on: December 25, 2018, 05:08:54 am »
   AH Come-on, folks,  name Jeri Ellsworth I'm pretty sure,  (sorry to be so abrupt, exxcuse,) Well from what I read, she implemented an entire Commodore C64 using FPGA logic.  I'm not up to date,  now, but Jeri produced a multi-game clone, around 2004, of a bunch of C-54 classics.   Also included a TV set driver, in the hand-held, so it was a stand-alone system.
   I love working with the 6502, register rich, primative some ways, but with some really inspiring indexing and pointer power !
A C-64 with 256 bit colors, would be nice.
   please look up Jeri Ellsworth for her Engineering projects, if you care to,  thanks


The point?
I think that there would be few people reading this thread out of an interest in vintage computing who wouldn't already be aware of Jeri Ellsworth and/or the C64 Direct-to-TV product.
« Last Edit: December 30, 2018, 10:04:07 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 
The following users thanked this post: nugglix, BrianHG

Offline RJSV

  • Super Contributor
  • ***
  • Posts: 2102
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #148 on: December 25, 2018, 11:35:58 pm »
Sorry about that post, ignorant / impulsive...  I saw those proto boards, on page 1, (love 6502!) and did not realize so much material was beyond. Apologies, Rick-Jack
 

Offline soldar

  • Super Contributor
  • ***
  • Posts: 3128
  • Country: es
Re: Cloning a Commodore PET-2001
« Reply #149 on: December 26, 2018, 12:10:58 am »
Impressive project. I had a PET 2001 and also a Rockwell AIM-65 with which I did several projects and I still have a keypad access system I designed and built.

I still have a bunch of HN482764  (8192-word x 8-bit UV Erasable and Programmable ROM) and TMS2516 (2K x 8 bit UV ROM) which I will gladly give away to anybody who can use them.

All my posts are made with 100% recycled electrons and bare traces of grey matter.
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #150 on: December 30, 2018, 10:22:37 am »
It sounds like you did exactly what I had to do for that font ROM - at least it was only 5x7...  It sounds like you've already done it, but if not I can provide a hex file with the "floating a" if you need it.

My plan for the floppy controller is to emulate the WDC1771 with an Arduino Mega talking to a flash card.

OK, back to your current project...  I'm gonna have to steal your keyboard template idea.  It will beat going back to the vhdl file to figure out where I mapped the Break key :)


Maybe I should just make provision for an external '1771 emulator to be plugged in? Hm, I will see. Your project sounds interesting. Did you get as far as of yet as testing any or all of your VDHL on an FPGA development kit or the like?

There were some weird design decisions made with the original TRS-80; for example the odd-ball 10.6445 MHz pixel-shifting clock frequency. Perhaps that was a commonly available crystal 40 years ago, but you certainly can't buy a 10.6445 MHz crystal off the shelf today. That high frequency meant that all 384 pixels of a complete row were serially shifted out in just 36uS of the complete 63.13uS line period. Unless displayed on a TV/monitor having a tweakable (expandable) width control for the horizontal picture size, that will result in a fairly squished up display horizontally. Also 10.6445 MHz is pushing the video bandwidth limitation of your typical TV-based display monitor a bit too far and it was a complaint back in the day that the high-resolution video characters were ill-defined and blurry on the screen. Maybe RS just had a preexisting stockpile of 10.6445 MHz crystals to use up?

To mitigate these issues and to avoid having to source a 10.6445 MHz crystal, in my clone design I've lowered the pixel-shifting clock frequency to 8MHz. The master clock source will be a generic 16 MHz oscillator. The CPU clock in the original TRS-80 was 1.774 MHz (10.6445 MHz divided by 6). I'll divide my 16 MHz by 9 for 1.778 MHz, which is more than close enough.


OK, better late than never; here is where I currently am at, construction wise, with the Model 1 TRS-80 clone. I basically have the whole thing designed on paper and it's now just a matter of building it. I intend to verify the design this time around, before laying out the PCBs, by building the complete computer on bread board. So far I have the video generation circuitry constructed entirely in CMOS logic to the extent that it will display from the uppercase page of the character set in high-res (64 horizontal characters) mode. My CMOS implementation is quite a bit different from the original design and I'm using an 8MHz pixel clock as mentioned previously in the quoted post.

The screen is just showing a random garble of characters at the moment due to the random contents of the video RAM at power up. Might start a new thread in a day or two  :)

Oh, and yeah, a couple of characters are a bit dicky (N for example), necessitating a character ROM revision - I did manually type this ROM out byte for byte in a binary editor after computing each byte on graph paper and am still not 100% sure if my character set is an entirely verbatim, pixel-for-pixel replication of the original.


« Last Edit: December 30, 2018, 10:37:54 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline wilfred

  • Super Contributor
  • ***
  • Posts: 1248
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #151 on: December 30, 2018, 10:44:17 am »
I always enjoy reading your posts about progress in your latest project. But, wouldn't a dedicated thread for the TRS80 clone help people follow along better.
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #152 on: December 30, 2018, 01:20:48 pm »
I always enjoy reading your posts about progress in your latest project. But, wouldn't a dedicated thread for the TRS80 clone help people follow along better.


Yes, already contemplating starting a new thread. I was hoping to maybe get some CPU action already happening before going out tomorrow night, but I just noticed that the two Z84C00s CPUs which I bought months ago now in anticipation of this project are in fact a pair of Z84C20s, which is a bloody PIO. Sometimes if I'm lucky a Digikey or Mouser order placed on a Sunday night will arrive the following Thursday or Friday arvo, but I can't see that happening now with NYE an all. Argh. Another week+ in limbo.
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline kizmit99

  • Regular Contributor
  • *
  • Posts: 106
  • Country: us
Re: Cloning a Commodore PET-2001
« Reply #153 on: January 01, 2019, 09:31:07 pm »
 :-+
Looking forward to seeing what you do with this...

I've been planning to start a thread on my TRS80 project, but have been spending too much time trying to get the disk-controller emulator working.
Just for grins, here are a few shots of where mine's at...
First version of the PCB needs a few extra pullups:


It's able to read and write from "cassette":


And plays all of the games I've tried on it.  Here's Star Trek ala 1979...


Have been working on the disk emulator for far too long now...


But even though it's still very flaky (I'm getting more read failures than from a real floppy :)), it will boot (and somewhat run) LDOS:


Definitely looking forward to your approach.   :-+
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #154 on: January 02, 2019, 07:52:52 am »
I'm interested to see how your disk controller emulator works out  :)

I've decided to build my TRS-80 Model 1 clone and the expansion unit as separate units. The only non-standard thing I'll be doing, architecturally, is putting the full 48k of memory into the TRS-80 clone. As you likely know, the original TRS-80 keyboard unit was expandable to 16k maximum and you got to 48k with an additional 32k inside the expansion unit. My clone will be compatible with an original expansion unit too, with a small modification -  the RAM inside the expansion unit will need to be disabled by inhibiting the memory data bus read buffers.
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #155 on: January 09, 2020, 03:48:15 am »
Ahhh, ok, just do / try this (I've seen this before with my friend's board miller.) :

Follow my settings in the attached screenshots:

For the Gerbers Films, Select Imperial or Metric, with the highest resolution of 2:5.  For the film coordinates, use the relative origin.  (This means the coordinates used in the gerber file places 0.0 X 0.0 at the position of your set origin marker in your PCB.)

I usually use the bottom left corner of the PCB.

Now for the NC Drill settings. 
Use the same units and resolution as the Gerber File settings, and
!!! Use " Reference to relative origin " just like the Gerber Films so that your drill hole has the exact same coordinates as the pads on your Gerber Film which is also now set to the same reference relative origin.

This used to be aligned manually by the tech at you PCB manufacturing shop, so, the NC drill used to never have to match the coordinates of the gerber film.

See my PCB screenshot for relative origin position...



Hi Brian,

I'm just popping in to update this thread as this issue is still haunting me. I can't do as you described above because the option to align the NC Drill file to any kind of origin at all wasn't a thing until a later version of Protel than what I own.

I did however update and fix the Gerber files provided on my site for this project ( http://www.glensstuff.com/pet2001/gerber/gerber.zip ) so that they display properly in JLCPCB's on-line viewer. JLC's Gerber viewer is smart enough to automatically align the drill guide layer used for manufacturing (this is the layer with the .TXT extension) to the relative origin of the PCB, which must be set to the lower left hand corner of the board. The very first set of Gerber files that I had posted to my site (which Elecrow manufactured for me without complaint) still had the origin set to the default position; that being the lower left hand corner of the worksheet itself rather than the PCB. This is why they did not view properly in JLC's viewer. I've since had my own boards manufactured by JLCPCB.

However it seems that virtually all other on-line Gerber viewers aren't as smart as JLC's and they won't do this alignment of the drill guide to the origin of the PCB. Someone has contacted me out of a concern that this might make the Gerber files that I have posted to my site unsuitable for manufacture, which it doesn't.

Anyway, this thread directs a lot of attention to my site, so if anyone else has concern about the utility of the Gerber files that I have posted, the cut-n-past of my reply to the mentioned correspondent, quoted below, remains my definitive response until someone donates to me a license for Altium Designer 20.



Quote
Hi <redacted>

The JLCPCB Gerber viewer is smart enough to automatically align the drill guide to the relative origin of the PCB (which needs to be set to the lower left hand corner), and it simply looks like the other on-line viewers aren’t.

I have Protel 99SE service pack#4 – unfortunately this version of Protel does not have any provision for automatically aligning the drill guide to the other layers. According to some historical information on Altiums web site, that option wasn’t added until Service Pack #6 and above.

Anyway, if JLCPCB’s on-line Gerber viewer is smart enough to automatically align the drill guide, then so should be the production engineer when it comes to production! I’ve not had a problem with my work or play boards (Entech, IMP, Elecrow, JLCPCB, PCB Cart and others) – I suggest that you just up-load the Gerbers files and submit your order.

I did however find an a free Gerber file editor called Gerbv, and following the instructions here:   https://docs.oshpark.com/design-tools/gerbv/modify-orientation/
I successfully managed to manually align the drill guide to other layers. However the program is a bit buggy – for example, even so all of the other layers register fine, it won’t properly display and auto-detect the format of the drill guide (which is the file with the .TXT extension). For the drill guide layer I had to manually edit the format options to 2-digit trailing zero suppression before the layer would display as it should. This bugginess makes me reluctant to use this program to modify all of my Gerber files as it might be corrupting the files in other ways which aren’t obvious until you try to or have them made.
« Last Edit: January 09, 2020, 03:57:59 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline rthorntn

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #156 on: January 09, 2020, 08:46:58 am »
Fantastic project GK, thanks for all your hard work on this!

If anyone in Australia had a few extra PET PCB's fabricated and wouldn't mind mailing me one or two sets, obviously I will cover the cost of the boards and postage and packing?

Cheers
Richard
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #157 on: January 09, 2020, 12:32:12 pm »
No problem Richard. You can add a TRS-80 to the to do list now too:  http://www.glensstuff.com/trs80/trs80.htm

A Jupiter Ace is now pending.
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Cloning a Commodore PET-2001
« Reply #158 on: January 09, 2020, 05:21:38 pm »
Ahhh, ok, just do / try this (I've seen this before with my friend's board miller.) :

Follow my settings in the attached screenshots:

For the Gerbers Films, Select Imperial or Metric, with the highest resolution of 2:5.  For the film coordinates, use the relative origin.  (This means the coordinates used in the gerber file places 0.0 X 0.0 at the position of your set origin marker in your PCB.)

I usually use the bottom left corner of the PCB.

Now for the NC Drill settings. 
Use the same units and resolution as the Gerber File settings, and
!!! Use " Reference to relative origin " just like the Gerber Films so that your drill hole has the exact same coordinates as the pads on your Gerber Film which is also now set to the same reference relative origin.

This used to be aligned manually by the tech at you PCB manufacturing shop, so, the NC drill used to never have to match the coordinates of the gerber film.

See my PCB screenshot for relative origin position...



Hi Brian,

I'm just popping in to update this thread as this issue is still haunting me. I can't do as you described above because the option to align the NC Drill file to any kind of origin at all wasn't a thing until a later version of Protel than what I own.

Hi GK,

Which version of Protel are you using?
Which OS?
I'm assuming that within your PCB-editor, you are missing the 'CAM Manager...' under the 'File' menu.

I will be glad to help where I can.


**** BTW, JLPCB's new gerber viewer seems to decode your attached PCB files with the their drill offset, whatever they may be, correctly.  Perhaps it is a little bit smarter.

I'm curious, you don't have this menu in your 'CAM Manager...' when you double click on your gerber files?
« Last Edit: January 09, 2020, 06:33:16 pm by BrianHG »
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Cloning a Commodore PET-2001
« Reply #159 on: January 09, 2020, 05:52:09 pm »
It sounds like you did exactly what I had to do for that font ROM - at least it was only 5x7...  It sounds like you've already done it, but if not I can provide a hex file with the "floating a" if you need it.

My plan for the floppy controller is to emulate the WDC1771 with an Arduino Mega talking to a flash card.

OK, back to your current project...  I'm gonna have to steal your keyboard template idea.  It will beat going back to the vhdl file to figure out where I mapped the Break key :)


Maybe I should just make provision for an external '1771 emulator to be plugged in? Hm, I will see. Your project sounds interesting. Did you get as far as of yet as testing any or all of your VDHL on an FPGA development kit or the like?

There were some weird design decisions made with the original TRS-80; for example the odd-ball 10.6445 MHz pixel-shifting clock frequency. Perhaps that was a commonly available crystal 40 years ago, but you certainly can't buy a 10.6445 MHz crystal off the shelf today. That high frequency meant that all 384 pixels of a complete row were serially shifted out in just 36uS of the complete 63.13uS line period. Unless displayed on a TV/monitor having a tweakable (expandable) width control for the horizontal picture size, that will result in a fairly squished up display horizontally. Also 10.6445 MHz is pushing the video bandwidth limitation of your typical TV-based display monitor a bit too far and it was a complaint back in the day that the high-resolution video characters were ill-defined and blurry on the screen. Maybe RS just had a preexisting stockpile of 10.6445 MHz crystals to use up?

To mitigate these issues and to avoid having to source a 10.6445 MHz crystal, in my clone design I've lowered the pixel-shifting clock frequency to 8MHz. The master clock source will be a generic 16 MHz oscillator. The CPU clock in the original TRS-80 was 1.774 MHz (10.6445 MHz divided by 6). I'll divide my 16 MHz by 9 for 1.778 MHz, which is more than close enough.


OK, better late than never; here is where I currently am at, construction wise, with the Model 1 TRS-80 clone. I basically have the whole thing designed on paper and it's now just a matter of building it. I intend to verify the design this time around, before laying out the PCBs, by building the complete computer on bread board. So far I have the video generation circuitry constructed entirely in CMOS logic to the extent that it will display from the uppercase page of the character set in high-res (64 horizontal characters) mode. My CMOS implementation is quite a bit different from the original design and I'm using an 8MHz pixel clock as mentioned previously in the quoted post.

The screen is just showing a random garble of characters at the moment due to the random contents of the video RAM at power up. Might start a new thread in a day or two  :)

Oh, and yeah, a couple of characters are a bit dicky (N for example), necessitating a character ROM revision - I did manually type this ROM out byte for byte in a binary editor after computing each byte on graph paper and am still not 100% sure if my character set is an entirely verbatim, pixel-for-pixel replication of the original.



TI has a 2$ flash-rom oscillator.  Tie 1 crystal, and you can program 4 arbitrary output clock frequencies, ie 10.6445 MHz and others for cpu clk.  It will power up every time with these frequencies.

http://www.ti.com/product/CDCE925?keyMatch=CDCE925PW&tisearch=Search-EN-everything&usecase=part-number
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #160 on: January 10, 2020, 02:06:17 am »



Hi Brian,

I'm just popping in to update this thread as this issue is still haunting me. I can't do as you described above because the option to align the NC Drill file to any kind of origin at all wasn't a thing until a later version of Protel than what I own.

Hi GK,

Which version of Protel are you using?

**** BTW, JLPCB's new gerber viewer seems to decode your attached PCB files with the their drill offset, whatever they may be, correctly.  Perhaps it is a little bit smarter.


??? Brian, did you care to read my post beyond the first sentence?
 

Quote
I'm curious, you don't have this menu in your 'CAM Manager...' when you double click on your gerber files?
(Attachment Link)


I have the menu - just as stated already the position options relative to an origin are missing.
« Last Edit: January 10, 2020, 02:09:15 am by GK »
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Cloning a Commodore PET-2001
« Reply #161 on: January 10, 2020, 03:47:48 am »
I asked which version of Protel you are using?
If you have an official Protel 99, your 'key' may be good to freely upgrade to Protel99se which has the film offset settings...
Protel98's key wont work in 99se.
 

Offline GKTopic starter

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: Cloning a Commodore PET-2001
« Reply #162 on: January 10, 2020, 04:50:56 am »
I asked which version of Protel you are using?
If you have an official Protel 99, your 'key' may be good to freely upgrade to Protel99se which has the film offset settings...
Protel98's key wont work in 99se.


Quoting from my post which you didn't read:


Quote
"I have Protel 99SE service pack#4 – unfortunately this version of Protel does not have any provision for automatically aligning the drill guide to the other layers. According to some historical information on Altiums web site, that option wasn’t added until Service Pack #6 and above."
Bzzzzt. No longer care, over this forum shit.........ZZzzzzzzzzzzzzzzz
 

Offline gwpt

  • Newbie
  • Posts: 3
Re: Cloning a Commodore PET-2001
« Reply #163 on: January 23, 2020, 07:21:51 am »
Fantastic project GK, thanks for all your hard work on this!

If anyone in Australia had a few extra PET PCB's fabricated and wouldn't mind mailing me one or two sets, obviously I will cover the cost of the boards and postage and packing?

Cheers
Richard

Hi Richard,
I just had some boards made for the PET project. How many are you after? hows $20 a set plus postage? (Let me know where you are and I can calculate it)
Cheers
Guy
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf