Homebrew Stella-DS Improved

[wavemotion]

Why not... numbers are cheap and it rained all Memorial Weekend so here's another release!

Version 2.4: https://github.com/wavemotion-dave/StellaDS

* A bit more juice squeezed out of the TIA. Added cart-specific options to bypass VerticalBlank zero (not all games need that memory cleared if we are dealing with a static screen... and this buys us CPU cycles!) and, somewhat more dangerously, HorizontalBlank clearing can be disabled for more speed. Only a few of the more stubborn games utilize these but it provides a few more frames/sec on the complicated games! Phaser Patrol is up to 55FPS as is Official Frogger. Elevators Amiss (the low water mark for any game supported by the emualtor) is up to 52FPS.
* Removed PAL/NTSC option... only NTSC is supported (all games were released in NTSC except a dozen PAL exclusives which have long since been converted to run on NTSC - Search Atariage).
* General cleanup and minor memory/code optimizations to get the most out of the emulator.
* Added 2 more lines of resolution before the top of the screen and 5 more below... this allows the games that utilize underscan and/or significant overscan to show properly. Scores and such won't get cut-off so easily now.

 

[Indy13]

Thanks for the latest updates @wavemotion

I tested my games directory with the last two versions of StellaDS on my DS Lite and for the moment I don't know which one to choose the 2.3 is good and it keeps the PAL and NTSC system, the 2.4 adds some interesting finishes but it there is no longer a PAL and NTSC system, I have quite a few PAL games in my games directory very often both versions and even I must admit that most of the time I only use the NTSC system, it I still use the PAL system somtimes and the rendering is better on some games, so for the moment I have three versions of StellaDS: the original, the 2.3 for the PAL system / NTSC and 2.4 for speed, that's a lot of versions ^^

Would it be possible to make a 2.4 version by reintegrating the PAL / NTSC system ?

 

[wavemotion]

Thanks for the feedback, Indy!

So, I think it's just an optical illusion. The PAL-NTSC switch was, literally, only a color swap to a different palette. I never got around to making it work ... so if you turn on frame display you will see it's still running "pal" games at 60FPS (instead of the correct 50FPS) and internally we are still rendering 262 lines (ntsc) vs 312 (pal). Since the switch did nothing other than change colors - I removed it since nobody had complained about PAL issues and 99% of most rom sets are NTSC for the Atari 2600 (there were very few PAL exclusives).

However - you're one of my favorite people here and as such, I will make PAL-NTSC work properly for you. Give me a day or two and I'll have a Version 2.5 with proper NTSC and PAL support!


