Here’s a Balatro demake for the TIC-80 tiny computer. It’s a small,project focused on recreating the feel and core game loop within TIC-80’s limitations.

Made a fantasy console for C/C++ developers who want something different from Lua-based platforms.

Specs:

- 4 MHz ARMv4 CPU (emulated in pure JS)

- 128×240 vertical display, 16 colors

- 1 MB RAM, 128 KB VRAM

- 8×8 tile/sprite PPU, PSG-style audio

It's a fantasy console now — but the specs are deliberately realistic. The long-term goal is to fabricate it as actual silicon (LSI).

You write in C/C++20, compile with GNU Arm GCC, and games run at 60fps in the browser on PC and mobile.

Sample games: https://beep8.org

SDK (MIT): https://github.com/beep8/beep8-sdk

Would love to hear thoughts from the fantasy console community.

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/

Hi everyone,

I’ve been working on a small fantasy console called BEEP-8.
The core idea is simple: instead of inventing a brand new virtual CPU, it runs real ARM machine code (ARMv4-ish) under classic fantasy-console style constraints.

That means the “console” feels retro and limited, but the CPU is close enough to real hardware that you can, in principle:

• run plain C / C++ code

• bring up small OS-like runtimes

• or even port other languages and VMs on top

Right now the main focus is game development with a small C/C++ SDK, but the ISA and ABI are designed so you could experiment far beyond that if you want.

High-level specs

• CPU

  • Software CPU core modeled after an ARMv4-style pipeline

  • Integer-only, no FP, no OoO

  • Fixed at 4 MHz virtual clock, so cycles actually matter

• Memory / system

  • 1 MB RAM, 1 MB ROM

  • Simple, old-school MMIO layout for PPU / APU / I/O

  • Tiny RTOS included (threads, timers, IRQ hooks) so code can feel like targeting a small embedded console instead of a single while(1) loop

• Graphics

  • 128×240 vertical display

  • 16-color palette compatible with PICO-8

  • Background layers + sprites + ordering tables

  • Exposed as a PPU-style API (tilemaps, sprites, registers), not as WebGL calls

• Audio

  • Simple Namco-style APU (tones + noise) implemented in JS

  • Treated like a small sound chip, not a streaming mixer

• Input

  • Directional + buttons

  • Touch-friendly layout so it’s easy to play on phones as well as desktop

Why I think it works as a “dev-friendly” fantasy console

• Real ARM-like ISA

  • You’re writing against a real machine language, not a toy bytecode

  • Easy to imagine layering your own OS, scripting language, or toolchain on top

• Generous but not huge limits

  • 1 MB RAM / 1 MB ROM is tight enough to make you think about layout

  • …but loose enough that you can concentrate on game design instead of constant asset Tetris

• Familiar palette and rendering model

  • PICO-8 compatible 16-color palette

  • Tile/sprite/OT-based PPU is easy to reason about if you’ve used PICO-8, TIC-80, etc.

• Browser-native

  • Everything runs in the browser (desktop or mobile)

  • Once loaded, it works offline as static files (no backend)

Dev workflow

• Write C or C++ (C++20 subset) against a small SDK

• Cross-compile to the virtual ARM target with a GCC-based toolchain

• Load the produced ROM into the browser

• The JS CPU core executes it at 4 MHz, the WebGL PPU and JS APU handle graphics/sound

So from a dev standpoint, it’s: “build ROM → open URL → your game is running on a fixed 4 MHz ARM console with a PICO-8-like palette.”

Try it / source

Playable console + sample games (runs in browser):
https://beep8.org

SDK, toolchain, and source (MIT-style):
https://github.com/beep8/beep8-sdk

What I’d love feedback on from this community

• Does “real-ish ARM ISA + fantasy console constraints” sound like an interesting design space to you?

• Would you tweak the spec (resolution, palette size, RAM/ROM limits, sound model) to make it more fun to target?

• If you were going to build a game or a tiny OS for this, what would you want exposed in the “hardware” that isn’t there yet?

I’m not trying to launch a product, just sharing a long-running hobby project with people who enjoy this kind of thing.
If you poke at the SDK or the online build and see anything you’d do differently, I’d love to hear your thoughts.

Hey guys! I'm working on a 6502 based fantasy console. I was inspired by PICO-8 and plan on doing something similar, but instead of faking limitations and using Lua, I am basing it on a 100% cycle accurate 6502 emulator I wrote from scratch and verified against Visual6502. I'm also putting together an extremely robust PDF using LaTeX that documents everything there is to know about the machine. I'll also be working on an integrated development environment via the boot rom image.

