Slashdot Mirror

This is a non-story.

Speaking of "stories," I do not understand why no one has yet mentioned Gordon Dickson's classic short "Computers Don't Argue" from 1965.

Magazine reproduction
Text version (but atrocious background color)

Also:

BASIC Computer Games and
More BASIC Computer Games

None of them had graphics but I typed them in anyway and sometimes even tried to correct the differences between versions of BASIC...

Also:

BASIC Computer Games and
More BASIC Computer Games

None of them had graphics but I typed them in anyway and sometimes even tried to correct the differences between versions of BASIC...

Some good beginner computer architecture books:

Code by Charles Petzold
Inside the Machine by Jon Stokes
Machine Language for Beginners by Richard Mansfield

And an online course:
NAND to Tetris

Ha! This was the one that we spent hours on end transcribing from: http://www.atariarchives.org/c...

Found out the school library had several books on basic programming [...]

Those books are still around on the Atari Archives. For a while I was translating old BASIC games that I could get to work on the Commodore 64 into working Python scripts. A lot of spaghetti code with all the gotos and gosubs.

http://www.atariarchives.org/

>> I'm currently going through an old compiler book to translate Borland C into modern C

err... why?

To learn C better. Also to learn how to write compilers. The used — and very obsolete — edition of the book was cheaper than the current edition ($5 vs. $70), and modern C compiler books are very expensive. Once I understand how to write compilers, I'll write a BASIC compiler in Python. I've been translating old BASIC games into Python, which I've never gotten to work on my Commodore 64 as a teenager. Of course, Python extensions are written in C (or Cython).

Keep in mind that I got an A.S. degree in computer programming and work in IT support. My education was practical, not theoretical or theological.

Or use BASIC to learn about a different programming language. I never got any of the BASIC Computer Games (see link below) to work on my Commodore 64. Fast forward 30 years and a taxpayer-funded A.S. degree in computer programming, I started translating the BASIC games into Python to learn more Python better. A very educational experience.

http://www.atariarchives.org/basicgames/

http://www.atariarchives.org/d...

I remember that book well, I owned it and its predecessor.

I didn't know anything about different BASIC variants, so I recall typing in a lot of games that didn't run because they were the wrong dialect, and trying to figure out how to make them work.

I also bought this book at Radio Shack and, while it was educational and entertaining, it didn't take me long to realize it wasn't written for TRS-80 BASIC; it's from the mainframe/mini era. Tandy just slapped a picture of a TRS-80 on the cover so they'd have some kind of programming book to sell!

... in this book: http://www.atariarchives.org/m...

Many of those old books are available at the Atari Archives. I've been translating David H. Ahl's BASIC games into Python to learn that language better.

http://www.atariarchives.org/

Great question and welcome to IT!

I have a pretty crazy history with computers which started with self assigned projects and self appointed challenges at 11 years old.

First, I bought 101 Basic Programs by David Ahl available here: http://www.atariarchives.org/b... and spent a summer typing those games into a basic interpreter running on an Atari 600xl. There were MANY games in this, which was my attraction, but the real learning came when i didn't like the game's mechanics and changed them to suit myself, with the sheer volume of tedious typing led to a lack of attention which introduced errors - and helped me actually learn the logic of the code by figuring out why it was breaking down and where.

Now to be clear, the programs you proposed are - shall we say - like watching paint dry - tremendously boring - and code doesn't have to be like this. You have a whole generation of game players who - if you simply introduced things they would be interested in - mechanics of gameplay - whether that's physics and having them draw a pixel that falls at a certain rate, or it's introducing collision detection, or it's introducing scripted dialog and response systems to the traditional 'hello world' stuff, or it's applied fractal graphics (fractals are actually quite easy to implement), or it's making logical changes in a text based adventure - games are my suggestion and advice to ANYONE teaching programming for the first time.

