DS994a - A Texas Instruments Emulator for the DS/DSi

  • Thread starter Thread starter wavemotion
  • Start date Start date
  • Views Views 15,731
  • Replies Replies 83
  • Likes Likes 35
https://github.com/wavemotion-dave/DS994a

Version 1.8 is released. I spent the last 4 days working on the last of the glitches. DS-Lite/Phat users rejoice for speed has been found!

V1.8: 19-Feb-2024 by Wavemotion Dave
  • Improvements to the TMS9918a emulation to fix 5th sprite handling and improve collision detection. Megademo, Eric in Monsterland and Interceptor all work correctly now.
  • Fix for Robots of Death II and NUTS so they start properly (was hanging on Speech detection).
  • DSi now supports up to 8192K (8MB) banked ROMs (the older DS still supports 512K). The Dragon's Lair demo will run but won't process speech/sound as the emulation is not fast enough.
  • Optimized VDP rendering and CPU memory read/writes to be a bit faster to help with older DS-Lite/Phat. This gives a 5-50% speedup in video rendering depending on the game. The megademo will sustain 60fps throughout.
  • Improved memory density so that we end up with more cache-hits than misses when dealing with CPU memory - this gives a nice speedup of several percent across the board.
  • Lots of code comments and refactoring improvements as time permitted.
The VDP emulation got a ton of attention to fix both the 5th sprite detection and properly handle inter-frame collision detection. I also found one game that was just ... odd to say the least. Miner 2049er seems to have a problem with collision detection. After an archaeological dig on the forums here, it appears that a real VDP will update the 5th Sprite Number when a 5th sprite is not detected - I think it will represent the last sprite scanned and put on a line which is what I implemented and the Miner 2049er collision detection seems to work (probably by accident).

DS994a has come a long way - the last two releases have been about improving the accuracy of emulation without sacrificing emulation speed. The design philosophy remains the same: have the ability to play Hunt the Wumpus on the toilet. As such, I'm okay sacrificing a bit of accuracy to make the games playable at full frame rate ... fortunately I found some significant speedups in the VDP rendering. Turns out a lot of what gets written is the background color which I've now optimized for. I also realized that much of the VDP scanline rendering is to even boundaries and instead of writing a byte, I can write 16-bits or 32-bits at a time which gained a ton of speed.

Most actively developed emulators asymptotically approach 100% accuracy - but never quite reach it. I'd now put DS994a about 95% in terms of accuracy - all your favorites should play smoothly even on older hardware. Enjoy!
 
Did you make V1.8a for me? :D:lol:
Absolutely!

On a side note: I'm just about wrapped up creating 'Wavemotions Highly Curated TI-99 Game Database'. The problem with TI-99 is that we're stuck with crappy 8.3 filenames and badly named often overdumped cart images due to legacy pioneers back in the early 1990s. As such, I've been slowly cleaning up the database of proper and correct cart dumps - with a huge bit of help from the MAME efforts which seek accuracy (but take it a bit too far for the TI99 breaking each component ROM chip down to individual files which gets messy). If any of you have spent any time on WHTECH (the premiere site that has hosted TI99 related material for three decades now), you know it's a bit of a mess organizationally - with duplicate files, alternate dumps and things strewn about haphazardly reminiscent of the clothing isle after a big sale at Target.

To that end, if anyone wants to test my highly curated pack of 50 game carts, please drop me a private message. I think these should be as close to the real cart images as possible - and all 50 should play flawlessly on the latest DS994a and be properly named to credit the company and copyright date.
 
https://github.com/wavemotion-dave/DS994a

V1.9: 24-Feb-2024 by Wavemotion Dave
  • Improvements to the TMS9900 CPU core to improve accuracy and slight optmization for another frame of performance.
  • Added new global configuration default for frame skip (DSi, by default will disable frame skip and the DS-Lite/Phat will enable light frameskip).
  • Improved Disk menu handling to show free space and used space plus some instructions on how the paste buffer works.
  • Fix for Zero-Zap so it picks the right control scheme.
  • Lots of cleanup and code comments added across the board.
