Archive for September, 2007

This is a series of posts I’ve had on the back burner for a while. It was inspired by Alan Kay’s comments in an interview from a few years ago, where he said that we’ve seen a significant retrogression in the state of computer science as a result of a “pop culture” that developed in the computer field. I agreed with him, but also commented that I had been a part of that pop culture growing up, and that I might never have entered the computer field if it hadn’t happened. So I had mixed feelings about it.

I did some searching online and found some videos demonstrating technology from these days of yore. I’m only covering the computers that I used extensively from 1981 to 1996. Feel free to compare these computers to what Engelbart and Kay helped create in the 1960s and ’70s.

Atari 8-bit computers

A.N.A.L.O.G. cover #13 (1983), from The Digital A.N.A.L.O.G. Archive

People today, and for many years in the past, associated Atari with video games. For a time they also made personal computers. The first computers I used for any length of time were the Atari 400 and 800, beginning in 1981. These were available for people to sign up and use at my local library. Kids as young as 10 could use them (I was 12 at the time). I finally got my own Atari 8-bit computer in 1988, a 130XE. This was just at the time when the 8-bit computers were dying out. Atari stopped making them about a year or two later.

I read about what was going on with the IBM PC and the Mac in the 1980s, but I didn’t participate in that whole thing. Both of those computers were out of my price range.

I first learned how to program on an Atari, and I did a fair amount of it in Atari BASIC. I’d show some of what I wrote here, but I haven’t had the opportunity to transfer my old programs from disks to images that emulators can read.

Below are some videos I found of the Atari 8-bit doing various things.

Atari brought out their first 8-bit models in 1979, the Atari 400 and 800. Each had a MOS 6502 CPU, running at 1.8 Mhz. The most memory that either model could typically be upgraded to was 64 kilobytes of RAM. They cost several hundred dollars as well. Your cell phone has a more powerful processor and more memory than this now…

Here’s an in-store demo for the Atari 8-bit series from the days when it was new. I can’t embed this video. Follow the link. This is an example of typical 8-bit sound and graphics on the Atari. It doesn’t show what the computer can really do in these areas (I’ll get to that below), but I imagine they weren’t shooting for that. They were just trying to appeal to the typical home computer buyer.


Here’s a video I made giving you an idea of what it was like to program the Atari in BASIC. Notice the line numbers down the left column. These were necessary for each line of programming (which could contain several commands). Line numbers determined the sequence of program segments that would be executed, and they acted as labels. You could GOTO or GOSUB to a line number to emulate loops and subroutines.

I wish I could show you more (and better) examples, but this is all I got right now.


I also did plenty of word processing with it using AtariWriter Plus (I was a writer at a young age, even 🙂 ), and I used terminal software with a 1200 BPS modem quite a bit. I used to upload and download stuff to/from bulletin board systems and communicate to others in discussion areas. Bulletin boards (BBSes) were typically single-user systems. If you could get through, you could connect up to a BBS’s modem, and get full access to their machine for a period of time. No one else could get on. After you were done, you’d disconnect, and then someone else could connect. Not very efficient, but the BBSes I frequented were typically 8-bit computers themselves. Multitasking and multiple connections would’ve been a tall order. Only the advanced BBS systems on tricked out PCs allowed multiple simultaneous connections. The other catch was while you were on the modem no one could call you.

I also used my terminal setup when I got to college (’88-’93) to connect to my school’s CDC Cyber mainframe, and Unix minicomputer systems. Yep, I managed to pull it off. Everybody used modems through phone lines. We didn’t have direct ethernet connections from where we lived. I used a free piece of software called “VT-10 Squared” that gave me an 80-column text screen, and VT-100 emulation. And I used Chameleon, which gave me VT-52 emulation and X-modem data transfer capability (nothing to brag about, actually). The slowness of my modem got to be a drag sometimes, especially when I was doing programming assignments. I could use the full screen editors, but I’d waste a lot of time waiting for the screen to redraw if I was trying to scroll through code. So I’d load up my word processor and write most of my code in that, and then upload it to compile and test it.

Why not get a faster modem, or a PC, or some other 16-bit machine, you ask? At the time I didn’t have the money. I only got my 8-bit machine when they came down in price enough so I could buy one.


