wow, this is seriously impressive!

What is your background to make all of this possible?

Hello vets,

Thanks for the compliment! I really appreciate that (more than you think).

My background is pretty much defined by the fact that I had absolutely no online presence until yesterday. I usually stay away from modern trends; I am more the guy standing in the background, just watching.

To be honest, I dislike the increasing level of abstraction in every aspect of technology—and life. I work in IT, and I feel that all those rising, endless IT problems we face today are rooted in this cheap abstraction. I am totally stressed out by it. It feels like everything is built on sand, which is just horrible. In contrast, I find my inner freedom in things I can still fully understand down to their very roots. Modern electronics and operating systems can't give me that—modern programming is like cooking with pre-made sauces. It just does not feel real.

With GALAXEUS, I wanted to chop every vegetable and blend every spice from scratch, right down to the bare metal. It was surely about the final result, but it was also about the process—dealing with old hardware and understanding its inner workings. That might not be the reason I started this in the first place, but it is definitely the reason I finished it.

To tell you the truth about why I started it in the first place: when I was an 11-year-old child back in 1981, the magic of computers impressed me deeply. After I saw my very first arcade machine ever—it was inside a showman's caravan at a local funfair in my village—I couldn't stop thinking about it. It was real magic to me, a real wonder before my eyes. The game was Galaxian (GALAXEUS... you see? 😉). That exact moment was where my fascination for computers began, and after all these years, I just had to bring that specific feeling back to life once in a while to keep my mental batteries charged.

Funny thing: in the early years of making GALAXEUS, I was hunting for fast ISA hardware just to get it working. In the later years, I was hunting for the opposite - trying to see how slow the system could go while still maintaining that performance. Classic retro logic: the slower the hardware, the higher the price tag nowadays because of its age, 🤣. You can't make this stuff up -paying extra for slower components. Oh, how the turntables...

For me, in the '80s, there was a real closeness to the hardware: your ear against the case, hearing the tape drive spin, feeling the machine getting warm under your hands, and the static aura of the CRT's glass screen nearly touching your nose. I got my first computer (a ZX81) in November 1982, and those rainy November evenings stayed with me throughout my life: that first-time brightness, and how a small screen could make a little room feel like open space. But the arcade machines in the greasy German Imbissstuben just played in a league of their own back then. At home, we only got pale imitations - clumsy downgrades that never reached that arcade-grade quality. So as a child I always wondered: if you just tried hard enough, if you pushed the machine to its absolute limit, couldn't you achieve that arcade perfection right on your own desk? GALAXEUS grew out of exactly that feeling. I wanted the most control one could think of - the fluid motion, the clean shot - and I wanted to, no, I had to, understand the machine from its roots. Assembly was the only choice: directly optimized, with an OCD-ish attention to detail, where every single line of code is so close to the hardware you can almost feel its heartbeat.

So that's my background. If you asked for my professional background, it is actually much more boring: I am a graduate biologist with an interdisciplinary degree combining Biology and Systems Science. Today, I work in IT at the University of Osnabrück's data center, but I am not a professional coder. I am a full-time System Administrator dealing with storage, virtualization, and backups. I code my own tools in C, C++, and Shell of course. When it comes to professional coding, I am a self-taught autodidact; my real strength is that I have ideas when others only see a dead end.

Greetings from Germany,

Stephan

this is very impressive indeed - considering you also get this performance with an 8bit OAK vga that is considered junk for anything other than a XT system
kudos!
I will look forward to try it when it gets released!

Hey keropi,

Thank you! And thank you for the interest. This keeps me going. I am currently preparing everything for the downloads. I'm still polishing up the readme.txt and the game tools need a bit of polish, too. But things are moving along!

