Hi everyone, I'm a recent computer science/math graduate and I have no real background in VHDL or Verilog, as pretty much all of my programming experience comes from high-level languages for data science and software stuff. I have always wanted to contribute to some sort of open-source gaming preservation project, and truthfully MiSTer seems like a much more worthy investment of time than any software-based emulation project.
I just got my DE-10 Nano in the mail and I was wondering if anyone has a good place to start for learning VHDL/Verilog, how to set up the DE-10 development environment, or (if possible) also how to translate hardware schematics into those languages as well? From what I understand there are a ton of MAME arcade cabinet blueprints that could be translated but nobody's gotten around to it, so I'd love to help if I can.
Last thing - is there any sort of developer comms platform like a discord or slack channel to discuss specifics, or are these sort of things discussed here on this forum?
Thanks to everyone for all the hard work so far
Resources to start programming for the MiSTer?
-
- Core Developer
- Posts: 547
- Joined: Sun May 24, 2020 9:30 pm
- Has thanked: 20 times
- Been thanked: 145 times
Re: Resources to start programming for the MiSTer?
I suggest that starting small, but with hands-on is one place to start.
1) Compare the Template-MiSTer and ADCTest-MiSTer cores, to see a relatively trivial implementation. When you are comfortable that you understand this, move on to a core for an old and simple computer (like the TRS-80 for example)
2) Rather than roll up your sleeves to write a core, you should take a look at making minor changes to an existing core - these could be bugfixes, or new features (or just altering a behaviour in a private version for your own benefit).
1) Compare the Template-MiSTer and ADCTest-MiSTer cores, to see a relatively trivial implementation. When you are comfortable that you understand this, move on to a core for an old and simple computer (like the TRS-80 for example)
2) Rather than roll up your sleeves to write a core, you should take a look at making minor changes to an existing core - these could be bugfixes, or new features (or just altering a behaviour in a private version for your own benefit).