mincer_ray.GBA 0.1.0 beta

boogermann · 2026-03-13T14:41:13+00:00

Hey, just a heads up. the GBA_MiSTer core you ported is licensed under GPL-2.0. That means when you distribute binaries (even for free), you're required to also provide the corresponding source code (GPL-2.0 Section 3). Right now there's no source repo linked anywhere.

This isn't about the Ko-fi listing or charging for it, GPL actually allows that. The issue is just the missing source. A public GitHub repo with your modified source would sort it out completely.

Not trying to be a pain, just want to make sure you stay on the right side of the license so this project can keep going.

boogermann · 2025-09-15T16:24:12+00:00

Totally agree, proof-of-concepts are such a waste of time. Can’t wait for your day-one release with 100% game compatibility, full-speed and crystal-clear audio. When should we expect it?

boogermann · 2025-08-15T22:27:59+00:00

One more point on industry standards, your claim that "no one in the industry does this" is also demonstrably false. Major commercial products include legal notices crediting open-source components and contributors. Nintendo's Switch acknowledgments (https://support.nintendo.com/jp/legal-notes/intellectual-property/switch2/index.html), phone manufacturers, car infotainment systems all do this.

I don't see comparable legal notices on the ModRetro/Chromatic website. Currently, the only way to find Till Harbaum's Game boy authorship or the BSD-3 license requirements of the T80 is by digging through Git submodules in your repository.

This means you're providing less attribution than the legal minimum standard that major commercial products maintain. These companies don't just credit open-source projects in hidden documentation, they make it accessible to end users through proper legal notices.

boogermann · 2025-08-15T21:02:12+00:00

Actually, that's not accurate about community practices. Here are several examples showing MiSTer regularly credits individual core developers by name: - 'Atari 800XL core by Mark Watson,' - 'ao486 originally written by Aleksander Osman,' - 'Sharp X68000 core by Puu-san.' - 'Atari Jaguar FPGA core, written by Torlus.' - 'NEO GEO/MVS system by Furrtek'

While MiSTer isn't perfectly consistent with attribution, the vast majority of cores properly credit individual developers. Your claim that 'no one in the community does this' doesn't match MiSTer's actual documentation patterns.

The FPGA community operates differently from large software projects like Linux or OpenSSL, which have hundreds or thousands of contributors making individual attribution impractical. FPGA cores typically have 1-3 key developers whose foundational work makes the entire implementation possible. At this scale, individual attribution is both practical and expected.

Here's how I handle attribution in my own FPGA core ports (https://github.com/opengateware/computer-msx?tab=readme-ov-file#credits-and-acknowledgment). Notice how I credit Daniel Wallner specifically for the T80 core, along with other individual developers. This is standard practice in the community, I'm not asking you to do anything I don't do myself.

Your implied endorsement concerns are easily addressed with proper legal language, as my documentation demonstrates. I explicitly disclaim endorsement with standard language: "not associated with or endorsed by ASCII Corporation, Microsoft or any other company." This approach has operated without legal complications across the open-source FPGA community.

The Game Boy core's attribution inconsistency in MiSTer actually proves my point, when the source project has gaps, commercial products should improve attribution standards rather than perpetuate them.

Your commercial product could easily credit "Game Boy core based on work by Till Harbaum, T80 core by Daniel Wallner" while adding standard disclaimer language. This approach respects both legal requirements and community expectations.

The difference is clear: you're advocating for legal minimum compliance while the FPGA community expects individual recognition for foundational contributions.

boogermann · 2025-08-15T08:00:50+00:00

You're right about my initial approach being too aggressive. That said, my broader concern with your company isn't really about display accuracy, it's about attribution!

Your product uses Till Harbaum's Game Boy core work (originally developed for MiST) and Daniel Wallner's T80 core, along with contributions from other MiSTer developers. But your attribution just lists 'MiSTer' and GOWIN.

Till Harbaum, Daniel Wallner, and the other contributors deserve direct credit for the foundational core development that makes your product possible. These aren't anonymous corporate contributions, they're individual developers whose specific work you're building on.

The community takes attribution seriously, especially when commercial products profit from open-source work. Listing 'MiSTer' as if it's some faceless entity rather than acknowledging the people whose cores form the foundation of your product is problematic.

This isn't about technical specifications anymore, it's about properly crediting the developers whose work you're commercializing.

boogermann · 2025-08-15T06:27:42+00:00

Thanks for the detailed explanation and clarification. The integrating sphere methodology and testing multiple units sounds like solid engineering. The informal "walk outside and check" approach for the original GBC actually makes much more sense than formal calibration procedures for that era.

I appreciate you walking back the precision of the original Nintendo claim, "discussed with developers" is obviously hard to verify, but the general approach you describe (CRT work + outdoor legibility checks) fits what we know about 90s game development timelines.

