wavemotion

I think most DS users are right-handed (including me) - if only because most people are right-handed I think you prefer the directional on your dominant hand - there were some players back in the early days of the arcade that would cross their hands so their right hand would control the joystick. Most arcade control panels were designed with the joystick to the left and buttons to the right (see Galaxian, 1979, below for a fairly typical layout) and a few games were kind enough to give buttons on either side of the joystick for player preference. Nintendo and Sega who owned the markets from 1985 onwards settled on the d-pad to the right and buttons to the left which is how the DS is laid out. Directions to the right is not for everybody, though it's been the trend for 40 years after the first generation of consoles. I think we all have a natural preference for which hands controls the directions. Interestingly enough, with a Colecovision, I do cradle the controller in my left hand and use my right for directions (mostly because that was the picture in the manual) - though I have become accustomed to using the NES, SNES and Genesis gamepads over the years. I guess I'm a switch-hitter :D

Oh wow! I live on the border of Mansfield and could have probably walked to the last one As the developer of ColecoDS and the resident emulator guy... I feel like I'd be the odd-man out here (carrying around my Coleco and ADAM in my pocket with a few thousand games) - but maybe I'll pop in if only to remind myself what real hardware looks like

Thanks @johnnywc - totally make sense! I've uploaded StellaDS version 7.2a (https://github.com/wavemotion-dave/StellaDS) with tweaks to improve the Tutankham Arcade experience. It will set the proper screen position and size, select the Genesis controller (with SaveKey in the right port) by default and swap in the optimized CDFJ+ driver (which can only be used for games that have no more than two banks of 6502 code - such that it can be placed in the DS 'fast memory' core). While the game will run fine on the stock StellaDS 7.2, the new version will optimize the experience for players without having to customize the settings.

Okay... so StellaDS screenshot handling doesn't work well as some of the spites must be on alternate frames so you don't see the Treasure here but it's just to the right of the little green circle-explosion (I got hit as I took the screenshot). There was no vertical wall there that I could see - and I tried to move right into the treasure but couldn't so I assumed it was because I was holding a key. I did not try to approach it from the top as it sure looked like there was nothing standing in my way here.

Super fun with the Genesis controller - of course I played for an hour without reading the instructions so didn't even know Flash Bomb was a thing! I was surprised I couldn't drop an item - even if it zapped back to its starting location. Wanted to drop a key to pick up a treasure. Checked the arcade version and turns out that's accurate. Well... maybe something if you're looking for a 'Champ Games' exclusive extra I think I'm going to have to add a Joy2B+ option to StellaDS!

No... it means that when I coded the mirrors for the colecovision emulation I got it wrong. For emulation purposes, I write to all mirror locations so that the readback (which is generally more frequent) is fast - and I goofed one of the mirrors. So Boulderdash occasionally writes and reads from the 0x6C00 block - which would work fine on an ADAM provided whatever it wanted there was likewise written to 0x6C00. But in my emulation, I had this bug: So when the game wrote to memory, I wrote it to all mirror locations EXCEPT 0x6C00 (I wrote 0x6800 twice). This was the only game that I had trouble with for years until I discovered my mistake with mirror handling. With my bug, the game would run but would occasionally (but not always) hang later in the first stage. Interestingly enough, other games that utilize RAM mirrors worked fine - probably because they were not specifically affected by the one broken mirror (7 years of bad luck). Dave

As an aside... the view from your shoulders is quite nice.

https://github.com/wavemotion-dave/ColecoDS V9.7: 16-Apr-2024 by wavemotion-dave Fixed Colecovision RAM mirrors such that Boulderdash runs properly. The Heist now forces RAM to clear (all zeros) as it is known to be picky about contents of RAM on power up. Fix EEPROM sequential reads so Activision PCB games like Jewel Panic work correctly. Added the Wildcard and Print buttons on the virtual ADAM keyboard. All ADAM virtual keys should now be present. Added new configuration options to select the Colecovision mode to run in - you can force ADAM emulation, force PCB types, and set EEPROM sizes, etc. New global option to auto-patch for 'Fast BIOS' to force the 15 second wait down to 3 seconds. Minor cleanup and optimizations to the Adam core. ColecoDS is asymptotically approaching 100% compatibility. No emulator quite reaches that state of perfection but for classic and homebrew Colecovision carts (with and without SGM), I'd put ColecoDS at the arbitrarily precise 98.3% level. I have no scientific proof for this number - it's just a wet finger in the air guess. Some users were operating with non-original BIOS to cut down on the 15 seconds of COLECOVISION banner time... and some of these BIOS files were a bit too drastic in their modifications and caused some compatibility problems. I strongly recommend you use the original Colecovision BIOS with a CRC32 of 3aa93ef3 - to that end, I've added a global option that will patch a single byte (in memory - leaving your original BIOS pristine) to drive the 15 seconds of banner display down to about 3 seconds. Slow enough that you get the nostalgic feels of the game "loading" but fast enough that you get on with your gameplay quickly. Lastly - someone asked me recently what am I going to do when I get to the release after 9.9... of course I'll simply go to 10.0 - because, as it turns out, there are lots of numbers in the universe.