One of my favorites was BC’s Quest for Tires (a play on the movie title “Quest For Fire”), by Sierra On Line. The video below shows someone playing the game from beginning to end. It was unique for its time because it was a “thinking action game”. You had to act quickly, but you also had to problem solve to get past a few puzzles. Some of the obstacle game play you see here has been copied in more modern titles.

This game wasn’t easy to get through. The only way I ended up making it all the way to the end (before my patience ran out) was to cheat using an emulator by saving my place from time to time so whenever I lost too many lives I could just load it back to where I was and continue. Most games in those days had no “save place” feature. You had to play them from beginning to end.

One of the best games created for the Atari 8-bit was called “Ballblazer” by LucasFilm Games (A division of THE LucasFilm, of course. Years later it was renamed LucasArts), released in the mid-1980s. It was one of the few 8-bit games that gave the player a 3D first-person view. The video shows the version that came on disk. The amazing thing to watch was seeing the action sequence it showed you while the game was loading. This is shown at the beginning of the video, with the big ball and the big rotofoil going back and forth across the screen. Remember this is a slow machine that was not designed to multitask. It always made me wonder how they pulled it off. The action intro. loads extremely quickly. I figured they used vertical blank interrupts to emulate the multitasking action, but still, the graphics in the action sequence are complex (for an 8-bit) and fast. Getting it to do stuff like this was not easy.

The original “Ballblazer”

The player (whose display is at the top of the split-screen) is playing against the computer (whose display is on the bottom). The player loses against the computer, here. Everything you see and hear was generated by the computer in realtime. The game is like futuristic two-player soccer. Two “rotofoils” are placed on either side of the checkered field. A ball is launched into the middle. The two players use their rotofoils to try to catch the ball in their “force field” and hold on to it. Whoever doesn’t have it tries to free the ball from the other’s force field, and capture it in theirs. The objective is to try to shoot the ball into the other player’s goal (it looks like two goalposts), which moves from side to side. Scoring is based on distance from the goal. If you shoot the goal from far away, you get a lot of points. If you get it in the goal from close range you get 1 point. The goal posts narrow with each score, making it harder to score again.

LucasArts re-released Ballblazer in the 1990s for the Sony Playstation.

Another great game of the time was Rescue on Fractalus, also by LucasFilm Games. It used a fractal landscape-generation algorithm to create a 3D alien landscape you could fly around in. Of course the graphics were low resolution compared to what we’re used to now, but it was an impressive feat, and they managed to get a decent frame rate.

Most games for the Atari were written in assembly language. That was the only way they could get the speed. The games from LucasFilm pushed the Atari’s hardware to the max, squeazing out every bit of performance they could get.

“Rescue on Fractalus”

Again, you see the intro. animation at the beginning while the game loads. The goal is to pick up stranded pilots on the surface of the planet, while pods on mountain peaks try to shoot you, and kamikaze flying saucers try to hit you. There are also aliens that try to fake you out. They’ll pose as stranded pilots, and if you let them into your ship they’ll cause damage (which you can hear). If you don’t let them in they try to come in through the windshield of your ship and you have to zap them with your ship’s energy field to kill them.

You can also cause damage to your ship by running into the side of a mountain. At the end of each level the mothership arrives. You use your rockets to boost your ship back up into space so you can dock with it.

(Update 10-14-07: Thought I’d add a few more games I enjoyed. I’ve been adding to this list lately, because I keep thinking of more good, classic games I played. Sorry if this is messing up your RSS feed. This may be the last of it.)

International Karate, by System 3

This was fun. It performed well. It even had good sound effects. I especially liked the punch-to-the-gut move. It was the most dramatic move. It always made me chuckle because you’d hear the “thud” of the punch, the other guy’s eyes would get big and you’d hear him go “AIEEE!!!”, and collapse.

The Halley Project, by Omar Khudari and Tom Snyder, Mindscape