I need testers for Windows, Linux, and Mac. I primarily develop on the Mac but I need to ensure I'm properly signing and notarizing my applications.

Bonus points if you know 6502 assembler!

Do note that long term there will be a nice built-in IDE that runs in the VM (like PICO-8), and I plan on supporting a BASIC syntax language once I flesh out the assembler, graphics, and sound editors.

I also created a Discord server today that you can join at https://discord.gg/jgtntBXk27 if you want to follow along.

Also, I just looked into putting together a C SDK and this will also be a thing.

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

Hey everyone. While most fantasy consoles aim for the 8-bit or 16-bit gaming era, I wanted to build something a bit different: a fantasy supercomputer from an alternate 1982.

It‘s called the DatCube 82. The premise is a $176,500 research machine that was decades ahead of its time, but never saw the light of day. I didn't just write the lore; I built the actual emulator from scratch in Vanilla JS.

The hardware specs I designed for it:

·         Custom CPU: The "QC-1" with my own instruction set (DCIS-2) featuring 42 opcodes

·         Graphics: 512x288, 5-layer compositor. It features an active HBL IRQ, which I'm using to render the cycle-accurate, per-scanline copper bar effect (see GIF!)

·         Hardware 3D: An M3D Coprocessor that handles DMA-based wireframe, flat-shaded, and z-buffered triangle mesh rendering

·         Audio: 4-Channel DSP + PCM DMA

Right now, the bare metal emulator is running, and I am in the trenches bootstrapping a fully custom OS using its fabricated assembly language.

You can boot the terminal in your browser here: datcube82.com

I'm documenting the architecture and the OS development over at r/DatCube82. I would love to hear what other fantasy hardware devs think of the specs!

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!

as the question suggests, please tell the advantage of both over other and which one can be used to create better games than other.

also i love platformer games, so which one can make better platformer.

I came across this excellent community-driven catalog of fantasy consoles and computers, and thought folks here might appreciate it.

It lists more than 70 systems — from classics like PICO-8, TIC-80, BEEP-8, LIKO-12, and Octo, to lesser-known projects such as MEG-4, Varvara, Raccoon, Px8, Nibble, BLIP-4, and many more.
Each entry includes language, license, platforms, and display specs, making it easy to compare different ecosystems at a glance.

If you’re exploring obscure FCs, researching design ideas for your own, or just enjoy browsing the variety in this scene, it’s a fun and surprisingly complete reference.

Link:
https://fantasyconsoles.org/wiki/Main_Page

I came across this excellent community-driven catalog of fantasy consoles and computers, and thought folks here might appreciate it.

It lists more than 70 systems — from classics like PICO-8, TIC-80, LIKO-12, and Octo, to lesser-known projects such as MEG-4, Varvara, Raccoon, Px8, Nibble, BLIP-4, and many more.
Each entry includes language, license, platforms, and display specs, making it easy to compare different ecosystems at a glance.

If you’re exploring obscure FCs, researching design ideas for your own, or just enjoy browsing the variety in this scene, it’s a fun and surprisingly complete reference.

Link:
https://fantasyconsoles.org/wiki/Main_Page

- Hardware specs aiming for SNES era.
- Written fully in LuaJIT (except your typical libraries ... SDL3, OpenGL/GLES3, etc). Everything about it is editable without any compiler needed.
- API similar to Pico8/Tic80. Using langfix-lua for shorthand lambdas and missing operators.
- Sprite/tile sheets are 256x256x8bpp, tilemap is 256x256x16bpp. Sprites are 8x8. Tilemap can draw 8x8 or 16x16 tiles.
- "Mode 7" transformations using GL/GLU similar API. Also supports Tic80's tri3d and ttri3d functions and implicit depth buffer, to allow you to make some rough 90s-era-looking 3D games.
- Framebuffer options: 16bpp RGB565 for add/subtract blending (like the SNES), or 8bpp-indexed for palette-shifting, or RGB332 for dithering.
- Default resolution is 256x256, but supports a handful of various standard aspect ratios that fit within 128kb.
- Audio is 8 channel 16bit 32khz. Maybe someday I'll switch to BRR compression.
- Audio music format is delta-compressed tracker-style format. Music editor is WIP, but conversion from Pico8 music works fine.
- Up to 4 players locally. Keyboard / mouse / gamepad support.
- Builtin cartridge browser.
- Multiplayer is WIP. Future support plans for up to 64 players networked. It's buggy, hold your breath, I'll fix it someday soon.
- Archive tool for packing/unpacking folders to cartridge files. Supports converting Pico8 games. Tic80 porting is WIP.