So as the developer of ColecoDS, I decided to support all 'cousin' systems to the Colecovision in the one emulation package due to how similar it all is. The differences come down mainly to memory/IO maps, the amount of memory, the SN vs AY sound chips and possibly the use of a CTC chip for more sophisticated handling of timing/interrupts (vs the CV just tying VDP to the non-maskable interrupt... some developers curse this) ColecoDS currently supports these very similar systems: Colecovision with 1K of mirrored RAM and optional Super Game Module for an additional 32K of memory (similar to the lower-half of the ADAM memory map) and the AY sound chip for easier MSX ports. The upper 32K is used for carts and bigger carts can use various banking techniques to page in more ROM as needed (the venerable MegaCart being the most popular which allows for a 16K fixed bank and a 16K variable bank... the more sophisticated Super Game Cart allows for 8K banking that makes it a bit easier to port MSX1 games that use an 8K mapper). Coleco ADAM with 64K base memory (and no RAM mirrors) and up to 16MB of Expanded Memory (though I think above about 1 or possibly 2MB it kinda gets pointless). Things are generally memory mapped in 32K chunks (upper and lower memory). Can run in Colecovision mode with the standard CV bios (though the RAM is not mirrored and that will cause compatibility issues with a very small number of games). Super games in DDP (tape) could be up to 256K in size and standard disks were 160K (though most hobbyists would modify or upgrade to a 320K disk or larger) - with the clever AdamNet handling allowing for DMA transfers of data without a heavy load on the Z80 so new stages for games could load while you play. Sega SG-1000 and SC-3000 are hugely similar to the CV with just some changes to the IO and memory map. The SC-3000 adds more memory and a keyboard to provide some entry level computer support. Some 3rd party expanders map RAM in various places for bootleg MSX ports to the SG-1000. Many of the early homebrews for the CV came from the SG-1000 game pool. Sord M5 is likewise similar to our CV but adds a CTC (counter-timer-chip) used for cassette and sound timing. Most software was supplied on carts. Apploon and Up Up Balloon are both great original games that would be right at home on the Colecovision but most developers don't look to the Sord for inspiration (and maybe the CTC handling is not easy to untangle for the Colecovision which lacks it). MSX1 is more versatile than the CV with memory mapping in 16K chunks (vs 32K of the CV/ADAM) and even that can be further chunked into 8K segments by various MSX cart mappers. Of all the cousin systems, this one is the most widely supported by the hobby community with tons of new homebrews coming every year... many of the new CV games are ports of MSX classics. Uses the AY sound chip which is very similar to the venerable SN chip with wider dynamic range and uses simple waveform envelopes to produce some great effects - this AY chip is provided on the CV by the Super Game Module. Some of the best MSX1 games utilize an off-board sound processor known as the Konami SCC which is hard to replicate exactly (though Opcode comes close) on the CV even with the Super Game Module. Most games come on carts but there is also tons of cassette and disk based software for the MSX1. Standard disks are 720K. Spectravideo SVI is very close to MSX1 (vs the Colecovision) and was the basis for the MSX1 standard - but retains the 32K memory map of the CV. Cassette based loader (only a half-dozen or so carts are known to exist). Sadly most everything on the SVI was either a back-port from MSX or the games got released on MSX compatible systems so this system just doesn't have the exclusives to make it stand out. Casio PV-2000 is very similar to the Colecovision but uses memory mapped VDP access vs IO Mapping and also has interrupt driven keyboard handling. Hanimex Pencil II is mostly a gaming console with a chicklet keyboard tacked-on for various flavors of BASIC carts. Only a few carts are dumped though a few dozen others are known to exist. Tatung Einstein has a faster (4MHz) processor and ample use of CTC timer handling. Disk based system and uses the same SN chip as the Colecovision. This was the system of choice for many Z80 developers back in the mid-80s to write and test games as it was really well built and came with 64K standard memory and a reliable 3" disk drive (200K formatted) and had virtually the entire CPU bus accessible on the back (via something they called the "Tatung Pipe"). Memotech MTX also uses the CTC timer and is a cassette based system. Uses the same SN chip as the Colecovision. Creativision uses the same VDP and sound chip but is built around the 6502 CPU vs the Z80 in all the systems above. It's like the Atari and Colecovision had an illegitimate child that neither wants to claim on their taxes. It's got a unique set of controllers that remind me of the Intellivision and when you hook them up side-by-side, it makes for a makeshift A-Z keyboard.

