Homebrew A5200DS - Improved

[wavemotion]

i do really appreciate what all you guys do, i have no knowledge on how to even make a start on this sort of thing, but i love the old systems, like Atari 2600, ZX Spectrum and Commodore 64

Me too, dj, me too!

I'm happy to have been able to contribute to the Atari 2600, 5200 and 7800 scene on the DS. Very happy with the performance on a DSi (especially amazing is the play on a DSi LL/XL where the screen holds onto pixels slightly longer and renders them very well). A good DSi LL from Japan is like $40 shipped on eBay and is well worth it as a retro-gaming godsend!

If I had infinite time, I'd probably want to do a proper Intellivsion Emulator for the DS. The Intellivsion Lives was really not well done - rendering amazing games like Minotaur (AD&D - Treasures of Tarmin) virtually unplayable as they cut off most of the inventory at the bottom of the screen. Grrr.....

 

[djleviticus]

Me too, dj, me too!

I'm happy to have been able to contribute to the Atari 2600, 5200 and 7800 scene on the DS. Very happy with the performance on a DSi (especially amazing is the play on a DSi LL/XL where the screen holds onto pixels slightly longer and renders them very well). A good DSi LL from Japan is like $40 shipped on eBay and is well worth it as a retro-gaming godsend!

If I had infinite time, I'd probably want to do a proper Intellivsion Emulator for the DS. The Intellivsion Lives was really not well done - rendering amazing games like Minotaur (AD&D - Treasures of Tarmin) virtually unplayable as they cut off most of the inventory at the bottom of the screen. Grrr.....

i got a nice yellow DSi, so i will give StellaDS a try over the weekend. I will put your StellaDS up there with ZXDS, amazing, shame there isnt a better c64 emulator for the DSi. I know the 3DS c64 runs really well on a N3DS.

 

[wavemotion]

i got a nice yellow DSi, so i will give StellaDS a try over the weekend. I will put your StellaDS up there with ZXDS, amazing, shame there isnt a better c64 emulator for the DSi. I know the 3DS c64 runs really well on a N3DS.

Nice! You'll be plenty happy - on the DSi with the 2x faster CPU, everything will run really well. Even the games that require flicker-free mode (Yars Revenge, Asteroids, Lady Bug, etc) will look amazing and run at 60FPS.

 

[djleviticus]

Nice! You'll be plenty happy - on the DSi with the 2x faster CPU, everything will run really well. Even the games that require flicker-free mode (Yars Revenge, Asteroids, Lady Bug, etc) will look amazing and run at 60FPS.

in twilght menu on stellads 1.6 on my dsi ive loaded up frogger and the you dont get the full screen of the game, weird

 

[wavemotion]

Looks perfect here. Make sure you're using the No-Intro NTSC roms. Those are the most common - the PAL stuff won't look right (too many scanlines for the DS). See the Compatibility.TXT for the list of the good No-Instro MD5sums you want.

 

[MarioKartFan]

@wavemotion The latest release is awesome. Montezuma’s Revenge has been a favorite of mine since the 1980s and it runs as smooth as butter on the 3DS. I noticed that for some home brew games the built in bios doesn’t do the trick. I had to drop in a real bios in the same directory as the emulator to run (e.g., Donkey Kong redux). Once I did it ran like a dream!!!

 

[wavemotion]

Glad to hear it, MKF!

Yeah, the Altirra open-source bios is not 100% compatible. It's nice that it can be included and "built-in" so some games will just run right out of the box... but for maximum compatibility you want to have 5200.rom placed in the same directory as A5200DS.NDS

Yeah, I'm pretty happy with the latest performance and sound code... though there are still "zingers" and other small artifacts in there. It's a wonder there isn't more - the whole sound system is asynchronous - meaning that the memory is written by the Arm9 processor and the wee Arm7 picks it up in memory and plays the sound - but there is no real coordination and so if the Arm9 fails to provide the samples, the Arm7 will just loop old samples. So when you get a hint of slowdown here or there, it causes a sound artifact that lasts no more than a fraction of a second. I guess it's the price we pay for having processors and letting one do some sound work while the other does the main gaming action. Still... I feel like there should be a better way...

