Any info on StellaDS?

[+johnnywc]

7 minutes ago, llabnip said:

So I see exactly that for Gorf... but that's not the FF offset, it's the memory location where the FF offset is... right?

Yes, you are correct.

7 minutes ago, llabnip said:

And so I see 3E0 as the FF Offset pointer but the memory location of ARM_RAM[3E0] is always zero (since John is not using a FF offset).

Yes, this is true for Gorf.  Qyx is using an offset of 200 since I needed to use lda # (0-33) for certain kernels.

7 minutes ago, llabnip said:

Who would write the 3E0 memory location? Can I assume that if there is a zero in memory location 3E0 it will never change? I assumed the FF Offset was changeable at run-time.

You would only typically change this either once on Initialize like Darrell does or hack the actual driver using a binary editor.  Changing it more than once wouldn't make sense as all of your FF operations would most likely fail or produce unexpected results 

7 minutes ago, llabnip said:

 

In other news, I found that a Fast Fetch LDA is often followed by STA. It's 15:1 in Gorf that it's an LDA-STA pair.  It's only 5:1 for Turbo.   But doing a "look ahead" and seeing a LDA-STA pairs and processing them together actually produces a nice speedup! Gorf got almost 2 frames of performance. Draconian as well.  Galagon gets a frame of performance as does LBA.  Turbo Arcade doesn't even get a full frame of performance... but it's not a loss!

Cool!  The 5:1 ratio for Turbo is because it doesn't have many kernels so most of the lda #s are doing an sta # immediately after but just having one *not* do that will have the ratio skewed.

 

However, looking at the main Turbo kernel:

 

KernelDefault:
    sty COLUBK
    stx COLUPF

    lda #DS_PF0L
    sta PF0
    
    lda #DS_PF1L
    sta PF1         ; 18

    lda #DS_P1GFX
    sta GRP1        ; 23
    
    lda #DS_P1CLR
    sta COLUP1      ; 28
    
    lda #DS_PF2L
    sta PF2         ; 33

    lda #DS_PF0R
    sta PF0         ; 38

    lda #DS_PF1R
    sta PF1         ; 43

    nop 
    
    lda #DS_PF2R
    sta PF2         ; 48
        
    lda #DS_P0GFX
    sta GRP0        ; 53
    
    sleep 7         ; 7 60
    lda #DS_PFCLR
    tax             ; 4 64
    lda #DS_BKCLR
    tay             ; 4 68
    
    
    lda #DS_P0CLR   ; 2 70
    sta COLUP0      ; 3 73
    jmp FASTJMP     ; 3 76

I could use the LDX LDY FF feature to change the lda #DS_PFCLR , tax and lda #DS_BKCLR, tay and save 4 cycles as well:

 

KernelDefault:
	...

    sleep 7         ; 7 60
    ldx #DS_PFCLR
    nop             ; 4 64
    ldy #DS_BKCLR
    nop             ; 4 68
    
    
    lda #DS_P0CLR   ; 2 70
    sta COLUP0      ; 3 73
    jmp FASTJMP     ; 3 76

 

This would up the lda #/sta # ratio a bit.  I wrote Turbo before this feature was available so that explains why I'm not using it (yet)   

[+SpiceWare]

51 minutes ago, johnnywc said:

Of course you could just modify the .bin directly and save 4 bytes (or how much ROM that assignment takes up), but this is much easier to do.   I assume you could have done the same to update the driver to enable/disable LDX LDY FF as well (at the cost of some more ROM for the assignment).  

 

Correct, could have modified the .bin directly, or done the same with LDX/Y in the Initialize routine. 

 

Part of what's up is this is an early attempt at a CDFJ+ framework with the ultimate goal of the same framework working in Linux, Mac, and Windows.  This was a decision of using less space in the final game ROM vs complexity of the framework.

 

Eventually I'd like to have the makefile hex-edit the CDFJ+ driver somehow, so would only need 2 versions of the driver (one for 32K, other for 64K+) and no driver modifications would occur in Initialize(). But I'm not there yet.

 

51 minutes ago, johnnywc said:

do you know why Stella 6.6 can't run a CDFJ+ game like Gorf, even if it doesn't use LDX, LDY FF and has a DD offset of 0?

 

