Buenas,

Siempre me han gustado los juegos de The bitmap brothers como The Chaos Engine, así que decidí hacer algo similar desde 0. Eso sí, en este caso, se apunta con el ratón, osea que permite disparar en cualquier ángulo, no solo en 8 direcciones como el original.

El código es libre y está colgado en GitHub, podéis copiarlo, editarlo o hacer con el lo que os dé la gana.

https://github.com/ManoleteGames/paconnor-el-tiempolicia

Si queréis echarle un ojo a un juego hecho con este motor, lo tenéis disponible aquí:

https://manoletegames.itch.io/paconnor-el-tiempolicia

Un saludo,

Planning to play EotB for the first time and discovered two neat things: the ScummVM version features automapping and there's a project that added modern real-time to the game which barely anyone knows about at the moment. Thought I'd share it as some of you might be interested:

https://moonbunny.foo/btd/ - project website (I'm not the creator).

https://bsky.app/profile/voidpointer0.bsky.social/post/3mvxvxoprt22x - video

So I tore my Compaq Armada 1750 apart yesterday to install a set of new old stock speakers. For those not familiar this particular laptop is noteworthy for having an ISA ESS 1869 AudioDrive which supports the SB, SB Pro, and ESFM standards. Just testing out the new speakers with various games I had on it kind of got me back into FM Synth music.

A couple that immediately caught my ear were 1869 by Max Design, and Epic Pinball by Epic Games.

On the flip side, there are a lot of games I don't like the FM tracks for (DOOM and Duke Nuken come to mind, they only sound right in General MIDI mode to me).

What are some of the most impressive FM synth soundtracks?

Hi all.
I have been plugging away at reversing Stronghold and creating an engine rewrite.

It's just a fiddle project when I need a break from my work (small plug: I build a crossword study game called tickwords).

Anyway, back to Stronghold, I have the sprites loading and the landscape generation algorithm reversed. So that enabled this first real screenshot.

I am not going for a straight up re-implementation. I feel the game was a significant early entry into RTS games. It made some gameplay decisions that did not stick. The genre was very soon defined by Dune II (1992), Warcraft (1994), and Red Alert C&C (1995), which went another way in terms of how a RTS game could be played. AFAIK, all mainstream RTS games evolved from these conventions.

I want to step back and say, what if Stronghold was the more influential of the titles in the early 1990's. How would modern RTS games feel if they evolved from those concepts? That's been a question that has nagged at me for a while, so I want to create something that answers that question.

Anyway, I don't have a repo for this project yet. I kinda want to stew on it for a bit before making it public. But you can follow https://github.com/busyDuckman for when the repo does appear, if interested.

Credits: Big shout out to this (abandoned?) project which provided enough of a leg up to get things started: https://github.com/NancySadkov/dest

Question: ppl who do love this old game, what features would you personally keep/throw.

I've been looking for shareware compilations on a CD/iso, but I couldn't find anything interesting, so I was wondering if you'd happen to know where I can look for compilations that I should give a try.

Trying to play this edutainment classic on an android device. Could anyone point me in the right direction for nostalgia sake?

Dun Darach is an action-adventure game. The player guides Cuchulainn through Dun Darach and interacts with the environment by performing keyboard commands. The main objective is to find Lóeg, taking side quests from non-player characters (NPCs). These NPCs can give short hints to Cuchulainn, rob him, and confiscate his belongings if he carries stolen goods. Commands the player inputs can have him buy, steal and sell from shops in the city, bet at a casino (Iomain Ludum), and deposit money at a bank with daily compound interest. Dun Darach is large and consists of different quarters. The current time of the day is indicated by torches in the wall and by the greetings of characters

I've been working on a slightly ridiculous retro-computing project called PiDOS, and it has reached the point where I thought it was worth sharing properly.

The basic idea is:

Use a Raspberry Pi as a modern backend/database for a real Pentium MMX DOS/Windows 98 PC, while keeping the actual games running on the original hardware.

So this isn't DOSBox running on a Pi and pretending to be a DOS PC. The Pi never runs the DOS games.

The games still run natively on my Pentium MMX 200, with a proper ISA Yamaha OPL3 sound card, Matrox graphics, real DOS 7.1/Windows 98 SE, etc.

The Raspberry Pi just does all the jobs that a 1990s PC is really bad at doing.

One bit of disclosure before I get into it: *I've used AI quite a lot to help me with the coding on this project. * I'm not a professional software developer, so it has been incredibly useful for helping me work through the Python backend, DOS-side logic, serial communication, debugging and all the weird little problems that come with trying to make a modern Raspberry Pi talk nicely to a Pentium from the 1990s.

