As an intro for the emulator itself I have to note that bigPEmu is one of those emulators that hits the ground running. Compatibility, speed and features/GUI are very impressive and that’s actually an understatement in this instance.
As an intro to the man behind the project, we've added a link at the end of this text to a detailed interview with him at the RetroRGB Youtube channel.
When did you start working on bigPEmu as a standalone project? Is it your first (non commercial) emu project and how long did it roughly take overall?
Rich: I started it right around the beginning of February. It took about 3 months to get the whole retail cartridge library running nicely, and that's the version of the emulator core which shipped in Atari 50. After that was wrapped up and integrated into Bakesale (Digital Eclipse's engine), I started work on the standalone framework and gradually chipped away at that stuff. It's hard to say how much time that part ate, because I was juggling it with a lot of stuff, but I went a little crazy with that side of things too and ended up including a bunch of secrets and adding a lot of nice little fluff features. I ended up sitting on a release for a little while, but DE was kind enough to give me the greenlight to release it before my second surgery. I figured, just in case anything went horribly wrong there, it would be nice to see it out into the world before that happened. Fortunately, the surgery went well!
If I’m not mistaken bigPEmu is a high level emulator right? (or maybe not???) Were there any outstanding challenges while putting this emu together?
Rich: It depends on your definition of "high level", but in my sense of it, no, I don't think it is a high level emulator. There are certain approximations and sacrifices (like having various "lockstep" modes to determine how closely the processors actually run together for the sake of performance), mostly to keep things running smoothly even on more limited platforms (like the Switch) without relying on any form of dynamic recompilation. You're not allowed to do that on any of the consoles these days! I didn't want to rely on having to do any real ahead-of-time translation of the RISC code either, although I probably would have come up with some automated caching of generated (translated to C/C++ for convenient target compatibility) code if it had been really necessary. Of course, self-modifying code isn't terribly uncommon in the Jaguar library either, and that's a much bigger pain to deal with when you're limited to statically cached and translated code, but it's also a solvable problem.
Anyway, getting back on track here. BigPEmu emulates all of the pieces of the Jaguar with a mind toward being functionally accurate, and doesn't hand any of the work off to higher-level systems. The Blitter, OP, RISC chips, M68K, etc. are all implemented to specification. With the way the Blitter works, if you wanted to do something like implement some hardware triangle-based rendering, there isn't really a good way to hand that rendering off to a higher-level system without a decent bit of per-title work. I'm taking the same approach with the Jaguar CD (which I just started working on), implementing it at a hardware register level instead of doing the high level thing and just hooking into CD BIOS calls. This approach is ultimately the best way to ensure compatibility and accuracy, and performance isn't really a problem there. Emulating the CD hardware isn't too expensive in contrast to a lot of things, so a high level approach would only really make sense if I just didn't want to have to spend more time understanding the hardware! This will also allow things like VLM, which does tons of its own direct hardware access instead of relying on the BIOS, to function without any special work. I haven't yet looked to see if anything else in the retail library is being naughty and directly accessing hardware instead of just calling BIOS functions, but if there is, it won't break. Hooray.
As far as challenges, yeah, there were a lot of undocumented and quirky things to discover with the hardware, and I'm still discovering them. Going through the homebrew library has been a good way of bringing more of those things to light. Timing is also a big challenge with this hardware, and I had to deal with tracking down some pretty insidious bugs that often related to the pipelining in the RISC chips. When you introduce write-after-write hazards into very tenuous circumstances (like a dependency on an external memory access which is affected by whether other components also happen to be hogging the bus), things get pretty crazy. So it's been a continuous battle of trying to make timing accurate enough to avoid serious problems like that while retaining good performance, and there's definitely a lot more I can do to make timing even more accurate. It's a long term goal to get things running accurately down to the cycle, but that will probably end up being a "powerful native CPU" path.
Which emulator/emulators did you first use that possibly inspired you to write and share your own?
Rich: My first emulator memories are with Bloodlust's Nesticle, and later Genecyst which also really stands out for me. I used ZSNES for a long time as well. I loved those things, they each reached the pinnacle of what they were made to do at the time, and they did it with personality. Especially the Bloodlust emulators. I think I channeled the same spirit when I was writing the little emulator intro sequence and thinking of secrets to stuff in there. As far as motivation for writing the emulator, I think it was a combination of having derived a lot of joy from emulators already, and wanting to apply some of my skillset to make a really good one for a system that needed it.
I must note that the GUI of the emulator is way above and beyond the normal GUI we get on typical emulator releases (if any! sometime s it’s just CLI
. Polished and easy to use. Was your past programming experience a factor towards that result?
Rich: Thank you! I think my past experience definitely factored in. I didn't study any existing GUI or draw from specific examples when I was writing it, I just let my brain tell me what to do, and that was the result. I'm certain that I was inspired by countless GUI and programming experiences, but I did the ML thing and just let my brain give me end results without examining the underlying process.
What is your overall perspective for the emulation scene in general? What would you like to see materialized next?
Rich: The support for BigPEmu has been pretty amazing, and I've met a lot of good people in the Jaguar homebrew community. It's made me really happy. With the whole cancer thing going on, the timing here in meeting people and finding so much support in a community like this has been really good on a personal level as well. So I couldn't ask for more on that front. As far as what's next for emulation as a whole, there are still those less-than-perfectly emulated systems that deserve some love (like the 3DO and Saturn), and there's always a bigger challenge on the horizon for emulating more current hardware. Things tend to get much higher level in that realm, oftentimes out of necessity, but that's also generally compatible with the higher level way the software is written now.
I think the bigger challenge is eventually going to be overcoming encryption, the vendors are doing their best to keep people from even getting into userland (even with some measure of success, they'll still have people probing for kernel vulnerabilities on devkits from the very start), and I think that's a long road for them, but eventually they're likely to succeed as hardware capability converges with the desire for absolute software fascism. Either that, or everything will get moved to the cloud once that infrastructure really becomes viable and offers a more acceptable user experience. Which will make emulation impossible unless the vendor decides to release the guts of the thing one day, and the prominent vendors in the industry have shown they are not at all generous with materials of that nature. So once things get to that point, we might find ourselves in a situation where emulation can't help us preserve an entire library of software written for newly dying hardware. In the end, that's the result of unfettered capitalism.
As a follower of the emulation scene over many years I notice that it is not very often that highly talented optimization wizards (a.k.a. exceptional developers) are tangled in an emulation project. However when that happens we have some fireworks (bigPEmu - exhibit A). I don’t want to give other specific examples because I will miss important instances and that would be a shame but the question to you is, would you ever consider looking into other emulation projects and giving hints to developers about what could be done differently to hit important performance thresholds in relevance to game playability?
Rich: Thank you, that’s very flattering. And, of course! Assuming I live long enough, I definitely plan to continue working in emulation and going wherever my heart takes me. I expect to be busy with the Jaguar for quite a while yet, improving BigPEmu and adding more features, with Jaguar CD support being the Next Big Thing underway. After that, though, now that I actually have a decent number of people supporting me on Patreon, I'll probably come up with a list of projects that would make me happy to work on and do a poll to see which way people want me to go.
Can you please tell us what are the best ways for bigPEmu fans to support this kick-ass project further?
Rich: Certainly! If you're interested in my continued work on BigPEmu and other emulation projects, and maybe some interesting higher-level hybrid emulation-enhancement projects that are still swirling around in my head, please come show your support on Patreon: https://www.patreon.com/richwhitehouse
The Patreon account is really helping, especially right now, since I've been able to take on less contract work with the cancer/surgery situation. Patreon funds are making a real dent in my monthly expenses, and rather than the usual stressful contract milestone situation, it's a lot easier to spend time chipping away on the emulator with the support of an understanding community. I really couldn't think of anything better for me right now, honestly, and the success I've enjoyed there so far really caught me by surprise. I can't say it enough, I'm incredibly thankful for everyone in the community that's shown up and offered their support.
Thank you very much for the interview, we truly and from the bottom of our emu-junkie hearts, wish only the best for your emulation interests but for you personally as well!
Rich: It was my pleasure! Thank you, I appreciate it, and the support warms my own emu-junkie heart!
As an intro to the man behind the project, we've added a link at the end of this text to a detailed interview with him at the RetroRGB Youtube channel.
When did you start working on bigPEmu as a standalone project? Is it your first (non commercial) emu project and how long did it roughly take overall?
Rich: I started it right around the beginning of February. It took about 3 months to get the whole retail cartridge library running nicely, and that's the version of the emulator core which shipped in Atari 50. After that was wrapped up and integrated into Bakesale (Digital Eclipse's engine), I started work on the standalone framework and gradually chipped away at that stuff. It's hard to say how much time that part ate, because I was juggling it with a lot of stuff, but I went a little crazy with that side of things too and ended up including a bunch of secrets and adding a lot of nice little fluff features. I ended up sitting on a release for a little while, but DE was kind enough to give me the greenlight to release it before my second surgery. I figured, just in case anything went horribly wrong there, it would be nice to see it out into the world before that happened. Fortunately, the surgery went well!
If I’m not mistaken bigPEmu is a high level emulator right? (or maybe not???) Were there any outstanding challenges while putting this emu together?
Rich: It depends on your definition of "high level", but in my sense of it, no, I don't think it is a high level emulator. There are certain approximations and sacrifices (like having various "lockstep" modes to determine how closely the processors actually run together for the sake of performance), mostly to keep things running smoothly even on more limited platforms (like the Switch) without relying on any form of dynamic recompilation. You're not allowed to do that on any of the consoles these days! I didn't want to rely on having to do any real ahead-of-time translation of the RISC code either, although I probably would have come up with some automated caching of generated (translated to C/C++ for convenient target compatibility) code if it had been really necessary. Of course, self-modifying code isn't terribly uncommon in the Jaguar library either, and that's a much bigger pain to deal with when you're limited to statically cached and translated code, but it's also a solvable problem.
Anyway, getting back on track here. BigPEmu emulates all of the pieces of the Jaguar with a mind toward being functionally accurate, and doesn't hand any of the work off to higher-level systems. The Blitter, OP, RISC chips, M68K, etc. are all implemented to specification. With the way the Blitter works, if you wanted to do something like implement some hardware triangle-based rendering, there isn't really a good way to hand that rendering off to a higher-level system without a decent bit of per-title work. I'm taking the same approach with the Jaguar CD (which I just started working on), implementing it at a hardware register level instead of doing the high level thing and just hooking into CD BIOS calls. This approach is ultimately the best way to ensure compatibility and accuracy, and performance isn't really a problem there. Emulating the CD hardware isn't too expensive in contrast to a lot of things, so a high level approach would only really make sense if I just didn't want to have to spend more time understanding the hardware! This will also allow things like VLM, which does tons of its own direct hardware access instead of relying on the BIOS, to function without any special work. I haven't yet looked to see if anything else in the retail library is being naughty and directly accessing hardware instead of just calling BIOS functions, but if there is, it won't break. Hooray.
As far as challenges, yeah, there were a lot of undocumented and quirky things to discover with the hardware, and I'm still discovering them. Going through the homebrew library has been a good way of bringing more of those things to light. Timing is also a big challenge with this hardware, and I had to deal with tracking down some pretty insidious bugs that often related to the pipelining in the RISC chips. When you introduce write-after-write hazards into very tenuous circumstances (like a dependency on an external memory access which is affected by whether other components also happen to be hogging the bus), things get pretty crazy. So it's been a continuous battle of trying to make timing accurate enough to avoid serious problems like that while retaining good performance, and there's definitely a lot more I can do to make timing even more accurate. It's a long term goal to get things running accurately down to the cycle, but that will probably end up being a "powerful native CPU" path.
Which emulator/emulators did you first use that possibly inspired you to write and share your own?
Rich: My first emulator memories are with Bloodlust's Nesticle, and later Genecyst which also really stands out for me. I used ZSNES for a long time as well. I loved those things, they each reached the pinnacle of what they were made to do at the time, and they did it with personality. Especially the Bloodlust emulators. I think I channeled the same spirit when I was writing the little emulator intro sequence and thinking of secrets to stuff in there. As far as motivation for writing the emulator, I think it was a combination of having derived a lot of joy from emulators already, and wanting to apply some of my skillset to make a really good one for a system that needed it.
I must note that the GUI of the emulator is way above and beyond the normal GUI we get on typical emulator releases (if any! sometime s it’s just CLI
. Polished and easy to use. Was your past programming experience a factor towards that result?Rich: Thank you! I think my past experience definitely factored in. I didn't study any existing GUI or draw from specific examples when I was writing it, I just let my brain tell me what to do, and that was the result. I'm certain that I was inspired by countless GUI and programming experiences, but I did the ML thing and just let my brain give me end results without examining the underlying process.
What is your overall perspective for the emulation scene in general? What would you like to see materialized next?
Rich: The support for BigPEmu has been pretty amazing, and I've met a lot of good people in the Jaguar homebrew community. It's made me really happy. With the whole cancer thing going on, the timing here in meeting people and finding so much support in a community like this has been really good on a personal level as well. So I couldn't ask for more on that front. As far as what's next for emulation as a whole, there are still those less-than-perfectly emulated systems that deserve some love (like the 3DO and Saturn), and there's always a bigger challenge on the horizon for emulating more current hardware. Things tend to get much higher level in that realm, oftentimes out of necessity, but that's also generally compatible with the higher level way the software is written now.
I think the bigger challenge is eventually going to be overcoming encryption, the vendors are doing their best to keep people from even getting into userland (even with some measure of success, they'll still have people probing for kernel vulnerabilities on devkits from the very start), and I think that's a long road for them, but eventually they're likely to succeed as hardware capability converges with the desire for absolute software fascism. Either that, or everything will get moved to the cloud once that infrastructure really becomes viable and offers a more acceptable user experience. Which will make emulation impossible unless the vendor decides to release the guts of the thing one day, and the prominent vendors in the industry have shown they are not at all generous with materials of that nature. So once things get to that point, we might find ourselves in a situation where emulation can't help us preserve an entire library of software written for newly dying hardware. In the end, that's the result of unfettered capitalism.
As a follower of the emulation scene over many years I notice that it is not very often that highly talented optimization wizards (a.k.a. exceptional developers) are tangled in an emulation project. However when that happens we have some fireworks (bigPEmu - exhibit A). I don’t want to give other specific examples because I will miss important instances and that would be a shame but the question to you is, would you ever consider looking into other emulation projects and giving hints to developers about what could be done differently to hit important performance thresholds in relevance to game playability?
Rich: Thank you, that’s very flattering. And, of course! Assuming I live long enough, I definitely plan to continue working in emulation and going wherever my heart takes me. I expect to be busy with the Jaguar for quite a while yet, improving BigPEmu and adding more features, with Jaguar CD support being the Next Big Thing underway. After that, though, now that I actually have a decent number of people supporting me on Patreon, I'll probably come up with a list of projects that would make me happy to work on and do a poll to see which way people want me to go.
Can you please tell us what are the best ways for bigPEmu fans to support this kick-ass project further?
Rich: Certainly! If you're interested in my continued work on BigPEmu and other emulation projects, and maybe some interesting higher-level hybrid emulation-enhancement projects that are still swirling around in my head, please come show your support on Patreon: https://www.patreon.com/richwhitehouse
The Patreon account is really helping, especially right now, since I've been able to take on less contract work with the cancer/surgery situation. Patreon funds are making a real dent in my monthly expenses, and rather than the usual stressful contract milestone situation, it's a lot easier to spend time chipping away on the emulator with the support of an understanding community. I really couldn't think of anything better for me right now, honestly, and the success I've enjoyed there so far really caught me by surprise. I can't say it enough, I'm incredibly thankful for everyone in the community that's shown up and offered their support.
Thank you very much for the interview, we truly and from the bottom of our emu-junkie hearts, wish only the best for your emulation interests but for you personally as well!
Rich: It was my pleasure! Thank you, I appreciate it, and the support warms my own emu-junkie heart!