I don't know - the initial CdFJ+ support was added in 6.3. I see this in CartridgeCDF::setupVersion()

 

  if ((cdfjOffset = scanCDFDriver(0x53554c50)) != 0xFFFFFFFF && // Plus
      getUInt32(myImage.get(), cdfjOffset+4) == 0x4a464443 &&   // CDFJ
      getUInt32(myImage.get(), cdfjOffset+8) == 0x00000001) {   // V1
    myCDFSubtype = CDFSubtype::CDFJplus;
    myAmplitudeStream = 0x23;
    myFastjumpStreamIndexMask = 0xfe;
    myDatastreamBase = 0x0098;
    myDatastreamIncrementBase = 0x0124;
    myFastFetcherOffset = 0;
    myWaveformBase = 0x01b0;

    for (int i = 0; i < 2048; i += 4)
    {
      const uInt32 cdfjValue = getUInt32(myImage.get(), i);
      if (cdfjValue == 0x135200A2)
        myLDXenabled = true;
      if (cdfjValue == 0x135200A0)
        myLDYenabled = true;

      // search for Fast Fetcher Offset (default is 0)
      if ((cdfjValue & 0xFFFFFF00) == 0xE2422000)
        myFastFetcherOffset = i;
    }

    return;
  }

 

 

And that appears to match what I see in the last commit before 6.6 was released in November 2021.

 

Maybe that IF is failing for some reason, which would cause CDFJ+ to not work. Check GORF to see if 0x53554c50 in the driver is immediately followed by 0x4a464443 then 0x00000001

[+SpiceWare]

25 minutes ago, johnnywc said:

You would only typically change this either once on Initialize like Darrell does or hack the actual driver using a binary editor. 

 

Probably be easier for StellaDS' optimization if the driver was always hacked instead of modified during Initialize().

 

My framework is not being used by anyone yet, so I'll switch gears and initially just target Linux and have the makefile hexedit the ROM.

[+wavemotion]

23 minutes ago, SpiceWare said:

Maybe that IF is failing for some reason, which would cause CDFJ+ to not work. Check GORF to see if 0x53554c50 in the driver is immediately followed by 0x4a464443 then 0x00000001

I can say for sure that if() is the same code I'm using in StellaDS and it detects that GORF is using a fast fetcher offset of 3E0 and can also say for sure that ARM RAM location 3E0 is always zero and so to the emulators it looks like GORF has an offset (and that offset happens to be zero).

[+johnnywc]

40 minutes ago, SpiceWare said:

 

Correct, could have modified the .bin directly, or done the same with LDX/Y in the Initialize routine. 

 

Part of what's up is this is an early attempt at a CDFJ+ framework with the ultimate goal of the same framework working in Linux, Mac, and Windows.  This was a decision of using less space in the final game ROM vs complexity of the framework.

 

Eventually I'd like to have the makefile hex-edit the CDFJ+ driver somehow, so would only need 2 versions of the driver (one for 32K, other for 64K+) and no driver modifications would occur in Initialize(). But I'm not there yet.

Cool, yes I agree that making the framework less complex is important.   I agree that hex editing the driver would be the best solution (and still retain the simplicity in the framework) so hopefully you can manage to get it work!   I can take a peek as well if you need help with the Windows version.

40 minutes ago, SpiceWare said:

 

I don't know - the initial CdFJ+ support was added in 6.3. I see this in CartridgeCDF::setupVersion()

 

  if ((cdfjOffset = scanCDFDriver(0x53554c50)) != 0xFFFFFFFF && // Plus
      getUInt32(myImage.get(), cdfjOffset+4) == 0x4a464443 &&   // CDFJ
      getUInt32(myImage.get(), cdfjOffset+8) == 0x00000001) {   // V1
    myCDFSubtype = CDFSubtype::CDFJplus;
    myAmplitudeStream = 0x23;
    myFastjumpStreamIndexMask = 0xfe;
    myDatastreamBase = 0x0098;
    myDatastreamIncrementBase = 0x0124;
    myFastFetcherOffset = 0;
    myWaveformBase = 0x01b0;

    for (int i = 0; i < 2048; i += 4)
    {
      const uInt32 cdfjValue = getUInt32(myImage.get(), i);
      if (cdfjValue == 0x135200A2)
        myLDXenabled = true;
      if (cdfjValue == 0x135200A0)
        myLDYenabled = true;

      // search for Fast Fetcher Offset (default is 0)
      if ((cdfjValue & 0xFFFFFF00) == 0xE2422000)
        myFastFetcherOffset = i;
    }

    return;
  }

 

 