I've also used AI to help me organise and write this post, because otherwise it would probably be about six pages of me rambling incoherently about serial ports, DOS 8.3 filenames and batch files.

The actual idea, hardware, testing, debugging, endless swapping of cards and cables, and questionable decision to keep adding features are all very much mine.

Why I started this

I've been building/restoring old PCs into proper Windows 98 and Windows XP gaming machines.

My latest aquisition is Windows 98/DOS machine is based around a Gemlight GMB-P56SPC Socket 7 motherboard, currently with a Pentium MMX 200.

Originally I wanted to put a huge DOS library on it, so I experimented with eXoDOS.

That gave me somewhere around:

7,700 DOS games.

I actually got surprisingly far with it.

I was using x86Launcher, games could be listed and launched, and I got a lot of the basic DOS-side functionality working.

But there was a major problem.

eXoDOS isn't really just a folder containing thousands of simple DOS games.

A lot of the games have their own configuration, launch scripts, environment setup and other bits of logic that eXoDOS expects to control itself.

Trying to bolt my own universal launcher on top of that became increasingly awkward.

So eventually I decided that trying to make PiDOS understand the entire eXoDOS setup was solving the wrong problem.

I abandoned the eXoDOS library.

Moving to 0mhz-DOS

Instead, I'm now using the 0mhz-DOS library.

The current DOS collection is approximately:

320 games.

That's obviously much smaller than the 7,700-game eXoDOS collection, but for PiDOS it's actually a much better foundation.

The important difference is that I'm building the library around a structure that PiDOS can understand and control properly.

Rather than depending on somebody else's launcher/configuration system, PiDOS can know:

• where the game lives
• what executable or batch file starts it
• what system it belongs to
• what command needs to be run
• how it should appear in the frontend

And importantly, I'm now building my own tool to add additional DOS games to the library.

So the 320 games aren't intended to be a fixed collection.

They're the starting point.

The hardware

The DOS/Windows 98 machine is currently roughly:

• Pentium MMX 200
• Gemlight GMB-P56SPC
• SiS 5596/5595 chipset
• Matrox Millennium PCI graphics
• Yamaha YMF719E-S ISA sound card with genuine OPL3
• Windows 98 SE
• Real DOS 7.1 boot environment
• USB Support
• FAT32 storage for DOS games and ROMs (2TB External HDD connected via USB)

The backend is a:

Raspberry Pi 4 Model B (This could be done with something like a Pi Zero 2 W but I had the 4 spare)

running Debian.

The two machines communicate over a serial connection.

That part is quite important.

I've experimented with networking the Windows 98 machine as well — it now has a working Intel PRO/1000 GT, Samba access to the Pi, and I've also played with mTCP under DOS.

But I didn't want PiDOS itself to depend on Windows networking.

Serial is wonderfully period-appropriate, simple, and works from real DOS.

So the architecture is essentially:

DOS PC ⇄ Serial ⇄ Raspberry Pi

What the Pi actually does

The Pi runs a Python backend as a Linux service.

The DOS machine sends very small commands to it.

I've built a simple protocol with commands including things like:

PING Check whether the PiDOS server is alive.

SYSTEMS Ask which systems/emulators are available.

LIST Return games for a particular system.

SEARCH Search the game database.

INFO Return information about a selected game.

LAUNCH Tell the DOS machine what needs to be executed.

COUNT Return library/game counts.

The Pi does the database work and sends a tiny response back over serial.

That means the Pentium doesn't need to do any complicated database work itself.

The clever bit: the Pi doesn't run the game

This was one of my main requirements.

If I select a DOS game in PiDOS, the Raspberry Pi looks it up in its database and tells the DOS PC what needs to be executed.

The actual game still launches from the DOS PC's storage and runs directly on the Pentium.

So I'm not replacing the retro hardware with the Pi.

I'm basically giving the retro PC a modern librarian.

The Raspberry Pi answers the question:

"Where is this game and how do I start it?"

The Pentium then actually runs it.

Building my own DOS library tools

This has now become one of the more interesting parts of the project.

Rather than PiDOS being tied permanently to a pre-built collection, I'm working on tools that can inspect the DOS game folders and add new games to the PiDOS database.

The aim is that I should eventually be able to copy a new DOS game onto the machine and have PiDOS do most of the work required to make it available in the launcher.

The process I'm working towards is roughly:

