FPGA N64
ultrafp64.com
ultrafp64.com
Interestingly, SM64 is usually throttled by memory speed. This means that using 'inline' is detrimental to performance, since making the program larger can cause another read from memory.
Here's an overview video, he has many more specific videos about specific topics:
There's an entire community doing N64 homebrew: https://n64brew.dev/wiki/Main_Page , including a faction who are working on a Rust SDK (basic demo: https://youtu.be/XmlmvRrRFqs).
Great videos though!
It's sort of been a smooth transition from literal ROM hacks, to hacks with custom assembly, to hacks that are compiled from source, but the name has stuck.
> you'll see text strings with the %s token... pretty sure those would only come from C.
There is nothing inherent in % escaped substitutions that unequivocally implies C. You could pretty easily write an asm port of a basic printf function if one wanted to reuse previously translated strings. Not saying C wasn't used for the NES port of this title, but this by itself isn't as strong a clue as implied.
In fact, the function for printf used to be implemented in assembly on Unix. In this link, the actual implementation is in doprnt.s, and the function printf (in printf.c) just passes its arguments to the function _doprnt. In V6 Unix, it was the same for scanf, but V7 seems to have replaced it with a C implementation.
It was only done with assembly on the NES.
[RL, ..., MuZero unplugged w/ PyTorch ]
> Farama-Foundation/Gymnasium is a fork of OpenAI/gym and it has support for additional Environments like MuJoCo: https://github.com/Farama-Foundation/Gymnasium#environments
The Mario64 game can be won with a minimal number of stars;
> Farama-Foundation/MO-Gymnasiun: "Multi-objective Gymnasium environments for reinforcement learning": https://github.com/Farama-Foundation/MO-Gymnasium
Ghidra may or may not be useful for e.g. gadgets with mario64
Return-oriented programming > On the x86-architecture: https://en.wikipedia.org/wiki/Return-oriented_programming#On...
[0] https://mister-devel.github.io/MkDocs_MiSTer/setup/requireme...
[1] https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=...
There's a project called marsfpga that will support newer hardware.
Software updates are a different matter entirely. The system has evolved greatly, with each year so far having resulted in an impressive list of new additions and improvements.
The cogs and wheels of the niche entrepreneur industry have been slowly turning, and the next 1 - 5 years promises several likely newer generation products. People highly invested in some of the 32- and 64- bit systems not covered by MiSTer, and or people who want more modern display options, will be very interested in those. The price projections seem to be aiming at the $500-$1000 range.
But as of today it's still hard to look past the MiSTer, as a multi-year already proven system, which has for years offered elite level 8- and 16- bit recreations, recently added an amazing Playstation 1 core, is close to adding an N64 core, and can be had right now all-inclusive starting in the $300 segment.
There have also been a few different takes on making a mister in more of a console form factor, and boards that integrate into arcade cabinets or fit in ITX PC cases.
The software has come a hell of a long way. In the army days, the most advanced cores were 8 bit systems like the NES. Now we’ve got PlayStation 1, Sega Saturn and N64 in the works. Similar progress has been made supporting old computer and arcade systems too.
There is an upcoming sort of successor called Marsfpga that’s recently started being teased. From the little that’s been shared so far, the community seems hopeful that this will mean the Dreamcast and support for arcade games through the early 2000s are possibilities.
Once you get much beyond that era, an FPGA-based approach makes less sense - the systems become much, much more complex and also largely standardise around with x86 or ARM where there are always to run them without emulation at all. A notable exception to that is the PS3 with its cell architecture. Then again, people said for a long time that PS1 and Saturn were not possible.
Not much info on the page, also I'm not in any way affiliated. Just think it's cool that this is getting commercialized.
The size of the company also explains the support issues.
The only shipping they do is extremely expensive express shipping internationally. They had some adapters that were previously OOS come available, but the Pocket system was OOS. I emailed them, asking them if I could buy the adapters, have them put them aside, and reserve the Pocket, and have them ship it all at once whenever the Pocket was in stock. I even offered to pay it all up front so they weren't put out. They basically (politely) told me to suck it up, and buy both, and pay ~ 100 AUD each time to ship them express, separately.
Niche audio companies (eg Schiit) do this infinitely better!
I'm most excited for the next generation of FPGA retro consoles coming in the next 6ish months. Specifically the MARSFPGA. All the existing Mister cores, plus a bunch of new stuff enabled by a better and newer FPGA. The estimated price is $700, that's reasonable for those of us with large disposable income that want the retro kit with no hassle, easy access for the kids, and high Wife Acceptance Factor.
I'm also looking forward to all the upcoming arcade cores for the MARSFPGA.
this was obviously always possible, but it required someone who wasn't indoctrinated into the community. the community behind a project is always both the very best and very worst thing about any project.
https://digilent.com/shop/nexys-video-artix-7-fpga-trainer-b...
The market for the original hardware, old cartridges and mods for things like better video signals or Bluetooth controllers is also popping.
The timeline matches, 2 years between hire and announcement.
Discussed a few days ago: https://news.ycombinator.com/item?id=37901025
there are a few different major brands
https://digilent.com/shop/fpga-boards/development-boards/int...
For online courses, I've heard good things about Nand2Tetris but have not tried it myself.
The target audience for nand2tetris are people that want to understand how the CPU works, and nand2tetris focuses too much on how to make logic using nand gates leaving other areas uncovered.
I recommend the Ben Eater youtube chamnel, he has a series of videos about building an 8bit computer, that in my opinion is much more informative for a curious person.
nand2tetris covers many levels of abstraction; it is both lower and (much) higher level than Ben Eater’s projects, which is one of its main points: you can create something in one level of abstraction and then build on it in the next level of abstraction. It only starts with logic gates (a single one to start with, “nand” obviously) and goes through the other logic gates that can be built from nand gates, then various digital logic built on that, registers and other synchronous logic, ALU, full CPU, full computer. Hardware is only the first half of the course. Then you build a stack machine, assembler, objected oriented language compiler, a software library I think, and finally a game you write in that (doesn’t have to be Tetris). So the whole second half is layer on layer of software abstractions starting from the hardware. I would say it handwaves over video output and keyboard input because it’s not what they’re teaching about, while Ben Eater shows how to physically build such things.
Ben’s is purely hardware up through 2 main registers, an alu with only add and subtract, an 8 bit digital readout, no real input (besides updating RAM to input the code & data using switches), 16 bytes of RAM (4-bit address), and control unit to implement machine language with a few opcodes. His 6502 project starts with a CPU which is already far beyond where the 8-bit computer ends and builds a computer architecture around it (RAM, ROM, I/O, and peripherals: video, keyboard, serial).
nand2tetris is normally simulated and Ben’s covers physically building things which has its own set of lessons/skills to learn. Coincidentally I ran across a crossover of the two projects today: a video of someone who built a breadboard version of the nand2tetris 16-bit cpu (called Hack)! https://youtu.be/L-azf9ecvfo
Here are some project tutorials for it (should be easy to adapt to other hardware too):
https://github.com/icebreaker-fpga/icebreaker-workshop https://github.com/icebreaker-fpga/WTFpga
I started messing with FPGAs with the DE0-Nano, but eventually got so frustrated with the tiny buttons that I upgraded to a DE0-CV, which I really enjoyed my time with. It has some 7 segment LEDs, physical switches, and buttons, and it also has a VGA port, PS/2 port, and Micro SD card slot, so you can build a pretty snazzy little PC if you want to.
I know nothing about electronics, but the recent uptick in FPGA game systems like the MiSTer getting Playstation and N64 support, I am hoping that FPGAs can pick up where Higan left off; it would be great to get cycle-accurate emulation of the Xbox 360 some day since I never fixed mine after getting a red ring.
That said, I acknowledge that that would take a lot more work, and it might not be economically worth it for Analogue or the MiSTer people to bother with it.
The Higan concurrency architecture hit a wall because it needs to sync between modules every single cycle, what gets very expensive as the clock rates go up.
But you don't need to sync every single cycle, especially once CPUs started getting caches, so we just need a new concurrency architecture that's flexible enough to only sync when needed.
I've been experimenting with an actor based concurrency model which seems to be fast enough for a cycle-accurate N64 emulator (though I won't know until I have the RSP and RDP implemented). I'm hoping it might even be fast enough for 6th gen consoles, perhaps when combined with other techniques like a cycle-accurate jit and fine-grained memory locks.
I'll have to post an article if it ever gets to a workable state.
------
As for cycle-accurate FPGA emulators, I don't think they are cost-effective even for something like the N64, yet alone a 360. You can get 90% of the way there with a cycle accurate CPU, shared bus, cycle accurate RSP/RDP. But you have to map the RDRAM onto DDR3 memory and the timings don't really line up. The linked UltraFP64 project doesn't even try for accurate RAM timings and will preform better than a real N64. I suspect the WIP n64 core for MiSTer is much the same.
You could build a custom board with memory that actually matches the timings, but that gets expensive.
Not sure this thing is open source hardware, or available to anyone in any form, or even real.
:) Just a nitpick, don't mind me. This is a neat project
Dual = There are two clocks
Dueling = The clocks are swinging swords at each other
(The PS2 is also implemented on a FPGA. Idk whether the PS1 is or isn't though)