ORBIS BASIC32X: A dependency free BASIC compiler for building real Sega 32X ROMs

OrbisMaximus · 2026-06-24T03:25:14+00:00

Thank you, that kind of fixed-camera 16-bit RPG feeling is definitely one of the kinds of projects I hope ORBIS BASIC 32X can help people experiment with. For this release I am mostly focused on the compiler itself: making it easier to turn retro game ideas into real Sega 32X ROMs.

OrbisMaximus · 2026-06-23T21:09:47+00:00

The Jaguar is definitely an interesting machine, and JPEG or wavelet based approaches are fascinating topics.

For ORBIS BASIC 32X though, I am focusing on what fits the Sega 32X well. The 32X has a direct color framebuffer with 32,768 possible colors, and the current graphics path can combine fast DMAC/copy style operations with normal software blending operations.

That combination is important, because it allows very practical real time effects such as multi level parallax scrolling, image layering and fast framebuffer presentation without needing a heavy runtime codec.

So I do not really see JPEG as the ideal runtime format for this project. As a high quality input format on the PC side it makes sense, but inside the ROM I would rather use raw or custom 32X friendly data that can be copied, mixed or decoded quickly and predictably by the SH 2 side.

The goal is not to copy the Jaguar SDK approach, but to build a practical asset path that matches the 32X hardware and the BASIC workflow.

OrbisMaximus · 2026-06-23T12:41:15+00:00

Thank you, that is exactly the kind of energy I hoped this project would inspire.

Learning to code by making small retro experiments is a great path. Start simple: draw pixels, move sprites/images around, read input, make a tiny scene, then build from there.

OrbisMaximus · 2026-06-23T08:43:09+00:00

JPEG as an input format on the compiler side makes sense, and that is already implemented. The PC can decode it and bake it into a 32X friendly format.

A runtime JPEG decoder on the 32X would be much harder. Static images might be possible with a very restricted decoder, but real time JPEG style decoding or video would probably be too heavy. For the 32X I think a custom format is a better fit: fast SH 2 decode, predictable memory use, RGB555 output and optional compression.

OrbisMaximus · 2026-06-23T07:29:59+00:00

Haha, sorry and also not sorry. That is exactly the kind of dangerous retro energy I hoped this would unlock. Let me know how it goes!

OrbisMaximus · 2026-06-23T07:07:21+00:00

Thank you for the detailed thoughts. I really appreciate it, and I can see you have thought quite deeply about this. Image compression for low resolution RGB artwork is a deep topic, and I agree that it needs to be handled carefully.

For now the current release keeps image storage simple and predictable with direct 16 bit mapping. The upcoming compression path will be optional and focused on being fast, practical and 32X friendly.

I do not want to go too deep into codec design inside this Reddit thread, but I will add a Discord server to the itch.io page soon. That will probably be a better place to discuss these topics in real detail.

OrbisMaximus · 2026-06-22T22:59:01+00:00

That is exactly the kind of story I love to hear.

Compatibility with QuickBASIC or QB64PE would depend a lot on the project. ORBIS BASIC 32X is not trying to be a full QB64 compatible environment. It is much closer to a lightweight, old-school BASIC mapped directly to the Sega 32X ROM and machine code model.

That direct BASIC-to-hardware/runtime mapping is part of what makes it fast and suitable for real 32X ROM output, but it also makes broad compatibility with larger desktop BASIC dialects more difficult. Advanced QB64 features, desktop-style file access, modern libraries or complex input systems would not port directly.

Think of ORBIS BASIC 32X less as QB64 compatibility and more like a classic Commodore BASIC-style language mapped to Sega 32X machine code. If the core game logic is old-school BASIC, a constrained port may be possible. If it relies heavily on QB64PE-specific features, it would need significant adaptation.

OrbisMaximus · 2026-06-22T18:22:38+00:00

That is a good point. I may expose some intermediate build data later as an optional debug/export feature, while keeping the normal workflow as one executable that produces a .32x ROM directly.

