SpecNext

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.

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).

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.

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 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.

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 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.

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.

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.