Star Rider PIF board completely emulated and disassembled

I've been continuing to reverse engineer the Star Rider PIF board and I think I'm basically done.  There is only one command that I don't understand and it appears to be entirely software-related so both Daphne and Dexter can support it without me understanding what it does or how it works.

Here's my wiki page with all of my notes: https://www.daphne-emu.com:9443/mediawiki/index.php/StarRiderNotes

An interesting I learned today: The STAND BY line actually flashes, which I never supposed.  Here is the function that waits for STAND BY to stop flashing:

ROM:FA75 WaitForStandByToStopBlinking:           ; CODE XREF: PR8210A_PLAY+39 P
ROM:FA75                                         ; PR8210A_REJECT+1D P ...
ROM:FA75                 pshs    cc,a,b
ROM:FA77                 orcc    #$10            ; disable IRQ'
ROM:FA79                 jsr     Sleep150Ms      ; sleeps for 150,208 cycles (from before the function is called til after it has returned)
ROM:FA7C                 lda     #$20 ; ' '
ROM:FA7E                 bita    PIA_B_DATA      ; test STAND BY
ROM:FA81                 beq     WhileStandbyIsHigh ; branch if STAND BY is inactive
ROM:FA83                 jsr     Sleep150Ms      ; sleeps for 150,208 cycles (from before the function is called til after it has returned)
ROM:FA86                 bita    PIA_B_DATA
ROM:FA89                 beq     WhileStandbyIsHigh ; This code checks to make sure that standby does not come active again after it sees that it was inactive.
ROM:FA89                                         ; If standby does come active again, this code will block indefinitely until it becomes inactive again.
ROM:FA89                                         ; (it is designed to check to make sure blinking activity has ceased)
ROM:FA8B                 jsr     Sleep150Ms      ; sleeps for 150,208 cycles (from before the function is called til after it has returned)
ROM:FA8E                 bita    PIA_B_DATA
ROM:FA91                 beq     WhileStandbyIsHigh ; This code checks to make sure that standby does not come active again after it sees that it was inactive.
ROM:FA91                                         ; If standby does come active again, this code will block indefinitely until it becomes inactive again.
ROM:FA91                                         ; (it is designed to check to make sure blinking activity has ceased)
ROM:FA93                 lda     #$86 ; 'å'      ; #$86 means that stand by has not gone inactive after a reasonable amount of delay
ROM:FA95                 jmp     OnFatalError    ; Everything here might be diagnostic type stuff or error code reporting type stuff
ROM:FA95                                         ; code 0x80 means CRC check failed
ROM:FA95                                         ; code 0x81 means RAM test failed
ROM:FA95                                         ; code 0x82 means IRQ test failed
ROM:FA95                                         ; code 0x85 means syncing to vsync/field failed
ROM:FA95                                         ; code 0x86 means STAND BY never went low before going high/low again
ROM:FA95                                         ; code 0x87 means we got an invalid FIRQ command
ROM:FA95                                         ; code 0x88 means we ran out of space in our array at 0x300 (see F2C5)
ROM:FA98 ; ---------------------------------------------------------------------------
ROM:FA98 
ROM:FA98 WhileStandbyIsHigh:                     ; CODE XREF: WaitForStandByToStopBlinking+C j
ROM:FA98                                         ; WaitForStandByToStopBlinking+14 j ...
ROM:FA98                 ldb     #$FF            ; This code checks to make sure that standby does not come active again after it sees that it was inactive.
ROM:FA98                                         ; If standby does come active again, this code will block indefinitely until it becomes inactive again.
ROM:FA98                                         ; (it is designed to check to make sure blinking activity has ceased)
ROM:FA9A 
ROM:FA9A WhileBIsLessThan10:                     ; CODE XREF: WaitForStandByToStopBlinking+30 j
ROM:FA9A                 incb
ROM:FA9B                 jsr     Sleep50Ms       ; this delays for 49,993 cycles (from $FA16 until the last RTS has finished)
ROM:FA9B                                         ; So about 50 milliseconds
ROM:FA9E                 bita    PIA_B_DATA      ; test STAND BY
ROM:FAA1                 bne     WhileStandbyIsHigh ; branch if STAND BY line is high
ROM:FAA3                 cmpb    #$A
ROM:FAA5                 blt     WhileBIsLessThan10
ROM:FAA7                 puls    b,a,cc
ROM:FAA9                 rts
ROM:FAA9 ; End of function WaitForStandByToStopBlinking