And that appears to match what I see in the last commit before 6.6 was released in November 2021.

Hmm, I think I'm confused.  The last commit before 6.6 link you showed me doesn't have any of the code for LDX/LDY or FF offset detection, correct?  So it *doesn't* match what you have above, which I assume is from v6.7?  

40 minutes ago, SpiceWare said:

Maybe that IF is failing for some reason, which would cause CDFJ+ to not work. Check GORF to see if 0x53554c50 in the driver is immediately followed by 0x4a464443 then 0x00000001

I checked and it does contain those bytes at offset 0x184.   Hmm, no worries I'll just have to wait for the 6.7 version of Stella for R77 to be released.    I'd try to port it myself but I'm not even sure where I would start, and I assume I would need some sort of Linux dev environment.

[+SpiceWare]

38 minutes ago, johnnywc said:

Hmm, I think I'm confused.  The last commit before 6.6 link you showed me doesn't have any of the code for LDX/LDY or FF offset detection, correct?  So it *doesn't* match what you have above, which I assume is from v6.7?  

 

Could have written that better, the perils of getting distracted by the day job

 

I was referring to the detection for CDFJ+ itself being the same, didn't think the new LDX/LDY or FF stuff should matter since you're not using it.

[Thomas Jentzsch]

While I was taking a shower this morning (= waking up) I had this crazy idea. The DSi uses an ARM chip, which here emulates another ARM chips.  Why cannot it not run the Thumb code directly? The idea occurred when I remembered that @DirtyHairy was able to patch earlier ARM games (like Space Rocks) to work with the UnoCart. Which of course is a much simpler task.

 

I know the memory layout is different, so this would have to be adjusted at assembly time. Or the ROM could be adapted at run-time (decoding, analyzing and patching on-the-fly). And then we have 'bx' which would have to return to emulation. Not sure how much of this is feasible.

 

Anything else I am missing? Stupid idea?

[Thomas Jentzsch]

@llabnip I just had a look at your code and how you handle register 15.

 

I wonder why you sometimes do not use FIX_R15_PC. E.g. cmp3 and add4 could both read from registers 0..15. Is that a mistake or am I missing something here?

[+wavemotion]

1 hour ago, Thomas Jentzsch said:

@llabnip I just had a look at your code and how you handle register 15.

 

I wonder why you sometimes do not use FIX_R15_PC. E.g. cmp3 and add4 could both read from registers 0..15. Is that a mistake or am I missing something here?

Good catch! mov3 as well. I fixed those up. Surprised I haven't seen any ill effects from those - though maybe the C compiler doesn't tend to use R15 with those instructions. 

[+wavemotion]

3 hours ago, Thomas Jentzsch said:

Anything else I am missing? Stupid idea?

I had the same idea halfway through this thread. I woke up one night realizing that I'm running an ARM9 processor and could just run the Thumb code directly. Then I realized the memory is not right - and would have to be adjusted. And not sure at all how it plays with the ARM32 interrupts that are happening and then my head started to spin and I decided to go back to sleep. 

[Thomas Jentzsch]

1 hour ago, llabnip said:

Then I realized the memory is not right - and would have to be adjusted.

Yup. That looks like the most complicated part to me. But there is a good change that I am missing something.

1 hour ago, llabnip said:

And not sure at all how it plays with the ARM32 interrupts that are happening...

AFAIK the emulated ROM code does not use any interrupts. And the DSi interrupts shouldn't interfere any more than they already do, no?

[+wavemotion]

19 minutes ago, Thomas Jentzsch said:

 And the DSi interrupts shouldn't interfere any more than they already do, no?

I don't know... you're probably right.

 

I've got a laundry list of things to work on and getting native Thumb support is on it... but it's way down.

 

I need to fix the sound in the fast music fetchers for Draconian and Mappy. That's going to take some effort.

 

I did just fix the NTSC palette having now borrowed the mainline Stella 6.7 NTSC default NTSC palette. My reds were way too purple - Gorf now looks right.

 

[+johnnywc]

6 hours ago, llabnip said:

I need to fix the sound in the fast music fetchers for Draconian and Mappy. That's going to take some effort.

 Looking forward to this!  

6 hours ago, llabnip said:

I did just fix the NTSC palette having now borrowed the mainline Stella 6.7 NTSC default NTSC palette. My reds were way too purple - Gorf now looks right.

 