This came out in 1985, a year before Halley came by Earth (with a disappointing display). It was an educational game to get kids interested in astronomy. You had a base on Halley’s Comet, and you’d fly around to different planets and moons, solving questions about the solar system. What impressed me was they’d managed to build a real 3D system for the game. The Sun, planets, and Halley’s Comet were displayed to scale in size, distance, and motion. You had to fly between the planets and moons using the constellations. Though you don’t see it in this video, it had semi-realistic shading. If you looked at the side of a body facing away from the Sun, it appeared black against the night sky. You could see “phases” of a planet or moon, partly light and partly dark.

They made the game as realistic as possible, but there were some compromises. Even though the objects were in 3D, you moved in 2D space. It lacked the details. Every object except Halley’s Comet looked like a blank, but solid sphere. We’re talking about a low powered 8-bit machine. It wasn’t powerful enough to display the planets realistically in motion, and to scale at the same time. You could “land” on the gas planets. It had a “hyperspace” feature where you could travel faster than light to get between planets quickly. Otherwise it would’ve literally taken years to play it.

They had a contest, which I didn’t participate in. Whoever completed all the missions, plus a secret one, first, won a certificate from Mindscape.

Overall it was a cool game. Quite an achievement.

Orbit, by R. S. Horne

My impression is this was a freeware game. It’s a gravity simulator dressed up like a game, and it’s kind of exciting, because it takes some skill, and you have to take a few things going on simultaneously into account. What’s neat is everything is affected by gravity, even the missiles you shoot. The goal is to last as long as possible against asteroids that come into the gravitational field of a star in the center of the screen. You are in a blue ship that can maneuver and shoot missiles at them. You’re defending yourself and an orbiting “mothership” that resupplies you every time you dock with it. You are brought into the field and you have to use your thrusters skillfully to stay in orbit without crashing into anything. This game is educational because it shows you the dynamics of flying in a gravitational field. If you want to fly to the opposite side of the screen faster you can’t just rocket your way there. You have to take gravity into account. The same goes if you want to orbit more slowly. You don’t just thrust in the opposite direction of the way you’re travelling. The best way to maneuver is to use gravity to your advantage, and sometimes that means doing the opposite of what you think you should do.

Shooting things at a distance is tough, because your missile travels in an arc. Occasionally I was able to get off some lucky shots (not shown here). One of the things I liked to try to do was shoot a missile at a bit of an off angle to the star, which would cause it to go into an unstable orbit. This introduced an element of danger, because it would shoot off in some direction you couldn’t predict.

Star Raiders, by Atari

I’m sure a lot of people have played this, even on the 2600 console. This is not me playing it, by the way. Whoever this is is darn good. This was a favorite of mine once I got the hang of it. The idea was you were playing in a 3D, dynamic environment with bad guys trying to destroy your bases. You had to intercept enemy squadrons, and blow them up before they could surround your base(s) and destroy them. You went back to your bases for repairs on engines, shields, and photons (your weapon).


Here are some graphics and sound demos showing off what the Atari 8-bit could do.

Multicolor balls in action

Just a guess, but I suspect color cycling was used to create the effect, that and the use of display list interrupts to enable the larger color palette on the screen. I could be wrong. I’m no expert in how these things were done. I was never into trying to get right down to the hardware. I was, and still am, more of an application programmer. Still, I liked watching these demos.

The demo you see below shows some graphics and effects you would normally expect to see in a 16-bit demo, but in a lower resolution.

“The Shrine” demo by La Resistance, made in 2007


The next demo I’ll show here contains a little bit of adult material, so I’m only providing a link to it. It’s the best 8-bit demo I’ve ever seen. It’s called “Numen,” was created by a group called Taquart, and came out about 10 years ago. In my past experience all good graphics and sound demos came from Europe. I assume that’s where “Numen” and “The Shrine” came from.

Everything you see in “Numen” is generated by a souped-up Atari computer. It has about 256 kilobytes of RAM, and an added Pokey chip. Pokey was the sound chip for the computer. The 8-bits only came with one of these, and they gave you four 8-bit synthesizer voices, or two 16-bit voices, on 1 channel. Someone came up with a hardware modification that techs could put into an Atari that would add a second Pokey chip, which an enterprising programmer could use. Adding the second chip gave you eight 8-bit synth. voices, or four 16-bit voices, divided into 2 channels. The CPU still ran at the standard 1.8 Mhz.

