Blog 10th Anniversary

Hooray, the blog is ten years old!

How to celebrate? Retrospection, of course.


In 2011 I only made two blog posts, overviews on Laser 200 and Panasonic JR200 computers. My original idea was to present explorations on home computer hardware, more obscure the better.

It's possible I first got interested in having and using old computers and the idea of the blog simply grew out of that. 8-bit computers were still quite cheap at that time and I had made a few extremely cheap "lot" purchases that would seem impossible now.

Another explanation is that I had been looking to found a blog, but I wanted to avoid direct job-related postings or a diary. I also felt I would be a crap commentator of any topical or current themes, which may or may not have been true. Additionally I thought the theme shouldn't be anything as general as "drawing", "films" or "music" even if like all these things.

After writing some posts, I realized these were really notes that I could later use myself. This approach may have rescued the blog for me, as I didn't have to care so much whether anyone read it or not.


For a while I did continue on the hardware side of things, exploring the JR200 tape format. Some of these posts are extremely thorough, and although I never quite learned to do simple and short blog posts, I've relaxed somewhat over the years.

I continued to explore JR200 with Marq, the other active Panasonic user in Finland (or in the world for that matter). 

After the JR200 theme ran dry there was a long pause in blog posting. I continued in autumn with modding a ZX Spectrum +2 case, gaining some minor infamy with this sawed-off mod.

Even if Panasonic JR-200 was a good start for the theme, there aren't that many un-explored computers out there. I bought ZX Evolution and this generated a lot of posts for the following year.


This was the first really active year, as I managed to do 20 posts. Various ZX Evolution-related keyboard and casemod projects kept me engaged. 

I was able to keep the computer overviews going with Sinclair QL, Schneider EuroPC, Canon X-07, Panasonic MSX and Orel BK-08. However, I also exhausted this angle here and in many cases I didn't have that much new to say. I also learned it was perhaps too much to try to go into each platform as deeply I had gone with that JR200 tape format. 

I also often later found some of my statements were inaccurate and I begun to steer away from this type of posting. I relaxed the blog theme a little and provided game overviews, and other "hardware" such as typewriters, fleamarket findings and a clone of Sinclair A-bike.

Significantly, PETSCII was first discussed. As Marq made his PETSCII editor for Zoo 2013, I made my first "official" scene C64 releases under the handle Dr. TerrorZ and was involved in the First Ball PETSCII demo. The base was built for later developments such as Commodore 64 code and Multipaint software.


I took a lot of interest into Sinclair QL and peripherals, writing a blog post with QL and so on. There are also ZX Spectrum/C64 hardware projects and still more ZX Evolution posts.

The year saw the ZX Sprites post, which is one of the most viewed. It's still something of a mystery how many of the hits are genuine and how many are robots, but there's at least a clear difference between a post that's viewed by dozens and a post that is viewed by thousands, which is also reflected somewhat in the amount of comments received.

There were again less "computer overviews" in 2014, but I did discuss Sharp MZ-800.

I had a notion of moving towards building electronics and logic, but I had also to admit there were even more limitations to what I could do and what I could present as reliable information on this blog. I'm nowadays a bit wary to present anything electronics-related.

