• Please review our updated Terms and Rules here

1981 MTU ad for PET graphics

ab3ap

New Member
Joined
May 8, 2022
Messages
7
Location
Pennsylvania, USA
In another group, a 1981 ad was posted where MTU improves PET graphics. I don't know why, but the short program presented in the ad fascinated me for a few days. For any interested, my little explorations converting it to python are at https://udel.edu/~mm/hat

Mike
 

Attachments

  • hat320.png
    hat320.png
    13.8 KB · Views: 16
This is not far removed from another popular computer graphics example of the era which was to use the sin(x)/x function as a base for generating a three-dimensional ripple surface.
Given that this is the kind of thing that I gave my TRS-80 a high-res graphics card for, I'll try out translating that Atari hat code and see how long it takes Level II BASIC on a 1.7 MHz Z-80 to do it.

1652322700432.png
From Graphics on the BBC Microcomputer.
 
This is not far removed from another popular computer graphics example of the era which was to use the sin(x)/x function as a base for generating a three-dimensional ripple surface.

I remember writing one of these when I was in high school that randomized the ”center” position of several diminishing sin waves with randomized amplitudes on a grid and rendered the resulting interactions isometrically like this. The results were very much like a “surface scan” you might see on a screen in an early 80’s sci-fi movie.
 
GK2001, both programs present a surface of revolution in slices, so probably the main differences are the expression for the surface and the slice stagger for the 3d look. I hope you'll share your code when you're done!

I only just this week got a trs-80 emulator running (sdltrs) after chasing down bios roms for it. So much fun. I always wanted one as a kid when they came out, but no way was my machinist dad going to ante up US$400 for one. :)
 
GK2001, both programs present a surface of revolution in slices, so probably the main differences are the expression for the surface and the slice stagger for the 3d look. I hope you'll share your code when you're done!

I only just this week got a trs-80 emulator running (sdltrs) after chasing down bios roms for it. So much fun. I always wanted one as a kid when they came out, but no way was my machinist dad going to ante up US$400 for one.

This was quite a straight forward port to the Tandy. It's really only complicated by the USR routines required to execute drawing commands to my VGA video card add on.

It took my VGA-equipped TRS-80 almost exactly 2h and 45 minutes to run this quick BASIC translation.
I noticed the number of decimal places used for the 1.5*pi constant to compute XF and forced double precision (declaration character #) for XF and a couple of other variables which returns 17 digits of precision. This was probably unnecessary and might have slowed things down a significant amount.

At this stage I didn't bother modifying the scaling to fit the hat to the higher display resolution. I only modified the plotting offsets to center the graphic.

I think things could be sped up a lot and you could get away with much coarser and thus much fewer iteration steps if the code is improved to actually draw lines between successively computed points. The code in its current form produces a curve just by plotting individual points, so the iterations need to be many and in rather small increments to arrive at a curve which is only mostly contiguous.

This is all I have time for this evening. I might experiment with and improve the code as described and then add it to my site as another example program, if successful, in a day or two.


mtuhat1.jpg

mtuhat2.jpg

mtuhat3.jpg
 
Last edited:
Reminds me of Weird Science for some reason.

View attachment 1241061

Heh. Only if the wiz kids in question were planning to build a perfect woman with rather strange, uhm, features. ;)

I was thinking more of things like Alien: (If you do a random number of interacting sine waves with different amplifications on a plane it produces something that looks *kind* of like a landscape. Kind of.)

6047866844_fd1822f70d_z_d.jpg
 
Very nice, thanks for sharing!

No problem. :)

BTW, if you're keen on dabbling with another a retro language, BBC BASIC is worth a look: https://www.bbcbasic.co.uk/bbcwin/bbcwin.html
I just ported the base-level code to start testing my ideas for improving it for speed on the TRS-80. This is much quicker than waiting hours for the result!

Note that BBC BASIC uses the lower left corner as the coordinate datum rather than the top left corner; hence the Y=1024-Y inversion to prevent the hat being drawn upside down.
Also, there are two "graphical units" for each real pixel. The window size is 640x512, so the coordinate range is 1280x1024; hence the multiplication of X and Y by 2.


1652500001768.png
 

Attachments

  • 1652499177445.png
    1652499177445.png
    43.4 KB · Views: 2
Last edited:
I think things could be sped up a lot and you could get away with much coarser and thus much fewer iteration steps if the code is improved to actually draw lines between successively computed points. The code in its current form produces a curve just by plotting individual points, so the iterations need to be many and in rather small increments to arrive at a curve which is only mostly contiguous.

Well, this only works properly for the open wire version of course. Here it is with half the iterations. Solves in basically half the time but the curves are totally contiguous now. Cutting the iterations by any more than half starts to cause the outer rim to begin breaking up. However at 0.5 iterations, this is still a visual improvement over the original.

1652521533126.png
 
Last edited:
Had fun myself a while ago with a supersoft board on the PET ..
 