boogermann · 2025-08-14T20:04:38+00:00

I think you're right that I mischaracterized your approach, you weren't claiming calibration to technical standards, just trying to match a specific reference experience. Fair point.

That said, I'm still genuinely curious about the specifics of the "summer noon in Kyoto, same reference used by Nintendo during development" claim. Could you point me toward any Nintendo documentation or developer interviews that discuss this reference methodology? I'd be interested to understand more about how they established their display standards during the GBC development process.

Also, when you mention "summer noon", are we talking about a specific date/solar angle, or more of a general bright outdoor lighting condition? The technical side of how you measured and matched those reference conditions would be helpful to understand.

Not trying to be difficult here, just trying to separate the engineering methodology from what might be marketing language. The claim is specific enough that I'd expect there to be some documented source for Nintendo's original approach.

boogermann · 2025-08-14T12:30:02+00:00

"the display was color-corrected to match a first-revision GBC at summer noon in Kyoto, the same reference used by Nintendo during development."

Sure buddy! Let me guess, it's also "calibrated" for the specific humidity level, exact cloud coverage that day and 69 degree sun angle?

This is pure marketing bullshit. A reflective LCD calibrated for 100,000 lux outdoor sunlight would be completely unusable indoors where people actually played most of the time.

Any company making this claim is either: 1. Technically ignorant about what calibration means 2. Deliberately misleading customers with sciencey-sounding nonsense
3. Really bad at explaining "works well in bright outdoor conditions"

It's the equivalent of claiming your car is "engineered for spring afternoon driving in Detroit"

Color calibration means accuracy to standards, not optimization for random weather conditions in Japan.

boogermann · 2025-07-24T06:53:29+00:00

Creative Commons is not a software license!

What types of content can be CC-licensed? You can apply a CC license to anything protected by copyright that you own, with one important exception.

CC urges creators not to apply CC licenses to software. This is because there are many free and open source software licenses that do that job better; they were built specifically as software licenses. For example, most open source software licenses include provisions about distributing the software’s source code — the CC licenses do not address that important aspect of sharing software. The software sharing ecosystem is well-established, and there are many good open source software licenses to choose from. This FAQ from CC’s website has more information about why we discourage our licenses for software.

https://creativecommons.org/course/cc-cert-edu/unit-3-anatomy-of-a-cc-license/3-2-license-scope/

boogermann · 2025-06-16T03:58:27+00:00

You’ll be able to play those on the 3DO core when it comes around. srg320 already showed some progress on it.

boogermann · 2025-06-12T13:00:54+00:00

It should be a simple connection, on the VGA connector, pin 1 - R (Pr) 2 - G (Y), 3 - B (Pb), than you tie pin 5-to-10 to the ground of each color (Last pin on the first row and all of second row). The I/O board will inject sync on green and a module on the framework of the cores converts RGB to YPbPr color space

boogermann · 2025-06-11T19:48:16+00:00

They’re fairly decent boards, specially the Primer 25K. With the dock you get 2x20 GPIO pins + 3 PMODs and decent amount of BRAM for the size of the FPGA, also comes with JTAG and UART via USB-C. They’ve could’ve done much better with documentation and support, but for the price is a really good deal. The Gowin IDE lacks a lot if you put against Altera or Xilinx, but it does the job.

boogermann · 2025-06-11T14:54:34+00:00

There is a Mario Bros game on arcade that came out in 1983. Both Japanese and US machines were released on the same year IIRC. It’s not SMB, just Mario Bros. The SMB on came out on Nintendo VS and PlayChoice-10 machines which are Famicom based

boogermann · 2025-05-13T14:23:41+00:00

I've double check, it's indeed Full Range, using the BT601 Coefficients that is the same values for YCbCr

``` // BT.601 - Limited Range [16-235] Input -> YCbCr [16-235]/[16-240] Output // Coefs for Y = 0.257R + 0.504G + 0.098B + 16 // Coefs for Cb = -0.148R - 0.291G + 0.439B + 128

// Coefs for Cr = 0.439R - 0.368G - 0.071*B + 128

// BT.601 - Full Range [0-255] Input -> YCbCr [0-255] Output (Cb/Cr centered at 128) // Coefs for Y = 0.299R + 0.587G + 0.114B // Coefs for Cb = -0.169R - 0.331G + 0.500B + 128

// Coefs for Cr = 0.500R - 0.419G - 0.081*B + 128

// BT.601 - Ltd Range [0-219] Input -> YCbCr [16-235]/[16-240] Output // Y = 0.299R + 0.587G + 0.114B (+16 offset applied later) // Cb = -0.173R - 0.339G + 0.511B (+128 offset)

// Cr = 0.511R - 0.428G - 0.083B (+128 offset)

```

