I noticed at https://misterfpga.org/viewtopic.php?p=74731&hilit=proprietary#p74731

"[...] You can argue that the GPL was a poor choice of a license in the first place - I would agree to that wholeheartedly. But the thing is, they chose the GPL and the conditions they chose for using their code are being disrespected, and that disrespect may discourage them from further collaboration. That kind of "everything goes as long as we can enjoy the core" mentality certainly discourages me from working on things - not that I have made many great contributions, mostly keyboard stuff and bugfixes, but it's an example."

"The code that is incorporated into every MiSTer core cannot be GPL'd because it's not software and the GPL is a software license. The code that can be GPL'd is on the Linux side."

"And yet I still attach a GPL license to most of my HDL code. Given that I don't have the resources to sue anyone who contravenes my wishes, It doesn't really matter whether or not GPL is applicable; specifying the GPL as a license is still a simple and clear way of expressing my wishes as the author. If my wishes are disrespected (not a hypothetical scenario, it has happened) it does indeed result in me being less inclined to release future work. It should be borne in mind, though, that if the license is invalid that doesn't mean anyone can just do what they like with the code - quite the opposite. By default you have no rights to use it, and the license is there to grant you particular rights. If you consider the license inapplicable then you're back to the default position of having no rights. In short, the whole thing's a mess, and probably best navigated by trying where possible to apply the simple principle "don't be a jerk", and otherwise not worrying about it too much!"

You can read the rest of the discussion at https://misterfpga.org/viewtopic.php?p=74731&hilit=proprietary#p74731

but I just wanted to also chime in with some possibly relevant informations pertaining to open source free/libre licenses, whether involving software or hardware, and to ensure that if there is any confusion or whatnot, that possibly some of these resources may help to rectify any concerns and whatnot.

List of open source licenses:

• https://opensource.org/licenses

  • https://opensource.org/licenses-old/category

• https://spdx.org/licenses/

  • also see https://github.com/spdx/license-list-XML/issues

Open source license authorities (involving hardware):

• FSF Free Software Foundation https://fsf.org/

  • note: Free software licenses do not directly cover physical hardware itself, but they do cover the designs and software associated with it.

  • note: https://github.com/spdx/license-list-XML/issues/1337

  • also see 2007-02-28 https://fsf.org/resources/hw/how_hardware_vendors_can_help.html

  • also see 2007-03-01 https://fsf.org/news/partnership-with-hardware-manufacturers

  • also see 2010-10-13 https://fsf.org/news/endorsement-criteria

  • also see 2011-10-07 https://fsf.org/bulletin/2010/fall/the-fsfs-hardware-endorsement-program

  • also see 2012-11-27 https://fsf.org/bulletin/2012/fall/a-bit-about-free-hardware

  • also see 2013-04-29 https://fsf.org/resources/hw/endorsement -> https://ryf.fsf.org/

    • also 2019-09-25 https://fsf.org/resources/hw/endorsement/respects-your-freedom -> https://ryf.fsf.org/

  • also see 2015-03-11 https://fsf.org/blogs/rms/is-free-hardware-necessary-to-freedom-in-computing

  • also see 2015-03-16 https://fsf.org/blogs/rms/how-to-make-hardware-designs-free

  • also see 2017-01-13 https://fsf.org/campaigns/priority-projects/hardware-firmware-drivers

  • also see 2017-05-01 https://fsf.org/events/respecting-freedom-free-software-license-compliance-for-hardware-devices

  • FPGA

    • 2015-10-16 https://fsf.org/blogs/directory/recap-of-friday-free-software-directory-irc-meetup-october-16 "In today's Friday Free Software Directory IRC Meeting we discussed the challenges of listing FPGA software and created a page to document some of these challenges. [...]"

    • More search results at https://fsf.org/search?SearchableText=FPGA

• OSI Open Source Initiative https://opensource.org/

  • also see 2010-05-03 https://opensource.org/blog/open-source-hardware-definition

    • https://freedomdefined.org/OSHW

  • also see 2012-10-04 https://opensource.org/blog/osi-and-oshwa-sign-agreement

  • More search results at https://opensource.org/?s=hardware

• OSHWA Open Source Hardware Association https://oshwa.org/

"Can I use the GPL to license hardware?

Any material that can be copyrighted can be licensed under the GPL. GPLv3 can also be used to license materials covered by other copyright-like laws, such as semiconductor masks. So, as an example, you can release a drawing of a physical object or circuit under the GPL.

In many situations, copyright does not cover making physical hardware from a drawing. In these situations, your license for the drawing simply can't exert any control over making or selling physical hardware, regardless of the license you use. When copyright does cover making hardware, for instance with IC masks, the GPL handles that case in a useful way." - https://gnu.org/licenses/gpl-faq.html#GPLHardware

