Domain 83 for Commodore 64

Domain 83

This Commodore 64 game has been long in the making. Not that I've coded it for that long, it's just that the first version was started around 2016, abandoned, had a few false starts, and then I wrote again entirely new code at the end of 2025, salvaging whatever I could from the previous projects. Some of the sprite graphics and background tiles have made the long trip from 2016 with very few changes.

A small number of game projects were started very soon after Fort Django (2016), but they were mostly abandoned and what eventually came out was Digiloi at the end of 2018. Digiloi also resulted in a flurry of ideas for PETSCII games, which didn't materialize, but that's another story.

So, Domain 83. This game combines ideas again from Bruce Lee and Saboteur yet puts them through similar streamlining as in Fort Django, this time with more effort towards visuals and more complex game content. 

An early version from around 2018

Over the years I also looked at diverse ideas from Athena, Impossible Mission 1/2, Freak Factory and Nexus. Amiga versions of Stormlord and Wolfchild also occupied the same mental landscape.

At times I figured the game could have more exploration and adventure elements, especially the weird tone of Nexus seemed intriguing. In the end I streamlined the game a lot and the result is more "fast and simple Bruce Lee" than anything else.

Later exploration of a scrolling bitmap as a game background: nope.

The 2016 graphics were strongly influenced by Impossible Mission II, but I found the perspective too inaccurate for the kind of engine I was working with. Also as I heard of "Impossible Mission III" being in the making I wanted to avoid that association. I made the perspective simpler. Near the end I drew a lot of visual inspiration from the Amiga game Flashback.

I especially wanted to avoid the narrative-driven arcade adventure. What I mean I just don't want to see character dialogue or ominous text messages on a terminal screen in a game like this. Or even cut scene animations. Some may feel it's a missed opportunity, but I'm really always impressed by the replay value of short games like Bruce Lee and Blue Max, where such narratives do not intervene.

New start: Domain 83 in mid-December 2025

This game really started from the sprites. I had this idea that if the player could be made from a vertically extended sprite, and highlighted with a non-extended sprite, I could have 4 such entities on screen without even considering multiplexing. And furthermore, if the said game character were to make a flying kick, it could use a horizontally extended sprite instead. And if these extended sprites were drawn in a certain way, they wouldn't look blocky.

The sprites were drawn in Multipaint C64 hires "limitless" mode, so I could just freely create a sprite sheet I wanted. I needed to mentally understand the pixel shapes of the extended sprites, as I wouldn't rewrite Multipaint just to have a quirky sprite handling mode. A Processing sketch was written to convert all the sprite frames and their exceptions from a png into a source file.

As there are more than 80 sprite definitions, and I was expecting more to come, I preferred not to have them at the video bank locations, where they might complicate memory use. Instead, animation frames are copied to the video bank positions when needed. For the enemies, this is not done for each screen update, as the copying would take too much processor time. In addition it was easy to add some programmatic animation to the sprites, especially their disintegration when killed.

I also took advantage of free positioning of the two sprites, so the overall animation frame size can be maximized where needed. So the punch animation frame for the player is wider than 24 pixels, as the bare hand extends beyond that limit.

Part of the sprite sheet, over a 24x21 pixel grid (normal sprite size).

And although the main character gender wasn't a determined outcome of this process, it struck me early on that the ninja from Saboteur 2 could work here. Yet I didn't want a ninja hood covering everything. Maximizing the top sprite led to the "bare midriff" idea. Honestly. So the design of the main character game arose almost entirely from the technical schema.

This also helped establish the color balance for the game. The usual C64 black backgrounds I have mostly favored, would be out, and colors like grey and cyan would be in.

From the days of Fort Django the bar for decent C64 game has been raised quite a lot, or better said there is now a sea of releases. I wanted to see if I could make a more polished output this time, yet I'm not too keen to overdo it or pour on a lot of presentation. I'm still very fine with "1983" style video games, and the self-imposed single file limitation gives a suitable project scope.

The previous release, The Last Z-8 in 2024 was made quickly, based on "safe" and known techniques and learning almost nothing new about the C64 itself. In turn, Domain 83 explores more complex sprite graphics and multicolor character-based tile maps with more detail than I have done before, adding some beat-'em up elements.

A green room.

In 2016 I was still too inexperienced to finish a C64 project of this complexity. Character graphics, tile maps, sprites, music, sound effects, it was still all too much and I ended up with something that looked promising but glitched too hard and I lost track of memory use.

Even as I restarted everything in 2025, I ended up facing some of the same difficulties. If the sprites' relation to the tiles is not very well defined, it can result in ambiguities, undesired behavior and glitches. These are then fought against by making exceptions and fixes to different situations. The base "world physics" could only really be written once, whatever came after is sort of a bodge on a bodge, and each fix contains a risk of producing another problem.

As the game has ladders, jumping, falling, punches and flying kicks, it's quite tricky to follow what the player can or cannot do in a particular situation. Suddenly I find it's possible to exploit a room edge to travel through a wall, or something similar. The lesson learned might be the "world physics" could have been written even more thoroughly in the beginning.

Instead of having the player character "stuck" doing an animation I'd rather have the sprite move as freely as possible, following the joystick instantly. So the opposite of the Prince of Persia/Flashback approach, not that I could have that animation anyway.

First three rooms in Tiled: Enemy positions and trapdoors are baked in the map data

The map is of modest size, I preferred to have more graphic variety instead of a large abstract map. There are still more than 40 screens. The metatiles are made of 4x2 multicolor character tiles. I drew the metatile sheet with Multipaint and created the map with Tiled.

Another sketch made in Processing converted the characters, making note of repeat characters and their color variants, and exporting both the characters and the metatiles as a source. So I could be constantly aware of how many characters have been used out of 256, and reduce their use for certain tiles if so needed.

Each metatile points to a "movement tile", or shadow tile, which defines the actual air/platform/ladder/walls. There are less of these shadow tiles, so the shadow tilemap is considerably smaller than the tile definitions. So what is seen on screen is only visual.