https://github.com/wavemotion-dave/ColecoDS V9.6: 08-Apr-2024 by wavemotion-dave Removed DrZ80 core - the high quality CZ80 core is all that remains. Complete overhaul of the Adam handlers to clean and refine - jettisoned conversion to FIAD in favor of simple raw sector dumps. Fix for games like Best of Broderbund (dsk and ddp) now load properly. Finally getting to the point where the AdamNet and disk/ddp handling is working smoothly with some of the holdout games now loading and running properly. I've also jettisoned the entire DrZ80 core which was faster than the CZ80 core but did not have the same high-level of compatibility. I've made enough improvements over the years to gain the speed needed that we can run everything under the new higher-accuracy Z80 core. DrZ80 served me well - but like many things in life, it's time to move on. That also freed up about 40K of precious DS resources for future expansion.

A while, perhaps. I believe a big chunk of the problems were that Coleco was far too slow (in some cases not until after they gave up on the Adam) in releasing technical documentation and making it easy for third-party developers to produce software or hardware for the machine. Like TI and the 99/4a, things were held too close to the vest when opening up the information would have produced a larger software and hardware base and probably lengthened support. Atari and the 8-bit line got 10 full years of support mostly because the technical documents were available early and well detailed. Just my ten cents (with inflation).

I think some (all?) of these were developed and brought over by CBS in Europe to the US so we didn't get them until very early 1986.

Boom! Thanks, Jim. That was exactly what I needed - the firmware is well commented and the skew factor is, indeed 4:1 but they SKIP from 15-->2 (5:1) to get the sectors back on track (no pun intended). (note: sectors here are one-based: 1-18) Soft sectored disks can be laid out in any manner - including just a linear layout (1,2,3... etc). The skew is simply used to help efficiency since while the computer is processing the sector just read, other sectors will fly by under the disk read head and having a skew means that when the computer asks for the next logical sector it's more likely to have that sector "coming up" rather than wait for a full rotation of the disk to get that sector back under the head.

Greetings programs! From Marcel's ancient but incredibly useful site, I came across this information on disk sizes utilized by the ADAM (with 160K being the 'coleco standard' size): I can confirm that 160K and 320K work just as described with a sector interleave of 5. That is, the sectors on a track are laid out in the following order: 00 05 02 07 04 01 06 03 And the 720K parameters also make sense with a sector interleave of 4 (given 9 sectors/track): 00 04 08 03 07 02 06 01 05 But the 1.44M (and 640K which I don't care much about) seems wrong. With 18 sectors/track, the interleave of 4 doesn't make sense to me. Maybe the first 9 sectors of a track and last 9 sectors of a track are both 'Interleave 4' but I don't see how 18 sectors could be 'Interleave 4' as the modulo math doesn't work out. Interestingly enough, an Interleave of 5 still works out for the 1.44M parameters: 00 05 10 15 02 07 12 17 04 09 14 01 06 11 16 03 08 13 Anyone have any insights on how a 1.44M disk was laid out for Adam use?