It may look super confusing but it's as clear as it's going to get :)

I still need to know when the FIELD and 4MS inputs come into the PIF board relative to the LM1881's vsync before I can know for sure how to make Dexter support this player.

More MACH3 testing from Warren

From the chat room tonight, Warren reports:

<Warren_O> some mostly good news to report...
<Warren_O> the boosted file still didn't work, even though it measured 0.220-0.230V... but... if I run the audio through a cassette deck to boost the level, it works great
<Warren_O> I think the measured voltage level is greatly affected by frequencies like the 60 Hz static in analog LD audio, so it isn't giving me an accurate representation
<Warren_O> so I've at least determined that it *is* possible to get a low audio error rate with dexter
<Warren_O> we just need to do some more testing and adjusting to get it right
<Warren_O> I need to make sure I'm getting as much output from the Pi as possible (right now it's using an old raspbian image from CAX, in which the mixer doesn't seem to work right)
<Warren_O> and then need to filter/eq/maximize the mach3 audio to get it as close to original as possible
<Warren_O> if that's not enough, we may need an op-amp stage to boost the level
<Warren_O> but I will worry about that later if it becomes necessary

What he is saying is that the Raspberry Pi seems to be outputting too weak of an audio signal (by itself) for MACH 3's hardware to pick up the target data on the audio channel.  There are 3 things we can do to fix this: a) increase the audio to maximum level inside the laserdisc image file itself (he already tried this), b) crank the Pi's audio output to its maximum strength (we don't yet know if we have any mixer that the pi offers cranked up), c) add an audio amplifier to the Dexter board to force the audio to the correct level.

We will prefer to avoid 'c' if we can help it since it will add to the cost and complexity of the board.  But we'll do it if that's what it takes.  The good news is he verified that with the correct audio level, MACH 3 can read the target data properly which is a huge win for MACH 3 owners everywhere :)

Warren also tested with the VBI Injector board to see if MACH 3 could pick up the frame numbers.  Unfortunately, I had a bug in the latest firmware which caused the "white flag" to always be drawn and it turns out that MACH 3's hardware relies on the white flag _never_ being drawn.  I've done a quickie fix but can't test it from my present location.

All in all, things are looking very promising.

More MACH 3 and Star Rider

Warren got his MACH 3 hardware powered up.  In his words " it boots, runs, and passes the frame and audio decoder tests with my 8210."  Rumors are that he will test Dexter with VBI frame number injection next.

I know in my last blog post I said I wasn't going to keep digging  into Star Rider but I changed my mind.  The digging continues.  I've disassembled a vast majority of the PIF board ROM.  Some sections remain unclear so I am going to try emulating just this board to decipher what the remaining functions mean.

MACH 3, Cliff Hanger, and Star Rider

Sorry for the big interval since my last post.

I've ordered 3 more VBI Injector boards from OSHPark.com and they should be here this week (or next week).  I will then send two of them out to testers who are able to further test MACH 3 and test Cliff Hanger.  Warren also has ordered a PCB from OSHPark.com to help him power his MACH 3 boardset so he will be testing that game soon too.

In the mean time, I've been digging into the Star Rider schematics, specifically the PIF board, to try to understand when it lowers the PR-8210A's "JUMP TRIGGER" line relative to VSYNC.  I've pretty much decoded the entire schematic for the PIF board and documented the memory map.  I'm kinda getting derailed from moving forward making a rev3 Dexter board though, so I think I won't keep continuing down this path until after the rev3 boards are made.  I think I know enough about how Star Rider uses the PR-8210A to have the board made without the software being written.