Grid showing the 4x2 metatiles

The 4x2 metatile size, instead of 2x2, is something I learned by inspecting the C64 Turrican map. A wide tile can give an impression of square tile, as a few "square tile variants" are baked into the metatiles. This helps save memory with the map, but can make it necessary to produce more of these tile variants. Turrican only has enough variants to help keep up the illusion of a more precise grid.

Domain 83 graphics style and platform screen alignment for these tiles meant I had to produce quite a lot of tile variants, but in the end I didn't really run out of metatiles (160 out of max 255), characters were far more precious in the end and I ended up examining where I could exchange or use same characters without losing real detail.

Part of the metatile sheet

At the beginning of 2026 I was very confident that the game could be finished for Zoo 2026 demoparty, but the months soon went by. At summer I made moderate progress. As the event neared, I learned the deadline was four days earlier than I had assumed. A quick decision was needed. Should I sit on this, releasing the game next summer?

I tried to finish as many rough edges I realistically could, and submitted the product for the game development competition. At this point I knew there were still glitches here and there, and the game content doesn't vary all that much especially towards the end. But it's not likely that the few days mattered much. It's more like I used the impending deadline as an excuse to have an outcome at all.

A problem of pacing was that I wanted the player see early on the technical feat of three simultaneous enemies, but those enemies can be quite difficult. So the difficulty curve is all over the place really. Avoiding the enemies is often easier than fighting them, but will lead to lower score. Hopefully all of them cannot be avoided!

At first crouching had no use in the game at all, I was still toying with the idea of something thrown at the player or avoiding lasers or other items. But in the end it works like in Bruce Lee: player can avoid the enemy hits. I was never very satisfied with this so I made up this thing where the androids become "angry" if you crouch too much. After they become angry, they are able to hit you even if you crouch.

The result at this point is not as finished in all fronts as I could have hoped, but I feel it's fast and playable enough and does what I aimed to do.

Entering the "sewer" section.

There may be a fixed version that addresses some of these things, and the number of small glitches and bugs, but I am not sure if it is worth the trouble.

Oh, the name? It was one of the last things I decided. The title screen just had a few red blobs for a placeholder, produced with the same tile/map engine that does the rooms. Essentially the title screen is just another room on the Tiled map. I could have made a separate routine for drawing the logo in character precision, but I needed to save time. So I knew the name itself would be constrained by the engine limitations.

Thinking about it, one of the words suggested by the space and the emerging lines was "Domain".  Looking at Lemon 64 database, I learned a game called "Domain" had been planned for the Commodore 64 already. Interestingly enough it's a side-view game with big sprites! I ended up with "Domain 83", in reference to the "1983 principle" I occasionally think of when making games.

The game at itch.io:

https://drterrorz.itch.io/domain-83

Spirits on the rise

Trangia Triangle and the spirit burner

The spirit burner included in the Trangia 27 set has always been underutilized. Sure, I used it a few times before I succumbed to the tempting convenience of a gas burner. But it was not nearly enough to say I've been through with it. Some poor experiences also contributed to avoiding the spirit burner, such as starting with a frying pan and damaging the Trangia pan and the plastic disc in the process.

Last summer an attempt was made to set up a few rocks and boil 5dl of water in a small aluminum pot, in order to experiment with a more "hobo" setting. This was difficult, possibly due to a combination of factors. The spirit had some water in it to avoid soot, but this also decreases its effect. The weather was windy and it's unclear if the distance of the burner to the pot was good. The pot didn't have a lid either. Sure, the water got hot enough for the instant soup, but it didn't properly boil.

Recently, a more modest goal was adopted, to use the Trangia 27 coffee pot to boil a smaller amount of water. This was first achieved with the Triangle, a Trangia product, so no surprises there. Another session, a few rocks were again used to prop up the burner, which now worked with no problems.

The no-stove setting

It can take about 8 minutes of 3-4dl of cool water to heat up in the windy outdoors, but once the flame is up and running only 4 minutes passed for a smaller amount of water afterwards.

Spirit burning has a reputation of being silent, but in the windy circumstances at least the Triangle setting produced considerable amount of noise and writhing flames! Generally, it's very quiet.

The bottom of the coffee pot ends up sooty, but most of it gets loose by rubbing it against wet moss. Back into the plastic bag and until next time.

There's a possibility that I could only carry the spirit burner, the needed spirit inside the burner, the coffee pot, water, food and a lighter. Even the chair is technically optional. Apart from the food and water itself, all this could fit inside the 27 coffee pot.

The backpack needs to be protected from the sooty pot too, so I'm not entirely convinced if it would be a good idea to optimize so far. Cover it all in a plastic bag (and not just the yellow bag for the spirit burner) to avoid any spirit touching the insides of the pot. 

It may be best to carry the spirit in its dedicated container, and let the burner spirit run out in the session.

In any case, using spirit even occasionally will save some gas.


Twig stove

The next setting had also an experimental theme. The spirit burner was put inside a twig stove that came with no promise that such use could be optimal. Lo and behold, it did work and at that one time it was even slightly faster than with the Triangle. It took about 6 minutes to get the water to boil.

That one quick result might have been due to different conditions and water temperature, but the twig stove doesn't seem to perform worse as a spirit stove than the Triangle. This is quite interesting as the burner is clearly further away from the pan bottom.

The Twig Stove

This session also featured the first proper use of the twig stove together with on-site collection of twigs and cones. A Japanese-style saw was helpful for making small wood pieces rapidly. This was an overkill, and using it extensively could ruin a precision saw. Foldable camping-style saws exist, curiously they don't always come cheaper.

It took roughly 20 minutes from first ignition to fully boiling water. But there was about 0.5l of water to boil. To get this more effective and less smoky, cardboard should not be used as the ashes tend to block the fires underneath.

Fuel

An ignition gel block was helpful but perhaps not as long-lived as could have been expected. After the flame becomes secured, regular feeding of the stove should be encouraged, as twigs and cones don't burn for long and heat can easily drop off. Red-hot charcoal at the bottom of the stove is a good sign.

