RustBoyAdvance-NG: GameBoy Advance emulator and debugger, written in rust
github.com
github.com
My strategy in the end is simply to stuff the entire state in a struct that I pass around everywhere, using a more functional style instead of class methods. This way I don't have to borrow anything and I have access to the full state everywhere in the code. It doesn't make for clean OOP-style encapsulation but I found that doing that was too complicated in an emulator, you simply have too many interactions between the various modules of most consoles. For instance the DMA can write data to the GPU which can trigger an IRQ in the interrupt controller which can change the CPU state which can modify the state of a coprocessor which can lead to registers being banked into RAM etc...
Besides, the architecture of an emulator is generally constrained by the underlying hardware, so it's rare that you have to do big refactors. Having leaky interfaces is not much of a problem in practice because you don't really have to worry about "but what if tomorrow I need to emulate a Game Boy Advance with a very different GPU?".
While we're showing off Rust emulator projects I've spent the last few days writing an emulator for the PlayStation's CD-ROM sub-CPU: https://gitlab.com/flio/psx_cd . I hope to be able to integrate it into my PlayStation emulator when it's done, which would save me from having a super hacky high level CD interface like most other PSX emulators out there.
The emulators are written in C, not Rust, but I bet this approach would also work perfectly with Rust's borrow checker (since there's no shared state in memory the borrow checker shouldn't even "activate"). An emulator is essentially built from functions which take a 64-bit integer as input, and return another 64-bit integer.
In the end I found that it was more trouble that was worth. I didn't feel like it made the code significantly clearer and if you realized later on that something actually ought to be shared between two modules it required a ton of refactoring.
Also having everything in a single struct that's passed everywhere can make debugging slightly easier. For instance if I encounter a situation where some bogus command is sent to the GPU I catch it in the GPU code and dump the CPU state right there instead of having to notify the condition upstream and add some hook in the higher layers to handle the CPU dumping for instance.
It's probably not the most elegant solution but I find it simple and rather effective.
Does Rust even have classes?
I think we're all capitalising on the HN algorithm gearing towards Rust-related posts which can only be a great thing for those who absolutely love Rust <3. Perhaps I should be a town crier for the Rust project to market all things Rust.
ππΆπ’π·!, ππΆπ’π·!, ππΆπ’π·! ππ«π¬π±π₯π’π― π€π―π’ππ± βπ²π°π± ππ―π¬π§π’π π±!
What the hell are those? I looked at each letter (Unicode 1D5{12,36,22,37}), and apparently it spells out Oyez?
Oyez (/oΚΛjΙz/, /oΚΛjeΙͺ/, /oΚΛjΙs/, more rarely with the word stress at the beginning) is a traditional interjection said two or three times in succession to introduce the opening of a court of law, especially in Great Britain. The interjection is also traditionally used by town criers to attract the attention of the public to public proclamations.
Edit: Maybe you meant 'hear' not 'here'.
Now excuse me while I get back to selling shovels.
I donβt know why the hate, but I would say HN is a community with a lot of developers, and if things are getting voted up, itβs because many of the folks on here might have enjoyed seeing the post/article/project.
Someone compiled linux with a C++ compiler a few months ago and the compiler found a few bugs. That was interesting and useful.
The Rust community really has an interest in showing the world that it is a serious candidate to replace C++. That's why we see a preponderance of "this same problem, but solved in Rust" - they're providing another data point to show that Rust can work in a problem space that had previously been the sole domain of C/C++. In that regard, I would think it interesting.
Instead I learned what Oberon allowed me to do, got to dive into the history of programming language research at Xerox PARC, and became a firm believer in GC enabled systems programming languages.
Programming languages landscape lacks dreamers like Alan Kay or Jobs, apparently many only believe in stuff that is demoed in front of them and even if proven wrong, they only care if they can take immediate profit from it and not 5 years down the road.
So always take a critic view on whatever is on the cover of IT Vogue.