DS99/4a - Emulator for the DS/DSi

[+arcadeshopper]

Well this might help or make it worse

 

https://www.unige.ch/medecine/nouspikel/ti99/disks2.htm#Sector R/W

[+wavemotion]

34 minutes ago, arcadeshopper said:

Well this might help or make it worse

https://www.unige.ch/medecine/nouspikel/ti99/disks2.htm#Sector R/W

Well... I've got some reading to do. I wonder if it's not too late to change DS99/4a into a TI-83 Calculator emulator  

 

I appreciate all the help guys... I'm in a bit over my head but will continue to make progress!

[Tursi]

6 hours ago, llabnip said:

Ok... I don't (yet) understand this but I'm going out on a limb and will guess this is probably my problem!

 

Right now I'm emulating via a PC hack ... I simply look for the Program Counter to be >40e8 and then I vector off to handle sector read/write. Something in my gut tells me that's not "level 2" of anything

This is exactly what Classic99 does and it's compatible with everything. The only thing are you bypassing is direct register access to the disk controller - all software interfaces work fine.

 

[Tursi]

6 hours ago, arcadeshopper said:

roa does level2 dsr calls for sector read/write btw.. so you need to support those in your disk emu.. classic99 doesn't in one of it's modes

What are you talking about? ROA was developed on Classic99, and the game works fine in FIAD, DOAD, and TI Controller (with size hack) just fine.

[+arcadeshopper]

4 hours ago, Tursi said:

What are you talking about? ROA was developed on Classic99, and the game works fine in FIAD, DOAD, and TI Controller (with size hack) just fine.

sorry someone posted before that it didn't work in one of the modes.. works fine for me in fiad mode 

[Tursi]

2 hours ago, arcadeshopper said:

sorry someone posted before that it didn't work in one of the modes.. works fine for me in fiad mode 

People keep regurgitating statuses from 15 years ago as if Classic99 never saw a single update.  Based on the number of posts that I've seen (let alone the ones I haven't), if I didn't post it, or I posted it more than 10 years ago, it's probably not true now.

 

 

[+wavemotion]

With three cups of coffee and some help from @Tursi (mostly to eliminate things to try) I've got a discovery.  ROA is making use of the 9901 timer. When I did my re-write, I didn't understand that very well - and based on some experiments and some reading, it looked like it was mostly used for Cassette IO handling which I wasn't supporting. So I simplified my handling of anything 9901 timer-based...  and by simplified I mean I almost totally ignore it.  I suspect ROA is one of those rare games that makes use of it. I don't know if it enables the timer interrupt or if it's just setting and checking the countdown register... but this is my current best guess as to what's going wrong with DS99.

 

 

[+OLD CS1]

13 hours ago, llabnip said:

and by simplified I mean I almost totally ignore it

This is how I handle so much of my life at this point.

 

BTW, I wanted to tell you that you are a nuisance: I found myself browsing eBay for a DS because of your new emulator.  So, yeah, keep making it better and thanks for nothing.  (Um, do you know anything about programming on Android?)

[+wavemotion]

40 minutes ago, OLD CS1 said:

BTW, I wanted to tell you that you are a nuisance: I found myself browsing eBay for a DS because of your new emulator.  So, yeah, keep making it better and thanks for nothing.  (Um, do you know anything about programming on Android?)

Nice! I don't know Android programming... 

 

One tip on a DS - the recommended unit is a DSi as it will have 2X the CPU and 4X the memory and is an easy soft-mod via the SD card slot built into the unit. Of the DSi units... the XL has a somewhat slower refresh on the LCD and more closely mimics the slow fade of phosphor on a Tube/TV screen. I have emulation settings to blend 2 frames to produce a similar effect, but it comes at a 15% CPU penalty (which is OK for most simple games).

 

Anyway... one trick is to look for broken DSi units. For example, you don't really need the actual Game/Cart slot to work. You only care about the SD card slot (which was criminally underutilized during the heyday of the DSi). Units with a broken cart slot tend to go really cheaply and will have no bearing on playing homebrew stuff via the SD card slot.  The older DS units do not have an SD card slot.

[+adamantyr]

On 1/30/2023 at 10:23 AM, Asmusr said:

Regarding 4MB SAMS, the hardware only exists in very low numbers, and I'm pretty sure Realms of Antiquity does not depend on that. 

Yeah, it runs on the 1mb version. It may even break on the 4mb version.

[+adamantyr]

15 hours ago, llabnip said:

With three cups of coffee and some help from @Tursi (mostly to eliminate things to try) I've got a discovery.  ROA is making use of the 9901 timer. When I did my re-write, I didn't understand that very well - and based on some experiments and some reading, it looked like it was mostly used for Cassette IO handling which I wasn't supporting. So I simplified my handling of anything 9901 timer-based...  and by simplified I mean I almost totally ignore it.  I suspect ROA is one of those rare games that makes use of it. I don't know if it enables the timer interrupt or if it's just setting and checking the countdown register... but this is my current best guess as to what's going wrong with DS99.

It does use the timer, but it's for random numbers. The clock runs so fast it's usable in any state. (I originally used the VDP timer, but it produced predictable patterns for battlemap generation.) I'm not sure if that would cause the game to not work, though, unless even trying to set the CRU bits to access it caused your emulator to crash.

 

Also, for the 180K version, you have to use the cartridge binary, and put all the rest of the files from the game disk on a single disk, and split the world disks into four disks. And be sure to configure their location in the configuration menu.

[+wavemotion]

Ok... finally some success.  Many Bothans died to bring us this.

 

There were several issues - but the primary culprit was the SAMS memory which I was not handling in a robust way. Realms of Antiquity sometimes maps the same bank into different memory regions - and my swapping was not handling that properly.

 

I've made the corrections and it runs - with timer handling for proper randomization (my timer handling is not all that accurate yet... but perfectly fine for this use).

 

The problem: the emulation accuracy of having a 16-region map of 4K chunks plus Timer handling costs the emulator 20% in speed. That's okay for the DSi and above where we had the headroom, but was not acceptable for the older DS (or DSi users with R4 card) with the slower CPU - many of those games were already running right at the margins of full-speed.

 

So I split the CPU core into two duplicate cores... one with fast, non-memory-mapped handling (supporting up to 32K expanded memory) and the other more accurate core that handles things like SAMS memory mapping, IDLE instruction use and Timers. 

 

This way, 98% of the games use the faster, streamlined core and they get the full speed (well... it's a 2% hit on speed due to some additional core checks... but we can absorb a 2% hit).  If a game uses the timer, IDLE instruction or needs SAMS memory mapping, it will auto-switch to the more accurate core.

 

I'm not ready for a new build yet - I have a ton of cleanup to do from the destruction caused by the debugging of this one.  Hugest thanks again to @Tursi for his guidance and willingness to try experiments to aid in this endeavor. 

 

[+wavemotion]

Ok... tonight I'll be doing the cleanup work and will get a new release out. 

 

For the DSi, it will support triple-360K drives (DSK1, DSK2 and DSK3) along with the previously available (but now working!) SAMS 1MB support.  I'll also persist the SAMS memory when saving/loading states.

 

For the older DS-Lite (or a DSi / 2DS / 3DS running via an R4 flash cart), the system will not have enough memory resources for that full support.  I'll need to make a design choice.

 

As a TI enthusiast... would you rather have:

• Dual 180K Disk Drives with a SAMS 1MB card
• Dual 360K Disk Drives with a SAMS 512K card

The main reason I ask is that there is not that much SAMS-aware stuff out there and some of it really wants a full 1MB so it seems less useful to provide a 512K version (though Dungeons of Asgard will run!). 

 

Thoughts or opinions of any kind?

 

[+Lee Stewart]

3 hours ago, llabnip said:

The main reason I ask is that there is not that much SAMS-aware stuff out there and some of it really wants a full 1MB so it seems less useful to provide a 512K version (though Dungeons of Asgard will run!). 

 

fbForth 2.0 can manage SAMS from 128 KiB to 32 MiB (Classic99 hack). I have successfully tested a 4 MiB SAMS card on real iron—thank you, @FALCOR4. Turboforth ( @Willsy ), Camel99 Forth ( @TheBF ), and RXB ( @RXB ) also have SAMS functionality.

 

...lee

[+Ksarul]

Is it possible to set it up with a simple software configuration switch that allows both options? If not, I suspect that most gaming use cases don't require disk sizes larger than 180K, so you can probably get away with that and 1M SAMS. I say that on the gaming disks only because 180K was really the de facto disk size maximum for commercial offerings BITD, and most stuff was actually released on 90K disks.

[+arcadeshopper]

4 hours ago, llabnip said:

Ok... tonight I'll be doing the cleanup work and will get a new release out. 

 

For the DSi, it will support triple-360K drives (DSK1, DSK2 and DSK3) along with the previously available (but now working!) SAMS 1MB support.  I'll also persist the SAMS memory when saving/loading states.

 

For the older DS-Lite (or a DSi / 2DS / 3DS running via an R4 flash cart), the system will not have enough memory resources for that full support.  I'll need to make a design choice.

 

As a TI enthusiast... would you rather have:

• Dual 180K Disk Drives with a SAMS 1MB card
• Dual 360K Disk Drives with a SAMS 512K card

The main reason I ask is that there is not that much SAMS-aware stuff out there and some of it really wants a full 1MB so it seems less useful to provide a 512K version (though Dungeons of Asgard will run!). 

 

Thoughts or opinions of any kind?

 

pretty sure very little cares of sams is 1mb.. some things can address it but nobody uses it really so 512k should be fine

[+wavemotion]

Thanks for the feedback guys... I've released DS99/4a version 0.9:  https://github.com/wavemotion-dave/DS994a 

 

This supports triple 360K drives (DSK1, DSK2 and DSK3) and will handle SAMS memory banking properly such that Realms of Antiquity will run if using a DSi or above (as it has the extra memory needed). I played about 1 hour... two dungeons and the starting village and surrounding environs. Super fun!

 

One thing that isn't quite right... the game won't let me swap disks. That is:  it works fine if I mount up the 3 disks (DSK1, DSK2 and DSK3) before starting - it reads and writes properly and save games work fine... but if I forget to put in a disk in a drive and it prompts me, it never accesses the drive when I press "any key" after mounting the disk. I don't see it hit the disk CRU registers and I don't see it hit the TI Controller registers nor does it ever read any sector from the newly mounted disk. I've got an outstanding question with @adamantyr on how he's doing the disk swap check to see what I'm missing in my emulation. If I can solve that, it would be possible to play this on the older DS hardware with just 2 drives and swapping the world disks in/out.

 

Lastly, I now persist the SAMS memory with Save and Load state. I use a Run-Length encoding so it doesn't always have to save the full 1MB of memory. In fact, if the game doesn't make use of the memory, that whole 1MB will shrink down to 8 bytes of save/load.

 

I had to change the way save states work... so older .SAV files will not work with version 0.9.  Configuration has also been reset as I prepare for the 1.0 release (where I hope to lock it down and not wipe again) - so be sure to reset your keys if you map them for a game.  For Realms of Antiquity, I'm currently using ESDX mapped to the D-Pad for easy movement... A=ENTER, B=SPACE, Y='Y' (for YES) and X='N' (for NO) and START='C'ast and SELECT='I'nventory at least until I think of a better mapping. Lesser used keys are just handled via the virtual keyboard. So far this has allowed me to play it quite smoothly on the DS.

 

By default each game is configured to run on a 32K expanded system. The SAMS support must be enabled on a per-game basis (you can also set to have the SAMS support enabled globally). Be aware - the SAMS handling does require a more accurate emulation core and will slow down the emulation by almost 20%.  That's generally fine for the DSi and above but my recommendation is to use the default 32K expanded system for virtually all games and only enable the SAMS support for the few things that need it.

 

Let me take this opportunity to fill in a bit of back-history on me... In 1980 I got my Atari VCS (now known as the Atari 2600) and my world forever changed. My buddy got the Intellivision the same year and we played the hell out of both those systems. A couple years later and I got the Colecovision (and later ADAM) and he got the TI99/4a. We played a summer of Tunnels of Doom and Pirate's Adventure, Ghost Town and Parsec.  We would start the cassette loading on ToD and go play for 10 minutes and come back and hope that the load didn't crap out along the way. So much fun. I made my first sprites on that system using the built-in TI-BASIC ... moved them around with keys and was enthralled with the whole experience. Couple that with having seen TRON that same summer and my career choice was pretty much set for life.   

 

Fast forward to 2020 and the pandemic got me in a funk... feeling restless I started to port emulators to the DS as a sort of hobby-project. It's not a coincidence that Atari 2600, Intellivision, Colevovision, ADAM and the TI-99/4a are in the group of emulators I now maintain for the handheld. 

 

Well... that's me. Enjoy!

End of line.

[+wavemotion]

A bit of an interesting development... in reading @adamantyr's development blog, I saw that a fairly late entry claimed needing 256K of SAMS memory (rather than the 1MB claim on the main page). I also saw another blog entry that showed the memory map going up to 74 SAMS blocks (74x4K = 296K).  So I decided to track the highest SAMS block called for and played the game for about 30 minutes... the largest numbered 4K block I got was 67... reasonably close to the 74 shown on the memory map.  If that's true - I think the game would play fine on the older DS units running only 512K SAMS emulation (128 blocks). So I tried it... and it worked!  At least through the first two villages. 

 

It's hammering SAMS swaps ... but it's running at 58 fps in battle and well above 60 (full speed) in the overworld so it's perfectly playable with no detectable slowdown even on the oldest DS hardware. 

 

Here is my oldest DS-Lite unit running Realms of Antiquity:

[+wavemotion]

Just an update... I'm asymptotically approaching a 1.0 release. It's clean - it's semi-lean and it plays like a dream

 

I've integrated an improved TI keyboard courtesy of @dphirschler with sharper graphics, cleaner lines and a font that is closer to (at least one of!) the TI keyboards. 

 

Soon... soon... 

[ti99iuc]

It is nice!

[+jedimatt42]

Ok, it is pretty cool to be able to TI from a thing that is clearly unimportant and interruptible from my wife's perspective. My other TI hobby work looks too much like my day job. Tunnels of doom via stylus is pretty natural once you remember all the key combos.   

 

I gave the previous version a go, and noticed via TI BASIC, I don't seem to be able to hold down FCTN-4, break. I had to press it a dozen times to get out of a 10 print... goto 10 loop. 

 

The 4A keyboard isn't read with interrupts, and there isn't a buffer, so if it isn't pressed for that brief moment in such a loop that the BASIC interpreter peeks at the keyboard then it is just missed. If you can handle touchscreen down and up events separately, it would improve the keyboard maybe. 

 

I hadn't looked at custom mapping keyboard to buttons yet. That might work around the use case.

[+wavemotion]

32 minutes ago, jedimatt42 said:

Ok, it is pretty cool to be able to TI from a thing that is clearly unimportant and interruptible from my wife's perspective. My other TI hobby work looks too much like my day job. Tunnels of doom via stylus is pretty natural once you remember all the key combos.

Thanks for the feedback Matt! If you go into Key Config (before the game is started) you can press X a couple of times to toggle in the ESDX keys on the d-pad... add PRCD and BACK to some keys (maybe START/SELECT or X/Y) and maybe two more keys for F(ire) and M(ap) you'll be able to do like 80% of exploration without ever touching the virtual keyboard.  

 

I'll look into FCTN-4 = BREAK ...  In theory it should keep the key pressed if you are using the (default map) left shoulder as FCTN and press and hold the virtual keyboard 4. If you're using the virtual keyboard to do the FCTN it will only be a momentary press due to limitations of not being able to press two places on the screen at a time (unlike, say, modern phones). 

[PeteE]

2 hours ago, llabnip said:

I'll look into FCTN-4 = BREAK ...  In theory it should keep the key pressed if you are using the (default map) left shoulder as FCTN and press and hold the virtual keyboard 4. If you're using the virtual keyboard to do the FCTN it will only be a momentary press due to limitations of not being able to press two places on the screen at a time (unlike, say, modern phones). 

Can you make the FCTN,CTRL,SHIFT keys "sticky" (somewhat like shift key on modern phones keyboard) where you can press FCTN and it stays pressed until the next key is pressed and released. That would get around the limitation of the resistive touchscreen. The FCTN key on the screen could highlight/invert color to indicate that it is held in the "sticky" state.  Pressing FCTN again (without pressing a different key) would clear the sticky state.

Edited February 9, 2023 by PeteE

[+wavemotion]

13 minutes ago, PeteE said:

Can you make the FCTN,CTRL,SHIFT keys "sticky" (somewhat like shift key on modern phones keyboard) where you can press FCTN and it stays pressed until the next key is pressed and released. That would get around the limitation of the resistive touchscreen. The FCTN key on the screen could highlight/invert color to indicate that it is held in the "sticky" state.  Pressing FCTN again would clear the sticky state.

Interesting. That's almost how it works if you press those keys on the virtual keyboard. But as soon as you press the next key, it "releases" the FCTN/CTRL/SHIFT.  I could look into making them truly sticky until the key is pressed again - that would probably solve @jedimatt42's issue if he's trying to do it with the touch screen.  

 

I suppose I could even make it configurable. A couple builds back, I added like a dozen "spare" configuration flags... both on a per-game basis and globally.  

[PeteE]

9 minutes ago, llabnip said:

Interesting. That's almost how it works if you press those keys on the virtual keyboard. But as soon as you press the next key, it "releases" the FCTN/CTRL/SHIFT.  I could look into making them truly sticky until the key is pressed again - that would probably solve @jedimatt42's issue if he's trying to do it with the touch screen. 

Oops, I wasn't clear in my statement, and I don't have my DS with me in the office, so I think you may already have what I intended to write.  I think the problem is this:   "But as soon as you press the next key, it "releases" the FCTN/CTRL/SHIFT"     it should be "as soon as you release the next key"  -  both FCTN and the next key need to be held from the TI point of view at the same time.  If that is how it already works, I apologize for not verifying it myself.

Edited February 9, 2023 by PeteE