This demo, leaving aside the low resolution, sounds like a 16-bit demo. In fact I think X-Ray (their music guy) only used 16-bit voices. It also features many of the same types of graphical effects and animation you would expect to see in a 16-bit demo. That’s what’s amazing about it. Taquart clearly pulled out all the stops on the hardware. They used every trick in the book, reprogramming the graphics hardware, to get more colors on the screen than what an Atari would normally display. They programmed the sound hardware to good effect as well. Everything you see and hear was generated by the computer at actual speed. No video editing was done. It’s hard for me to say of course how much was pre-calculated.

The thing I think is cool about these demos is they’re an art form. Most demos are just “look how many sprites I can animate on the screen” and “greets” to friends, but these try to do something uniquely difficult, and do it gracefully. I’ll show some more of these for the Atari ST, coming up in a later post.

Edit 9/26/08: I was looking at old videos and came upon this one on YouTube. I feel like I just gotta show it here! It’s made by a guy who goes by the name of “Mr. Atari.” The video you see was made by him using his own process. What you see here is the first 3 minutes of the movie The Matrix: Reloaded as played back by a stock Atari 800XL. The video and audio are being streamed from a hard drive an SD card connected through an IDE adapter designed for the Atari. The video of the movie you see is pre-digitized (it’s not going through an analog-to-digital process as it’s being displayed). The video is displayed in a GTIA graphics mode on the Atari. The digital audio you hear is coming from the Atari as well! This is pretty goddamn impressive!

This was probably recorded (for YouTube) using a direct feed from the Atari’s monitor port. It looks and sounds pretty clean (for the technology that’s being used, that is). If you don’t believe this is real, you can look at this as well (it’s a digitized Atari video games ad), where “Mr. Atari” shows the displayer he was working on, and he uses a video camera to record what’s coming from his monitor.

—Mark Miller, https://tekkie.wordpress.com

Read Full Post »

Ramon Leon at On Smalltalk posted a tutorial wiki app. in Seaside. Give it a try.

—Mark Miller, https://tekkie.wordpress.com

Read Full Post »

Dr. Randy Pausch gives his last lecture (h/t to Mark Guzdial)

Randy Pausch, a computer science professor at Carnegie-Mellon University and the creator of Alice, is dying of pancreatic cancer. I learned this past weekend that he had given his last lecture recently, while he was still in good health. It’s become kind of commonplace for universities to have dignitaries give “last lectures.” The scenario put to them is, “What would you tell people if you were going to die soon?” Well Randy really did it. As you can see from the video he was not morose about it. He was downright cheery. What he had to say was good and inspirational. He focused mostly on his career and people he’s met along the way, leaving his illness in the background.

I had heard of Alice through Squeak, but I had never heard of Randy Pausch before this. What he has done is amazing. He’s managed to marry performance art with computing via. virtual reality technology. He developed a course bringing together people from all sorts of disciplines to participate in creating immersive environments.

Randy said Alice is a “head fake” to get students to learn programming, “while doing something else.” He says students think they’re creating movies and video games with it, but they’re learning programming. He said with Alice, “The vision is clear: Millions of kids having fun while learning something hard.”

There were two parts of his speech that I loved.

In “Hello. World” the demonstrator creates a world in wireframe to please an endearing rabbit. The demonstrator renders the world, creating a sunny place with dancing, singing characters. She then does a “system reboot” that destroys the world before your eyes in a whimsical and hilarious way. Such creativity!

In another segment, on things other people had taught him, Randy talked about a former student, Dr. Caitlin Keller, who suggested that instead of seeing Alice as an easy-to-use tool to teach programming, he should present programming as a form of storytelling, through Alice. It sounded like he took that advice and used it in his classes. He said she demonstrated by using Alice this way in middle schools that girls could be attracted to learn programming, suggesting that it’s all about the approach, not the subject matter. This was heartening to me. I think it would be beneficial to male students of programming as well. I’ve written previously of the pleasure of “coding like writing,” though what I talked about was different. I wouldn’t call it storytelling, but rather describing a process using concepts, more like technical communication, rather than a narrative.