A nice polished release... up soon is the big 2.0 with a newly designed splash screen which I'm rather excited about! I'm working on a scheme to get RPK files (the ones used in MAME for TI-99) working which should allow the games to be launched by TWL++ - we'll see...

1708791846519.png
 
https://github.com/wavemotion-dave/DS994a

V2.0: 01-Mar-2024 by wavemotion-dave
  • Support for .rpk (Rom PacKs - same as used by MAME/MESS).
  • Fix for save/load state of games that use RAM (MBX carts, MiniMem, etc)
  • Improved SAMS handling so that the proper amount of RAM is detected
  • On DSi and above, DSK3 is now fully buffered and writable.
  • Lots of small tweaks and cleanups across the board as time permitted.
  • Refactored and reduced resources so we free up an additional 256K of valuable memory for the future!
The .rpk format is unique to TI-99 and provides a way for MAME/MESS to group rom files into a single game pack. This format should also allow (should @RocketRobz and team decide) to add DS994a game launching directly from TWL++ (the extension is ".rpk").

If you are using my emulator, don't be shy about telling me. Knowing that our work is being used is often the only form of compensation some developers get!
 
That's a good resource.

Let me also be clear - I'm not depricating the use of the old-school mixed-mode C/D/G/8/9 files. But .rpk is the MAME (formally MESS) way of putting several ROMs relating to the same game into an archive along with an XML file that describes where they go. So it's not as messy - and allows things like TWL++ to focus on the .rpk for launching a game (vs the sprawling mess that is the C/D/G/8/9 format).

I plan to support both formats going forward for maximum flexibility.

