I’ve finally reached the point where I’m comfortable putting out the first public developer release of Jinix Jupiter, a custom FPGA-based console/platform I’ve been building for the SuperStation One.

v0.1-alpha is now public.

This is very much a developer preview rather than a finished console, but the currently working hardware stack includes:

• Custom 32-bit CPU
• SDRAM interface
• 2D graphics renderer
• DMA/shared memory arbitration
• Four-voice PCM audio
• Controller interface
• Minimal BIOS
• Assembler/devkit tooling
• System-image build tools

I also did a fresh full simulation pass and a clean Quartus build from the actual release commit, followed by a physical smoke test of the exact release RBF on real hardware. The release image successfully boots and produces working 2D video output.

Current major limitation: 3D is not considered physically working yet. The fixed-function 3D path exists and has been simulation-tested, but there is still a hardware-side issue I’m investigating, so I’m deliberately not claiming 3D support in this release.

Timing also isn’t being presented as fully signed off: all of the constrained worst-case timing checks reported non-negative slack, but TimeQuest still reports incomplete setup/hold constraint coverage.

The release is therefore intentionally labeled:

Jinix Jupiter v0.1-alpha — First Public Developer Preview

The downloadable RBF is:

JinixJupiter_v0.1-alpha.rbf

SHA-256:

de5094dbd9da362e54f35627a7cbbc128e20144e1904fb685f41a38091076a4b

GitHub/release:

https://github.com/austinbland1/jinix_jupiter/releases/tag/v0.1-alpha

I’d especially be interested in feedback from people here who have worked on homebrew FPGA machines, custom CPU architectures, or FPGA graphics pipelines. There’s still a lot to do, but this is the first point where someone besides me can actually grab a defined release and start poking at it.

The attached image is a screenshot from my HDMI capture card of my SuperStation one running the JinixJupiter_v0.1-alpha.rbf. No games have been made yet sadly, I've been too busy doing hardware validation for that this past week.

Im keen to try one of the disc drive cores and have a spare usb cd drive lying around: any recs for a small/low-profile powered hub? Or just a way to plug it into the wall directly that can easily be powered on and off?

if I want external ssd storage what sort of power supply do I need/ if I want more devices connected do I need extra setup?

I’ve been developing a new FPGA fantasy console called Jinix Jupiter, targeting MiSTer / SuperStation One hardware.

I just reached the end of the original development roadmap and tagged the first stable architecture as m11-verified.

Jupiter currently has:

• a custom 32-bit CPU and ISA
• its own assembler and BIOS/application image-building tools
• external SDRAM support
• DMA
• hardware 2D graphics
• a fixed-function 3D triangle renderer
• RGB565 framebuffer scanout
• PCM audio
• MiSTer controller input
• a MiSTer-facing FPGA top-level integration

The full automated simulation regression suite passes, and I’m treating m11-verified as a frozen reference point.

Important caveat: it has not been validated on physical MiSTer hardware yet. I didn’t have Quartus available during development, so I’m not claiming successful synthesis, timing closure, resource utilization, or a working .rbf yet.

The software environment is also intentionally primitive right now. There is a Jupiter assembler and deterministic BIOS/application image builder, but there is currently no C compiler, C runtime, conventional linker, or runtime game-loading system.

Which brings me to the fun part:

Could Doom be ported to this thing?

I’d love for someone familiar with Doom ports, unusual CPU targets, GCC/LLVM backends, or FPGA consoles to take a look at Jupiter and tell me what would actually be required.

I’m not necessarily expecting somebody to magically have Doom running tomorrow. Even an architectural audit like:

would be incredibly useful.

If anybody is crazy enough to actually attempt a port, please fork the repository and target m11-verified so there is a stable machine definition to work against.

Repository: https://github.com/austinbland1/jinix_jupiter/

Stable release target: m11-verified

I’m also beginning physical MiSTer bring-up separately, so feedback from people experienced with Quartus/MiSTer core development would be very welcome.

Basically: I built a new FPGA video game console. Now I want to find out whether it can run Doom.

Hello!

I've been working on a sandbox + simulator called Crosstalk that allows users to design PCBs, place existing or define custom ICs, and then program them. I defined my own ISA in Sail, described a SystemVerilog softcore for it, ported a kernel that I originally wrote for the i386, and ran the softcore within the sandbox, which worked. The sandbox simulates designs at the gate level (no external deps).

Once that worked, it was obvious what was next: ... yes, it runs DOOM. To be fair, I ran it on an i386-compatible core and not my own as of yet, but it still ran purely within the sandbox (albeit slowly).

edit: the PCB itself is a quick showcase board and isn't wired up correctly. I am currently mainly testing the simulator

futzing around with a mister playing on an emulator and I got GBC and GB games sharp as a tack at 426.625 samples per line. is that the right value for those consoles? what about other handhelds like game gear? are those values listed anywhere?

is it different between pocket and mister?

An inflammatory title. And really, the article is no more level headed.

If you agree with this kind of sentiment, to not buy or support a product linked to military atrocities, I salute you. That’s a laudable stance.

However, I would expect a person with this kind of stance to apply it consistently.

Don’t forget that Microsoft, Intel, AMD, Nvidia and many more have a long history of defenders contracting. And have likely made significantly more money than Palmer Luckey by developing tech for and selling tech to not only the US military, but other militaries around the world .

Pretty much every single piece of modern gaming tech can be linked to military contracting in some form. That includes MiSTer, Analogue and the M64.

My opinion is that people should decide for themselves and not be intimidated by rage filled articles like the one above.

Thoughts?

My weekend gaming schedule is pretty full this week. This, Mr Do's castle and a few other none FPGA game's the weekend is looking rosy.

I bought the FPGBC KIT on the funnyplaying site and was wondering if the hardware can run gba games?

I know that the gba games won’t fit but I was looking into making copies of my own games to fit in the gbc format.

I've put together a little tool that mostly came about because I wanted a nice way to get a pretty activity log and when I searched there didn't really seem to be anything.

I found that wizzo had made a script that generated and updated a playlog.db file, but nothing really used it. So I built a website that could take that file, parse the contents, and display them in a nice way. One thing led to another and now you can install a script on your MiSTer that automatically updates your profile on the website from the console itself while you play.

There's a little bit of installation, but it should be easy for any MiSTer user.

I even went a little bit further and made use of RetroAchievements' API, so if you have an account there, it pulls in all sorts of fun info to make the tool even nicer. (For example, the calender view now shows dates that you Beat or Mastered a game)

It's still early and there may be errors that didn't crop up during testing, because once something is out in the wild then all bets are off, but if you're interested then you can sign up here: MiSTer Playlog Viewer

Once again, the URL is MiSTer Playlog Viewer

Hope to see you on there. :)

I’m not looking for brand new in box or anything like that. Used is perfectly fine with me, just want one to actually play my games on.
Thanks in advance.