Those of us old enough may remember the heyday of the text adventure game genre from the first time around. London-based Magnetic Scrolls was an early pioneering company producing titles for the first Amiga and Atari ST platforms. Fast-forward to 2017 and [Hugh Steers], the original co-founder and core developer for Magnetic Scrolls has formed an initiative to revive and re-release the original games on modern platforms. Since the 1980s-era DEC MicroVAX used originally for development is not particularly rare in retro computing circles, and media containing source code was found in someone’s loft space, reviving the games was not a tall order.
Not much happens until you try to read the tape, then you trip over the so-called sticky-shed syndrome. Secondly you may find that a small amount of the oxide layer sheds from the tape, coating the read head, rollers and guides inside the complicated tape mechanism. This quickly results in it gumming up, and jamming, potentially chewing up the tape and destroying it permanently.
This was further exacerbated by the behaviour of the DEC TK50Z tape drive, which needed to shuttle the whole length of the tape as part of its normal operation.
A temporary solution was to bake the tape in an oven to drive out the moisture and reduce the stickiness enough to run it through the drive safely. Then only the oxide-shedding problem remained. The TK50Z drive was swapped for a TZ30 which shuttles the tape less, but also critically with a simple hack, would allow the heads to be cleaned with IPA between read passes. This was enough to keep the gumming up at bay and allow enough data to be read from the tapes to recover several games worth of code, ready for the re-releasing process.
The video after the break shows [Rob Jarratt] working through the process of the data recovery.
Ten lines of BASIC is a big limitation, even when getting clever by stacking multiple statements into a single line, so [Martin]’s game has a much narrower scope than the original Atari 2600 version. Still, the core elements are present: E.T. must find and gather all the parts of the phone in order to contact his ship, after which he must meet the ship in time to escape. All the while, FBI agents attempt to interfere. The game was written in SAM BASIC, used by the SAM Coupé, a British Z80-based home computer from the late 80s with an emulator available for download.
Now, for lovers of “um, actually” topics, do we have a treat for you! Let’s take this opportunity to review a few things about E.T. The Extra-Terrestrial. That it was a commercial flop is no doubt, but the game itself is often badly misunderstood. Way back in 2013 we covered an extraordinary effort to patch improvements into the binary for the 2600 game, and in the process there’s a compelling case made that the game was in many ways far ahead of its time, and actually quite significant in terms of game design. You can jump right in on an analysis of the hate the game receives, and while reading that it’s helpful to keep in mind that In 1982, many of its peers were games like Space Invaders, with self-evident gameplay that simply looped endlessly.
If you are a certain age, your first programming language was almost certainly BASIC. You probably at least saw the famous book by Ahl, titled BASIC Computer Games or 101 BASIC Computer Games. The book, published in 1973 by [David Ahl] was a staple in its day and the first computer book to sell over one million copies. Of course, if you want to run Super Star Trek or Hamurabi, you better fire up an old retrocomputer or a simulator because BASIC in 1973 doesn’t look like what we have today. Or, you can head to GitHub where [coding-horror] is inviting people to help update the programs using modern languages.
This article was meant to be finished up before Christmas, so it’ll be a little late whenever you’re reading it to go and prepare this for the holiday. Regardless, if, like me, should you ever be on the lookout for something to give a toddler nephew or relative, it could be worth it to look into your neglected old parts shelves. In my case, what caught my eye was a 9-year-old AMD laptop catching dust that could be better repurposed in the tiny hands of a kid eager to play video games.
The main issues here are finding a decent selection of appropriate games and streamling the whole experience so that it’s easy to use for a not-yet-hacker, all the while keeping the system secure and child-friendly. And doing it all on a budget.
This is a tall order, and requirements will be as individual as children are, of course, but I hope that my experience and considerations will help guide you if you’re in a similar boat.
Python is an absolutely fantastic language for tossing bits of data around and gluing different software components together. But eventually you may find yourself looking to make a program with an output a bit more advanced than the print() statement. Once you’ve crossed into the land of graphical Python programming, you’ll quickly find that the PyGame library is often recommended as a great way to start pushing pixels even if you’re not strictly making a game.
Today, the project is celebrating an incredible milestone: 20 years of helping Python developers turn their ideas into reality. Started by [Pete Shinners] in 2000 as a way to interface with Simple DirectMedia Layer (SDL), the project was quickly picked up by the community and morphed into a portable 2D/3D graphics library that lets developers deploy their code on everything from Android phones to desktop computers.
Things haven’t always gone smoothly for the open source library, and for awhile development had stalled out. But the current team has been making great progress, and decided today’s anniversary was the perfect time to officially roll out PyGame 2.0. With more than 3,300 changes committed since the team started working on their 2.0 branch in July of 2018, it’s a bit tough to summarize what’s new. Suffice to say, the library is more capable than ever and is ready to tackle everything from simple 2D art up to 4K GPU-accelerated applications.
If you haven’t given PyGame a try in awhile, don’t worry. The team has put special effort into making the library as backwards compatible as possible, so if you’ve got an old project kicking around that you haven’t touched in a decade, it should still run against the latest and greatest version. If you’ve never used it before, the team says they’ll soon be releasing new tutorials that show you how to get the most out of this new release.
Making certain games run on systems which were never designed to run such games (or any games at all) is a favorite hobby of some, with [deater] being no exception. His latest creation involves porting Myst to the Apple II, or ‘demake’ in his own words. This means taking a game that was released in 1993 for MacOS and later for Windows 3.1 and the original PlayStation, and creating a version that works on an 8-bit system from 1977.
Obviously the graphical fidelity has been turned down some compared to the 1990s version, but at this stage much of the game’s levels have been implemented. For anyone who has ever played the game before, much of the visuals will be instantly recognizable. According to [deater], the game should run on any Apple II/II+/IIe, with at least 48 kB of RAM, but 64 kB needed for sound effects. If a Mockingboard sound card is installed, it will even play the intro theme.
On the project page the (currently) three floppy disks can be downloaded, with the source available on Github. While one is there, one can also check out [deater]’s ‘Another World’ port to the Apple II which we covered last year.
Most of us are aware that printf() is one of those functions that is considerably more complex under the hood, and capable of far more, than it may appear to be. But did you know that it is capable of Turing-complete computation?
[Nicholas] clearly steps through the theory, so give it a read. In short, a maze of arguments handles the logic of the game while an embedded scanf() reads user input, and printing the game board is always preceded by an escape code to clear the screen.