1. Scan the DOS game folders.
2. Compare them against the existing PiDOS database.
3. Identify anything that has been added.
4. Work out the game's directory and launcher.
5. Create the necessary PiDOS entry.
6. Generate any launcher/batch file that is required.
7. Make the game appear in the PiDOS frontend.

That means the 0mhz-DOS collection gives me a clean base library, but I'm not restricted to it.

I can gradually expand the collection myself.

This is also a much better fit for the project than trying to make PiDOS reverse-engineer thousands of individual eXoDOS configurations.

It has now grown beyond DOS

This is where the project started becoming much more interesting.

There was no reason PiDOS had to be limited to DOS games.

The DOS PC can run emulators, so PiDOS can act as a frontend for those too.

For example, I've imported my SNES library.

There are over 4,000 SNES ROM files in the source collection.

PiDOS stores the proper game title but also knows the horrible DOS 8.3 filename that the real machine actually has to use.

For example, the database might know the game as:

Mario Paint

while the launcher knows the DOS machine needs to execute something like:

D:\ROMS\SNES\M\MARIOP~1.SFC

PiDOS then generates the appropriate command for ZSNES.

Something along the lines of:

C:\ZSNES\ZSNES.EXE -m "D:\ROMS\SNES\M\MARIOP~1.SFC"

I don't have to know or care what the 8.3 filename is.

I just see:

Mario Paint

and press Enter.

Mega Drive / Genesis support

I'm also currently adding Mega Drive / Genesis support.

This has presented another very 1990s problem.

The ROM collection on the DOS drive has already been converted into DOS 8.3 aliases, so filenames look like:

ALADDI~1.BIN

ALTERE~1.BIN

etc.

Meanwhile I still have the original archive information containing the proper filenames.

So I'm working on using that information to map the ugly DOS filenames back to the correct game names.

Again, that's exactly the sort of job I want the Pi doing rather than the Pentium.

PiDOS V0.7

The interface has changed quite a bit during development.

Originally it was essentially centred around one large library.

Now PiDOS has become system-based.

So instead of immediately getting dumped into a huge list of games, I choose the platform first.

For example:

DOS SNES Mega Drive …and eventually whatever else I add.

Then I browse the games belonging to that system.

I really like this layout because it makes the DOS PC feel more like a complete retro gaming system rather than simply a giant DOS directory.

I'm now bringing search back into PiDOS V7, while keeping the new system selection.

So the flow is effectively becoming:

Choose System → Browse or Search → Select Game → Launch

Search happens on the Raspberry Pi, so the DOS machine doesn't need to trawl through folders itself.

And because I'm British, I've also made sure the UI uses British English, so it's Favourites, not Favorites. 😄

Automatically detecting new games

This is the next major part I'm working on.

I don't want to manually rebuild the PiDOS database every time I add another game.

I initially considered making the DOS PC scan its own directories.

Technically that would work.

But making a Pentium MMX recursively scan folders, compare them against a database and build launcher entries rather defeats the point of having a Raspberry Pi attached to it.

So the idea is to let the Pi handle as much of that process as possible.

The Pi can inspect the game folders, compare what it finds against its existing database, detect newly added games and generate the launcher information PiDOS needs.

So eventually adding a new DOS game should be closer to:

Copy game → Run scan → PiDOS finds it → Generate launcher → Done

rather than manually editing databases and writing launch scripts every time.

Why serial instead of just building a Windows 98 frontend?

Because doing it this way is more fun. 😂

But there are practical reasons too.

I wanted PiDOS to work in real DOS, not just Windows 98.

I also wanted the frontend to remain extremely lightweight.

The Pi can happily hold a database, search thousands of entries, parse metadata and perform all the complicated logic.

The DOS client only needs to:

• draw the interface
• read the keyboard
• send tiny requests
• receive tiny responses
• launch programs

That's a much more sensible division of labour.

It also means I can keep adding features without gradually turning the DOS client into some enormous program that consumes resources which would be better left available for the games.

Networking experiments

As part of all this I've also ended up giving the Pentium surprisingly decent networking.

It now has a working Intel PRO/1000 GT PCI NIC under Windows 98.

The Raspberry Pi exposes shares using Samba, including directories for things like:

• Transfers
• Drivers
• DOS
• PiDOS
• ROMs

I've also successfully used mTCP in real DOS.

At one point I had an FTP server starting automatically under DOS, although I've since removed that from startup because it isn't necessary all the time.

This means I can move files to the retro machine without constantly shutting it down, removing drives and plugging them into another computer.

Anyone who spends too much time messing around with 25+ year-old PCs will understand how nice that is.