Optimization, in my opinion, such as fast sorting algorithms for a text search are wonderful and all, but teach the student how this is applied to the real world, and have them build a portion of a scripted response system so they understand how dialog responses work in a game and methods to make these more effective. Teach them not just the tool, but at least ONE strategy and method to apply that tool.

Now for self development, once I input all those programs... I got into practical joking.

So I taught myself how to code to create practical joke programs that made it look like a hard drive was being reformatted - a program I would place on an unsuspecting target's machine while they were at lunch. I created another practical joke to make it look like a digital computer screen had lost it's vhold. Another practical joke would periodically pop up 10 notepads on the desktop. And yet another practical joke program - chug and slug - would chew through memory or slow the system to a crawl. From there, I took up TCP/IP programming because I wanted to remotely send a friend's computer a difficult to locate message which would have his computer moo like a cow. I taught myself SMTP and POP and how to build a generic SMTP /POP proxy server because I was interested in a girl at work and needed a way to seamlessly intercept communication that she (or anyone else in the office) couldn't detect. I taught myself how to hack into other machines to install my practical jokes and to 'net send' messages from my boss's machine to a friend of mine - and tell him to come to my boss's desk.

Programming - in large part - can be one of two things: It can be a way to simply do a job - like a hammer to the carpenter - which makes programming horribly dull for most - or it can be a creative means for expression - which is what made it so much fun and lucrative for me for years.

My advice is to challenge yourself, and your students - the practice and art of having fun. Give them non destructive challenges to achieve.

Practical jokes AND games make for wonderful ways to express and to learn this skill and find yourself in great demand.

Programming involved a lot more thinking and planning, instead of bashing it until it compiled.

Try translating an old BASIC game into a modern programming language. All those GOTO and GOSUB statements can get tedious. I spend a fair amount of my time mapping what goes where in the program before I can even start coding. For fun, of course.

http://www.atariarchives.org/basicgames/

Try translating ancient BASIC games into Python or another modern language.

http://www.atariarchives.org/basicgames/

Try converting BASIC Games into a modern programming language. I'm doing that with Python to learn the finer points of the language while remembering the tricks needed to get PITA BASIC to work back in the day.

All the old programming books are still available on the Internet (see link below). I'm translating the old BASIC games into Python to learn the Python language better. I never got most of the games to work on the C64 because I didn't understand programming or BASIC dialects back then.

http://www.atariarchives.org/

I wasn't assigning blame to either the language or the developer. What I'm doing to learn Python better is revisiting the BASIC games of my misbegotten youth from 30 years ago. Some of these programs were submitted by readers of Creative Computing magazine, written for the DEC PDP minicomputers, or floating around the university computer labs at Dartmouth, Berkeley or Stanford. Translating the classics into a modern language is a bit of challenge.

The Dice program warns that rolling the dice 5,000+ times will take a long time. A typical hobbyist computer back then had a 1MHz processor. On my quad-core 3.2GHz processor, rolling the dice 50,000,000 times takes 192 seconds under Python. By using Cython to turn the dice rolling code into a C extension imported into Python, rolling the dice 50,000,000 took 1.8 seconds.

If you enjoy 1970's technology, try translating BASIC games into Python. That's an exercise in unraveling spaghetti code, chasing GOTO statements, and figuring out what parts of the code was to get around hardware limitations.

You CAN write nicely structure, well-documented code in almost any language, including BASIC and Assembly. I know, I've done it many, many times. It is simply that some languages ALLOW sloppy programming techniques, and that some developers write sloppy, undocumented code.

Don't blame the language; blame the developer.

If you enjoy 1970's technology, try translating BASIC games into Python. That's an exercise in unraveling spaghetti code, chasing GOTO statements, and figuring out what parts of the code was to get around hardware limitations.

Give him one of these books and tell him if he wants to play a game he has to transcribe the code first:
http://www.atariarchives.org/b...
http://www.atariarchives.org/m...

That's how I got started, and around the age of 7 too.

