DS99/4a - Emulator for the DS/DSi

[+wavemotion]

14 minutes ago, Asmusr said:

I'm not suggesting anything complicated, just that one of X or Y keys (on the DS) is mapped to 2 by default.

Oh! That's easy   

 

Yeah... kinda seems pointless to have ABXY all mapped to the joystick fire button by default. 

 

Any thoughts on a reasonable default keymap?  A and maybe B both for FIRE since some people naturally rest their thumbs on one or the other... X for '1' and Y for '2' which should allow most games to start (both from the TI menu and often from the Game menu itself).  

 

Edit: checked in a build with X='1' and Y='2'. Start was already the CR/ENTER and Select was SPACE so with that I bet you could start up 90% of all games without touching the touch-screen.

 

9 minutes ago, InfiniteTape said:

Realms of Antiquity. It's a modern TI release by @adamantyr. It's not free, but it may push your implementation in new ways. http://quixotic.adamantyr.com/roa.htm

Ah... I've read so much about the game and watched @pixelpedant's YouTube on it... I seem to recall that it required SAMS so you will have to turn on SAMS (you only get 512K on the DS or DSi/2DS/3DS if using an R4 cart... but you get 1MB if using DSi or 2DS/3DS via Twilight Menu).  I also seem to recall that it used 360K disks - right now I only support the basic PEB TI disk controller so that's limited to 180K DSSD disks. 

[Asmusr]

10 minutes ago, llabnip said:

Edit: checked in a build with X='1' and Y='2'. Start was already the CR/ENTER and Select was SPACE so with that I bet you could start up 90% of all games without touching the touch-screen.

Yes, I think that works.

[InfiniteTape]

11 minutes ago, llabnip said:

Ah... I've read so much about the game and watched @pixelpedant's YouTube on it... I seem to recall that it required SAMS so you will have to turn on SAMS (you only get 512K on the DS or DSi/2DS/3DS if using an R4 cart... but you get 1MB if using DSi or 2DS/3DS via Twilight Menu).  I also seem to recall that it used 360K disks - right now I only support the basic PEB TI disk controller so that's limited to 180K DSSD disks. 

Turning on SAMS got me into the game. I'd forgotten about that requirement. It looks like getting support for mounting DSK2 is minimum from where we are now. It's possible to split the content into 4 180K disks, but not ideal.

[+wavemotion]

46 minutes ago, InfiniteTape said:

Turning on SAMS got me into the game. I'd forgotten about that requirement. It looks like getting support for mounting DSK2 is minimum from where we are now. It's possible to split the content into 4 180K disks, but not ideal.

I can make that happen   

 

If you're willing to try it, I'll add in DSK2 mount support in the morning. 

[+arcadeshopper]

2 hours ago, llabnip said:

Ah... I've read so much about the game and watched @pixelpedant's YouTube on it... I seem to recall that it required SAMS so you will have to turn on SAMS (you only get 512K on the DS or DSi/2DS/3DS if using an R4 cart... but you get 1MB if using DSi or 2DS/3DS via Twilight Menu).  I also seem to recall that it used 360K disks - right now I only support the basic PEB TI disk controller so that's limited to 180K DSSD disks. 

correct it either needs 360k disks or a large drive like TIPI 

[Tursi]

We can probably patch the TI controller DSR to think it can manage 360k disks, too. If you're using my technique then it's just reading sector numbers anyway (IIRC), so even though the ROM wouldn't work for chip level emulation, for this hack it should be fine?

 

[Tursi]

You know... I would test the hell out of it, but in a quick test here, I think it might "just work" if you allow 360k floppies. It looks like the limit is enforced inside the sector read function, and that's completely bypassed. I tested here with a 360k floppy and the test disabled in Classic99 - and it seemed to work.

 

[+Ksarul]

38 minutes ago, Tursi said:

You know... I would test the hell out of it, but in a quick test here, I think it might "just work" if you allow 360k floppies. It looks like the limit is enforced inside the sector read function, and that's completely bypassed. I tested here with a 360k floppy and the test disabled in Classic99 - and it seemed to work.

 

All you really have to do to the TI controller to get it to work with 360K disks is to change the number of tracks per side to 80 in the DSR. Then you get 80-track SD disks with 360K of storage space. Of course, then you have the issue of generating the 80-track disk images. . .and all of this assumes that @Tursi's trick isn't a better solution to the problem. At least there are a couple of ways to get there from here.

[Tursi]

26 minutes ago, Ksarul said:

All you really have to do to the TI controller to get it to work with 360K disks is to change the number of tracks per side to 80 in the DSR. Then you get 80-track SD disks with 360K of storage space. Of course, then you have the issue of generating the 80-track disk images. . .and all of this assumes that @Tursi's trick isn't a better solution to the problem. At least there are a couple of ways to get there from here.

I think that change actually happens later in the code path than the intercept - which happens at the start of sector read. Like I say, I had Classic99 reading a 360k disk image with no changes at all. But yeah, I'd forgotten it was possible to hack the TI controller that way... 

 

Of course, either path ignores the realities of the disk image. If it's a 360k disk image, it's much more likely marked as double density than 80 track. But since the sector read is being simulated, it ends up not mattering.

 

[+wavemotion]

Thanks guys... I've been working hard this morning adding in support for dual 360K disks. I've got the TRON soundtrack running on loop in the background and hopefully in a few hours I'll have something up and running!

[+wavemotion]

Okay...  I've checked in 0.7e with support for Dual 360K disk drives. Press X on the disk menu to swap from DSK1 to DSK2 and back again (instructions are at bottom of screen). Temporarily enabled 1MB SAMS even for older DS-Lite users with R4 card.  This only leaves me with about 100K of free memory on the older DS-Lite (or those using R4 cards to load which always run in DS-compatibility mode).  That's not sustainable... will have to make a trade-off at some point for older DS users. Maybe if you want 1MB SAMS on older hardware you only get one disk drive... 

 

Speaking of two drives... please don't mount the same disk in two different drives until I get protection for that worked out properly.  What would happen if you did this? I foresee two possibilities. It might work. Or... we could create a time paradox, the results of which could cause a chain reaction that would unravel the very fabric of the space time continuum, and destroy the entire universe! Granted, that's a worse case scenario. The destruction might in fact be very localized, limited to merely our own galaxy.

 

I've also made it trivial to add support for DSK3 in the future but honestly on this little Nintendo handheld, it's probably not really useful.

 

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

[InfiniteTape]

That was quick, but in my experience the TRON soundtrack will do that!

 

We're getting a little farther. I mapped the game disk ROAGAME to DSK1 and the first data disk ROAWORLD12 to DSK2. There's a ROAWORLD34 that's also needed, but you can use an in-game menu to set it to look at DSK2 for both of them, and it prompts you to swap disks as needed. (Note: I've never tried that feature on real hardware, since I use TIPI.)

 

Everything goes fine during new game setup until it needs ROAWORLD34. The game prompts me to put it into DSK2, and I mount that disk in the emulator menu. But the game keeps prompting me and won't proceed. I've confirmed in the emulator menu that the list contents of the disk look correct. I'm not sure if this is an issue with swapping disks mid-game or with some other aspect of emulating the game.

 

Implementing DSK3 support might be a faster fix, but something doesn't seem right as-is. Is there debug output available somewhere?

[+wavemotion]

Hmmm... just using Adventure and ToD to save and load and swap disks... I'm not having any problems mounting a new DSK2.  But those are pretty simple examples. 

 

It is possible the 360K support isn't quite right - though it's getting pretty far for that to be a major problem.

 

I put up a special version on github called:  DS994a_3D.nds

 

This has DSK3 support... this test version will only run on DSi or above.

[InfiniteTape]

On 1/28/2023 at 10:08 AM, llabnip said:

Hmmm... just using Adventure and ToD to save and load and swap disks... I'm not having any problems mounting a new DSK2.  But those are pretty simple examples. 

 

It is possible the 360K support isn't quite right - though it's getting pretty far for that to be a major problem.

 

I put up a special version on github called:  DS994a_3D.nds

 

This has DSK3 support... this test version will only run on DSi or above.

Thanks. That version let me mount all three disks. I can get through the character creation and the introductory text. Once it tries to switch to the main game screen, there's a brief moment of a black screen with white grid, then it stops on a light green screen with dark green vertical lines.

 

[+wavemotion]

1 minute ago, InfiniteTape said:

Thanks. That version let me mount all three disks. I can get through the character creation and the introductory text. Once it tries to switch to the main game screen, there's a brief moment of a black screen with white grid, then it stops on a light green screen with dark green vertical lines.

So someone else reported that as well... and we discovered that if you mount the same 3 disks as DSK1, DSK2 and DSK3 in Classic99 it will fail at exactly the same point. Which is perplexing!  Classic99 works great when the default DATA directory is mounted as FIAD but not when mounting the three independent .DSK images in DSK1, DSK2 and DSK3 (if you could try this experiment for confirmation that would be another data point).  I even built a special version that would accept a 1.44MB DSK image (highly non-standard but do-able with TIIMAGETOOL) and we tried to copy all files to that disk mounted as DSK1 and got the same behavior.  Something strange for sure... still investigating.

[+InsaneMultitasker]

1 hour ago, llabnip said:

I even built a special version that would accept a 1.44MB DSK image (highly non-standard but do-able with TIIMAGETOOL) and we tried to copy all files to that disk mounted as DSK1 and got the same behavior.

Be aware that disk images beyond 360K (technically 400K but that's a special use case for ramdisks & nanoPEB images - see @Lee Stewart post below) require a DSR (the EPROM-based disk controller routines) that supports bitmap and file cluster calculations for the  larger capacities.  While you may be able to read and write some sectors with success, file IO leveraging the TI controller routines will be problematic beyond a 360K image.

[+Lee Stewart]

27 minutes ago, InsaneMultitasker said:

Be aware that disk images beyond 360K (technically 400K but that's a special use case for ramdisks) require a DSR (the EPROM-based disk controller routines) that supports bitmap and file cluster calculations for the  larger capacities.  While you may be able to read and write some sectors with success, file IO leveraging the TI controller routines will be problematic beyond a 360K image.

 

The 400 KiB nanoPEB images should also work because they use the sector-allocation bitmap in the usual way.

 

...lee

[+adamantyr]

On 1/27/2023 at 2:08 PM, InfiniteTape said:

Realms of Antiquity. It's a modern TI release by @adamantyr. It's not free, but it may push your implementation in new ways. http://quixotic.adamantyr.com/roa.htm

Yeah, developer of Realms of Antiquity here. In order for it to run, you will need to emulate the SAMS card, which provides 1024mb of CPU memory to the base TI.

 

Hardware details can be found here: http://www.unige.ch/medecine/nouspikel/ti99/superams.htm

[+arcadeshopper]

1 hour ago, adamantyr said:

Yeah, developer of Realms of Antiquity here. In order for it to run, you will need to emulate the SAMS card, which provides 1024mb of CPU memory to the base TI.

 

Hardware details can be found here: http://www.unige.ch/medecine/nouspikel/ti99/superams.htm

He's got sams emulation 1024 on larger ds's and 512k i think on the lesser ones and is working on 360k floppy emu now.. having issues

 

[+wavemotion]

Ok.. I bought a copy of @adamantyr's Realms of Antiquity on itch.io... it's far too difficult to debug this remotely

 

I'm using RoA version 4.22.045 (latest at time of writing)

I'm using Classic99 QI.399.063 (latest at time of writing)

DS99/4a version 0.8 (latest at time of writing)

 

Here is what I can confirm..

 

It works fine in Classic99 both via default FIAD and via DSK1, DSK2 and DSK3 mounting of the 360K disks (using the Disk Image selection... not the TI Controller selection which has properly emulated limitations of 180K).

 

It does not work fine in DS99/4a... it will let you mount the 3 disks and will get through character creation with nice title screen music and it all seems fine until you go to start the adventure - at which point the game just shows garbage output on the screen.

 

I tried to break up the ROAGAME disk into two 180K chunks per the instructions here: http://quixotic.adamantyr.com/roa-running.htm but the ROA game file is, by itself, 768 sectors and will not fit on any 180K disk image. 

 

I tried to run the game .bin to cover the first disk and split everything else up into 180K disks and got the same results - character creation goes fine but then causes garbage to the screen upon starting the game.

 

So I switched tactics to not using the .bin file and just load the disks via XB and I get the 'Loading......' screen but then the screen turns almost all black with little flashes of the title screen showing... some light beeping. The keys are non-responsive. 

 

I grabbed as many 360K disks as I could get my hands on... mostly compilations and such and those seemed to run fine with DS99/4a. I was able to load all parts of the compilations and save back to the disk as appropriate. Looking at the written disk under a hex dump didn't show any obvious corruption - so I think the 360K 'hack' of the TI Controller is working fine. 

 

So the only conclusion I have so far is that DS99/4a isn't up to snuff   But we kinda knew that.

 

Based on anything I've said above, I'll take any hints, clues, conjectures or just wild speculations... even the smallest clue can help me debug!

 

 

Edit: I know I've read somewhere that the game runs under SAMS 1MB and also 4MB... I have the 1MB emulation but perhaps the game is trying to detect if there is a 4MB configuration and I'm not handling that right?  I don't quite understand how you get 4MB SAMS as there are 256 banks of 4K = 1MB... perhaps some CRU bits select the 1MB chunk and I'm not handling that?  Just guesses at this point...

 

 

[+Lee Stewart]

1 hour ago, llabnip said:

Edit: I know I've read somewhere that the game runs under SAMS 1MB and also 4MB... I have the 1MB emulation but perhaps the game is trying to detect if there is a 4MB configuration and I'm not handling that right?  I don't quite understand how you get 4MB SAMS as there are 256 banks of 4K = 1MB... perhaps some CRU bits select the 1MB chunk and I'm not handling that?  Just guesses at this point...

 

This post might help.

 

...lee

[+wavemotion]

Thanks Lee - that's helpful. I started a more earnest debug of the problem at lunch today and didn't make much progress. I'm moving away from thinking this is a 360K Disk read/write issue but maybe something wonky with SAMS handling.

 

I currently pass the exptest_8.bin test at 1MB - both quick test and full test.

 

Dungeons of Asgard plays fine (I'm about 1 hour into the game) at 128K of AMS memory (I had problems with this when I didn't have pass-thru mode working right).  The game seems to play correctly no matter if I load from the .bin or via XB and the DOA.DSK file.

 

Texcaster also seems fine with 1MB of SAMS memory (sky textures fine)

 

However... AMSTEST4.dsk does not find any SAMS memory which is a smoking gun...

 

 

 

 

[Asmusr]

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

[+arcadeshopper]

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

[+wavemotion]

25 minutes 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

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