Electronics > Projects, Designs, and Technical Stuff
Cloning a Commodore PET-2001
GK:
--- Quote from: james_s 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
--- End quote ---
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. ::)
GK:
--- Quote from: MK14 on June 11, 2017, 06:39:38 am ---
--- Quote from: GK on June 11, 2017, 06:07:39 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.
--- End quote ---
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.
--- End quote ---
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:
--- Quote from: GK on June 11, 2017, 06:55:16 am ---
--- Quote from: MK14 on June 11, 2017, 06:39:38 am ---
--- Quote from: GK on June 11, 2017, 06:07:39 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.
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
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:
--- Quote from: MK14 on June 11, 2017, 06:22:50 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.
--- End quote ---
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:
--- Quote from: GK on June 11, 2017, 07:08: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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version