ZX Spectrum ULAplus mode, Multipaint etc.

I was asked to do ULAplus extended ZX Spectrum graphics mode support for the Multipaint painting software.

I was initially reluctant. Multipaint supports only the most established and "culturally recognized" modes, and I've not bothered to make C64 FLI/AFLI modes either, and they don't even require new hardware.

But I then saw that some images might actually come out of it, and seeing as I already own hardware that can display the mode (ZX Evolution) my curiosity grew. It's a challenging mode to work with, and Multipaint might help here.

I suppose a fairly huge proportion of currently active ZX Spectrum enthusiasts would be at least aware of the ULAplus mode. Although there are many modded and patched games and converted images that use the palette, the lack of editors and paint programs means Multipaint could even fill a niche here.

I'd usually prefer to release things before discussing them, but here I'll make an exception as there's a bit more to digest than usual.


ULAplus hardware?

In addition to the already mentioned ZX Evolution, I know about a ZX-UNO computer that has it. Then there is the SLAM drop-in ULA replacement which works on 128k or a +2.

A HDMI video board called the TK-Pie appears to promise these modes too.

Emulators also support the mode. I couldn't get my Linux Fuse patched to support it, but I have the mode working on ZX-UNO emulation within the ZEsarUX emulator. There I have to switch the mode on in the Display segment of the settings menu.



ULAplus and ZX Evolution

I had to update the firmware of my ZX Evolution to make this mode work. The firmware you get from one of the nedopc pages is not recent enough, so I went to GitHub and downloaded the latest zxevo_fw.bin and zxevo.rom. (Go look for the ROM at pentevo/rom/bin/)

I cannot guarantee this is the best option for your ZX Evolution, but at least I have my ULAplus mode working on a hardware speccy.

Upgrading the firmware was easy as I have my Evo inside a mini-ITX case. Wired correctly, I can then copy the zxevo_fw.bin to the SD card, and simply hold down the "soft" power button while plugging the cable in. The power LED flashes a bit and the firmware has been upgraded. These days the ZXevo ROM can be updated from within the baseconf service and it is a good practice to have both the ROM and the firmware updated at the same time.

ZX Evolution does not have a full ULAplus mode, it omits the difference between 6th and 7th level of the Red and Green components. So it might be something to consider when making graphics on the ULAplus.




ULAplus mode in Multipaint

Here I focus on how ULAplus works in practice and what it might mean for someone using Multipaint, although it's not yet definite how it will work.

ULAplus is clever in that it does not make the Specrum incompatible, it simply changes what is done with the memory bits that make up the display file. So, I'm only talking about the most standard mode, which has the same old resolution of 256 x 192 and the 32 x 24 attribute resolution with 256 colours to choose from.

The attribute "clash" is not removed, there are still two colours inside an 8x8 area, and much like with the ZX Spectrum there are rules to how these colours can be chosen.

But as there are more colours and they can be combined in more flexible ways, the look of the graphics can be changed quite radically. I'd go as far as to say the ULAplus experience proves the colour clash wasn't such a huge problem with the original ZX Spectrum, the limited colour palette was.

Here's a diagram that may be more confusing than helpful, but let's try it out:

From Multipaint painter's perspective:

-There is an index of 64 colours.
-These 64 colours can be adjusted with RGB sliders from a total of 256 colours. It is a kind of semi-9-bits RGB palette.
-The 64 colours are really four sets of 16 colours. No colours from two different 16-colour sets can be mixed inside the 8 x 8 area.
-Each of the 16-colour sets are further split into two subsets of 8 colours. The colours inside the 8x8 must be from a different subset. ("INK" and "PAPER")

Just as in the normal ZX Spectrum mode, Multipaint does not care which colour is INK or which is PAPER. This is why I have described the mode in a bit idiosyncratic way.

The internal workings can be partly forgotten by the artist, but still ULAplus is more complex than the ZX Spectrum limitations and it would be better if the artist understood these rules.

My starting point for the ULAplus Multipaint engine was to first prevent any pixel drawing operations that cannot be done, and then attempt to fill in the gaps with some helpful intelligence, without going overboard with this "helpfulness".

An early test of the TAP export, shown on the screen of a ZX Evolution computer.

The 16-colour set is technically called a Colour Look-Up Table (CLUT) and I will now follow that terminology here.

So, if the pen colour is from another 16-colour set (CLUT) than the colours underneath, then Multipaint likely won't allow you to draw on it.

If there is no diversifying pixel information at all within the 8x8 cell (it is filled with 64 pixels of the same colour) and it is not legal to draw with the current pen colour, it will be "primed" by Multipaint with the chosen colour. The area will also belong from that point onwards to that CLUT.

However, if the pen colour is legal the pixels will be added on that square and from that point on it will have two colours in it.

So, two different halves of a CLUT combine to make the colours on the same 8x8 area. It doesn't matter which colours or bits are there internally, just as long as you use the same pen colours that already exist on the area, it will work.

Multipaint allows a small detour here: If there is a way to resolve the drawing operation by using different colours from the same CLUT, this will be attempted. If this won't work, a possible combination will be sought from another CLUT.

For example you might have the colour black (0,0,0) in both sides of the same CLUT, this would facilitate drawing black easily on any colours that belongs to that CLUT without having to pick the correct colour everytime.

If the colour black is present at all sides of all four CLUTs, you can freely draw with the colour black over any portion of the picture, the 2-colour rule of course applies.

Also, if you want to breathe freely and have 8 colours that behave like the Spectrum with no CLUT nonsense, define the colours 8-15 same as the colours 0-7, and draw away!

Powerdrome pitstop from Atari ST/Amiga. An adaptation, not a conversion.

Importantly, the palette will be visually separated to show the 16-colour sets as rows. The artist ought to internalize the idea that the colours within an 8x8 area have to be from within the same CLUT, and from different "sides".

QL assembler

Lately I've turned into a bit of a QL-nut, and now I wanted to try coding assembler on it. Most of the files and initial info are from Dilwyn Jones's comprehensive QL web pages, particularly the assembler and archiver pages.

Although vasmm68k on Linux is very useful, there are limits to what kind of code can be run on an emulator. It's not easy to find an emulator that a) works on Linux, has b) cycle-exact scanline video emulation, has c) flexible transfer between it's own filesystem and the PC and is d) free. UQLX is nice to have, but as far as I know it does not do screen flipping/vsync in the way a real hardware does.

So I went the route of compiling 68000 code on the QL hardware platform itself. After all, it is a semi-16-bit architecture with 800K of memory. With modern media, it should not be excessively painful to code on this system.

First I tried a tiny assembler called Adder, but only on my unexpanded QL it goes past the initial screen, so I moved to the larger Qmac assembler/linker package. This is a bit of an overkill for the things I want to try out, but at least it is convenient and does what one would expect from a full assembler.

I also tested asm20 at some point, but after a promising start it seemed a bit too incomplete. I failed to find a way to include binaries, and as I could not turn off the listing (opt nolist does not work) it becomes quite slow for even small sources.

I'm wondering why a quick editor/assembler/monitor setup like Asm-one or K-Seka on the Amiga/Atari ST does not exist for QL, or if it does, where is it hidden?


QMAC

So, over to the Qmac/Qlink package. Installing is not too hard once you get the hang of transmitting files over to the QL. Just unzip the qmac package on your Sinclair QL drive.

It should be remembered that QL archives need to be unzipped on the QL filesystem, as PC/Linux extraction tends to mess with QL executable file headers. To get around this, there's an already-unzipped version of unzip, and a BASIC file that repairs the header for that file.

After this has been achieved,

exec_w flp1_unzip;'flp1_archive_zip' 

will start storing the files from the archive_zip to flp1_, if they are on that drive.

After the qmac file is unarchived, it is a good idea to copy the assembler, the linker and the source to a ram disk, if you have the memory to spare, as it should always be faster than any drive.

Afterwards, the executables can be run directly from the ram drive:

exec_w ram1_qmac;'ram1_source'

where 'source' is the assembler source text file with the name source_asm, here assuming it is in ram.

exec_w ram1_qlink;'ram1_source'

and this would result in a source_bin file.

Running the binary:

a=respr(size): lbytes ram1_source_bin,a: call a

For a relocatable code file, this would then reserve some unused memory space, load the file and call it. The size must be enough to contain the binary size. For non-relocatable code, the code should be loaded to a "safe" address and called from there, such as 196608 on an unexpanded QL.

ALCHP and LRESPR might be more handy but I tend to avoid running the Toolkit 2 extension unless I need it, as it's a few seconds more boot time :)

The commands above also show how to pass parameters to executable files. Note that EXEC_W executes the file and exits, whereas EXEC would run it as a job.


Running QED text editor

QED is a nice little text editor for writing the assembler sources. Loading QED, the file definition has to be a bit more explicit:

exec_w flp1_qed_exe;'flp1_source_asm'

Use F3 to enter the command mode in QED. X saves & exits the editor, Q exits.

By the way, with a television monitor the QED window size may need changing. Be sure to download a QED version that includes the BASIC configuration file. This config program brutally overwrites the QED binary with your chosen parameters, which is handy in that the QED can then always be copied as one file.

The configuring program may complain of a missing variable, as the window size function calls are part of yet another non-universal extension package. Insert something like this at the beginning:

10 SCR_XLIM=512: SCR_YLIM=256



Boot files

The above won't go very far in establishing an effortless edit/compile cycle.

But with boot files and the superBASIC procedures, much more can be done. Besides, creating useful boot files on Sinclair QL is somehow more fun than scripting on modern computers.  Use colors, graphics, whatever you like. Hey, it's BASIC - but with procedures!

My boot file will copy the assembler, linker and my current working source and related binaries to a ram disk. From there they run almost instantly.

They could be copied from the HxC Floppy Emulator disk image, but the QL-SD sdc1_ drive is much faster than the HxC, so the files are copied from there.

20 print "Copying to RAM..."
30 copy sdc1_qed_exe to ram1_qed
40 copy sdc1_qlink to ram1_qlink
50 copy sdc1_qmac to ram1_qmac
60 copy sdc1_source_asm to ram1_source_asm
70 copy sdc1_datafile to ram1_data_bin

Obviously these can be made into it's own function that gives on-screen information as the files move.

In absence of a real makefile, I have a defined procedure called MAKE, just to have a similar compiler command on QL as on my Linux:

100 def proc make
110 exec_w ram1_qmac;'ram1_source'
120 exec_w ram1_qlink;'ram1_source'
130 end def

After all this, MAKE will assemble and link the file source_asm, and as a result there will be ram1_source_bin.

Executing the result can be made into a procedure too, just remember to reserve enough memory to fit the binary, otherwise it will behave erratically=likely crash.

I called this procedure SYS to have it short and as a nod to the Commodore computers.

10 a=respr(8192)
200 def proc sys
210 lbytes ram1_source_bin,a
220 call a
230 end def

If the code is to be loaded to a fixed address, the LBYTES should load it directly and no RESPR is needed.

Also bear in mind that apparently plain BASIC is not able to free the memory taken up with RESPR. So the memory should be reserved once in the boot file, not inside the procedure. As long as you don't re-run or load another basic program (and you don't need to) the variable is kept in memory.

Some extensions have commands for allocating/deallocating memory from BASIC, such as the ALCHP mentioned above.

A procedure for launching QED with the current source is also desirable, as a sort of alias for the long command line.

250 def proc qed
260 exec_w ram1_qed_exe;'ram1_source_asm'
270 end def


Development environment options

So, after the boot file has been run, I can type QED to edit my current source file, MAKE to compile it, SYS to run the code. More shortcuts can be created for producing disc backups out of the RAM files, etc. Instead of command procedures I could also create a key-press based environment.

As Sinclair QL is a multitasking system, the QED text editor can also be run as a parallel job with EXEC instead of EXEC_W, flipping between QED and the BASIC prompt using CTRL+C. This has the advantage I don't have to exit QED so the cursor position is not forgotten. The self-defined BASIC procedures remain in effect. Also, I can view and edit the source as the compilation runs in the background.

Whenever screen update happens on another job, the QED screen gets messed, and there is no screen refresh when you switch a job. In QED, F5 key at least redraws the screen.

Dual QL setup

With the above setup, if the code returns to BASIC neatly, it's possible to go on modifying the source without having to boot up the QL after every code test. Obviously, if the program crashes the system has to be rebooted, but having all the current materials auto-copied at least reduces the chore.

The crashes and re-boots resulting from wrong code can be alleviated by having two Sinclair QLs connected with a net cable, one as the compiler and the other as the target. Although this is probably more trouble than it's worth, I had to try.

One approach might be to assign NET values to each of the QLs and use LBYTES neti_2,address type commands for loading in the resulting binary data.

It gets crowded in here...

But, after fixing my EPROM cartridge with an FSERVE-enabled Toolkit II, I can also finally enable a file server between the Minerva-equipped QL and the unexpanded QL with a TKII cartridge. (The fileserver does not work from a RAM-based toolkit.)

With the file server, it becomes possible to access files from drives connected to the first QL, referring it with n1_ or n2_, for example. Commands can take the form of EXEC_W n2_flp1_qed_exe

The file server works if you remember it's not all-powerful - trying to do complex things such as compiling across the server and editing text at the same time may result in the computer getting stuck. Trying to poll a file every few seconds over the server was not such a great idea either. Even if I managed to get the QL stuck, in most of the cases the actual server job survives, so files may be recoverable.

So, instead of the LBYTES neti_ - SBYTES neto_ approach I can use the file server to load and run the binary off the ram disk of the other QL.

The second QL does add some unwanted physical complexity to the setup, and obviously the crashing target QL needs to be re-booted too.

Another thing is the other QL does not have Minerva so my page-flipping routines need a different approach and the code can't simply return back to BASIC. But more of that some other time.


68008 assembler

A few snippets of my early code. I'm only here interested in plain QL coding, and my code likely won't work in the later variants.

Still, I try to be nice-ish, and make relocatable code, mostly because it's useful to have the code return to BASIC intact for further editing (see the setup above). But I've not loaded the screen address using the QDOS call and neither do I care about potential graphics screen variants.

The following code will fill the usual screen area and return to BASIC without an error message:

    SECTION CODE
    MOVE.L #$20000,A0   ; starting from 131072
    MOVE.L #$3FFF,D0    ; $4000 words = $8000 bytes
LOOP
    MOVE.W #$AA00,(A0)+ ; bit pattern
    DBRA D0,LOOP        ; loop until d0 is 0

    MOVEQ #$0,D0        ; return to basic
    RTS
    END

The Qmac likes to have SECTION and END.

Note that using + with MOVE.W will "hop" the A0 address in 2-byte steps. With MOVE.L it would be 4.

Next thing to ponder is why the following code might be faster than the previous:

    SECTION CODE
    MOVE.L #$20000,A0
    MOVE.L #$7FF,D0
    MOVE.L #$AA00AA00,D7
LOOP
    MOVE.L D7,(A0)+
    MOVE.L D7,(A0)+
    MOVE.L D7,(A0)+
    MOVE.L D7,(A0)+
    DBRA D0,LOOP

    MOVEQ #$0,D0
    RTS
    END

With 68008, I'm told it would be wise to have as much as possible done through the registers, as the speed issues (versus 68000) are not such a huge problem.

Some have gone as far as to say the QL is "really 8-bit", but as the opcodes are equal to 68000 and much more than 65536 bytes of memory can be accessed without writing any paging routines, I'd say it's a true 16-bit world for the coder.


The verdict

I'm surprised it's still possible to get accustomed with coding on the QL itself. Today's card readers and the memory expansion are very helpful in this. The largest problem is that the Qmac is not that fast, especially as the source begins to grow, but it has been useful in getting to know 68000 and the QL.

The QED text editor block copy/paste functions are a bit primitive compared to modern editors, but overall the typing experience is not that bad. Sinclair keyboards are a bit of an acquired taste, but I've found I can live with the QL keys.

It's been a long and rocky road to get the Sinclair QL make these things. But it has also been quite rewarding. I've been working with a sprite routine, something I'll come back to later.

Sinclair QL Tetroid disk interface / memory expansion

The Tetroid Disk Interface is a memory expansion, disk interface and card reader for the Sinclair QL. It adds 768K memory to the 128 of the plain vanilla QL, totaling the memory to 896 kilobytes.

I ordered this from Russian Federation via eBay, with a Compact Flash (CF) card thrown in. The seller is identified as "tetroid" around forums and SellMyRetro site, so the interface is called Tetroid Disk Interface. The device can be considered an extended clone of a Miracle Trump card for the QL.


Fitting inside the case

Looking at the board, I check the jumpers are in good position for the plain QL, as instructed by the manual leaflet. Three jumpers turn on/off the disk interface, the QUBIDE/QUBATA interface and the extra memory.

Before I could get the card to fit, I had to whittle away just a tiny amount of the plastic from the QL with a paper knife. After this the card slides easy along the rails and fits comfortably to the extension port. The card sinks in completely, only the CF card protrudes slightly over the QL footprint: beautiful.

First boot up experience

Booting the QL with the included Compact Flash card, my first thought was: "It takes a bit long to get to the BASIC". But the CF card is filled with goodies and extensions that load on start-up, so the QL eventually ends up with a sort of graphical desktop.

Whaat....

Glancing at all the start-up messages, there are ToolKit 2, Q_Liberator (basic compiler?) , TURBO TOOLKIT (another basic compiler?), Pointer Toolkit, Qmenu, Scrap, History Device...  The CF card contents are a very thoughtful inclusion and makes me already feel I have something new to explore. (Edit: It seems I've maybe misunderstood this a bit, it's not that all the above software is on the card, but the related runtime libraries needed. Anyway, there's a bundle of things on the card)

As the QL has multi-tasking, a notepad, a calculator and a BASIC command line window can be open at the same time. The GUI is a very early effort, many windows often show functions and technical details that are text-based anyway. All this is very interesting, but not my focus now. Perhaps at a later time...

Now I can move to writing on QL...

Funny to see that there is less than 480Kb left after everything has been loaded. That's still three times more than the normal 128, which wasn't all usable anyway.


Without the CF Card

Next I took the CF card out and booted the QL again. (Don't insert/remove the CF card when the power is on).

Boot time to SuperBASIC is fast, but I guess checking the 800K memory adds a bit to the process. I shed a tiny tear for every second added to the boot time, because for me directness is a major charm of old computers.

Left: Showing memory in BASIC, Right: after running the TK2

The Tetroid manual leaflet obviously does not explain how to use your QL or the extensions. It doesn't even describe the Trump card functions, so the manual for that device is recommended reading.

The PRINT (PEEK_L(163872)/1024-128) command I found from a QL forum can prove the 896 K of memory is there. But to make things more simple, the Toolkit II can be summoned from the interface. TK2_EXT command gives the command set. Now I can PRINT FREE_MEM to show the remaining memory. JOBS shows the multitasking jobs, FSERVE starts the file server, ED runs the improved BASIC line editor.

The floppy drive, if it is connected, can be accessed from FLP1_ and the Compact Flash card is WIN1_. If the FLP1_ is present the QL will run the boot file from there.

With this amount of memory, a RAM disk starts to make sense. Multiple microdrive contents could easily be run from the memory. The default virtual drive is RAM1_ and again the Trump Card manual is your friend.

It's also possible to break out of the CF card boot basic file (SPACE+CTRL). This way I can have a peek at the WIN1_ drive from SuperBASIC without loading all the files into memory. The boot file can of course be altered to stop the commands from running next time.


Using HxC Floppy Emulator

The Compact Flash card does not show up on my Linux system, as the CF card is apparently in a format that can only be accessed with a Windows-only image editor and the QL itself. As far as I understand, there's no way to read/write files directly like you would with the mountable images inside a ZX Spectrum DivIDE CF cards. There's also probably no easy way to access the image file with Linux at the moment.

Well, I have my HxC Floppy Emulator. It took some steps to set up, though, so I'll put my notes here for future use.

The basis for the following is the document Using an SD Memory Card with the Sinclair QL, which contains information about the disk format parameters.

There are a bunch of Jumpers at the backside of the HxC. The organisation of these may vary from model to model, I have a boxed one with the pins bending backward. To make the HxC work with my QL, the jumper needed to be at the top left corner:

To get the HxC Floppy emulator windowed utility working on Linux, I followed these instructions exactly:

http://www.atari-forum.com/viewtopic.php?t=29580

(I have Linux Mint 18 Sarah 64-bit). The command line version does not seem to be sufficiently detailed to generate these kind of images.

After running the HxC Floppy Emulator, I followed the how-to document mentioned above.

Use settings to tick out "auto", and choose Generic Shugart, which probably is the default anyway.

At the HxC main panel, use Load RAW Image to get to the screen below. Configure the format according to the specifications from the "Using an SD card..." document, or follow this image at your peril.

I ignored all the parameters that could not be followed from the document.

I tried to generate an empty image with "Create Empty Floppy", but although the HxC accepted the image, the QL did not recognize it. (Edit: It might have needed formatting)

I then used Load RAW File to load an existing DD raw image that is based on an emulator file. This I did not create myself, but downloaded from a QL forum. It may or may not be available.

After OK'ing the result, it can then be exported from the HxC main menu as a .hfe file. Copy this to the SD card.

On the QL end, the HxC device is connected to the Tetroid. Turn on power for the HxC device. Select the hfe image. Turn on Sinclair QL. The drive is recognized as FLP1_ in SuperBASIC.

Phew...

Here I have powered the HxC from the 5V / GND pins of an Arduino, which has no other purpose here. When powered with an 9V adapter, the 5V output should have enough amperes to run the HxC. Powered from an USB, maybe not so much. Anyway this may not be ideal and I'll move to a PC power unit when feasible.


More

I once looked at an SD card reader device called QL-SD. This was a very cheap alternative, a replacement for a microdrive, including the Minerva ROM upgrade in the deal. However it also took out some memory away so for a 128K machine it was also a bit of a downgrade. Moving files from and to the SD was also not straightforward as the files were inside a disk image, again not so easily accessible from Linux.

The Tetroid interface also adds RAM and the floppy interface, an all Trump card functions, something the QL-SD did not offer.

Do these devices work at the same time? I have not yet tested, but I think there's no reason why not.

26.11.2017: Addendum

I inserted the TDI to my QL-SD equipped Sinclair QL, which has the Minerva ROM (JSL1) that came with the QL-SD. The TDI works nicely, and depending on the three TDI jumper settings, I can get one or two of the drives on-line, but never all three of them.

Jumpers on:
J1: Memory : SDC1_ is available
J1+J2: Memory + Floppy : FLP1_ and SDC1_ are available.
J1+J3: Memory + CF : WIN1_ is available
J1+J2+J3: Memory + CF + Floppy : WIN1_ and FLP1_ are available.

At least all drives can be reachable in some ways. With configuration J1+J2 I could move files between HxC and the QL-SD, and with J1+J2+J3 between the CF and the HxC.

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.

The Recreated ZX Spectrum

Just a quick note on the Recreated ZX Spectrum retro Bluetooth/USB keyboard.

Appearance

The designers have done a good job making the Recreated look almost exactly like a real Spectrum. Even the rubber feet and faux-heatsink holes are in a correct position. Obviously the backside is different from the original, because it's not a computer and does not have Spectrum connectors.

The inevitable comparison

On the surface, there are very minor differences. The Sinclair ZX Spectrum logo is embossed a bit taller and the angle for the elevated back is different. I have to appreciate they did not add any "recreated" or other new logos on the device. Maybe, just maybe, the metal panel bends ever so slightly due to the way it has been connected.

Having said that, it really looks like a Speccy. To me the surface matting, paint glossiness, key graphics - all are ok. It would be unfair to nitpick on the differences.

But how does it feel? It's not as heavy as the original, but the perfectionist might correct this by inserting some weights inside. (The case is held together by screws). The keyboard feels quite as it should, maybe the touch is just a tiny bit lighter. Am I imagining the keys have more tendency to bend at an angle when you press them? Acoustically, the key presses sound sharper and have more "echo" to them.

The keyboard is pretty much as atrocious as the original, which is a compliment here. It remains to be seen how much I can get used to it. I tried to type some of this blog post with the Recreated, but gave up after a paragraph.

Functionality

The Recreated is mainly intended to work with the Elite Systems' Spectrum app on the iOS appstore. My interest is in getting it to work with a PC, so I've not even tried the app.

A lot of effort has gone into enabling the keyboard to work on iOS devices both as a keyboard and a gamepad (not only for the Spectrum app) and as a normal PC-keyboard. However this means that at least currently it won't work directly in emulators as a 100% Spectrum-equivalent keyboard. For example, getting the " character does not result from pressing Symbol Shift+P, as it is mapped to shift+2. Perhaps if emulator makers accommodate, the Recreated will be a slightly better deal in this respect.

I was worried the keyboard might not work without batteries, but the included USB cable is sufficient, and I prefer this to wireless. Obviously the Bluetooth is the way to go with mobile devices.

One unexpected thing was the "unlocking" procedure, which you have to do to get the device to work properly as a keyboard. This is easily done online at the Elite systems website or through the app, but still to me this felt a bit of an added rigmarole. Fortunately the device appears to remember the setting.

Sorry about the weird angle but I was not going to dismantle it more for the time being.

Looking inside, there's a lot of free space. The battery holder means the case is not that easy to mod into a real Spectrum case, but it might be within the realms of possibility. Note though the keyboard membrane cables are different and come out from different places. Interestingly the designers have preserved the 5/8 (5/10 really) division and possibly the original membrane matrix. The usual RWAP replacement membranes probably cannot be used here.

Addendum: I checked if the plastic pieces are interchangeable with old Spectrum case parts. I found the Recreated bottom and old Spectrum top fit together somewhat ok, but not the other way round. The changes required could be minimal, though. This, of course, without the PCB inside. 

So, the situation is fairly good for projects that combine the Recreated keyboard with an old computer. 

An old PCB does not fit well inside the Recreated bottom, even if the battery holders were removed. There's a specific groove for the PCB in the real Spectrum case which does not exist in the Recreated. 

The red arrow points to the lacking PCB groove.

An Arduino fits inside without any changes, using low or bent cables for the I/O pins. A Raspberry Pi could just about fit there, if the battery holder is removed and care is taken in positioning the board.

All in all

If someone has decided to limit their Speccy-activities and game playing on a mobile device, the app+Recreated might be good combo. Text adventures and complex games are really crying for a keyboard anyway.

For a more involved retro hobbyist like me, it's harder to pinpoint a really good use. I have my real Speccies, and emulators do not greatly benefit from this keyboard because of the key mapping. It could have been nice for BASIC programming. It's kind of fun for games, though. I would like to connect it to my ZX Evolution, but it's a no-go because the Evo uses PS/2 keyboards.

A Kempston/Atari joystick connector would have added more value to this, but admittedly it's hard to see how it could work in a simple way. Cursor emulation?

The ZX Spectrum Recreated might be expensive, I maybe paid more for this than on any single retro computer I've bought (but then I'm a cheapskate) but I suppose that's not a major issue. It's not much more expensive than many specialist keyboards, although I'll have to repeat a ZX Spectrum keyboard, recreated or not, doesn't really work as a good PC keyboard replacement.

I'm positive about the product in the sense that this might mean more real ZX Spectrums in the future, now that there is a precedent for manufacturing the required physical parts. Time will tell...

More info:
http://sinclair.recreatedzxspectrum.com/

ZX Spectrum isometric

The item in question.

This is a look at isometric adventure-type games on the ZX Spectrum, where the genre originated and mostly thrived. They were popular in the mid-eighties, especially in the UK. Spectrum game development in the UK was relatively insular, so I feel justified in tracing all the influences back to Knight Lore and some of its more important imitators.

Brace yourself! There's going to be a lot of samey-looking 1-bit monochromatic graphics!

1984: The Beginning

Knight Lore introduced the whole "Filmation" concept. The Congo Bongo-esque player character could move around rooms, behind and in front of objects and act on them physically. The environment was dynamic: objects could be pushed around by players and monsters alike.

Knight Lore. Push those tables to reach the objects. 

This gave an impression of all things being treated equal within the game world, something not often seen outside Boulder Dash. Objects pushed over the edge fall, monsters change their direction when encountering objects etc. Dropping an object over a monster would create an ad hoc moving platform that could be occupied by the player. These were unprecedented elements in an action game.

1985: Ultimate holds the ball

Notable: Alien 8, Fairlight, Nightshade
Others: Enigma Force, Cylu, Chimera

Ultimate's own Alien 8 did little to alter the Filmation scheme, using the same engine with a sci-fi backdrop. Some rooms had a remote control for another drone robot, suggestive of the multi-character games to come. Nightshade introduced scrolling, but this was at the expense of more complex character-world interaction.

Left: Enigma Force. Right: Nightshade with scrolling graphics, from Ultimate

I'm listing Enigma Force here, even if it is not really part of the genre. The developers, Denton Designs, would also go about creating isometric games. This sequel to Shadowfire utilized a more direct frontal perspective, but it also employs the kind of depth-sorted masked graphics seen in isometric games. It is notable for its multi-character gameplay, speech bubbles and icon driven interaction, elements that would also re-emerge in other titles.

Cylu and Chimera are small games where the perspective element is simplistic compared to Ultimate offerings.

Fairlight, and then some more Fairlight

The most important game here is Fairlight. It eschewed the cartoon-style graphics of Ultimate games in favor of a more "naturalistic" views, built out of lines and fill patterns. Admittedly, the rooms had often less content than in Knight Lore, and the sprites were smaller. It also introduced a heavy dose of "what the fuck I'm supposed to do" style of adventure gaming, which depending on player tastes were either an improvement over Knight Lore or not.

1986: Floodgates open

Notable: The Great Escape, Batman, Fairlight 2, Movie
Others: Strike Force Cobra, Sweevo's World, Pyracurse, Gunfright, Rasputin, Nosferatu, Pentagram, Molecule Man

1986 saw a spate of isometric games released on the Spectrum. The developers had not only Knight Lore to look up to, but also Fairlight and Nightshade. Ultimate's own Pentagram seems poorly conceived in comparison to what was on offer. Gunfright, built on Nightshade's scrolling routines, at least offered an original wild west scenario. The 128k-only Fairlight 2 expanded on the first game, but offered little new. At least the forest environment showed that the rooms need not be made of rigid blocks.

The Great Escape

The Great Escape by Denton Designs was a different type of game altogether. The prisoner suffered a daily routine, which the player was encouraged to break at suitable moments in order to win the game. The Great Escape is an imaginative blend of adventure components with action elements in a clockwork world. The scrolling portions are more impressive than in Nightshade, though again the sprites are a bit tiny.

Left: Swift scrolling in Pyracurse. Right: Strike Force Cobra with some clever coloring.

Developers experimented with adding multiple characters to games, as in Pyracurse and Strike Force Cobra. SFC characters could crouch, jump and somersault, kick doors in, shoot machine gun in various directions and throw grenades. Sadly the environment was not that accommodating, as there was not that much to shoot or blow up. Certain puzzles could only be solved by co-operation of two characters. There was a hilariously detailed character selection screen, which as far as I can tell made absolutely no difference in the game.

Batman by Jon Ritman and Bernie Drummond, released by Ocean.

Building on the basic Ultimate formula, Jon Ritman and Bernie Drummond added graphical detail and little nuances to create Batman. Shifting the balance from jumping-oriented tasks to a variety of puzzles, Batman could offer a more honestly straightforward and at the same time more diverse game experience than other imitators. Batman needed to collect various items before he could even jump or carry items, and this modification structured and varied the game somewhat.

Left: Rasputin, Right: Nosferatu

Rasputin is a depressingly difficult jump-and-avoid game that makes use of the Enigma Force-style frontal perspective. Despite some impressive graphics, the game does not seem that well thought out. Sweevo's World did away with jumping altogether. The game is still quite three-dimensional, as lifts can be employed to move the character up- and downwards. The rooms are often self-contained puzzles that require careful object placement. Nosferatu is an uninspiring vampire hunt in a pretty static world.

Movie from Imagine.

Movie brought stylish graphics and an original storyline about 1930s gangsters. Graphic user interface, pistol shooting, melee fights, typed speech bubbles, free-roaming characters, thrown object "physics", Movie seemed massive back at the time. Yet the icon controls made the gameplay an excruciating experience. To throw a punch you had to enter the icon mode, select the fist icon and press fire. Ditto for firing the pistol. No key shortcuts either.

It seems 1986 brought a lot of sophistication to isometric games. However, ZX Spectrum games were often faux-complex, with sprawling empty maps and unnecessary objects to throw the player off the scent. One buzzword was "icon-driven", despite the fact most of the games would have worked better without. Isometric perspectives and graphic interfaces made good screenshots in magazines, but the games themselves could be surprisingly sparse.

1987: The genre starts to age

Notable: Head Over Heels
Others: 3D Game Maker, Bubbler, Martianoids, Hydrofool, Greyfell, Get Dexter

1987 saw both the pinnacle and the nadir of the isometric phenomenon. On the one hand we have the much-lauded Head over Heels, a game which took the best elements of Batman, scaled and revised into a tight puzzle-oriented game. On the other hand we have 3D Game Maker, an editor for creating formulaic, often substandard isometric games, which I will not name here.

Head over Heels

Head Over Heels combined a couple of good ideas that had been floating around. Isometric games were usually notorious for their sprawling maps, and the bit of episodic structuring HOH gave was very welcome. Sweevo's World had already introduced kind of multiple selectable "worlds", but these were simply different starting points that did not really compartmentalize the game.

Strike Force Cobra and others had shown that multiple character cooperation could add new types of puzzles. HOH showed restraint in having only two characters with genuinely distinct abilities. Thus, Head Over Heels tempered many past elements into a more balanced whole.

Left: Bubbler Right: Martianoids

Bubbler and Martianoids are not strictly isometric adventures, but should be noted as they were published by Ultimate. Bubbler is more of an arcade game (Like Marble Madness or Spindizzy) with fast scrolling and puzzle elements whereas Martianoids clearly follows Alien 8 with the standard Ultimate graphical flair. It plays on a flat landscape, though.

Hydrofool. Note that we are underwater now, playing that Gollum-esque character. A bit of a gimmick, really.

Hydrofool was a sequel to Sweevo's World. Even though the rooms are underwater, the character could mostly swim in a defined flat "plane", which sort of makes me suspect it's Sweevo's World all over with just overhauled graphics.

1988: The last significant isometric Spectrum games

Notable: Inside Outing, Where Time Stood Still, La Abadia Del Crimen (The Abbey of Crime)
Others: Phantom Club, Super Hero, Last Ninja 2

1988 saw only very few inspired isometric games. The super-hero themed Phantom Club is worth mentioning mostly because it was authored by the same people as Movie. Despite good running-and-somersaulting animation and improved technical routines, the result is not as inspiring as Movie. Last Ninja 2 was converted from the C64, skipping the first part altogether.

Left: Detailed scenery in Inside Outing. Pretty much everything can be moved. Right: Phantom Club boasted some bold color choices.

Inside Outing is another conversion from Amstrad. The game has a thankfully simple goal of retrieving a bunch of diamonds inside a crazy mansion. Rather than go for a huge amount of empty rooms, the spaces have an unprecedented amount of objects which all interact.

The screen update is still fairly fast, boasting some sophisticated isometric routines. It looks better on Amstrad/C64 - with colourful graphics - finally showing that the Spectrum might not necessarily be the only platform for the genre.

Left: La Abadia Del Crimen. Right: Where Time Stood Still

Where Time Stood Still is a kind of successor to the The Great Escape, and although aficionados would be satisfied, one could say it was mostly same old. Much like in Denton Design's earlier effort, Enigma Force, there are four player characters crash-landed into a hostile environment. Icon control, speech bubbles, food/fatigue levels, arcade action and whatnot. Although a technical tour de force for the 128k Spectrum, the game is surprisingly devoid of content.

From Spain, the Umberto Eco-inspired La Abadia Del Crimen is also an adventure game, again more comparable with The Great Escape than any other game, what with the daily routine in an isolated environment. I have not looked much into it though, but the Spanish-speaking speccy world holds it in high regard. For the English speakers, there is an unofficial translation, The Abbey of Crime.

It's all a matter of perspective

After all the imitators and seeming improvements, it is striking that Knight Lore/Alien 8 actually did most with the "new" perspective. These games had functional jumping, avoiding and route-planning based on three dimensions rather than two. The puzzles required object placement and retrieval, again thought out in 3D. Newer games could modify these elements, but would not deviate from the basic formula. And if they did deviate, it usually resulted in making the perspective less meaningful, reducing it into a visual gimmick.

When the 16-bit computers hit big time, the isometric genre was seen as decidedly 8-bit and was not tried that often on the bigger computers, just as the whole British style arcade adventure died a quiet death. Sure, many games utilized the perspective but were not part of this action adventure genre. When polygon graphics became feasible, games like Tomb Raider and Super Mario 64 could offer similar thrills without locking to a particular perspective. Perhaps something of the DNA of the isometric lives in the modern 3D action game.

Genre stupidity:

-Four way controls in an apparently free 3D environment? Urgh!

-Randomly moving enemies. Holy hell, the games are difficult enough as they are.

-Huge slowdown. When the going gets tough, it gets tough on the framerate.

-Faux complexity. Empty rooms, clunky interfaces, non-functional objects, sterile characters.

Genre greatness:

+A sense of mystery and exploration based on visibility and "locked out" game areas

+Fun experimentation with the physical object behavior and the game world

+Clever and satisfying puzzles enabled by the isometric object engine

Sinclair and the 'Sunrise' Technology

The book Sinclair and the 'sunrise' technology from 1986 is an account of Sinclair's rise and fall in the micromarkets in the 1980s. The book is written sufficiently late to include every noteworthy Sinclair project, yet early enough to be truly contemporary. (The Cambridge Z88 came later, for example.)

It is an interesting document of the struggle to acquire the money, know-how and resources that enabled the eventual production of the Sinclair home micros. I was surprised how small Sinclair's companies actually were. Clive arose from mail order analog radio equipment and amplifier business, DIY geek stuff basically. The book maintains that professional advertising and Clive's calculated presence helped nurture an image of a vastly more competent and large-scale operation than it really was.

The text is sufficiently well researched, although sometimes it seems only a few key interviewees supply the most crucial characterizations. What seemed less professional is the way the authors appear to constantly take small swipes at Sinclair. The authors are intent on showing the machines were not a result of Clive Sinclair's direct involvement, yet at the same time point out that the bad details in them (e.g. membrane keyboards) were a result of Clive's single-mindedness. This is already somewhat contradictory. Many of the products' shortcomings relate to the design insights that made the products possible in the first place.

There seems to be slight misrepresentation about the relation of design briefs, the broader conditions and constraints that inform the outcome and the "actual designing" of the technical work. This does not mean that Clive designed or invented the products - yet outcomes are a result of a broader landscape within with the engineering and industrial design choices were made. Clive's personality and business goals, for good or for worse, were instrumental in setting the engineering and design targets.

Funnily, Clive is lambasted pretty much for what Steve Jobs has been lauded for: being a shrewd, vocal and single-minded in following his visions. The difference is that from the viewpoint of big business, Steve Jobs succeeded and Clive Sinclair failed. However, as the book lays it out, it was never really Clive's fate to succeed in a big business way.

When belittling Clive's achievements, it can be asked what would have happened if Clive Sinclair had not arrived at the scene at all. Reading between the lines, the authors think it might have been better for the industry. Clive and the Sinclair brand filled a void at the time: The UK "wanted to believe" there was a new field in which the nation could excel and compete. To the authors this was largely an illusion and Sinclair's worst crime was to undermine UK investors' trust in an emerging field.

At the broadest the book is a critique of Thatcherism, using Sinclair's failure as an example of misguided policy of supporting small companies as a cure to a dwindling economy and unemployment. In fact, seeing Sinclair's career as an instrument of Thatcher's policies is the most troubling outcome of the book to this politically naive reader/speccy fanboy. However, this may also be a bias in the book. Clive's relatively small-scale dabbling in technology might also be seen as a-political.

The Sinclair products, despite their failures were quite indicative of the gadget life the 2000s would eventually become: mobile screens (the flat-screen TV), laptops (tiny computers) and electric transports/scooters (C5). However, as the landscape and infrastructure for such products did not exist, the Sinclair inventions remained rather isolated and superficial demos of what might be. Nevertheless, there still remains a certain prophetic aura about them. It's not that any one of them is particularly novel, but taken together they give an impression of some un-realized Sinclairlandia that never came to be.

As the book suggests, Amstrad is probably the real success story of British computers, but here I must also say that Amstrad is somewhat boring. Who cares about Alan Sugar? Many of the computer legends were quite unmemorable characters. I'm not saying the spectacled red-head was a great role model or a hip character. Yet he and his products brought a kind of color to the otherwise drab field. Thus, "print the legend", I say.

(Thanks to Markku for the book. Here are his views in Finnish.)

Ian Adamson and Richard Kennedy, Sinclair and the 'Sunrise' Technology. The Deconstruction of the Myth. Penguin Books.