“I want to make creating games for the Next as fun as it was creating games for the ST at the start of the 90s,” says Neil Halliday.
The NextSTOS developer is explaining his plans to SpriteFountain ahead of a public beta. His language takes inspiration from STOS on the Atari ST, with familiar commands, support for old asset banks and a development workflow built around Visual Studio Code.
“I’ve been coding since the late 80s, and when STOS arrived on the Atari ST, it was a game-changer for many people, not just myself. STOS brought simplicity to creating not just games, but multimedia presentations to the masses.”
On the Next, Neil sees hardware knowledge as a barrier to getting started.
“There are a lot of registers to think about in order to take advantage of its impressive arsenal of hardware. If you’re just starting out on your programming journey or struggle with technical jargon, it can be very daunting and will likely put some people off.”
“Hopefully everyone can have a dabble with NextSTOS,” he says.
What survives from Atari ST STOS?
NextSTOS changes where you write a program as well as how you structure it. Neil points to the differences between François Lionet’s STOS in 1988 and AMOS in 1990 as an earlier example of the language evolving.
“There is no loadable program on the Next to ‘run’ STOS,” he explains. He says “all coding is done through Microsoft Visual Studio Code, and the NextSTOS language and compiler/assembler is installed as an add-in”.
“The language itself has evolved. I’ve introduced some of the features I personally felt were missing from STOS, such as functions and case statements. However, any seasoned STOS coder could look at some NextSTOS code and recognise it instantly.”
“Where practical, I’ve used the same syntax as the original STOS, and the terminology is almost identical. For example, we have the ‘wait vbl’, ‘screen swap’, and ‘screen copy’ commands. You can even use existing STOS .mbk files for sprites and music, and NextSTOS will convert them during compilation/assembly. I’m hoping to have an import feature in the near future.”
The Missing Link and Misty will stay on the ST. Neil rules out support for those extensions because of their stored commands and hardware dependencies.
“Seasoned STOSSERS sometimes swapped extensions around, so it’s therefore not possible to guess the tokenisation,” he explains. There is also the issue of “ST-specific hardware that cannot or does not translate to the Next”.
The Next’s own memory system has proved the hardest part of development. Neil describes the challenge as “memory, memory, memory”. Its processor sees a 64KB address space at once, so reaching the wider memory requires changing which banks occupy it.
“This is one of the things that makes programming the Next tricky, and therefore one of the primary things I wanted NextSTOS to remove,” he says. His aim is to handle the banking so programmers do not need to organise those switches themselves.
Raspberry Pi music and plans for the beta
The accelerated Next’s internal Raspberry Pi already has music players, including one for SNDH.
“NextSTOS recognises this and uploads the SNDH file to the Raspberry Pi, which then takes over the replay by emulating the 68000 processor of the ST and outputting the music.”
“So far, I haven’t found a music file that doesn’t work. My current test set is around 790 different music files from various artists.”
The Pi approach followed earlier experiments with native Next code.
“Before using the Raspberry Pi accelerator, I did actually convert some SNDH files to native Z80N and had them play, but each file had to be converted individually, which created complexities in and around digi-drum and digital music.”
The public beta will put the new language in the hands of more testers.
“We will be testing this like heck in order to make sure everything works as it should,” he says. He describes NextSTOS as a completely new programming language, adding: “It is the job of the beta testers (whoever they may be) to test, test, test and report back with any non-working behaviour.”
The planned installer uses VSIX, the package format for a Visual Studio Code extension.
“NextSTOS will be simple and easy (I hope) to install and configure. The plan is to release a self-contained VSIX (VS Code extension) that just gets installed, and as part of that, there will be an option to configure everything else that is needed.”
Full documentation will cover configuration and setup. For testing code on a computer, Neil points to Mike Dailly’s CSpect emulator.
“In terms of the release, when we are ready, everything will be made available via the STOS Coders website,” he says.
Follow development through the STOS Coders website, the STOS Coders Facebook group and the ZX Spectrum Next Facebook group. CSpect is available from Mike Dailly’s itch.io page.