Okay... more questions. Disk emulation is working much better for me now - but I'm perplexed by how CP/M 2.2 and T-DOS 4.5x handles disks and drives of varying size. I know on T-DOS (and presumably via a patch on CP/M) you have to configure your drives - providing how big they are (160K, 320K, etc). So I did that and told T-DOS that my first drive was 320K and my second drive was 160K. So far, so good. I was able to make a 320K T-DOS boot disk with a bunch of utilities on there - it boots and the utilities all load and run reasonably well. But this is where it gets strange. If I put a 160K T-DOS disk into the second configured drive, it works fine - files read and run without issue. I guess that's because I told T-DOS that drive was a 160K drive. But if I put a 160K T-DOS disk into the first drive (configured as 320K max), it will show the directory but things don't load right - most programs I try to run crash and a CP/M STAT command on that drive freezes. If I try to copy *.* to, say, the RAM drive, it will keep trying to copy the same file over and over (no errors - just copying it forever) as if T-DOS misunderstood the directory structure on the 160K disk. Why does T-DOS care if I put a 160K disk into a drive that can support 320K? Even an EOS formatted disk will work properly for SmartBasic which will see the proper space on both a 160K and 320K disk ... now I realize that EOS is a much simpler / linear block structure ... but you would think T-DOS could figure it out by reading the disk and saying "yeah, this is a 160K disk and even though it's in a 320K max drive, I can handle it". Is this just a limitation of how T-DOS (and, probably, CP/M) work? I went through the ADAM CP/M 2.2 manual and the T-DOS 4.5x manual but nothing specifically addressed this. From my endless DOS years, I was able to use different disks (single sided, double sided and different densities) in the same drive with no issues. Or is there still something buggy in my emulation (more likely I'd guess!)? EDIT: Okay... found this in the ADAM Survival guide which gives me a clue with the 'DISK COMPATIBILITY' comments. I suspect that the way the disk structure is laid out, a full 320K DSDD is different enough that you can't mix/match 160K and 320K disks with T-DOS... but it looks like you can mix/match 160K with 'medium-sized' (WTF?) disks that would reduce the capacity on a 320K disk but allow it to remain compatible with 160K disks (I gather that this "Eve Format" is from Eve Electronics). Still digging my way through docs to try and come to grips with all this. EDIT#2 ... I suspect this is another clue:

https://github.com/wavemotion-dave/ColecoDS V9.5: 30-Mar-2024 by wavemotion-dave ADAMnet improvement for disk/tape handling. Improved timing, improved caching and more disk/tape games should load and run correctly. DSi gets a massive 2MB of Expansion RAM for the Adam (32 banks of 64K). DS-Lite/Phat still has 128K (base 64K plus the standard 64K expansion RAM). Adam now properly handles 320K disks and three drive bays are virtually attached (two 320K disk drives and the internal Tape drive at 256K). Adam full keyboard now uses an LED indicator under the CAPS LOCK button to indicate status. Adam has improved keyboard graphic with more keys added. Adam no longer mirrors RAM as a Colecovision would. Adam optimization provided 5% improved emulation speed which should make most everything playable even on the older DS-Lite/Phat. Adam supports the 32K expanded ROM and running carts under Adam emulation - name your ROMs as .adm so it loads into the right place in memory. Tatung Einstein now has two proper standard 200K disk drives. Tatung Einstein full keyboard now uses LED indicators under the SHIFT/CTRL/GRAPH and ALPHA LOCK keys for a visual improvement. Tatung Einstein properly handles the backspace key when using the Alpha-Numeric keyboard overlay. 2000 individual game configurations are supported - save/load states optimized and numerous tweaks under the hood. This one is a big update. Save states and configs are changed to allow more flexibility for me into the future. Sorry. This release started as a cleanup of the Tatung Einstein driver but got out of hand with a desire to really get the Coleco ADAM emulation up to a much higher compatibility level. I had a breakthrough in disk/ddp handling and decided to really pour on the additions for the ADAM to bring it to a nice new plateau. I've reworked the top row of the keyboard graphic to squeeze in another key and make it a bit more authentic looking - obviously with space constraints, I've had to take some liberties with the layout to fit on the DS screen with the goal of keeping the SmartKeys reasonably centered. In settings you can change the speed of the AdamNet drive handling. The default is FAST - but if you want a somewhat more authentic experience, you can choose SLOW or SLOWER - neither of which is quite as slow as an original Coleco disk (or tape) drive ... but you'll get longer loading (with sound effects!) and more visible time on loading screens and maybe that's your jam. Me? I'm old enough now that I don't want to waste too much of my remaining life-force waiting for things to load I hope you guys enjoy it! Do let me know if you use the emulator - I'm well over 500 development hours into this now and feedback is hugely appreciated.

I'm working hard getting the ADAM emulation updated for the next release. I've got two full DSDD (320K) disk drives enabled plus a standard Tape drive (256K) with a new menu to select whatever media you want. I'm excited! I might be the only one I've also got the 1MB expanded RAM working on the DSi and above (the DS-Lite/Phat will have to "struggle" with just 128K of RAM - the base 64K and one bank of expanded 64K .... though to my knowledge, everything known to mankind should run with that configuration).

Finally! I had to go over the ADAMem code about a dozen times before I saw a subtle but significant difference in how I cache the block being read from tape/disk vs the way Marcel does it. It didn't help that ColEM which is what I started with for Adam emulation is so close to the ADAMem implementation - roughly the same layout, functions, variables and it's clear that the two code bases share more than a passing similarity and that caused me to be a bit over-sure of my caching algorithm. I now follow the ADAMem block caching algorithm almost exactly - my timeouts are almost the same though I'm hooked into the VDP vertical blank for timing which is a little course but gets the job done. That removes almost every hack I had in place for ADAM disk/tape and memory handling. I no longer need any special memory pattern to make CP/M disks boot and I can read/write and save back a CP/M disk with no issues. The only remaining weirdness is that Adam Bomb 2 remains incredibly picky about the state of main ADAM RAM on a cold start. I'm still using a set pattern to get it to come up reliably... but otherwise things are in a much better place. Compatibility for Adam games should really shoot up - and I'm excited enough that I'll probably rig up a 2nd virtual disk drive. A new ColecoDS release soon - I've got a bit of cleanup to do and a ton of debug to remove. Huge thanks to Marcel and ADAMEm for a roadmap to follow.

Thanks James - I'm still looking through the AdamEM code - I'm sure the answer is buried in there somewhere. And you know me - I'll keep at it until... I don't have a ton of skill but I have determination

Okay, Clue, tonight we check everything in the right-hand column... I spent the evening (and early morning with coffee) going back through my code, the ADAM Technical Manual, the ADAMem and MAME drivers and ... nothing. I took a guess that maybe the writes from CP/M was pulling the same trick I've seen on reads by some programs (most famously by Super Donkey Kong and Super DK Jr) where the clever game programmer would request to start the NEXT block of data transfer knowing that the CPU could outpace the physical tape/disk and so read and process the last 1K block while the disk/tape controller was slowly filling in behind it. I solved this last year by slightly buffering the read requests so that it does not "instantaneously" fill the read-buffer but will delay a few frames (arbitrary but it worked) before it starts to copy the read-buffer into main RAM. Otherwise games that pull this trick will have wrong data in RAM (Super DK will have massive graphical glitches while Super DK Jr. will fail after completing the first screen, etc). With this as my new guess, I hacked in a quick-and-dirty write delay cache... which didn't seem to help any (admittedly it was done sloppily enough that I might have gotten it incorrect - I pulled it back out for now). I also remember CP/M utilizing the expanded RAM (my emulation is a 128K Adam with one bank of expanded RAM) - I thought it was only for a small RAM Disk but maybe it has other uses and I'm not handling something correctly... so I temporarily disabled the extra bank and while the small RAM Disk did disappear, CP/M disks did not work any better. So I'm back to thinking it's how main RAM is setup. It's just too quirky that CP/M is so picky about what the contents of RAM are on a cold-boot and there is something here I'm just not yet understanding. Now it's not the end of the world if CP/M programs can be run but not write back to disk... ColecoDS is a portable/handheld emulator and being able to play games is more important than full-blown general-purpose emulation... but I'd like to understand and get it as close to perfect as possible. [slight rant mode - feel free to skip!] As an aside, having worked more than 1000 hobby-hours over the last 3+ years on various classic emulators, I can say that the ADAM is the most mysterious in terms of finding definitive technical information. Even the obscure Tatung Einstein got a pile of books from the manufacturer describing the inner details of the hardware, full schematics, timing diagrams, best practices, etc. Coleco didn't seem to release as much technical information and a lot real knowledge appears tribal in nature. Worse, I see gaps from (clearly) knowledgeable people who were once on Atari Age whose posts are now taken down (I assume by request of the person(s) who left... a shame and feels a bit like the "I'm taking my ball and going home!" attitude). Other times I see people say they will respond to a question in private (email, PMs, etc.) which doesn't help grow the knowledge base. I'm very thankful for what documentation does exist - and to those pioneers who make sure that their knowledge is spread far and wide - it's those people who share information freely and publicly that help the hobby the most.

