Cloning a Commodore PET-2001

[GK]

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 
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. 

[GK]

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.
 
 

[MK14]

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

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

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

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

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.

[GK]

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.

[MK14]

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.

[james_s]

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.

[MK14]

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.

[Kleinstein]

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.

[MK14]

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) ?

[GK]

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.   
   

[GK]

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.
   

[SeanB]

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.

[boffin]

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.

[BrianHG]

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.

[GK]

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.
 

[CJay]

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.

[MK14]

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 

[MK14]

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).

[daybyter]

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.

[CJay]

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.

[MK14]

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.

[CJay]

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.

[MK14]

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.

[GK]

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.





 

[GK]

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 T_HW 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 T_HW) 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.