Right now, I am going through my precious hardware collection (which my wife refers to as "the junkyard") to test different motherboards and VGA cards. I still even have to re-test my old Sound Blaster 1.0 with all its possible IRQs. It worked perfectly last year, but I've made quite a lot of changes to the IRQ handler since then, so wish me luck! If all goes well, I plan to release the 64k ROM (GALXEUS.BIN), the PC Booter (GALXEUS.IMG), and the DOS version (GALAXEUS.COM) on 16.08.2026. I will also include a full compatibility list of all the VGA cards, NICs (for the Boot ROM), and mainboards that successfully survived my testing 😉

Greetings

Stephan

This is definitely going on my Commodore SX25 when I get a chance to install and run it.

Hello Sneakernets,

Thanks for your interest. That gives me exactly the motivation finish the project. I need four more weeks – after 30 years, I refuse to release something that isn't fully baked. This here is just a probe to see if anyone even gives a byte about my stuff.

Look, I know no software is ever perfect. Maybe RollerCoaster Tycoon is, but Chris Sawyer is an Assembler entity sent to us from a parallel universe, and I’m just a mortal with a keyboard. For instance, right now, the BLASTER var in the DOS version has to be fed manually via the command line. It’s ugly. It's amateur. It's totally non-feng-shui, and it’s definitely not good code-fu. I need to fix that so command line arguments only overwrite an existing setup, instead of acting as life support.

While I’m at it, I’m also compiling a definitive list of vintage hardware that GALAXEUS actually runs on. So far, I haven't found any regular desktop hardware that fails. However, portable computers with built-in LCD screens are struggling – their vintage LCD controllers just refuse to handle 67 Hz, though 60 Hz works perfectly. I thought about adding a /60Hz switch, but nah, I’ll keep it as it is. If they die, they die, 🤣.

I also need to whip the readme.txt into shape with some clean, solid English, arguing with a narrow-minded, humorless AI until we're at each other's throats, just so I don't look like Forrest Gump trying to explain a DOS config, or on the other side of the skale like Rain Man because the AI and me are.not.smart.men. 🤣

I really takes really longer as I thought to test my old hardware collection. Each Mainboard, RAM in the right sockert, BIOS settings, it takes so much longer than I thought. I am on vacation and praise the Lord the weather is bad in Germany! Wife has no problems we're both doing indoor stuff - perfect.

Greetings

Stephan

Pling wrote on 2026-07-19, 19:38:

While I’m at it, I’m also compiling a definitive list of vintage hardware that GALAXEUS actually runs on. So far, I haven't found any regular desktop hardware that fails. However, portable computers with built-in LCD screens are struggling – their vintage LCD controllers just refuse to handle 67 Hz, though 60 Hz works perfectly. I thought about adding a /60Hz switch, but nah, I’ll keep it as it is. If they die, they die, 🤣.

This is the type of coding I live for. It gives me great joy to know that some are still working in this late year of 2026, pushing the old hardware to its limits, optimizing code, and working in Assembly. It is really becoming a lost art. I thank you for this pursuit. Truly amazing work.

As to a 60 hz setting and a /60 flag, I highly recommend that you reconsider. I do not think any laptop made in the last 20 years will run at 67 hz with their LCD screens, which are usually stuck at 60 or 70 hz in bare metal DOS. The customized resolution of 544x480 is highly impressive for an 8-bit ISA VGA card with 256kb of VRAM. Your goal is admirable in supporting old systems, but I think a "compatibility" mode for new systems should also be considered for folks like myself who don't want to spend thousands on vintage hardware, but still would like to appreciate your magic on a $50 laptop. At this point, the oldest x86 desktop system I have that still works is a P5 233. And it might be dead by now, for it's 30 years old by now.