Oh, and wait a year or two before you teach him how to save the code onto audio cassette... Ya know, cause you don't trust him yet not to overwrite a previous save.

Give him one of these books and tell him if he wants to play a game he has to transcribe the code first:
http://www.atariarchives.org/b...
http://www.atariarchives.org/m...

That's how I got started, and around the age of 7 too.

Oh, and wait a year or two before you teach him how to save the code onto audio cassette... Ya know, cause you don't trust him yet not to overwrite a previous save.

Around the time I could read & write I started running & modding these games. All text based so you can focus solely on game mechanics.

http://www.atariarchives.org/b...
http://www.atariarchives.org/m...

Graphics programming can come later.

Around the time I could read & write I started running & modding these games. All text based so you can focus solely on game mechanics.

http://www.atariarchives.org/b...
http://www.atariarchives.org/m...

Graphics programming can come later.

http://www.vintage-basic.net/g...

"BASIC Computer Games
From Wikipedia, the free encyclopedia
BASIC Computer Games
Author David H. Ahl
Subject Computer programming
Publication date
1973
BASIC Computer Games (1973, 1978, 2010) is a compilation of type-in computer games in the BASIC programming language collected by David H. Ahl. Some of the games were written or modified by Ahl as well. It was the first million-selling computer book.[1]

The first edition of the book, released in 1973, contained 101 games that had been collected from a newsletter Ahl wrote for DEC's education department. Many of these games had originally been written on different platforms and then ported to DEC machines. These were easy enough to port to other popular platforms of the era, and many of the games re-appeared on other popular systems like the Data General Nova and HP 2100 series.

Copies of the original collection were still widely available when the first hobbyist microcomputers started appearing in 1975, and it became quite popular with these owners. The release of the "1977 Trinity" machines (Apple II, Commodore PET and TRS-80) was soon followed by a great many new competing microcomputer platforms featuring BASIC, along with the userbase to go with them, and demand for the book led to a second edition in 1978. Sales remained strong for years, and spawned similar collections in More Basic Computer Games (1979), and Big Computer Games (1984) and Basic Computer Adventures (1984).

The BASIC Computer Games are playable under the relatively obscure Microsoft Small Basic development environment for kids.[2] Computer Science for Kids has released a 2010 Small Basic Edition of the classic Basic Computer Games book called Basic Computers Games: Small Basic Edition.[3]

