Or more officially, the ZX Spectrum Next.


Specnext is an imagining of what the ZX Spectrum might have turned into, should Sinclair have continued with it. It's a chimera of a machine, taking parts of various post- and concurrent-Sinclair clones and popular peripherals, and adds further things like hardware sprites and tilemaps.

Unlike many other more recent Spectrum clones, which have been thrown together just to play some of the old games, the Specnext is a labour of love for many people and it shows. As I'm writing this, kickstarter 2 is being shipped, and several thousands of people will get their hands on their very own Specnext for the first time. I hope they enjoy theirs as much as I've enjoyed mine.

I like it very much. If you want to stay in 48k spectrum limits, feel free. Need more speed? Up the CPU clock (up to 28MHz, 8x the original). Need more memory? Up to around 2 megs available. Better graphics modes? And so on. Nobody is forcing you to use all the hardware features, but they're there if you want them. Some people complain that the hardware is too capable, but that's really not the case.

Oh, and no more loading off tapes. You can access SD card storage, which is frankly the most liberating thing for software development compared to the 48k speccy.

Specnext can run tape images, but additionally there's .nex files that take over the whole machine, as well as something called "dot commands". Dot commands can be run from basic programs and are the easiest to develop, so that's basically all I've done so far.

My problem getting into Specnext was that all the tools I made for 48k speccy were tailored for the 48k device, which meant I pretty much had to start over, and I still, years later, haven't built tools to the level I had for the 48k, where I could pump out (80's) commercial quality games very quickly.

A lot of my projects have been a lot of research with no final result as of yet. But I've made a few bits that are useful.

You can find all of my SpecNext code on github under very liberal license.

First step was to get some kind of development cycle going. Initially I would compile things on PC, copy them onto an SD card, unmount the SD card, physically move the SD card to the Next, reboot, run the binary, crash, move the SD card physically to the PC, repeat.

The Next has a Wifi module, but nobody had done much with it. Okay, that's unfair, the Next shipped with some programs that used the module, but nobody had made a convenient file transfer program, so I wrote one, designed primarily to make development easier.

NextSync (permalink)

NextSync 1.2

dot program

With NextSync the development loop changed to: build on PC, run .sync on the next, run the binary, crash, repeat. Much easier.

NextSync has two parts: the .sync dot program and a Python script server that you run on your PC (or mac, or pi, or abacus, or whatever).

Wherever you run the server script becomes the root of your Next's SD card, so if you want to put a file into /dot/dt, you might run the server on c:\nextdev\sync\ and your binary would be c:\nextdev\sync\dot\dt. Then just run .sync on the Next and, if the planets are properly aligned, the file just appears on your Next.

dt (permalink)

Delta-time 0.1

dot program

Benchmarking things that take less than a frame is pretty easy on a Spectrum, just change the border color and see how much of the frame your code takes. But when you have something that takes several seconds, like benchmarking data transfer between the Next's Raspberry Pi and Next, you need something else.

The Next has an RTC, or real time clock, module, which can give time in one second granularity. The .dt dot command can be used to query time difference between two calls. So you might do something like:

10 .dt a
20 .payload
30 .dt a

Which will take the timestamp from integer variable a, calculate difference with current time and print it, replacing the timestamp in the integer variable a. So the above bit of basic will first print a nonsense value, then run the payload (whatever it is), followed by how long the payload took (+/- 1 second).

sdbench (permalink)

SD Benchmark

Dot program

I wrote a simple SD card benchmark, .sdbench. You can try it if you're curious, but unless you have some complete lemon of an SD card, the bottleneck will be somewhere else and the results will be the same as with everyone else.

playfli (permalink)

I've done several video playing experiments with the Next, none of which are ready for prime time, but maybe one will be, eventually. First one is a pretty straightforward FLI player, which doesn't perform too well and is pretty buggy.

playflx (permalink)

PlayFLX 0.6

dot program

While doing the FLI player I figured I could extend the format a bit to be more efficient and more Next friendly. I ended up redesigning the whole format. Good side of being able to develop on a supercomputer (i.e, anything you can buy off the shelf these days) is that you can spend a lot more time while compressing, so FLX compresses way better than FLI does, while being as light (or lighter) to process.

FLX works fairly well, but the development stalled because I wanted to add audio to the format, and there were some issues with file i/o and using DMA transfers which have been fixed in more recent Next distributions. I should pick it up at some point.

Another problem that I faced was content generation; I needed to render flat polygons for FLX to compress well, but modern Blender seems to be utterly incapable of it.. meaning I'd need to write my own, OpenGL based renderer, and that rabbit hole hasn't lead anywhere as of yet.

There's some performance limits - if you compress well, the decoding may take too long. To help with this the FLX player decodes several frames in advance (as many as fits in memory), so if one frame takes too long that's fine. You can reduce the compression to improve the performance.

TileCine (permalink)

Another research project is to make lossy video using the tiles. This yields constant bitrate stream and some of the results are promising, but there's quite bit to do yet.

LFAC (permalink)

Low Fidelity Audio Codec

GitHub link

One offshoot from all this is the Low Fidelity Audio Codec, with which I can produce fairly good quality lossy 8 bit audio. I haven't made the SpecNext counterpart of it as of yet, but the long-term plan is to combine LFAC with FLX and/or TileCine for a complete video experience.

zakplay (permalink)

ZakPlay 0.2

dot program

A common way to store AY or FM music (for old Spectrums or Atari ST) is to record sound chip register dump per frame. There's a lot of these files out there, in various formats. I designed a new format, zak, as a better-compressed universal format, and a SpecNext player for it. I also converted very many files to the new format.

aymid (permalink)

MID player proof of concept

nex program hardcoded to play a single file

As a proof of concept, one evening project I wrote a .mid file player (through the AY chip) for the Next. It doesn't work with most mid files, as many would require some preprocessing; all midi files do not actually store all notes in order, so the time events would need to be reordered before playing and that might be a bit much to ask from a 8 bit computer. We'll see if this goes anywhere.

nextpimidi (permalink)

NextPi-USBMidi 22092023

Dot program and nextpi binary

The nextpimidi is another proof of concept project where a server is running on the Next's Raspberry PI and a dot command is running on the Next. One dot command can be used to receive midi data through usb midi on the Raspberry PI, playing the notes on the AY chips.

Another dot command can be used to send midi data through the usb midi.