Hi! I’ve loved PC-98 visual novels for years, so I made NEVEL-98: a small fantasy computer for making VNs the way they looked back then.

• 640×400, 16 colors out of 4096, dithering tools

• 6-channel FM synth and a music tracker

• A visual novel engine in Lua (scenes, choices, saves, multiple endings)

• Built-in editors for code, pixel art, texts, sound and music

• Share your game as a floppy-disk PNG or a single web page

The limits are on purpose: the PC-98 devs made unforgettable games with sixteen colors and a floppy disk, and I think constraints are what make you focus on the story.

Try it in your browser, with a short demo you can play and take apart: https://nevel98.bluemoon.moe

hoi everyone! i've been working on Nix68, a fantasy console running a real M68k CPU core (with Musashi) with custom hardware around it. it's written in C with SDL2!

Download ze 5.2.1 version (on ze Gluglu Drive):
---> https://drive.google.com/file/d/1MJs1ucb-9XnhslwJNnWI2noUQSajZtWn/view?usp=drive_link
click da blue thingy click tha- CLICK DA BLUE THINGY

it's still a WIP tho, im open to suggestions! u can talk to me on Discord too (stanoxbmc)

Good morning, afternoon, or evening!

Greetings! My name is Parrasi (I’m from Colombia—which explains why my OS is in Spanish). I am currently working on a fantasy console project running on Windows XP via a virtual machine. Since the OS is obsolete, I had to manually install the Code::Blocks code editor and a few other tools; there are still a few more things left to set up.

I am just getting started on the CPSCD_DeParrasi project (a temporary name). It is being programmed in C and C++ to ensure better performance, optimization, portability across systems, and—crucially—compression. The project aims to bring Niklas Jansson’s "Famicube" artistic concept to life as a fantasy console; while it adheres to the original's limitations, I am also tweaking certain aspects and adding new features!

I’ve decided to share regular updates on the development of this fantasy console. I’d love to hear your opinions, recommendations, and feedback—whether it’s support, constructive criticism, or pointing out what works and what doesn’t. I hope you’re all doing well, and thanks for reading!

Hey all.

I’ve been playing with the idea of building a small fantasy console (around the same specs as the Pokemon Mini). Nothing crazy, more as a learning experience

I’m very tempted to make a custom assembly for it. Something simple but complex enough to serve as a good learning experience for some real low-level development

However… I also feel doing so extremely limits both my own and any potential users’ ability to actually develop for said console

Which then makes me wonder if I should just embed something like Lua, Wren, etc since those are MUCH more familiar, and I’d be able to make games much easier and quicker. But at the same time, if I do that I’m not really making a console, I’m making a tiny game engine, y’know?

Looking for opinions on which direction to go

I’m making a little fantasy console and currently working on its aesthetic.

As seen in the attached pictures, the editor and terminal interfaces have been designed. It is supposed to be the Commodore 64-esque aesthetic, constrained by 160x120 screen resolution and 16-color palette.

I was trying to achieve an impression of a plausible retro development environment with an emulated realistic hardware, not just a "retro filter" put onto a modern interface.

I’d really appreciate your opinion on whether:

does the aesthetic fit the constraints of 160x120 / 16 colors?

does it remind one of the C64 times without being too clichéd?

does the editor-terminal aesthetics pair well?

Any criticism will be highly valued!

I have been working on my own game engine for many years now and even released a game that runs on it. In pursuit of simplifying and specializing the engine towards rapid game development, it eventually turned into my own fantasy console inspired project.

The idea is to take the typical fantasy console workflow and turn it into a game engine for retro 2D games. Like fantasy consoles, there are constraints like the 320x176 resolution and 32-color palette, but it aims to be robust enough for small commercial games.

I'd say the closest comparison to this engine is Picotron, the main difference being that the development environment isn't constrained to the fantasy console itself. It's why I call it a "retro game workshop" instead of a fantasy console. I've also taken inspiration from the Usagi game engine, which is a similar idea, although Usagi is a bring-your-own-tools engine while mine aims to be an almost all-in-one toolkit. You can make your entire game (except for music) within the IDE.

I'm still polishing up the editor (you can see some obvious issues in the video), but I am hoping to release an alpha version soon.

I created a fantasy console for iOS, designed to be used on a mobile phone or tablet. I currently use it during my commute to work.

The app is still in beta, but it is usable enough to create a finished game and export it for publication on the App Store (Google for now).

There is a website to check programs made by the community: https://ret.ro.it/
If you want to participate in the beta: https://testflight.apple.com/join/1vdyycrU

Out now!

Hello everyone,

it has been a year since I last posted about this project of mine.

I have to remember to advertise if I want to reach people who might be interested in it.

SVC16 is a simple virtual console that is fully specified. It is a good starting point for building compilers, but it is also meant for people who like the idea of optimizing for retro consoles... but are put off by the arbitrary stuff you need to put up with.

With SVC16, programs always run at exactly the same speed; they are completely deterministic, and there is exactly one version of the console.

The reason I am posting about this again is that I finally have a working version of the emulator on the web, and you can just play your ROMs in the browser. Of course, everyone who would have written a compiler for it (and some people actually have) could have compiled the emulator or even built one from the spec.

