ares v119.2 released
Unfortunately a few critical issues crept in between v118 and v119, so here is a bugfix release for all reported issues.
It also fixes some game bugs while I'm at it, and boosts 32X compatibility from 50% to a little over 60%.
Please do upgrade if you have v119, this one's important.
- SH2: MAC must increment R[n] before reading from R[m]; fixes Virtua Fighter and Toughman Contest
- SH2: fixed dynarec MOV @Rm+,Rn to not increment when Rm==Rn
- SH2: fixed dynarec TST instruction
- SH2: improved dynarec accuracy by breaking blocks on delay slot branches
- SH2: improved dynarec accuracy by decreasing the underclocking amount
- Mega Drive: implemented undocumented VSRAM and CRAM DMA fill
- Mega Drive: simplified scanline VDP renderer; fixes TMNT: Tournament Fighters graphics
- Mega Drive: improved region detection; correctly identifies Alien Soldier region now
- Mega CD: fixed crash on game load
- Super Famicom: fixed direct color mode; fixes Secret of Mana world map
- WonderSwan Color: fixed initial state for new EEPROMs plus EEPROM size; fixes missing sound
- lucia: fixed saving RAM files when a manual save path was specified
- ruby: fixed library dependency detection for Arch Linux and other distributions
- hiro/GTK3: added CSS stylesheet overrides to improve appearance [Screwtape]
Download v119.2 from ares.dev
ares v119 released
I'm releasing ares v119 today, which includes very preliminary Sega 32X emulation support. Compatibility is currently at around 50% with the dynamic recompiler, probably closer to 75% with the cached interpreter, and since the system requirements were a bit too steep (on account of my Mega Drive core being cycle/dot-accurate), I downclocked the SH2s a bit until I can speed up the emulator more. You'll currently need about a Ryzen 5 2600 to hit 60fps reliably. With the underclock, my Ryzen 7 5800X hits 120fps, and without it, 85fps.
Although the compatibility for the new 32X core is a bit low, this is mostly due to pesky CPU bugs. The accuracy is quite high and I've emulated as much of the 32X and SH7604 peripheral functions as possible. I pass all 161 tests from the Mars Check Program. It should not take much more work to reach 98% compatibility in the future. Sega CD 32X emulation support is present, but is likely not functional, as I haven't tested it yet.
Other major features in this release include Sega SVP support for Virtua Racing, plus improved Nintendo 64, Mega Drive, and Mega CD emulation compatibility.
I'm going to start working on Sega Saturn emulation now, while Luke Usher works on Neo Geo emulation. No promises as to when or if these cores will become playable, I'm just giving you all a heads up since you'll see the skeletons for these systems in the source code now.
- Nintendo 64: improved Expansion Pak detection
- Nintendo 64: fixed swapped L and R buttons [simer]
- Nintendo 64: emulated the RST bit for gamepads
- ruby: added library detection support for the Linux and BSD targets
- lucia: gained support for game paks (custom file dialog only)
- Super Famicom: added support for Super Game Boy, Sufami Turbo, and BS Memory packs
- hiro: made SourceEdit optional for gtk2 and gtk3 targets (disabled for ares)
- Nintendo 64: emulated 2048-byte EEPROM identifier and transfer protocol
- Super Famicom: corrected ppu-performance widths table indexing to consider overscan
- Mega CD: fixed a bug in register $ff8003; allows Popful Mail to boot [TascoDLX]
- Mega Drive: fixed a bug with 256-width video modes
- Mega Drive: improved VDP DMA emulation which should fix many games
- Mega Drive: added SVP emulation
- Mega Drive: added 32X emulation
- Mega CD: fixed a bit-masking bug in register $ff8004; fixes Radical Rex [TascoDLX]
- Nintendo 64: fixed C implementation of RSP VMACU instruction
- Nintendo 64: use correct NTSC and PAL PIF ROM images based on the region
- Mega Drive: fixed reset logic, Z80 interrupt timing + prefix timing + bus control [TascoDLX]
- Mega CD: fixed word RAM access and CDC DMA word RAM transfers [TascoDLX]
- Nintendo 64: improved RSP VMOV emulation [Rasky]
- Nintendo 64: fixed RSP DMEM DMA alignment (&~7, not &~3) [Rasky]
- Nintendo 64: upgraded to the latest version of ParaLLEl-RDP
- nall: greatly expanded recompiler/amd64's supported intrinsics
- mia: substantial refactoring around a new virtual filesystem implementation from nall
You can download ares v119 from the official website.
You can follow ares progress updates on my Twitter account.
Aside: while I have your attention, the official website for bsnes is now bsnes.dev, and for higan it is now higan.dev. If you run an emulation-related website, if you could please update your bookmarks I would greatly appreciate that. Thank you ^-^;
Sega 32X progress
I've ironed out nearly all of the bugs and reached around 85% game compatibility.
ares now passes all 161 Mars Check Program tests, and I've implemented a cached interpreter for the SH2s.
Because of how demanding the base Sega Genesis (cycle-accurate 68K + Z80, dot-accurate VDP, PSG + YM2612) and Sega CD (additional faster 68K, extra VDP, PCM, CD-DA) is, and then adding the 32X (dual SH2s, extra VDP, PWM) on top of all of that, this likely isn't going to be enough headroom. Right now, I'm barely maintaining 60fps with my 5800X without the Sega CD component, so I am going to have to write a pure dynamic recompiler for the SH2s, and start using a priority queue again for scheduling the peripheral events that the SH7604 has built-in. I'll also likely need to improve and use my Genesis scanline renderer for all of this.
Things should go better with Sega Saturn emulation, since I won't have to start from a core built around cooperative threading and dot-based rendering, and I should be able to offload the video rendering to another thread, but that's still going to be no walk in the park either. I may need to go even further and implement a cached interpreter for the 68K as well. We'll see how it goes, but one way or another I'll get us to 60fps for both eventually.
Sega 32X and SVP emulation
I've added Sega 32X and SVP emulation to ares.
The SVP emulation runs the only game that uses it perfectly well, but the 32X emulation will need quite a long time to mature.
For starters, it really needs a dynamic recompiler and an event priority queue to speed things up. There are also many bugs in the implementation, so compatibility is currently low. The idea is to refine the SH-2 (SH7804) cores for the 32X support, so that in the future, I'll be able to jump into the Sega Saturn with mature and performant SH-2 and 68K cores. But that's rather far off into the future.
ares v118 released
I'm excited to launch ares v118 today, the first release featuring playable, full-speed Nintendo 64 emulation!
The new Nintendo 64 emulation is made possible thanks to Themaister very graciously porting his Vulkan-based ParaLLEl-RDP graphics renderer to ares. With its default settings, it is nearly pixel-perfect to real hardware, and it optionally supports upscaling to 2x or 4x the original Nintendo 64 resolution, plus optional supersampling back down to the original resolution (for enhanced anti-aliasing) if desired. The Vulkan support requires an appropriate graphics card, and either Windows or Linux. At this time, Vulkan is not available for macOS nor the BSDs.
Also new for the Nintendo 64 core in this release is Rumble Pak, Cartridge Pak, SRAM, EEPROM, and Flash save support. Note that for right now, the Rumble Pak will only be enabled for games which use internal saves (SRAM, EEPROM, and Flash.) That does not cover all Rumble Pak-capable games. The option to choose between Rumble Paks and Cartridge Paks will be added to a future release.
For the PlayStation core, Luke Usher provided two rendering fixes that allow Final Fantasy VII and Tony Hawk's Pro Skater to be fully playable!
Right now, approximately 33% of the Nintendo 64 library is fully playable, and about 67% of the PlayStation library is fully playable. Each core has only been under active development for about one month each, so they both have a long way to go. Please treat these early releases as tech samples, rather than finished emulation cores.
Further, note that the Nintendo 64 and PlayStation cores employ cached interpreters. This is a middle-ground between the accuracy of interpreters and the performance of dynamic recompilers. As such, ares' system requirements will be a bit higher than traditional emulators for these systems. Presuming no background task interference or CPU throttling, generally speaking, a Ryzen 5 2600 or better CPU should get you to around ~120fps in the average case, and ~60fps in the worst case.
The source code has also been released under the terms of the Creative Commons BY-NC-ND 4.0 license.
You can download ares v118 now from the official ares website.
Bahamut Lagoon released
The Bahamut Lagoon fan translation project has officially concluded.
I am so incredibly grateful for all of the support I've received in realizing this dream.
My eternal gratitude to Tom for making this dream a reality with his translation.
Further, I can't thank everyone enough who helped beta test and proofread for this patch.
Truly, we put out the best patch that we possibly could! It's been a real honor!
You can download the final version 1.1 patch and source code here.
ares v117 released
It is my privilege to release ares v117 today.
Most notably, this release adds Sony PlayStation emulation. Please understand however that this support is new, and compatibility will be low. That said, the base hardware is entirely emulated, including MDEC, SPU, CD-XA, memory card support, etc. It shouldn't take much effort to raise the compatibility to a respectable level in the future. And thanks to dynamic recompilation and multi-threading, it should run at full-speed even on modest hardware. ares can run games in either ISO/CUE or BIN/CUE format, as split/WAV files or as a single merged BIN file.
As for the Nintendo 64, Themaister has ported Parallel-RDP to it, and it too is now capable of running commercial games at full-speed, with accuracy just shy of Cen64. However, the support is too new and untested to release at this time, and memory card support has not been added yet. Nintendo 64 support should ship with the next release instead.
Beyond this, there are six months of emulation improvements: many new Famicom mappers were added, several Master System and Game Boy Advance emulation bugs were fixed, etc. Also, a second virtual gamepad has been added for multi-player support.
Everything I've ever written has been open source: ares won't be any different. But for the immediate future, I'm holding off while we work some things out. Namely:
1. I won't be using GitHub, so I have to set up an alternative version control system and issue tracker for hosting the code.
2. I don't want to subdivide fixes between higan and ares. That's already a big enough problem for higan and bsnes.
3. angrylion is non-commercial, and it's still part of ares if compiled in.
4. I don't personally want ares to be sold commercially. I realize that would make it non-FOSS, and I am okay with that.
For the time being, anyone involved in ares' development has access to the source code. And as with my promise in 2004, I stil remain committed to my final software release being under the ISC license. I'll try to get binaries ready for other platforms in the mean time.
I received my first real computer in 1997.
Almost immediately, a friend introduced me to emulators (Snes97 and ESNES) and fan translations (RPGe.) I've always been regretful that I missed the true origins of both scenes by maybe a year, but there's not a lot I could do about that. But I knew pretty much immediately that I wanted to be a part of both of these scenes. But at the time, I didn't know how to program at all. Not only was I year late to the start, I also was at a disadvantage in not having the skills to participate yet.
Still, I got to work right away, and while I've talked at length about the early days with Bahamut Lagoon, that's not all of my early past. The actual first game I worked on was Dragon Quest I & II, where I was manually searching and replacing text from the English NES games by hand with a hex editor. Needless to say, that didn't end well. Though I did go on to teach the person (ChrisRPG) who ended up finishing that fan translation, and I ended up contributing code to said project.
But what's more interesting is that bsnes was also not my first emulator, it was merely my first successful one. I took to programming really fast, and the first emulation project I tried to work on was with ATani. We were trying to make the first Sega CD emulator, all the way back in 1998. Although we weren't successful then, ATani went on to produce a working Sega Genesis emulator, and I later produced a working Sega CD emulator of my own.
I also worked on an unnamed Nintendo 64 emulator, which never got past a CPU core, around 1999 or so. There was also an unnamed Sega Genesis emulator that I got to run a couple demos around the same time before the sheer complexity of the 68000 CPU overwhelmed me back then.
But most interestingly, I had written an SNES CPU emulator for the purposes of fan translation work. My idea was that rather than trying to reverse engineer and write our own C ports that might be buggy, we could instead use a CPU emulator to decompress graphics and scripts from the original Japanese games using their original decompression routines. The idea worked fairly well and I used it to help out several fan translation projects (including my own) back in the day.
Using that core and expanding upon it around 2000 or so, I created my first SNES emulator, which I called StarSNES. It too ran many demos, but no commercial games. Still, this was the closest I had gotten to creating my first working emulator.
Aside from that, I also contributed a bit of code to ZSNES back around 2000 as well. 2001-2003 was spent working on Der Langrisser, and my time was limited on account of needing to work two full-time jobs to make ends meet back then. And so it wasn't until 2004 that I really had the time and knowledge to become successful in emulator development.
To wrap this up ... it's interesting looking back and seeing the overall trend: I never give up on anything I start. Every fan translation I wanted to work on was either completed by me or by someone I've helped do so. Every emulator I've wanted to write I've ended up creating in the end. Japanese was similar: I had wanted to learn that language since I was 14. It took actually moving to Japan and being immersed in the language for several years for it to finally click, but like everything else I eventually got there.
I think this might be part of the reason I'm so hesitant to start entirely new projects ^-^; but now that I've finished everything I've ever wanted to, I've started doing just that and taking up new endeavors. I hope to one day show you all some of the new things I've been working on. It turns out you can teach an old cat new tricks ~
Hi there, I'm Near. This is my Twitter-but-better clone.
I'll be using near.sh/posts to host long-form messages and posts requiring file attachments.
I'll mostly only be using this area to write about emulation topics and about projects I'm working on, but you never know, I might post about other topics from time to time as well.
In the future, I'll implement an RSS feed for this page so that you can follow updates externally, but for right now, I'm afraid you'll have to check this page for updates. As such for now, whenever there's a new message here, I'll cross-post it over to my Twitter account.