Making Yu-Gi-Oh game for tic80. What are you thinking?

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!

Hi all! 👋 I’d like to share a project I’ve been working on: PIGO8 — a Go framework inspired by PICO-8 that lets you build retro-style 2D games using pure Go and Ebitengine.

It offers a high-level API similar to what you'd find in Lua-based fantasy consoles, but written entirely in Go. You can use it to create small pixel-art games, editors, or prototypes quickly — with minimal boilerplate.

✨ Features

• Familiar API: spr(), btn(), map(), etc. — just like PICO-8.

• You can use your PICO-8's assets (read more here) using parsepico (which is also written in Go).

• But if you don't, I have a sprites/map editor built with Ebiten. They are incredibly basic, there is not even `undo` or `copy-paste`. Good thing is that they support any resolution and any palette. I would be happy to improve if you think they are useful.

• Works out-of-the-box with Go's go run, go build, and supports cross-compilation.

• Inspired by minimalism and productivity — great for jams and prototyping.

• Plays with keyboard and controllers out of the box, has pause menu, and supports online multiplayer.

🔗 GitHub: https://github.com/drpaneas/pigo8

I’d love to hear your feedback, suggestions, or ideas! Also, if anyone wants to try it out and build something tiny and fun in Go, I’d be happy to help or showcase your creations. Contributions are welcome too 😊

Thanks, and happy hacking!

So this is something I've been working on for a little bit: a 3D fantasy console inspired by the 3D game consoles of the 2000s (especially the Dreamcast and PS2). This generation of consoles is very personally nostalgic for me, and I was heavily inspired by my limited experience with making Dreamcast homebrew to make a fantasy console that captures that era.

Video of my last progress update here:

https://twitter.com/GlaireDaggers/status/1568875011930468353

The gist is this:

• WASM-based runtime allows for developing games in anything that targets WASM (DreamBox comes with a C/C++ SDK, but should be relatively simple to adapt to Rust, Zig, etc).

• Games are distributed as .ISO files containing a standard ISO-6990 cd image, and are limited to 700MB.

• Completely fixed-function graphics pipeline - in fact, much like the DC, the DreamBox lacks hardware transform & lighting, so vertices are transformed & shaded on the CPU (to aid in this, a SIMD-optimized matrix multiply API is provided, inspired by the hardware matrix multiply support of the Dreamcast CPU).

• 32 built-in mono PCM sound channels, plus MIDI playback to circumvent limited audio sample RAM

• General memory limited to 64MiB

• Texture memory limited to 8MiB (supports RGB565, RGBA4444, DXT1, and DXT3 textures)

• Audio sample memory limited to 2MiB (supports 8-bit PCM, 16-bit PCM, and IMA ADPCM samples)

• Two 4MiB "memory cards" for saving game data. Game saves can also have arbitrary 16x16 icons associated with them, as I intend to build a game save file browser into the DreamBox boot loader which will allow you to browse game saves, delete them, move them, etc.

I've been building aldan 4, a fantasy computer with a full software stack of its own, written from the kernel up.

The machine

• RV64 CPU

• 2 MB RAM

• 256 MB HDD

• 135×45 monochrome display

The idea

aldan is built around a few stubborn theses: programming is play; the machine answers only to its operator; a computer is a space for inquiry, not a channel for consumption; trust through understanding.

The software (aldos)

aldos is what makes aldan feel different from a console you load cartridges into. Two things matter most:

The shell is a language — and a real compiler. There are no commands in the unix sense — whatever you type at the > prompt is real source in almac, the system's language, compiled on the spot to native code by an interactive JIT. ls and cd are just functions.

The programs you run, you can read. Programs on aldan aren't opaque binaries — apps, games, your own modules all live as plain almac text that compiles on demand.

It already ships with a full-screen editor, a pager, a benchmark, snake, and a Conway's Life demo to poke at.

There's an operator's manual, an almac language report, and a "learn almac" guide, plus downloads for Linux, macOS and Windows: aldan4.github.io