Anyway, I'm porting the core sound improvements of A5200DS to A7800DS and it's sounding great. The 7800 has less wiggle room in terms of performance - the CPU is already pretty maxed out so I may have to abandon any hope of really running on the DS-LITE/PHAT with that one (The 1.9 DS-LITE will always be available - and older models will have to live with older/crappy sound). At least until someone smarter than me (not hard!!) comes along and improves it further

MKF - can you do me a favor? I don't have a 3DS. If you run Motezuma's Revenge on your 3DS and press X to show FPS and press Y to let it run full speed... how many frames does it achieve? It's 74 on my DSi - and I'm unsure if the 3DS would run it any faster or if it clocks the same as the DSi.

 

[MarioKartFan]

Glad to hear it, MKF!

Yeah, the Altirra open-source bios is not 100% compatible. It's nice that it can be included and "built-in" so some games will just run right out of the box... but for maximum compatibility you want to have 5200.rom placed in the same directory as A5200DS.NDS

Yeah, I'm pretty happy with the latest performance and sound code... though there are still "zingers" and other small artifacts in there. It's a wonder there isn't more - the whole sound system is asynchronous - meaning that the memory is written by the Arm9 processor and the wee Arm7 picks it up in memory and plays the sound - but there is no real coordination and so if the Arm9 fails to provide the samples, the Arm7 will just loop old samples. So when you get a hint of slowdown here or there, it causes a sound artifact that lasts no more than a fraction of a second. I guess it's the price we pay for having processors and letting one do some sound work while the other does the main gaming action. Still... I feel like there should be a better way...

Anyway, I'm porting the core sound improvements of A5200DS to A7800DS and it's sounding great. The 7800 has less wiggle room in terms of performance - the CPU is already pretty maxed out so I may have to abandon any hope of really running on the DS-LITE/PHAT with that one (The 1.9 DS-LITE will always be available - and older models will have to live with older/crappy sound). At least until someone smarter than me (not hard!!) comes along and improves it further

MKF - can you do me a favor? I don't have a 3DS. If you run Motezuma's Revenge on your 3DS and press X to show FPS and press Y to let it run full speed... how many frames does it achieve? It's 74 on my DSi - and I'm unsure if the 3DS would run it any faster or if it clocks the same as the DSi.

It runs at 74, which seems right since I’m pretty sure that in DS mode it’s basically 1:1 a DSi assuming you set the appropriate settings in TWiLightMenu++

 

[wavemotion]

https://github.com/wavemotion-dave/A5200DS

Version 2.1a - fixed command line launch for TWL++ (sorry @Robz8 !)
Y key is now alternate fire button like A (and Full-Speed toggle is only when you press the upper right corner of the touch screen).

 

[wavemotion]

I got 64K "MEGA" Carts working! That means some great ports like Berks4 and MULE will play!!

Now... maybe, just maybe, I'll attempt the "MEGA" 512k for Bosconian ... though if it banks switches too often, I don't think the DSi's processor will handle it. But maybe!

 

[wavemotion]

Version 2.2: https://github.com/wavemotion-dave/A5200DS

* Fixed launching via command line (so TWL++ integration will work now)
* Added support for 64k Super Carts (Laser Hawk, Dropzone, MULE, Berks4, etc)
* Added support for 512k Super Carts (Bosconian... though it runs really slowly)
* New memory map scheme for slight improvement in stubborn games like Bounty Bob Strikes Back

The support for 64k super carts is a huge step forward. There aren't a ton of 64k games, but what did get used for 64k conversions on the Atari 8-bit are amazing! Dropzone, MULE, Laser Hawk and Berks4 are all awesome ports. They all run at 60FPS with the exception of Berks4 which runs at 58-59 and will be very close to full speed (the very slight slowdown doesn't detract from the enjoyment).

I'm making headway into Bounty Bob Strikes Back. That bank-switching scheme is painful... and the game runs at 48FPS and sometimes up into the 50FPS when some enemies are eliminated. It's almost fun again.

I did get Bosconian 512k super cart running... but it runs really slowly. That's just pushing too much on the poor DSi processor.

 

[wavemotion]

Big breakthrough!

