Any info on StellaDS?

[+wavemotion]

I'm toying with adding QuadTari (well... DuoTari to use @johnnywc's unofficial coined term) to StellaDS if only to support RobotWar twin sticks and SaveKey.  Right now I support twin sticks which works really well on the DS (d-pad for left joystick, XYAB for right joystick) but the Save Key would be non-functional. 

 

Are there any other single player experiences that would benefit from this DuoTari in the left port and SaveKey in the right?

[+johnnywc]

9 minutes ago, llabnip said:

I'm toying with adding QuadTari (well... DuoTari to use @johnnywc's unofficial coined term) to StellaDS if only to support RobotWar twin sticks and SaveKey.  Right now I support twin sticks which works really well on the DS (d-pad for left joystick, XYAB for right joystick) but the Save Key would be non-functional. 

That would be cool! 🕹️ 🕹️

9 minutes ago, llabnip said:

Are there any other single player experiences that would benefit from this DuoTari in the left port and SaveKey in the right?

All other uses for the QT in Champ Games is for multi-players with SaveKey, although I am considering adding in driving controller support to Turbo Arcade and it would support having a joystick in the other QT port for shifting and menu navigation.

[+fdr4prez]

15 minutes ago, johnnywc said:

although I am considering adding in driving controller support to Turbo Arcade and it would support having a joystick in the other QT port for shifting and menu navigation.

that sounds neat

[+johnnywc]

Just now, fdr4prez said:

that sounds neat

Thanks!  You will also be able to use joystick port 2 for shifting (just without Savekey support) or you can play with AUTOMATIC where shifting is not required (and use SELECT and the DC to navigate the menus).  

[+wavemotion]

Wasn't too hard!  Admittedly, it's only a DuoTari and only supporting Joysticks at the moment... but enough for RobotWar.

 

 

RobotWar does, indeed, detect as QuadTari with SaveKey.

[+wavemotion]

I have released version 6.3 of StellaDS with some newfound speed.

 

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

 

I optimized the main 6502 loop which brought with it a solid 1-3 frames of performance depending on the game.

 

At this point, all DPC+ games run full speed on the 134MHz DSi or above. This includes Space Rocks TE and Scramble - both of which will not drop below 60 even when things get really hectic on-screen.

 

Normal Space Rocks has gusts into the lower 80 fps and is now fast enough that I can enable Half-Flicker-Free mode which blends alternate frames to make the game really pop with zero flicker. 

 

The older DS-Lite/Phat running at 67MHz gains this performance as well and some games that were marginal are now full-speed. Medieval Mayhem, Stampeed, Adventures of Tron and a bunch more were previously running in mid-to-upper 50s on the oldest DS handhelds and now will pretty much sustain a full 60 fps.  A huge portion of the non-ARM library will run fine on the older DS units.

 

CDF/CDFJ/CDFJ+ games all got a nice boost and the only real holdouts that won't sustain 60 fps are Draconian (though there are now some gusts to 60+ when there isn't too much going on) and Turbo Arcade (generally lower 50s). 

 

[+SpiceWare]

Nicely done!  Haven't messed with the frame blending modes, but just tried FF Half Mode for Space Rocks and that's quite nice!

 

I think Alpha 3 in Draconian hits the hardware the hardest, during development I would fly straight up thru the middle of the stations to check for screen rolls on the Harmony.

 

 

[+wavemotion]

Yeah, the frame blending modes really help on the original DS and DSi. The XL and 2DS/3DS screen tends to hang on to the pixels a little bit longer and so there is less flicker on those games that are prone to having some flicker. 

 

The FF Half Mode is somewhat new - the original blending was to blend each two frames together (so 1+2, 2+3, 3+4, etc) but the Half Mode blends each even frame with each odd frame (1+2, 3+4, 5+6, etc). The original blending mode soaked up almost 20% of the CPU time but the Half Mode soaks up only 10%. In practice the output produced looks virtually identical and so I can't find much reason to use the old FF blending mode. Starting with the next release, I'm going to fold both blending modes together and just do the even/odd frame blend and call that 'Flicker Free Mode'. 

 

Obviously FF mode is only useful if the game can run unthrottled 10% faster than full frame rate. Space Rocks just got there. 

 

