Electronics > Projects, Designs, and Technical Stuff

Cloning a Commodore PET-2001

<< < (7/33) > >>

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:

--- Quote from: james_s 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.

--- End quote ---

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:

--- Quote from: Kleinstein 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.

--- End quote ---

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:

--- Quote from: MK14 on June 11, 2017, 07:32:49 am ---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.
--- End quote ---


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.   
   


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