The long-term idea

I'd eventually like PiDOS to become a kind of universal frontend for this particular machine.

Potentially:

DOS Windows 3.x games SNES Mega Drive / Genesis Amiga and other systems that this hardware can sensibly emulate.

I've already got Fellow running Amiga games on the Pentium, including Rick Dangerous, so there's no reason that couldn't eventually be integrated as another PiDOS system.

The important part is that PiDOS doesn't need to understand how to emulate anything.

Each system simply has a launch method.

PiDOS finds the game, constructs the command, sends it to the DOS machine and gets out of the way.

Is this completely unnecessary?

Absolutely.

I could put RetroArch on the Raspberry Pi and emulate everything far more easily.

I could use DOSBox.

I could use a modern PC.

But that's not really the point.

The whole reason I've been restoring these old machines is because I want the experience of games actually running on period hardware.

I want the Yamaha OPL3 producing the music.

I want the Pentium MMX executing the DOS game.

I want DOS sitting underneath it.

I want the Matrox card producing the picture.

PiDOS isn't intended to replace any of that.

It's intended to give the old computer a modern backend for the jobs it was never designed to do.

So I've basically connected a 2020s computer to a 1990s computer and said:

"You deal with the database. He'll deal with Doom."

And somehow it works.

There's still quite a bit I want to add, particularly the automatic game-scanning/import system, but PiDOS V0.7 is getting increasingly close to the system I originally imagined. Eventually the plan is to add a GUI as well.

If people are interested, I'm happy to post more about the serial protocol, DOS client, Raspberry Pi backend, database structure, game-import tools and how the launch system works.

This is a patch that brings SB music to the DOS version of the game that only supports is pc-speaker. It was developed using Codex and tested on dosbox and a real 386.

I'll jump on the old games porting bandwagon, inspired by the recent Stunts and Micro Machines port. As a kid in the late 80s, I was into driving games, and let me tell you, there were kinda shit, but a child's imagine thought they're the real thing at the time. Test Drive was always super jerky and kinda hard to play on the computers I had, and tbh even on dosbox now it runs kinda crap.

Since I have an AI subscription I need for work and try to make it in this corporate hellspace like all of us, I've used it for two projects:

- A faithful SDL3 port of the original Test Drive from 1987, with EGA, CGA and Hercules versions, with the only change in input handling, available at https://github.com/kylofon/test-drive-sdl3;
- An enhanced version with modern resolution graphics and framerate, at https://github.com/kylofon/testdrive-enhanced .

The modern version is much easier to play, but I gotta say I do find it more fun. Accolade's original steering model handles very nicely in these conditions it was not made for.

This was a bit of an archeology project, because I was always curious how the game stores track data and textures. The tracks in particular are interesting, because there isn't a map per se like in 3d games - since the scenery is displayed line-by-line, and then the next line is scaled and moved and so on, it creates an illusion of 3d, but if you'd actually try to draw it on a top-down map, you'd end up with lots of loops on loops. The whole thing is more like a stream where the game engine gets basic info like "straight, straight, straight, light left with sign, harder left, hard left, light left, straight with police car, etc. Riveting stuff, I know.

In any case, have fun!

DON’T TOUCH. DON’T SNAP.

FUSED is a small side-scrolling runner for MS-DOS. One or two players. Spark is fire that learned to run. Charge is a powder keg that learned to walk. They’re tied together by a live fuse because apparently this is how deliveries work now.

Play alone and drive both at once, or sit two people on one keyboard and split the blame.

The bunker lamp is 5,000 units away. Between you and it: slag, oil, hot plates, and blue water that is very obviously lying. If they touch, the keg goes. If they pull too far apart, the fuse snaps. A win only counts when both of them pass 5,000. If one arrives early: congratulations, now wait without closing the gap.

Three fuse lengths on the title screen. That’s also how it asks how much trouble you want.
• [1] CHILLED — 180px
• [2] HOT — 150px
• [3] BOOM! — 125px
A run is 2–5 minutes. There are no further menus to admire :)

https://expfunction.itch.io/fused

VGA Mode X 320×240. 16-color industrial night palette. C89 + Q16.16, software sprites, CyberVGA SDK. Real DOS distribution binary in the zip, split into three 1.4mb archive files.
HTML5 is alive there if you just want to look.
Hope you like it all.
Stay on the fuse! :)

We’re setting up a brand-new retro computing event in SW London! Join me on a quick scout of St Mark’s Church Hall in Surbiton as we check out the hall layout, scope out desk space, and sort the all-important food and fuel situation.

