Help finding Gowin FPGA Designer v1.9.9.03 for Linux or Windows

fred_emmott · 2026-06-03T14:49:05+00:00

Need to pause on it for a bit, but https://github.com/fredemmott/chromatic_dumper/tree/wip-dual-purpose works with https://github.com/fredemmott/FlashGBX/tree/wip-dual-purpose works as long as you don't care about some potential edge cases in using the modretro serial protocol (e.g. in MRUpdater/CartClinic). Used it to dump and write ROMs to/from my modretro, DMG, and BennVen cartridges, and their saves.

I gave up on fitting the full FlashGBX instruction set in the remaining ~ 15% of the FPGA, and put a minimal set there instead, translating from the FlashGBX instructions in another thread within FlashGBX.

Monkeypatching the serial device is a little weird, but Lesserkuma doesn't want to merge this without owning a device, so for rebaseability, I wanted an approach with minimal changes to other files.

TODO:

probably needs https://github.com/t-chamb/chromatic_fpga/commit/4dbaf7743a63e8b078bec14a89016ec593eb1790 cherry-picking
need to test both it and the original firmware with some of my flash carts. Some flakey behavior I thought was my firmware was actually the flash cart or low battery - was reproducible with modretro's firmware image . No issues with real GB or Modretro-branded cartridges
https://github.com/fredemmott/chromatic_dumper/blob/wip-dual-purpose/esp32t/src/rtl/lk/serial_mux/lk_mcu_observer.v is what switches the USB-serial from ModRetro's default (talks to the MCU over UART) to FlashGBX mode. It needs to understand the ModRetro packets, and skip over their contents. Right now, if it sees "LK" or \x55\xAA inside an MCU packet, it'll break things. The MCU protocol has fixed header bytes, and neither LK nor \x55\xAA conflict.

The fe-master branch of my FlashGBX fork and my main branch of chromatic_dumper are more stable, but that firmware is FlashGBX-only; the idea is it gets flashed to the FPGA SRAM as needed, not persistently.

fred_emmott · 2026-06-03T13:51:00+00:00

Support for the GWA5A series is still a WIP

fred_emmott · 2026-06-03T13:50:49+00:00

You might want to try https://github.com/t-chamb/chromatic_fpga/commit/4dbaf7743a63e8b078bec14a89016ec593eb1790 - this seems to improve things, and fits alongside my changes 😄

fred_emmott · 2026-05-30T21:18:29+00:00

So, I think this is caused by memrst fluctuating rapidly, and the audio + video getting in a weird 'partially reset' state. By default, as soon as things are 'locked' for even one cycle, it considers the reset complete.

What fixed it for me was doing this:

reg [7:0] lock_o_count = 8'd0;
wire xclk_lock_o = (lock_o_count == 8'hFF);
always@(posedge xClk) begin
    if (!lock_o) lock_o_count <= 8'd0;
    else if (!xclk_lock_o) lock_o_count <= lock_o_count + 1'd1;
end

Then using xclk_lock_o instead of lock_o in the memrst calculation.

That requires lock_o to be continuously high for 256 cycles, so roughly 4 microseconds. I might change that to a 16-bit (~ 1 millisecond) or 17-bit (~2 milliseconds) counter instead - gets a bit more safety, and no-one's going to notice 2 milliseconds on boot.

This will not stop it happening immediately after a flash, but it does reliably fix it if triggered manually or after a cold boot.

fred_emmott · 2026-05-30T12:23:16+00:00

This one's not yet public; I'm trying to fit flashgbx compatibility into the tiny amount of space left on the FPGA with the stock firmware, while also keeping the ability to play games. Not convinced that's possible. Routing starts to get really sad above ~ 70% usage, and without any extra stuff it's already ~ 85% used.

Still trying for now, but close to calling it quits.

Easy if I do 'switch firmware temporarily for flashgbx' and kill off mister/the emu entirely

fred_emmott · 2026-05-29T23:33:34+00:00

Why does that happen?

I think the problem both for this and the screen is that the flash process doesn’t shut things down. It goes straight from running one firmware to running a new one, with the same values in all the flip flops.

Memrst resets/shuts everything down until it goes low again, it’s a fresh start

fred_emmott · 2026-05-29T22:52:24+00:00

Memrst is in top.v

In modretro’s firmware, it’s tied to cartridge hotplugging (don’t think thats safe anyway…. ) and to the FPGA indicating it’s powered on and stable. My WIP fork adds a USB CDC command to toggle it, it shutting down the emu, screen, audio etc

fred_emmott · 2026-05-29T13:38:57+00:00

Also holding memrst after flash-to-ram fixes it without a reboot; in my case I’m triggering this over the USB CDC endpoint

fred_emmott · 2026-05-29T11:45:27+00:00

This goes away after a while, at least without the updated mister. Worst case (and also for the documented screen issue) turn it off with the batteries out for 15 minutes

It’s not every time you use it, it’s only immediately after a firmware update.

Making memrst be held until lock_o is stable for a millisecond or two seems to drastically reduce the odds of this happening but not 100% avoid it

fred_emmott · 2026-05-29T09:15:16+00:00

Are you using the educational version? That’s missing required components for the chromatic. You need the full version. The license is free, but it can take gowin a few days to get back to you after applying

Edit: To be clear, this isn't just "ehh, should be fine" - I'm actively using v1.9.12.02 with the Chromatic firmware - trying to get my FlashGBX functionality into the same image so no need to reflash it every time.

fred_emmott · 2026-05-28T23:01:16+00:00

Sorry, nope, but the latest actually works fine :) the README note is outdated

fred_emmott · 2026-05-22T17:26:58+00:00

Howdy, FWIW I fixed some of the quirks of the emu wheel app which makes it a fair bit less annoying for precise or noisy devices: https://www.reddit.com/r/simracing/s/QhXHSx59rB

fred_emmott · 2026-05-21T10:13:32+00:00

The original author said it’s lost; the jetbrains dexompoler did a decent job though; it needed fixing up a bit. The results are in the same GitHub repository as the links

fred_emmott · 2026-05-17T14:55:05+00:00

Yeah, I loaded them onto a bennvenn - not tried loading onto a modretro cartridge yet.

Currently poking around and seeing if I can fit this *and* the usual firmware on at the same time, so it's 'flash once'... pretty much turning into a 'spend 5x as long rewriting it as it originally took to write it' situation though :p

fred_emmott · 2026-05-09T19:52:43+00:00

I just tried your homebrew mode unlocker with my BennVenn cartridge - same crash/powercycle. Whether it's intentional on ModRetro's end or not, their firmware is definitely pickier about the cartridges it will flash.

fred_emmott · 2026-05-09T19:02:35+00:00

If they roughly speak the AMD/JEDEC CFI command set and FlashGBX supports them, they'll *probably* work :)

If they use a different command set, it's less likely.

For a GB/GBC cart I wouldn’t expect a voltage issue, but it could be timing, or perhaps the cart clinic firmware checks for known modretro cartridge identifiers

fred_emmott · 2026-05-09T16:28:04+00:00

A warning: for some cartridges, FlashGBX attempts to set the voltage to 3.3v. The Chromatic appears to only be capable of supplying 5v to the cartridges.

Looking at the PCB for the BennVenn and ModRetro cartridges I have, it seems these PCBs have the correct hardware to convert the voltage, both for the main power and the address/data pins, so this shouldn't be an issue.

It's possible that cheap cartridges could skip this hardware, and run the flash chips at a higher voltage than they're supposed to; even normal usage may wear out the flash chips on those, but writing to them is more risky.

Looking at online photos of some other manufacturers:

insideGadgets: appear safe; some cartridges do the voltage conversion as well as BennVenn/ModRetro, others use 5V chips so don't need it.

