The Let's Play Archive

In Search of the Most Amazing Thing

by ManxomeBromide

Part 5: The Nonfunctional Era

Part 5: The Nonfunctional Era

Starting up my next session, I was greeted with this screen immediately after loading:

I'd been planning on comparing the DOS version of this game to the other three versions at some point this LP, so this seems like as good a time as any to do it. Despite being extremely cryptic, there are three important facts we learn from that message up top, or by looking more closely at what it implies and refers to:

How do you ship a game written in BASIC in 1983?

On most systems, this is pretty easy. Two of the other platforms that the game was written for—the Apple II and the Commodore 64—had a version of BASIC burned right into their ROMs. On the C64, this was all you needed, and you'd just load the first file in and run it. On the Apple II, you also had to make sure that the disk was formatted and had enough DOS on it that you could load and run your files.

The Atari home computers, however, did not ship with BASIC. You needed to have purchased the BASIC cartridge and have it plugged in. As long as that was in place, you could set up a disk with enough DOS on it to boot and then a startup program to kick you into BASIC and run the program.

The PC was a weirder case, though. You had a DOS disk that you needed to boot off of, and you had an "advanced BASIC" named BASICA.COM that was on the DOS disk as well. In Search of the Most Amazing Thing relied on features of Advanced BASIC, but it didn't ship with it. Before you could run the game, you had to "install" it, onto itself, which appears to copy over BASICA and also set up the disk to properly autoboot into it.

Why is running in DOS a terrible idea?

All of that is well and good, but it turns out that in 1983, three-quarters of BASIC was actually in ROM. They were on the motherboard on the original PC and the PC XT, and on a cartridge you plugged into the PCjr. My childhood career with this game ended abruptly when the family PC was upgraded to a more modern model. Every clone, and every AT-or-later actual IBM, would just die instantly once you put your old disk into the new machine, because it would try to call out to ROM routines that no longer existed.

That's simple enough to fix; later versions of DOS shipped with a complete BASIC ("GW-BASIC") purely in software. That's mostly fine, but apparently they changed the syntax on this somewhere along the way. Some of the versions out there—sadly, including the one that the Internet Archive provides on its MS-DOS streaming arcade—will crash to BASIC with syntax errors the first time you enter a Trader's Hut. It's a trivial fix (apparently there is some disagreement across the dialects about whether or not you are allowed to name a variable TIMER), but whatever mod you're using has got to do it.

The final awful bit comes when we look at the code in the vicinity of my crash.

As I mentioned back in the firat update, the game is constantly loading new bits of code in to run as the game progresses, because it was built to run on a PC with 64KB of RAM and it can't fit everything in at once. It does this by having the BASIC programs load and run each other as needed. The problem is, loading and running a new program blows away all your data, like, you know, where you are on the map, what you're doing, who you're talking to, and so on and so forth.

The game deals with this by storing this information in a chunk of memory independently of BASIC, and then reading it back into BASIC variables at the start of each program. As long as it's messing with memory directly, it also directly uses 12KB or so of memory to store the full-screen graphics in a compressed form. (Having that handy is one reason screen transitions are so fast.) It's also using 198 bytes of space for machine code support handling those screen transitions.

On pretty much any 1983 home computer but DOS, this is fine. But on DOS, it's not fine. Due to some quirks in the way the 16-bit x86 chips work, DOS is basically allowed to put the programs it runs and that data they use anywhere it wants in memory and the program running won't really notice or care. This requires more work once your program is using more than 64KB of code or data, but DOS and the EXE format take care of that automatically. By the time the program starts running, everything stops caring.

I suspect the original unmodded version knew that it could reserve 12KB of memory where nothing was going to touch it, but that probably stopped working around DOS 2.1. Looking at what I'm running, though, it appears to just yolo all of this into 12K around the 320KB mark in RAM and hopes for the best. I know the original code didn't do this because the machine I ran this on back in the day only had 128KB in the first place. But here? Well, I did some checking on my DOSbox state and it looks like running a BASIC program usually ends up only using space up to the 256KB mark if even that. So it's usually fine. But this time, it looks like I rolled snake eyes and DOSbox decided to load BASIC straight into the memory space that the code eventually trashes.

At least restarting the emulator fixed it.

So, why are you bothering with the DOS version, again?

Mainly because it's the version I had as a kid, but also because all the other versions have odd compromises or ugly bits that make me feel like they were not the original design. We've now basically seen all the screens that the game has to offer, so let's see how they look on the other systems!

The Apple II

The pros: Pretty good BASIC for graphical stuff, needs machine language support for sound and some of the trickier graphical bits, but it's easy to stick that in. Decent hi-res graphics resolution (280x192) and a better palette than the CGA's cyan-magenta-white. Runs out of the box, assuming you had an Apple II newer than the original 1977 model. Our modern idea of the "default" Apple II—the Apple IIe—came out the year this game did, though.

The cons: Drawing complicated shapes can be a bit slow. Disk access is incredibly slow. Color accuracy is kind of a problem; most graphics will have color "fringes" distorting the edges. More on this when we look at the Atari version.

One of the reasons I suspect that the CGA version is the "master" version is because there is an otherwise-inexplicable amount of magenta in the 8-bit versions.

Also, check out that green and purple fringe around all the characters. Hope that doesn't bug you because all the text in the game will be lousy with it on the Apple II.

For everything, really. We had a bunch of Apple IIe machines at school so I sort of grew up with them but I really, really do not miss the experience.

No complaints here.

Or here, other than that I feel like the DOS CGA graphics were crisper.

Again with the magenta everywhere.

Applesoft BASIC didn't have "draw a filled rectangle" operations built-in and doing it by hand in BASIC is painfully slow. We just get starker linework instead.

A pretty solid B-Liner, and we are a stick figure now because of Applesoft BASIC's special ability to quickly draw and erase vector shapes. This sort of replaces the pixel-color-swap software sprites that were in PC BASIC—again, I prefer the DOS version, and on DOS we tilt back and forth as we accelerate, a courtesy that Apple does not provide.

The Apple version is the only one where the B-Liner's sprite on the driving map isn't just a circle.

This is almost exactly the same as the PC version.

The flight controls are noticeably more clumsily laid out, though.

The Atari Home Computers

The Atari 400 and Atari 800 were released in 1979 into a home computer market dominated by the Apple II, the Commodore PET, and the TRS-80, and it was—at least by the standards we use today—miles ahead of all of them. Its graphics and sound were based on their arcade machines and on the primitive yet strangely effective hardware of the Atari 2600. I've talked about the Atari 2600's graphics technology in great depth as part of my LP of Solaris; the Atari home computers graphics pretty much added a text mode and a proper bitmap mode to all this (that is to say, you could just ask the graphics chip "please set these pixels at these coordinates", or directly write strings to screen memory and have them appear on the screen) and also had some nice additions like hardware sprites.

By the time I was aware of the Atari home computers personally, they were already also-rans because the Commodore 64 was just enough more powerful than it to take the throne... but the Atari computers not only predated the Commodore 64, they predated its predecessor, the VIC-20. An Atari 800 will blow a VIC-20 completely out of the water.

The pros: Best use of color across all four of these systems. The Atari computers and consoles had a 128-color palette that was the best available across basically everything until the 16-bit era, and was no slouch compared to some of those either. Fastest UI response time of all the 8-bit versions. You can control it with a joystick.

The cons: "Fastest UI response time" still doesn't mean fast. Worst graphics resolution of any version (160x192). The most primitive disk hardware, which means that you have to swap floppies mid-game regularly. It's a BASIC game, and BASIC is Sold Separately. Graphical elements are often slow enough to appear that you can see them get slowly rendered into place. Mire Crabs are sprites and it's not difficult to distinguish them from Night Rocks in-game both by sight and by how long it takes them to appear on screen. Although you can control motion with the joystick, there is no brake key and you have to stop by nudging the joystick just so.

The wacky: Despite the Atari's vastly superior color capabilities, the game doesn't use it. If I load up a game and visit Smoke, I get this odd display:

This is because my emulator has not been properly configured, and it is acting like I've hooked the Atari to a VGA monitor instead of to a television screen as intended.

The way North American televisions work is that there are two important signals mixed into the channel you're tuned to: a luminance signal that is pretty much an analog representation of the black-and-white image to display, and a chrominance signal that describes the color to lay over it. The chrominance signal exists at about 13MHz, much faster than luminance would ever change in a photographed image.

(Furthermore, the reason that "4.77MHz" and "1.08MHz" speeds keep showing up in CPUs of this era is that computer manufacturers would just buy colorburst oscillators in bulk and then divide the signal by 3 or 12 to become their CPU clocks. It's about the right speed, and they're super cheap because TVs are everywhere! Hooray!)

The upshot of this, though, is that if you have a computer display and you alter the luminance fast enough—say, by drawing extremely tight patterns of vertical stripes—you can trick the television into treating that as a chrominance signal. The Atari programming manuals referred to these as "artifact colors", and I'm pretty sure that's the standard name for it everywhere.

Flipping a switch in my emulator gets us much closer to the intended results.

In an effort to thwart the uglier parts of North American television color technology, text always appears on a background of the same hue. Only luminance and saturation change between foreground and background in the high-resolution modes. When you aren't relying on artifact colors, it mostly works.

The Atari insists that its text and high-resolution graphics modes have text and background that are variations of the same hue. I think that this is to avoid another class of color artifacts on NTSC televisions. More importantly, the fonts on the Atari are "double-dotted", which means that you never have pixels lit just on their own. Having two pixels lit in a row is a good way to get a less distorted display, and I find this text much more readable than the text on Apple's high-resolution mode.

That said, you had 16 hues to pick from, what is up with the purple, eesh

This is recognizably the same image as the one used on the Apple and PC, but the color noise really hurts it.

On the other hand, this is the first case where the aisles are different colors. The PC could have done this, it just didn't. Tsk.

This is the first dramatically different display we've seen so far, and it's also much faster than the Apple equivalent. These are actually character-based graphics; there's a collection of characters in the font that you can use to draw boxes and lines and such and here it uses them to animate the shopping cart and draw the shelves very, very rapidly. At the end of the day, these are just controlled by commands that print out text.

The Atari doesn't have enough RAM to spare to have a blank screen to fly over, so Metallica's entrance just appears as the B-Liner stays in place. Our jetpacked self has lost quite a few pixels. (Atari's sprites, in an effort to avoid color distortion, have half the horizontal resolution of the main display, which makes them behave very much like the Atari 2600's sprites in appearance and behavior.)

The walls are white now, because the Atari is the first system on this list that makes it reasonable to alter the background color.

Driving doesn't look great; the artifacting really messes with the display. If I tell my monitor to stop simulating artifacting, we see why:

Those shapes match the DOS version pretty closely, though the Popberry tree is quite a bit smaller. These aren't sprites; they are painstakingly drawn onto the screen with line-drawing commands. Honestly, I suspect it would have been faster to just do DOS-style software sprite-copies by hand. This was probably less work to port though.

One hilarious side effect of this though is that unlike the DOS version, it's too slow to draw them at speed. That means the Mire Crabs are sprites, and you can immediately distinguish Mire Crabs from Night Rocks because Mire Crabs appear on the screen instantly and are made of much fatter pixels with less detail.

Flight screen is pretty much the DOS one with nicer colors. This one's also pretty funny if we turn off artifacting:

Notice that the green and purple backgrounds are lines that are equally spaced. That's because on NTSC, the hue is encoded in the signal as its phase, so offsetting the vertical lines changes the color.


The PC was released in 1981, a relative latecomer to the home computer space but also not entirely sure what it was trying to be. The Color Graphics Adapter that this game is programmed to use had television and monitor output, and each was capable of different kinds of color graphics. The monitor had relatively sane 16-color palette, but when you took it into its default 4-color graphics mode, your palette options were cyan-magenta-white and green-red-brown. The logic is sound: your four colors are toggling whether red or green or both are part of the color, and then palette selection ends up toggling whether blue is part of every color. But while the logic is sound, the outcome is nonsense.

When hooked to a television, you were restricted to monochrome text modes, but the graphics modes let you do "artifact colors" like we saw with the Atari. In fact, there was a 640x200 graphics mode that was ideal for this, with four logical pixels turning into a single blob of color on the television screen. You could get 16 colors out of it—in what is not at all a coincidence, they are the same 16 colors the Apple II could produce. All of the Apple II's colors were created by intentionally exploiting this color-artifacting technique. (That's also why Apple text has those distinctive awful color fringes.)

The pros: The highest resolution display of any version (320x200), with pixel-perfect control over the colors available. This results in the crispest graphics. Extremely fast graphics operations, including flood fills. The other versions spend entire seconds drawing out things like the Night Rocks; I can only catch it mid-draw on DOS if I do frame-perfect video capture and then frame-advance through it. The smoothest animation and controls of any version by an extremely large margin.

The cons: An awful cyan-magenta-white palette that seems to have infected most of the other versions as well. Does not run unmodded on any system that isn't an original IBM PC, PC XT, or PCjr. Available mods are somewhat unstable. Most of the game's realtime elements are based on the speed of your processor instead of relying on the system clock. Many text and status screens were intended to be viewed while code or data was being loaded off the floppy disk, and without frame-perfect video capture important messages are often lost.

You've seen the screencaptures for DOS all through this LP, so I won't replicate them here. What I will instead show is the incredibly kickass Musix they provide as the sample, showing how the Musix system works:

Normally you'd think that drawing one continuous line would not let you draw multiple objects or stick-figure rays, but nope, let's just add a border and exactly retrace our steps as needed. Hats off.

The Commodore 64

The C64 was released in 1982 and was in many ways a more powerful home computer than any of the other systems here. However, it also had the weakest BASIC of any of the systems described here, by a dramatic margin. As a nearly-pure BASIC game, this means it has the most machine-code backup of any of these versions.

The pros: Tied with the PC for best resolution (320x200) and can display many more colors at once, subject to some restrictions on color density. Joystick control and hardware sprites for fast animation, like the Atari. Commodore 64 BASIC is the best documented of these four, so it's relatively simple to follow along with many of the more exotic things it attempts.

The cons: No built-in graphics primitives, and the machine-language support programs they created to make up for it are unforgivably awful. The UI is so slow and unresponsive it is nearly impossible to use with any precision. Despite having the best sound chip by a comically huge margin of the four systems, the Musix playback sounds the worst of the four. The strengths of the C64's graphics and sound systems are not exploited and the weaknesses are left in as ugly warts instead of being worked or designed around. As much as I love the C64 as a system, it has the worst version of In Search of the Most Amazing Thing, and it isn't even a close call.

It's also the only system on this whole list that can't autoboot off of disks. You had to manually load and run the program:

Or, you could just not load and run the program and instead poke around to see what's on it:

File sizes there are in "blocks" with 4 blocks being about a kilobyte, so we've got 15KB in machine code support (the largest of the four, but C64 BASIC is the weakest, so this checks out), and a bunch of files named ".BAS" which was not at all the done thing on the C64 and kind of rams home the idea that this was a hasty port to cash in on a new and popular platform.

The largest of the BASIC subprograms is GROUND, which covers all of your jetpack work and also the driving and B-Liner cabin interfaces (trading off to BCOMP and FLY as needed if you go check the computer or the flight controls). It's weighing in at just under 20KB. For comparison, when the goons went and typed in a bunch of programs from Compute's Gazette the machine code programs were all under 8KB and the largest BASIC program was just over 10.

It's also got this odd little screen when you start up and this is to automate the process of modifying BASIC so that it leaves enough memory free for your graphics and machine code support. The technique it's using here is almost exactly the one that Hex War used which I dissected for that old thread.

The B-Liner here has the strange vertical lines again. This kind of makes me think that they just borrowed the graphics from the Atari version, because the C64 did not permit artifact colors the way the Atari did. Normally it used a split video signal to make sure interference would never occur, but even if you plugged it into a television, Commodore made sure that the graphics display pixels did not sync with the NTSC color clock, specifically to block the technique.

The C64's bitmap mode can display all 16 of its colors at once, but when you're in high resolution mode (320x200, same as DOS), each 8x8 square of pixels can only have two colors of the 16 (foreground/background). What we see in this image is zero effort put into actually aligning the elements of the display so that they line up with those 8x8 blocks, and as a result we get a form of graphical corruption called "attribute bleed". The C64's predecessor, the VIC-20, was also subject to this and had it worse because the VIC-20 also lacked sprites. Here it just looks lazy. They really should have dropped the resolution to 160x200, which would give them a background color and 3 independent colors per 8x8 block. That would have been enough to render this in full color with no compromises they hadn't already made on the Atari.

More attribute bleed, more inexplicable vertical lines.

This could have been in full color, but the Atari bitmap data was sitting right there, I guess.

Also like the Atari, it's using character graphics. Unlike the Atari, these character graphics are utterly terrible, even though the default character set could totally match the Atari's display. I don't even know.

Finally. This is the first image that's actually pushing the C64 to use graphical capabilities that the other ports did not. Even so, it's still not great, and we ourselves aren't as detailed as we could be.

Much like the Atari version, now with no artifacting and thus properly sharp displays. Despite being drawn on the bitmapped display, the popberry trees and trading locations are all much smaller for some reason. If they were sprites, this would make sense (Atari sprites can only be 16 pixels wide but may be any height, and C64 sprites are 24x21) but they aren't.

Also, these elements take multiple seconds to draw out on the screen. If you don't have an emulator with a switchable Warp Mode on it, driving any distance is completely impractical.

Hey, it's my least favorite display in the entire game in any port! Attribute bleed everywhere and a chair that they expended absolutely zero effort on. I get that they wanted to keep a higher-resolution display, but so much of this could be fixed by replacing parts of the display with sprites that just don't move.

It didn't have to be this bad.

The flight control screen looks fantastic and is probably—as long as you're only looking at static screen shots—the cleanest version of any port.

But that's only true because it's a static screen shot. Actually interacting with it is utterly, unforgivably slow. This is me moving the cursor over to flip the WHERE switch, in real time.

And that's after spending 25 seconds just drawing the display itself. This is all the more infuriating because there's no reason to bother with painstakingly drawing any of this line segment by line segment. Switches are only ever in two states, and the C64 graphics was built around something more like NES tile graphics. Button state could be swapped in a single frame just by blitting new tile graphics over the old button location. The only bits that really need generic line drawing are the rotary dials like the altimeter and the homing beacons, and those can render at a more or less acceptable speed.

Besides all that, it's actually even worse than it looks, because BASIC can only do one thing at a time. Those bumps of the cursor, a second apart? If I move the joystick and recenter it before the full second completes, the joystick input is lost completely. This is a problem the Atari port has too. Joysticks don't buffer their inputs the way keyboards do.

And so...

And so, this is what the other versions of the game look like, and why I have no qualms whatsoever about inflicting the CGA's terrible palette on you. Crisp and responsive graphics and an actually usable UI are making up for it, by a tremendous margin.

But if you had to go with an 8-bit version, I'd probably go with the Atari version.