The programs can also be run on a modern Microsoft Windows machine (32-bit only) by downloading the GW-BASIC interpreter.[4]"
(http://en.wikipedia.org/wiki/BASIC_Computer_Games)

http://www.atariarchives.org/b...

I remember hammering in just about every game listed in the 1978 book. It really was fun as a 5th grader to puzzle through why these lines of text resulted in a computer doing stuff.

"Inside Atari DOS" is now online:
http://www.atariarchives.org/iad/

It was published by Compute! Books, not Atari. DOS was written under contract for Atari by a third party, so I'm not sure how much Atari had to do with it. But importantly, it was the original code with comments and extended explanations.

De Re Atari was published by Atari in 1981, and was probably the most detailed programming manual. It didn't have listings for the OS, but it provided enough detail that you wouldn't need them to understand how to use almost every aspect of the machine. (My Atari is in storage, but that happens to still be on my shelf.)

I don't have the OS listings. I'm not sure they were published.

Back in the day, the source code for Atari DOS was included in a published book that explained exactly how it worked. That's one of the things that was great about that platform--so much information was readily available.

Yes, but possibly in spite of, rather then because of, Atari themselves. According to the book "Hackers" by Steven Levy, the Atari 800 was treated as a closed platform in the early days, and Atari wouldn't divulge documentation on its inner workings;

Transferring his new assembly-language skills to the Atari was difficult. The Atari was a "closed machine". This meant that Atari sequestered the information concerning the specific results you got by using microprocessor assembly-language commands. It was as if Atari did not want you to be able to write on it. It was the antithesis of the Hacker Ethic. John would write Atari's people and even call them on the telephone with questions; the voices on the phone would be cold, bearing no help. John figured Atari was acting that way to suppress any competition to its own software division. This was not a good reason at all to close your machine. (Say what you would about Apple, the machine was "open", its secrets available to all and sundry). So John was left to ponder the Atari's mysteries, wondering why Atari technicians told him that the 800 gave you only four colors in the graphics mode, while on the software they released for it, games like "basketball" and "Super Breakout", there were clearly more than eight colors.

Of course, it's true that all this stuff was *later* very well-documented, but how much Atari helped in that is open to question (*). It's certainly well-known that Atari were assholes in general in their late-70s/early-80s heyday, and they definitely tried to suppress third-party development of VCS games. So though I've heard enough people disputing aspects of "Hackers" not to take it as gospel, it does seem to tie in with what I've heard about Atari at the time.

The Atari DOS book doesn't appear to have been published by Atari themselves, and whether it was with their blessing, I don't know. "Mapping the Atari" wasn't an official publication either.

While Atari released documentation, I suspect it was at the level *they* wanted people to be using the machine at. And for all their plus points, the 400 and 800 were clearly intended as more closed, consumer-oriented machines. The 800 did have some good expansion capabilities, but this was clearly meant to be done via its official ports and interfaces designed for that use. The lower-end version, the Atari 400 had far less official expansion capability, e.g. it was never originally designed to support RAM expansion- it was possible, but apparently required far less friendly hardware modifications and installation directly onto the motherboard.

The 1200XL was notoriously even more closed (and flopped massively). FWIW, the BASIC "manual" that came with my 800XL was a paltry pamphlet, and the official DOS 3 manual was nicely-presented, but certainly not deep.

Of course, it all worked out in the end, but I guess what I'm saying is that let's not romanticise the original intentions of companies like Atari back then, who'd have been happy to sit on those secrets and not release them to their users (who they viewed as potential competition).

(*) Those early days (1979 onwards) were before my time- I got my 800XL in 1986, so I can't speak from personal experience.

Model I and "Creative Computing" books/magazines for me. Amazing that these books are available in eBook format now. Search for "David Ahl" on Amazon. Also here: http://www.atariarchives.org/bcc1/

Had loads of fun with Lunar Lander, Hunt the Wumpus, Super Star Trek, and many others.

The Apple I and II were designed strictly on a hobby, for-fun basis, not to be a product for a company. They were meant to bring down to the club and put on the table during the random access period and demonstrate: Look at this, it uses very few chips. It's got a video screen. You can type stuff on it.

Stephen Wozniak on the Homebrew Computer Club
http://www.atariarchives.org/deli/homebrew_and_how_the_apple.php

If you take this route then see these sites:
http://www.atarimagazines.com/
http://www.atariarchives.org/basicgames/
http://www.atariarchives.org/morebasicgames/

It was 'More Basic Games' that got me hooked. Best $7.00 I ever spent on a technical book. I still have my copy.

If you take this route then see these sites:
http://www.atarimagazines.com/
http://www.atariarchives.org/basicgames/
http://www.atariarchives.org/morebasicgames/

It was 'More Basic Games' that got me hooked. Best $7.00 I ever spent on a technical book. I still have my copy.

Load up a C64, Apple ][, Atari, or other 8bit emulator. Demonstrate BASIC. Then point them here: http://www.atariarchives.org/

I still have "Mapping the Atari"
A complete and comprehensive list of every memory address on that machine.

Oh my gawd! I think I'm gonna cry.

In the era of the 1980 home computers, It was an advanced programming technique, on the same level as VGA programming in the 1990's, or GPU shader programming is now. It was more of technological curiosity, with only one or two games used it (Tetris), since the results varied from TV to TV. It did seem strange how using a 320x200 monochrome screen could generate red, green, yellow or blue pixels just because the pixel size was smaller than the sampling rate of the CRT tube.

>The 1980s arcade games with vector graphics (not raster/bitmap) displays were ahead of their time. Now that we have Flash and SVG that can specify graphics in vector format,
>we could use display HW that can render with vectors instead of pixels, for even smoother and better looking displays.

It's still extremely hard to get a convincing "Tempest", "Lander" or "Asteroids" on a PC display. There is some real subtlety to the vector system.

I played Lunar Lander a lot, but I always kind of had a grudge because I knew they stole the idea -- I really enjoyed playing this: http://atariarchives.org/basicgames/showpage.php?page=106

a book released a book in the 1970's where they had a simple chess like game in basic that had a 3 x 3 array. The computer would make a random legal move.. if the computer did not lose after the move.. it saved the move for next time. if it lost after the move it would remove it from memory or more advanced was to block that move if the board had the same set up. so while he is making a robot learn to walk by its self (cool) the logic process in programing is not new at all.. This was based on a math question from 1962 http://www.atariarchives.org/basicgames/ http://www.atariarchives.org/basicgames/showpage.php?page=83

a book released a book in the 1970's where they had a simple chess like game in basic that had a 3 x 3 array. The computer would make a random legal move.. if the computer did not lose after the move.. it saved the move for next time. if it lost after the move it would remove it from memory or more advanced was to block that move if the board had the same set up. so while he is making a robot learn to walk by its self (cool) the logic process in programing is not new at all.. This was based on a math question from 1962 http://www.atariarchives.org/basicgames/ http://www.atariarchives.org/basicgames/showpage.php?page=83

Hi, I'm the author of "Invent with Python". I'd like to go into some more details about the book.

I wrote this book because I noticed there was a lack of "by example" programming tutorials for Python that young adults could follow along. I first learned BASIC from a book which presented the complete source code for games (think Byte magazine or those books on http://atariarchives.org/ )

It seems that most "4 kidz" programming books were focused at too high of an abstracted level (RPG Maker, game creation kits, etc.) and didn't go into actual code. I wanted something at the level of BASIC (but without BASIC's hang ups). Each chapter of the book focuses on the complete source code for a small game and explains the concepts from there. The first several chapters of the book use ASCII graphics for their games (tic tac toe, othello, hangman, etc.) and the later chapters go into graphics and sound (Pygame makes it very easy). The book skips some topics that aren't necessary for these basic programs (OOP, recursion, most of the standard library's modules, even file I/O). The book is meant to be an introduction that gets the reader creating programs as soon as possible.