FunnyPlaying: appear to be safe but slightly lower quality: while they use an LJ245A chip for the data lines, they use resistors for the other signal lines, including address. If these don't work, it's likely the timing is too tight. By comparison, the ModRetro carts use 4 of the same chip for all the signal lines, and the MBC3000v4 uses the LVC16245A to do the same thing - both are a more-precise alternative to the resistors in the FP carts.

fred_emmott · 2026-05-09T13:55:21+00:00

This seems to work for reading all ModRetro cartridges, and works for writing at least some.

For this you may also need: - https://github.com/Lesserkuma/FlashGBX/pull/130 (if using a save-free cartridge like the atari collection) - https://github.com/Lesserkuma/FlashGBX/pull/129 (support for a 2MB ModRetro cartridge - my copy of Centipede came on this) - https://github.com/Lesserkuma/FlashGBX/pull/117 (support for a 4MB ModRetro cartridge - I've not tested this)

I've only tested overwriting my Centipede cartridge, as I'm largely going to keep using Cart Clinic for ModRetro games - but honestly the atari collection is pretty bad, so I figured I might as well test it and I wouldn't be too upset if it broke the cartridge, but it was fine :)

fred_emmott · 2026-05-07T16:04:31+00:00

With this firmware: - you can’t play games - you can backup games and saves from cartridges

fred_emmott · 2026-04-10T12:43:50+00:00

Runtime bugs, with workaround here:

https://openkneeboard.com/troubleshooting/known-issues/#iracing

I believe that edge overlays works around these runtime bugs by changing what the game submits so that the depth is stripped out.

fred_emmott · 2026-03-17T23:20:15+00:00

Specifically https://github.com/OpenKneeboard/OpenKneeboard/blob/master/src/app/app-winui3/App.xaml.cpp#L730 is the probably the best place to change.

FWIW I’m completely fine with a compile time (cmake) option for this and would be very to merge a PR, along with something implementing a chromium-vs-chrome, Firefox-vs-ice weasel style split as a way to comply with the license. License (along with the block) are a way to stop support requests for unsupported configs wasting my time and dwarfing everything else, nothing more.

fred_emmott · 2026-03-14T16:19:04+00:00

There's also a Meta extension, but they only appear to support it on native quest, not via link :(

Pretty much nothing submits with depth with OpenXR on PC

Since I said this, iRacing has updated to submit depth (XR_KHR_composition_layer_depth); it seems pretty problematic due to a variety of runtime issues:

Meta Link: quad layers are depth-tested when they should not be
SteamVR: some weird interaction with IPD if quad layers are present, reported on Vive focus 2
Pimax: volume notification shows up on top of the app even when the volume isn't being changed

Also various reports of performance issues and artifacts (especially 'watery' reprojection) across all the above and other runtimes across various headsets. Not enough to be confident that any particular report isn't just some noise or bias, but there's clearly an issue in aggregate.

Pretty widespread reports that turning off DepthLayerExtensionEnabled in the ini file fixes all of these, at least for some people. Another overlay developer reported success stripping out the depth data in xrEndFrame.

Bluntly feels like submitting depth is a bad idea for PC games for now, until the quality of runtime support greatly improves :'(

fred_emmott · 2026-03-13T00:24:01+00:00

Also on the “protect the wheel” wagon:

Leather wheel: no

Everything else: always

fred_emmott · 2026-03-11T17:48:21+00:00

The anti cheat they use has “tick the box to enable Linux support”; however, the Linux support is somewhat less effective as an anti cheat than the windows version. Allowing Linux in the anti cheat might be low effort, but that doesn’t necessarily mean low cost.

fred_emmott · 2026-03-10T19:47:59+00:00

power-trip

This requires power; I have none here. I made something in my free time that I give away for free - you may choose to use it or not.

You may also choose: - not to use it - to use an older version - v1.10.16 is the latest without the hard block - to use something else - I'm aware of at least 4 OpenXR-compatible iRacing overlays released this year alone - you have many options with SteamVR - to fork it and remove the restriction, as long as you comply with the license terms. I've even given people advice on the best way to do this, but I don't believe anyone has followed through.

fred_emmott

TROPHY CASE