He gave some useful advice for life, like, “Brick walls are there to show you how badly you really want something.” They’re there to keep out the people who aren’t dedicated to the task. He also said, “If you wait long enough,” with someone you are displeased with, “they will eventually impress you.” I have a new perspective on “brick walls” after listening to him.

Something he implies is it’s important to be in a community that agrees with your work values, and is open to what you’re trying to accomplish. If you’re running into people who don’t value your ideas, much less understand them, it doesn’t necessarily mean your ideas are wrong. You might be hanging around the wrong people.

At the end the president of CMU announced that they’re going to build a bridge between the performing arts building, and the computer science building on campus. The buildings are already situated next to each other. They’re going to name the bridge, appropriately, after Randy.

The end of the lecture was touching. He said he did this lecture, and recorded it, for his kids so that someday they’ll understand some life lessons. It reminded me of a movie that came out years ago called “My Life,” starring Michael Keaton and Nicole Kidman, about a man and his expecting wife who find out he’s dying of cancer, and how they choose to live the remainder of his life. It contained a great idea for terminally ill parents: Take the time to record “sit down talks” with your kids, teaching them life lessons, because you won’t be around when they’re older and ready for them. It also gives them an opportunity to know a bit of you, so you won’t be someone who wasn’t there for them.

That was one message from Randy’s lecture. What it also brought to mind for me is a message that all computer science programs should heed: TRY TO MAKE PROGRAMMING FUN! This doesn’t mean it has to be all fun all the time, just try to incorporate it somewhere.

I’ve been saying this to whoever will listen since industry started complaining that there weren’t enough computer science graduates. A group of companies got together in the 1990s to try to promote getting educated in computing for the benefits (ie. salary, nice job, good lifestyle, etc.). They created some videos to be shown in high schools with this message. The 2000/2001 tech recession clearly showed the fallacy of this line of thinking. Yes there are good times in this industry, but they don’t last. It’s a chaotic place to be.

When I was learning computers as a 12-year-old, the fun aspects were emphasized. Not so much playing games, but there were simple things you could try and get some gratification from what you did. There were resources available (books, magazines with type-in programs) that tried to make the experience of programming enjoyable by having you try things that were fun. There were all sorts of things around in our culture that made science and computing look fun and interesting. That’s why I got into it. It wasn’t imposing and boring. I developed this mentality that computers were “creation machines.” Unlike physical mechanical devices, you could mold the computer to whatever you wanted it to be, and you could take the vision you had in your head and realize it in front of you. That experience has always been a blast for me. There were some fun experiences I had in CS in college, but not too many. It was serious work, and fun was hardly ever emphasized. I think it killed that spirit within me a little. When I got out, for some reason I didn’t look for places to work that would be fun. I just wanted a job, and that’s what I got. Not to say I didn’t have enjoyable experiences in and out of the work world. I certainly did. I’ve worked with some great people. Was the computing part fun? Sometimes. What I’ve worked on remembering in the past year is what it was like to have that spirit of “computing is fun”–not necessarily easy, but fun nonetheless. Randy’s lecture was a part of that experience for me.

Thank you, Randy. I am sad to see you go so soon. I hardly knew you. Best wishes to your family. Your contributions will live on in your software and in your students.

By the way, readers can find Alice for Squeak Version 3.8 (not sure if it works in the current version, 3.9 as of this writing) in the Balloon3D class library on SqueakMap (just bring up “SqueakMap Package Loader” inside Squeak and search for it), or in Monticello using the http://www.squeaksource.com/Balloon3D repository. It’s called “Wonderland”. Once it’s loaded in Squeak, evaluate “Wonderland new” in a Workspace.

Edit 9/24/08: While I’m updating/cleaning up old posts, I figure I should update this one. Dr. Randy Pausch died of his illness on the morning of July 25, 2008. Here is a site Randy Pausch set up to document his “adventure” with cancer, and other events along the way. It also links to a page that’s like a scrapbook of his efforts to bring awareness to cancer research, and the events he was a part of, talking about his philosophy of life.

—Mark Miller, https://tekkie.wordpress.com

Read Full Post »

If you’re a software developer and you’ve wanted to learn Squeak, it’s been a struggle for a while now.

