Donated Atari Mega ST Gives A Peek At Game Development History

[Neil] from The Cave, a computer and console gaming museum in the UK, has a treat for vintage computing and computer gaming enthusiasts. They received an important piece of game dev history from [Richard Costello], who coded ports of Gauntlet 2, Mortal Kombat, and Primal Rage for Atari ST and Amiga home computers. [Richard] brought them his non-functional Atari Mega ST in the hopes that they could get it working again, and demonstrate to visitors how game development was done back in the 80s — but sadly the hardware is not in the best shape.

The Atari ST flagged deleted files for overwriting but didn’t actively wipe them, allowing an undelete utility to work.

That doesn’t stop [Neil], however. The real goal is seeing if it’s possible to re-create the development environment and access the game assets on the SCSI hard drive, and it’s not necessary to revive every part of the hardware to do that. The solution is to back up the drive using a BlueSCSI board which can act as a host, scan the SCSI bus, and dump any device it finds to an SD card. The drive didn’t spin up originally, but some light percussive maintenance solved that.

With the files pulled off the drive, it was time to boot it up using an emulator (which begins at the 16:12 mark). There are multiple partitions, but not a lot of files. There was one more trick up [Neil]’s sleeve. Suspecting that deleting everything was the last thing [Richard] did before turning the machine off decades ago, he fired up a file recovery utility. The Atari ST “deleted” files by marking them to be overwritten by replacing the first letter of the filename with a ‘bomb’ character but otherwise leaving contents intact. Lo and behold, directories and files were available to be undeleted!

[Neil] found some fascinating stuff such as mixed game and concept assets as well as what appears to be a copy of Ramrod, a never-released game. It’s an ongoing process, but with any luck, the tools and environment a game developer used in the 80s will be made available for visitors to experience.

Of course, modern retro gaming enthusiasts don’t need to create games the classic way; tools like GB Studio make development much easier. And speaking of hidden cleverness in old games, did you know the original DOOM actually had multi-monitor support hidden under the hood?

Continue reading “Donated Atari Mega ST Gives A Peek At Game Development History”

Assessing Developer Productivity When Using AI Coding Assistants

We have all seen the advertisements and glossy flyers for coding assistants like GitHub Copilot, which promised to use ‘AI’ to make you write code and complete programming tasks faster than ever, yet how much of that has worked out since Copilot’s introduction in 2021? According to a recent report by code analysis firm Uplevel there are no significant benefits, while GitHub Copilot also introduced 41% more bugs. Commentary from development teams suggests that while the coding assistant makes for faster writing of code, debugging or maintaining the code is often not realistic.

None of this should be a surprise, of course, as this mirrors what we already found when covering this topic back in 2021. With GitHub Copilot and kin being effectively Large Language Models (LLMs) that are trained on codebases, they are best considered to be massive autocomplete systems targeting code. Much like with autocomplete on e.g. a smartphone, the experience is often jarring and full of errors. Perhaps the most fair assessment of GitHub Copilot is that it can be helpful when writing repetitive, braindead code that requires very little understanding of the code to get right, while it’s bound to helpfully carry in a bundle of sticks and a dead rodent like an overly enthusiastic dog when all you wanted was for it to grab that spanner.

Until Copilot and kin develop actual intelligence, it would seem that software developer jobs are still perfectly safe from being taken over by our robotic overlords.

New Release Of Vision Basic: Hot New Features!

As the Commodore 64 ages, it seems to be taking on a second life. Case in point: Vision BASIC is a customized, special version of the BASIC programming language with a ton of features to enable Commodore 64 programs to be written more easily and with all sorts of optimizations. We’ve tested out both the original 1.0 version of Vision BASIC, and now with version 1.1 being released there are a whole host of tweaks and updates to make the experience even better!

One of the only limitation of Vision BASIC is the requirement for expanded RAM. It will not run on an unexpanded C64 — but the compiled programs will, so you can easily distribute software made using Vision on any C64. A feature introduced in version 1.1 is support for GeoRAM, a different RAM expansion cartridge, and modern versions of GeoRAM like the NeoRAM which has battery-backed RAM. This allows almost instantaneous booting into the Vision BASIC development environment.

Some of the standout features include a doubling of compilation speed, which is huge for large programs that take up many REU segments in source form. There are new commands, including ALLMOBS for setting up all sprites with a single command; POLL to set up which joystick port is in use; CATCH to wait for a particular scanline; and plenty more! Many existing commands have been improved as well. As in the original version of Vision BASIC, you can freely mix 6510 assembly and BASIC wherever you want. You can use the built-in commands for bitmaps, including panning, collision detection, etc., or you can handle it in assembly if you want! And of course, it comes with a full manual — yes, a real, printed book!

