ZX Spectrum and ChatGPT

I used ChatGPT (free version) to create a ZX Spectrum BASIC quiz game. I did not adjust the code afterwards at all.

I saw a few attempts at using ChatGPT in the ZX Spectrum Facebook group, where the consensus looked like "impressive, but we're not there yet". The LLM had failed to understand the Sinclair BASIC dialect, so although the logic of the simple programs could be sound they would not run on a Speccy.

But I figured, well, ChatGPT can be instructed to avoid the mistakes?

What I set out to do is a quiz game where the computer gives a name of an U.S. president, and the player has to know or guess when he was first elected.

I first made ChatGPT produce a list of presidents and the election year. As the result had some ambiguities and complexities, I asked to simplify the list so there are only first-time election years and no problem cases.

Then I asked it to format the list into ZX Spectrum DATA statements, starting from the line 1000, with 10 increments.

Only after seeing this list was formatted correctly, I asked ChatGPT to prepend the list with a Quiz-type BASIC game.

Although you can ask ChatGPT to use ZX Spectrum BASIC, this is not enough and the result is likely to be more generic BASIC dialect.

So, it is better to give a set of iron rules. Instead of trying to teach the peculiarities of Sinclair BASIC, I simplified the orders further, to avoid getting ChatGPT confused or produce something that would be difficult to debug. For example, dimensioned strings could be difficult to handle, as they work differently in the Spectrum.

bas2tap converts plain text listings into a Spectrum emulator TAP file. It's quite pedantic (i.e. accurate) so some of the rules below address this issue too. Bas2tap is an important tool as otherwise it would be too slow to test the listing, now I can just copypaste the ChatGPT output to a text file and run a command from terminal.

So, after outlining the game program, I told ChatGPT:

Remember that ZX Spectrum BASIC follows these rules:

-Use only one-letter length for variable names, and dimensioned variable names.

-Do not use IF-ENDIF reaching on multiple lines. Each IF-THEN part must only happen on one line.

-Do not use END. Use STOP instead.

-When assigning a (non-dimensioned) variable, you need to explicitly use LET

-When using GOTO or GOSUB, use GO TO and GO SUB instead.

-Do not use dimensioned strings. This could be achieved by looping and reading the DATA list for each  item. e.g. RESTORE can reset the reading of the DATA list.

-The first element of a dimensioned array is 1, not 0.

You could also forbid it using RANDOMIZE, as chatGPT may use it to reset the random seed, which is not really necessary.

That point about dimensioned strings and data lists is only relevant if the program has to go through a data list in the first place.

The game itself is quite silly, as I gave rather silly instructions to ChatGPT. You get to guess presidents, but if you fail it will tell you the year. The game ends if you guess one president right. Well, that's not a huge problem.

The way the program works is also a little quirky, but this too is to be blamed on the instructions I had given to ChatGPT. The program stores the year values to an array, but not the names. So it will have to scan the DATA statements again to get the name.

What I liked most about this exercise was how I could populate the data table so fast and easy, making a potentially boring task a wheeze. Granted, a list of presidents could be googl-eyed, or acquired from Wolfram Aplha, but there's still dullness in cleaning up and reformatting the results to DATA lines suitable for the limitations of this particular listing.

The listing: (Ok I did remove line 10 that had the unnecessary RANDOMIZE)

20 DIM Y(40)
30 PRINT "PRESIDENT QUIZ! GUESS THE YEAR A PRESIDENT WAS FIRST ELECTED."
40 LET S=1000
50 RESTORE S
60 FOR I=1 TO 40
70 READ A$, B
80 LET Y(I)=B
90 NEXT I
100 LET Q=INT(RND*40)+1
110 RESTORE S
120 FOR I=1 TO Q
130 READ A$, B
140 NEXT I
150 PRINT "WHAT YEAR WAS ";A$;" ELECTED?"
160 INPUT A
170 IF A=Y(Q) THEN PRINT "CORRECT! WELL DONE!": GO TO 200
180 PRINT "WRONG! THE CORRECT YEAR IS ";Y(Q)
190 PRINT "LET'S CONTINUE.": GO TO 100
200 PRINT "DO YOU WANT TO PLAY AGAIN? (Y/N)"
210 INPUT B$
220 IF B$="Y" OR B$="y" THEN GO TO 100
1000 DATA "George Washington", 1788
1010 DATA "John Adams", 1796
1020 DATA "Thomas Jefferson", 1800
1030 DATA "James Madison", 1808
1040 DATA "James Monroe", 1816
1050 DATA "John Quincy Adams", 1824
1060 DATA "Andrew Jackson", 1828
1070 DATA "Martin Van Buren", 1836
1080 DATA "William Henry Harrison", 1840
1090 DATA "James K. Polk", 1844
1100 DATA "Zachary Taylor", 1848
1110 DATA "Franklin Pierce", 1852
1120 DATA "James Buchanan", 1856
1130 DATA "Abraham Lincoln", 1860
1140 DATA "Ulysses S. Grant", 1868
1150 DATA "Rutherford B. Hayes", 1876
1160 DATA "James A. Garfield", 1880
1170 DATA "Grover Cleveland", 1884
1180 DATA "Benjamin Harrison", 1888
1190 DATA "William McKinley", 1896
1200 DATA "Theodore Roosevelt", 1904
1210 DATA "William Howard Taft", 1908
1220 DATA "Woodrow Wilson", 1912
1230 DATA "Warren G. Harding", 1920
1240 DATA "Calvin Coolidge", 1924
1250 DATA "Herbert Hoover", 1928
1260 DATA "Franklin D. Roosevelt", 1932
1270 DATA "Harry S. Truman", 1948
1280 DATA "Dwight D. Eisenhower", 1952
1290 DATA "John F. Kennedy", 1960
1300 DATA "Lyndon B. Johnson", 1964
1310 DATA "Richard Nixon", 1968
1320 DATA "Jimmy Carter", 1976
1330 DATA "Ronald Reagan", 1980
1340 DATA "George H. W. Bush", 1988
1350 DATA "Bill Clinton", 1992
1360 DATA "George W. Bush", 2000
1370 DATA "Barack Obama", 2008
1380 DATA "Donald Trump", 2016
1390 DATA "Joe Biden", 2020

ZX Workstations

Perusing some earlier Your Spectrum and Sinclair User magazine adverts from 1983-1984, I came across all kinds of funniness.

Joysticks that are not really joysticks, joystick adapters, programmable joystick adapters, a joystick that works, computer stands, Microdrives, Wafadrives, sex drives, keyboard replacements, keyboards, keyboards with space bars, computer stands, wobble stoppers, custom keypanels, Sharp computers, amplifiers, echo amplifiers...

I kid you not.

But I'd really like to focus on one particular object type, a product that will turn all your loose home computer gear into a "workstation".

You see, the Spectrum had the main unit, the power supply unit (no power switch), a tape deck, a printer, TV, joystick adapter, joystick, and all these had wires going this way and that. Plus you would have loose tapes and whatever lying around. Some organization might be needed in any case.

Also, it gave an opportunity for companies less focused on electronics or software, to participate in the great ZX Spectrum boom.

These workstation gadget items could be considered as a forerunner to the laptop "dock".

I'll also look at a related product idea that attempts to make the gear more portable. Which is a bit less like a dock I guess. But anyway.

I'm not super-interested in computer tables here, but I'll give this one a pass for warming up the theme:

This perhaps best explains some of the reasoning behind these products. In early 1980s it was not yet a given that people could curl together with their favourite electronic gadget for most of their waking time, so there was this quaint idea that a computer could "gather dust", or be an eyesore "when not in use".

Rotronics (of the Wafadrive fame) have produced a sexy-looking setup, and it's the insert that gives the hint that this could also perform as a workstation.

For the mobile worker, that emergency cut-down toilet paper roll must come in handy.

A company called PAS had a somewhat similar product, but I can't see how to remove that cover so I'll give points to Rotronics here.

Also, it seems they failed to name their product, although "The Rotronics Portable Case" was not such a great name either.

(I realise these kind of cases can be bought nowadays, often with a customizable foam-plastic type array inside.)

Now we're getting to the proper workstation territory. Also, talking of great product names, I almost thought this was called the Space (Saver) Station. However, FORCE ASTRO is almost as good. I think that with this setup, any kid would have felt they were operating the Skylab.

I'm pleased they've taken ergonomics to a point where it addresses the accommodation of the computer to this self-contained unit. The integral reset facility speaks in favor of this product, too, as "now you can leave your equipment permanently set up and beautifully protected". There's also acres of space inside, I really don't know how they did it.

A Kelwood advert shows not one, but two variants on the theme. First is the Microstation, which seems also a concept for moving the setup around, as the telly is not on top of it.

In fact the display is a bit far away, behind that wall of urine samples holders and what looks like a brick-sized power switch. Ok, another ad shows in more detail this concept of different "stackpacks", but damned if I could understand what they do.

The second setup is the Kelwood (almost) Wireless Workstation, which as a product name almost delivers the promise of the Space (Saver) Station. The workstation is not particularly more wireless than any other product on this page, though. It's just a marketing choice to focus on that one particular feature. It's also not as Spectrum-specific, and comes with accessories of its own.

They too promise acres of room for all peripherals, which seems a bit of an exaggeration. Possibly it would have been better to promise (almost) acres of room. The rhetoric and graphics tells me this has something to do with the FORCE ASTRO workstation.

One more naff looking ad, one more space-organizing product:

TTL had the audacity not to call it a workstation, but instead a "desk console", and it seems to deliver all the usual goodies. It's worth noting some of these products offer a way to switch between LOAD/SAVE states for the tape recorders. I guess it was not possible to have both mic and ear cables connected at the same time.

Here's another "console". In case you thought these were expensive, fear no more:

Forerunner of IKEA, they've chosen corrugated board as the material of choice. I can believe this would keep its sturdiness for a better part of a decade. That angle could really come in handy when typing on the good ole rubber keys. If only it had a monitor stand.

The pinnacle of all ZX workstations, is the ZX Workstation. No bullshit, no nonsense, no space-saving tricks, no almost wireless, and no acres of room. It will raise and tilt the TV for better viewing, and angle the computer for easier typing.

Afterwords

There were more of these, I simply chose the more visual ads.

On a bit more serious note, I guess these could have been somewhat attractive for a person who couldn't build a comparable setup. I also very well know how much damage the PSU cord could get on a loose speccy, so helping that problem alone might have made these worthy products. My dad built something similar from a loose garden table so who I am to laugh.

A fun thing is that many of these were soon less than useful as the ZX Spectrum+ form factor would not fit the more spectrum-specific designs. I also suspect Interface I/II might already be a bit tight fit with some.

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

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.

XORin' in the Free World

One day, I thought it might be possible to re-create my Fort Django on the ZX Spectrum. I abandoned this exact goal as there's not that much material that can be re-used and some of my findings discouraged me from this route.

Instead the code became an exercise in game sprite graphics. I wanted to have three huge-ish characters on screen with a smooth framerate, with a game that would again float somewhere near the Saboteur!, Bruce Lee and Dan Dare territory.

I decided on XORed sprites, so I don't have to do masks. XORing graphics means that the underlying pixels are inverted with the sprite pattern. It's a nice method in that with XOR the sprite drawing and erasing routines are exactly the same, because re-drawing on the same position leaves the screen as it was before drawing.

Granted, it can look a mess whenever the sprites overlap. Many complained about colour clash in ZX Spectrum games, but I guess XOR was partly to blame, too. Atic Atac is maybe the best game that uses the XOR approach, and it's very fast.

Early days. Using sprites adapted from Fort Django

I needed to plan the graphics and the game around the XORing artefacts, so it would not get too bothersome. This was the reason to move away from the Fort Django concept, as the ladders and furniture might create too many disturbances around the moving, overlapping graphics.

Another weird technique is to draw the sprites when entering the frame and erasing them on the way out. With a Commodore 64 you could simply check for the suitable scanline, but with a ZX Spectrum this is not possible. I'll simply have to ensure that each frame still does the same things even if there are no enemies on screen. This also means the game is fixed for the 3.5MHz timings. Such an approach is not very elegant nor portable, but it's justified to get a silky-smooth game in a closed environment that the 8-bit computer is.


The sprites, actually

Although XORing is a fast technique, I still had to revise my approach a bit. My initial target of 40x64 sprites with smooth framerate were clearly out, so I went for 40x48 instead, which is the size of the Saboteur human characters.

I can't even have true 40x48 sprites, but by doubling the vertical pixel size it is possible. Not only are the pixels doubled, but the underlying vertical screen resolution needs to be divided by two to make the XOR draw/redraw logic work. So I'm working with 256x96 screen with 1x2 proportioned pixels.

Drawing one "line" of the sprite data as 1x2 pixels.

This has the benefit that as I fetch the sprite graphics, I can assume the two subsequent screen line contents are the same, so the routine does not have to read them separately.

The sprite graphics are drawn from left to right, zig-zagging the two lines. The stack is pointed to a table that has the vertical screen addresses sorted out for every other pixel row coordinate, and these addresses are pop'ed for each sprite line. The horizontal component of the address needs to be added, too.

1x2 pixelled sprite data pictured in GIMP, with one data line highlighted.

The sprite Y-coordinates are also constrained to multiples of 2. This has the benefit that there is never a troublesome screen address boundary between the zig-zagged vertical pixel rows. Within the line, the zig-zagged pixel row can be changed with just incrementing or decrementing the address high register.

Other good things came out of the 1x2 pixels: Instead of needing 256 bytes for each sprite frame, I could fit a graphic frame inside 128 byte boundaries. The 40x64 sprites would not have fit in a 256-byte boundary anyway.

The pixel ratio is not that limiting, as the sprites can be drawn deal with it rather than stubbornly make something that does not fit. My current sprites are hardly the pinnacle of ZX graphics, but it looks promising. And of course the screen portions where the sprites are not drawn, can be in 1x1 pixel format.

Toying around with some gfx pretty much ripped from Dan Dare.

With this tweaking of the resolution I could draw apparent 40x48 pre-shifted pixel areas three times, after which the scanline is at the 16th line of the Display File. This would mean that a moving sprite at the top of the screen could become distorted.

I could use a portion of the screen for a dashboard, as in the image above, and these 16 lines might not matter. I am making a game after all, and not a generic sprite routine.

But then the silly me realized that if the sprites are drawn in a certain order, the scanline intrusion can be made nearly meaningless: If the first sprite to be drawn is at the top of the screen, the second at the middle of the screen and the third in the bottom of the screen, all happens smoothly by "racing the beam". I only have to take care that not all sprites move near the top or bottom at the same time.

The diagram below shows what happens during one frame. These are not based on actual values, the picture is exaggerated for clarity. In this example only the second sprite is truly both a: drawn before the scanline enters the pixel drawing area, and b: erased after the scanline leaves the pixel drawing area.

This brings certain limitations to what can be performed with the sprites in the game. For example, only the player character has full freedom to move all around the screen, whereas the other sprites would stay within invisible "cages". Yet these cages are so lax that by switching sprite positions these cages do not matter much.

Technically, it would even be possible to draw more sprites than the three, if the sprite drawing order is well managed. This is somewhat equivalent of multiplexing sprites on computers that have real sprites and good scanline routines. But I felt this might become a bit too complex programming exercise or limit the "cages" a bit too much.

So, there are now three "big sprites" and the player sprite is always the second sprite to be drawn. The game, whatever it might be like, has to be designed around the small limitation that the enemies can't go everywhere.

Animation frames were another source of trouble. I wanted to save frames by "baking in" the leg motion inside the shifted frames. But this produced too fast animation. So instead of four shifted frames there would be eight sprite frames for simply making the guy walk on screen. The eight frames make a total of 1K graphics laid out in 128-byte address boundaries.

What else? I didn't make a clipping routine, even if it's not too slow to check the coordinates and divert to another sprite drawing routine. I wanted to negotiate some programming time out of this project.

Dude, where's my game?

So, after making the to-hell-with-portability sprite engine, I could concentrate on the game. All I've made since the sprite routines is a tile-drawing/collision routine, a bit more joystick stuff and experimenting with ways to draw unobtrusive objects. It looks nice, but currently a bit limited for a proper game. I'll get back to this in some form, but it doesn't seem to happen anytime soon.

Icon driven

When Apple Macintosh made a splash on the computer scene with its mouse/icon desktop interface in 1984, the occasion had a curious side effect. Software on humble 8-bit computers such as ZX Spectrum and C64 started to feature icons too. Not only utility programs but games were suddenly adorned with an interpretation of the WIMP (Windows, Icons, Mouse, Pointer) approach.

Of course, graphical interface elements had been hanging around for a while in different forms, but the Xerox Parc/Apple approach was the one that became, er, iconic.

It was exciting to have a peep into an icon-driven windowed environment on your cheapo Speccy or C64, as a Mac would be a very expensive ride. It makes me think that early 1980s home computer games were not only entertainment but demonstrative showcases of computer tech you could not otherwise have.

Here I've tried to include some of the more important, curious or representative icon-controlled games from this early period. Sometimes it's hard to distinguish the boundary between "icon-driven" games and point-and-click adventures, and I've only tried to include the most interesting borderline cases.


Alien

Arguably, Alien might not have been that much influenced by the Mac phenomenon. It is more reminiscent of earlier graphic CAD workstation displays, with a schematic plan main screen and text-based menus at the side. You don't have a floating cursor but menu items are highlighted. So, in effect the game can be played with two keys.

You are in control of multiple characters, and actions are afforded depending on whether there are exits or objects present. This is pretty much a semi-real time adventure game with rooms, items and locations. On occasions you may be presented with a graphic depiction of the Alien or Jones the cat scuttling across the screen. These incidents can be pretty startling, despite the primitive graphics.

As the scenario plays in real-time, icons serve better than text-based commands. It would be rather unfair to punish the player for slow typing speeds... Also, the relevant commands need not be remembered as they are displayed on screen.


Shadowfire

On the heels of Alien, Shadowfire was one of the earliest successful icon-driven 8-bit games, where the graphical environment was used as a selling point. Here, as in many games, the icons largely replace text adventure-style commands, for example using a combination of "pick up" and afterwards the icon for the object to be picked up.

The icon screens work pretty smoothly, but the arrangement is where the age shows. You need to click "computer" screens to get to the movement, battle and inventory screens and these computer icons are only differentiated with color. Some icons are puzzling initially, with added detail where a simpler graphic might have served better.

In hindsight it would seem obvious that a half-formed action could be cancelled by clicking the already clicked icon, but instead you have to go and select the "back" icon.

Even though the icon system is very slick, moving and managing six characters around a large map becomes a daunting task, constantly switching between screens and character selection. It's mind-numbing, and I start to wish there was at least a short-cut key to each character.


Enigma Force

This sequel to Shadowfire used the same icon system, but the main game plays in a real-time arcade adventure type screen. The complexity of Shadowfire is reduced, with only 4 main characters with 4-direction movement. The icon layout now scrolls when the cursor is pushed left or right, giving a more streamlined set of actions than in Shadowfire.

The characters can be given pre-programmed motion instructions, should you know before-hand how the map lays out, that is. There's also a "mind control" icon that allows direct control of a character via joystick.

The icons themselves don't look that much clearer, and in addition to the "back" icon there is also an "oops" icon to remove actions from the queue.


Aliens

Aliens from Electric Dreams took game elements from Alien/Shadowfire/Enigma Force, transforming the influences into an intense semi-first person action adventure.

Not an icon controlled game, though, which is just as well. The lineage and a game screen layout that is suggestive of multi-window environment makes the game worth including here. Perhaps it started to dawn on the designers that certain things were better done with keyboard.


Fourth Protocol

A Frederik Forsyth tie-in, the game is visually very reminiscent of the Apple Mac environment, but in motion it is a quite simplistic interpretation. The pointer does not move freely but is switched between icons, much like in Alien, opening up iterations for your decision tree.

The game is in reality quite text-heavy and at points you have to type in names and numbers. As the game opens you find yourself reading files and memos, assigning watchers to potential cases and getting reports out of them. Later on you go on a physical-world adventure which is extremely minimal in its descriptions. (i.e. "Victoria, Tube Station, Ticket Office")


Mission Omega

A very complete implementation of a windowed environment with drop down menus, the game could even be played with a mouse. The Commodore 64 version is especially nice-looking, but it's also imitating the Mac interface very heavily. The section where you build your droids is impressive.

After this section, I have to say the game content is rather minimal. You move around in a boring maze, giving orders to each of the robots.


Star Trek: The Rebel Universe

Admittedly, this is a 16-bit game, but it also appeared on the Commodore 64.

This is a complete icon-controlled game, without any drop-down menus or much text for that matter. One interesting idea is that multiple roles of the Enterprise crew are shown as mini-screens around the main screen, again something you might have seen in a CAD program.

Something similar was on the drawing board of the Electric Dreams' Aliens game. Sadly the Star Trek screens don't update in any real time, but that might have been the goal at one time.

There's something left of this idea in how further option screens come available as character screens are opened. Bringing these out (solar system, engineering, star chart) re-customizes the surrounding screens, but arguably these are just big icons.


Stifflip & co.

A very bog-standard example of an icon-driven adventure game, showing some elements of a nascent "point'n'click" adventure: the characters are shown on-screen. The humorous and big graphics makes Stifflip more memorable. The aesthetic has more to do with comic strips and silent movies than with Apple Mac.

Much like with Fourth Protocol, it's more of a graphic multiple-choice game with windowed sub-selections, and you'll be picking actions from text-based menus a lot.


Icon Jon

An obscure Amstrad CPC game that plays something like the Magic Knight games but the icons are more visually defined (and Apple style).

The game is controlled using a set of icons but also has computers, computer architecture and programming as the topic of the game. Bit like in TRON, the game depicts life inside computer circuitry. You can pick up and manipulate items and 'chat' with the cast of characters.

The title and game idea goes to show how intense the whole icon phenomenon was at the time.


Zoids

Four command icons placed around the main radar screen. As activities take place, new windows "pop up" around the screen with live sequences and further information. The windows "multitask" to some extent, so not all action stops just because you choose an icon.

You control a smoothly moving cursor, much like in Shadowfire. On occasion the Commodore 64 goes full on with the window overload, as every action seems to bring up multitudes of windows for iterating your action. The ZX Spectrum version is less impressive.

Saboteur II - The Avenging Angel remake

The saboteur, doing her sabotage.

After the excellent Saboteur remake for web browsers, Clive Townsend, the author of the Saboteur games, has released a similar treatment of Saboteur II - The Avenging Angel.

I waited for this release with mixed feelings. On 8-bit computers, Saboteur II from 1987 felt less good than the original. Slow, giant-size map with repeating rooms, difficult and random fighting. This type of opinion was also echoed around the 'net, so I never really found myself back with the game.

Even then, I also felt that on certain points, the sequel was an improvement over the first Saboteur game. You can select your own entrance by dropping from the glider, and you can sneak a bit around the building and not only inside it. The jumping is much more fluid and there are no frustrating jump sections. The ninja can do a satisfying somersault which has more subtle uses than in the first game.


The Saboteur II remake

Enough of that, what's the new game like?

With the Saboteur 1 update, Clive had done an excellent job of enhancing the outcome without altering the game play inside the original game area. Here I was worried that the second game could not work without fundamental changes.

Now that the game is faster and there is more to see, I'm happy to say Saboteur II becomes much clearer and better without any real alterations to the game core. For example, now I finally see that the different missions encourage taking different routes within the complex, whereas Saboteur I was bounded to the one back-and-forth journey with variations.

An example of the kind of attention to detail that has been put in the new graphics.

There's more visual detail, locations and "intel" points and achievements where you learn about the background of the complex. Another nice added detail is the enemy energy bar, which is also shown alongside the player energy. Although it confused me a little at first, this makes the fighting rules more clear and easier.

The missions and some game play aspects have been tweaked. I see the items are no longer placed in "stashes" of multiple items, and the code locations don't have items in them. This is a reasonable streamlining as there was no real benefit from the stash system. A tiny difference is that the missions are now properly locked away, and you can't use a code from a magazine to unlock them :)

As with the previous remake, there are also added game screens and plot elements, which are here revealed in a more piecemeal fashion. After completing a few missions you'll discover there are doors that lead to new rooms... and yes, there's also a new section after all the effort and that's all I'm going to say for now. Let's just say I like the way the new narrative unfolds. Just take heed of all the intel and achievement notes and you'll get an idea what you might be missing. Also, the background in the loading screen is a map, too.

The Amstrad CPC style shows Nina as a redhead!

But it is difficult at the very beginning! I died a dozen times in the first few screens when I started out, but after this initial frustration I took a deep breath and looked at what was wrong with my play style.


Some playing tips

For absolute beginners I'd recommend avoiding the androids, running away from them, or finding routes where you don't have to engage them. This way you can get a better feel of your way in, out and around the complex.

Eventually you have to learn to fight, ninja-style. Nina can do more fighting moves than her brother, but I'd suggest using the flying kick (run + fire) as the primary form of combat, as you can at the same time distance yourself from the androids and keep on fighting. A flying kick followed with a punch can be a devastating combo, but you need to get the rhythm of the fight correct. The crouching kicks are good for the pumas.

Serious moonlight!

The thrown items are as good as one kick, which can make the difference between life and death in some places. Ideally, throwing an item followed with flying kick+punch will destroy an android extremely fast. Got to appreciate the new splintering effect when throwing stuff at the androids!

Situations where two androids are close up can be dangerous. At places, you need to clear yourselves "home space" before climbing up or down a level, because you can't rest while on the ladders between two floors.

As in the original Saboteur 2, there are also some "silly" points where you can rest. These are spots the androids won't enter, despite what logic might say. Take note of such places.


The Avenging Angel

To me this release is just as good or better as the Saboteur! remake, but for slightly different reasons. I appreciate the way the game is able to enhance and finalize Saboteur II: The Avenging Angel in a way that makes me say this is the game it ought to have been, or always was in its heart. The added material, different graphic modes, various music tracks and other improvements here and there make it so much more. I can only hope Saboteur III will be made, combining the best elements from both games.

Get the game(s) from here

My thoughts on the Saboteur! remake here

Saboteur! remake

How it all began...

I've always been a fan of this atmospheric ninja/industrial espionage game released in the 1980s on ZX Spectrum, Commodore 64 and various other platforms. Now I'm looking at the recent (2015) version of Saboteur! at clivetownsend.com, from none other than... Clive Townsend, the original author.

Based on Unity/WebGL, it runs happily on a modern browser.  Before I say anything, I'd urge anyone who finds the game working on their computer to simply go and pay the small fee for the full game. Especially all those naughty people who played the original Saboteur games for free back in the day :)

With remakes of old games, I often feel that any changes to the original seem "wrong". Nothing like that here. The original central gameplay is intact. There are simply visual and especially aural improvements that make the experience of revisiting Saboteur more interesting. The game has also been expanded greatly, which I'll discuss below.

There are various options that need some attention before playing seriously. You'll have to sign in to get the full game, but as a bonus you get to save your highscores, achievements and other progress to your online account. As for the options, the game was initially set as "fast", but I found the "normal" speed most satisfying at least for now. The QAOP keyboard controls are satisfactory. The ninja moves with arrow keys too but the QAOP gives a crisper response at least on my computer.

As the game replicates the original, the controls have not been updated in any way. Especially the jumping sections may put off people who are used to more fluid, console-type games.

The menu graphics are all new, high resolution, but the game graphics are Spectrum-like, and boldly so. You can also select C64 colours if they are more to your taste. I wouldn't have blamed the author for changing the graphical style altogether, but it's good to have the ZX Spectrum style pixeling here.

Guess which mode?

Well, there are in fact more graphics modes than the ZX/C64, but they have to be found in-game and they only work in the original warehouse area. Making them work was not 100% obvious, so here goes: After you've found the different "VR goggles" in the expanded game, start a new game from the beginning, then press ESC to get to the expanded graphic mode options.

However, even the ZX and C64 modes are not identical to the originals: there are tiny updates and added detail here and there. The new grenade explosion is pretty mighty.


The New Story

Like many players, I didn't know that blowing up the bomb was not enough to truly complete the mission. The disk has to be retrieved, too. Then it gets interesting. After you think you've completed the mission, there's more to do but I won't say anything about it here in case someone is a newcomer.

...Well, ok. I have to say something. What unfolds is a completely new Saboteur adventure, which is more modern, storyboarded kind of game. There's more to read, for instance, as the ninja communicates with the radio dispatcher, Metal Gear style. The style stays true to the 8-bit limitations, it's just as if the Speccy had a huge amount of memory. Even if I suspect some scenes would not run on a standard Spectrum the effects never go overboard.

We're not in Ninja Kansas anymore

The new area deviates a bit from the "one item held" logic of the original, as you can now possess keys and other quest items. Also, the map is no longer strictly two-dimensional as you can enter from front and back of the screen to different sections of the map. There are quest-oriented sections and then time-based map areas that are more reminiscent of the original Saboteur game. There are also jumping areas that make me pull my hair out in frustration, like I was ten years old playing Jet Set Willy. Maybe I can blame the keyboard here!

There's now more to do, new enemy types and behavior, more switches, keys and moving mechanisms to set and reset. There's also a lot of detail and humor, such as winks and nods to 1980s pop culture, ninja schlock and earlier computer culture. What I appreciate is that all the references are from the period, no internet memes in sight! No doubt we'll get to learn some more about the Saboteur world and how the first game ties to the sequel, the Avenging Angel.

Maybe, just maybe, I would have preferred a more compartmentalized play experience, such as new missions instead of this longer quest. Yet, altogether the new sections are well organized and as you get further you're bound to be obsessed with seeing it all through. Obviously the new material in no way detracts from the original game, which is intact. As with the original, the difficulty levels change the game experience and the map, and I'm looking forward trying to complete the harder modes. If a true Saboteur III appears, this all certainly seems very promising for it!

The game is quite a perfect treat to those who liked the original, and I think those who grew with 8-bit games should find it interesting. More changes might have been needed to win over more new fans, but then again too many changes might have lost that Saboteur charm.

Saboteur at Clivetownsend.com

My thoughts on the Saboteur II remake

Look at the Saboteur SiO

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.