Tuning The Spectrum

Up until now, I used a Commodore 64 -themed memory stick as the drive for Retro Games' The Spectrum. Obviously it sticks out like a sore thumb drive.

It took a while before I bothered to look for a better alternative. Eventually I ordered an "Eletra Nano" USB memory, 32GB (USB 2.0). The memory size is acceptable, and with this I mean it's not too much! I wouldn't want an overkill of space, as the emulator files tend to be 48K or less and I don't even want all of them on the stick.

I don't mind the 2.0 protocol because the drive doesn't have to shift large files.

Smaller, virtually invisible memory sticks exist, but this is still easy to pull out with fingers. The colour, shape and styling are quite compatible with the Sinclair.

Importantly, it works. Format with FAT32 and move all the files from the other stick to this drive. Then insert it in The Spectrum and go.

Previously, I've discussed the modification of a vintage Kempston/Sound interface to give a more full 1980s experience to The Spectrum. The sound interface side is still under consideration.

If I really wanted I could have created space under the "Kempston" interface, camouflaging the memory stick entirely. But I'd rather avoid any accidental physical contact with the memory stick, even if crashes related to extension wobble might be period authentic.

Kempston-USB adapter for The Spectrum

What's wrong, or right, in this picture?

After using it for a while, Retro Games' The Spectrum is a rather nice Speccy-tribute. But it's not an authentic hardware replica, and old 9-pin joysticks and peripherals won't work with it.

But what if... I was to purchase a vintage joystick adapter and disguise it as a Speccy peripheral? Delightfully devilish!

I already have an Arduino-based adapter for attaching classic 9-pin joysticks to USB, and it works with The Spectrum. An Arduino Micro or Leonardo can pretend to be a HID device, essentially becoming a gamepad without buttons. On Retro Games' The C64, I had problems possibly because it's a type of controller not "whitelisted" in the firmware.

The USB ports at the back of The Spectrum are where the edge connector is supposed to be. This got me thinking I could build an adapter to look more in line with The Spectrum's appearance.

I happened to have some Speccy joystick adapters, and one Timex Joystick-Sound Unit has had its guts removed already before. Not sure why, but at least I don't have to feel too bad about breaking one now.

Apologies to all Portuguese Spectrum fans to whom the sound unit is a matter of national pride. (Timex manufactured these units in Portugal, among other things).

All the parts

I started by fitting the Arduino Micro inside, using 3x1 protoboard as a replacement for the original circuit board.

There's more room inside than in my compact adapter, but because of how the board fits inside, it's not all in use. Also, I wanted the Arduino to sit on a socket, which eats up quite a lot of space.

But it all fits inside, I then soldered ready-tinned wires to connect everything. Maybe the Arduino would have fit better horizontally, but what's done is done.

The new problem was finding a short USB-cable or some kind of adapter, that would work as a connector and keep in place.

I did look for L-shaped adapters and cables, but there didn't seem to be a ready-made configuration for a USB-A in L-shape that would configure into a micro-USB.

So I just bluntly took the least useful Micro-USB cable I could find, cut it and soldered it into a really short USB-A-to-Micro cable. I found the space was not quite enough for the Micro end, so I whittled the rubber out to bare minimum to make it fit.

The Micro-end has been whittled bare.

I wanted to make the adapter so it could be meaningfully pulled apart, if I need the Arduino again in some distant future.

At this point I could test it already works and fits into its place. I uploaded the same Arduino sketch as with my earlier adapter, and soldered the cables same way. That's it.

The remaining problem was how to make the USB-A end stick to the box firmly enough and still be able to dismantle the whole thing. Of course I could just glue gun it all to oblivion, but it might be tricky to get apart.

The USB sticks into place

I fit a piece of MDF snugly and put two screws through. This looks like enough to keep the USB connector in place and it won't fall apart when I gently remove the adapter from The Spectrum.

Another dummy connector, or something in similar shape, could be added just to keep the unit more firmly in position. I'll do it if I'm in the mood for fine-tuning this box.

I already know the Arduino joystick adapter feels lagless enough, and in practice this unit doesn't add that much to the Speccy experience. The old adapter I built is more practical. But this was a fun project idea and at least The Spectrum has its own adapter.

One future idea is to implement the "sound unit" function promised on the tin. This is not too far-fetched, as I could pull the audio out of the HDMI->VGA adapter's audio splitter and add a tiny speaker with an amplifier circuit. This would add some value to the box, replicating all the glorious 5 octaves from a tinny speaker as it's supposed to be.

Retro Games Ltd: The Spectrum

I guess it was unavoidable. To add to the pile of Spectrums and emulators, I bought Retro Games' "The Spectrum". Is it any good?

Physical appearance and connectors

The case appears as good as can be realistically expected. Perhaps the graininess of the back part is grainier than in the original, and obviously it says RETRO and not Sinclair. 

I'm not going to open it just yet, I've seen pictures of the insides though. The weight is credible, there are metal weights inside. If you need to adjust the weight up- or downwards, it shouldn't be hard to do.

The rear panel has only modern connectors: there's a kind of emulator inside, I suppose a bare-bones Linux, which then provides HDTV-out and USB connectivity.

The connectors and buttons at the back

Retro Games have entered the USB-C age, which is good. I've powered The Spectrum happily with a 20000mAh power bank, using the 5V/3A output. A Raspberry Pi -type PSU should be optimal. I've not dared to use a laptop charger, though I'm not sure why it would be a problem.

The power cable is at the "wrong" side of the computer but it's sensible to have it near the HDMI, so as not to have wires dangling from both sides.

There's a power button so the cable doesn't need to be yanked away every time. There's one USB port near the HDMI and power cable, a good place for a semi-permanent memory stick holding your games and original system ROMs.

Then there are three additional USBs, perhaps for two controllers and one for ... keyboard, if you really want to.

And a home button at the right side, surely a familiar idea to users of Multiface cartridges of old. From here you can access the game selection carousel and other system menus.

The triad of USBs is nicely placed where the original Spectrum had the edge connector, contrast this with TheC64 which had nothing at the cartridge port location. I can imagine a 9-pin joystick adapter taking its rightful place here.

Keyboard

The most important thing for me is the keyboard. Because if it doesn't work, then I'm nearly better off using an emulator on the PC. So, does it pass the muster?

First I'll say it's better than the Elite Recreated keyboard from around 2015, which I tried hard to like in my review back then. For the record I have to admit it had the Sinclair logo, and the case was perhaps in some ways more accurate.

They might not be exactly identical to the original Spectrum keys

I couldn't shake the feeling The Spectrum keyboard is a little mushy too. But this was at least in part because I had no sound on while in BASIC. Perhaps an added psychological sense of "snappiness" comes from that sound.

Turning sound on did make it more comforting, although it would be nice if the sound came from the insides of the case itself. Maybe a DIY hack will surface.

Playing games, the key presses are usually silent so the above point shouldn't matter at all. How does the keyboard fare as an authentic Spectrum controller?

The built-in games are chosen from a "carousel"

I'll say I was fine with it. Using the holy QAOP combination for games worked well, I didn't experience missed key presses or physical obstructions. Epic games like Lords of Midnight and Elite are more enjoyable this way than with a PC keyboard. I can even use the original keyboard overlays.

Perhaps surprisingly, I couldn't get into adventure games with this keyboard. I tried a few, but soon turned away in frustration. It's not the keyboard as such but the wonky and slow input that Speccy adventure games often had on offer, and I'm not a big fan of the genre anyway.

Typing BASIC works well, and this is one major difference to PC emulators. There you have to feel your way around a non-standard keyboard layout to produce the BASIC keywords. No such problems here, but admittedly it takes some guts to use that old rubber for programming.

Then some nitpicks.

It's interesting to note the printing on and around the keys are positioned just a little bit off. Perhaps it could be even an IP matter, made just different enough so it's not a full facsimile of someone else's work?

But that's not all...

Retro Games The Spectrum: ~9.6mm

The keys are just a tiny bit smaller than in the original Spectrum. This was my first intuition, and when I took out the vernier caliper, I could see the original ZX Spectrum has almost exactly 10.0mm size keys, and The Spectrum has them in the 9.6-9.7mm territory.

I'm wondering if they shrunk unexpectedly in the manufacturing process.

To me this raises the question if the original rubber mat would fit the new machine. It did seem to me the holes in the metal plate are correctly sized.

Sinclair ZX Spectrum: 10.0mm

Joystick

As my Arduino joystick 9-pin adapter didn't work with TheC64, I was a little sceptical (spectical?) if it would work on The Spectrum. But then news started coming in nearly all USB game controllers work, and I was ready to be optimistic.

I must say it passed with flying colors. I can attach a TAC-2 controller and play games without having to resort to a modern gamepad.

This one here.

Two controllers can be set, and there are ample options for configuring them.

I didn't even try the Retro Games Competition Pro-style USB joystick that came with TheC64, I assume it works and is just as bad as before.

I have no intention to test lag scientifically. My gut feel is that there is likely not much lag, but if you really go looking for it you might find it.

Spectrum games rarely have a very fast screen update anyway, so any lag would probably be lost within the general chunkiness. Using my Joystick adapter and 50hz HDMI display, I didn't feel anything was off in the fast paced Atic Atac.

Video

50hz and 60hz screen refresh rates are provided, and you have to make that choice when you first boot the computer.

I think it's crucial The Spectrum is connected to a 50hz-capable display, for authentic speed. Fortunately I have such a display, so no problem there. Normal TV-type displays can likely do this better than some computer monitors.

The screen is scaled in an integer-based way, so I didn't see any interference patterns or moire-type effects, not on a 2560 x 1440 resolution display or 1920 x 1200 display. Why I even bother to mention this is that I've found some non-commercial emulators difficult to set up in this respect.

The clear menus you'd expect from Retro Games

For authenticity, the amount of BORDER displayed can be adjusted, and this is also a game-specific setting.

For my tastes, the non-bright color levels and the BRIGHT levels are a little too close to each other. My experience is that the boot-up white screen is grayish, and the bright white really stands out.

The BASIC program below is a very rudimentary test that tells me The Spectrum generates a rock solid frame rate.

10 PAUSE 1
20 BORDER 0
30 PAUSE 1
40 BORDER 7
50 GO TO 10

Seeing "tear" or other hiccups would indicate a less than ideal experience. The border should flash consistently, as it does on The Spectrum.

A 50hz smooth frame rate in a Spectrum game is quite rare, so it's not surprising if games are not silky smooth. But it may be indicative of more subtle timing issues in the hardware? To be really sure, I would have to compare outputs to each other side by side.

After seeing a few demos that showcase horizontal scrolling, it was easier to see the frame rate is indeed smooth. It may be that a 50hz in a modern display is more mechanical than a CRT with some afterglow.

To get audio, I needed to use my HDMI-to-VGA with 3.5mm audio splitter, and it worked just as well here as with TheC64.

System

Games can be loaded using an USB stick. It should be FAT32 formatted, and you need to have games in folders that have a maximum of 256 files each.

I'd recommend NOT to have 1000s of games at hand, but to concentrate on a smaller number of games you know you can return to, and maybe a few unfamiliar ones you intend to have a crack at.

A suitably themed memory stick...

I don't have much to say about the 48 game collection that came with the computer, haven't yet tried them all really. To me it's a combination of hits and misses, some obvious inclusions (Manic Miner) and some obvious omissions (the Ultimate catalog).

From older games, I prefer simple and short ones such as Saboteur!, Bruce Lee, Splat, or Viking Raiders. But just sometimes, more epic is more fun, as with Lords of Midnight or Elite.

Compatibility issues may arise because the Retro Games ROM for Spectrum is not a Sinclair/Amstrad ROM. Fortunately this can be changed, if you think you have a permission to use the ROM. These need to be added to a specific folder path on the USB stick, THESPECTRUM/roms/ (See the large manual p. 48)

Using the default Retro Games Ltd system ROM, I could see that Manic Pietro, which uses a timing-based graphics engine to circumvent the normal attribute limits, showed some flickering. Switching over to Sinclair ROMs, this flickering ceased.

Here I have to say a speed boost would have been welcome for games such as Lords of Midnight, or Viking Raiders. But The Spectrum is set at the standard 3.5Mhz. There is a rewind option for cheating.

There are no timing adjustments, for example the "Pentagon" timings are not possible, and 128K appears to be the memory limit.

There are some reports of snapshots not working. I did find a snapshot of Bruce Lee, which works on Fuse emulator, but crashes reliably on The Spectrum. This with Sinclair ROM or not. These situations can be fixed by searching for an alternative snapshot or TAP file.

Final words

For someone who already knows their way around Spectrums, this may be just another collectible to fill the shelves. But I think it succeeds better in reaching its goal than TheC64 did, which wasn't bad either.

Some questions were left open, such as if it's possible to use an older Spectrum rubber mat, or modify an existing keyboard membrane to work on The Spectrum. Maybe I'll look into this eventually.

ZX Spectrum Next

Sinclair ZX Spectrum Next

The first ZX Spectrum Next Kickstarter was launched in 2017. Back then I felt the ZX Evolution was enough for me. When I learned of the second Kickstarter, promising improvements over the first one, I had to jump in.

The board is a continuation of the TBBlue, where an FPGA drives the entire thing. So it's not a software emulator but there's no factory-made bona fide Z80 chip inside. In fact they call it the Z80N because it has a few extra instructions. If the magical aura of a genuine 8-bit CPU is absolutely necessary, then steer elsewhere...  

But let's not forget the original Spectrum ULA video chip was a kind of proto-FPGA chip too. It's just nowadays more realistic to have everything in the "ULA".

256 colour graphics with support for scrolling and sprites, multi-channel sound, SD card storage media, 2MB memory. For programming this means a memory paging system, because the Z80 cannot address more then 64 kilobytes of memory directly.

The computer can also work as ZX80, ZX81, 48K, 128K, through either emulating or switching the ROM and capabilities.

Instead of listing everything the computer does (and it does a lot) I'll just relate my initial observations and things I have found interesting after week and a half.

First Impressions

The Next comes packaged with the appropriate PSU and a printed booklet in the tradition of the original Sinclair manuals. It's crammed with information and tables. In addition there's also a quick start sheet.

The great thing here is that I don't need to buy anything extra to get it up and running. Ok, a video cable is necessary but who doesn't have a HDMI or a VGA lying around?

The case is physically very impressive, a proper industrially molded case and keyboard. In size and appearance it is quite close to the Spectrum Plus, although not nearly as tall. Rick Dickinson, the original designer of many Sinclair products, was still involved with the design before his passing.

In the correct order

I'm not a big fan of rounded corners in tech, but I have to admit the rounding and the rainbow plastics gives the box a lot of character. It's also a tribute to the original rubber-keyed Spectrum.

The keyboard appearance and feel exceeded my expectations. It mostly follows the Spectrum Plus layout, the main difference being the cursor keys have been positioned more reasonably. 

The layout difference makes it hard to compare the Next with modern keyboards. It feels right but I tend to mistype because my fingers are one key off, typing LIAR instead of LIST and so on.

Occasionally I lapse into Speccy-thinking, using shift+P to create " and even searching the cursor keys from both sides of the space bar! My brain hasn't really decided yet what to do with the keyboard.

The lack of explicit CTRL and ALT keys also affects the way software deals with keyboard shortcuts.

Instead we have True Video and Inverse Video

Connectors

There's a bunch of modern and less modern connectors at the backside. In the great Sinclair tradition, there is no power switch on the computer itself and you can just "pull the plug". 

Fortunately, the package includes a separate power switch cable extension. Together with the modular adapter there's quite many parts to fiddle with, which makes me worry a little.

If you have the additional Raspberry board (I don't) the USB and digital video debug ports are available. You cannot use them as conventional USBs for keyboards and controllers.

I tried to load Horace Goes Skiing from tape using my Sanyo Data Recorder, but got no reaction. Possibly the cable was bad, I wasn't that motivated to find out the problem.

Edit: I was too lazy to check the connector, it's a split EAR/MIC, so it makes sense that a mono cable doesn't work.

I've yet to test the RGB connector, not sure if I should try to make the cable myself or just order one.  Big plus for the Next people for including the RGB.

You can attach a PS/2 mouse or a keyboard to the PS/2 connector. It's worth noting any external keyboard will still follow the Spectrum layout rather than its own.

The mouse needs to be supported by the software. The Next menus, file browsers and editors do not directly make use of it.

Power connector excluded

The left side of the computer hosts the Reset, Drive and NMI buttons, with the SD card "drive".

The NMI button accesses the "freezer" menu, there I can change the CPU speed (3.5/7/14/28MHz), enter POKEs, save Spectrum snapshots and screenshots. These save features won't work as well with the Next software, if at all.

For the sake Sinclair QL nostalgia, the SD card slot really ought to be at the front, near the right side of the computer, but it's fine as it is and certainly not in the way.

Without a spring ejector, it's a little tricky to remove cards from the slot. But with some preparation and use of the wi-fi, I don't need to swap the card that much.

It's recommended to backup the card on a PC before doing anything further.

Standardizing two joystick ports is a good thing. If you intend to use the Next mostly as a game console, the front positioning might be good. Again, hot-swapping joysticks is not recommended. 

For other activities the joysticks might be in the way. Although the ports are supposed to double as serial ports, I don't feel too good about connecting peripherals from the front side. 

I tried a Megadrive pad and it accepts a second fire button too. Nice. Turn off any autofires or other exotic features before plugging in...

Extra buttons

Modern video cables such as HDMI are not physically very flexible, something I noted with the similarly tiny Raspberry Pi 400. The Next at least has some size and weight to it, so it's not like a flap of plastic dangling at the end of its cables.

A cable mess was a fact of life with the integrated keyboard computers, and it can't be helped much. It is fortunate you can get away with only two cables, the PSU and display.

Booting up

At first I was a smidge doubtful about the Next booting from a SD card, but it looks to be fast enough. Resetting isn't exactly as instant as it used to be in the 8-bit era, but the few seconds are not too bothersome.

But as reset is often the default "exit" from a program, these seconds can begin to matter...

The main choices

(The screenshots are from the Zesarux emulator and can look different to the software in the Kickstarter 2 Next.)

There's a wealth of options in already in this menu, and the SD card has a plethora of apps, demos and games to keep one exploring for days. 

For the occasional games player, the main environment is likely to be the Browser. Here you can navigate the SD card folder structure and select any of the files there. These can be ZX Spectrum TAP tape files, or SNA/Z80 snapshot files.

Basic programs also launch happily from the browser, and autorun if they have been saved with SAVE "filename" LINE 10 or something similar.

The Browser

Apart from the Browser there are many ways to operate and do things with the Next.

A number of Basic environments are available, 48K, 128K and Next Basic.

The Command Line supports alternate browsing through commands such as CD, LS and also the running of "dot" commands.

The Command Line also doubles as a Basic environment, and the dot commands can be used from within NextBASIC listings.

One interesting dot command is the .HTTP, which allows fetching of files over the internet. There's also a software for searching and downloading Spectrum snapshots from a database. After installing Getit and NextSync, there's little need for juggling SD cards.

I never really liked the Sinclair 128 Basic editor, it's a weird compromise between a line and full screen editor. At first the Command Line looked like a better starting point for Basic, but I grudgingly accepted the 128-style editor.

Command Line

TXT2BAS and BAS2TXT are also worth checking out, as they can translate between tokenized basic and ASCII text files.

The neat thing is that using #autoline 10 in the text file, the TXT2BAS can fill in the line numbers. The NextBASIC has REPEAT...UNTIL and procedures, so you don't need to explicitly refer to line numbers with GO TO and GO SUB.

It's possible to use a text editor on Next (or PC) to write Basic and then turn it into a runnable program using TXT2BAS.

As the computer is capable of a high resolution text display, a full screen text editor or notepad would have been nice. At least you can view text files through the browser in a higher resolution.

A command-line assembler would have been nice too, there's something called Odin in development but I'm unsure if it's exactly what I would have hoped.

(Edit: The Sol assembler looks quite nice)

Of older scene demos, Aeon was supplied on the card and it looked fine. There are also technical demos of Next capabilities, like the Rusty Pixels' Scrollnutter, a throwback to the Amiga era of multiple-speed big-font scrollers. There's not that much Next activity on the demoscene, though.

Lords of Midnight

There's plenty of games or at least game demos already on the card. Next War is a surprisingly addictive tower defense type game and Night Knight is a fun-looking conversion of an MSX effort. Warhawk is quite impressive scrolling shooter with lots and lots of sprites. There's also a 256-color version of Mike Singleton's classic Lords of Midnight.

HDMI Update

It's worth applying the FPGA core update as soon as possible. I found some timing problems, flickering and music tempo fluctuation in a program where it wouldn't really happen on a 48/128 machine.

I guess it could also affect game experience even in cases where nothing is visibly or audibly wrong.

By now you should have your SD card contents backed up.

Make sure Next is turned off, take the SD card out of and use your PC to access it.

Download the file TBBLUE.TBU from Phoebus Dokos' Gitlab site.

Direct download link:

https://www.gitlab.com/thesmog358/tbblue/-/raw/master/TBBLUE.TBU

Copy this one over the one on the SD card root.

Insert the SDcard back into the Next, and press U while powering up the computer.

Go through the flashing process (it takes a while), then switch off and on again as instructed. The new version number should be indicated in the boot screen.

50/60 display refresh rates

Talking of display, the 50Hz legacy of 8-bit computers can be a potential source of woes.

The ZX Spectrum was 50Hz, and so was Commodore 64 and everything else in Europe. But many computer displays today can't work with 50Hz, you'll likely have better luck with a TV than a dedicated computer display.

My HP Elite display seems to be happy with the 50/60 changes and any experiments with scrolling resulted in no glitches.

Just be aware that from an European point of view 50hz was really the more "authentic" display refresh rate, and all games and demos might not function correctly in the 60hz refresh rate.

For completeness, Next can adopt different timings and the Russian Pentagon timings are also included.

By the way, PAUSE 1 is a simple way of invoking "Wait Vertical Blank" in Sinclair Basic. I believe it just invokes the HALT Z80 command which stops the CPU until the ULA is ready to redraw a new display frame.

It works in NextBASIC too, so, adding these lines to the basicTiles/smoothTileScroll.bas source...

5 RUN AT 3

165 PAUSE 1

205 PAUSE 1

...makes that demo genuinely smooth scrolling.

smoothTileScroll.bas

The PAUSE/HALT method is not very sophisticated. The Spectrum Next has a proper line interrupt, I should check how to make better use of that, or if it can be easily used from Basic at all.

New graphics

Somewhat controversially, the Next heavily expands the graphics capabilities of the Spectrum. This reminds me a little of the TS-Conf setup which brought Amiga-esque capabilities to the ZX Evolution board.

The Next's additions are more closely integrated with the Spectrum-like ROM, NextBASIC and other features.

The hardware supports a 256 color mode, tile maps and a large number of sprites. There are so many modes I can't really examine all of them here. For example, there's a 128x96 16/256 color mode, Timex hires and Timex 8x1 color modes are also possible.

All in the best possible taste

Note that 256x192 with 256 colors takes 8 times more memory than the original 1-bit 256x192 Spectrum display file (excluding the attributes), resulting in 48K image files. That 2MB doesn't sound so huge after all.

Conveniently, 28MHz is also 8 times faster than the original Spectrum processor speed, and the graphics are also banked. What I'm saying a filled vector flight simulator or a Doom-style routine is unlikely to turn out super-fast on the 256 color bitmap. Although there's a Wolfenstein raycaster demo that seems to prove me wrong. Well.

What really helps here are the scrolling tiled modes and sprites, making the hardware closer to 1990s consoles such as Super Nintendo or Sega Megadrive.

The new modes work cleverly as layers on top of (or under) the classic graphic mode. So you could in principle have 1-bit bitmap elements on the Spectrum attribute layer, and then sprites on top of that.

256 colors through NextBASIC. One line is transparency, letting the background through.

Here's a little NextBASIC program to show 256 colors:

10 RUN AT 3
20 LAYER 2,1
30 BORDER 0 : CLS
40 FOR N=0 TO 255
50 INK N
60 PLOT N,0
70 DRAW 0,191
80 NEXT N
90 INK 0 : PAUSE 0

Line 10 activates the 28MHz processor speed.

Line 20 switches on the layer 2 (256x192 x 256 colors) and selects it.

The further INK, PLOT and DRAW commands play out on the selected layer.

Note that the LAYER 2 considers the top left corner as the 0,0 point, and the bottom right corner is 255,191. The old Spectrum graphics has bottom left corner as 0,0. This was more correct for plotting mathematics, but extremely confusing nonetheless.

You can have either 8-bit or a 9-bit color palette.

The 8-bit palette has only 2 bits for Blue, but simulates the third bit by performing an OR 1 with the most significant of the two bits.

So,

RRRGGGBB b

00000000 0

BB b

00 0 =   0

01 0 =  73

10 1 = 182

11 1 = 255

The outcome values are how to represent the blue value on PC, these seem to agree with Zesarux emulator and other sources I could find. Red and Green ramps would have values 0,36,73,109,146,182,219,255.

To be honest, the 9-bit RGB seems to be used all over. 256 colors can be freely chosen from a total of 512, much like in the original Atari ST.

As 320x256 is also possible, it shouldn't be difficult to display ST images on the Next. It takes a whopping 80K of bank memory, though.

The 256 color default palette is already well thought-out, and it can be a good idea to explore its possibilities before even trying to change it.

Next Ninja, courtesy of Bing create, conversion and some adjustments by hand.

Manual etc.

The book has a lot of information in it, replicating in parts the nostalgic experience of wading through the original ZX Spectrum manuals.

It is, however, not a book that explains in a simple way how to start using the Next features in your Basic or Assembler programs. There's no alphabetically ordered explanation of what each Basic command does. It might no make sense anyway, as some of the keywords are used in very different roles. For example, the old keyword ERASE on its own simply wipes out the current program, used to terminate an autoexec.bas.

The book is not very visual at explaining the computer capabilities, and some of the few diagrams are printed in small size. I kept scratching my head about the layer, sprite, palette and color specifications, trying to find out concise information from the internet.

Still, having the book is far, far better than no book at all, and especially at times when I can't be bothered to open a browser on another computer while working on the Next, it's a valuable reference.

It's worth looking at the Basic listings included in the SDCard, if only to see how sprites are loaded and displayed on screen, how the mouse driver is invoked etc.

Utilizing the extra power requires some study of the memory banking and examining what the various commands and registers do. Remember that even at 28MHz, the Spectrum Basic isn't really all that fast.

End notes

It's a ZX Spectrum to end all ZX Spectrums, all right, but how do I feel about the "extra" dimension? Perhaps the computer could be seen as a Spectrum with a somewhat more modern retro games console tacked on as a compromise?

Or perhaps not, as the new features are also part of the NextBASIC and the generally Spectrum-like environment.

Almost needless to say the Spectrum Next is far above simple products such as TheC64 maxi/mini and especially the ZX Spectrum Vega. Those mostly worked as game platforms and rather poorly as computers. The MEGA65 is probably a comparable project.

It's early days for me, so I don't have a final verdict. But I feel the Next, with all its additions, is still somehow respectful to the original ZX Spectrum experience. The extra features could make it interesting for those looking for "new" 8-bit computers.

The primary use after all?

What makes this kind of computer fresh and attractive is the anarchy made possible by not having to care about security, localization, multi-user log in, accessibility and whatever else is taken granted in mainstream computing. Just some core functionality and a bunch of software written in very different, individualistic ways.

It looks like the Spectrum Next has generated enthusiasm. Hopefully there will be enough momentum to keep new software appearing for years to come. The hardware and the system is of course interesting in its own right. 

I left out the productivity software side. Although any serious developers are likely to use cross-development tools, there are still the obligatory character, sprite, tile and map editors, suggesting you could use Next directly for creative purposes. Maybe they are enough for small Basic programs, but better tools could inspire more software and content.

I had some minor success in compiling assembler, turning on layer 2 and displaying some extra colors. It looks like understanding the .nex package format would be very useful. I'll come back to this if I learn the ropes.

Bare Metal Revolution (?)

Some years ago I asked myself, "surely someone must have written emulators directly for Raspberry Pi hardware?". At that time there were a couple of promising but incomplete attempts at writing a C64 emulators for the Raspberry Pi.

Now it seems in the meantime these projects have become more mature, and I am clueless about these recent developments (as usual). Now even I can easily try two "bare metal" emulators on the Raspberry Pi.

Bare metal sounds like it ought to be a musical genre, but really it's intended to mean that the emulator does not reside on top of a conventional operating system, like having Fuse Spectrum Emulator on top of Linux.

This is not to say the emulators are coded bit by bit on the processor, but at least without a full OS I guess spurious memory, swap or disc accesses can be avoided altogether and it becomes possible to achieve very fast boot time and rock solid frame rates.

I was also attracted by the possibility of composite video output which I expected to make the experience more 'real'. More about that below.

I tried two emulators, the ZXBaremulator and the BMC64.

In both cases, the relevant files are copied on a FAT32 microSD card. The C64 needs the kernal, chargen, basic and d1541II files too.

Lines in config.txt can be used to adjust how Raspi sets up the video image. Which leads me to give you a...


Foreword & Warning:

I may have ruined my old Sony portable TV by changing the display resolutions, overscan modes and their parameters for the composite video. The TV started smelling a bit bad and the composite image begun wobbling, turned yellow with color components misaligned. Ouch.

I can't say my fiddling with these emulators is what caused the death of a 30-year old TV, could easily have been a coincidence. I wouldn't blame the emulators or the Raspberry Pi in any case.

However I did try varieties of video modes that might not have been too friendly to the TV.

Progressive scan. The camera is what makes the screen look distorted.

ZXBaremulator

First one is the ZXBaremulator, a ZX Spectrum emulator. It's not clear to me if this is based on some existing software. Just a hunch it is not Fuse, looking at which options are there and which are absent.

Boot time is near-instant. Pressing F1 brings up the file menu, Alt-K gives keyboard help. 128K and +2 are also emulated, so enjoy those AY sounds. Tapes can be loaded by selecting them on the menu then using the LOAD "" or the 128 Tape Loader. A reset+auto-load would have been nice.

Thankfully the tape (TAP/TZX) loading has been speeded up. It's not instant like on big-computer emulators, but a lot better than no turbo at all.

With composite, Raspberry Pi outputs something like 480-pixel height screen through interlacing. This is somewhat helped by doubling the lines, so the Spectrum 256 x 192 screen area is really a 384 pixels tall, add borders to that and the vertical space is filled.

However doubling the lines doesn't quite get rid of the 'flickering' quality of the graphics, which becomes more obvious when white and black horizontal lines are repeated.

On my Pi2B+ and Pi3B+, the composite can output progressive scan, so I could get remove the flickering by changing a line in the config:

Instead of sdtv_mode=2

I can use

sdtv_mode=18    # progressive PAL

This is not without problems as the result can be blurry and/or has interference patterns from scaling.

Using disable_overscan removed the interference type pattern but the blurry scaled result is not perfect either. The screen is solid and this at least proves to me the interference is not an inavoidable TV artefact but a result of the raspi scaling. Looking at checkerboard and horizontal line dithering patterns, these become overtly mixed, as if the dither really formed a new color.

When playing games, the slight blurriness does not matter as much as the flickering did, but fonts can look a bit garish and the end result is not especially authentic.

+128K modes and AY sounds too
+SD directory structure supported
+Helpful key overlay & menu screen

-Can't load snapshots (z80, sna)
-No support for 9-pin joysticks

Watching that Gianna Sisters smooth scrolling

BMC64

Emulating Commodore 64 is no small feat, and here the results are also admirable. The frame rate is smooth, as can be proven by looking at the Great Gian(n)a Sisters intro screen for minutes and minutes. The emulation is based on Vice, so it ought to be pretty good.

The overlay menu is nice but apparently there are no key shortcuts?

The C64 palette is not as harsh as the ZX, so the flickering on composite is not as immediately apparent. However, it's there and using black/white line patterns shows it.

Using sdtv_mode=18 in the config.txt again kills the flickering, but no amount of fiddling with the disable_overscan and overscan values can remove the interference pattern like could be done with the ZXBaremulator.

Thinking of a real case, the large texts made from thin horizontal lines in Wizard of Wor become affected by the scaling.

I'm unsure if this is a result of the emulator author making a choice or not. The supposedly 'real' aspect ratio is not in my opinion as important as getting a resolution that scales well.

So the results are not as promising as with the Spectrum in this area. So here I'd say endure the default 480i flickering if you want to use the composite. The interference pattern is there too but it's maybe less conspicuous.

Scaling artefacts.

The Raspberry Pi GPIO pins can be connected to real Atari/Kempston 9-pin joysticks. This was easy to do without soldering, using a suitable connector and jumper cables. Just remember the GPIO numbers are not the pin numbers, check the GPIO-numbered pins within the connector of the particular make of Pi. They ought to be similar though.

Using a 9-pin joystick such as TAC-2, it became easier to judge whether there is a lag or not in the emulation. Using the composite connector with a CRT and the GPIO-connected TAC-2 joystick, I felt the lag was negligible or non-existent, I really couldn't complain at all.

Using the HDMI television, I felt the presence of a noticeable lag in games with very crisp controls, such as Buck Rogers. Whether the particular TV is to blame (most likely) or if the HDMI connection always produces some delay, I can't say. Still I'd think even this lag is acceptable for many games.

Maybe more about this later...

The disk loading is real time, so get used to waiting. Ok, it's possible to use an Epyx Fastload cart image to get a faster loading speed (for me a 25 second waiting time was reduced to 11) but that's an extra stage too.

An Action Replay VI cart image did not work as I would have hoped. Carts obviously run instantly but I only tried some 8K and 16K cart images for now. (It's not an accident the test games mentioned here are cart images, they load instantly.)


+Nice overlaid menus
+Selection of palettes
+Support of 9-pin joysticks via GPIO

-SID emulation could be better? No 6581/8580 selection?
-No SD directory structure support
-No PRG loading support?

Edit 19.12.2020: I had a second look at a later version of BMC64 and it's become a lot better!


But why?

These emulators are a fantastic job overall. But do *I* need something that lies somewhere in-between real hardware and an emulator running inside normal OS, especially as I have both options already?

Well, it's another interesting project to mess with, and it would be fun to build a case for a new ZX or C64 as the Pi is so tiny. It might be handy to carry and show 8-bit games and demos to people without having to lug all that old hardware, yet having something more than just an emulator on a laptop.

The composite image modes turned out to be a bit of a mixed bag, so perhaps I'd go with HDMI here after all.

Again, I have to warn about the dangers of fiddling with the video modes too much on an silly old TV. I'm not sure if framebuffer_width affects the composite image at all but I had that included on my BMC config when I fried my TV.

Linux, Rasm, Arkos Tracker 2, ZX Spectrum

Looking at a promising recent z80 cross-assembler and Arkos Tracker 2. Both work on Linux and there are now easy-to-use music player routines for ZX Spectrum included.

The assembler compiles the player routines without any modifications so it made sense to me to lump my notes together here.

It couldn't get much easier for the Linux user I think!


Rasm

Rasm is the z80 cross-compiler. (The R stands for Roudoudou I suppose). Download the Rasm archive, extract it to a folder.

Look for the compilation instructions inside the c file, something like

cc rasm_v0108.c -O2 -lm -lrt -march=native -o rasm

(Edit 30.8.2022: These days make seems to work as it should. If compilation stops at stdio.h or string.h, may need sudo apt install build-essential before attempting.)

After copying the output rasm to say /usr/local/bin, you can then use rasm inputfile.asm to produce an instant binary from out of the source.

The inputfile.asm contents might be something trivial like this:

org $8000

ld hl,#4000
loop:
inc a
 inc l
ld (hl),a
jr loop

This should fill the top third of the screen with garbage.

The black screen comes from the bin2tap BASIC header

When the binary rasmoutput.bin (the default name) has been created, it still needs to be converted to a TAP file that a Spectrum could load.

Using the bin2tap (need to compile that too) you can create a runnable tape with a BASIC header. By default it works with the $8000 (32768) address so no need to worry about that either. Again, it ought to be copied to /usr/local/bin (for example).

Then, working with the default output binary name:

bin2tap -b -o mycode.tap rasmoutput.bin

After this, Fuse will happily load the produced mycode.tap and use the BASIC loader to load the binary and execute it at 32768 ($8000).

Rasm is a clever modern macro-assembler with all the repeat functions you'd expect nowadays. With a good editor like sublime-text (with added z80 highlighting) it's a breeze.

For example, the following will generate a table of 192 start addresses for each vertical pixel row, often needed in ZX Spectrum graphics routines:

screenbase=$4000

ytable:
repeat 3,yblock
repeat 8,ychar
repeat 8,ypixel
dw screenbase+(ychar-1)*32+(ypixel-1)*256+(yblock-1)*2048
rend
rend
rend

Using variables, evaluations and local labels inside repeat blocks even quite complex repetitive code can be generated.



Arkos Tracker 2

More information about Arkos Tracker from here. Extract the archive and simply run.

I'm not going too deeply into song creation here, suffice to say this is the easiest cross platform 8-bit tracker I've seen, with an audible default instrument and preset instrument categories for bass, snare etc.

After the pattern has been filled with bleeps and bloops, you can export the creation from the menu option file/export as generic (AKG), choosing source as the export mode.

Pick the PlayerAkg_SPECTRUM.asm from the players/playerAKG/sources folder, and copypaste the contents to the end of your source.  (Of course it would be a better practice to include the player routine and the song.)

For example, this is a minimal main loop that will HALT the Spectrum until the next frame, and call the 'play frame' portion of the player routines.


org $8000

ld hl,Songname_Start
xor a
call PLY_AKG_Init

loop:
halt
call PLY_AKG_Play
jp loop

; paste the PlayerAkg_SPECTRUM.asm contents here

; paste the Songname_AKG.asm contents here


The exported song source can be copypasted after the player source. The Songname obviously refers to the filename it was exported with.

The start address is not needed so the org line may need to be removed from the song source. As can be seen the player nicely accepts a flexible start address - no need to copy the song data to some specific address either.

My example is simple, it's not especially useful to simply HALT and call the player routine, it might be better to use an interrupt to play the song.

But this is it for now, I'm super-impressed how easy this was to set up and get running.

New Spectrum, New C64?

Recently, there have been some rumors about new models of ZX Spectrum and Commodore 64. Whereas we've lately seen the ZX Spectrum Recreated and the Spectrum Vega /plus game console, the Next promises to be something more like a real computer, like the ZX Evolution. Following the blueprints of C64 Reloaded, Individual Computers seeks to produce both new cases and new stock of the Reloaded. There's also a funding campaign for something called THE 64, which sounds a bit too ambitious to be honest.

Although the new computers would be compatible with their respective originals, they are not exact replicas. And why would they be, really? The world deserves a better C64 and a better Spectrum. Such a project would also open up the possibility for further "cloning" with contemporary means, ensuring the platforms live on.

Anyway, all this made me think, what would I like to see from such a project?

Overall, the new computers could be more flexible for building different types of cases and input/output solutions. The 1980s home computers were notoriously closed products. Many connectors could be made as header pins, and the responsibility for building the less often used connectors would be up to the owner or third parties.

There are two schools of thought about the video output. Others would like a current (hdmi) video output for modern displays, whereas others see old-fashioned monitors and TVs as a must. One possibility is to have modular video output, you'd only get what you need. However it can be a bit of a space-waster really. ZXEvo has it pretty good, a VGA output and then header pins for RGB.

Given this overall idea, below are my wishlists. These are simply fantasy as I can't really plan this type of stuff.

The Fantasy models:

• Circuitboard footprint that fits in at least some Spectrum model case (preferably the toastrack 128, but maybe +2/+3)
• A new z80 processor 3,5mHz/7mHz/14mHz
• 48K-64K base RAM, Memory expansions through the 128K memory model or more as in Russian machines (Evolution).
• FPGA ULA video generation. Preferably pins for RGB and composite, but also modern hdmi.
• FPGA YM audio generation. Also a socket for real YM
• Alterable timing schemes: Russian Pentagon, British Spectrum, something new? (Not sure how to achieve this)
• SD card reader. I would maybe leave out the floppy controller.
• First 16K as re-writable/replaceable ROM, or as RAM with write protect.
• Reasonably compatible zxbus/edge connector pinout
• Keyboard input pins compatible with the original spectrum, but also USB or at least PS/2
• Audio jack/pins
• Joystick pins (sinclair/kempston)
• Kempston mouse compatible mouse port, maybe USB or at least PS/2

So, quite similar to ZX Evolution really. The major difference is trying to make it fit in smaller space and leave out certain things. I'm not too keen on new display modes, but why not.

If there has to be a new case, borrow ideas from 128K Spectrum or Sinclair QL, but a bit flatter if possible. The QL keys looked cool but I guess they have to go. The Next renders look good but in my opinion round shapes never quite belonged with the Spectrum... What I'm looking at is a keyboard-less case, that could be altered to integrate a keyboard.

then...

• Original footprint circuit board, preferably short board
• A new 6502 processor? Does such a thing exist?
• 64K memory, expansions via the REU standard. Also REU on board, what's the maximum, 16MB?
• Standard serial port (real 1541, SD2IEC)
• SD card reader
• Cartrdige expansion as 100% cartridge-compatible as possible.
• FPGA SID. Audio generation via SID emulation, also a socket for real SID 8580/6581 or Swinsid
• FPGA VIC-II. Video generation, preferably both composite/RGB and modern hdmi
• Joystick ports/pins
• Commodore mouse compatible mouse port, maybe USB or at least PS/2
• Keyboard input pins compatible with the original C64, but also USB or at least PS/2
• Audio jack

The C64 is a tricky thing. With Spectrum, the specs are simple and there's also some precedent for ignoring them. Consider the Russian scene for example, who have very nearly redefined what a ZX Spectrum is. But with Commodore 64, fans would not be satisfied with anything less than a timing-exact, perfect, real thing.

If there's a new case, it would be C64C-style, and forget the original brown breadbox colors. Yes the breadboard is nostalgic but it's a bit too tall and ugly to be honest. With keyboards it's a different thing. Many functioning originals exist so it would be wise to allow using the genuine item. This pretty much then defines the form of the computer. Proper arrow keys would be welcome, though.

Horizontal starfield in BASIC

Scrolly stuff is a bit hard in eight-bit BASIC, so of course it had to be tried.

Horizontal scrolling is an interesting case as the environment usually does not have special commands or ROM calls for that. Also, starfields are kind of easy/fake scrolling as there's no real bitmap or background to move.


Commodore 64

In the first version, I was silly enough to use dimensioned arrays and a FOR-NEXT loop for drawing the eight stars. POKE seemed slow in this context and I abandoned it for a while. The C64 BASIC does not have a LOCATE or PRINT AT command, so the horizontal/vertical coordinates had to be handled with the TAB function and/or character control codes. This means that for the speed of the program it is not trivial where the stars are vertically. I settled for 8 stars with one row between, filling about 2/3 of the screen.

I did know from experience that it is not necessary to test each star x coordinate every time the coordinate is reduced. After the eight stars are moved, only one of the star coordinates is checked. With stars it is acceptable if they disappear at a bit randomly near the left side of the screen.

For the second version, I unrolled the code and did away with the DIM at the same time. So each star has their own separate variable. Because of the single-star coordinate testing, the star printing is unrolled eight times, and after each printing only one horizontal coordinate is compared.

40 print chr$(19);tab(xx);"* ";chr$(17):xx=xx-1
41 print tab(xa);"* ";chr$(17):xa=xa-1
42 print tab(xb);"* ";chr$(17):xb=xb-1
43 print tab(xc);"* ";chr$(17):xc=xc-1
44 print tab(xd);"* ";chr$(17):xd=xd-1
45 print tab(xe);"* ";chr$(17):xe=xe-1
46 print tab(xf);"* ";chr$(17):xf=xf-1
47 print tab(xg);"* ";:xg=xg-1
65 if xx<9 then poke 1025+xx,32:xx=35

(repeated eight times, with the last line comparing a different variable)

I also tried to combine the character formatting codes and printed stars into one long line, but this was a bit slower.

By using POKE instead of PRINT "* "; statements, although previously unsuccessful, I could now get an extra bit of speed. The third starfield is faster, but it also flickers a bit. Possibly not so visibly on a tube TV.

20 poke ba,32:ba=ba-1:poke ba,42
21 poke bb,32:bb=bb-1:poke bb,42
22 poke bc,32:bc=bc-1:poke bc,42
23 poke bd,32:bd=bd-1:poke bd,42
24 poke be,32:be=be-1:poke be,42
25 poke bf,32:bf=bf-1:poke bf,42
26 poke bg,32:bg=bg-1:poke bg,42
27 poke bh,32:bh=bh-1:poke bh,42
29 if ba<1032 then poke ba,32:ba=1063

(repeated eight times, with the last line comparing a different variable)

One advantage is that the POKEd stars can be more freely located around the screen, but also their color is not specified and in principle the color memory could be pre-filled with interesting colors.

The alternative would be using a char display that is pre-filled with * and the POKEs would address the color memory.

A larger number of stars, or even a kind of parallax is also possible, but I want to keep the program version speeds easily comparable.

I used petcat (one of VICE package tools) to convert text files into a basic PRG.

All three starfield program versions are downloadable from here:

http://csdb.dk/release/?id=148877


ZX Spectrum

I could transfer the above insights into a finished result almost straightaway. The screen memory is filled with ****oooo---- type pattern and the attribute space is filled with black-on-black.

Then the POKEs adjust the attribute memory just as the Commodore 64 version used the character screen memory. This way it's possible to have some advantages of a character display on the Spectrum bitmap screen, as shown in many machine code demos and games.

I also tried a PRINT AT -based version that does not use POKEs. It might be just a tiny bit faster than the POKE-ing, but not enough to justify it.

Perhaps surprisingly, despite all the talk about Commodore Basic being slow, the ZX Spectrum version is not really faster. It's a bit difficult to compare through eye-ball judgment, but given that the Speccy screen is 32 characters wide and C64 is 40, one might even say the C64 BASIC is more effective here. Obviously this character-based starfield is not an indicative comparison of the two Basics overall, for example bitmap graphics is practically impossible on C64 Basic.

I used zmakebas to convert text files into a TAP.

Download the zip with the TAP and the text file from here.


MSX

I made a short attempt at replicating the approach with MSX basic, where I had to use a LOCATE/PRINT based approach as there's no real way to POKE directly to the screen.

I could not easily find an equivalent of petcat/zmakebas so I simply wrote the listing in an emulator. However I crashed my openmsx trying to save the machine state so the motivation for the project sort of dwindled. But what little I got did seem a little faster than the Spectrum and C64 versions. I could not really go into potential SCREEN 0/SCREEN 1 differences, though.