I had that issue for the longest time. I don't understand why, but the only way I could get CP/M disks to boot with my emulator was to initialize all of the ADAM RAM to 0x38 on a "cold-start". As I recall, there was no other pattern from 0x00-0xFF that worked reliably. ADAMem initializes main memory as WORDs (the lower byte of the word to 0x00 and the upper to 0xFF but that wasn't any more useful in getting CP/M disks booting). If I set my emulator to use RANDOM memory at startup, CP/M disks would boot about 1 in 10 tries but most of the time would just get stuck on the loading screen waiting for the A> prompt.

So I'm working on cleaning up the ADAM emulation for ColecoDS and have run into a problem I can't yet solve. Right now, the emulation supports two drive bays - a DISK drive at up to 320K (DSDD) and a TAPE drive at the standard digital data pack capacity of 256K. Both virtual drives work fine for EOS disks/games/programs (e.g. Super Donkey Kong, SmartBASIC, etc.) - no problems reading and writing and saving back to the SD card as a .DSK or .DDP file. I can save high scores, save game states in Super Zaxxon, etc. Both virtual drives work fine for any flavor of T-DOS disks/games/programs - no problems reading and writing and saving back to the SD card as a .DSK or .DDP file. But CP/M 2.2 disks are driving me nuts. I can read them fine - list directories and run programs (Infocom Games and various utilities) but as soon as I try to write to the virtual .DSK it gets screwed up. I end up either destroying the disk image in memory or some other malady (all files are removed from the directory listing, or the disk suddenly gets marked as R/O when it was R/W just second before, etc). I've been sticking to standard 160K disks with no special attributes so as to not introduce issues with larger capacity disks. And it's perplexing. The disk emulation handles the proper ADAM sector skew factor of 5 and appears to be handling the block transfer to and from main memory at the proper timing. I'm still debugging what is obviously a problem in my emulation but if anyone has any clues about what oddness might lie in CP/M write I/O handling on the ADAM, I'm all ears! Even the smallest clue can help me narrow in on my issue. I've been googling facebook and the forums here for clues - and although there are occasional mentions of oddness with CP/M and ADAM, there isn't anything definitive that I can point to. I have a hunch it might have something to do with how I initialize main ADAM memory. CP/M disks seem to be picky about the state of RAM when the system comes up... Appreciate you guys!

The DS-Lite/Phat (original blocky version) is an ARM9 at 67MHz, 4MB of RAM and a screen resolution of 256x192. The DSi and DSi/XL/LL is an ARM9 that can run at either 67MHz (compatibility mode) or 134MHz with 16MB of RAM and a screen resolution of 256x192. The older 2DS/3DS is an ARM11 that can run in either ARM9 compatibility at 134MHz (like a DSi) or at full 268MHz with 128MB of RAM (only 16MB accessible in compatibility mode) and a screen resolution of 400x240. The "NEW!" 2DS/3DS is an ARM11 quad-core running at 804MHz with 256MB of RAM... it can also run in ARM9 compatibility mode (134MHz / 16MB RAM) and a screen resolution of 400x240 or 800x240. I target the DSi for all of my emulators which means the DSi / XL / LL will all run my emulator as it is intended... 134MHz and 16MB of RAM at 256x192. If you run it on an older DS or in compatibility mode on a DSi (via a Flash Cart), it will be limited to 67MHz and 4MB of RAM which I can detect and adjust the emulation accordingly. Since so many people have older DS models in their basements/closets, I try to make sure my emulators will run on those older models. My emulators will not take advantage of the improved screens nor the faster CPU and increased memory of the 2DS/3DS... but those models are certainly capable of running in DSi mode (so 134MHz and 16MB of RAM) - which is still going to give you the full experience of my work. There will be some hardware up-scaling of the 256x192 resolution I output to the native 2DS/3DS 400x240... but generally it will look pretty good. I could target higher models - but it's a different set of development tools and, well... I happen to have a small army of DSi units (both normal and XL/LL) and so that's my platform of choice

For sure. You can go into the game config and bump up the sound quality... There are 4 levels (LOW, MEDIUM, HIGH and ULTIMATE). Each level requires more CPU horse-power but you can try bumping it up one level for any game and see how the system performs. The DSi (with the 2X CPU) defaults to HIGH and many of the simple games (Astrosmash, Treasure of Tarmin, etc.) can easily drive up to ULTIMATE on the faster processor.

Glad to hear it! I've worked hard to ensure that the experience on the older DS-Lite/Phat hardware is nearly identical to that of the later models. The only real difference is that I have to sample the sound engine a bit less often - so the sound is not quite as good as later models - but passable for handheld use.