What I noticed was that Python makes writing these games much easier than BASIC ever was and Python really should become the modern replacement for the niche that BASIC had. Also, Python is a real language (unlike game creation kits) and can scale up to the professional level (unlike BASIC).

Oh yeah, and if you check out the book ( http://inventwithpython.com/ ) the web version is always more up to date than the PDF version. Thanks for the traffic Slashdot!

I don't suppose you've ever heard of BASIC before, have you?

[emphasis and link added]

Although developing a hacked-up personal computer implementation of a language with a publicly available spec (note the date) unencumbered by copyrights or patents was better that Ballmer could do, it wasn't exactly a great achievement in computer science.

Sokoban will keep your brain busy for a while.

And Freeciv if you like a more complex challenge.

Tetris is of course also a classic good game to train your reflexes with.

And if you like flight simulators you have FlightGear.

And of course - if you want to go really classic check out Basic Computer Games.

Star Raiders was a great game. It was fast, hard and a really fun game to play. Considering when it came out, it was a real testament to just how good the Atari 8 bit was in terms of graphics and sound. It was all there - display list with different modes, player-missile graphics (sprites), good sound effects for the time, and fast 3D action. In general the Atari 8 Bits excelled at real-time 3D types of games compared to the C-64 (Encounter anyone?). The 64 kicked the 800's butt in terms of platform games (it has better sprites) and everyone loved SID. Paradroid was great, and who can forget the Last Ninja tunes, ghosts and goblins etc. To get a good idea of what the 8 bit was capable of check out 'De Re Atari'... it's by the guy who wrote Star Raiders. it's a really good read, and any Amiga hackers will see lots of deja-vu when they read how players work and priority levels and the magic that was Jay Miner.

http://www.atariarchives.org/dere/
No flame war intended here. Like I said the C-64 was an awesome machine in it's own right and rocked.

Here's how I think of the lineage (regardless of company) Atari 8 bit -> Amiga C64 -> Atari ST (but not so good a fit, maybe the Atari ST is more like a new PET?).

Any commodore history folks have some insight? The C-64 for the time was better than the ST in my opinion. Jay Miner actually wanted to build a 68K based successor to the 8 bit at Atari and when management said no he left and did it anyway and we got the Amiga.

--Tarp

Commodore users were used to machine language monitors, where you could switch from hex, to binary, to ascii, to assembly. Assembly on this level is machine language, and anyone who says different is just an idiot. Its not compiled, it is just ran by executing a particular memory location. JSR = 20 = 32 = " " = 100000. Some of the better ML monitors actually displayed the opcodes with asm code. http://www.atariarchives.org/mlb/chapter1.php - this book points these facts out very clearly. Pretty much making them all the same low level languages. Now, when you start to use psudo ops, lables, variables, libraries, self relocating code, ect... its not on the same low level, but is still low level.

The later 1050 used double density disks (but could read and write single density disks with a lower capacity).

You had to get the doubler ROMs to get true double density 180k, otherwise the drive did some weird 1 1/2 density 160k...

The 1050 supported 130K "enhanced" density". The later XF551 supported true double density and apparently was also true double-sided, but that came out pretty late in the day and it wasn't that cheap by the standards of the time.

Home computers at that time (6502/6509/Z80) ran at around 1 MHz . Since instructions took 1 to 3 clocks to run, you get around 300K instructions/second.

According to De Re Atari's chapter on floating point performance, the maximum times for the various operations were as follows:

Integer -> FP = 1330 micro-seconds
FP -> Integer = 2400
Subtraction = 740
Addition = 710
Multiplication = 12000
Division = 10000
Load = 70
Store = 70
Polynomial evaluation = 88300
Exponentation (e) = 115900
Exponentation (10) = 108800
Natural Logarithm = 136000
Base 10 Logarithm = 125400
Set to zero = 80
Set register in X to zero = 80

Assuming a calculation just uses basic arithmetic operators, then you get
around 30 to 500 FLOPS.

The 6502 CPU was actually clocked at the same rate as the pixels in the framebuffer were written out to the TV/monitor. All of this was documented by Chris Crawford and many others who wrote De Re Atari

There were four sprites you could program - each had its own band of memory (we would call them cursor overlay planes these days). Each byte described a single scan line. Control registers defined the horizontal position and amount of stretching (power of two) of the band. You had to write some assembly language routines to shuffle these bands up or down. If you wrote a horizontal-blank interrupt you could have multiple moving sprites, each at a different position per row. These were the player in player-missile graphics. There was a fifth band which were the missiles (the ping-pong ball in video-pong and video-olympics). Each pair of bits in a byte defined the location of the missile associated with each player. Collisions between players and missiles were detected by reading various collision registers.

It was great fun programming, but the hardware was capable of so much more than what was possible with the Basic compiler that you really needed the assembler cartridge. Otherwise you had spend your time writing assembly language using numbers rather than mnemonics. It was interesting to see that there were assembler routines to handle the floating point arithmetic, while other assembler routines handled the rendering of trapezoids - through an XIO command. Other Basic interpreters (the Dragon 32) had assembler routines for matrix/array calculations. If they had put all that together, where would the 3D industry have been now?

That sounds eerily like Computers Don't Argue. (Why worry about malice? The amplification of initial incompetence will be much worse.)

I fondly remember figuring Atari's particular flavor of basic back in the day. It was fun making loops that used feedback variables assigned values from STICK(0) or PADDLE(0), etc. in order to make the screen flash or do other crazy stuff. And with SOUND statements driving any of the four channels, half the fun was driving the parents nuts. (Or at least until you had to stop or risk having the power adapter taken away.)

These links pretty much cover it:
Atari BASIC: The good, The Bad, The Ugly

Atari Basic Self Instruction Guide, (c) 1979

It was probably the only language I figured out (but have since forgotten). When moving to other computers (Amiga and then PC), it was just a lot easier to use software to achieve results rather than to puzzle together some code. (Not to mention there were plenty of other distractions in J.H. and H.S.)

Got a labor shortage?

Hire people willing to work for less.

The market will fix the problem. No need for special legislation or hire wages.

Sorry, I don't mean to be an ass, I just am, but your post bothers me because it appears to imply legislation allowing more people into our country is market interference, but the most true solution to letting the market decide is to let people in willing to work for less. We all save money as the cost of services is reduced, and unless we value Americans as people more than others it is a net positive. Even if we don't value Americans for it can be a net positive for our country. As long as foreign workers are not being abused (paid way to little, or forced to take pay cuts or lose their work status, in other words, as long as their foreignness is not being used to artificially suppress the wage), then it is a good thing. It is exactly the same economically as a machine getting invented to do the work. I mean think of the number of farm workers put out of business by the diesel engine. Or the number of computers put out of work by computer scientists and electric engineers.

Oh, yeah. What did Commodore have at this time? The PET? I heard rumors it had games.

I can confirm that it did, in fact, have games. Unfortunately, you had to type them all in by hand from a book and included titles like "Hunt The Wumpus", "Lemonade Stand", and "Tic Tac Toe". If you did want to save them, and you were lucky, you had a tape recorder you could use...

You were also limited to the alternative special characters (two or three for each letter, a bit like the commodore 64). I kinda remember a version of space invaders that used the alternative character set.

Apple's HiRes mode kicked the crap out of this.

Early games on the Apple II:

Mystery House
Wizard & The Princess (I hated that desert/maze)
Evolution (kinda like an early Spore...?)
Sneakers (a more-fun Space Invaders)
EAMON (not graphical, but a very early RPG, although honestly it never worked right for me)
Dung Beetles (pac man w/gigantic map & voice synthasizer that said "We Gotcha!")
Castle Wolfenstein (parodied by "Castle Smurfenstein" by Silus S. Smurf)

W

The first minigame I ever saw was in Major Havoc, which came out in 1983. As you approached the space station for the next battle, you had a little Breakout game to play in the lower right corner of the screen. When you cleared it, you got an extra guy. I don't know how popular it ever was or how well known, but there you are, and at least moderately early.

Physics puzzles? 1992? Since the article doesn't confine itself to graphic games, that's not even close. Try KINEMA. The book the listing on that page was taken from was published in 1978, but I saw it a year earlier on a timesharing system my high school was connected to. Yeah, it looks like a quiz, but there are quiz games too, and everyone called this a game.

I wonder if this guy ever even played Dragon's Lair. It didn't use a CD-ROM because it predated them, and the animated scenes wouldn't have fit on one anyway; it used a laserdisc. The picture wasn't "tiny, grainy", it was very high-quality hand-drawn animation -- by Don Bluth, for God's sake.

The article makes it sound as if the "brag board" was something the game industry invented. Actually, it had been around for decades -- albeit informally, and probably illegally. When you scored amazingly well on a pinball machine, you recorded it by carving the score and your initials into the frame around the backglass. Preferably while the manager of the establishment hosting the game wasn't looking. The tradition carried on into coin-op video games. Building it into the machine did two things. It prevented lying about your score, and it saved wear on the game cabinets.