Edit: I went back to the original version I started with (@Robz8 version from Aug 2020 which is largely AlekMaul's original with a few tweaks) - turns out that version didn't deal with PAL properly either. It's hard coded to 60FPS and the max scalines is 290 (which is 262 plus 28 overscan lines to compensate for the really badly behaved games)... not 312 as PAL requires. So near as I can tell, it's just a color palette swap there as well. Load up Adventure (Pal) on the original 1.1 version and you'll see it's running at 60FPS and worse, it doesn't handle the larger Vertical Blank area so the whole screen is shifted down a fair number of pixels. I tried to simply change the frame rate (60FPS -> 50FPS) and extend the overscan area (so we can handle 312 scanlines) but it's tricky as PAL for the Atari 2600 has a standard 228 visible pixels displayed vs the standard of 192 pixels for NTSC. 192 is perfect for the DS/DSi which has 192 vertical pixels on display ... though unfortunately a number of games utilize the overscan/underscan so some compression artifacts happen.

In short: this might take some time and I'm not at all convinced how it will look given the extra display lines on a PAL system.

 

[wavemotion]

Version 2.5: https://github.com/wavemotion-dave/StellaDS

I've restored the PAL Palette functionality - though it's moved to when you select a game. See bottom of the menu for instructions - basically instead of pressing A to pick the game, press Y and it will load in the PAL color palette.

Note, however, that this simply restores the original "PAL" functionally which doesn't yet run the games at the proper 50FPS but does replicate the behavior of version 1.1 thru 2.3. I will continue to do my best to get a proper PAL working system - but @Indy13 at least you've got the older functionality you are used to

In the discovery process, I also found a way to eek out 1 more Frame-per-Second on the Starpath Supercharger games (Phaser Patrol is now at 56FPS and Official Frogger about the same) and Elevators Amiss (the most stubborn of games) is bordering on 54FPS! This was accomplished because every game utilizes a different "end scanline" for the game. Atari's recommendation was to stick to 192 visible scanlines but most games stretch that a bit to get more "stuff" on screen (the pack-in game of Combat was notorious for stealing more than a dozen overscan lines to render the playfield... and if the Atari flagship pack-in game could do it, well, almost everyone else did too!). To cover this overscan potential, StellaDS was accommodating a fixed 210 scanlines (18 "overscan" lines) but very few games take advantage of that many... so I added a table-lookup for the hard-to-render games that utilize less scanlines - essentially, for those games, I can "stop drawing" when we reach the cut-off...)

 

[MarioKartFan]

This is just fascinating. My favorite thread lately!

 

[Indy13]

A huge thank you @wavemotion

You rock my friend !

I love the idea that you put this option in a discreet way in the list of games, it's really great !

The fact that you can change options simply by pressing the A or Y button is just brilliant !

I love this version again a thousand thanks !

 

[wavemotion]

Version 2.6: https://github.com/wavemotion-dave/StellaDS

Spit-and-polish release for all the most recent changes...

I fixed the long-standing issue where you couldn't scale or shift the screen for Paddle games (Kaboom, Breakout, etc).
I went through my collection of 800 games and make small tweaks as needed to get them centered on screen as best I could... about 100 of the games needed tiny adjustments here.
Small memory optimization - mostly to use less stack memory which I'm running low on

 

[CrashMidnick]

This is awesome ! Thanks !

 

[wavemotion]

Version 2.7: https://github.com/wavemotion-dave/StellaDS

I'm so close... I spent the weekend learning all about compiler optimizations. Part of my frustration is that when I make a small tweak to the code, I can sometimes gain or lose up to 10% speed. I've come to find out this is caused by compiler optimization "hot spots" where the compiler guesses incorrectly about padding loops or jumps to an alignment that doesn't play well with the complexity of all the function calls and data fetches in the system. I tried about a hundred different optimizations and alignment switches (including turning off alignment) and came to the conclusion that I'm not smarter than the GCC compiler (no kidding!) but that the compiler doesn't always do the best thing for speed... so I now have a bit of "snake oil" - code that does nothing that I can manipulate to shift the code by a byte up or down to see what gets me the optimal speed. It's difficult because of the many different cartridge types and specialized code for each - so sometimes optimizing for one cart type will cause slight performance issues for another. Frustrating! But I think I'm close to getting a good balance... and I've even managed to get Elevator's Amiss (which used to run at an abysmal 30FPS) up to 59FPS with the occasional gust up to 60

 

[djleviticus]

Version 2.7: https://github.com/wavemotion-dave/StellaDS

I'm so close... I spent the weekend learning all about compiler optimizations. Part of my frustration is that when I make a small tweak to the code, I can sometimes gain or lose up to 10% speed. I've come to find out this is caused by compiler optimization "hot spots" where the compiler guesses incorrectly about padding loops or jumps to an alignment that doesn't play well with the complexity of all the function calls and data fetches in the system. I tried about a hundred different optimizations and alignment switches (including turning off alignment) and came to the conclusion that I'm not smarter than the GCC compiler (no kidding!) but that the compiler doesn't always do the best thing for speed... so I now have a bit of "snake oil" - code that does nothing that I can manipulate to shift the code by a byte up or down to see what gets me the optimal speed. It's difficult because of the many different cartridge types and specialized code for each - so sometimes optimizing for one cart type will cause slight performance issues for another. Frustrating! But I think I'm close to getting a good balance... and I've even managed to get Elevator's Amiss (which used to run at an abysmal 30FPS) up to 59FPS with the occasional gust up to 60

View attachment 266046

thanks for the update

 

[wavemotion]

Yes! So much time to squeeze out that last 1 FPS

I continually go back and play the Activision Anthology on my GBA SP and marvel at how close they got the speed and framerate on that 16MHz console. I have 4x the speed (8x for DSi) and can barely do as well. It goes to show you that optimizing in assembly and really understanding the internals of the hardware being emulated is key. It's why guys like @FluBBa stand apart in what they can accomplish on this handheld.

 

[wavemotion]

Version 2.8: https://github.com/wavemotion-dave/StellaDS

About two dozen micro-optimizations especially in the sound driver to squeeze out every bit of performance. Elevators Amiss is now running at 60FPS. The most incredible Starpath Supercharger games are now all running at or near 60FPS with the exception of The Official Frogger which runs at 58 with gusts up to 59. I think Midnight Magic might be the slowest game now... running at about 57.

About 800 games (virtually the entire library) I tested run at full-speed 60FPS on the DSi

Enjoy! I think I'm done with optimizing this thing... time for some new features. Maybe a per-game high-score list or built in manuals or something fun!

 

[djleviticus]

wow, once again thankyou

 

[FluBBa]

If I did a 6502 in asm that would work as a drop in replacement for the C one would you use that? (if it's any faster that is)

 

[wavemotion]

If I did a 6502 in asm that would work as a drop in replacement for the C one would you use that? (if it's any faster that is)

Yeah, of course! But see warning below...

I did my best to clean up the 6502 core by putting the CPU registers in fast memory.
However, I've complicated things

Because of the StarPath Supercharger (which is a special add-on module of which only 12 games were made for it but they are all above average including several that are in the top 25 of the entire library), I basically "include" the 6502 instruction set twice... and redefine the peek() and poke() functions to the Starpath versions (which are more complicated... and I don't want that overhead for the non Starpath games). This bulks up my NDS executable by about 300K (it really does double the size of the CPU core!).

I'd love to streamline back down to one unified 6502 CPU core - and the peek() and poke() routines could determine if we are Starpath Supercharger or not... but because I'm running so very close to (but not quite) 60FPS on the Starpath stuff, I opted to waste a crapton of NDS memory to nearly-duplicate the CPU core to gain that extra frame or two.

If it now sounds like I've got a screw loose and you want to back out of your offer... that's totally understandable!


Otherwise:

 

[FluBBa]

Do you have (one of ?) the 6502 core(s) in ITCM? I'm not sure how to do that with C code, but that can probably speed up things quite a bit.

 

[wavemotion]

Do you have (one of ?) the 6502 core(s) in ITCM? I'm not sure how to do that with C code, but that can probably speed up things quite a bit.

Yes, both cores are in ITCM along with the peek/poke memory fetchers.

The only other big thing that would fit in the limited ITCM space was the TIA which handles the Player-Missile Graphics which does collisions and such.

Between the TIA and the 6502 Core(s), about 80% of the DS CPU is churning in there...

In the meantime... First peek at some new features (finally)!!

 

[Incure]

Just came across this post and what a development since I first used Stella DS! The hi-Score feature is really a great addition, as a kid I used paper and pencil to keep note of my hi-scores because the cartdridges couldn't save at that time.

Another nice to have is some boxart with the games.

 

[wavemotion]

Just came across this post and what a development since I first used Stella DS! The hi-Score feature is really a great addition, as a kid I used paper and pencil to keep note of my hi-scores because the cartdridges couldn't save at that time.

Same! I had a crappy little notebook to record the scores. That's basically what this is... a way to save up to 10 high-scores per game. You can enter 3 initials and 6 digits of score which covers 99.9% of all games. I may expand things in the future, but this will at least replicate the "jot scores down on scraps of paper" but in clean digital form

The other addition I'm working on is in-game manuals... so you can see the different variations and what the difficulty switches do, etc.

 

[wavemotion]

High score is done... I'm happy with it!

Instruction manual preliminary support is in... just a few games have manuals right now. For the upcoming 3.0 release, I hope to have the most common/popular 125 games with short manuals. But typing them up is time-consuming. Volunteers always welcome