6502 'Ghost Read' Triggering HW

[+wavemotion]

So in my quest to streamline my port of Stella for the DS, I've stumbled upon the 6502 "Ghost Reads" (if there is a better term, let me know - that's mostly what I see when searching Stella issues and a bit of discussion here on AtariAge).

 

For example, 6502 instruction 75h is ADC zeropage X.

 

In Stella, to get the operand is as follows:

 

case 0x75:  // ADC zpg,X
{
  intermediateAddress = peek(PC++, DISASM_CODE);
  peek(intermediateAddress, DISASM_NONE);
  intermediateAddress += X;
  operand = peek(intermediateAddress, DISASM_DATA);
}

 

The highlighted line is a sort of "ghost read" - the result of which is not used. In this case (as with many of the addressing modes), the read likely triggers nothing as it will always be in the lower 100h bytes (so RAM or TIA read). In theory a few bankswitching schemes could trigger here... 3E and 3F and relatives come to mind.

 

My question is this... are there any known games that rely on a "ghost read" triggering something like a bankswitch?

 

I ask (for a friend!) because these are sources of extra precious emulation cycles that I'd like to potentially eliminate and upon doing so (replacing with a dummy routine that just bumps the cycle count... essentially a 'fake_peek'), I haven't seen any ill effects other than a bit more efficiency for the emulator.

 

I realize not doing the "ghost read" (but still compensating for the cycle count) is not accurate... my question is whether it's mostly safe to do so.

 

Thanks in advance - you guys are a fount of knowledge!

 

[Thomas Jentzsch]

This is mainly emulated for developers. And as long as Stella's debugger has not been used, the setting is ignored.

[+SpiceWare]

I don't know if anything relies on it, though I think the ARM enhanced routines have logic in them due to it.

 

Looking at peek() in CartCDF.cxx:

 

  ; lines 280 - 286
  if (myFastFetcherOffset)
    fastfetch = (FAST_FETCH_ON(myMode) && myLDAXYimmediateOperandAddress == address
                 && peekvalue >= myRAM[myFastFetcherOffset]
                 && peekvalue <= myRAM[myFastFetcherOffset]+myAmplitudeStream);
  else
    fastfetch = (FAST_FETCH_ON(myMode) && myLDAXYimmediateOperandAddress == address
                 && peekvalue <= myAmplitudeStream);

  ; lines 369 - 375
  if (FAST_FETCH_ON(myMode))
  {
    if ((peekvalue == 0xA9) ||
        (myLDXenabled && peekvalue == 0xA2 ) ||
        (myLDYenabled && peekvalue == 0xA0))
      myLDAXYimmediateOperandAddress = address + 1;
  }

 

 

If I remember correctly: The test of myLDAXYimmediateOperandAddress == address and the setting of myLDAXYimmediateOperandAddress = address + 1; were done to make sure a ghost read didn't trigger a Fast Fetch, which would crash the program.  The ARM driver has similar logic for the Harmony/Melody.

 

If that's correct, then if you eliminate the ghost reads you should be able to do something like this, which might be faster:

  bool myFastFetch{false};   <-- replaces uInt16 myLDAXYimmediateOperandAddress{LDAXY_OVERRIDE_INACTIVE}; in the header 
    
    

  ; lines 280 - 286
  if (myFastFetcherOffset)
    fastfetch = (FAST_FETCH_ON(myMode) && myFastFetch
                 && peekvalue >= myRAM[myFastFetcherOffset]
                 && peekvalue <= myRAM[myFastFetcherOffset]+myAmplitudeStream);
  else
    fastfetch = (FAST_FETCH_ON(myMode) && myFastFetch
                 && peekvalue <= myAmplitudeStream);

  ; lines 369 - 375
  if (FAST_FETCH_ON(myMode))
  {
    myFastFetch = ((peekvalue == 0xA9) ||
        (myLDXenabled && peekvalue == 0xA2 ) ||
        (myLDYenabled && peekvalue == 0xA0));
  }

 

 

There's probably similar logic for the Fast Jump feature.

[Kroko]

Not implementing ghost reads means that your emulator is not doing what some (most?) cartridge hardware would do. It is probably not a problem for already existing games, but if somebody wants to use your emulator to check if his program is going to work on real hardware, he might not see the issue until he actually builds the hardware and plugs it in.

So I think it is a good feature for homebrewers that emulators implement ghost reads. If you just want to replay existing games then I guess it might be less important.

[+wavemotion]

3 minutes ago, Kroko said:

Not implementing ghost reads means that your emulator is not doing what some (most?) cartridge hardware would do. It is probably not a problem for already existing games, but if somebody wants to use your emulator to check if his program is going to work on real hardware, he might not see the issue until he actually builds the hardware and plugs it in.

Fair point - however, my big disclaimer in the StellaDS emulator (source files and readme) is that it's gone out of its way to not bring in the amazingly high-level of emulation accuracy of mainline Stella. In order to run the majority of games on the little 67MHz handheld (134MHz for the DSi and 2DS/3DS in compatibility mode), some safeguards have been removed. I was mostly wondering if this particular bit of emulation accuracy would be missed ... it buys me almost two frames of performance and that's not easy to come by.

 

29 minutes ago, SpiceWare said:

I don't know if anything relies on it, though I think the ARM enhanced routines have logic in them due to it.

Thanks Darrell. I haven't seen any ill effects and the speedup helps both on ARM-assisted games and games that were marginally close to 60fps on the older DS handhelds.  My biggest fear is that someone is relying on these ghost reads to trigger something and that removing the emulation logic will have an adverse affect but it's hard to imagine anyone designing their code to specifically take advantage of it.  But what do I know  

[Thomas Jentzsch]

I wouldn't worry about them.