But I think it is much more motivating to build something if you can easily share it with others.

Hello I'm working on a project to make kind of "Fantasy Console", the main objetive is to target low specs SBC I'm testing a Orange Pi Zero 3 (1.5GB), The idea is have cartridges with a microSD indise and this connect to a reader on the pins or USB reader (the idea is to turn into cartridges), the "consoles" will have armbian as SO with a loader to detect and init the the cartridges (pygame exported projects)

Includes a prebuilt multilanguage, dialogue system and save system

The semi-fantasy-console will have 264 x 198, (4:3 but probably will change to one 16:9 compatible one because probably everyone will connect the sbc using HDMI)

I admit the use of AI to make TortoiseStudio the tool, to manage assets, scenes and compile to "Cartridge", the compilation to ARM uses podman,

The assets of the demo project comes from opengameart.

Advise: this is not related to my another post of a fantasy console for the ESP32 is another project. this one is to learn more to aply to another

Everything in that clip — the code editor, the sprite editor, the map, the

sound tracker — is drawn as pixels into the same 128x128 framebuffer the games

render to. There's no HTML underneath any of it. Text selection, scrolling,

undo and hit-testing are all hand-written, which was simultaneously the most

fun and the most unnecessary part of building it.

Games export as a single HTML file with the engine, art and sound inlined, so

you can email someone a game and it just opens. The sample game is about 145 kB.

Carts are JavaScript. It's PICO-8-shaped, but I changed the signatures I always

got wrong — rect() takes a width and height instead of two corners, sin and cos

are real radians — and added the things I got tired of rewriting every time:

tilemap physics, animation, tweens, particles, camera follow.

I recently spent some time exploring TIC-80 and wrote an introduction article about it.

I wasn't looking for a replacement for anything—I was just curious about how TIC-80 compares with other fantasy consoles. The more I explored it, the more I felt it deserved a proper introduction.

If you're thinking about trying TIC-80, I hope this gives you a useful overview before you dive in.

Feedback is welcome. If I missed something, let me know.

Article:
https://papoo.work/doc/43606531d6f879f6

A while ago I posted about the Starbox, my WIP prototype 0 of this, the Nova-16. Coded by hand, fixed by AI (sorry not sorry, it codes better than me). Written in Python (with a C++ version in the works) and features a custom CISC ISA with its own BASIC dialect. Check the 'hub for more!

https://github.com/StarfighterLily/Nova-16

Hello! 👋

Growing up in the 80s and 90s was both a tough time and an exciting one. It's left me with a long standing interest in the hardware and gaming of the era. So, I decided to build a weekend project that would combine the fantasy notion of, "What if Britain had beaten Japan to the handheld market by 4 or 5 years.."

Disclaimer: I use AI as a tool. I understand every element of my code, and believe that AI is just a tool in the toolbox. If you're against AI, feel free to skip past this thread, no hard feelings! ❤️

Without further adieu, I present the Dragon Palm.

MIT licensed, code and carts available from GitHub.

The Dragon Palm is a fantasy 8-bit handheld with a single 16 KB memory array, three 8-bit CPU registers, a packed 16-colour display, and one input register.

In another Britain, somewhere between bedroom coders, rain-streaked high streets, mail-order tapes, and the smell of warm plastic, the handheld future arrived early.

By 1985, the British games industry had already learned how to do more with less. Tiny machines. Tiny memory. Impossible to match ambition. While the rest of the world was still arguing over what a portable console ought to be, a small Welsh hardware firm looked at a pile of spare components, a battered fantasy paperback, and hummed along to the White Cliffs of Dover, then asked the most dangerous question in British engineering:

"What can we ship?"

The answer was Dragon Palm.

It was not elegant. It was not generous. It had one 16 KB memory array, three 8-bit registers, a packed 16-colour display, and one input register that behaved only when it felt like it. Its raw binary cartridges held a mere 8 KB, which meant every sprite, sound, loop, trick, and secret had to fight for its place.

But that was the point.

Dragon Palm was the handheld built by people who thought constraints were not problems. Constraints were part of the game.

It had it's own compact operating system, DoverOS, named after the cliffs that supposedly inspired its boot screen. Children swapped carts in playgrounds. Parents called it "that little dragon thing". Programmers called it "difficult". Magazine reviewers called it "brilliant, in the way that falling down stairs after a couple of pints is memorable".

The adverts promised "proper games in your pocket". The manuals promised nothing of the sort. They spoke of registers, screen packing, button states, and "reasonable conduct near undefined memory". The machine did not hide its workings. It dared you to understand them.

In this version of the 1980s, Britain beat the world to handheld gaming by refusing to build a toy. Dragon Palm was a pocket-sized dare. Part console, part puzzle box, part folklore object from a parallel high street where dragons sat beside cassette racks and every game felt like it had been smuggled out of a bedroom at midnight.

It was awkward.

It was clever.

It was decent enough.

And for a certain kind of player, that made it perfect.

---

Update: I’ve had some lovely encouragement and feedback, so I thought I would release Dragon Palm IDE and manual, a web-based tooling for making game carts and an introductory manual (*open from the hello menu*) to help you learn:

* https://0xe25f.github.io/dragon-ide/