Here you can see a relevant latency test

But there is a technique called "Real-time image resizing and rotation with line buffers" which could be implemented in FPGA to mitigate this lag issue: https://patents.google.com/patent/US6801674B1/

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.

I’ve published a short write-up centered around the new Contributing a Core to MiSTer FPGA wiki guide. It covers the requirements and conventions for joining MiSTer-devel, why they matter for preservation, maintainability, and long-term compatibility, and where Update All fits within this ecosystem.

More info in the public post: https://www.patreon.com/theypsilon/posts/to-all-new-core-165871199?utm_source=reddit&utm_medium=social&utm_campaign=new-core-165871199&utm_content=main-post

I’ve also added several new things to Update All during the past two weeks:

• 240p Test Suite integration: adds the 240p Test Suite database to Update All, including a dedicated 240p core under Utilities and test-suite ROMs for Game Boy, GBA, Master System, Mega CD, Mega Drive, N64, Neo Geo, Neo Geo CD, NES, PlayStation, Sega 32X, Saturn, SNES and PC Engine. It’s useful for calibrating CRTs.
• New tools/scripts: MiSTer Hi-Fi is a music player supporting formats such as FLAC, WAV and ALAC. MiSTerFin is a Jellyfin client tailored for CRT use.
• New hybrid cores: Solarus brings the Solarus 2D action-RPG engine to MiSTer. 3S-ARM brings the PlayStation 2 version of Street Fighter III: 3rd Strike to MiSTer through its decompilation project.
• Automatic self-updating before the Settings screen opens, so you no longer need to run the updater twice to see new additions
• New experimental mirror system, starting with Andi Brazil, intended for users who may have connectivity issues with GitHub, such as those experienced in Brazil last year.

Enjoy!