One of the nice features of Vision BASIC is the customization of the development environment. On the first run, after agreeing to the software terms, you enter your name and it gets saved to the Vision BASIC disk. Then, every time you start the software up, it greets you by name! You can also set up a custom colour scheme, which also gets saved. It’s a very pleasant environment to work in. Depending on how much additional RAM you have, you can hold multiple program segments in different RAM banks. For example, you could have all your source code in one bank, all your bitmaps and sprites in another, and your SID tunes in yet another. The compiler handles all this for you when you go to compile the program to disk, so it’s easy to keep large programs organized and easy to follow.

If you’ve always wanted to write a game or application for the C64 but just didn’t know how to get started, or you felt daunted at having to learn assembly to do sprites and music, Vision BASIC is a great option. You will be blown away at the number of commands available, and as you become more experienced you can start to sprinkle in assembly to optimize certain parts of your code if desired.

Programming Ada: Implementing The Lock-Free Ring Buffer

In the previous article we looked at designing a lock-free ring buffer (LFRB) in Ada, contrasting and comparing it with the C++-based version which it is based on, and highlighting the Ada way of doing things. In this article we’ll cover implementing the LFRB, including the data request task that the LFRB will be using to fill the buffer with. Accompanying the LFRB is a test driver, which will allow us to not only demonstrate the usage of the LFRB, but also to verify the correctness of the code.

This test driver is uncomplicated: in the main task it sets up the LFRB with a 20 byte buffer, after which it begins to read 8 byte sections. This will trigger the LFRB to begin requesting data from the data request task, with this data request task setting an end-of-file (EoF) state after writing 100 bytes. The main task will keep reading 8-byte chunks until the LFRB is empty. It will also compare the read byte values with the expected value, being the value range of 0 to 99.

Continue reading “Programming Ada: Implementing The Lock-Free Ring Buffer”

Programming Ada: Designing A Lock-Free Ring Buffer

Ring buffers are incredibly useful data structures that allow for data to be written and read continuously without having to worry about where the data is being written to or read from. Although they present a continuous (ring) buffer via their API, internally a definitely finite buffer is being maintained. This makes it crucial that at no point in time the reading and writing events can interfere with each other, something which can be guaranteed in a number of ways. Obviously the easiest solution here is to use a mutual exclusion mechanism like a mutex, but this comes with a severe performance penalty.

A lock-free ring buffer (LFRB) accomplishes the same result without something like a mutex (lock), instead using a hardware feature like atomics. In this article we will be looking at how to design an LFRB in Ada, while comparing and contrasting it with the C++-based LFRB that it was ported from. Although similar in some respects, the Ada version involves Ada-specific features such as access types and the rendezvous mechanism with task types (‘threads’).

Continue reading “Programming Ada: Designing A Lock-Free Ring Buffer”

Shipping Your Illicit Software On Launch Hardware

In the course of a career, you may run up against projects that get cancelled, especially those that are interesting, but deemed unprofitable in the eyes of the corporate overlords. Most people would move, but [Ron Avitzur] just couldn’t let it go.

In 1993, in the midst of the transition to PowerPC, [Avitzur]’s employer let him go as the project they were contracted to perform for Apple was canceled. He had been working on a graphing calculator to show off the capabilities of the new system. Finding his badge still allowed him access to the building, he “just kept showing up.”

[Avitzur] continued working until Apple Facilities caught onto his use of an abandoned office with another former contractor, [Greg Robbins], and their badges were removed from the system. Not the type to give up, they tailgated other engineers into the building to a different empty office to continue their work. (If you’ve read Kevin Mitnick‘s Ghost in the Wires, you’ll remember this is one of the most effective ways to gain unauthorized access to a building.)

We’ll let [Avitzur] tell you the rest, but suffice it to say, this story has a number of twists and turns to it. We suspect it certainly isn’t the typical way a piece of software gets included on the device from the factory.

Looking for more computing history? How about a short documentary on the Aiken computers, or a Hack Chat on how to preserve that history?

[Thanks to Stephen for the tip via the Retrocomputing Forum!]

Programming Ada: Records And Containers For Organized Code

Writing code without having some way to easily organize sets of variables or data would be a real bother. Even if in the end you could totally do all of the shuffling of bits and allocating in memory by yourself, it’s much easier when the programming language abstracts all of that housekeeping away. In Ada you generally use a few standard types, ranging from records (equivalent to structs in C) to a series of containers like vectors and maps. As with any language, there are some subtle details about how all of these work, which is where the usage of these types in the Sarge project will act as an illustrative example.

In this project’s Ada code, a record is used for information about command line arguments (flag names, values, etc.) with these argument records stored in a vector. In addition, a map is created that links the names of these arguments, using a string as the key, to the index of the corresponding record in the vector. Finally, a second vector is used to store any text fragments that follow the list of arguments provided on the command line. This then provides a number of ways to access the record information, either sequentially in the arguments vector, or by argument (flag) name via the map.

Continue reading “Programming Ada: Records And Containers For Organized Code”