I usually don't launch my games via TWL++ so I'm fine with the old-school mixed-mode filenames but the .rpk is likely the future (MAME has supported it for many years, JS99er supports it and it's on the to-do list for Classic99 for the future).
 
  • Like
Reactions: Tarmfot
wavemotion, you the man, not just for having a great user name from the only anime that isn't Pokemon worth watching, but I've been having a blast playing the games I used to play when I was a kid with my first home computer. We had TI-99/4A computers at school in the math room, and we were allowed to play games when we finished our work. I got started playing The Attack in class, and missed lunch because apparently I was really good at the game. First time playing, and I just took to that game. Played right up until the next class came in without dying.
 
Version 2.2 is released. We're rapidly approaching the 2 year anniversary of DS99/4a... it's been a "fun" journey! 🎉

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

V2.2: 15-Dec-2024 by wavemotion-dave
  • Fixed paste of disk filenames allowing more characters (not just A-Z, 0-9)
  • Added sound (speech) samples for Microsurgeon.
  • Added sound (speech) samples for Fathom.
  • Fixed River Rescue (improved VDP interrupt mask handling).
  • More games load with better key maps (e.g. Defender now auto-maps X and Y as Hyperspace and Smart Bomb).
  • Reverted to allowing both '3' and '9' as the file type modifiers for "inverted cart type". There are examples of both in the wild.
  • Main menu cleanup and refactor.

Much of this version is about improving the user experience. Most users don't want to tinker with filename endings or will remember that Frogger uses joystick port 2... so this version will handle most of that under the hood. My goal for the next release or two is that a user of DS99/4a will simply pick any game they want to play and it should load and play with no additional fuss and virtually no additional configuration. If they want to tinker - that's cool too... but I'm finding most people just want to be taunted by the Alpiner voice lady and remember a time when they were kids without the responsibilities of being an adult.
 
V2.3: 19-Dec-2024 by wavemotion-dave

  • Refactored memory allocation to buy back almost 400K of much needed DS RAM (mostly for new speech samples)
  • Added speech samples for: MASH, Sewermania, Buck Rogers and Borzork and added missing samples for Fathom and Microsurgeon.
  • Re-sampled Superfly for improved speech.
  • Minor tweaks and improvements under the hood to get ready for 2025!

Major update with tons of new speech samples for all the popular games.

To that end, I've also "released" a highly curated set of games for the TI-99/4a that brings all of the 'feels' from 1982-1983 with this classic machine and should give you an idea of what it was like growing up with this computer. Absolutely no links, but the go-to for everything TI99 is over on WHTech and some DS994a stuff is under the emulators section.
 
Last edited by wavemotion,
V2.4: 24-Dec-2024 by wavemotion-dave
  • New Alpha keyboard specifically designed to improve the experience of playing text adventures like the Scott Adam's Adventure series.
  • Fixed sound output in Red Baron (engine idle now sounds correct - not the high pitched squeal of previous versions).
  • New Wave Direct sound driver for games like Dragon's Lair Demo and Ghostbusters to render SN-chip "speech" properly (okay... properly is a strong word - but it's passable)
  • Improved pagecru handling to mask the banking within the binary size (e.g. 4 banks for 32K carts) and disallow normal ROM banking (I'm looking at you... Red Baron)
  • Improved disk emulation to properly report motor enabled/strobed CRU bit. Not even sure anyone looks at this - but maybe.
  • A filename that ends in _cru just before the .bin extension will be considered a Paged CRU cart type (a handful of the original Databiotics carts used this scheme).
  • The 32K RAM expansion now initializes memory as >FF00 to more closely mimic how the typical RAM chips in use would power up cold (accuracy improvement borrowed from MAME)
  • Save/Restore State improvement to save a few more bits of information to ensure things come back up properly (old save states will not work - sorry!)
  • Other minor cleanup and improvements under the hood. Comments added to help future emulation developers.

I'm asymptotically approaching 'done' here. I've got through the last batch of programs that wouldn't run correctly and my next step would be to just start plowing through the lesser known stuff to see if things are running as expected. Not sure it's worth that effort as my goal isn't perfection - the main point of DS99/4a is to play Tunnels of Doom on the toilet.

The new simplified keyboard is nice to switch in for text adventure games. Been enjoying that with a replay of Scott Adam's GHOST TOWN.

I've extended the mixed-mode file name detection... so in addition to the usual C/D/G/8/9/3, we also have 0 (to replace the console GROMs ... i.e. Son of Board) and now _cru which enables CRU banking for the few Databiotics games to need them. You can set/override any of this in configuration on a per cart/game/rom basis.

I've made some things more generic for future expansion here... it would be pretty easy to add things like the p-Code card but honestly, nobody is going to use it. Well... maybe that one weird guy. I see you - lurking in the corner. Yeah, maybe... one day... but it's really not practical to use a handheld for any kind of p-System work. I've no real interest in getting Horizon RAMDisk or HDD support - the triple-360K floppy support is enough to run Realms of Antiquity (and, of course, Adventure and Tunnels of Doom) and that's really all I care about.

So it's probably bug fixes from this point out - and hopefully not many of those left!!

Enjoy - and Merry Christmas friends!
 
Happy (if a bit early) New Year!

V2.5: 29-Dec-2024 by wavemotion-dave
  • Optimization pass to improve the emulation speed by a couple frames per second. Useful if you are running on the older DS hardware.
  • Properly mask off the low bit on WP writes to avoid problems in programs like SYSSCAN (which sets an odd-address for the WP).
  • Properly mask off the low bit on PC writes to more closely mimic real hardware.
  • More TMS9901 timer accuracy improvements to more closely mimic the timing on real hardware.
  • Improved speech module emulation so that XB CALL SAY commands no longer freeze the emulator.
  • Fixed switching into a directory whose name is longer than 26 chars (should now support the full 128 char limit).
  • Full pass commenting to improve code readability for future generations.
  • General cleanups and a bit of spit-and-polish across the board.
 
V2.6: 05-Jan-2025 by wavemotion-dave
  • Added p-code card emulation. Requires 12K p-code DSR and 48K (64K space) internal GROM. See Atariage for details.
  • Automatically enable the 8K/32K 'SUPERSPACE RAM' for various flavors of the Editor-Assembler GROM.
  • Added ability to 'soft reset' the machine - reloading the cart/grom but leaving the .DSK files in place.
  • Freed up some stack space to prevent potential lock-ups on disk writes.
  • Minor comment/cleanup pass on the SAMS code to better clarify what it's doing.
 
I have just released a hot-fix version for DS99/4a at: https://github.com/wavemotion-dave/DS994a

V2.7: 08-Jan-2025 by wavemotion-dave
  • Rewrote the disk write handling to only write dirty sectors and avoid writing the whole disk. This greatly improves the reliability of writing on the DSi with SD card (and speeds them up).
  • Minor cleanup of messaging to improve the UI experience - better error checking on file reads/writes.
  • Streamline of save states to take less room (and faster/more reliable writes to SD).
Ever since the first versions of DS994a, I've been battling a rare disk write issue. I thought it was stack related... but after a lot of investigation over the past week, I've come to understand there is a potential lockup (bug?) in the libnds (the open-source library I use for development on the DS/DSi) and the FIFO handling. Part of what takes place in the system is a carefully choreographed synch between the two DS processors (ARM7 ... doing very little except handling I/O and sound, and the ARM9 which is the more powerful processor that focuses on the gameplay/emulation/video output). This dance is sophisticated enough that the system employs a series of FIFOs to keep the two processors in sync. There appears to be a very rare FIFO lock-up condition that can take place on the DSi when using the SD card slot when writing files (though not when reading which is very reliable). How would this manifest? Well... for me it was hitting about 1 in 100 saves in Realms of Antiquity. For the better part of the last year, I've put in safeguards around the lockup so that at least the .dsk file was not corrupted - at worst it would lock up and not make the save and you could just restart and load back the last save point.

But that's not ideal... and not nearly robust enough to make me sleep at night.

By the way, this FIFO lockup does not manifest when using an R4 card or similar ... only when running directly from SD card on the DSi/XL/LL or above. That's not to say that the R4 card is better... only that it's more reliable in this situation. R4 cards have drawbacks - the most notable of which is that it generally runs in 'compatibility mode' at 67MHz speed and with less memory available than the DSi running homebrew software from the SD card.

Prior to this V2.7 release, I always re-wrote the whole .DSK file even if just one or two sectors changed. It was easier for me to just blast the whole thing back to SD. But writing 360K (or 180k or 90K) when only a few sectors have changed is not useful - especially knowing that the more data I write, the more likely we are to hit this FIFO lockup.

So in V2.7 I've switched to tracking dirty sectors and only write the changed sectors back to disk. I do this in a careful way so as not to corrupt the disk on a failure by buffering enough for virtually any game's worth of writing. I found that in Realms of Antiquity, for example, a typical save only updates 3 or 4 sectors (about 1K of data) and rather than blast out the 360K disk, it's faster to write the 1K worth of sectors which significantly reduces the window for potential FIFO lockup. I've gone from failing 1 in 100 writes in RoA to about 1 in more than 5000. Still not perfect - but what is in life?! Especially when it comes to free software.

Remember, there is a 'Backup Disk' menu choice for you to occasionally make a copy of your disks within the emulator... and with this now massively reduced chance of lock-up - hopefully the system will be robust enough for general game playing.

I've also reduced the Save State files by about half... for your typical non-RAM-expanded save states, these are less than 32K in size (one flash cluster on the SD). Though I wasn't having any significant problem with save states writing, this should improve speed and reliability in that department as well. Unfortunately, old save states won't work with V2.7. You must break a few eggs to make an omelet. Or something like that.

I continue to appreciate everyone that has provided kind feedback and support for DS99/4a... Upwards and Onwards!
 
Last edited by wavemotion,
Thanks Dave.
One question. Does this apply to all files written? Like hiscores, configuration etc.
Btw, perhaps, other approach could be writing some wrapping about fwrite called fvwrite or whatever, which writes the data and reads it back, does a comparison, and tries again in case of mismatch, a few times maximum to avoid sd wearing. assuming there isn't any cache in place.
 

Site & Scene News

Popular threads in this forum