I also dared to present a top-list of what I considered all-time best games. This could be revisited at some point. (Where's Half-Life 2 and Blue Max? Why is Neuroshima Hex positioned so high?)


As I moved to Linux this also meant more Linux and "modern computer" blog posts, such as Raspberry and Arduino.

There was some rekindled interest towards ZX Spectrum, but it seems that old computer overviews are now largely gone. There's a nice post about ZX Spectrum isometric games.

This year saw one of the most viewed pages, Gimmick guns of the Spaghetti West. I still don't quite get how people find their way there.


I went more into Commodore 64 direction, building up the development environment, building up to the release of Fort Django, three years after(!) having worked on that PETSCII demo at zoo 2013. 

Multipaint was first made public, and that had been under development for 2-3 years too.

The only "system overview" was Commodore Plus/4.

Rest of the year seems to have been somewhat thin, continuing with some C64/6502 themes and commenting on a Jarre concert in Helsinki(!)

The five-year anniversary went without fanfare.


I started reflecting on my PETSCII and bitmap graphics as collected posts.

More retro game posts, such as Saboteur II and a post on icon driven games.

After a long time I bought an old computer, Basic 2000. I already think I made a note of having made a rare new acquisition. I also got Atari Portfolio, though, but was quite disappointed with it.

The decision of not being a collector had already been made earlier. I really wanted to use the platforms, and couldn't concentrate on too many. So I tended to go for the Big Three of C64, ZX Spectrum and MSX. Even then I'd mostly concentrate on C64.

Significantly, I made an Amiga post, but the time had not yet really come. A few hardware posts, a TAC-2 microswitch mod and building the Sinclair QL EPROM cartridge. At the end of the year, Sinclair QL momentum was building up as new hardware had appeared to the scene.


I continued with QL theme, but also Amiga. First chess posts are from here.

Here I had reached a kind of natural blog mixture that has not changed much after. I post about twice a month. As explorations computer systems are quite rare, the discussion is more about peripherals or simply whatever I have been working on. Then there are the occasional bitmap and PETSCII presentations, sci-fi literature and whatever casemod/building projects I could bother to do.

At the end of the year I released Digiloi for the C64.


A nice active year with QL, C64, Linux, PETSCII, some chess, Atari Falcon (a new system which generated a bunch of new posts).

I first posted about Linux Proton/Steam, a way to play non-native commercial games on Linux. Looking at these games has become an occasional feature.


Notably a pandemic year so I probably had some more time and motive to concentrate on blog writing, therefore there are more posts. Then again it appears I've done shorter blog posts.

Strangely, there are three book overviews, which were rare previously, but it didn't become a huge trend.

I had fun time exploring The64 Microcomputer and later, the BMC (Raspberry-emulated C64) environments.


And here we are. I'm going on with the same twice-a-month pseudo regularity, posting about whatever I happened to have time to do.

This year I've done more Amiga/Amibian posts. In recent years there has been perhaps a shift towards 16-bit computers and who knows it might continue.

More to follow

Has the world changed much in ten years? Computers that were 30 years old in 2011 are now pushing 40. I've become more aware that the equipment might just be rotting on the shelves and I should get rid of them if I'm not interested in servicing them.

Blogs were no longer especially fashionable in 2011, and this hasn't changed much. I don't myself regularly follow many blogs or even retro news. There is now more Facebook group activity than at 2011, and a lot of retro activism appears to have been concentrated into these groups.

There's no end in sight, but it's also clear the themes are shaped by available time and energy. The blog has transformed from the original 8-bit reporting to a more personal site on themes which may or may not relate to old computers at all.

QubIDE clónica

El peligro de tener una alimentación dual 5V/9V es que puedes meter 9V en una tarjeta configurada para 5V. Eso me pasó a mí con mi QubIDE. Vi claramente cómo salía humo de uno de los chips. Pues nada, esta QubIDE hay que arreglarla.

Lo primero que pensé fue cambiar los chips GAL, que eran los que estaban más cerca de donde salió el humo. Por fortuna el contenido de los GAL está publicado en Internet, así que me compré unos chips Lattice GAL16V8D-15 y un grabador TL866 II PLUS, grabé los chips y a probar. Aquello no funcionó. Probé con varias versiones de ficheros Jedec que encontré para los GAL, pero ninguna funcionó.

Lo siguiente fue comprar el resto de chips de la QubIDE. Mirando las datasheets, en todas más o menos se decía que los chips soportaban instantáneamente una tensión máxima de 7V, luego con unos 9V durante varios segundos va a ser que se han quemado todos. Conseguí todos los chips (los 74HCT646 me salieron muy caros, pero no había otra) y a probar. Tampoco funcionó. Empecé a pensar que se había quemado alguna pista o alguna otra parte que no veía.

Si tuviera una QubIDE funcionando podría comprobar cada uno de los chips por separado hasta encontrar el problema, pero no tengo. Así que pensé: como están publicados los esquemas y los jedec, pues me la fabrico.

Cogí el esquema publicado por Zeljko Nastasic, el autor del hardware de la QubIDE, y me puse a dibujarlo en KiCad.

Se trataba de hacerlo lo más parecido posible al original, si no idéntico. En algunos detalles me tuve que fijar en la QubIDE real para ponerlos iguales. En el proceso dibujé símbolos especiales para los GAL, como si fueran componentes por sí mismos, y también dibujé símbolos especiales para los conectores de bus ATA y de bus QL.

Después pasé a dibujar el PCB, posicionando los componentes y fijándome en las pistas tal y como están en la QubIDE real, pero la placa original es de cuatro capas y las pistas interiores no se ven, así que tuve que tirar de FreeRouting para colocar el resto de pistas en mi dibujo, por supuesto, también de cuatro capas.

Aquí disponía de todas las huellas necesarias para el dibujo de la placa, pero también quise verla en 3D porque me apetecía, y los modelos 3D no estaban todos, de modo que tuve que modelar los conectores DIN 41612 para ver la infografía a gusto.

Los modelos 3D los he hecho con OpenSCAD, de OpenSCAD los he pasado por partes como STL a FreeCAD, y de FreeCAD los he exportado a WRL para finalmente importarlos en KiCad.

El siguiente paso es hacer un pedido de componentes a Mouser y un lote de placas a JLCPCB. Las placas han de ser como mínimo cinco, y los componentes, cuantos más mejor para ahorrar, y, bueno, compré componentes suficientes para montarme dos, por si metía la pata con una de ellas. Un tiempo después llegaron los componentes, y un poco más tarde las placas.

Hora de ponerse a soldar.

Mientras tanto grabo las EPROM con el nuevo driver que hizo Alain Haoui, para esto también me vino bien el grabador que compré al principio de esta historia.

Estando ya todo en su sitio la enciendo por primera vez sin conectar ningún dispositivo y esto es lo que sale:

Hasta ahora todo bien. Me alegro de que no hubo ningún error en el PCB. Conecto una tarjeta SD con un adaptador ATA de 40 pines y la reconoce, bien. Pruebo con varios dispositivos más y todos los reconoce, bien.

Escribo unos comandos para formatear una tarjeta y empezar a usarla.






Aparentemente va todo bien. Escribo algunos ficheros y parece funcionar. Reseteo el ordenador y no lee bien la tarjeta SD, no reconoce la FAT. A veces sí, a veces no. Tiene un funcionamiento errático.

Repaso los GAL, tengo tres versiones diferentes, la versión 1 que sólo sirve para las versiones 1.xx de la ROM; y la versión 2 de varias formas, para las versiones 2.xx y 3.xx de la ROM. Pruebo con todas las versiones, usando los diferentes chip GAL que tengo, pero nunca consigo un funcionamiento estable. Ya empiezo a desesperar y me pongo a mirar el código fuente y además descompilo a mano los ficheros Jedec para comparar, y después repaso la lógica y trato de entender lo que hace, lo reescribo en CUPL y lo compilo. Y sigue fallando esporádicamente.

Entonces repaso todo lo que he realizado hasta el más mínimo detalle y me doy cuenta de que los chip GAL originales no son iguales, los originales son AMD PALCE16V8H-15 para el GAL1 y AMD PALCE16V8H-25 para el GAL2, los míos son todos de 15, así que por si acaso compro unos de 25. Y regrabo de nuevo y al final pongo Lattice GAL16V8D-15 para GAL1 y Lattice GAL16V8D-25 para GAL2. Ya todo en su sitio vuelvo a probar y voilá, funciona.

Ya tengo QubIDE que funciona. Ahora puedo probar los chips originales de la QubIDE original, voy probando uno por uno y resulta que sólo los GAL están mal, con lo cual volvemos a mi primera opción, que era cambiar sólo los chips GAL, que en su momento no funcionó y no sé por qué. Incluso el chip de ROM funciona bien, así que le dejo la versión 2.01, que es la que tenía.

Bueno, ahora con la tontería tengo tres QubIDEs. Y además con todo esto he aprendido…

A dibujar esquemas, nuevos símbolos y circuitos impresos en KiCad,

A trazar rutas de forma automática con FreeRouting,

A modelar en 3D con OpenSCAD y FreeCAD para KiCad,

A programar GALs con WinCUPL.

Y como final quiero dar las…

Gracias a Zeljko Nastasic, por diseñar el hardware de la QubIDE y publicarlo en Internet.

Gracias a Andrew Reed y Phil Borman por programar el driver y liberarlo con licencia GPL.

Gracias a Alain Haoui por hacer un nuevo driver mejorado y publicarlo para que podamos utilizarlo.

Kilobyte's Gambit Declined

As an addendum to the previous Kilobyte's Gambit post, I explored my copy-cat pawn approach further. At that point I declared I couldn't really guarantee a win with it. Well, neither can I guarantee it now but after 13 consecutive wins I think the system is quite reliable for me.

Warning: This has little to do with real chess playing, it's more about finding exploits in the 1K java chess engine. I'm also looking to win fast and safely.

So, this is the formation I'm looking to establish in the beginning. (I've already started moving the rook)