I'm not sure if the "convenience" of having the fuel on site compensates for all the dirt and smoke this session produced. But it perhaps all contributed to a more memorable event.

Smoke or steam? Hint: It's smoke.

A number of guys tending a real fire can become a matter of demonstrating knowhow and casting doubt on the smallest prodding made by others, whether one knows anything or not. But at least the water was ultimately boiled.

The Knorr standard test

Cooking a Knorr dry meal directly in a pot has become one of the standard tests for any gear combination. The above-mentioned sessions concentrated on getting water to a boiling point. Here the food should boil modestly for 10 minutes. In the end it wasn't as difficult as expected.

Again, the twig stove was repurposed for the task.

The simmer lid just about fits through the stove window

The simmer lid was used at a point where the contents were clearly boiling too much, and it did its job keeping the actual lid open. As the simmering begun to wane I removed the lid, just in time to get some boost before the spirit ran out. 

It took fifteen minutes from ignition, and the fill of spirit did run out in the making, but the food was acceptable at that point. A few minutes more could have been hoped for.

Knorr, Knorr, Knorr

It's the Same Different World

A year and a half back, I wrote about watching all the available episodes of A Different World (1987–1993) from Netflix. I also mentioned the rumored new series. Well guess what, there are now ten new (2026) episodes, also on Netflix.

The ingredients are mostly the same: a 2020s generation enters the Hillman College, among them Deborah, the daughter of Dwayne and Whitley from the original series. Another notable freshman is Shaquille, Ron Johnson's successful football-playing son.

Sorry, Netflix wants me to photograph their show from the screen.

Deborah and Shaquille already have some history between them, which provides the necessary romantic fast forward for a series that only has ten episodes. Rashida from Compton, L.A. looks like the one fish out of water, and tensions will arise.

So it's not a full reboot, actually not a reboot at all, but a continuation of the show after decades have passed. The series concept is quite robust for re-vitalizing, as it's about the college and not about the specific characters. Yet at the same time the show was very much tied to the chemistry of the original actors, and as soon as the creators attempted to shift focus to a new generation, it began to fizzle.

Indeed I was surprised how many of the old actors are present. They are nearly stealing the show from the younger generation, as if to admit this was always about them anyway. The freshmen are dangerously close to having the same fate as their counterparts in the last seasons of the old series: not as inspiring as the pioneering crew.

Repeating the mistakes of our fathers.

The fact the main character is a daughter of Whitley and Dwayne, could have in itself been a sufficient baton from the old series, but as Whitley and Dwayne are almost constantly present as well, one wonders if the connection is even necessary.

No show today relies on laugh tracks or "studio audience", although the writers found a way to make a small nod to that practice. So even the supposed comedy is quite different from the 1980s style. The precedent for this was already scattered across the 1980/1990s show, as many episodes dealt with serious matters. I've also felt that whatever merits the original show had were hidden between the intended gags, and the new creators are aiming to bottle that spark again.

Even if a single episode usually explores a theme, more definite story arcs are introduced for the ten episodes. As the presidency of the entire college now befalls on Dwayne, he has to negotiate a crisis of missing millions and salvage what remains of his marriage. The students are mostly preoccupied with their relationships, but also study problems, money, mental health, and who had teh sexx0r with who. The Pit once again becomes a central environment for interactions.

As two semesters are being fast forwarded, a lot can happen between episodes. So all the newbie tropes are basically done after the first installment, and by the fifth the viewer is supposed to accept the friendships and enmities. The episode length is about right, but the season could have benefited from a few more episodes.

Weren't we all.

What is now endearing in the original series, was the complete lack of mobile phones and smartphone culture, or even the mainstream World Wide Web. Obviously a show explicitly set in the late 2020s is naturally entrenched in smartphone culture and we have skipped the entire WWW era.

A post-Covid smartphone culture is perhaps symbolic of the pace and quick shifts the story now takes. I can only compare this to the fairly recent Bold Type (2017-2021), where the transition from physical media was still a plot point. We've gone past something, again, which makes itself present in contemporary shows like this.

Just as the original, there's a pinch of politics and topicality. In the current ideological landscape of the US, the writers just cannot avoid commenting on the current administration even if they wanted to, and the reason for why the show needs to exist, also begins to reveal itself.

Because A Different World doesn't let go of the old characters, it works as a dose of closure for those who really, really wanted to know how it went with Whitley, Dwayne, Ron, Freddie and whoever is alive of the rest of the cast. And it does this just fine, and benefits from the fast forwarding approach. Unexpected guests from the past arrive at a staggering pace, and an interesting name gets dropped near the end. For some plot points I could have hoped the cast was at least 10 years younger.

Conveniently, all plotlines and tensions converge in the season finale. I hear the series has been signed for second season, not a problem at all.

Enter the Matrix with Neo6502 and Morpheus

Neo6502 from Olimex

I ordered this cheap small 6502-themed board in about 2023, wasn't that interested with the Apple II material that came with it, and didn't find the moment to flash the Morpheus BASIC environment.

What postponed the flashing was a lack of a strange item called USB-A-to-A (male/male) cable, which I didn't have around. Some kind of adapter could work, but at least my USB-C to A cables didn't perform here.

Now I finally bought a real USB-A-to-A 2.0 cable and flashed the Morpheus BASIC into the board. Connect the Neo6502 USB-A ("host") to the computer (only this one cable) while holding BOOT key, then release it and the device shows as a drive. After copying the firmware to it, the on-board speaker gives a sound and it's done.

Now connect the power USB and HDMI, preferably also a keyboard, and this screen should appear:

Neo6502 Splash screen

The Neo6502 has a 6502 chip of sorts, hence the name. It's a W65C02 running at 6Mhz, yet a lot of heavy video and memory lifting is done by the RP2040 co-processor. So although notionally the computer does have a 6502-type chip as a CPU, the RP can support in math and shifting memory areas.