(I've got dozens of cheap "modern" laptops, however which happily run bare metal DOS when booted from a USB stick! DOSBOX is not my cup of poison. I still use DOS bare metal on "modern" systems as much as I can).

Once again, thanks for sharing GALAXEUS with the community and for being brave enough to espouse your techniques and coding knowledge here. I'm very impressed.

Impressive, very nice 😀.

What is the reason to run it at 67Hz?

zyzzle wrote on 2026-07-20, 03:39:

As to a 60 hz setting and a /60 flag, I highly recommend that you reconsider. I do not think any laptop made in the last 20 years will run at 67 hz with their LCD screens, which are usually stuck at 60 or 70 hz in bare metal DOS.
(I've got dozens of cheap "modern" laptops, however which happily run bare metal DOS when booted from a USB stick! DOSBOX is not my cup of poison. I still use DOS bare metal on "modern" systems as much as I can).

This is the type of coding I live for.

Hello zyzzle,

I'll definitely reconsider. It would be pretty easy to parse for a /60 Hz switch and set this frequency for the DOS version. For the Floppy Booter it would be much harder, as it must be squeezed into the 512-byte GALAXEUS boot sector loader and config code. There is only one byte of free space left - seriously, no joke! 😀. And since the fixed 67Hz timing dictates the game speed, running it at 60Hz makes it way too easy. Still, there's a certain charm to running it on old mobile hardware. I actually own an old Dolch Portable 386 that just couldn't handle the 67Hz - and that's been bugging the hell out of me for years now.

And this kind of coding is exactly what keeps me going, too. I’ve always had quirky interests since I was a kid. You could say football was completely off my radar while I was busy with sci-fi stuff. Luckily, I wasn't an outcast, but there was simply no one around to share my early interests with. Fortunately, I had a brother who was 16 years older - an engineering student by this time - who answered my weirdest questions.

Greetings

Stephan

I have a 386SX running at 16mhz, but with a much quicker VGA card than the Oak you've been testing on. What would you expect in terms of performance, is GALAXEUS more CPU or VGA bound at the moment?

Thandor wrote on 2026-07-20, 06:20:

Impressive, very nice 😀.

What is the reason to run it at 67Hz?

Hello Thandor,

thank you fro your friendly words. The reason for the 67Hz is, that on IBM-compatible VGA chipsets, you can set something called the master hardware clock .

00 = 25.175 MHz (default for standard 640x480 graphics)
01 = 28.322 MHz (reserved for 720-pixel wide text modes, like 720x400)
10 = external <- that's where you have to drop the code and heat up the soldering iron 😀
11 = ?? 1.21 Gigawatts? summons Cthulhu?

When you change the pixel clock via the Sequencer the absolute frame grid remains exactly the same. Switching the clock source in the graphic modes to the text-mode oscillator, the graphics card spits out frames at accelerated speed. It's a 12.5 % faste rate, actually exactly 67,43 Hz every CRT and TFT can handle this. In the code it looks this:

; adjust pixel clock
cli ; IRQs off, when the Sequencer Controller is on its tuning spree
mov dl,0C4h ; DX = 3C4h I/O sequencer controller
mov ax,0100h ; sequencer: start synch. reset
out dx,ax ; note: when changing VGA clocking always reset

; boost vertical refresh rate up to 67.4Hz at 640x480
mov dl,0CCh ; DX = 3CCh VGA miscellaneous output register 3CCh/3C2h
in al,dx ; AL = current clocking configuration byte
and al,11110011b ; AL = clock select bits masked out
or al,00000100b ; set clock to 28MHz (xx=01: 28MHz, xx=00: 25MHz)
mov dl,0C2h ; DX = 3C2h (VGA misc output write port)
out dx,al

And this following code can get one even further. It reduces the horizontal total, which works very well with CRTs but really stresses out most TFTs,
that may fail to center the picture properly and it causes other weird TFT issues like drifting the border color into a not-quite-black border.

The code:
; further attempts to pimp the refresh rate (unused due to vandalism)
; achieving a clean custom 70Hz mode would be the Mona Lisa of broken VGA timing, but sadly TFTs prefer chaos over art on these settings.

; mov dx,03d4h ; exceeding 67Hz disrupts flipclip
; xor ax,ax ; (we do not want to go above 67hz/67fps anyway)
; out dx,al
; inc dx ; dx = 0x3d5
; in al,dx ; get horizontal total in al
; sub al,4 ; reducing horizontal total increases the refresh rate
; out dx,al

Greetings

Stephan

vetz wrote on 2026-07-20, 08:10:

I have a 386SX running at 16mhz, but with a much quicker VGA card than the Oak you've been testing on. What would you expect in terms of performance, is GALAXEUS more CPU or VGA bound at the moment?

Hello vetz,

I am quite sure it is VGA-bound. The slower the VRAM, the more likely it affects performance - and actually, it's still quite easy to reduce the CPU cycles. Even in this state of optimization, there is still some breathing room. For example, I am using a very small Sound Blaster DMA buffer of only 44 bytes, which fires 250 mixing IRQs per second. I have my reasons for this tiny buffer, but it's more aesthetic than practical. When setting the length to 88, 166, or even 220 bytes, there is no sound delay anyone could possibly notice, but it results in much less IRQ overhead. A 220-byte buffer would mean a maximum of 20ms between action and sound (and on average even just 10ms, as the buffer is constantly being filled while playing a sample). I think DOSBox uses a massive 1024-byte buffer in its engine by default and nobody complains. I remember this well from my DOSBox INI-orgy days.

Actually I am quite curious about this, I have no 16 MHz 386SX Board to test. If the slow 386SX has a chache, it would be no problem at all. I have no cache and run the RAM with states r/w 1/1 and fast refresh clock (wich makes it even slower). What was the slowest 386sx they made at all? 12 MHz? - nah, I dont think so, or did they, 🤣? But after this post I go though my collection ("the junkyard" ). I recently got a bunch of old oscillators, maybe a board has an oscillator in a socket taht I can change without soldering. When you get the game, I would de happy for a feedback. Actually I would be upset, if there is a regular 386sx system with stadard VGA that could not handle the engine.

Greetings Stephan

PS sorry for writing your nicname wrong in the first comment, I am new here and currently doing 10 things to do at once. I am taking advantage of the bad weather in germany to prepare the publishing of my engine.

zyzzle wrote on 2026-07-20, 03:39:

Pling wrote on 2026-07-19, 19:38:

As to a 60 hz setting and a /60 flag, I highly recommend that you reconsider. I do not think any laptop made in the last 20 years will run at 67 hz with their LCD screens, which are usually stuck at 60 or 70 hz in bare metal DOS. The customized resolution of 544x480 is highly impressive for an 8-bit ISA VGA card with 256kb of VRAM. Your goal is admirable in supporting old systems, but I think a "compatibility" mode for new systems should also be considered for folks like myself who don't want to spend thousands on vintage hardware, but still would like to appreciate your magic on a $50 laptop. At this point, the oldest x86 desktop system I have that still works is a P5 233. And it might be dead by now, for it's 30 years old by now.

Hello zyzzle,
as you recommended, I added the /60 switch. Now I am struggeling if I should add a /70 switch, too. I got it running quite well with 70Hz by pimping the horizontal timing further. But it's more a much complex modification for the VGA init. 70Hz work well with the real CRTs that I tested, but TFTs struggle with the aggessive horizontal Timing, e.g. they come up with borders that are not quite black (the black tends to have a n ugly dark grey touch). Seems the TFT controllers have struggle to translate the analog Cathode Ray's behavior to their fixed pixels.

Greeting

Stephan

Thandor wrote on 2026-07-20, 06:20:

Impressive, very nice 😀.
What is the reason to run it at 67Hz?

67Hz were quite easy to achieve via the VGA registers. I even got to higher frequencies and fps like 70Hz/70fps with a more complex VGA setup, but TFTs began to show problem under this stress. CRTs worked well though. I attached a picture: under 70 Hz vertial grey lines maily in the border regions start show up. So I dropped the 70Hz branch completly.

Thanks for your extensive reply 😀.

386SX16 is indeed the slowest available. There are 12MHz 386DX CPU around but they are very rare. All the official documentation from Intel I’ve found states that the 386DX launched at 16MHz.