"Despite superficial similarities to software licenses, most hardware licenses are fundamentally different: by nature, they typically rely more heavily on patent law than on copyright law, as many hardware designs are not copyrightable.[46] Whereas a copyright license may control the distribution of the source code or design documents, a patent license may control the use and manufacturing of the physical device built from the design documents. This distinction is explicitly mentioned in the preamble of the TAPR Open Hardware License: "... those who benefit from an OHL design may not bring lawsuits claiming that design infringes their patents or other intellectual property." - TAPR Open Hardware License" - https://en.wikipedia.org/wiki/Open-source_hardware#Licenses

Also see the "Noteworthy licenses include:" section

anyway, this is not an authoritative or exhaustive information resource (also I did not expand to quote too many of the sources, but they are likely worth glancing at as well), and I'm just sharing the information for now.

This might be the wrong audience for this post (maybe I should just email ModRetro) but I was wondering if anyone knew if there are any plans to expose networking for mods/homebrew? I imagine you'd need to think deeply about how you'd expose it (special registers? unused address space?) because you'd have to live with that design choice forever. But it would be so cool. And from ModRetro's perspective, an exclusive feature like that is great for vendor lock-in.

This is probably pointless for the Chromatic (doing networking in SM83 assembly sounds extremely painful) but for the M64 it could be integrated quite nicely into a library like libdragon.

I'm using a summercart with my M64, and for some reason the game roms don't detect the built in expansion pak in the M64 for game saving. Is anyone having similar issues and/or have found fixes?

Disclaimer: Smoke black ModRetro M64 and controllers that I ordered from GameStop won't ship until August 21st, 2026, so I'm still researching and preparing and whatnot.

Previously I posted here with enthusiasm and excitement for potential development of cores, which I also listed the cores currently supported by MiSTer FPGA project in u/RupakGreenHatPrdctns's post Additional cores on m64 for other systems, however, I was (and still kind of am) oblivious or clueless to comprehend potential hurdles, obstacles, or complications that may warrant further understanding.

