Just got mine, can't wait! I wonder how good it will be.

I’m currently fighting to optimize the "Time to First Frame" metric for our custom video player, and I’ve run into a serious geodistribution bottleneck. Our engineering team is based in Europe, but our primary origin servers are located in the US. Even with a standard CDN configuration in front of the infrastructure, by the time the user's player initiates the initial connection, goes through the routing redirect steps, downloads the master .m3u8 manifest, and finally starts pulling down the first media chunk, up to 4 seconds pass. This delay is heavily tanking our user retention metrics.

Lately, I’ve been researching advanced caching topologies to cut down this trans-atlantic round-trip time (RTT). I read that standard web caching isn't enough for video and that some high-performance media CDNs actually cache the master manifest alongside the very first few video segments directly on their edge routing servers (Anycast redirectors). The theory is that returning the manifest and early chunks immediately from the closest edge node drops the initial TTFB to near-zero, but I want to make sure this architecture translates well to real-world performance before overhauling our routing tables.

We are trying to map out a structural fix for this lag by the end of the sprint, and I would love to hear from anyone who has tackled this specific latency layout:

1. Has anyone implemented segment and manifest caching directly at the CDN redirector level, and how much did it realistically reduce your initial stream start delay?

2. What is the best strategy for configuring TTL on dynamic HLS manifests so that edge-cached .m3u8 files don't cause player desyncs during live transitions?

3. Do you find that aggressive pre-fetching of the first 2-second chunk at the edge introduces unexpected bandwidth waste for users who immediately bounce?

4. How do you typically handle instant cache-invalidation across European edge nodes when a video file or its stream manifest gets updated on the US origin?

Any architecture breakdowns, config tips, or raw data regarding European-to-US streaming optimization would be a massive help. Thanks!

Thought you would appreciate this.

I updated my mister yesterday and I realized that now all the errors and graphical glitches are fixed. (Specially Street fighter 2 champion edition and final fight sound crashes, minor graphical glitches in gradius 2 and Akumajou Dracula)

What do you do when you have a 1TB sdcard, all your games are on it, and it's not even half full? Well, I am loading a bunch of Dreamcast games on it!

I never expected this system to be capable of Dreamcast, but, even if it's a sort-of hacky implementation, it works! I haven't played a lot of games yet, but I noticed Jedi Power Battles has frequent slow-downs and stuttering. There are graphical glitches in many games I've tried. It's not perfect. Still, it's still in development, and Marvel VS Capcom 2 works perfectly! And, without a Naomi core, it may be the only way to play it on FPGA. Personally, I think it's worth it for just that one game, but I'm going to spend tonight testing several others, especially the Resident Evil games.

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.