The following picture shows the alternative position that sometimes happens. It might be just as good, but it happens less often so I have less proof. You'd be looking for a breakthrough at the h-file rather than g-file but otherwise it's not that different.

The starting move is e4. (King's pawn two steps forward) If Beth copies your move from the very beginning, you need to choose which pawn to move. I've found the c3 move to be safe. Then continue copying the moves, seeking to complete the above formation.

If Beth moves the queen to b6, just keep calm and move your pawn to b3, which will be protected. This is usually always followed with a bishop to g4. Just follow up with a pawn to f2 and the bishop will be scared away.

By the way, Stockfish engine at evaluates the pawn formation as even for black and white. The following moves are in no way condoned by Stockfish, but will result in a strong enough position.

I believe it's now useful to put your bishop to h3, after which Beth either exchanges it or you will have to exchange it (which is often better as this usually results in a king move).

If the bishop is not taken future rook moves may be dangerous.

If the bishop is blocked it may help to wiggle a piece back and forth until the exchange becomes available.

Now it's time to pile up your material to the right side, and usually you can take your time as Beth moves pieces around aimlessly behind the wall. This is really the key to winning here as you can exploit the given time in any way you want.

The more you can do at this stage, the better. It's a good idea to keep the rook at h3 protected with the knight, and to have some room to move the queen at the second file in case you need to back up the rook at g.

It's possible a knight may attempt to slip in through b4 or d4, in which case you need to take care and seek to exchange it with a bishop. This sometimes leads to a less secure game.

As there's all the time in the world, the white should also develop a knight near the top, to the d5 square. It's not immediately useful but an opportunity for exchange will usually present itself and it can be crucial for an easy win.

The remaining bishop points to the right edge, backed up by the queen. Then you can move forward with your g-pawn, and begin to advance with your rooks and other pieces, looking to line up your rooks and the queen and exchanging away knights and bishops.

At this point, I have now checked that Stockfish evaluates this (or roughly similar) position quite strong as +3.2, pretty nice considering there's no material difference!

Yet it can be a precarious situation and things can still go wrong. Sometimes a knight or bishop may need to be sacrificed in order to get a good skewer (winning the black queen).

The below shows what could happen. I sacrificed a rook to get in a situation where I wiggled the rook and queen back and forth until I skewered the opponent's queen. Although I only have a queen and a knight against a rook pair it won't be too hard to win.

Breaking the pawn formation in the middle is to be avoided, as your king's defenses are not that good there and the approach really relies in the idea of smuggling your pieces up using the g- and h-files.

If the engine starts to do weird moves such as a pawn breakthrough in the middle, or crazy sacrifices, you'll know it is sensing defeat or massive material loss and simply trying to postpone or compensate it. Take the opportunities as they come.

Exchanging queens is not often the best idea, unless you can win significant amount of material. It's usually better to have the queen and a good position even if it means you have slightly less material.

The above situation is not exactly the best outcome, but something like this can easily happen. Not much of a material advantage to speak of and you have to take care the queen doesn't slip through or take that knight. Here exchanging the queen may be necessary as it would get rid of the danger and help get that pawn at f6, working towards promoting the h-pawn.

Here it lead to endgame with knights and pawns, in which I got rid of the opponent's pawns altogether.

Towards the end, if you can't see a way to directly mate the opponent, be on the lookout for exchanging all pieces this way just to ensure pawn promotion, because Beth is really poor at handling those. 

Knights can be dangerous at the end game if you're looking to win fast.

The last thing to take care is to avoid a stalemate, which Beth will try to arrange if possible.

So, although some chess skills are needed to handle some of the more tricky situations, to me it appears the engine is far more easy to win with this approach than with conventional openings. 

Maybe I'm finally through with this strangely addictive chess engine :)

QL-SD ROM (tiny!)

Hardware revisions

I get asked a lot about the state of my new QL-SD, so here’s an update. The new external QL-SD variant (henceforth called “QL-SD ROM”) went through a lot of revisions:

A sample of QL-SD ROM revisions
A sample of QL-SD ROM revisions

This series also exemplifies my progress as a PCB-designer. I’ve never formally learned to create PCBs, so it’s all learning by doing. With QL-VGA v2 I made my first 4-layer PCB and that experience in turn enabled me to create the final variant on the right, “QL-SD ROM tiny”:

(the case will probably not be part of the final product, but I will offer the files as always).


One of the main features of QL-SD ROM, besides the two MicroSD slots of course, is its 512kB big flash memory. It can hold 8 different QL operating systems (called slot 0 to slot 7) and is bank-switched by software with slot 0 being the default on power up. Switching to another ROM is as easy as entering “ROM_SWITCH 5” into Basic. Also, there is one “Forces ROM 7” switch that can be enabled in case something is wrong with slot 0 so the QL doesn’t boot anymore.

All slots can be re-programmed using a new Basic extension, so updating the QL-SD driver or flashing a new operating system is as easy as typing “ROM_FLASH 2,ram1_minerva_rom” into Basic!

Hardware and software is pretty much finished, so I have sent two units to beta testers and I’m eager to hear what they have to say. When they are satisfied and don’t think major changes are needed a larger batch can be produced.


One of the problems with this new variant is how to get the initial operating systems on it in the first place. It cannot be programmed to the flash before it’s being soldered to the board. One way is to put normal ROM chips into the QL and enable the “Disable OS-ROM” switch on the board. This way the QL boots with the internal ROM and one can load everything needed for the flashing from floppy disc. Afterwards one has to switch it back, remove the ROMs from the QL and test the whole board… this takes a lot of time and I already know that I will loath the process very quickly. So you can see how dedicated I am to producing this by the simple fact that I even developed a special flashing station to bootstrap the process:

The Raspberry Pi’s GPIOs are connected to the QL-SD ROM and then basically emit the same pattern a QL would emit when it flashes the device. I actually had to program the software two times because the first version was written in Python and the Python GPIO libraries are incredibly slow (like “5-10 minutes per board” slow). So I rewrote it in C and that does the whole job within 40 seconds.

But I wanted big SDs!

Yeah sorry, no democracy here. I’m in love with the small form factor and the mechanical stability it provides. I did however buy a cheap MicroSD to SD adapter to test it and it works perfectly fine, so people can still enjoy large SDs with this device. Only one will fit of these as the slots are too near each other, but you can still use the second slot with a MicroSD card.

QL-SD ROM tiny with big SD adapter

What now?

When the tests are finished and everything is alright I’ll have a look at making a first run. I just have one request, please restrain from contacting me personally to be informed when it goes on sale. I’m happy that you are interested but I just get too many requests of this kind. I will publish updates in all relevant channels and this being designed to not be too cumbersome to produce I hope I can make enough for everyone.

The Kilobyte's Gambit

Recently, I've been playing The Kilobyte's Gambit. This is an older Javascript 1K chess engine that has been put together with CGA/MS-DOS -style visuals, referring the series The Queen's Gambit. Here you play against a pixellated caricature of Beth Harmon the chess master from the show.

After winning the first game ever against it, I got emboldened and thought it was a simplistic opponent. However, later games revealed I can hardly guarantee a win and have probably lost more games against it than I've won. True, I try to play fast but even when I play slow and careful a victory is not always secured.

I was also curious if the small engine would reveal its limitations to me.

A low level player like me is pleased when the early game follows some known opening pattern, and then a comfortable middle game follows. Yet, when opening theory is discarded as anarchistically as Beth does here, then I'm faced with a difficulty: What to do when the opponent does a move I know to be "wrong" but I cannot exploit this knowledge in any way? 

Beth's approach resembles some of those dreaded "pawn-pushers" at I try to play normally and soon my defences are overcome with pawns far too close to comfort. Yet I somehow know it's not a good approach.

As much as I hoped for a "silver bullet" solution that would break the computer and win every time, this doesn't seem to be the case.

At some point I tried copying the pawn movements. After creating an near-immobile wall between you and the opponent, the computer gets confused and simply moves pieces back and forth.

This gives time to pile up your rooks and material to the right edge and push through. After a couple of successes with this approach I begun to be confident that this is it. Yet as the wall is broken you are not always the one to benefit from it! Also, "Beth" may choose an opening where this isn't even really possible.

Still, are there any observations beside "play well and carefully?" One clue is in the instructions: Beth sees four moves ahead. This is enough so it won't fall for a simplest traps or discovered attacks, and unlike a beginner Beth won't be hanging pieces.

The 4-move horizon is broad enough to produce moves that can break a castling and lead to a mate. These can even appear diabolically clever.

Frustratingly, Beth never castles, which seems like another bad practice, but the engine does rather well despite of this. It knows the castling move, though, but as much as I've observed it's only done to avoid a mate.

The non-castling is one piece of knowledge that can be exploited. Checking occasionally provokes the king to move around, if there is no adequate or useful piece for blocking the attack. Furthermore the king may be lured to territory where it can be mated.

(The castling rules appear to be off: You can't castle if the involved rook is under threat, and this is wrong.) 

If Beth appears to sacrifice something, be very careful. Often this is just a prelude to a fairly useless exchange, but something worse might happen. One idea I've tried to observe is not to be too responsive to the black moves. If Beth seems eager to exchange a piece, try to come up with something else.

The engine is quite bad with end games with pawn promotions, as it might simply not see that five-six moves ahead the player can have a new queen. This suggests a strategy where the black pawns are reduced and all pieces exchanged. To make this happen is of course easier said than done.

Early in the game, Beth might even "give away" pawns as part of piece exchanges. These are not usually too dangerous to take, but the moves afterward have to be done carefully.

In the above position, the center pawn can be taken with the knight. Black takes knight and then White takes knight with the queen (check). Some threatening situations arise but as the computer doesn't see that far here these could be resolved without loss.

In the same vein there can be opportunities for forks. I cannot really fathom how the engine allows these. I suspect it might see a mate or worse in the near future, something that's not easy for the player to see, and the only way to avoid it is to permit the fork.

Clearing the field of black pawns entirely should not done lightly, as the engine seems to thrive on an open field. I guess as the decision tree becomes broader, a human can't handle it easily but it's no problem for the computer. Semi-closed positions are better as there a person can more easily see ideas beyond the 4-move limit.

Lessons learned?

I'm wondering whether it's a good idea to concentrate on this game. Does it improve chess skills at all?

I compared the engine to Stockfish levels 1-4 in Lichess, and Level 4 ("1700") was able to win it with certainty, whereas I suspect Level 3 might win it with luck. At this time, it didn't. The thing is the Lichess Stockfish easy levels sometimes do random mistakes and blunders that the 1K engine doesn't do at all.

It's a good idea to have some exercise against "bad" openings too, as there are those non-castling pawn-pushers in online play too. (I've started to suspect some of them are testing their own engines) Many chess engines don't really offer this option.

The graphics are quite unclear, which makes the game somewhat more difficult. Many times I've blundered because I couldn't tell the king and queen apart, especially when the king may move about more than the queen.

When going back to Lichess after an 1K gambit session, the graphics there look blissfully clear and spacious. Possibly, just possibly, this CGA-ordeal helps in reading the board.

Korg Volca SysEx

The Korg Volca FM (2016) is a neat tiny remake of a Yamaha DX7 (1983) digital FM synthesizer.

The cheapness does come with some strange omissions, and the most astounding is that it doesn't understand the MIDI Program Change signal.

Also, editing the sounds fully on the Volca is not really possible. The knobs cleverly access multiple operators and the overall algorithm through a few knobs. (Edit: Actually there is a way to edit the parameters and it's not too bad.)

One selling point of the Volca is that as it's a DX7 clone, it can load DX7 patches, i.e. programs/voice data. As the Volca can receive a single-voice patch, I thought I could simply send the whole instrument data at once, and ignore the lack of Program Change messages.

This model also means the Volca can interpret all the original DX7 parameters, such as the meticulous editing of 6 separate operators, Feedback, Pitch envelope and LFO. It's just all under the hood, as the parameters are not accessible with MIDI Control Change messages.

There's an unofficial firmware update that expands the Volca capabilities in these respects, but I wanted to avoid that route as yet.

Sending SysEx

I used to think System Exclusive packets were something arcane, possibly because I didn't get them to work reliably with an Atari ST and a BASIC in the 1990s, having very little information at hand.

With better hardware and better drivers, plus all manuals and information on the Internet you could hope for, it's much more easy to experiment. It's simplicity in itself, a number of 7-bit bytes are bookended by $F0 and $F7 bytes.

Volca doesn't have MIDI out so I couldn't just sniff the contents of the SysEx package.

The device can send/receive patches using audio(!) and for a moment I thought I'd examine that format as I did with the Panasonic JR-200 tape format those long short years ago.

However, the Volca SysEx patch is well documented and there's a lot of DX7 material around on the web so I felt I should be able to pull this off without going to extremes.

Almost 100% of all Yamaha DX7 patches on the internet are in the 32-patch (4kbytes) format, whereas I'm far more interested in the single-voice (156-byte) format.

Even MIDI can easily send that much data in an eyeblink, so although I don't expect real-time editing of the voice it should be comfortable. 4Kbytes wouldn't be that slow either, as MIDI moves stuff by 31250 bits per second, with a stop bit that becomes 3125 bytes per second I'm told.

Just to give a further idea of the speed, MIDI moves roughly 52 bytes during a frame if I'm working on 60fps screen (Not that MIDI has anything to with the screen sync)  It's not a huge amount when presented like this!

Well, after a few misunderstandings and typos I could send the SysEx dump to Volca, proven by having the text display show my instrument name. By the way Volca only shows 8 characters of the 10, which can be annoying when making a disction between Trombone1 and Trombone2 and so on...

It says MyPatch1, not NyPatchI!

SysEx is initiated by sending $F0 over MIDI, and terminated with $F7. As MIDI data contents tend to be 7-bit, the data within a SysEx dump is within 0-127 range ($00-$7F).

$F0 - Exclusive status
$00 - Global MIDI Channel (Device)
$00 - Format Number (1-voice as opposed to 32-voice)
$01 - Byte Count MSB (1=128)
$18 - Byte Count LSB (128+

... data

$F7 - End of Exclusive

I was worried that the Global MIDI channel (Device) does not really do anything. If I had two Korg Volcas in my MIDI chain, there's no software way to differentiate between the two and they would both receive the same data. So a setup with multiple Volcas wouldn't work with this approach, unless I had separate MIDI buses for different MIDI interfaces.

Well, as I don't have multiple Volcas, the remaining real problem was to decipher the patch data as something meaningful, and I didn't undertand the DX7 patch structure that well. (I used to have a Yamaha DX11 instead.)

Using Processing/Java and midibus library, the below sends a bare Sysex, excluding all the program setup and given that "output" is an already set midi bus.

I've colorized the areas to correspond with the comment lines.

Some notes on the patch structure

A human-readable DX7 patch sheet might say Frequency Coarse 1.0 and Frequency Fine 0.0, but would not tell which bytes would represent such information. In turn the Volca MIDI specification says that Coarse frequency can be described with 0-31 and Frequency Fine is 0-99, but not tell the relation to the frequency. 

I couldn't find a full "Rosetta Stone" that would solve all this, but at least the source to this DX editor  served as a starting point. Here I could already see that Keyboard Level Scale values 0-3 correspond to -LIN, -EXP, +EXP and +LIN and the oscillator mode is R/F, pointing to Frequency Ratio and Fixed Frequency.

It's worth to note that the six Operators are "upside down" in the SysEx bank, starting from 6 and ending with 1.

So, I'm onto something here, and the original DX7 manual was also helpful here.

The FM synthesis is based on the idea that an oscillator frequency is modulated with another oscillator. If you first modulate the frequency of one oscillator and then in turn use this to modulate the frequency of another, you can get quite complex sounds. There's a feedback in the algorithm too, which often provides that 'raspy' or 'crunchy' digital DX sound.

The way the 6 operators interact with each other depends on the overall Algorithm (0-31). The algorithm decides which of the operators are carriers and which are modulators. If you can't see how the algorithm is built, then editing the sound is quite pointless. The Volca of course bypasses this rather neatly.

For example, algorithm 4(of 31) means that Operators 1,3,5 are carrier (sound-generator) operators, and 2,4,6 act as modulators for the respective carriers. (6 also feeds back into itself).

Algorithms 1 and 21 (#0 and #20)

You have to refer to the algorithm chart of the DX7 or Volca, bearing in mind these are often numbered 1-32 whereas the MIDI data is 0-31. Roughly, these start from algorithms where all operators feed into each other in turn, ending with algorithms where all or most operators are parallel carriers.

Operators can feed a proportional frequency or a fixed tone. It's usually better to start from having all operators in Proportional Ratio mode.

Frequency Coarse in Ratio mode:

0 = 0.50 Hz
1 = 1.0
2 = 2.0
3 = 3.0


29 = 29.0 Hz
30 = 30.0 Hz
31 = 31.0 Hz

Frequency Fine (0-99) complements Coarse so that Frequency Ratio is

Coarse Freq * (1+F*0.1)

where F is the 0-99 setting.

... meaning that 0 = 0.50 * 1.99 would be 0.995hz and 1 = 1.00 * 1.99 would be 1.99Hz obviously.

It's a good idea to start with carriers that have 1 = 1.0 and modulators not too far off either. Voices easily become weird if you mess with disproportionate carriers.

Detune can add some "life" to a sound, ranging from -7 to 7 and the effect depends also on whether the operator is a carrier or a modulator.

0  = -7
1  = -6
2  = -5
3  = -4
4  = -3
5  = -2
6  = -1
7  = 0
8  = +1
9  = +2
10 = +3 
11 = +4
12 = +5
13 = +6
14 = +7

Each operator has an amplitude (volume) envelope, and these have 4 rate values and 4 level values. Instead of single decay there are two. This makes for 6*8 parameters for envelopes alone!

The scaling of these envelopes is too much to go into here now, just remember rate values are "inverse", smaller the rate longer it will take.

Rate Scaling means the envelope will be played faster in proportion to the note pitch, so if this is 7 the envelope part of the operator will be fast in any case.

When forming a sound it might be useful to first set all the attacks to 99 and all levels to 99 for all carriers, and then start reducing the effect of the different operators.

The velocity sensitivity (0-7) part is important, as this adds expressivity to a sound. Setting them all to 0 means all operators are indifferent to velocity change, which might be a good starting point. (Keeping in mind that operators also have levels).

Subtly adding values to some of the operators means that the proportion of the action taken by the operators on the sound will depend on the velocity. Bear in mind the "velocity" slider on Volca is not an overall "amplitude" but rather feeds in this 0-127 velocity value. 

The velocity data that comes in with notes does not affect this velocity. After the voice has been triggered, changing the velocity CC (41 decimal) does not change the sound already being played.

It's all so much clearer now! (sarcasm)

The verdict

As only 156 bytes are sent, I could send this individual voice data about 15 times a second without observing any kind of buffer build-up.

There's a chance the SysEx dump could even be used as a kind of in-song sound manipulator depending on where and how often notes are played. But it's probably much better idea to create sounds that are responsive to velocity and only send the SysEx patch at the beginning of a song.

Both in theory and in practice, the lack of Program Change interpretation can be bypassed using the SysEx. The practical issue remains of building a library of sensible patches to send... So I need to decipher the 32-voice banks after all.

Encuentro por el 36 aniversario de la versión en español del Sinclair QL

Cartel anunciador

Con un stand llamativo cuyas paredes estaban formadas por las siglas QL, Investrónica presenta en la feria Informat de 1985 el nuevo ordenador, destacando la ausencia total de Spectrum en este lanzamiento.

El precio definitivo de salida al mercado español fue de 125.000 Ptas. (751,27 €), incluyendo los programas de PSION notablemente mejorados y en castellano.

El año anterior, motivada por la demanda del mercado, la compañía ya había puesto en venta la versión inglesa con unas cifras que arrojaban las 2.000 unidades hasta la campaña de navidad de 1984.

Investrónica estaba a la expectativa. Quería ver como se desenvolvía el nuevo ordenador en el mercado español. Lo que sí tenía claro es que se trataba de una máquina distinta con otra orientación, y que no haría sombra al afianzado Spectrum, como demuestra este comentario de un representante de la compañía:

El QL, lo que no cabe duda es de que va dirigido a un público muy determinado, que se va a comprar un ordenador para darle una aplicación concreta, incluso en algunos casos para una única aplicación, como pueda ser, por ejemplo, para llevar un tratamiento de textos

Un año después, en 1986, Investrónica vendería a precio de saldo su stock de QLs y dejaría de darle soporte.

Pueden conocer lo que publicó la revista MicroHobby a este respecto del lanzamiento, y remontándonos un año atrás, lo que opinaba Investrónica sobre esta máquina.


Pues bien, aprovechando que el Pisuerga pasa por Valladolid, en el día de ayer, 16 de abril, nos reunimos los tres mosqueteros y D’Artagnan (Afx, Zerover, Badaman y Salvador Merino) para hablar de nuestras cosas y conocernos todos. Aquí el testimonio de ese encuentro.

Durante cerca de dos horas Salvador nos puso al corriente de algunas curiosidades que desconocíamos sobre el club QLave que el dirigió, y le contamos las peripecias y novedades del mundillo del QL.

Fue un gusto estar en esa reunión.

Salvador Merino

Para quienes no conozcan a Salvador Merino todavía, deciros que es quien mantuvo vivo el club casi hasta los albores del año 2000, y que tuve la suerte de conocerlo allá por el 2002, siendo el germen y el sustento del proyecto de la web de que inicié entonces. Casi todo el material disponible en la web se lo debemos a sus aportes, abriendo así la posibilidad a conocernos varios locos del QL décadas después de que este ordenador dejara de estar vivo comercialmente.

Al respecto del cierre del Club, Salvador nos cuenta: «Cuando decidí cerrar el club, todos teníamos un PC y sabíamos el futuro de Internet. El problema es que nos dimos cuenta que era imposible actualizar los programas QL de aplicaciones Internet, y para qué perder tiempo en actualizar esas aplicaciones para un emulador si esas aplicaciones estaban en Linux y Windows actualizadas, y para colmo eran gratis.

En Quanta ya se hizo lo imposible desde 1991 para conseguir todo el código fuente necesario para empezar a escribir las primeras aplicaciones en el lenguaje ‘C’, pero era imposible por nuestros medios mantener el ritmo de actualizaciones (Lo más difícil era obtener el código fuente para mantener la compatibilidad).»

Sinclair QL and 1084S Monitor

For some weird reason I had believed the 1084S display cannot be connected to my computers, because it does not have the 21-pin RGB fitted in. Then one day I realised I have an cable that does the job for Amiga.

Then I thought perhaps QL should work with it too, if not with the analog RGB then with the digital. This is something I tried a few years ago, mostly by guessing, but then abandoned it as I couldn't get it to sync.

I then found these instructions which made me rethink the cable.

I'll replicate the info here.

It turned out I needed to disconnect one wire and reconnect another in my already existing cable.

These are the female connectors at the backside of the 1084S and QL respectively:

So, to connect the QL to the 1084S a cable with 8-pin DINs is needed. 5 connections are made.

RED=Red signal
GREEN=Green signal
BLUE=Blue signal

The picture I got was really good.

Some additional QL notes

I admit I was somewhat flummoxed when turning my QL on after this long while. But one reason for making this blog is that I can go back to old material and again remember how things work. I don't really understand my boot arrangement anymore, but at least it works.

Using a QL keyboard after a long while was not an entirely positive experience. It is far more clunky and noisy than I remembered. The basic sensitivity of the keys is ok. 

CTRL+left or right is Backspace and Delete, and this is rather intuitive as the CTRL is really close. Not having to reach further is a benefit after getting used to it. For some kind of tasks this layout can be good, but for games it's not too great.

WTV can be a helpful command if the image does not fit the screen. With the 1084S the screen can be adjusted to fit, though. MODE 0 and MODE 8 switch between the lower and higher resolutions.

Depending on the setup the drive might respond to following commands (mdv is microdrive, flp for floppy drive and so on)

dir mdv1_
dir flp1_
dir win1_
dir sdc1_
dir ram1_ for the RAM drive

load sdc1_filename loads BASIC programs, whereas exec sdc1_qed launches programs such as Qed. Using Qed, F3 enters command mode, where Q exits and X exits and saves.

Leilei Relay

Baby UFOs in UFOland have to train arduously before they can leave their homeworld.

Historically, the most infamous of these training grounds was the Lei Lei Relay.

Collect the lanterns to advance to the next field, up until you reach the UFO cathedral. There you will attain the title of UFO master.

Guide the UFO using Joystick in Joystick port 2. Left and Right turns the ship, while Up is thrust and so is Fire. Pressing key '1' on the keyboard switches the musics on/off.


On and off I have been working on new Commodore 64 games. Most of them do not get much farther than early stages, so I really, really wanted to do something so small that it would get finished.

Even then, this game turned out to be somewhat bloated compared to my original intentions. So it's a small game that became slightly bigger than I wanted to.

It does have multicolor character graphics, sprites, smooth vertical scrolling, inertia, polar coordinate tables, multiple SID tunes and sound effects.

My original intention was to make a one-screen lander-type game. Some inspiration has been drawn from lander games and Space Taxi.

But it's closer to a gravity game like Thrust in the sense there's no actual landing involved. Instead, you need to collect all the lanterns from each room to proceed to the next one. The quicker this can be done, the more bonus points can be achieved. And that's it.

The weird shape of the player ship gives the game some additional spice. It needs to be turned into a vertical position to help squeeze it through some of the more narrow passages.

Unlike with Fort Django and Digiloi, there's no shooting, which makes this game simpler. But it's likely to be infernally difficult.

There's no PETSCII character graphics this time, I have some ideas about their use for other games, which may or may not be completed!

Tile map layout

As usual, I have come to trust Tiled for map-making. Instead of PETSCII I now used multicolor character graphics. The pipeline from character editing to "meta-tiles" would deserve a closer look but I'll leave that for another time. Let's just say experience in PETSCII gives a good start for optimizing character graphics, but it does have its own peculiarities.

First level in Tiled

At the center of the game routine is the scrolling screen buffer. Instead of updating screen portions piece by piece, the whole screen is redrawn for each frame.

I abandoned the character-specific colors to make this easier. This gives the game a somewhat monochromatic appearance. I tried to alleviate it by using different colors for different levels, and mixing the colors when possible.

There's a huge ordered buffer in the memory, but at least it made some other things easier for me. The level data in itself takes very little space, but testing levels and putting them in a reasonable order is time consuming so I went for a fairly low number.

More technical parts

The brutal redraw routine means I can scroll the area in whatever speed I like, and also if I draw changes into the buffer, these are rather simple to calculate, as all Y-coordinates work as increments to the HI-portion of the address. So if the first line of the buffer is at $8000, the next line is at $8100 and so on.

A new thing to me was polar coordinates and inertia, although I already made the routines for a more complex game idea, they found a better home in Leilei Relay.

The UFO coordinates are 24-bit values, but this is less complex than might sound.

24-bit coordinate:

[Low byte][High byte ][Highest byte  ]

Sprite coordinate:

          [Sprite LSB][Sprite MSB bit]

The high and highest byte are transferred directly to sprite screen coordinates, so that "highest" gives the MSB bit for the sprite coordinates higher than 255.

Low byte is kind of sub-pixel coordinates, as they increment over 255, the sprite has moved visibly one pixel.

For thrusting the craft forward, a polar coordinate table is needed. These are 8-bit values centred around the point 128,128 ($80,$80). They have been generated using Processing.

.byte $80,$80,$81,$81,$82,$82,$82,$83,$83,$84,$84, [...]
.byte $70,$70,$70,$70,$70,$70,$70,$70,$70,$70,$70, [...]

So the first values are $80 and $70, which indicates 128 and 112, denoting a 0,-16 vector.

I have 256 values in the table although the UFO has only 32 visible angles. I won't go into the confusion this might create, I initially thought it would be nice to have more functional angles than visible angles, but after experimenting with it, this is really a no-no. 

It's really annoying to see the ship move to a direction it is not pointing at even if the difference is very subtle.

So, it may be just as well assumed the table is 32 values long.

Oh, and the above table is not directly applied to the sprite coordinates, but to the ship inertia X/Y values, which are in turn 16-bit values.

These again have the initial value of $8000, $8000. (low byte=$0, high byte=$80)

If the ship angle is stored in register Y, then the above table can be used to alter inertia.

lda inertia_x_lo
sbc #$80
sta inertia_x_lo

lda inertia_x_hi
sbc #$0
sta inertia_x_hi

lda inertia_y_lo
sbc #$80
sta inertia_y_lo

lda inertia_y_hi
sbc #$0
sta inertia_y_hi

lda inertia_x_lo
adc move_anglex,y
sta inertia_x_lo

lda inertia_x_hi
adc #$0
sta inertia_x_hi

lda inertia_y_lo
adc move_angley,y
sta inertia_y_lo

lda inertia_y_hi
adc #$0
sta inertia_y_hi

Sooo the $80 is first subtracted from the inertia values, and then the motion (with the $80 baked in the values) is added. There must be a more clever way but this is the one I used.

The inertia values are then used similarly to affect the ship (24-bit) coordinates.

This is for the x coordinate, for the y coordinate it's the same. It may be useful to keep them separate.

lda ship_x_lo
sbc #$0
sta ship_x_lo

lda ship_x_hi
sbc #$80
sta ship_x_hi

lda ship_x_highest
sbc #$0
sta ship_x_highest

lda ship_x_lo
adc inertia_x_lo
sta ship_x_lo

lda ship_x_hi
adc inertia_x_hi
sta ship_x_hi

lda ship_x_highest
adc #$0
sta ship_x_highest

The main game sprite is simple, but it does have a layer of anti-aliasing, using another sprite. These were generated using Processing. There are 32 frames, making a total of 64 sprite frames for the UFO.

For each frame, the sprite graphics data are copied from outside the video bank area to the visible sprite frame, as 64 sprites would take a huge chunk of the video bank and this didn't fit into my plan. I'm now getting to understand how important it is in C64 programming to have a good plan for locating the graphic data and the video bank.

With this technique I could have had 64 frames (128 with anti-aliasing), but I felt it easier for the player if the vertical and horizontal positions can be more clearly discerned.

The thruster flame has only one frame but it is positioned differently in alternating frames to give it more direction and a tiny bit of transparency, again using a polar coordinate shift.

Four sprites are used on the lanterns, although with multiplexing they could have used up less. But I didn't want to practice multiplexing this time, it was enough to handle the above issues and sprite-to-sprite and sprite-to-background collisions.

Wrap up

Looking at my notes, I worked on the game intensively for a few weeks in May 2020. Some of the routines had been done previously so I didn't have to "invent" the inertia, polar coordinate and precision coordinate routines then. So adding that I might have worked on this for about month.

It appears I considered a release at end of June 2020, but decided to wait. Then I picked it up on this weekend, with the idea I might be heading towards a phase of adding things to the game. 

But instead I simply cut off loose ends, adjusted some of the musics, added some graphic variety, removed anything that still looked like a bug, tested it on a real C64 and released it.

Design-wise, there was a lot that could have been added, but at this point every addition would have needed another round of testing and assessing the whole game, so it was better to keep the original promise of a "small game".

Leilei Relay at csdb

GeForce NOW

I tried this tip to run GeForce NOW on my Linux and run streamed games through the browser. To be honest I'm not sure if this is needed anymore, but I followed the instructions to the letter and now have the service.

The nice thing is that I can "buy" a game in Epic or Steam but don't have to download them.

I was motivated to get games like Fortnite and Apex Legends running, so I could have some first-hand experience about these games. Also, I could try less interesting free-to-play games like War Thunder without having to waste hard drive space.

But as I could also "sync" my existing Steam library, it might be revealing to check games I already know well.

What I noticed is apparently no Steam savegames are translated to the service, so I had to begin the games from the beginning. The other immediate thing is that the streaming computer has a different keymap, affecting some games in (very minor) ways. E.g. Fortnite has auto-run key on = but it's not at shift+0. The key is not really needed, though.

The stream picture quality with 1920x1200 is high. On occasions I tried a lower display resolution to see if it would affect the evenness of the stream, but to be honest it might not have done much.

My observations are not serious comparisons, just how I felt about it.

Rise of the Tomb Raider cutscene

Above: Streaming from Geforce NOW

Below: Running on my Linux and GTX 1060 3GB with my preferred settings.

Rise of the Tomb Raider cutscene

In this scene there is a minor difference in how the pendant casts a shadow, more hair detail, and the leather jacket is rendered perhaps slightly differently. There may be different reasons for this than just the game settings, though, e.g. driver versions and such. Oh and the local screen might be scaled up from a 1440x900 or something,  and this might already explain the difference in materials.

The basic gameplay of Rise of the Tomb Raider is so loaded with "inertia" so a slight lag didn't matter. I felt more doubtful about the quicktime events, though.

Just Cause 3 is a game which I played with some intensity last year. Arguably it has more crisp controls than Tomb Raider, but still I didn't notice any great disadvantage here. The game itself eventually crashed, I think, which is what happened few times when running on my Linux too.

Just Cause 3

I didn't do a comparison of graphic settings, but it may be that using best quality shadows helps give the above effect. I don't know, but blurred and less definite shadows may actually look better in games.

I went through a few battles in Everspace. This was quite playable through the stream. Granted, here the cursor might not exactly follow the mouse, but the ship control itself is sufficiently sluggish so it translates well to the streaming environment. 

The loading hiccups I've sometimes experienced when playing this on my computer, were completely absent on the streamed version. Full graphic detail is active with no slowdown.


Elite: Dangerous is a good match for the service, as the game has a slower pace to begin with, and my experiences with Steam/Proton had been a mixed bag. Yes, I initially got it working via Proton, but after later updates I had difficulties in getting the game to run and have no incentive to troubleshoot it. 

After various arrangements and recovering lost passwords and verifying the account, and waiting for shaders to load and planets to generate, I got to my Elite: Dangerous via GeForce NOW. The nice thing here is that the game account is at Frontier, so I guess I am continuing my saved game. 

Oh, and the Geforce NOW tends to have DLC and additional content of the games pre-loaded so the Horizons addition was already plugged in. This is interesting, as I don't really own the Horizons content at Steam. (Horizons is what makes it possible to visit the surfaces of the planets.)

Elite: Dangerous

But so, Fortnite. Twice I tried the free variant of the Geforce service and had 200+ players in line before I could have a go. This meant about an hour of waiting. Then I paid the 6 month fee to get rid of the queue and the one-hour playing limit. The stream itself doesn't seem better, but I guess they wouldn't want to demonstrate a crappy stream in the free service.

I have now played a few hours of Fortnite. One time, the game got stuck in mid-stream, and I used the terminal to shut the browser window.

There was some choppiness as the session starts which I believe is due to the MMO logistics and not the stream really.

Apex Legends was offline and in "maintenance" which I'll have to see as a minus as it shows the service content might change on a whim.


This kind of streamed gaming requires some tolerance towards minor screen effects, as I wouldn't say the stream is perfectly smooth. But it's not always clear what is caused by the stream and what comes from the game itself, or even my setup.

Generally I don't see much point in running a game like Tomb Raider over the stream, if I already have it downloaded on Linux. If the streamed games are from a high-end "rig", then compared to that the 1060 already renders games rather well.

Using full graphics settings is fun to try but reveals that the additions are mostly in details I wouldn't care so much about. Granted, these are already slightly old games.

All in all there's a strange feeling this is not quite "real", but at least for trying out new games and especially games otherwise unavailable for Linux, it is a nice addition. The selection of games is not super-huge, especially at the indie end. But it's just a fact now that many major games are exclusive to different platforms and services.