GRAPHICS FOR 80 COLUMN PETS
The Integrated Visible Memory for the PET has now been redesigned for the new 12" screen 80 column and forthcoming 40 column PET computers from Commodore. Like earlier MTU units, the new K-1008-43 package mounts inside the PET case for total protection. To make the power and flexibility of the 320 by 200-bit mapped pixel graphics display easily accessible, we have designed the Keyword Graphic Program. This adds 45 graphics commands to Commodore BASIC. The image on the screen was created by the program below. If you have been waiting for easy to use, high resolution graphics for your PET, isn’t it time you called MTU?
A similar but higher-resolution Fedora Hat can be seen in the thread PicoMiteVGA DEMO over on TheBackShed forums.
via a mention in 1981 MTU ad for PET graphics over on VCFed which has some related images and programs for other computers.
Excellent! I did wonder if that might predate but it turns out this board was introduced in '82 - I find it remarkable how late, relative to introduction, these upgrades were. Evidently machines had long working lives.
Regarding the original “hat” plot: I played with the constants to make an Apple II friendly (280 x 192) version many years ago, and after a few optimizations it performed quite well, by modest standards. I then shared it with John Brooks about eight years ago and released the hounds!
The smallest (but certainly nowhere near the fastest):
10 HGR2 :E = 57:F = .4 * E:P = - .0374:Q = 180
20 FOR J = - E TO E:U = J * J * 5:C = 140 + J:D = 87 + J
30 FOR I = - SQR (16245 - U) TO 0:Y = SQR (I * I + U) * P
35 Y = D + E * SIN (Y) + F * SIN (Y + Y + Y)
40 HCOLOR= 3: HPLOT C - I,Y: HPLOT C + I,Y
50 HCOLOR= 0: HPLOT C - I,Y + 1 TO C - I,Q: HPLOT C + I,Y + 1 TO C + I,Q
60 NEXT : NEXT
TRS-80 Model III was introduced in mid-1980, so an expansion board in late 1982 is still only 2.5 years after initial introduction. The next year, the TRS-80 Model IV would replace the Model III, and it would remain in production until 1991.
Not a bad run for a computer system that was largely overwhelmed in the market by 1983 - including by the CoCo (which Tandy also supported well until 1991). And also both of them were overwhelmed in sales by the PC compatible Tandy 1000 line.
Note that the ‘hat’ has a different crown - it’s a simpler function being rotated.
I realise that only with bitmapped frame buffer graphics would this technique be applicable, of drawing from the back first and blanking pixels below the top edge of the current slice. Previous computer graphics output devices would include plotters and vector displays, where the program would need to figure out what to draw and draw only that.
I don’t know what technique was being used. It was more efficient to go from front to back. Instead of erasing an entire line segment of pixels below the currently drawn pixel, you just have a variable storing the highest height drawn so far.
You draw for each X coordinate (doesn’t matter left to right or right to left). You set the highest height variable to the bottom-most coordinate and then render from front to back.
For each pixel you want to render, you first check to see if it’s equal or below the highest height variable. If so, the pixel is hidden. Otherwise, you draw the pixel and update the highest height variable.
There’s a couple of subtleties here, I think - at least, there’s a dither on the X ordinates.
For more ports of this code see scruss’ thread on the fediverse. For the original, I think, see John Brooks on comp.sys.apple2 back in 2017:
I replaced the hacky hidden-surface-removal code with a better z-buffer visibility system.
It now draws front-to-back with no overdraw or erase.
Time is around 6 minutes on a IIGS and around 16 minutes at 1MHz.
It would be a lot faster with a bit of assembly…
5 PRINT CHR$ (21): HGR2 : HCOLOR= 3
10 DIM Z(279): FOR I = 0 TO 279:Z(I) = 255: NEXT
15 K = 16383:E = 57:F = .4 * E:P = - .0374
20 FOR J = - E TO 0:U = J * J * 5:C = 140 - J:D = 87 - J:LK = K
30 FOR I = - SQR (16245 - U) TO 0:Y = SQR (I * I + U) * P:Y = D + E * SIN (Y) + F * SIN (Y + Y + Y):K = K - 1: POKE K,Y: IF Y < Z(C - I) THEN HPLOT C - I,Y:Z(C - I) = Y
50 IF Y < Z(C + I) THEN HPLOT C + I,Y:Z(C + I) = Y
60 NEXT : NEXT :K = LK
65 FOR J = 1 TO E:U = J * J * 5:C = 140 - J:JJ = J + J:S = SQR (16245 - U)
70 FOR I = 0 TO S:Y = PEEK (K) - JJ:K = K + 1: IF Y < Z(C - I) THEN HPLOT C - I,Y:Z(C - I) = Y
80 IF Y < Z(C + I) THEN HPLOT C + I,Y:Z(C + I) = Y
90 NEXT : NEXT
Yeah, I was starting off typing about an array of heights, but this array actually does cost a significant amount of RAM for early PETs and TRS-80s.
But then I realized you don’t need to store an array actually. You can render one column of pixels at a time, so you only need one height value, not one height value per X coordinate.
Intuitively, you visually expect to render “horizontally”, because the plot looks like a number of horizontal curves. But a computer doesn’t care about that. It doesn’t care what order to plots the points in.
I heard about a Basic type-in program in 80-Microcomputer Magazine for the Model III hi-res board that did fractals, earlier this year. For the fun of it, I ported it to the Atari 8-bit (lower resolution). Here’s the original article:
I had no idea before this that the Model III had such an add-on. I watched a video on installing this board, and it came with a disk that extends TRSBasic with extra commands for accessing it.
As I heard a few years ago, the “Fedora plot” was originally published in Atari Basic in Compute! Magazine. I forget when. This surprised me, because by the time I got into computing on the Atari (1983), I saw programs published to do stuff like this, but they were always only on the Apple II or the IBM PC. I so wanted examples on the Atari (and I missed the “Fedora plot” by probably a couple years). There was a lively discussion about the Fedora plot on AtariAge 7 years ago, where ports to other computers were successfully demo’d:
