I also started programming on a C64... good times! I also remember radio shows about C64 programs (in Dutch!) that would discuss the program first, and then transmit the source code over radio waves. Since the C64 had a cassette tape as memory, you could record that part of the radio show on a cassette tape, and play the tape back on your C64. It was a bit error prone, and I still have the occasional nightmare from the strange sounds...
"BASICODE was a computer project intended to create a unified standard for the BASIC programming language. BASIC was available on many popular home computers, but there were countless variants that were mostly incompatible with each other. The project was initiated in 1980 by Hobbyscoop, a radio program of the Dutch broadcasting organisation Nederlandse Omroep Stichting (NOS).
Around 1980 the Dutch broadcaster NOS began transmitting computer programs by radio. Because programs and data were stored as audio on compact cassettes, it was possible to record such a broadcast on tape and load it into the computer later. However, because of the problems mentioned earlier, the program had to be adapted for nearly all popular types of computers and broadcast multiple times as well. Because the compact cassette has a very low data density compared to today's storage media, the recording of the programs took quite a long time, and only a limited number of programs could be broadcast per show. So, the additional broadcasting of different versions of the same programs was a great inconvenience.
In 1982 the executives at NOS decided to develop a unified data format. An application that was specific for each computer model, called Bascoder, managed the recall and storage of programs and data in this unified format from tape. The Bascoders were broadcast by NOS as well, but could also be bought from NOS on cassette and shared among friends and acquaintances. The format, which was very well-protected against interference, could be read and written by all popular home computer hardware. The robustness of the format also made broadcasting via mediumwave radio possible, which increased the range and in turn the number of potential users."
We copied the (100% pirated) cassettes very carefully in CZ, never mind recording fancy radio waves. And it was still unreliable as hell!
The magnetic cassette loading was sometimes more suspenseful than the actual loaded game :-)
Gamified by live-tuning the cassette head with a screwdriver...
I remember the early games on Amstrad CPC464 were pretty easy to copy. Then game makers started compressing the signal heavily in order to shorten load time, which at the same time made cassettes much harder to copy due to increased sensitivity to errors.
The sound was pretty different too. I still remember the sound of the Sorcery tape which was a lot more distorted than the early games :)
Luckily, nowadays you can still get that suspenseful experience by attempting to flash BIOS/UEFI on your motherboard. Will it work? Or will my motherboard get bricked in less than two minutes?
I've only heard about that era, I wasn't alive back then yet. Only thing I know is a cousin that had an old MSX, he'd go to the library to pick up old books containing full BASIC sources, typing them over meticulously and recording it on tape (or something, at least the things were loaded off of tapes. This was probably mid-90's)
Excellent work and a fun read. I've got fond memories of loading programs from cassette tape on a Vic-20 in the early 80s (it took 10 minutes or so kids). I tried typing in a game from a magazine and was unsuccessful too--it never worked right, pre crc. Me and a few cousins had a ball though with a random sentence generator program. We filled all the data statements with all the bad words a group of 12 year olds could think up. Good times.
It was my first exposure to programming, and a bit too early perhaps. Other than an occasional session on an ancient TRS-80 in high school, I didn't do any real programming again until taking a Turbo Pascal course in the mid 90s in college.
I have the opposite feeling. I used to write programs for the trash-80 with hundreds of variable all named $A, $B, $C...$AA, $BB. To top this off the inability to renumber lines meant that once you added 9 new lines you needed to solve the problem with a goto to a sub-routine ultimately ending up with spaghetti code of the worst kind.
Of course not having a printer meant the only way you could understand the now totally tangled spaghetti code was to keep all of it in your youthful short-term memory. Having nobody you could ask or learn from just added to the toxic mix.
Even now thirty years later the thought of programming like this makes me feel ill.
I don't know what TRS-80 you used, but I do know that the Microsoft BASIC in the Color Computer had a re-number command (RENUM newline, startline, increment). It was actually a very sophisticated version of BASIC:
As a kid (and I still own them) I had a Color Computer 2 and 3 - I programmed a ton of things on them, which ultimately led me to where I am today as a software engineer.
> Each character of those variable names takes up RAM.
Not to mention that at least on the C64, only the first two characters are significant anyway, ie, 'abba', 'ab', and 'abcd' all refer to the same variable.
I was never a big fan of Microsoft Basic. My prefered systems were BBC Basic (BBC Micro) and Locomotive BASIC (Amstrad CPC). Locomotive was larged based on BBC BASIC and both had a command called RENUM that would renumber your source for you. It was invaluable for smaller projects but I remember some of my larger projects I would have routines separated by thousands. eg
10 REM main routine
20 REM do stuff
1000 REM another routine
1010 REM do other stuff
2000 REM a 3rd routine
Then have GOSUBs / GOTOs using the n*1000 as the entry point into that routine. RENUMing the source when you've got the aforementioned structure was not an option.
ISTR that Locomotive's RENUM took optional arguments that let you renumber chunks of the program separately... yep! You could renumber starting from a given line number through the end of the program, so in principle you could do a whole-program RENUM and then restore the larger gaps to your GOSUBs: [1]
I have a vague memory that there was a reason for not doing this - something about using more memory or hitting a ceiling of some sort. The major problem of course was not having anyone to tell you that this was a bad idea.
I still remember trying to work out how to program in machine code by poking different values into memory. I had my own guide on what values to avoid and what values worked without having the slightest idea what I was doing.
Absolutely. BASIC on a Sharp 6000 pocket pc[1] for example was limited to (32k or) 64k lines of 256 characters each. Like in many other basic versions, there was no automatic renumbering. Discovered it the hard way.
I had to do that when writing programs in z80 assembly language - then converted to HEX bytes for each instruction.
It was always a pain because instruction-length varied and you had to account for the length when calculating the number of bytes to jump forwards/backwards. (I tended to prefer relative-jumps to absolute ones, but either way the same problem remained.)
I wrote a blog post recently about my early memories doing similar things on a ZX Spectrum. One thing I remember fondly is the books I checked out of the local library, which were full of listings.
Scrolling down to the bottom of this page you can find them online these days:
Well, in the Mythical Man-month, Brooks describes the difference between accidental (later clarified as incidental) and essential complexity.
In other words, computers getting easier to use doesn't affect the complexity of the aforementioned "business requirements" or the kinds of research problems we attempt to tackle, which are only getting harder.
But yeah, ten minutes to load one program from tape... that was a productivity killer.
The inefficiency lies is in translating the business requirements of an application to something the computer understands via your brain and code syntax. There are plenty of ways that process can be optimised.
They've been optimizing that process since the 1950's. My hunch is that until they've built something sufficiently autonomous to accept blame when something is broken, humans will still be coding.
> The keyboard is an efficient way of getting a program from one's head to the computer, so I don't see that changing.
This seems an awful lot like saying, in (let's say) the 18th century, "the horse is an efficient way of getting from one place to another, so I don't see that changing." The keyboard seems efficient now, but it, or, to be certain, some current and apparently perfectly satisfactory technology, certainly won't do so after the next big innovation.
I'm definitely not suggesting holding your breath; it would be foolish to say "keyboard-less programming is just around the corner, so don't bother with your keyboard!" On the other hand, a confident prediction like:
> People will be programming computers for a very long time to come and they will, for the most part, be using a keyboard to do it.
(the keyboard part, at least) seems to be a sure route to some future "640K should be enough memory for anyone."
Indeed it is! We are all supposed to be living in a post PC world where everything we do, programming included, will be done on a tablet!
> (the keyboard part, at least) seems to be a sure route to some future "640K should be enough memory for anyone."
Heh. Ok. But is this the same thing really? I mean, how many forms of input are there? We've tried the obvious ones and the keyboard just sticks with us.
> Heh. Ok. But is this the same thing really? I mean, how many forms of input are there? We've tried the obvious ones and the keyboard just sticks with us.
I guess it's not the same thing in that it's at least obvious what one could do instead of a 640 KB limit (just install more memory), but I still think there might be some life to the analogy. I agree with you that there's no obvious substitute for the keyboard, but that to me says only that it is a local maximum—with a potential further global maximum to be discovered, probably not by obvious changes, and necessarily not by perturbations to what we have already—which might (or, I'll certainly grant, might not) be bettered.
I got a chuckle about your dad still running his C128 for financials. Their was a local optometrist here who ran his entire practice on Tandy Color Computers, networked together in a multi-tasking environment running OS9. Each and every part of it was custom written by the doctor. I think he retired a few years back, but I know it was still running his home brewed system then.
A local company I know of still runs under dos with a custom accounting software, still running on a memorex telex 286 pc, with a whopping 10mb hard-drive connected to a parallel port dot matrix printer, green crt and a mouse that would make anybody with RSI cringe just by looking at it.
The same setup has been used since the first eighties.
Data entry is so quick you can barely see the forms before the secretary presses enter and stuff gets printed (the slowest process by a huge margin).
Would put to shame most software I've seen nowdays.
AFAIK the system only uses 6mb of the 10 available and includes all accounting history of the company.
I doubt it was networked, as there was never a network card/cart/dongle or anything like that available for the CoCo back in the day (I owned both a CoCo 2 and a CoCo 3 as a kid, and still have both in running condition) - not even from 3rd parties, as far as I can remember.
There also was a system for the Model 4 (IIRC) running Xenix (?) with a serial port expander option to allow multiple system communicate with this "server", but that doesn't sound like what was done (?).
Radio Shack/Tandy sold a serial port switcher system that allowed you to connect multiple machines together in some fashion. It was meant for an educational setting (a teachers computer connected to multiple student machines). I don't believe it was automated in any way - completely manual. That doesn't sound like it was something that would work for an office setting.
In theory, you could mount a multipak interface and drop three serial pak cartridges in it, and maybe tweak the internal electronics to put them at different addresses, leaving the fourth slot open for the floppy drive (or maybe a hard drive). There would also be the bit-banger serial port available - so that would allow you to hang four machines off of a central "server"...third parties also created expanded multipak interfaces that allowed for many more cartridges to be attached (I think up to 16 in some cases).
Another way (which if this guy was doing this, he may have done) would be to create a completely custom networking system; the simplest way would be to use the bit-banger port and maybe the cassette port together (you might even be able to do something with the joystick ports too!) - the cassette port, using the relay latching, could toggle between "listen" (RX) and "send" (TX) modes, and with some simple electronics, the voltage levels could be managed and "collisions" detected, so you could do a "round robin" or even a "random" communication protocol with collision detection. Or, some other kind of "one-wire" communication system could be done. I also suppose someone really ambitious could create a custom bit of electronics and multiplex several UARTs together, linked to a single cartridge and controlled by the CoCo.
This is kinda fascinating; I wonder if he ever published anything about it. If not, it seems like another small bit of CoCo history lost forever, which is a shame.
I wonder if that kind of thing was more prevalent in the days of simpler computers, or if people are still doing the same thing on Windows/Linux/Mac these days.
Go on ebay, and search around for 386 motherboards, 5.25 floppy drives, and the like - for old DOS systems. Prices fluctuate, but on the whole some of those boards go for an insane amount of money (for what they are).
A lot of this is "collectibility" bumping prices up; but a part of it is also the fact that there are more than a few companies in the world running CNC tooling that uses these machines as controllers. We're talking CNC machines that to replace entirely would cost hundreds of thousands of dollars (USD), if not more in some cases. So parts to repair and keep these machines running are in hot demand.
There are, though, a few companies out there taking a different approach: Since most of these systems are DOS based, they work to reverse engineer the controllers, and build custom Linux or other embedded systems, running DOSbox or some other emulator, to keep these machines alive. In some cases, a complete reverse-engineering is done (both hardware and software). There is a demand for it, and very few providers of this kind of service (some machines have little or no documentation on how they worked or were controlled, some have manuals in a foreign language, software is highly proprietary and dongle-ized, etc).
So for that case - for your question - yes, this is still done, and likely always will be. I'm sure there are other more "mundane" examples of people using old software on either new machines (say in a VM, or maybe if it runs, just on the new system) or using emulation. There are a few kinds of software where there is great trouble to be had trying to emulate it or such (either because of security dongles, or other custom hardware) - but if it can be done, it is likely to be done...
Hm I think you are answering a different question than what I was asking.
I was asking more that if any "smart non-programmers" like optometrists these days still write custom software to run their business? Or if in the era of Windows/Mac/Linux, it's too complicated to do so. The stack is too high, you have to remember version 0.8 of this or version 0.9 of that.
I assume he could do it with Tandy computers because things were simpler in those days.
To me, the appeal of programming was always to play god and make things exactly how you want them.
But more along the lines of what you're talking about, my former boss runs a retro-computing site/company, for example:
I like this. I've been writing code since the 80's and doing it professionally for decades.
I'll say this, Nothing is Easy Anymore.
By that, I mean writing code is easier than ever with the tools and capabilities available today. But you spend proportionately more time trying to fix those most obscure shit.
To quote Judas Priest:
You can hang a left, or hang a right.
The choice is yours to do as you might, but your just backseat driving if your hands ain't on the wheel.
"At some point, magazines started publishing listings with a checksum added to each line. They offered special tools that would compute the checksum of each line you typed, and checked it against the checksum you typed in at the end of the line."
you often did get it wrong. However it didn't matter as when there was a mismatch you checked both the checksum and the line for errors. Generally you found errors in both, fix both go to the next line.
Getting all the typos out took almost as long as typing it in in the first place. I don't think I ever successfully typed in a program longer than 1 page, I recall being on page 3 of one program I never finished though.
It is so weird being on the spectrum and hearing stories like this. My dad and I often typed in multi-page programs without errors, or perhaps one error in the program.
I always thought it was OCD or something, where I would not enter a character unless I'd heard it unambiguously from the person reading the program to me.
Having it read to you would make it a lot easier to get it right, I would think.
My problem was always going back and forth between screen and magazine, and maybe skipping a line or a hex word or whatever. It took me longer than I'd like to admit to even figure out that moving a ruler down the page to help me find my place each time I looked back would reduce errors tremendously. If someone were reading it while another person types, it'd be much easier to not lose your place on the page.
I was mostly working alone. Most of my mistakes where omission. In the line
2560 data 0,0,0,0,0,0,0,0,0,0,0,0,45,0,0,0,0,0,0,0,128,42,128,128,9,0,0,0...
Missing one 0 is fatal, but the streak is long enough that it is easy to miss one and not notice.
Not getting the checksum wrong, getting the checksum tool wrong. While typing the source of the checksum tool, you don't have the checksum tool yet. Classic bootstrap problem :)
The checksum tool was short and came with its own checksum. Most of the ways you can type in a program wrong will cause the program will fail to run in some obvious way. Thus your first task was running the checksum tool against itself. The odds that you can make a typo that will cause the checksum tool to be broke and yet generate the correct output when run on itself were pretty low.
This post made me wonder if this could be the origin of the checksum or certain checksum algorithms. A few minutes googling haven't led to any dates, so does anyone know what the history of the checksum is?
I can't say what the history specifically of checksums are off the top of my head, but error correction/detection dates back to at least the 1940s. Hamming(7,4) was created in 1950.
This was reality in my childhood. If you didn't have the money for commercial software, you typed in code from magazines. Most magazines also offered the listings on cassette tapes or floppy disks, but it wasn't cheap (for the period).
The worst to type in (and the checksum programs were best for this - though strangely, as a kid I never understood their purpose, and never used them!) were machine code loader programs. These were typically graphics utilities, sound generation utilities, or games. Essentially they consisted of a simple "loading loop" (either a FOR-NEXT or a GOTO style loop) in which data values were read and POKE'd into memory. For instance, such a loop would look like this:
10 I=&H0000:READ X:IF X=-1 THEN STOP:POKE I,X:I=I+1:GOTO 10
Now - I took out some of the spacing to make it somewhat readable, in real life, that would have been mashed even more, because you needed as much space as possible. The variable "I" would be the starting memory address of where the ML code would be POKE'd into memory, each value would be read into "X", POKE'd into memory, and "I" would be incremented and it would continue, until "X" was read as a -1 to stop the process.
Following this loader would be a super-long series of DATA statements:
...insert several hundred more DATA statements here...
9999 DATA 40, 71, ..., etc, -1
These were typically decimal values, as using hex values would consume more memory for the additional "&H" prefix (though there were loaders that would use strings to prefix the value, then convert back, etc before POKE-ing the value - the loaders could and did get very sophisticated). Also, again I spaced the values in the DATA statements out for readability - in real life they'd have been mashed together for memory space reasons.
So imagine typing page after page after page of these DATA statements in, numbers, commas, checking each line as you went to make sure you typed it in correctly. Then, you get to the end, and what do you do?
Well - those who were waaay too impatient would just type RUN:EXEC and hope - which was stupid, as these ML programs would typically either relocate themselves to where BASIC resided, or do other nastiness, and you'd never be able to save the code.
So - the smart thing was to save the listing to floppy or tape - then run it. You'd run it, then when it was done POKE-ing the values into memory, you'd execute it (different machines had different methods of doing this - on the Color Computer, which I am most familiar with as it was the machine I had as a kid, you'd RUN the code, then type EXEC - sometimes followed by an address value, depending on where the code starting memory pointer was set).
And it would crash the machine, or fail in some other way. Maybe you fat-fingered a double comma, or added an extra zero in the values (several no-op (NOP) codes in row, usually represented by 0 values - were not uncommon). Or maybe you typed a 4 when it should have been a 5 - or any number of equally bad options.
So it crashes - now what do you do? Welp, break out that magazine, and start scanning each line in your listing, and compare it with the lines in the magazine, and pray you find the problem. You could easily be there for hours. This kind of thing could stretch into days of work, if the program was especially sophisticated. But what you could get in the end...
...amazing games!
...new BASIC commands!
...new graphic routines!
...better sounds!
...all of these and more at the same time!
There really isn't anything comparable to it today; on one hand, that's a good thing. On the other, though, it isn't - these offerings tested your skills, patience, and anger-management. Those who were masters of such gained valuable lessons...
That's why the most important part of computer magazines was the "Errata" section - and they could stretch across many months: "Reader Joe says last month's errata was incorrect and line 1080 should be...". As a kid I started to suspect some were doing it on purpose to make me buy the next magazine!
I loved doing type-in listings though. A while back I started making a game "BASIC Instincts" that was going to be about finding clues and typing in BASIC. I had a prototype working (https://www.youtube.com/watch?v=GwBiJR_rj_w) but then "Else heart.break()" was released and took the wind out of my sails. Might have to go back to it though!
Awesome stuff! I'm really curious what kind of program your father uses on the C128 (emulator) for finances; can't really imagine how that would be practical today. Love to be surprised, though!
I had to learn programming because I was given a VIC20 when the C64 was the model du jour. And because I couldn't get any games for it, all I could do is learn to make my own. 30 odd years later... Things might have been different had i gotten the "right" model.
I started programming because my ZX Spectrum had a dead tape-deck on arrival. Back in the 80s shops closed over Christmas, so there was no chance of returning/replacing it.
I ended up reading the manual(s), this being back in the day when computer manuals had tutorials on BASIC, and even pictures of the circuit-layouts.
The bad part (and one could argue this being a "good" part as well) for the VIC-20 and C64 was that if you wanted to do anything useful and reasonable in BASIC on those machines, you almost HAD to delve into some deep areas; the BASIC they used wasn't even as sophisticated as what was available on the Apple IIe (which was pretty nice). The best versions of BASIC (in microcomputer land - there were BASICs out there for business purposes on much more sophisticated 16-bit machines of the time that were amazing) were on Radio Shack's offerings (mainly because they were from Microsoft). Compare, for instance, BASIC for the C64 and the Color Computer 2, and you'll see a great difference (especially in the areas of sound and graphics generation).
That said, the C64 forced you to use either arcane commands to access internal ROM routines for certain graphics or sound generation, or you had to resort to machine code of some form or another. So you if you wanted to do something beyond the "basics" (so to speak), you had to get down and dirty with the hardware. This led to some amazing things being done by people with that machine; it was much more popular than Radio Shack/Tandy's offerings - it was much cheaper, plus it had built-in sound (SID) - whereas it's Radio Shack competitor, the Color Computer line - everything was done by the CPU.
These tradeoffs had their own implications, of course - there wasn't much like OS-9 available for the C64 (a multitasking, multiuser operating system for 8-bit machines of the time - which was ported very successfully to the Color Computer, and still lives on in the open-source version called NitrOS9). But the 6809 chip (which facilitate the OS-9 conversion, as that chip was also used in a lot of embedded and industrial controllers, which was the primary purpose for OS-9) was an expensive chip that, while really powerful compared to what was in the C64, ate into the bottom line, and was part of the reason why a sound chip wasn't included on the CoCo.
Radio Shack/Tandy later came out with expansion offerings for sound (the Speech/Sound and Orchestra-90 cartridges), which could be plugged into a multipak interface (MPI) along with the floppy drive controller, and give great sound - but it was too little, too late, and both were expensive upgrades (if you had a floppy drive, in order to keep everything you had to spend several hundred dollars more just for better sound).
There were ways to get better sounds out of the Color Computer, but they consumed a lot of the CPU resources, and so they were mainly only used for music generation software (Musica and Lyra were two of the popular ones; the Rainbow also published a long program to type in that gave a really sophisticated "tracker" style four-voice system, where each voice could be defined with an envelope and waveform). Some ML coders learned to combine some sound generation realtime with graphics for some games, but it wasn't great, though toward the end of the heyday of the CoCo it got better. Recently, people have made greater strides with sound and music for games, graphics, etc - heck, I think there is even a SID emulator for the Color Computer...
> That said, the C64 forced you to use either arcane commands to access internal ROM routines for certain graphics or sound generation
C64 ROM contains no graphics or sound generation commands. Unless you count text mode scrolling as such.
Graphics and sound was either POKEs and PEEKs or 6510 machine language.
> These tradeoffs had their own implications, of course - there wasn't much like OS-9 available for the C64 (a multitasking, multiuser operating system for 8-bit machines of the time
I presume many here will have seen this before, but a while back somebody deconstructed/explained all of the problems with ET and then went on to correct them (by hex editing the rom):
It was a very frustrating game. A friend of mine got it for Christmas the year it came out. We tried really hard for a lot of hours but we were completely overwhelmed by it. I don't know if it was the bugs that made it impossible to win (or even progress very far) or just the difficulty of the game, but we moved onto playing other stuff after a while, even though we both loved ET more than anything.
I agree, but my older brother figured it out. It was confusing because most games were single screen with obvious objectives. ET had a larger map with randomized items. You had to collect various objects to get home and bring them back to a central base. Unfortunately, there were a lot of similar looking maps and bad collision boxes, so you were constantly falling down empty holes and having to lift yourself out.
Bugs aside, it was beatable, and you had to read the instructions a few times to figure out what the hell was going on, and you would just ... lose sometimes.
Deadly Towers on the NES gets a lot of hate for almost the exact same reasons: random dungeons, unclear gameplay, and sometimes vindictive enemies.
The funny thing is, the current roguelike indie boom is built entirely around those concepts, and the Dark Souls series is hailed for being a throwback to the original zelda, where you just had to figure the game out.
ET wasn't a great game, but it was an ambitious game when home consoles were a new thing and everyone just wanted asteroids and pac-man.
The environment is very different though - we have the internet, and can watch the entire game played through by experts if we want. Back then if the average player got stuck by not being able to figure something out, and didn't want to call the expensive helpline, their enjoyment was over.
And this easy access to info can be a double edged sword.
For example, adventure games are basically dead because of how easy it is to find a step by step guide on Gamefaqs or similar.
Similarly, MMORPGs used to foster an in-game (in-world?) community because so much had to be discovered and shared via it. These days it is one part follow the quest marker, and one part check the wiki.
MMORPGs had knowledge base websites dedicated to them almost the instant they came out. The reason they don't foster community anymore is more by design than anything else. That said, old MMORPGs fostered community via some pretty unfun methods. I'm not sure if there's a good middle ground.
0xA000 is also the address of the memory location that holds the contents of the display in so-called "mode 13h" in the old IBM VGA displays.
Mode 13h was an extremely popular graphics mode, used by many PC games in the early 90s (probably also late 80s). It gave a resolution of 320x200 pixels with 8-bit colour palette.
After entering mode 13h, the way to plot a pixel is to poke the corresponding 8-bit memory address, where the 0th pixel (display top left) is 0xA000.
I think that's A000:0000 or, without the segments, 0xA0000 (one extra zero).
0xA000 would mean video memory started not after 640kB, but after 40kB. That wasn't even enough for everybody when the IBM PC launched (the Apple II already had been shipping with 48kB for a few years at that time)
Interesting read, but frustrating at times. It felt inconsistent in its level of explanation - not sure why I need it spelled out to me that 40 x 25 is 1000, but the reader is presumed to know C64 assembly.
BNE without a CMP threw me for a loop (ba dum tsss). I hadn't remembered that BE/BNE typically operates based on the condition of the zero flag.
Even so, it seems odd to gloss over the assembly while explaining more trivial things. If the author reads HN, that would be a suggestion to make his otherwise excellent post a little easier to follow.
No. 1988 was when he first tried to enter and run the game. Many years later, after coming across a scan of the magazine with the code listing, he tried to fix it.