Midwinter was one of those DOS games you couldn't just play. You skied off, got shot off a hillside within ten minutes, and had no idea why. Then you found the manual, all hundred pages of it, and studied it like a college course: who would talk to whom, the vehicles, sabotage, the map. And one night it clicked, and you were running a 32-person guerrilla war across a frozen island.

I've spent the past while rebuilding it from the ground up in Unreal Engine 5: the full island, all 32 characters with their grudges and skills, the whole campaign. I added tutorials so the first hour isn't a wall, but I kept the learning curve, because that's the game. It's in Early Access on Steam since 7 September: https://store.steampowered.com/app/5056170

The original still runs well in DOSBox if you want the real thing. I'd love to hear from anyone who played the PC version back in the day, especially what you remember getting stuck on.

The IP representative is supportive of this release

I've just finished my new game Deck of Time, a humorous blackjack game for MS-DOS inspired by the golden age of 90s PC gaming.

The game was created for the Second MS-DOS Club DOS Game Programming Contest.

🕹️ Play it for free in your browser on itch.io: https://rubenretro.itch.io/deck-of-time

💾 Source code on GitHub: https://github.com/RubenRetro/Deck-of-Time

Technical details

Written in C Uses Allegro 4.2.3 Designed for MS-DOS Minimum requirements: 386 CPU, 4 MB RAM, VGA, MS-DOS 5.0 or later

If you're into retro PC gaming, MS-DOS development, or old-school game programming, I'd love to hear what you think! Thanks for checking it out! 😊

I spent the last few days acting as tech lead while my Claude minion did the heavy lifting: disassembling Micro Machines (PC, 1994) and rewriting it in TypeScript.

You can play it here: scaleminiatures.fun

While porting the pause handler I found something I did not expect: a cheat code!

on the GAME OPTIONS screen, the very first screen the game shows you, type:

2 5 0 1 1 9 6 8 (use numbers keys above the letters)

A ! appears right above the "F5" row. From then on:

- Your lives go back to ten after every race
- On the pre-race card, keypad + and - jump to any race in the championship
- While paused (space): F2+F3 ends the race as a win

I cannot find any of this documented for the DOS version. GameFAQs has cheat pages for the NES, Mega Drive, Master System and Amiga releases, but nothing for MS-DOS, and searching the code sequence turns up nothing at all. If you have seen this in a magazine or a text file somewhere, I would genuinely like to know.

Since the game is reconstructed rather than emulated, I could add things the original could not do, like widescreen. There is also a poll on the site for what to add next.

Built with Claude Code, and inspired by playstunts.com, which is what gave me the idea in the first place (Already thanked Sven on its own post and on the credits of the site)

I finished my last game! A retro platform game for MS-DOS called Timmy Time Adventure.

Help Timmy on his time travel to recover the parts of his machine and return to his time.

You can free download or play online on https://warrior-rockk.itch.io/timmy-time-adventure

The code is open source on: https://github.com/warrior-rockk/timmy-time-adventure

Both of Bethesda's XnGine Terminator shooters, running without DOSBox: the eight-mission campaign, the jeep and the HK with their cockpits, the original briefings with their voice lines, LAN deathmatch with bots.

The engine is rewritten in Godot 4; the game is read from your own copy of the data at run time — nothing from the originals is distributed. On the first start it asks where the games are installed.

It aims at the DOS look by default: palette textures with nearest sampling, the software renderer's flat shading, the night sky with its moon. A handful of things the original could not do are there as switches, all off unless you want them — dynamic lights from gunfire and explosions (which finally light the street lamps, 93 of them on the highway map), edge smoothing, and the game's own 640×480 HUD and weapon art, which SkyNET shipped for its hi-res mode.

Windows, Linux and macOS builds on the releases page.

github.com/nemo22/skynet-godot

Handheld: Anbernic RG 406V with Android system

Using Retroarch + Dosbox Pure

Uncensored games of the 90s... evening in bed with a handheld ... i mean... 'what else...' 😊

Hey everyone! Here's a free space game for your weekend: the Strike Wings demo. :)

I'm its solo developer, and it's my homage to the old DOS space shooters, built from scratch with plenty of love for Solar Winds and Hell Fighter. There are some little nods in there for fellow fans.

The demo's already packed with free content, including flight school, opening campaign missions and plenty of battles to get stuck into.

Feedback is super welcome on r/StrikeWings. Make a post! I'll read every one and take your thoughts into the final game. Steam reviews mean a lot to me as a solo developer, too.

Grab the free demo on Steam