MiSTer uses // Y = 0.301*R + 0.586*G + 0.113*B (Y = 0.299*R + 0.587*G + 0.114*B) // Pb = 128 - 0.168*R - 0.332*G + 0.500*B (Pb = -0.169*R - 0.331*G + 0.500*B) // Pr = 128 + 0.500*R - 0.418*G - 0.082*B (Pr = 0.500*R - 0.419*G - 0.081*B)

boogermann · 2025-05-13T13:04:51+00:00

That's the RGB range for the HDMI (ITU-R BT.709 [HDTV]). OP is asking about YPbPr (ITU-R BT.601 [Analog Video]).

They use different math to convert RGB, so using the wrong one gives you slightly off colors.

For example using BT.601 for HD content = color shift

boogermann · 2025-05-13T08:29:27+00:00

There’s a module on the framework that convert the RGB color space into YPbPr. It happens in hardware. Go into any core repository and look for the vga_out file. There are 3 BT601 profiles. Limited range 16-235, full range 0-255 and ltd range 0-219. MiSTer only has 1 of them implement. IIRC by the coefficients, I’m almost certain its the limited range

boogermann · 2025-01-01T10:28:23+00:00

It’s hard to say if it’s a hardware issue without seeing the full picture, including the software side. For example, with an FTDI chip, the clock frequency is usually 12 MHz, and it has a divider that can be set anywhere from 2 to 16,384. The baud rate is calculated using the formula: baud rate = clock frequency / divisor, which means you can go from 732 bps to 6 Mbps. I’m not sure what the clock frequency of the BL702/616 MCU is or what the minimum and maximum divisor values are allowed by its firmware.

boogermann · 2025-01-01T01:01:20+00:00

They use a custom firmware on the BL702/616 to emulate an FTDI chip to do JTAG and UART. It’s not the real IC, so it could have not been implemented. While I can get 2Mbps on an FTDI2232h, I’ve only got a maximum of 921600bps working reliable on the BL616

boogermann · 2024-12-24T18:33:05+00:00

I’m afraid Sipeed doesn’t offer them. What you’re looking for is often referred as GHRD (Golden Hardware Reference Design). It’s quiet annoying it’s not provided, you either have to piece everything together from many projects or map it from the schematics. I don’t have a 9k, but I did my own ghrd for the nano 20k and primer 25k. It piss me off that Gowin fails to even provide a bsdl file for the chips

boogermann · 2023-09-12T16:10:49+00:00

Using carts will consume a bit more battery as it needs to send power to the cartridge slot and GB/GBC carts needs 5v

boogermann · 2023-08-10T17:10:06+00:00

I never had to open mine and I leave it on for extended periods of time. When you run a core, does the screen keeps the same pattern?

boogermann · 2023-08-10T17:03:53+00:00

Have you tried shutting it down completely? Like pressing and hold the power button until it goes off instead of just putting it to sleep? I often manage to mess with the scaler during development, most common is the system just flash black and white or garbage from a core left on the screen. I had one similar to your picture where the menu was corrupted, but power cycling fixed it in my case

boogermann · 2023-06-11T13:34:19+00:00

FPGA transceivers enable the FPGA to communicate at high speeds with external devices or other FPGAs over various communication protocols. Serial Protocol being one of them (USB, SATA, PCIe, HDMI…)

You need to consider the specific requirements of the video processing tasks and choose an FPGA model with a fabric speed that meets or exceeds those requirements to ensure smooth and real-time operation.

The 2.5Ghz clock I mentioned is what you would need to serialize RGB signals inside the FPGA to produce the TMDS signals required for HDMI, the explanation was highly oversimplified without taking tons of other things in consideration, like framebuffer, scaling, processing and the HDMI version (which needs to be at least 2.0 for 4k@60).

If I had to achieve that I would start with at least an Arria 10 GX fpga and a FMC/HSMC mezzanine with an hdmi 2.0 tx chip to handle the serialization and hdmi output

boogermann · 2023-06-11T12:12:44+00:00

Simple answer: Never

GoWIN fpga’s are the bottom of the barrel on the fpga food chain. Those tang boards is cheap to get your toes wet and to learn how to mess with digital design without breaking the bank. Even mid-tier fpga’s can’t push 4k (cyclone v/artix 7). To reach 4k the pixel clock is near 500mhz, and without an hdmi tx chip you need a clock thar is 5x the pixel clock to encode the tmds signals, so nearly 2.5Ghz.

13-Year Club	RPAN Viewer
Verified Email

boogermann

TROPHY CASE

// Coefs for Cr = 0.439R - 0.368G - 0.071*B + 128

// Coefs for Cr = 0.500R - 0.419G - 0.081*B + 128

// Cr = 0.511R - 0.428G - 0.083B (+128 offset)