Cool!  I was wondering why my Lady Bug was purple and not red.  

[+SpiceWare]

On 11/30/2022 at 8:28 PM, llabnip said:

 

But Champ Games tends to utilize 208 pixel lines which means there are 16 pixel lines that get cut off. 

 

Incentive for a 3DS build! With its 800x240 display you could show all vertical pixels, even for PAL, and do a nice 4x to the horizontal 160 for consistent pixel size (5x fits, but would be the wrong aspect ratio).  😉

 

 

[+wavemotion]

20 minutes ago, SpiceWare said:

 

Incentive for a 3DS build! With its 800x240 display you could show all vertical pixels, even for PAL, and do a nice 4x to the horizontal 160 for consistent pixel size (5x fits, but would be the wrong aspect ratio).  😉

 

The only thing I know how to do on a 3DS  is play Pokemon Back/White

 

In other news... I did my first experiment with a Tia-Process-Sound-Every-Scanline and there is good news and bad news. The sound is pretty good ... not perfect but there's actual music in Stay Frosty 2 - who knew?!  (yeah, I knew).  The bad news is that it comes with a 5% performance hit that I need to sort out. At worst I can have two audio drivers - one for fast-fetching-music and the default one for background sampling (which works great for traditional bleeps and bloops). 

 

It was nice to hear ALERT! ALERT! and the background music in Mappy. The sound still has a few small/light crackles. As if you're listening to the music on a record player... but it's miles better than where it was.

Edited December 4, 2022 by llabnip

[+wavemotion]

Ok... StellaDS 6.1e is checked in.  The e is coincidental but really should mean 'experimental sound driver'

 

This is the first version to support the 'WAVE/DIRECT' (for lack of a better name... I'll come up with something better) sound for games using fast-fetch music or really any sort of direct volume mode of the TIA.

 

For any game you wish to try this new experimental sound driver, you must change the Sound Quality configuration to 'WAVE DIRECT' then Save the settings and reload the game. 

 

Draconian, Mappy and Stay Frosty 2 are at least not an embarrassment for this little emulator-that-could!

 

Feedback of any kind for the sound on those 3 games would be welcome.  I need to add back in the music fetchers in original DPC for Pitfall II (I stripped them out last year to gain speed given that they sounded terrible ... but I have the speed now and the new sound driver should render it semi-correctly).

 

Sadly, I had to change the config info so if you're mapped keys or screen offsets, those will get wiped. But I future-proofed it a bit so I shouldn't have to do that anytime in the near future. Sorry!

[+SpiceWare]

15 minutes ago, llabnip said:

Draconian, Mappy and Stay Frosty 2 are at least not an embarrassment for this little emulator-that-could!

 

Nice, I changed all three to WAVE DIRECT and the difference is astounding.  Well done!

 

WAVE DIRECT seems to help for Open Sesame, and helps just a little bit for Quadrun.

[+wavemotion]

8 hours ago, SpiceWare said:

 

Nice, I changed all three to WAVE DIRECT and the difference is astounding.  Well done!

Thanks! Look, I know StellaDS isn’t going to win any technical awards for sound reproduction - but not bad for the old handheld (the DS is now old enough that you can emulate a DS running the StellaDS emulator). 
 

8 hours ago, SpiceWare said:

WAVE DIRECT seems to help for Open Sesame, and helps just a little bit for Quadrun.

I have the old Stella bug with Quadrun screeching so one of the sound channels is disabled. I’ll re-enable and scour the Stella changes to fix the issue once and for all. 

 

 

I now default a number of games to use the WAVE DIRECT handling... including Frosty 2, Draconian(RC8) and the Mappy Demo.  Most users don't RTFM so I try to detect and apply sensible defaults when possible. The Mappy full ROM will be customized per-buyer so a user will have to turn on WAVE DIRECT unless I can detect it somehow (I assume via a pile of LDA/STA to the Waveform Base?). 

 

I'm fixing Pitfall II background music now.

Edited December 4, 2022 by llabnip

[+wavemotion]

Ok... 6.1f is checked in with the Pitfall II background music restored. It's scratchier than any of the  DPCPlus or CDF/J music fetcher games... that might be because StellaDS is struggling to keep up the frame rate on that one. Or that StellaDS is only mostly cycle accurate (where mainline Stella pretty much nails the cycles but at a performance cost I can't pay). But the sound on these games is far better than it was. 

 

I re-enabled full sounds on Quadrun for the new DIRECT WAVE driver and the 'Quadrun Quadrun Quadrun' plays but it's too fast. Otherwise it seems to work and sound fine. 

 

Fast Music Fetchers in DPC+ and CDF/J/+ games, however, sound quite good. Overall this is a win and keeps moving StellaDS in the right direction. 

 

[+wavemotion]

As I get ready to release StellaDS 6.2 I want to leave this here since there are only three things you can count on in life:

1. Death
2. Taxes
3. Someone will find this thread on Atariage in 20 years and want to know how to run Mappy properly on their 35 year old Nintendo Handheld.

These are the settings I use for Mappy.  This allows the entire playfield to be displayed with the X button (which I find very comfortable to tap when playing) to temporarily scroll up to see the score.

 

The HBLANK and VBLANK are not strictly necessary but this game does not require that either be truly "blanked" (saving the memset() call) to look correct. This buys us a frame or two of performance.

 

The sound here is changed to WAVE DIRECT to utilize the new driver for the fast fetcher music. 

 

 

 

I've also added 3 internal palettes (well 6x if you count the PAL versions).  

 

• Stella Default
• Z26 Default
• DS Optimized

After switching to Stella Default in the last build, there was something just ... missing for me in the output on the DS LCD. The greens were muted. The yellow/orange was just a tad pale. I remembered Pitfall being more vibrant green. And Chopper Command being a bit more orange-y background.   So I've built a DS Optimized palette which has no scientific basis and is reasonably close to the Stella Default but makes the colors pop a bit closer to the way I remember them in 1980 on our old wood console TV (the thing was like a piece of furniture - we had a lamp on top and all kinds of nick-nacks... must have weighed 300 pounds and left an indelible impression on the too-long carpet).

 

Edit: I do realize Stella has nice TV filters built in to replicate what I remember as a youth. With StellaDS, I can't take that kind of performance hit so any nostalgia must be recreated with tables. 

Edited December 5, 2022 by llabnip

[+SpiceWare]

From known issues:

Quote

Cherity music fetchers are incomplete and the background music will not play correctly (game is otherwise fine to play).

 

I added support to Stella for Cherity's music at some point, looks like it was in Sep 2018.  I also see some later bug fixes that might be important, like this one.

[+wavemotion]

41 minutes ago, SpiceWare said:

From known issues:

 

I added support to Stella for Cherity's music at some point, looks like it was in Sep 2018.  I also see some later bug fixes that might be important, like this one.

Nice! I'll add that to my near-term list of things to improve for StellaDS.

 

In case I didn't say it before, I do really appreciate the support you've shown StellaDS (and @johnnywc).  I honestly think you guys spending some time here talking about various things has actually boosted sales!  I've got at least 10 new users from AA using the platform... let's see... at $0 a head... carry the one... well, I guess I can't retire yet  

[ClassicGMR]

4 hours ago, llabnip said:

well, I guess I can't retire yet

Just wait ... when I hit the lottery ... WHAM-O!

[edweird13]

When I saw you had an emu for the INTV, 7800 and 2600 I went to my sons house and borrowed his DSi XL. Thanks for your hard work.

 

Now if someone would just update the emus for the PSP......

[Asaki]

On 12/5/2022 at 8:46 AM, llabnip said:

After switching to Stella Default in the last build, there was something just ... missing for me in the output on the DS LCD. The greens were muted. The yellow/orange was just a tad pale. I remembered Pitfall being more vibrant green. And Chopper Command being a bit more orange-y background.   So I've built a DS Optimized palette which has no scientific basis and is reasonably close to the Stella Default but makes the colors pop a bit closer to the way I remember them in 1980 on our old wood console TV (the thing was like a piece of furniture - we had a lamp on top and all kinds of nick-nacks... must have weighed 300 pounds and left an indelible impression on the too-long carpet).

It depends on which handheld you're using: I'm not sure about DSi, but I know the DS Lite uses RGB colorspace for the screens (or something awfully close to it), while the DS Phat's colorspace is very similar to the GBA Micro, but a little more washed out (and sort of the GBA and the non-101-SP). 3DS in DS mode will simulate something very close to Phat colorspace.

 

I don't know if any games were released to take advantage of DS Lite colorspace (the main reason I got rid of my Lite), but Ghostbusters is the only game I've played that had an option to change palettes.