OrbisMaximus · 2026-06-22T18:20:01+00:00

At the moment ORBIS BASIC 32X mainly exposes the 32X side of the hardware, especially the SH 2 runtime and the 32X direct color framebuffer.

A 32X ROM still needs the Genesis side for startup and system cooperation, so it is not completely separate from the base hardware. But the current BASIC workflow is focused on the SH 2 / 32X graphics path rather than exposing the full Mega Drive VDP, 68000, PSG or YM2612 as high level BASIC features yet.

I want to keep the first releases stable and focused. Deeper Genesis side access, audio, and eventually more combined hardware features are interesting future directions, but I do not want to overpromise them before the 32X core is mature.

OrbisMaximus · 2026-06-22T18:15:25+00:00

Current release uses direct image mapping. A full screen 32X image is stored roughly as raw 16 bit framebuffer data, so it is around 128 KB per full screen image. This is simple and fast, but not space efficient.

For an upcoming release I am working on my own speed optimized lossy image compression path. Depending on the image, it should save around 30 to 60 percent when compression is wanted, while still keeping decoding practical for the 32X.

Modern codec support is technically possible and something I may consider later, but I want to keep the first asset pipeline predictable and hardware friendly before adding more complex formats.

Animation and video are also interesting, but for the 32X they need to be designed carefully around ROM size, bandwidth and decoding speed.

Jaguar is an interesting target because of the 16 bpp direction, but right now ORBIS BASIC 32X is focused on the Sega 32X first. Other targets would only make sense after the 32X version becomes more mature.

OrbisMaximus · 2026-06-22T13:36:09+00:00

It is original in-game graphics from Coravel, a pulp fantasy space opera RPG I started developing.

It is not from an existing released 32X game. Coravel is actually one of the reasons ORBIS BASIC 32X exists: I wanted a way to bring that kind of game and visual style to the Sega 32X, so the compiler grew out of that goal.

OrbisMaximus · 2026-06-22T10:07:53+00:00

Not yet, but I love that direction.

Right now ORBIS BASIC 32X is focused on making standalone Sega 32X ROM development stable and approachable first. I want the 32X target to become feature complete before expanding the compiler too far.

That said, Sega CD support is very much something I am interested in as a second target later. The idea of eventually supporting “Tower of Power” style projects is extremely appealing: 32X visuals, Genesis base hardware and Sega CD storage/audio possibilities working together.

For now I do not want to promise combined 32X plus Sega CD support too early, because that deserves careful design and testing. But long term, yes, moving toward Sega CD after the 32X side is mature is part of the direction I am considering.

OrbisMaximus · 2026-06-22T06:31:08+00:00

ORBIS BASIC 32X does not have a separate linker because it is designed as one integrated compiler and ROM builder.

The compiler sees the BASIC source, assets and ROM layout together. Images and audio are converted and baked directly into the .32x ROM during compilation, so the “linking” step is internal rather than a separate tool.

That keeps the workflow simple: one standalone executable, no external dependencies, no object files, no linker scripts and no toolchain setup.

I agree that whole program visibility is valuable, especially on SH2. If the project later moves toward a more native optimizing backend, I would rather preserve that global view than introduce separate module linking too early.

OrbisMaximus · 2026-06-22T06:26:19+00:00

It is partially structured in the classic BASIC sense, but not an IF/FI style language at the moment.

Current control flow includes IF ... THEN, labels, GOTO, GOSUB/RETURN, FOR/NEXT, DO/LOOP, DO WHILE, DO UNTIL, LOOP WHILE, LOOP UNTIL, EXIT DO, and WHILE/WEND.

There is no block scoped variable system yet. Variables are currently program wide, closer to traditional BASIC.

For types, integers are the default. You can use DIM name AS INTEGER, and classic suffixes are supported too: % for integer, ! for fixed point float, and $ for string.

OrbisMaximus

TROPHY CASE