For example, drawing a rectangle RECT SOLID 0,0 TO 319,239 will instantly fill the screen, but doing FOR...NEXT loops to fill the screen with the PLOT command will be ploddingly slow. 

A 320x240 16 color video image is produced for HDMI, featuring tile maps and sprites. The 65C02/RP symbiosis is reasonable as otherwise the package might have been a little underwhelming. It's not an FPGA if that's important.

The board has USB-C for power, USB-A for flash/hub, HDMI, 10-pin UEXT (original to Olimex) for communicating with the microcontroller and a 6502 bus connector. USB HID devices such as keyboards, mice and memory sticks work on it, but as there's only the one USB, a hub is almost a necessity.

A number of cables is required

The NeoBasic looks like fun, fast and feature-packed. Reading the manual I see the authors are quite aware of later day BASICs such as Amos on Amiga and STOS on Atari ST, so it's not a bare-bones proposition. It doesn't follow all conventions, there's no STEP to the FOR...NEXT loop. There's also inline assembly, a separate simple BASIC editor, and many other features. Cross-development should also be possible.

I can print text (fast), pixels and lines and other graphic elements with ease. The 16 colour palette can be adjusted, not full 24-bit RGB but apparently a 8-bit subset. It looks like they opted for a 6x8 character set instead of 8x8, so the screen is 53 characters wide instead of 40, leaving 2 pixels to the edges. With the HDMI precision it makes sense. It's a bitmap display anyway, not a character mode.

BASIC

Using a memory stick (the "usb key" in the manual) I could also save and load BASIC programs. I did find a few editing idiosyncrasies and other things I didn't quite like. The screen doesn't scroll when the cursor gets to the bottom, the cursor just wraps around to the top. I couldn't easily find a SHIFT+HOME type combination that would clear the screen. HOME and END and many keys don't seem to do anything useful or what I would expect them to do.

If I return from the EDIT screen, the listing insists on renumbering on 1,2,3... and doesn't care about GOSUB values. I accidentally did this a few times, thinking that EDIT 20 would bring me the line 20 under the full screen editor, as some BASIC interpreters do. The manual does suggest sticking to the EDIT editor and not use line numbers at all, though.

Hardware side, some red horizontal lines occasionally flicker into sight. This problem is acknowledged but it looks like it cannot be helped by firmware updates alone. The board can be picky about the USB hub I suppose, I used a 4xUSB 2.0 hub from Nedis and while keyboard and memory stick work, I also encountered some problems. The AUTOSTART.BAS file refused to boot automatically, although with my old Aten USB switcher hub, it did.

With the Nedis USB hub

Olimex now sells a package that integrates the Neo6502, an USB hub and a keyboard into the same package. I would expect a selected hardware combination to have as few quirks as possible. The price is still cheap, but it's also worth knowing that this is a very narrowly focused hobbyist/tinkerer/enthusiast computer.

MiST FPGA impressions

From behind: USB, Audio, VGA, USB-C, Power switch

I decided to be different and order a MiST instead of the now popular MiSTer FPGA.

This has MIDI connectors, 9-pin joystick ports and maybe a small prestige of being from the lineage of one of the first, if not the first, FPGA reconstructions of old 8/16-bit hardware. Nowadays it can pretend to be many different computers or game consoles, but in its origins MiST was closely tied to Atari ST.

At least for starters, I'm going to stick with the Atari ST cores for a while and not go too much core-hopping. This is meant to relieve me from a shattered focus, dammit.

Well, I have a SiDi FPGA that mostly does the same thing but it doesn't have the 9-pin and MIDI connectors. I'll discuss that in some other post.

The all-important MIDI ports. Front: LEDs, SD card slot, Buttons

And the usual disclaimer: No, FPGA is not emulation. Here a CPU does not play at being another CPU on software level. Electro-logically FPGA performs close to the way the original CPU, video and audio chips would. But it is not exactly same as having the original computer, and requires different thinking at places.

I ordered my MiST v. 1.6. from Lotharek. Physical impressions are very good. The case is smaller than I thought, like a small bible(?!) and it's very sturdy. While this new case didn't look super inviting in the photographs, in real life it looks and feels good. It's heavy and made out of thick matted metal sheet.

Being so small, in theory it could be placed inside an Atari ST case, but this is not really the intention, as it's not a replacement board. Atari/Amiga keyboard->USB conversions float around, I downloaded an Arduino Leonardo sketch for a loose Amiga 500 keyboard. It is more appropriate for an Amiga core, but not too far from an ST key layout.

If there's a nitpick it's that the earlier, minimalist case had more places for adding those Atari/Commodore badges and stickers.

Like so. SiDi FPGA to the right for size comparison

There are connectors all around: SD card at front, two 9-pin Atari joystick ports at right, 4xUSB-A, 3.5mm audio, VGA, USB-C for power and a physical power switch. Left side has two MIDI ports, the closest to front is MIDI out. Possibly it also doubles as thru as in Atari ST, but I am not yet sure about that.

The 9-pin connectors don't normally support 16-bit mice, but the MiSTery core can do this too.