Attachments

  • EBEABD5A-5646-48D8-9AF4-8A7BA30919C9.jpeg
    EBEABD5A-5646-48D8-9AF4-8A7BA30919C9.jpeg
    1.5 MB · Views: 8
  • 0C402157-92CC-4282-8B53-FE340C6BEB5A.jpeg
    0C402157-92CC-4282-8B53-FE340C6BEB5A.jpeg
    1.2 MB · Views: 7
  • B410C8D7-F731-4464-A0D6-9BBE71789BF7.jpeg
    B410C8D7-F731-4464-A0D6-9BBE71789BF7.jpeg
    1.8 MB · Views: 7
Another
 

Attachments

  • C6B2AAD4-BF87-4C3A-884D-1C25144DCCE3.jpeg
    C6B2AAD4-BF87-4C3A-884D-1C25144DCCE3.jpeg
    1.7 MB · Views: 5
Nice. Love the look of the monochrome green phosphor. Code and execution times?

I've been inspired. Here is my translation/take on a sin(x)/x ripple surface from the example cited earlier.

A port of this code is currently executing on my TRS-80 Model 1. Judging from the progress for far, it looks like it is going to have an execution time of around 3.5 hrs before I can snap a finsished screen photo.

1652597410231.png
 
Last edited:
OK, I had to pull out the CRT VGA monitor for this one. The program took 3h and 34m to execute. This is a little bit beyond the TRS-80s native graphics resolution I suppose.

1652626410542.png

1652626303954.png

With the lights turned out:

1652626520548.png
 
Note that BBC BASIC uses the lower left corner as the coordinate datum rather than the top left corner; hence the Y=1024-Y inversion to prevent the hat being drawn upside down.
Also, there are two "graphical units" for each real pixel. The window size is 640x512, so the coordinate range is 1280x1024; hence the multiplication of X and Y by 2.
I don't immediately understand the idea of two graphical units, so will definitely look into BBC BASIC, thanks! :)

- Mike, still unsure why retro computing is this much fun...
 
I don't immediately understand the idea of two graphical units, so will definitely look into BBC BASIC, thanks! :)

This is a legacy from the language as it was implemented on the early 8-bit computers by Acorn of which the BBC Model B is probably the most famous. The pixel coordinate range is just a multiple of the actual pixel resolution. In the display mode of the example cited the ratio is 2:1. For example if you want to address a pixel at x100, y100, your coordinate values need to be x200, y200. I don't know what the real benefit of this arrangement is supposed to be and have never read an explanation of as to why BBC BASIC was originally implemented this way.

Back to that sin(x)/x ripple program posted immediately above: In porting this over to the TRS-80 and tweaking, without much thought, I made a silly simplification to the source code which almost doubled the programs execution time.
The original code stepped X from -XM to 0 and had two plot statements. The 2nd plot statement was identical to the first but just inverted X to plot the opposite, mirrored half of the image. I deleted the 2nd equivalent plot statement and changed the first FOR loop to step X from -XM to XM. This, however, is much less efficient as it takes way less CPU cycles to just invert X for the mirrored half of the image than it does to do the all of the calculations all over again in reverse.
 
The execution time of the PET was quite long. Depending on the image. The Hat (with hidden lines) took few hours but some of the other stuff was in minutes. My Flickr page has more pictures. After drawing, especially for The 3D rotational stuff, I captured the screen image into ram. When all rotations had drawn and saved, which could be 1-2hrs to finish depending on resolution and memory space , I played it back like a screensaver.


There is an album for the MTU board also. A decent chunk of the code can be found on Steve G’s GitHub page (he was very kind in allowing me to preserve my code there)


The Spirograph stuff I got the starting formula from various websites such as below and modified them accordingly



This book was where I also took inspiration from, converting a number of the transformation routines to work on the PET.


The high res board became a nice distraction from repairing PET computers…
 
Last edited:
The pixel coordinate range is just a multiple of the actual pixel resolution. In the display mode of the example cited the ratio is 2:1. For example if you want to address a pixel at x100, y100, your coordinate values need to be x200, y200.
In an undergrad graphics course, three major sets of coordinate systems were used: world (actual 3d measured positions and dimensions of objects), normalized (3d projection onto device independent coords), and finally device coordinates. A transformation matrix is built up to do it all, and the BBC BASIC method reminds me somewhat of the normalized-to-device scaling. But having to manually scale every point seems to remove the benefit of hiding actual device coords! Probably there is some other reason... 🤔
 
I like the Spirograph stuff. I actually bought a Spirograph kit a while ago to stick on the shelf; one of those nostalgia-driven purchases of something not particularly useful. I've been thinking of a "SpiroCAD" program to be written for my TRS-80. The closest thing I have done so far is that short Maurer Rose drawing program shown on my site.

This popped up elsewhere, much content relevant to this thread: 3D math primer for graphics and game development.
 
Last edited:
Back
Top