The ARM9 has fast memory for code and data. The fast code space was already being utilized (and I've extended that use to the maximum extent possible) but the DTCM "tightly coupled memory" was not being used. So I moved a few key lookup tables into that memory and got a full 10% speed boost across the board in core emulation! That's huge... finding 10% improvement isn't something that comes along every day. This renders the very stubborn Bounty Bob Strikes Back into the highly playable 55 FPS and a few of the other borderline games are now running full speed all the time.

Not doing a new release today - but it's checked in and you can just grab the most recent .NDS build.

PS: this also means that the same kinds of fast-memory speedups can be done for the other Atari emulators ... sigh. Always something to do.

PPS: this now renders many of the basic games very playable at or near full speed on a DS-LITE/PHAT.

 

[Coto]

Big breakthrough!

The ARM9 has fast memory for code and data. The fast code space was already being utilized (and I've extended that use to the maximum extent possible) but the DTCM "tightly coupled memory" was not being used. So I moved a few key lookup tables into that memory and got a full 10% speed boost across the board in core emulation! That's huge... finding 10% improvement isn't something that comes along every day. This renders the very stubborn Bounty Bob Strikes Back into the highly playable 55 FPS and a few of the other borderline games are now running full speed all the time.

Not doing a new release today - but it's checked in and you can just grab the most recent .NDS build.

PS: this also means that the same kinds of fast-memory speedups can be done for the other Atari emulators ... sigh. Always something to do.

PPS: this now renders many of the basic games very playable at or near full speed on a DS-LITE/PHAT.

Yeah, you can also use the 0x03000000 Shared WRAM, 32K to move data in there. Which resulted in 20% speed boost. As long as you don't use some BIOS calls (ARM9, as these may use 0x03000000, lzss callbacks, to name one), and that shouldn't be because the bios calls are mostly rewritten, thus, running from the EWRAM or ITCM areas).

It is possible to use both CODE and DATA sections in there, but IIRC CODE section can't reach either VRAM, or ITCM, or DTCM directly (as opposed to running code from EWRAM, which all of them work from there). Because of that, it's only treated as a IO storage for the emulator, thus, DATA section only.


For instance:
https://bitbucket.org/Coto88/snemulds/commits/0c36431a9965e83e35f2f147fc014bca83487736

 

[wavemotion]

Yeah, you can also use the 0x03000000 Shared WRAM, 32K to move data in there. Which resulted in 20% speed boost.

I wish I understood the architecture better. 32K is perfect - it allows all of the Bounty Bob banks and half of the 64K megacart banks to fit... but I couldn't get it to work. Rather than mess with linker scrips (which I'm not comfortable with), and since I'm only using the WRAM as one huge block of buffer... I tried this:

// WRAM!! 32k which is just enough to store the Bounty Bob stuff
// and half the 64K Megacart banks...
UBYTE *banked_image = (UBYTE *) 0x03000000;

Which didn't work. If I instead map this to the middle of normal EWRAM (say, 0x02500000) it works fine (but is no faster than letting the linker just place it in main memory).

Edit: One interesting thing I found is that if I move my buffer out to unused Video Ram (say, 06040000), I get a 10% speed improvement. VRAM must be faster in some way than normal memory? Using VRAM for banked memory copy has Bounty Bob Strikes Back running at 63FPS (finally!!) and other games that were running on the margin are now running full speed on the DSi.

 

[Coto]

I wish I understood the architecture better. 32K is perfect - it allows all of the Bounty Bob banks and half of the 64K megacart banks to fit... but I couldn't get it to work. Rather than mess with linker scrips (which I'm not comfortable with), and since I'm only using the WRAM as one huge block of buffer... I tried this:

// WRAM!! 32k which is just enough to store the Bounty Bob stuff
// and half the 64K Megacart banks...
UBYTE *banked_image = (UBYTE *) 0x03000000;

Which didn't work. If I instead map this to the middle of normal EWRAM (say, 0x02500000) it works fine (but is no faster than letting the linker just place it in main memory).