(As a side note I'm getting pain from typing all these caps-sprinkled names...)

What it does not have is an HDMI, but that's not important to me now.

The front panel also has three buttons, Reset, OSD (On-Screen Display) and User button. OSD is equivalent to invoking the display menu with F12. Holding it down can switch the RGB scanline doubler on and off, which can be useful if flipping between displays.

Atari ST up and running

Despite having existed for quite some time, picking up MiST is not instant plug and play, as a few things need to be learned. The MiST builders aren't responsible for explaining how the particularities of each hardware platform work, so instructions for enabling a full Atari ST experience might be scattered here and there.

Also, because MiSTer exists, it's challenging to google for MiST information, because the results are almost always mixed with MiSTer experiences. Some information is appropriate for both, but not all.

But it's quite easy to get the Atari ST core and floppy disk images running. These have extension .st. The .msa and .stx and others won't be accepted by the MiST!

I should have ordered the SD Card that was suggested, it would have saved an hour of looking around. Yet I was lucky to have a card that has worked so far. It's also wise to keep a copy of the contents on Linux/PC filesystem, but so far I've not lost any information.

For Atari ST, the FAT32-formatted card will have three files, core.rbf, disk.st and tos.img, as explained in the instructions.

The first boot looked a little different.

The core and the disk.st is supplied by the MiST Github starting page, but the Atari operating system (TOS) image needs to be acquired elsewhere. Needless to say, whatever its name, it has to be renamed to tos.img or it won't be found.

The TOS version ought to match the chipset the MiST is intended to represent, for example TOS 1.62 for Atari STE, whereas Atari STFM might benefit from a TOS 1.04. Alternative TOS versions can be mounted from the MiST interface itself.

Whatever core is going to boot, also needs to be named core.rbf. After initial tests I moved on to the MiSTery core, which enables a couple of additional things, such as a faster STEroids mode and the aforementioned 9-pin mouse support. This STEroids mode is not as compatible as the others, but switching it on and off is very simple.

For those who are used to emulators and the short cuts they offer, the FPGA gives a reality check. Things can occasionally be slow, disks boot, take pauses and turn and turn, just like with the original computer.

GEM desktop on mono 640x400 mode

Switching to 68020 CPU and using MegaSTE 16Mhz speed is not going to make it lightning fast. Even the Mistery core STEroids mode will fall short of Hatari's 32MHz mode. I think it's about 3x the speed of a normal ST. That Dread game demo is going to run smoother.

Although I love how austere the GEM desktop looks like, I have to admit it is sluggish in 8MHz. The STEroids mode makes it much better.

Display

As mentioned, there is no HDMI option. The VGA is more lenient than with a real Atari STE, so I could get a picture out of the HP Elite (supports 50 and 60hz), also the mono image, which a real Atari STE refused to do with that display.

I made a VGA-to-RGB adapter for the Commodore 1084S monitor using a VGA terminal block, and soldered the cables to a 6-pin DIN.

VGA terminal block AKA breakout

There's only R,G,B, Horizontal Sync, Vertical Sync and Ground to solder.

A tube display is still big part of my retro experience, so I'm happy to see that bright, rock solid image on the 1084S. A 50/60Hz switcher program produces the expected result. Protracker 2.0 extends to the border as it should. 

The STEroids mode doesn't replicate all the border-defying tricks, so the ST/STE chipset setting is required.

Batman the Movie was the first ST game I owned. Don't ask.

MiST won't know what display is connected. To activate RGB requires configuring a file called mist.ini, which is placed at the root of the SD card alongside with the core.rbf, disk.st and tos.img. Every time the MiST is reset, it reads the mist.ini and sets things up accordingly.

A minimal mist.ini for connecting MiST with Commodore 1084S 6-pin DIN analog RGB, could be as follows:

[mist]
scandoubler_disable=1
csync_disable=1

The first runs supported cores in 15kHz, the second outputs separate hsync and vsync in 15KHz.

Note: SCART cables often go the route of using the CSYNC pin, but if the SCART is again fed back to the 6-pin DIN using an adapter, then it is very unlikely to work with a 1084. Some versions of the 1084 display have a dedicated SCART connector, and I'd expect SCART cables to work there.

The normal VGA is not without its uses, as the 1084 cannot act as a mono monitor. I remember there are software "mono emulators" but please, no.

Mono mode on the Elo display

An older Elo industrial screen produced a "real" borderless 640x480 resolution at 35KHz/71.4Hz, into which the 640x400 mono image fits with black stripes at top and bottom. Using auto-adjust, it even went beyond its own manual clock parameter range and showed the pixels 1:1 with no moire effect.

I did have to kick the auto-adjust key every time MiST was even soft reset, though. With color resolutions of 320x200 and 640x200, no such luck, the modes have borders which means the entire screen can't scale appropriately.


Keyboard and mouse

Keyboard is quite an important part of the "feel" for the system. My new Keychron keyboard gave some problems, occasionally going permanently off-line when doing a soft reset, and things like that. It might be because of too little power from the PSU. It's not a huge thing as I would never dedicate it to a retro computer anyway.

An older Blackstorm behaved better, but something more appropriate may be needed eventually; a lot of software benefits from a numeric keypad. For the KCS Omega sequencer graphic editor it is a must, as it enables the quick looping. Flight simulation software often have view selection around numpad keys. Many of the hard disk patched games have an numpad * as exit option.

As I had a loose Arduino Leonardo AND a loose Amiga 500 keyboard, I could try a project for connecting them. There's a number of projects that do a similar thing, I downloaded this and it worked.

This was not entirely without problems (It's not an ST keyboard after all) but something to look at more closely later. I used the .ino as is and connected the wires. Depending on Arduino model, soldering may not even be needed. 

Amiga keys, ST core

Sadly it doesn't always come online, but re-plugging the USB a few times live it does go online and doesn't seem to drop off after that. It could be due the way Leonardo HID works, and not much can be done to it.

The SiDi FPGA behaves better with the Amiga keyboard, haven't tried it so often but so far it has always worked. Upgrading to newer MiST firmware didn't help. But, as I said, I'll look into it later.

One of the advantages of the MiSTery core over a standard ST core is that it supports a 9-pin mouse. So I can stick in a mouse that works with Atari ST and use that for more authentic feel. Atari/Kempston joysticks, such as TAC-2, are simple and supported across all relevant cores.

With a USB mouse, a mouse wheel simulates cursor up and down, this is handy but the ratio is a little weak, I go three nudges and the key is invoked maybe once. There could be an adjustment somewhere, but it's also possible MiST doesn't have it.

Atari ST, Hatari and hard disk images

The basic use for MiST Atari ST core is to collect a bunch of .st floppy disk images to the SD card and then select them using the OSD menu.

How to enable hard disk images? It gets trickier. There's a number of routes and I took what looked like the simplest. It may not be the best.

The language will be heavy with acronyms and jargon.

Just as the floppy disk images, there is a different kind of image file that can be put inside the SDcard to represent a hard disk, and it can be selected from the MiST menu.

The easiest route is to use Hatari ST emulator on Linux. It again requires the TOS images in order to work.

The emulator includes a tool for creating a hard disk image from the command line:

atari-hd-image 256 myimage.img ATARI

With this method, 512 is maximum, for two 256 partitions, but I didn't get that to work. So I use a 256MB image with single partition. Hatari can then "browse" that image from the Hard Disks submenu, using the ACSI HD 0 slot.

Hatari Hard Disks menu

The image needs the extension .hd otherwise MiST won't see it. Hatari doesn't seem to care about the extension but I used .img as most instructions had it that way. In case of such superstition just rename the file afterwards.

But this only implies the hard disk is now available, not that it is usable by the ST filesystem. Atari ST software is needed to perform the formatting. 

From the Internet, find an AHDI driver disk image that has AHDI.PRG and HDX.PRG. This is likely another .st floppy image, such as AHDI6061.ST which can be mounted using Hatari as drive A while the hard disk image is still attached. 

The disk ought to boot the AHDI.PRG from AUTO folder. The floppy likely has a number of tools. The HDX.PRG is used to format and partition the previously created hard disk image inside Hatari ST emulation.

An Atari STE chipset and TOS 2.06 might be a good combo for this. Ramp the CPU speed to 32Mhz to make the OS a little faster.

HDX.PRG formatting the drive image. It will take a while.

When using HDX only the ACSI drives are visible, so if there's a Hatari Gemdos folder drive available, it won't be accidentally formatted(!)

HDX probably suggests four partitions, this doesn't need to be the case, and I didn't even get it to work. At least I only succeeded with single partition drives.

Remember that for an ST, 250 is quite a huge size anyway, and MiST can attach two of them at any time.

The drive now exists and files can be written to it. Hatari can also be used to copy files and folders to the new hard disk image, inside Gem. These are copied from another "hard disk" image which is simply your PC/Linux folder mapped as a hard disk in Hatari.

The AHDI driver is still needed, and again, my first attempt at making the drive bootable did not succeed. So far I've simply used the floppy boot in the MiST with the AHDI.PRG in auto folder to have a system that recognizes a hard drive. This will be visible as C.

The alpha and omega of 16-bit sequencers: KCS Omega + Tiger

I got the Atari ST sequencer KCS Omega from ST Format magazine's January 1994 issue 54 coverdisk. Little did I know it would be my only commercial-level sequencer until mid-2000s. Also, I didn't know I would be ignorant about some of its more interesting features until recently.

Many go vintage, modular or just any DAWless setup. But others are also digging up their old Atari STs and Amigas to relive a workflow from the mid-1990s, or to engage with a distraction-free environment. 

Although it can take some effort to have an Atari ST set up and working these days, I guarantee a session won't start with downloading updates.

KCS Omega was the brainchild of one Emile Tobenfeld, who under the moniker Dr. T had already conceived MIDI products for Commodore 64 in the 1980s. In a way KCS Omega repackaged some of the same ideas and functionalities for the 16-bit range of computers, and put a graphic editor, Tiger, on top of it.

According to his FAQ, Tobenfeld had left the company in 1993. In a couple of years all the platforms on which KCS products had proved popular (C64, Atari ST, Amiga), had fallen out of favor, and Windows/Mac platforms eventually emerged as the victors in the productivity arms race.

Diverting opinions will arise. "Wasn't Cubase the thing on Atari?" anyone even modestly informed will ask. KCS Omega is comprehensive, quite fast and supports a number of workflows, and there are often multiple ways to achieve the same outcome. I'll maybe compare them later but at this moment KCS feels better than Cubase 3.1. To me, knowing the idiosyncrasies of KCS is like belonging to some arcane secret society. I don't even know enough to tell everything.


Tiger

In the mid-1990s, I mostly used the Tiger graphic editor, thinking this was the only way to use KCS for song building. Coupled with a Yamaha DX11, with its multitimbral, velocity-controlled FM operators, I could create quirky digital soundscapes by adding and duplicating note clusters and fiddling with their velocity stems. Add a Sequential Circuits Drumtraks and rudimentary rhythmic electronic music could be made. And that was that for a long time.

I did note that Tiger was an add-on to the "real" KCS Omega, but I didn't pay much attention to the central sequencer. I felt it was only a multi-tracker for recording MIDI live, and wasn't entirely wrong.

(The screenshots are from Hatari ST emulator for clarity)

Tiger: Fast editing of the velocity stems

First things first: I've noticed that at some occasion MIDI doesn't clearly output on channel 1, unless I switch the track channel to something else and then back at 1. Top where it says C< 1A>. So, trying to test gear and connection, this is a thing that can happen.

Tiger is a quite versatile piano roll editor even now, and certainly the most friendly way in into the intricacies of KCS. I can set quantize/snap on with that icon at the bottom right corner, then add notes with the pencil tool (2nd bottom left) and just kick Play.

With Add/Drop Tracks dialog, multiple tracks can be viewed and edited in parallel, and zoomed horizontally. The multiview likely works better on a high resolution monitor. The relative size of the areas can be adjusted by dragging the symbol at the top right of the track window, but this isn't visualized, it just happens. Clicking it switches between full view and the multi-view. Right-clicking the corner removes the sub-view. The combined views can also be stored and recalled.

Tiger makes use of a 2-button mouse. The four icons at the bottom left are for Left Mousebutton, and generally affect, or select, a bunch of notes or larger areas. They are: Erase selected notes, Draw Note, Paste, Set Range. If none are highlighted, it's possible to select individual notes or drag a selection rectangle.

Repeat Time from Repeats menu

The seven icons at the right side are for Right Mousebutton, and apart from the Play icon, they affect an individual note. So, if Play is selected on the the right, the right button always plays from the cursor position. The others are Draw note (again), Erase Note, Alter Note Position, Alter Note Pitch, Alter Note Velocity, Alter Note Duration.

It's a pity these only affect a single note, but I also understand the need for simplicity. I suppose the purpose with these right button tools is to nudge individual notes that result from a recorded live play.

So there are two Draw Note tools assigned to the left/right buttons, and the properties can be changed from a menu item.

A clone repeat time can be set from the Repeats menu. (960 units = 1 bar by default). I can then select a number of notes and use Control+Arrow keys to duplicate them around the track. Another option is to fill the track with the selection, so making a metronome track is very quick. 

Pressing keys on the numeric keypad, I can instantly loop a number of bars starting from the one under the mouse cursor. This is very useful.

Selected notes and a range. Double cursor? It's an emulator screenshot.

There are menu functions for selecting all notes, notes of a certain pitch, notes above or below a certain pitch, and all these selections can be filtered with the selected range. Handily, the selected notes can be moved around with cursor keys, and most of the keyboard is dedicated for altering position (QWERTY row, esp. Q/W-O/P are useful), duration (- and +) and velocity (ASDFGH row).

Various reversals can be made to the selected notes. Reverse the entire order, or only pitches, durations or velocities. One more way to tease out small creative discoveries.

Quantization is a normal sequencer function, it's fairly straightforward here. Recording and quantizing naively, I often end up notes in crassly wrong positions. I found it better to first fix things as much as possible by hand, then quantize if still necessary. 

On occasions I de-quantize parts of materials by moving them ever so slightly, just to avoid snapping everything to rigid 16/16 precision. Adding notes without the quantize is a fun exercise too. Doing this to multiple tracks can easily make a techno/dance/electro song very, very wonky, so use with care.

"Paste at Selection" menu item was confusing at first, as I naturally expected it to paste my previously copied material at a particular point. But this function pastes the copied notes on every selected note, using them as starting point for any pitch difference the original notes might have had. Use the paste icon at bottom left to do a normal paste.

If I drag a number of notes around, they will auto-play (optionally). I used to think this as a distraction, but it becomes a friend eventually, and ideas may come out of it. When playing with a sampler, drum kit or phrase set that triggers different sounds from different note pitches, moving the selection up and down can lead to serendipitous discoveries.

A CC track, and the menu item for adding one

Admittedly, dragging a number of notes around in the graphic editor will reveal the slow speed of an Atari ST GEM and this software. There are also ways to avoid dragging notes around, it's such a post-2000s way of thinking anyway.

Tracks have controller tracks for Program Change, Velocity, Aftertouch, Breath Control, Foot Pedal and Volume, which can be easily invoked. Note velocities are very smooth to change on the VE track, by just holding the mouse key and dragging over the stems in that window.

A CC controller track can also be added, for making Control Change messages. For example, Cutoff and Frequency are some typical CCs to send via MIDI. 

I had to use 2nd mouse button to draw on the CC track. Holding control and clicking, an interpolated slide can be created between two points in time. A segment can be erased by first dragging it over then using the "eraser" icon. (The first at bottom left). This style of editing doesn't work on the velocity stems, they are tied to the notes.

Finding out which CC values are present in a track seems to be impossible from Tiger, once the CC track view is closed. But the KCS Track Editor will list CCs among events, and from there it's also possible to delete all CCs or particular CCs with a filter. Or, indeed, adjust the CC values.

Track Edit, Sequences and the Open Mode

The main screen of KCS Omega is a 48-track MIDI event and note recorder, which functions much like a physical tape recorder might work. If the record button is on, you can auto-record just by pressing a key on the MIDI keyboard. After the recording has reached the end of the track length, a new track is created the recording continues on that, until the process is stopped or the tracks run out.

It can be handy to turn on "Mute new tracks" if the intent is to record the same melodies again and again. It's also possible to undo and re-record the currend (failed) recording.

After a bunch of material has been created this way, it can be edited in the KCS event editor or in the Tiger.

Only recently I've understood what the Open mode and the associated Play Screen could do for me. I didn't likely even see the Play Screen many times in the 1990s, so well it is hidden.

The Main screen

Firstly, I have to click EDIT or press F1 in the main screen to get to the Track Edit screen. From there, I can click on Open Mode. There, again clicking on Play Screen the modest-looking black screen opens, and the pull-down menus disappear.

But how do I add a new track in the first place, if I'm not using the live recording? This was always a little mysterious. Well, in a Track Edit screen, it's possible to click on one of those empty boxes in the grid at the bottom right of the screen. This provisionally creates a track, but I need to manually give some TIME to the only event on the list, otherwise the track won't really exist.

After this, I can again go to Tiger via the main screen and start adding notes there.

Looking at Sequence #2 events, and calculating its end point.

But anyway. If I have a number of tracks, I need to convert the tracks into sequences, and only afterwards I can trigger these sequences live in the Play Screen, aligned into the next measure.

Tracks can be sent from Tiger to become sequences. There it's wise to use the range selector and send that range.

In the case I've accidentally sent a track that only has 2 bars of material, but the track has the length of 8 bars. I can either delete that and use the range-select method, or fix the end point. In the Sequence screen I can go to the last event, which is DE. If I intend the sequence to have 4 bars, I make sure the DE lands at 5:1:1. There's actually a calculator that can help do this computation. 

This rather unimpressive screen is at the heart of KCS.

But wait, there's more.

When the tracks are converted into sequences, they can be turned on by pressing their corresponding key, starting from 1-9 and continuing on to A-Z. After these have been exhausted, 00-99 can be invoked from the numeric keypad, but these may be considered more like secondary material.

And this is actually the reason it's called a Keyboard Controlled Sequencer. D'oh.

And it doesn't end there. Sequences can contain events that trigger other sequences according to various logics, all of which I have not yet even discovered. The simplest way is to add a sequence launch value into the sequence event list (1-9, A-Z etc). The column where it usually says "ON" for a note (TYP), the number or letter of the sequence can be inserted. It can be transposed (NOTE) and played in a different relative velocity (VEL) and repeated a number of times (DUR).

If a W is added to the duration, this means the play waits until the sequence has finished, before playing the next one. If non-waiting sequence is triggered at the same time, it also plays alongside. The W option makes song construction clearer, but honestly a paper plan might help.

If a sequence containing these events is launched from the Play Screen in Open Mode, the sequence itself will trigger the other sequences, relative to its start. In theory, the sequences can produce a cascade of further sequences, but it may be wiser to keep these commands inside one sequence.

Also, the direct launching of sequences is still possible, even if the song is centrally automated.

All content from this range, from all tracks, can be dumped onto a new sequence

I now consider the tracks as more like sketches and snippets, and the Sequences are the real thing, a material from which a song can be constructed either by meticulously chaining them together using command sequences, or by playing them live on the Play Screen. In turn the outcome can be recorded elsewhere, or the MIDI output can be fed back into the Atari and recorded on a new track.

If each sequence only contains a particular instrument, then it's not much different to mixing, muting and soloing the tracks on the main screen. It can make sense to combine multiple tracks into one sequence, which is best done from the Tiger. For example, these could be intro, verse, chorus, bridge and outro. Then the sequences are more comparable to patterns in Soundtracker-type software.

Even though it clearly says "All Tracks", it still confused me that the function sends also the non-visible tracks to the sequence. A defined range from all tracks can be sent to a single sequence, and they get a proper end point for looping automatically. I clarified this to myself using the diagram below:

So, the resulting sequence has elements from all three tracks. I can chop the Tiger-created multitracks into components that have different instrumentation, or traditional song structures. This way, entire song components can be triggered by a single key, and not just mix channels in and out. Other single-track sequences could be launched in order to add nuance or variety. 

Importantly, currently muted tracks are not incorporated into the "All Tracks to Sequence", which can be helpful when building combinations.

Thought needs to go into what would work as a playable sequence. It's easy to paint oneself in the corner by creating tracks, combining them into sequences, and then find out later that for example a bassline needs adjusting. If this is done in the Tiger, the tracks need to be translated into sequences where ever the bassline was used. It may be better to wipe out the sequences and start again.

But if the bassline was kept as a separate sequence, then only the source track for it needs to be changed and translated. Or, using the event editor directly the sequence contents can be changed, closest thing to that instancing of notes I discussed prior.

Using randomized sequence play is an interesting feature, and it can be combined with non-random elements. However, in my experience the randomizer can generate tiny delays between sequences. It's still possible I made some mistake, but if it's a lag in the program I perhaps wouldn't record the audio output, but record the MIDI somehow and then adjust any problems in it.


Is it perfect?

I've now made it sound KCS Omega is some kind of hidden ultimate sequencer, with no flaws in sight. No mistake, it is a clever piece of software, but some aspects do show its age.

As I'm working with a limited package, there's no way to arrange tracks and elements visually in a song scale. The KCS can be expanded with the MPE, Multi Program Environment. The Tiger editor in fact is one MPE, Mixer and Programmable Variation Generator are also not included.

As a remedy, learning to trigger sequences as KCS events can be helpful, or the song can be created ad hoc in the Open Mode play screen.

Partly because of the MPE model, the overall UI is made from separate screens, and while producing focus, it can also create confusion as one key makes something in one screen and something else in a different context. Some commands invoke dialogues, messages and alert windows, some remain silent.

Although the Tiger is a good graphic editor, it is a little rough at the edges. I can't drag the select box to up and left, I always need to create it from top left to bottom right direction.

Much of this can be avoided by adopting the keyboard shortcuts, which are numerous. 

Copying notes as an instance cannot be done, what I mean that note changes would affect all similar instances. Technically, it is possible to get around this by planning ahead and reusing short note tracks in a KCS event list, triggering them as sequences.

However I'd still need to translate a sequence back into a track before it can be edited in Tiger. Of course a sequence event list can be directly altered manually, technically enabling instances.

The overall structure of tracks and sequences as separate entities does bring some leverage, but it can also produce these situations where I can see "I ought to have" done things differently at a previous stage.

What seems missing is any notion of an "instrument", as events brutally address a MIDI channel and that's it. This can be exactly the kind of simplicity one goes looking after in an old sequencer, but it also means there's no meta-level for making sweeping changes to the instruments.

Don't expect the MIDI to play seamlessly while operating the drop down menus, only the Open Mode play screen is free from menus. There's a setting to make the menus dependent on mouse press, but that can be also annoying. Tiger does decently while adjusting notes, which is enough.

Apart from all this, KCS Omega can be slow at times, especially if Tiger has many notes to draw. A faster ST helps, it won't hurt the tempo/MIDI timings.

Working in 2026

I tried KCS Omega on Atari Falcon, where the legacy video modes would give me med/mono resolution via VGA, and some speed boost. However the Tiger seemed to trash the screen memory in uncomfortable ways, making icons and UI invisible, otherwise it looked very nice. 

Turning the blitter off did not help. The glitching could be due to the Multi-Program Environment memory allocation scheme, as the main KCS works.

Also, the fan inside Falcon is so loud it would annoy me. An Atari ST is silent.

Just to show how the mono resolution looks like

I have an Atari STE with ACSI2STM, a tiny board that helps plug a Micro-SD card into the hard drive socket of the Atari. (This is not compatible with the Falcon.)

KCS Omega does not have an installer. The folder and containing sub-folders and files can be copied directly to the SD card filesystem, and run from there. 

If the files are inside a .msa or .st disk image type image, then Hatari ST emulator can be helpful, as it can open these images as disks. 

In Hatari, a folder in the Linux filesystem can be designated as a simulated hard drive, and when the files are copied in the Atari GEM in the emulator to that virtual hard drive, the files will appear on the Linux filesystem instantly. It's a clumsy way to move the KCS files out of the disk images, but it only needs to be done once. Then they can be copied over to the ACSI2STM SD card.

One more Hatari screenshot

This version of KCS Omega and Tiger fit into one floppy, so a HxC floppy emulator can also work.

A little bird tells that holding SHIFT when starting the KCS, will load the Tiger automatically. One of those little masonic rituals.