Terak Museum | Hacker News Reader

Terak Museum

threedee.com

29 pointsrbanffy11 comments

It was an nice little machine. But since it used the UCSD P-System, a slow interpreter, it was rather slow if you needed to compute anything.

(In my aerospace company days, our group evaluated a large number of forgotten machines, from the Apollo Domain and Symbolics 3600 down to the Terak. This was the era of weird UNIX workstations and things that were sort of like IBM PCs, but different. So I got to see most of the hardware of that era. Eventually settled on Sun 2 machines and 4.3BSD.)

When the UC sold the UCSD P-System the profiler and native code compiler were abandoned. With P-Code optimized for size and hot spots native compiled, small P-System programs ran comparably to programs fully compiled to native code and large programs ran thousands of times faster by reducing (usually eliminating) swapping and paging on those early memory-starved systems. I too migrated to Sun-2s but I purchased them myself. I'd learned the hard way that software developers need to own the means of their production!

Those graphics look really nicely done (especially the GIF); I actually wish matplotlib or whatever the most popular data viz libraries are had a feature that would make them.

I would look for dithering options if you can. On screens with limited colors, dithering is a great way to add a feeling of depth or shadows. You still see it in some pixel art.

If you read dev logs for playdate games, a lot of devs use dithering since it only has 1 bit color.

We used these for my first CS class at UCSB in 1979 running the UCSD P-System and they were great machines. It was frankly a much better system than the shared university IBM mainframe clone based computers used for other first year courses which used PL/1. Playing Space Invaders was one of the more popular activities on the Terak.

The compiler/run/debug & repeat cycle was light years ahead of how we developed on the mainframe. On the mainframe, using PL/1, you had a global onerror handler that would dump all variables and do a core dump of your program failed/crashed. The output was on from a line printer that you usually got a few hours after you submitted your job. On average you got 1 maybe 2 job runs a day. At least we didn’t have to use punch cards like the electrical engineers did for their Fortran programs; we used “glass TTYs” where we could save our virtual cards to a file system and later modify. Oh, and you needed to have the magic JCL cards at the beginning or your job. Those were the days.

Later that year the CS dept got their own VAX and from then on most coursework was done on that system using BSD Unix. The EE’s still had to use punch cards on the mainframe.

We did have a few other systems for some courses but the majority of stuff ended up being C or Pascal on Unix (with the occasional language like lisp or prolog for some classes.)

"Winner of the "Geek Site Of The Day" Award on October 16, 1996"

Reply on news.ycombinator.com