Edit: One interesting thing I found is that if I move my buffer out to unused Video Ram (say, 06040000), I get a 10% speed improvement. VRAM must be faster in some way than normal memory? Using VRAM for banked memory copy has Bounty Bob Strikes Back running at 63FPS (finally!!) and other games that were running on the margin are now running full speed on the DSi.

Indeed. VRAM is very fast. Or to put it simply, EWRAM is too slow. Everything else is fast.

DTCM/ITCM/VRAM/Shared Memory(0x03000000)/OBJ/etc are fast. VRAM can only read and write in u16(2 bytes)/u32 types(4 bytes). It is also possible to enable caches, but caches can lead to bugs so I shut them off. If you are NOT using self modifier code, then caches can help speed up CODE sections even further

Also the linker way of relocating code ensures all generated code to be relative to 0x03000000. This ensures program to work right at once. (If it was calling some code from ITCM, then jumps to EWRAM, doesn't matter, because the opcodes would still point to 0x03000000).

 

[wavemotion]

Version 2.3: https://github.com/wavemotion-dave/A5200DS

With the new DTCM and VRAM usage, virtually everything runs full-speed now on a DSi or above and many of the more basic games will run full-speed on a DS-LITE/PHAT. Bounty Bob Strikes Back is now playable at a full 60FPS!

 

[wavemotion]

Indeed. VRAM is very fast. Or to put it simply, EWRAM is too slow. Everything else is fast.

Ah! Well, it's definitely helpful and since I'm only ever moving 4k/32k blocks around for bank swapping, the VRAM solution works really well.

One thing that I find infuriating about all this is that whenever I add or remove code, it can cause memory to shift around enough to have a noticeable performance change. For example, I've built StellaDS and can get a full 151FPS on Adventure. I remove some code that is in some out-of-the way place (i.e. not executed except when selecting options) and suddenly it will drop to 140FPS on the next build. Then I add back the code or just add back some equivalent NOP loop and it's back to fast again. I suspected alignment or some compiler optimization that goes sideways when memory gets moved around. I tried to examine the .MAP files on each build and it's amazing how a little change can move code around... but I don't understand why moving code would affect performance. I assumed all code ran from code-space and nothing there was faster than anywhere else.

Mostly now I'm very careful when I remove or add code to see if I've got into a state of lower performance... and then re-arrange the deck chairs on the Titanic slightly and poof... performance back.

 

[Coto]

Ah! Well, it's definitely helpful and since I'm only every moving 4k/32k blocks around for bank swapping, the VRAM solution works really well.

One thing that I find infuriating about all this is that whenever I add or remove code, it can cause memory to shift around enough to have a performance change. For example, I've built StellaDS and can get a full 151FPS on Adventure. I remove some code that is in some out-of-the way place (i.e. not executed except when selecting options) and suddenly it will drop to 140FPS on the next build. Then I add back the code or just add back some equivalent NOP loop and it's back to fast again. I suspected alignment or some compiler optimization that goes sideways when memory gets moved around. I tried to examine the .MAP files on each build and it's amazing how a little change can move code around... but I don't understand why moving code would affect performance. I assumed all code ran from code-space and nothing there was faster than anywhere else.

Mostly now I'm very careful when I remove or add code to see if I've got into a state of lower performance... and then re-arrange the deck chairs on the Titanic slightly and poof... performance back.

Trust me. It's a bug in the way GCC generates code. That also happens when rebulding everything as -O2 or -Os. It will randomly generate faster code at either optimize profiles. Get used to do dev regardless of the speed. And when a build is done, pick either one giving the most speed.

Of course this does not happen under a paid environment (such as codewarrior, or ARM RVCT compiler). And that's because the compiler does a much better job. You'll find yourself pretty frustrated when sometimes moving a variable will cause white screens. But it's all good. Ask anything, I'll help!

 

[wavemotion]

You've been immensely helpful, @Coto !! Thanks!

 

[wavemotion]

Not enough for a new build, but the nightly check-in has a fix for Star Trek so you can finally START the game! The buggy programming back 40 years ago has now been emulated properly

Also, a few more memory tweaks to get another 3% speed boost. Many games will run near full speed on the DS-LITE and the only game that won't run full speed on the DSi is the crazy-big Bosconian (due to the heavy bank switching).