And not all games look best blended... if a game is drawing every frame and moving things rapidly then the blend can cause fine details to start to blur out.  WoW Arcade can now handle a frame blending (it's running just about 10% faster than full speed unthrottled) but the detail on the aliens running through the maze starts to blur up a bit.

 

Other games absolutely need a blending mode enabled. Yars Revenge will flicker the shield like crazy otherwise. The internal database of about 2000 games will generally decide which games need/want the blending and apply it by default - but as always, the user can override this on a per-game-basis in config.

 

Edit: tried some of the other levels in Draconian... holy hell some of those really push things!  I think my poor DSi is going to catch fire

 

Edited December 11, 2022 by llabnip

[+wavemotion]

I've been cleaning up memory management as I'm nearing some boundaries in the older DS hardware. 

 

For those that don't know... in general:

 

Original DS/DS-Lite/DS-Phat there is a 67MHz ARM9 processor and 4MB of RAM.

The DSi/XL/LL bumps that to a 134MHz ARM9 processor and 16MB of RAM.

The 2DS/3DS mimics the ARM9 of the DSi but also has an ARM11 dual-core at 268MHz and 128MB of RAM.

The 'New' 2DSXL/3DSXL and similar mimics the ARM9 of the DSi but bumps the ARM11 up to quad-core 804MHz and 256MB of RAM.

 

I'm targeting the original DS and DSi/XL/LL ARM9 processor.  As such I need to try and constrain to 4MB of RAM for it to continue to run on the oldest hardware. I'm committed to that for various reasons that aren't worth expoloring here.

 

All that to say that I'm starting to run up against memory limitations. I've got about 400K free RAM and virtually zero "fast ram" remaining (I use this for the ARM Thumbulator as well as an 8K cache for smaller carts that can be emulated almost entirely using fast memory). 

 

Right now, my imposed limitations on bank switching is as follows:  Pretty much anything up to 512K of ROM and 32K of RAM.  The only exception is CDFJ+ games which I can only support 256K of ROM and 32K of RAM (as I need to steal some of the larger cart memory for the decode array).

 

I assume that's probably good enough for most anything that exists today and is likely to not be a huge problem in the future?  I know there is the 3EX scheme which allows for 512K of ROM and 256K of RAM but I haven't seen any actual use of that. Given that some of the flash cart technologies (e.g. Harmony Encore) are in that same 512K/32K realm, I'm guessing I'll be okay with StellaDS.

 

Thoughts from anyone - does anyone know of any monster 512K+ or 32K+ efforts on the horizon?

 

[+wavemotion]

Finally.  It's been an uphill battle. 

 

Turbo, however, is only at 48 (with gusts to 55). 

Draconian both got a nice little boost in speed with some music fetcher optmization.

BOOM is running about 58.

 

All other ARM-Assisted games (released ROMs I happen to have) to will run at full speed.  

Qyx (demo) and WoW Arcade join the list of games that can now enable the Flicker Free mode of frame blending (requires the game run unthrottled at 65 fps to handle the extra 10% CPU needed for blending).  Galagon is close to that threshold as well.

As you can see, I've had to go to a running frame average with tenths of a frame to see if micro-optimizations are having any effect.

[+wavemotion]

Version 6.5 of StellaDS has been released. I'm burnt out trying to optimize so this is likely the last release for a while. I got Turbo Arcade to 49 with gusts to 58 depending on the scenery/section of the game. But I think Turbo is at the end of the optimization road and I've run out of gas.

 

That effort did provide another solid frame of performance but it's come at the cost of many dozens of hours of experimentation and hand-tweaking. For now: the emulation on the little DS handheld is as fast as science allows.

 

 

Time to give some effort/love to my other emulators on the DS!

 

 

[ClassicGMR]

You rock. I thank you so much for this it’s been awesome seeing it come along so well. 😊

[+wavemotion]

And I thought Turbo Arcade was going to be death of me  

 

Poor little DSi... almost melted. 

[+johnnywc]

6 hours ago, llabnip said:

And I thought Turbo Arcade was going to be death of me  

 

Poor little DSi... almost melted. 

Yeah, I didn't think EA was going to perform well as it does a ton of writes and decompression during the title screen.  It will perform better once I expand to 64K and don't need to compress the title screen graphics.  

 

How is the TPS during the actual game?

[+wavemotion]

1 minute ago, johnnywc said:

How is the TPS during the actual game?

About the same. Turbo Arcade is quite playable by comparison. I’ll hold out hope that the 64k version performs better. At this point the DS is out of juice unless I want to explore a sort of direct Thumb mode while patching memory access (since the DS memory map doesn’t align perfectly with the Harmony and related ARM boards). 

[+johnnywc]

2 hours ago, llabnip said:

About the same. Turbo Arcade is quite playable by comparison. I’ll hold out hope that the 64k version performs better. At this point the DS is out of juice unless I want to explore a sort of direct Thumb mode while patching memory access (since the DS memory map doesn’t align perfectly with the Harmony and related ARM boards). 

I'm sure we'll be able to increase the performance once I focus on optimizing on my side.  I was running out of time for the ZPH reveal and ran out of ROM too so I quickly put together a compression scheme for the title page and some of the in-game elevator graphics so I could free up more ROM so I'm sure it's quite inefficient speed-wise.  Once I expand to 64K I'll send you the version so we can work on getting the FPS up to a suitable rate.  

[+wavemotion]

A six-month necrobump!

 

I burnt out on this in January. I think if I saw another ARM-Thumb16 op-code, my head was going to explode.

 

I didn't even play StellaDS until about 2 weeks ago when I finally went back to it.

 

It's fun. I had forgotten that it's come a long way and really does a good job with 98% of the games.  A few really nice games have been released/updated since January - enjoying running through them!  I don't know what I'll work on next for this emulator ... but it's nice to just enjoy it again.

[+wavemotion]

Okay... over the last few days, I'm slowly meandering my way through the full ROMHUNTER v18 pack to see where I need to fix some things...

 

In my blood-lust of optimization, I went a little over-zealous on a few things that broke a few odd games. 

 

I'm not ready for a new build, but I did just check in a daily 6.5b:

• Fix for Meltdown prototype so it doesn't crash (was triggering a bank-swap on write to 0x2A0).
• Fix for Pleiades to fix graphical glitches (relies on data bus being driven on TIA reads - I'm sure other games were impacted by this fix).
• Fix for Atom Smasher prototype so it doesn't crash on start (wrong bank scheme detected).
• Added new option to use the 'Compatible' BUS driver which will drive the last bits on the data bus in TIA reads (a few games rely on this - but it does slow down emulation slightly).

I'm a little perplexed about the Meltdown issue. About 2 or 3 minutes into gameplay, there was a read to 0x2A0 which is one of the UA alternate addresses to handle some Brazilian UA carts. That triggered an inadvertant bank-swap and crashed Meltdown. 

 

I checked mainline Stella and they have the same extended UA hotspots I'm using... with the same address mask. So I figured if I played Meltdown for more than 5 minutes, it would crash... but it doesn't crash on Stella 6.6.  So obviously I'm doing something that isn't quite right but for now, I've simply put Meltdown into 'strict UA' mode where it only responds to the original 0x220/0x240 read address for a bank swap.  Thomas got my head on straight here... Meltdown was detecting as UA but it's just a normal 4K game.

 

I'll probably put out another full release once I'm through the rather large ROMHUNTER pack.

[Thomas Jentzsch]

23 minutes ago, llabnip said:

I checked mainline Stella and they have the same extended UA hotspots I'm using... with the same address mask. So I figured if I played Meltdown for more than 5 minutes, it would crash... but it doesn't crash on Stella 6.6.  So obviously I'm doing something that isn't quite right but for now, I've simply put Meltdown into 'strict UA' mode where it only responds to the original 0x220/0x240 read address for a bank swap.

Meltdown is not an UA game. And it is 4K, so it doesn't need any bankswitching anyway.

[+wavemotion]

9 minutes ago, Thomas Jentzsch said:

Meltdown is not an UA game. And it is 4K, so it doesn't need any bankswitching anyway.

Ah--haha! Yeah, doh.  My database listed it as a UA game for some silly reason and I never questioned it. Fixed and checked in 6.5c.  Thanks Thomas! 

[+wavemotion]

 

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

 

V6.6 : 20-Jun-2023 by Dave Bernazzani (wavemotion)

• Fix for Meltdown prototype so it doesn't crash.
• Fix for Pleiades to fix graphical glitches.
• Fix for Atom Smasher prototype so it doesn't crash on start (wrong bank scheme detected).
• Fix for E7 banking so it handles 8K, 12K and 16K roms.
• Fix for Flash Gordon to eliminate graphical glitches.
• Fix for Elf Adventure prototype so it runs.
• Fix for Star Gunner so it doesn't glitch.
• Fix for Warlords graphical glitches.
• Fix for Worm War I graphical glitches.
• Fix for A-Star not starting.
• Fix for Hugo Hunt graphical glitches.
• Improved random() generator for more robust RAM clear / handling on startup and added config to either randomize RAM or clear it at start.
• Added new option to use the 'Compatible' BUS driver which will handles things like invalid reads and drives unused TIA bits (a few games rely on this - but it does slow down emulation slightly).

 

No extra speed. No ARM improvements. I'm on a compatibility kick to see if I can get as many games running right as possible on the little DS handheld. 

 

What I found was that my speedups were problematic for games that are "less well behaved" - I always knew about games like Strategy-X which did illegal writes but there were some other games that had similar problems. My main addition with this build is a compatible BUS driver which is more accurate - it handles things like invalid reads and drives the TIA bits to the last known bus state. Many games are now running with this driver as a default since they were glitchy on the optimized driver. I've also allowed the user to select which driver they want to use on a per-game basis.

 

I ran through more than 600 of the latest ROMHUNTER pack plus another 300 Homebrews. They all seem to be playing without problems. Especially enjoying Bot&Tom2, @Thomas Jentzsch which works great with the optimized driver because you probably tested it with Stella developer settings and ensured no bad writes  

 

 

The one game I couldn't get to run is Edtris even with maximum compatibility turned on. I've read that the game does require proper handling of 'illegal' reads/writes but even using the amazing Stella debugger, I couldn't quite figure out where I might need to strengthen my code for that to work... someday...

[Thomas Jentzsch]

1 hour ago, llabnip said:

I ran through more than 600 of the latest ROMHUNTER pack plus another 300 Homebrews. They all seem to be playing without problems. Especially enjoying Bot&Tom2, @Thomas Jentzsch which works great with the optimized driver because you probably tested it with Stella developer settings and ensured no bad writes  

 

Happy to hear that you like Bot&Tom (no "2"). And of course I used developer settings during development. That's what I have added them for.  

 

BTW: Edtris doesn't run in Stella too when developer settings are enabled. It seems to have the typical missing "#" bug(s), because it works when I disable "Drive unused TIA pin...".

Edited June 20, 2023 by Thomas Jentzsch

[+wavemotion]

6 hours ago, Thomas Jentzsch said:

BTW: Edtris doesn't run in Stella too when developer settings are enabled. It seems to have the typical missing "#" bug(s), because it works when I disable "Drive unused TIA pin...".

Thanks for the clue... I couldn't get it to run in Stella with any settings. Turns out I had a bad ROM... re-downloaded from AtariAge and it worked great! (with my non-optimized driver).

 

[+wavemotion]

I'm tentatively starting development on save/restore states. I don't know how valuable they will be for the 2600 which generally offers short and impactful gameplay. Obviously they can be used by authors to debug a game - but that's not the core of StellaDS users. They can be used to game players to 'cheat' for high-scores which is not something I want to promote. Certainly I could use them to hone in on gameplay situations where I'm trying to improve emulation accuracy. Just need to convince myself the juice is worth the squeeze here.

 

[+wavemotion]

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

V6.8 : 01-Jul-2023 by Dave Bernazzani (wavemotion)

• Improved RSYNC so Extra Terrestrials (1984 by Skill Screen Games) works.
• Improved keypad handling so Magicard and similar keypad/keyboard game work.
• Added a few of the ultra-rare games discovered in the last decade to the internal database.
• Updated internal database to ROMHUNTER v18 for the classic-era games.
• Starpath Supercharger (AR) carts now clear RAM by default (prevent lock-ups).
• Added Dual Keypad/Keyboards for the few game that need them (BASIC, Magicard mostly).
• Fix for Sword of Surtr so it runs correctly.
• Hold L+R shoulder buttons for ~1 second to take a snapshot of the screen (written to SD card)
• DSi now defaults to the 'Accurate' BUS MODE for maximum compatibility.
• Improved data bus handling for undriven pins in Tia::Peek() for improved compatibility.
• A few more tweaks to a few more games to make them as accurate as possible.

This is probably a wrap for a while on StellaDS. I've got some other projects that need attention and I think this version will play 98% of all Atari 2600 games.