Electronics > Projects, Designs, and Technical Stuff

Cloning a Commodore PET-2001

<< < (5/33) > >>

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

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

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

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

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

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

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



MK14:

--- Quote from: GK on June 05, 2017, 05:45:02 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.

--- End quote ---

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

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

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

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


MK14:

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod