Wednesday, 13 March 2019

QL Tetroid Super Gold Card Clone

First I bought the Tetroid Disk Interface when I should have had the Gold Card. Then I ordered the Gold Card and very soon noted that a Super Gold Card clone also existed. Sigh.

Well, after some waiting I now I finally have the ultimate (?) QL add-on, The Super Gold Card.

Back: The Super Gold Card. Front: The Gold Card
The Super Gold Card has a 68020 and 4 megabytes of memory. The board is somewhat physically larger than the Gold Card. Still, it is smaller than a 1980s version. Again, take care not to grab the computer from the card when carrying!

Looking at the card, it seems Tetroid has got rid of that old Gold Card INGOT chip. If a replacement has been found this promises there could be a supply of these cards as long as there are people to buy them.

Plugged in
This card is sometimes said to be 3 times faster than the Gold Card, which I felt was about 4 times faster than an unexpanded QL. In crude math the SGC would then be 12 times faster than a standard QL. Let's see...

Fiddling with SuperBASIC, the thought came to my mind: Is this really that much faster than the normal Gold Card? 

The experiential, qualitative leap from Gold to Super is not as huge as from the ordinary QL to the Gold Card was. Adding this new speed boost does not give the same feeling as when accelerating the QL the first time.

Having said that, it is clear that when booting up to my environment that copies the QED editor, assembler and source to RAM from the SD card, I can sense the improvement is substantial. Compiling time with QMAC assembler also appeared faster.

So, I did some stopwatch tests on a few BASIC line drawing loops and assembler compiling. I ran the same programs without a card, with GC and the SGC. All the time the QL-SD card reader is present and supplies the Minerva ROM.

A BASIC line drawing program that takes 30 seconds in the non-accelerated QL, took 8.25 seconds with the Gold Card. With Super Gold Card, this was reduced to ~4.5 seconds.

The assembler compilation+linking task that previously took about 5 seconds on GC was now 3 seconds on SGC. I couldn't test the compiling on the unexpanded QL in a comparable way. I guess I could use the Tetroid Disk Interface to get enough memory for that.

These times are not super-accurate, but I'd say in everyday practice the card might be closer to being twice as fast than the Gold Card rather than three. Compared to an unaccelerated QL it's 8 times fast. Possibly the 3x or faster speeds can be achieved in only certain contexts.

Below I have a comparison table between Tetroid Disk Interface, Gold Card clone, Super Gold Card Clone and the QL-SD.

                      TDI      GC       SGC       QL-SD
Card Reader:          YES(CF)  NO       NO        YES(SD)
68000/Acceleration:   NO       YES      020       NO
Memory:               800K     2MB      4MB       NO *)
Disk interface:       YES      YES      YES       NO
Battery-backed clock: NO       YES      YES       NO
Toolkit 2:            YES      YES      YES       NO
Minerva ROM:          NO       NO       NO        YES

*) The file allocation table requires memory

Saturday, 2 March 2019

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.


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

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?

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.

Sunday, 17 February 2019

Linux, Rasm, Arkos Tracker 2, ZX Spectrum

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

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

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


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

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

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

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

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

org $8000

ld hl,#4000

inc a
 inc l
ld (hl),a
jr loop

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

The black screen comes from the bin2tap BASIC header
When the binary rasmoutput.bin (the default name) has been created, it still needs to be converted to a TAP file that a Spectrum could load.

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

Then, working with the default output binary name:

bin2tap -b -o mycode.tap rasmoutput.bin

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

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

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


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

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

Arkos Tracker 2

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

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

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

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

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

org $8000

ld hl,Songname_Start
xor a
call PLY_AKG_Init

call PLY_AKG_Play
jp loop

; paste the PlayerAkg_SPECTRUM.asm contents here

; paste the Songname_AKG.asm contents here

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

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

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

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

Monday, 4 February 2019

Zak McKracken and the Alien Mindbenders

Games that begin from your apartment are of a special category.
I have a vague recollection of 1988 or 1989, when I was torn between whether to have Zak McKracken or Neuromancer for the Commodore 64. I was greatly attracted to Zak, but bought Neuromancer instead.

In hindsight, perhaps this was a good choice. I shudder to think how Zak might have worked on a C64 and the 1541. Not to say Neuromancer fit into 8-bit so well, and I never finished that either. These two games have some similarities too: both allow travelling between distant locations through different transports, and money is an important of the game play.

To get both to the airport, just enter at the same time! There's another way, too...
Although I've played through a handful of Sierra adventure games, this is the first Lucasfilm game I have ever completed. This was recently, with the ScummVM engine on my Linux. I doubt if I would ever had the patience to do this without the flexible saving/loading options.

I tried to avoid using online help and maps. Yet on two points, outside clues were needed:

1. It never occurred to me that when Zak says he needs to draw the map he saw in the dream, it doesn't mean I should draw it but that Zak should draw it. Turns out this is quite crucial for the game!

2. Never figured out what to do on the ocean. I did think an animal might be helpful but no idea how to reach one. I supposed it would be under the water, and I spent futile energy in trying to equip Zak with the diving gear.

If you don't get it right, this sequence will annoy you every time you fly.
The game is excellent when it presents complete complex milieus, such as the beginning location, San Francisco and the Mars areas. I just love that spaceship buggy and manipulating the dashboard.

Some individual sections, such as causing havoc in the airplane, also deserve praise.

It gets more frustrating when navigating dark mazes and look-a-like rooms designed to add some sense of space and playtime to a game that is not much larger than Maniac Mansion. Yet I also appreciate the game is not pure storyboard but also involves mazes, time, co-ordination and checking money and oxygen limits. The Mars and Earth are two different adventures that run parallel, feeding clues into each other.

You can leave with the ship but it's bit of a red herring.
This approach also means that despite the mazes, walking distances have been kept fairly short, as the world is a sprawling network of point-to-point connections between distant locations. It's already a bit of a chore to move Melissa and Leslie in and around the Mars landing site at a time when you don't exactly know what needs to be done, so I'm actually glad there's not more of that.

I even prefer this game over The Secret of the Monkey Island. This is mostly because I am not a big fan of dialogue trees and Monkey had them in spades. Although the jokes and writing quality is better in Monkey, there's no end to the constant blabbering and in some ways the selection-tree reverts to a more primitive form of gaming.

Traveling salesman, anyone?

In Zak and Maniac, we are closer to the earlier idea of a 'text adventure' transplanted into a graphic environment. Even after playing it through, Zak still feels more like a game than a spoon-fed interactive story.

One thing graphic adventures could do well was the use of multiple player characters. Zak gives almost a bit more than can be handled, but the clever split between Earth-Mars activities helps keep it manageable.

A vital clue has been delivered.
Travelling around Zak's world, I have to note that the environments might be seen as somewhat culturally insensitive! Africa is two locations, the pyramids at Cairo and a primitive hut village at Zaire. There we meet a doctor with pedigrees of Master of Cranial Diminishment from the Watsamatta University and Witch Doctor First Class from Kinshasa University.

I also could have hoped for more countries and locations. Visiting the Tunguska site might have been fitting and hilarious and surely something could have been made out of Australia, China or Japan.

Not sexist? Who gets to do all the cleaning in this game?
The plot and comedic style reminds me of The Adventures of Buckaroo Banzai Across the 8th Dimension, a film I am not a huge fan of, but it has its moments. Also, add some nods to Douglas Adams' works and a heavy dose of Erich Von Däniken's ancient astronaut theories and we pretty much have the feel of Zak McKracken.

The notion of lowly alien race invading earth, and earth receiving protection from an esoteric "higher" race, was at the heart of the Buckaroo Banzai story too. The aliens' disguises and inability to fit in were similarly laughable.

Of course the idea of invading species and high protector alien race goes way back, and I recently encountered it in Have Spacesuit - Will Travel by Robert A. Heinlein. Come to think of it, the detail given to building the space suit and the constant monitoring of oxygen levels also reminds me of this Heinlein story.

Notes on the graphics

I did a Commodore 64 PETSCII 'text art' version of the iconic street vista, beginning from the observation that the SFO 42 bus is quite PETSCII-like in appearance.

Click to see it biggenated
While doing this, I didn't look at the C64 version, but used the Amiga/DOS graphics as the reference for for redrawing the graphics.

I made many compromises with Zak himself, to keep him in the correct height, so forgive me if he doesn't look quite himself.

Fits the grid alright.
Indeed I tried to follow the Amiga/DOS capture exactly. I noted that the graphics at this location are especially well fitted for a character grid, with 8x8 pixel elements.

I'd even argue character graphics may have been a starting point for designing this location, or there's some kind of tile compression scheme that benefits from the 8x8 approach.

I mispositioned the mirror!
With PETSCII, the 120x16 character area, together with symbols and colors, takes 3840 bytes, less than 4K!

Funnily enough, the outcome is in some ways richer than the C64 location, although I'm quite sure the game players would not have accepted the PETSCII look back then.

Thursday, 17 January 2019

IRQhack64 serial transfer

Previously I had only used my IRQHack64 to load files from the SD card. I now wanted to turn to the transfer functions, enabled by the 6 pins sticking out of the cartridge.

The transfer is something that potentially brings the cart to a whole new level. With this port it's possible to send a file over the serial and the C64 runs it automatically.

Just to make this clear, IRQHack64 is not a substitute for a C64 serial port, it doesn't connect a modem, internet or MIDI. Your PC communicates with the Arduino inside the cart, and the Arduino+EPROM work their magic with the C64.

But as the Arduino inside the cart is not limited by C64 hardware speeds, the files move at a nice 57600 rate, and they move over to C64 even faster.

I have postponed testing his because firstly I knew it would probably be a chore, as the IRQHack64 software is not very clearly documented. All the sources have been made available, but there's no overall comprehensive guide for what the cart is supposed to do and how.

Also, the Arduino code, the EPROM code and the irqhack64.prg need to have compatible versions or the cartridge likely won't work.
Connecting the PC to the cart using an FTDI board
More importantly, I needed the FTDI board, which makes it possible to communicate with the Arduino Pro Mini inside through serial, while the cart is on-line.

Converting the IRQHackSend

I used the IRQHack64Turbo project as a starting point for examining what the software is supposed to do. At least after compiling the Arduino source I get a working cartridge that plays nice with the current EPROM and the menu program.

The IRQHackSend in the Tools folder is a separate software for sending files from the PC end. It was simple enough to adapt to Processing.

The program opens a 57600 connection to the Arduino inside the IRQHack64, sends the "1" character which tells the Arduino at that end to start receiving. After this the Processing source sends the file length bytes, two header bytes and data bytes just as the original source does, with suitable delays here and there.

Immediately I got my software to talk with the cart, as the IRQHack transmits the menu and other responses over the serial. Using single character commands over the connection, the C64 can be reset with or without the cartridge, the cart menu software can be triggered remotely from the serial and so on. This remote control-reset was a nice bonus. So far so good.

However, using the file transfer mode was not a success, as the resulting bytes were often garbage. For a while I thought the serial transfer was to blame, and I spent hours messing around with the Arduino source.

The Obvious Solution

Umm, it turns out there is a speed toggle that apparently affects how the memory write works. The cart might have even have worked out of the box (not that it came with a box), but I could have changed that accidentally. The serial was not to blame at all, at least with these small file sizes.

The source seems to indicate it's possible to change the speed through the time-based button press interface using more than 5 seconds pressing. The source is also where I found this feature even exists.

I changed the Arduino source so I could send the speed toggle through a serial command, so I could be more sure that it has been received. After that, the serial-transferred files & memory writes started working!

Below is a Processing source for sending a file over to the IRQHack cartridge, using the FTDI board as a serial port.

import processing.serial.*;

Serial myPort;

void setup()
  int port = -1;
  for(int i=0;i<Serial.list().length;i++){
    String stn = Serial.list()[i];
    println (i+":"+stn);
    String portName = Serial.list()[port];
    println (portName);
    myPort = new Serial(this, portName, 57600);}
    println("NO USB found");