In 2001 and 2002 Mark Guzdial wrote two books on it: Squeak: Object-Oriented Design with Multimedia Applications, and Squeak: Open Personal Computing and Multimedia (co-authored with Kim Rose). These are two books I found that have a system/programmer perspective on it. They’re both out of print, but last I checked they’re still available from Amazon.com. A lot of the knowledge in these two books is still relevant to Squeak, but they are in a sense out of date, because they were written for earlier versions, and some of the features Guzdial talks about are either broken now or non-existent in the current version, and there are tools that are in common use now in Squeak that didn’t exist at the time he wrote them. By the way, if you get these books I strongly recommend that you get Squeak version 2.8, because it’s the version the books talk about. If you can, you might want to get the CD with the book (some of the used editions don’t have it). It has version 2.8 on it. 2.8 is also available online.

Edit 10-19-2011: Just for clarification, I’ll add that “Squeak: Object-Oriented Design with Multimedia Applications” is a book you can get if you’re trying to learn how to use Squeak, and learn the Smalltalk language. It guides you through the features of the system, and contains exercises to help you learn what you can do in it. “Squeak: Open Personal Computing and Multimedia” is more of a philosophical book, talking about why Squeak was created, and what it represents in the world.

Just today (Sept. 14, 2007) I heard about a new book that’s been published called “Squeak By Example”, written by Andrew Black, Stephane Ducasse, Oscar Nierstrasz, Damien Pollet, Damien Cassou, and Marcus Denker. It’s available as a free PDF (though financial contributions are accepted), or you can pay for a print-on-demand softcover book. The book is released under the Creative Commons Attribution-ShareAlike license. It is also open source. It will change over time, and knowledge contributions are welcome. There is a lot in it. It’s 300 pages right now.

This is a developer-focused book. If you’re looking for a book that looks at Squeak from a child’s/educator’s perspective, I’d recommend any of the other books on Squeak, such as Squeak: Programming With Robots, by Stephane Ducasse.

I’ve done a quick look-through of “Squeak By Example,” and my own assessment is it teaches you about the system features, both from a UI and programmatic perspective. While there is plenty of Smalltalk code in it, it’s not intended as a book for learning the Smalltalk language. For that they suggest you take a look at the collection of free books on Smalltalk that are available online. As far as I know these books are out of print, but they’re still useful. As an introduction I’d suggest “I Can Read C++ and Java But I Can’t Read Smalltalk” (PDF), by Wilf LaLonde.

As I’ve said before, there are tools you can run inside of Squeak. “Squeak by Example” discusses many of the ones developers will need to know about. Each tool also has an object model that is accessible from inside your own code, which is also discussed.

It talks about the system, or kernel objects, such as collections, streams, and the meta-object model. It talks about message passing, which is the mechanism by which you and objects communicate with other objects.

It teaches the basics of how to use Squeak in a nice level of detail. One of the things I haven’t liked about most of the Squeak tutorials out there is they ignore the basic, beginner-level knowledge someone new to it needs to know, like how to bring up menus, what menus are available, and what you can do with them, not to mention how to install and run it (though this is pretty easy). This book allows you to ease into it, showing you how to install Squeak, and how to use the mouse with it.

I’ve been itching to recommend this tutorial, done by Stephan Wessels, but I haven’t because it skips the beginner basics. Now I can, since you can learn these basics elsewhere. He takes you step by step through a complete development example, creating a “laser” game in Morphic, a graphical objects/UI framework in Squeak.

Just as a side note, when I first saw Stephan’s tutorial it reminded me of Laser Chess, by Mike Duppong, a game that was originally published in Compute!’s Atari ST Disk & Magazine 20 years ago (the multi-platform Compute! Magazine published ports of it for Commodore, Atari 8-bit, and Apple II computers).

Anyway, enough reminiscing. Here are some other tutorials on the Squeak Wiki. Like I said, they typically don’t cover the beginner basics, but once you know them, you’ll probably find other useful information here.

For you web developers out there, once you learn the stuff I mentioned above, you can move on to the Seaside tutorial.

Go forth, and enjoy Squeak!

—Mark Miller, https://tekkie.wordpress.com

Read Full Post »