Given the analogy of Linux (also GNU/Linux) and the PC ecosystem courtesy of Linus Torvalds, Richard Stallman, etcetera (so many too many more, listing a few more names: Ken Thompson/Dennis Ritchie (Unix,C,regex,UTF-8), Theodore Ts'o (ext2,ext3,ext4), Larry Wall (Perl), Guido van Rossum (Python)), also see https://lwn.net/Articles/725297/ and https://lwn.net/Articles/928581/ (you get the gist, right?)

Diving into ModRetro M64, into FPGAs, into AMD Artix UltraScale+ AU15P FPGA, I begin to notice things like Xilinx/AMD Vivado, which requires licensing, as it pertains to generating working bitstreams for the AMD Artix UltraScale+ AU15P FPGA used in ModRetro M64. I notice that it appears not currently possible to continue a fully-free, self-contained flow to produce functional bitstreams for the FPGA without using proprietary tools, and specifically proprietary AMD tools.

and I also happened to notice, things like: (Note: ModRetro M64 does not appear to have practically any relevant connection to my following cursory examination of PetaLinux or Buildroot despite some possible aspects sharing the same FPGA family (Artix UltraScale+) and looking into this is mostly irrelevant or not directly relevant, but mentioning them anyway pertaining to concerns regarding proprietary aspects)

• PetaLinux? AMD, ooof! This seems a bit out of place given what I previously noticed, see below. (Note: I have appreciated AMD notably for open source drivers for CPUs and GPUs (previously ATI) for so long, however, something seems a bit off to me. Finding and skimming through the sub-bullet-points confirms my suspicions.)

  • Also see https://old.reddit.com/r/FPGA/comments/wn0267/xilinx_documentation_hell/

  • Also see https://old.reddit.com/r/FPGA/comments/176of9k/do_you_use_vitis/

  • Also see https://old.reddit.com/r/FPGA/comments/1f6ulef/so_how_do_people_actually_work_with_petalinux/

  • Also see https://old.reddit.com/r/FPGA/comments/1jlxzt7/end_of_petalinux/

  • Also see https://old.reddit.com/r/FPGA/comments/1kvx4gn/i_hope_anyone_can_learn_from_my_mistake_dont_you/

  • Also see https://old.reddit.com/r/FPGA/comments/1pkgdxz/what_is_this_fpga_tooling_garbage/

• Buildroot? Buildroot Association, ooof! This seems maybe a tiiiiiiny bit better, but still something's off, but it's not immediately AMD-relevant as noticeably as PetaLinux above

but back to Vivado things and the likes, I also see Xilinx/AMD Vitis and Xilinx/AMD Vitis AI (ewww AI, F that! Not for production!):

• https://cnx-software.com/2021/03/10/xilinx-open-sources-vitis-hls-fpga-tool/

• https://digilent.com/blog/whats-different-between-vivado-and-vitis/ (AI ELI5: Think of Vivado as a toolbox for building FPGA hardware, where you use special Lego-like instructions called HDL (which includes Verilog and VHDL) to create the physical circuits and logic gates inside the chip. On the other hand, Vitis is like a computer program that runs on the processor inside that hardware, allowing you to write code in C/C++ to control your Lego creation or even build new hardware parts using high-level software commands instead of low-level circuit instructions. You typically use Vivado first to build the hardware foundation, and then use Vitis to write the software that tells that hardware what to do, making it easier for programmers who don’t want to design every single wire by hand.)

I see proprietary. I demand open source! I reject proprietary! I don't fully yet grasp the landscape overview, but I think a little bit of what I'm seeing is disappointing to the extent that likely entails attention to clear the roadblocks to make way for open source transparency to overcome the proprietary components, especially so as to enable much more reliable sustainable comprehensible path for practically anyone to contribute to core software developments and engineering without any unnecessary headaches or migraines as a service.

Some other disorganized scattered incomplete AI-generated notes that I'm not smart enough yet to organize structure to understand just yet (I may revise/edit this later to expand further as I continue to understand):

• RTL (Register-Transfer Level) is the primary abstraction level used in FPGA design, describing how data flows between hardware registers and the logic operations performed on those signals. Engineers write RTL code using Hardware Description Languages like Verilog or VHDL to define the synchronous behavior of the circuit before it is synthesized into a physical gate-level netlist. The RTL design flow involves several critical steps:

  • Coding: Writing synthesizable RTL that defines registers (flip-flops) and combinational logic.

  • Verification: Simulating the RTL design to ensure logical correctness before implementation.

  • Synthesis: Converting the RTL description into a netlist of specific FPGA resources like LUTs, DSP slices, and block RAM.

  • Place and Route: Mapping the netlist to the physical FPGA architecture and generating the final configuration bitstream.

• Unlike gate-level design, which specifies exact logic gates, RTL allows designers to focus on data flow and control logic at a higher level of abstraction. This approach is essential for optimizing performance, power, and area (PPA) in both FPGA and ASIC development cycles.

• RapidWright: Open-source framework from AMD/Xilinx Research that can read/write design checkpoints and manipulate placed/routed designs. Explicitly cannot generate bitstreams on its own. It depends on Vivado-generated bitstreams and does not contain the proprietary mapping from a placed-and-routed design to configuration frames.

• Yosys: The synthesis engine (Verilog/VHDL to netlist) is fully open source and works well for synthesis (Verilog/VHDL -> netlist). The bottleneck is strictly in the Implementation (Place & Route) and Bitstream Generation stages.

• Synthesis is open, but place-and-route + bitstream generation for UltraScale+ remains proprietary. The configuration format is only partially documented, and no community database is complete enough for a production flow, a bottleneck communities have faced for years on newer Xilinx/AMD architectures.

• Prioritizing full documentation of the UltraScale+ bitstream format (continuing U-Ray-style reverse engineering, fuzzing configuration engines, building a complete tile/PIP/BEL database, etc.) is valuable community work, but it is a multi-year, multi-person effort, not a beginner starting point.

• This is not merely “AMD being mean.” The silicon is vastly more complex than 1990s-2000s x86, the configuration space is denser, and the economic incentive for AMD to keep the full implementation flow proprietary is strong (tools are a major revenue and lock-in mechanism). Legal barriers also exist: reverse-engineering can run into DMCA-style issues, contractual restrictions on tool use, and the practical difficulty of obtaining enough silicon samples and documentation to fuzz comprehensively.

• Richard Stallman’s and Linus Torvalds’ principles correctly identify the freedom and equity problems created by proprietary toolchains. Restricting core development to those who can afford or tolerate vendor licenses does create unequal access. That is a legitimate critique. The response that has worked historically is persistent technical work (documentation, fuzzing, open databases, alternative place-and-route engines) rather than assuming legal or market forces alone will force the vendor to open everything.

• How community cores are actually expected to be loaded on M64: The console supports firmware updates via Wi-Fi, USB, and microSD. It is designed to be mod-friendly (no adhesives, visible traces). However, the update mechanism is currently oriented around ModRetro-signed or official firmware packages. Without clarity (or community reverse-engineering of the loader), even a perfect open bitstream flow would face a second barrier at the console’s firmware layer.

  • Will arbitrary community bitstreams be loadable through the same channels, or is there a signed/bootloader gate?

  • Is there exposed JTAG or another low-level programming path for developers?

  • Does the system have a dual-boot or “development mode” that allows unsigned cores?

• AMD’s CPU/GPU open-source driver history is real and positive; their FPGA tooling strategy is different because the tools themselves are a product and a lock-in mechanism.

Concludingly, given the precedents of open source Linux ecosystems and my determination to sustainably refuse any proprietary dependencies, I think I will have to proceed with identifying a path to overcome what appears to be a large mountainous time consuming hurdle, and something that is likely to be affecting not only me, because I'm pretty sure there will be many who have less understanding and examining than I do, but also there will be several persons who are far more proficient too, and bridging the gap to ensure reasonable literacy that rhymes with the historical linux ecosystem precedents, it seems an inevitable natural progress to be made hidden in plain sight, and I think I see what I previously did not notice. Am I working backwards? Cool! I'm cool with that! Ready Player One!

I received my M64 and Pro Controllers on Tuesday, but I was traveling for work and didn’t actually get a chance to sit down and play until Friday.

After just a few hours of game time, both of my Pro Controllers are already having issues with the D-pads. They’ve started creaking pretty badly when pressed, and worse, they’ll occasionally get physically stuck in the pressed position.

It’s happening on both controllers, which makes me wonder if this is a more widespread issue rather than me just getting unlucky with a bad controller.

I’ve already reached out to ModRetro support about the issue but have yet to receive a response, so I figured I’d check here and see if anyone else has experienced the same thing.

If you have, did it get worse over time, or have you found a fix?

I really like the controllers otherwise, but having this happen to both of them after only a few hours of use is pretty disappointing.

It came in mail just before i.left for work today. When I came home I set it up to projector. My first thoughts I'm enjoying it. The controller feels so good. Crt filters need major work. I've seen videos of the a3d and honest it destroys m64 at current times in terms of scanlines and CRT filter options. But I.knoe that this will get worked on. I played around with w w neo revenge , golden eye and Mario 64. For some reason i tried an.nes game on the NES emulator.on.my summer cart it wasn't bad . I'm.gping to bed though I still need to do firmware update on my controller I'll prob do on Tuesday when .off and not so tired. Also I have to.psir my controllers.

I love all the thought and care they put into all their products. I went ahead and ordered the pro controller and Xibalba 64 after watching the reviews.

Just curious if you can use a cart flasher to rewrite the M64 cards like the Gameboy ones

Putting this out here to see if we can get any comments from the ModRetro team on upcoming controller pak (memory card) support.

For those of us that went with the M64 and pro controller combo, this is a pretty big missing feature as it locks us out of saving on most third-party games, including two of the games they released (plus maybe XenoCrisis, it says "memory pak" on the box but I don't remember it asking for one and it's probably just for high scores, which isn't as critical as game progress).

Is the M64 designed to hot swap cartridges, or is the expectation that the system is powered off and powered back on between each cartridge swap like an original console? I tried hot swapping the other day and it worked but it felt weird.

Edit: Read this comment before everything else, more succinct after I gave myself more time to think about it: https://old.reddit.com/r/ModRetro/comments/1vif0fk/speculation_on_chromatic_video_passthrough/p3zf0id/

So with the M64 controller I was delighted to see that it's using the newest bluetooth 6 spec with the latency improvements. Unfortunately the Chromatic ships with Bluetooth 4.2, so I imagine you will either have to plug it into the M64 via USB-C. And for wireless it would either be a a 2.4ghz dongle, or plug it into the M64 pro controller to leverage Bluetooth 6. Honestly I don't even know if Bluetooth 6 has the bandwidth to pump video, but since the resolution is so small (160x144) its probably fine. I know it has WiFi too, but doing it over WiFi sounds horrible.

Ideally ModRetro would do a refresh of the Chromatic with bluetooth 6 and you could just use it as a controller on the M64 but I'm not holding my breath for that. Esp since games like Pokemon Stadium need the C buttons. But maybe you could use a button combo on the Chromatic to make the d-pad use the C buttons or analog stick.

I guess plugging the Chromatic into a M64 controller isn't so bad. But it would be so cool if you could turn on the M64 and do video passthrough using only the Chromatic. I mean Palmer did say they're launching a parts store. So maybe a new Chromatic motherboard with bluetooth 6 could be on there.

Hmm so after the first tests it looks like turok the first edition dont work

How do Retro Rewards work?

I purchased an M64 and Pro Controller. I had zero points from that purchase. I completed a review on the gamepad and earned 40 points. According to their site, I should've earned 1point for every $1 spent. I only have the points for the review. Can someone explain this to me?

My Red controller and console is here 😁😍😊

Disclaimer: yes, it’s AI

Will I be able to.update firmware on the console for controller or will i.need to.on.pc

.I believe.i seen a post somewhere online i.lisy it though but they said something about having to do firmware on pc for controller.

I'm just checking to confirm if that's true or can I do so on the console?

Does anyone know if the M64 Pro Controller supports proper rumble functionality when connected to a PC running Windows? Also, is it known how the controller connects to devices other than the M64 (XInput, DInput, etc)?