void waiter(int amount){
  for(int i = 0;i<amount/10;i++){
    if (myPort.available() > 0)print (char(;      

void keyPressed(){
   int k=key;
   if(k=='1')send_file("myfile.prg"); // send this file
   if(k=='r')myPort.write('3'); // reset c64
   if(k=='c')myPort.write('4'); // reset c64 nocart
   if(k=='d')myPort.write('2'); // enter dir menu remotely

void send_file(String fname)

  myPort.write('1'); // "type" the Receive prog command at Irqhack's menu via serial

  byte prgdata[] = loadBytes(fname);
  waiter(250); // 250*10 millis, original delay(2500) millis
  byte low = (byte)(prgdata.length % 256);
  byte high = (byte)(prgdata.length / 256);
  myPort.write((low)); // write length to receiving end  
  for(int i=0;i<2;i++){ // write prg header
    if((i%32) == 0)delay(10);
  for(int i=2;i<prgdata.length;i++){ // write actual data
    if((i%32) == 0)delay(10);
  // we're done here

void draw()
  if (myPort.available() > 0) print (char(;         

This is a minimal Processing sketch. I've only tried it on Linux. It scans the serial list for the presence of the string USB0, this may vary depending on your computer and serial adapter/FTDI hardware.

The program reads all incoming characters and prints them on the console. Pressing '1' will send a file myfile.prg over the serial, if it exists. R and C keys resets the C64 and D makes the IRQhack enter the file selector menu. If there's no Arduino source change, there's no point sending a 'speed toggle' command.

Now that I already made the work on Processing, I modded the PETSCII editor to save & upload the exported prg through a keypress, so I can do PETSCII graphics on PC screen and experiment with results on the C64 screen.

After reducing the pre-delay in my sending routine to 250ms, it takes about a second to transmit the 2K PETSCII prg, so I can do it as often as I like. This was initially at 2000ms. It may be that different C64 units need a slightly different delay.

I've worked on it a bit more for my own setup.
Using the same approach on my Multipaint, it obviously works but as the export file sizes are 10K it already takes closer to 4 seconds to see the results on the C64 screen. But that's not bad at all. I could also revise the Multipaint export so it would send a smaller file in case less than full screen area has is in use. Sending packed files isn't that useful as the C64 will take some time extracting them.

This is still a great improvement over the SD card switch-a-roo between PC and C64. This feels like a real professional Commodore 64 graphics workstation!

Not so fast

I came across problems when transferring some small scene demo and game programs that would normally run from the SD card. Although size is not the only cause, it seems larger files (20K+) are more likely to fail.

I have to stress there is no randomness here, trying to send the same file repeatedly does not help, nor do the small straightforward files really ever fail to send.


To extend my review of IRQHack64, I'd now say the serial transfer/remote features are a very nice addition to a developer's toolbox, but it doesn't add much value to a casual user or game player.

For the above purposes, sending simple & short files repeatedly, the cartridge transfer functions still performs fine. For longer files and demo/game collecting it is better to move them on the SD card anyway, from where they can be run more reliably.

The cart receives a file and run it, although it would be in some situations more useful to send memory areas to C64 without resetting or running any code, for example overwriting portions of the graphics memory. But, without changing the EPROM code this situation probably can't be changed.

Thursday, 3 January 2019


As last year, I try to recap the year.

Firstly, what I said in the 2017 post, the idea of platform-specific pages for the blog has not proceeded, although I've updated the existing Sinclair QL one. I'll have to look into it some more.

I have avoided buying more old computer hardware, although I did buy that atrocious hand held console and a crappy flea market NES-clone. And just at the end of 2018, a C128D motherboard. Oh well.

On with the show!

Releases, Coding, Events

At the end of 2017 I was quite enthusiastic about Sinclair QL, but it turned out I did not spend that much time with it after the beginning of 2018. Even the work on the still unreleased QLDD software was mostly done in late 2017.

Commodore 64 has kept its position as my retro favorite, and the building of a new desktop case for the computer has occupied much of my hobby-time (and this blog). I recently got my IRQhack64 transfer working and a more in-depth blog post is already in the works.

Multipaint was revised into a 2018 version, and a nice version it is. I'm beginning to see the need for better file handling (e.g. recent/last file, autosaves, overwrite warnings) and possible GUI updates.

Panasonic JR-200 returned in a more virtual form, with starting the work on an emulator. I hope this eventually results in something new for the platform.
As usual, I also produced some pixel/text graphics. One was sent to a disk cover competition, the first time I made a 5'25" disk cover. This type of scene output was quite unfamiliar to me, I've probably never seen demoscene disk covers before the 2010s.

The demogroup Desire asked me to make a picture for their X-party demo called C 64, Hear 64, and make it I did!

I didn't do that much graphics in 2018, it seems. But after Christmas, I released a new Commodore 64/plus4 game, Digiloi, following the footsteps of Fort Django. Another PETSCII showcase, it turned out much more popular than I thought it would be.

It also made the blog post about the game easily the most read entry in 2018 and one of the most read altogether.

I'm the first to say there's much more potential in PETSCII games than what I was able to put together here, as even I could see in hindsight it might be coded better in parts. Even as it is, more stuff could be moved on-screen, but the game was getting a bit crowded.

Also, the plus/4 conversion proved to me finally that this computer is something to explore a bit further.

Games, books, films

From the beginning of the year I have put more attention to Chess, playing puzzles and computer matches at, acquiring sets and reading literature. I even went to a beginners' tournament.

But I'm starting to waver a bit. The amount of time it would take to improve my skills might be disturbingly high. So far I've not seen reason to stop altogether. I'll blog about my experiences at some point.

During summer I played some Atari 2600, and recently I've enjoyed old Commodore 64 games such as Blue Max, Rambo and Raid Over Moscow, also taking mental notes about what makes these games click.

Of more modern games I played Tomb Raider 2013 version, as it worked quite nicely on my Linux. I also had a peep at Life is Strange, but it didn't catch my interest. At the very end of the year I put some effort to try to solve Zak McKracken and the Alien Mindbenders, but it's still going on. I still play Larn every now and then.

On the book front, I read a bunch of sci-fi books, with emphasis on bestsellers and famous books I might have missed earlier. Turns out there is quite a lot. Some of this I also documented in the blog, noting how many plots and ideas in these books have found their ways into various games.

Westworld was the most important TV series. I expected more nods to western cliches & classics, but the concept is less about the west and more about the responsibility towards the imaginary worlds we create. The parallels and connections to video game culture are obvious.

I liked the season 2 less, it felt more of a mixed bag and less purposeful than the first season.

W was an enjoyable Korean "paranormal romance" (genre made popular by Twilight, I guess) TV series which I learn is a quite common there. It's from 2016 but now shown on Finnish net TV. A comic book artist discovers a doorway into the comic world, bit like in that A-Ha video. The daughter of the artist gets involved with the tragic yet resourceful hero of the series and the indefinite murderer.

Take ... on ... me ..
The new Doctor Who with Jodie Whittaker was enjoyable TV somewhat in the same way the 1st new Who season (Eccleston) was, except with higher production. What I mean the writers have given up complex overarching plots and mysteries and concentrated on the one-off episodes, with less metaphysics. The format and storytelling was more straightforward.

This was clearly the most brutal reboot of the series in the 2000s. There was something of a post-Brexit and post-Trump vibe with the season. Instead of pushing the proud Britishness every now and then it tried to be a bit more considerate and inclusive in more ways than just adding a minority companion.

After the New Year's Eve episode I am even more convinced that the writers have decided to 'stretch' the narrative. What would have taken a few episodes at best for each new doctor, now takes a whole season. As the doc returns in 2020, they have plenty of time to think of a follow-up.

Solo: A Star Wars Story. To me it was a pleasant small surprise, even if the film does not add much to the broader 'Wars lore. Well, Lucas was originally influenced by early movie serials, and in Star Wars we now have them. Is that a good thing?

As Solo was the character that most embodied the "space cowboy" side of Star Wars, it makes sense to make his film a western. The space scenes on the other hand were a bit messy. What with the candy-colored Maelstrom and the Maw, it's like there never was a good clean space shot, the kind that made the original films so stylish.

On with 2019...!

Thursday, 27 December 2018

Digiloi: Action game with C64 default characters

Digiloi is a game I made for Commodore 64, using only the default character graphics (PETSCII) for visuals. For some time I've wanted to use this approach. Fort Django used PETSCII for the backgrounds, but all the gameplay worked with sprites.

There's nothing special about using PETSCII for games, it was done a lot back in the day. However, not many full screen action games were done using the technique, probably because sprites are far more useful and the clunky char-by-char movement was not that attractive.

This visual style is closer to ZX Spectrum game programming techniques, even if the Speccy does not have a character display. Many ZX games had movement restricted to the color grid, with big player "sprites" to compensate. Don Priestley used his unique techniques in Benny Hill, Popeye, Trap Door, Flunky etc.

Left: The old-style forest. Right: UFO attacks
Later, others made fast arcade type games with a more streamlined approach, for example Dan Dare IIISavage!, and Extreme. What I've done is a bit of a compromise between these, an arcade game following Priestley's non-scrolling style but ignoring the more complex aspects of his routines.

I could not achieve 50 frames per second for these big dudes. I wondered if I could stick to 1/2 or 1/4 framerate, knowing that each frame would add greatly to the amount of code that can be executed. I went for 1/3, which is something like 16.67 frames per second on a PAL machine.

I use 256-byte aligned buffers for holding the current screen background and building the screen for displaying. I discarded the idea of double-buffered page swapping routines as the color memory in this mode is fixed at $D800 anyway.

The visuals and game logic are orchestrated like this:

Frame 1:
The background screen & colors, which were built on entering the "room", are copied to the respective 256-byte aligned buffers using speedcode. Copying 2K of characters and colors takes nearly the entire frame.

+joystick poll, music/fx play

Frame 2:
The 8 x 8 character "sprites" are drawn over the 256-byte aligned buffers. Each large "sprite" graphic is stored in 143 reverse-ordered data bytes including color and line-padding zeroes. Some smaller graphic elements, like bullets, are drawn using hardcoded routines.

This uses something like third of a frame, depending on how many movable objects there are on screen.

+joystick poll, music/fx play

Frame 3:
The 256-byte aligned background buffer is copied to the visible screen using speedcode. Again, this is 2K and takes nearly the entire frame.

+joystick poll, music/fx play

During each frame the interrupt plays a GoatTracker SID tune and polls the joystick.

With this approach I balanced speed, memory and convenience. Especially I like convenience. The 256-aligned buffers are quite handy. When transfering the 8x8 character elements to the buffer, the writing address hi byte is INCed with self-modifying code to reach the next vertical line whereas X register handles the horizontal coordinate.

I already think I might have the graphic shapes erased with routines similar to drawing them, resulting in a faster screen clean-up. Also, I probably could use the X/Y registers without having to resort to the INC gimmick. But once I had my routines in place, I kind of prefer the 1/3 because it gives automatically a nice gameplay speed without having to slow things artificially. Convenience.

With the visuals, I took the easiest, black-background PETSCII approach. I noticed that PETSCII game visuals need a somewhat different approach than static screens: The overlaid "sprites" have to go well with the background without too large black outlines. I initially gave the main character a more rounded look as I would do in a picture, but this did not work with the background. I took most of the rounding off.

This not only influenced the character design but the backgrounds too, so there's more black empty space than would look good in a static picture.

2017? Well, um... I've been sitting on it for a while.
The game is pretty much 100% written in assembler, unlike Fort Django, which still had a fair amount of C code in it. There is still a short C scaffolding for initializing stuff, but after kicking off the main loop it's all asm.

I now feel it's not that much more difficult as the assembler can work quite easily with "variables" and tables, and the X and Y index registers make it easy to have array-like structures for game objects. Using the stack to store registers, it's possible to have hierarchical subroutines and sub-subroutines for various tasks and associated labeled memory locations as "local variables" if need arises.

Tools used:
  • CC65 cross-development package. This has C and assembler together. C is nice for initializing and testing ideas, though it seems I'm relying less and less on it. The included assembler has some things lacking in the code alignment and positioning department (stuff promised in the manual does not seem to work).
  • The text editor included with Linux Mint Mate, Xed or whatever it's called nowadays. Later in the project, I moved to Sublime Text with added 6502 asm highlighting.
  • VICE emulator. Obviously.
  • C64Debugger from Samar Productions. A neat tool for examining C64 memory content live as it is emulated. This was useful in getting the 256-byte aligned buffers working.
  • Marq's PETSCII editor. Not only it is good for creating static PETSCII screens, it does a good job with tiles and animated graphics. I did add custom ordered exporting code, though.
  • GoatTracker 2.73. Does the job well and has simple to understand sound fx routines (after understanding them, that is) and easy export.
  • Tiled. A friendly enough map editor that outputs csv. It's nice to be able to grab larger entities from the map or the tilesheet and paint with them. The tiles are exported as PNGs from the PETSCII editor straight into a tile sheet for Tiled.
  • Processing. For generating some of the tables and converting the Tiled csv directly into ordered room list in an assembler-friendly format. Also, the PETSCII editor modifications are made with Processing.

Commodore Plus/4 conversion note

As the game routine operates most heavily in an invisible back-buffer, there are not that many unique routines and addresses in use. So I could convert the game fairly fast to plus/4 simply by changing the speedcode to point to plus/4 character and color memory addresses.

The joystick reading needed a bit more investigating, but it's not that much more complex than on a C64. I added a keyboard key reading too to switch the music on and off. Sadly, there's only SID support on the sound side.

plus4 version
I re-painted the graphics using the PETSCII editor's plus/4 conversion as a starting point. Some coloring was hard-coded to the source (tut-tut!) but not at too many places. The result is not that different from the C64 original, but it has a bit more shine here and there.

It's more interesting to see that the code runs roughly 30% faster at places, even without trying any plus/4 specific tricks. More could be achieved with plus/4 on this type of game, than on a C64.

I can also see that despite having twice as fast processor, it does not mean a 2x speed. But, certainly the 1/2 framerate might be a more realistic goal even without modifying the routines too much.

*** 28.12.2018 plus/4 addition: The speed-up I'm talking about is not really present in the originally released Plus/4 conversion of the game. I have made a speeded up demo for plus/4 available at the download links below so you can see the game running at 25fps.

However this is a rough-at-the-edges implementation and I have no guarantee it works well all the time. Also, as the game runs faster it may be less playable. The plus/4 is quite a neat computer!

Some reflections

I've wondered why I don't finish more stuff. It's not really about available time.

My projects tend to follow this script:

1. Become enthusiastic about a visual/logical solution for graphics and animation routines, which are at first built with care and reason
2. Start building the game logic with fundamental routines, still maintaining neat hierarchy
3. Lose momentum. Become bored and make new additions without much thought, adding stuff outside the existing hierarchy, generating potential problems difficult to solve later
4. Hastily wrap up. Instead of creating more gameplay & narrative, be happy with finishing the thing

If something disturbs the game within phase 1-2, it's possible that the project never gets completed. If it gets past phase 2, I can at least stubbornly make a finished piece out of it.

One antidote is to try to make the start/game over/finishing logic fairly early on in the project, so it's basically "finished", although there might be a lot to do on the other parts. This is something I did here.

It might seem that more game content would be just incremental work. But again, creating and testing game content becomes increasingly painful as the game gains size. Add a level, it has to be tested. Add a monster type, all the rooms with it have to be tested. Add a weapon, all the areas have to be tested again.

No wonder games are sometimes pre-planned before coding anything. But I find it infinitely boring to try to design a whole game beforehand and then just code it, as lot of the fun arises from trying varieties and discovering things as I go along.

I'm also speculating that fatigue strikes because incremental work stages are boring. The first coding stages often bring an euphoria of seeing exponential results as a result of tiny amount of work or changes.

You'll need a Commodore 64 computer or a C64 emulator to play this game.

Direct download of D64 disk image with Commodore 64 and Plus/4 programs
Digiloi at csdb
At plus4world

Download the prg for the Commodore plus/4 speeded-up demo version here