Thursday, August 17, 2017

How to test whether Dexter is working properly with Star Rider

Star Rider is an overly complicated system and has many points of potential failure.  How can one test whether Dexter is to blame for problems with one's Star Rider game?

Fortunately, Williams included some nice built-in diagnostic tools in Star Rider.  To access it, press the ADVANCE button during the red 'moire' test (shown below), or any point thereafter during the attract mode.  Make sure the AUTO-UP/MANUAL-DOWN switch is in the DOWN position when doing this.  Both of these controls are supposedly inside of the coin door on a real cabinet but I've never had access to a real cabinet, so I am only going off what I've heard.

Press ADVANCE once you see this screen to get into the diagnostics screens.

The first test that comes up is the ROM test.  The board on the left is the ROM board that sits on top of the VGG board.  If all of the ROMs are failing, check the ribbon cable going from the ROM board to the VGG board.  Also check the two PROMs on the VGG board as they need to be good in order for these ROMs to be correctly read by the CPU.

The board on the right is the CPU board.  If any of these 5 tests fail, do not even bother continuing as nothing else is likely to work if you have CPU ROM read problems.

There are several more tests before the disc test: RAM test (uses rug pattern, failures here may be non-fatal or fatal depending on whether it's bad video RAM or CPU RAM), CMOS test (tests battery backed up RAM, failures here may be non-fatal), sound test (a missing or defective sound board will cause this test to not allow you to advance to the next test without spamming the ADVANCE button for about 30 seconds), and input test (steering mechanism, brakes, turbo, throttle, etc).

None of these aforementioned tests will tell you anything about Dexter so examine them at your leisure.

After the input test, hold down advance to get to the DISC TEST.  Make sure the AUTO-UP/MANUAL-DOWN switch is in MANUAL mode.

The four tests on the DISC TEST screen are controlled using the AUTO-UP/MANUAL-DOWN switch.  When in manual mode, the same test will execute over and over again.  When in auto mode, each test will execute in sequence one time.  I prefer a combination of the two: going into auto mode just long enough to advance to the next test, then switching back to manual mode.

Reset response test: This tests the communication from the VGG board to the PIF board.  It has nothing to d with whether Dexter is operational.  If this test fails, your game will not work period because it will not be able to talk to Dexter.  There are many points of failure that could cause this test to fail, but in my experience, a bad or unreliable PIF ROM is the #1 culprit.  The next thing I would check is the cable going from the PIF board to the VGG board.  I have yet to see a bad PIA6821.  Again, if this test fails, it's I/O from the VGG board to the PIF board, and so Dexter is not the cause of this problem.

The walking bit test is similar to the Reset Response test.  It tests communication from the VGG board to the PIF board.  It tests each of the 8 data bits one by one to make sure each bit is working properly.  If this test fails, it's a problem somewhere from the CPU/VGG to the PIF board, not Dexter.

The third test is the SEARCH TO test.  This test does test Dexter's ability to receive and execute search commands from the PIF board.  This test _does_ test whether Dexter is working properly.  If this test occasionally fails, it may be because you have not performed my PIF ROM modification yet (only needed for Dexter rev 3f, which is an older version!).  Other reasons for this test failing are the VGG board not being able to correctly decode picture numbers from the video stream that Dexter generates, but this is just theoretical as I haven't actually seen a VGG board with this defect (yet).

Last but not least is the STEP DISC test.  This test checks to see whether the PIF board can run the laserdisc player in a variable speed manner, which is what the game needs to do in order to make your 'motorcycle' accelerate.  I've never seen this test fail if the SEARCH TO test is passing.  If it is failing but SEARCH TO is passing, then I would suspect that it's not Dexter's fault but instead a hardware defect on the VGG board or PIF board somewhere.  Like I said, there are many things that can fail to cause the whole system to break.




Whether your motorcycle gives hope to the helpless is in your hands... good luck.  Oh wait, wrong game!

Tuesday, August 15, 2017

Star Rider now working in Dexter (with a ROM mod) !!

UPDATE: This mod is only necessary for Dexter rev 3f.  Dexter rev 3g (or later versions) does not need it!

TLDR: Star Rider will work with Dexter as it is today if one is willing to modify the Star Rider PIF ROM slightly.  Original EPROM is "AMD AM2732DC", I've successfully used a 2732A.






The Details:

My goal with Dexter is to never make users have to modify their hardware.  I want Dexter to be a drop-in replacement.  However, I don't think I am going to be able to do it in this case without a new revision of the Dexter hardware.  Even then, this modification may also be a wise choice for people who may be using a real PR-8210A laserdisc player and/or arcade operators who don't have time to restart games which are too fussy and crash easily.

Inside the PIF ROM, here is the function that performs a laserdisc search:

ROM:F69B PR8210A_SEARCH:                         ; CODE XREF: ROM:FCBA P
ROM:F69B                                         ; DATA XREF: ROM:F048 o ...
ROM:F69B                 pshs    cc,a,b,x
ROM:F69D                 lda     #3
ROM:F69F                 sta     LastCallbackCmd ; Last callback we executed (only a handful keep track here).
ROM:F69F                                         ; FF: IRQ should do timer test, nothing else
ROM:F69F                                         ; 1: PLAY was called (f5af)
ROM:F69F                                         ; 3: SEARCH callback was called, either by cmd in 0x300 or from FIRQ command 03
ROM:F69F                                         ; 4: jump trigger count does not get cleared after jump trigger is sent (FIRQ cmd 4 received)
ROM:F69F                                         ; 18: No cmd executed yet (or NOP) - IRQ jump triggers disabled, even when on IRQ count 8 (see FD2D)
ROM:F69F                                         ; 1B: disc is in default paused state after IRQ test is finished, jump triggers are active (f564)
ROM:F6A1                 lda     PIAB_PolicyActive ; Holds byte that should be output to PR-8210A PIA port B whenever we aren't in the middle of an operation
ROM:F6A3                 sta     PIA_B_DATA
ROM:F6A6                 orcc    #$10            ; disable IRQ'
ROM:F6A8                 clra
ROM:F6A9                 clrb
ROM:F6AA                 std     SlowTimer       ; This appears to be a timer that increases very slowly (or not at all)
ROM:F6AA                                         ; Can get increased by IRQ
ROM:F6AA                                         ; written by FD68
ROM:F6AC                 clr     UnknownSlowTimerHelper ; gets a variation of what was stored in $43
ROM:F6AE                 std     Cmd04MysteryWord ; may get modified by ChangePlaybackDirection function (F771)
ROM:F6AE                                         ; may have something to do with playback speed
ROM:F6AE                                         ; If high bit is set, playback direction is reverse, otherwise it's forward.
ROM:F6B0                 clr     HowManyJmpTriggersToSend ; This value determines how many jump triggers the IRQ will send at once.
ROM:F6B0                                         ; 0: none
ROM:F6B0                                         ; 1: one
ROM:F6B0                                         ; 2: two
ROM:F6B0                                         ; 3: three
ROM:F6B0                                         ; 4: four
ROM:F6B0                                         ; (no more than 4 is supported)
ROM:F6B2                 clr     HowManyJmpTriggersToSendSrc ; holds jmp trigger count (F78C)
ROM:F6B4                 clr     IsDiscNotPaused ; will be non-zero if PLAY or REJECT command was last issued,
ROM:F6B4                                         ; will be 0 if the STEP FWD/REV (pause) command was last issued.
ROM:F6B6                 ldx     #SearchArrayEnd ; start at memory location 62 (and work backward)
ROM:F6B9                 clr     ,x              ; put 00 terminator at the end so send loop knows when to stop
ROM:F6BB                 lda     #$E8 ; 'F'      ; PR-8210A search command
ROM:F6BD                 sta     ,-x             ; 61 = E8, 60 = E8, 5F = E8
ROM:F6BF                 sta     ,-x
ROM:F6C1                 sta     ,-x
ROM:F6C3                 ldb     #5              ; may indicate 5 digits
ROM:F6C5                 pshs    b
ROM:F6C7                 ldd     [Pointer]       ; load the frame number (unsigned binary format)
ROM:F6CB 
ROM:F6CB DigitLoop:                              ; CODE XREF: PR8210A_SEARCH+35 j
ROM:F6CB                 jsr     Pr8210ALoadLeastSigDecimalDigit ; This call computes the least significant frame number digit (in decimal format),
ROM:F6CB                                         ; converts it to the PR-8210A expected format, then loads it into X-1 3 times.
ROM:F6CB                                         ; It also loads a filler byte (0x80).
ROM:F6CB                                         ; X will be equal to where to put the digit + 1
ROM:F6CB                                         ; the frame number will be in D
ROM:F6CE                 dec     ,s              ; the 'b' that we pushed on earlier, subtract it
ROM:F6D0                 bgt     DigitLoop
ROM:F6D2                 leas    1,s             ; pop off digit loop counter
ROM:F6D4                 lda     #$AC ; '¼'      ; PR-8210A FRAME DISPLAY command
ROM:F6D6                 sta     ,-x
ROM:F6D8                 sta     ,-x
ROM:F6DA                 sta     ,-x
ROM:F6DC                 lda     #$E8 ; 'F'      ; PR-8210A SEARCH command
ROM:F6DE                 sta     ,-x
ROM:F6E0                 sta     ,-x
ROM:F6E2                 sta     ,-x
ROM:F6E4                 jsr     Sleep50Ms       ; this delays for 49,993 cycles (from $FA16 until the last RTS has finished)
ROM:F6E4                                         ; So about 50 milliseconds
ROM:F6E7                 lda     ,x+
ROM:F6E9 
ROM:F6E9 WhileCmdArrayNotAllSent:                ; CODE XREF: PR8210A_SEARCH+56 j
ROM:F6E9                 jsr     Sleep10Ms       ; this method stalls for 10,004 cycles (from the JSR $FA21 until after RTS has completed)
ROM:F6E9                                         ; So about 10 milliseconds
ROM:F6EC                 jsr     SendPR8210ACmdNoFirq ; Sends two leading 0 bits to remote control line,
ROM:F6EC                                         ; then sends 8 bits stored in A, starting with
ROM:F6EC                                         ; bit 7 and shifting left.
ROM:F6EC                                         ; So for example, the play command would be 0xD0
ROM:F6EC                                         ; (1101 0000)
ROM:F6EC                                         ; FIRQ' is always suppressed, IRQ' may or may not be allowed
ROM:F6EF                 lda     ,x+
ROM:F6F1                 bne     WhileCmdArrayNotAllSent ; if we haven't hit the end (memory location 62) keep going
ROM:F6F3                 jsr     WaitForStandByToStopBlinking ; This waits for the STAND BY line to stop blinking.
ROM:F6F3                                         ; (it will also exit if the STAND BY line is held low)
ROM:F6F3                                         ; If it does not go low initially after about 450 milliseconds, the game will error out with code 0x86.
ROM:F6F3                                         ; 
ROM:F6F6                 ldx     Pointer         ; appears to hold pointer to frame number
ROM:F6F8                 leax    2,x             ; Advance to the next pointer in the FRAME NUMBER lookup table.
ROM:F6F8                                         ; This only seems to apply when SEARCH is called via (currently unknown) callback method.
ROM:F6F8                                         ; If it is called from FIRQ cmd, any change to this pointer gets reverted when this function returns.
ROM:F6FA                 stx     Pointer         ; appears to hold pointer to frame number
ROM:F6FC                 lda     ,s
ROM:F6FE                 tfr     a, cc
ROM:F700                 jsr     SyncIrqCounterToVsyncAndField ; Syncs up IRQ counter with vsync/field
ROM:F703                 andcc   #$EF ; 'n'      ; allow IRQ
ROM:F705                 jsr     DisableLeftAndRightAudio ; Disables left/right audio
ROM:F708                 jsr     PR8210A_PLAY_FIRQ_OK
ROM:F70B                 jsr     PrepareDiscPauseViaJmpTrig ; Sets default behavior to pause the disc using 1 jump trigger (in reverse direction) per track
ROM:F70E                 lda     #1
ROM:F710 
ROM:F710 WaitUntilIrqCounterIs1:                 ; CODE XREF: PR8210A_SEARCH+77 j
ROM:F710                 cmpa    IRQCounter      ; Counts how many times IRQ handler has been called.
ROM:F710                                         ; When this value is 8, the IRQ handler may issue JUMP TRIGGERS.
ROM:F710                                         ; This gets called every 4 MS approximately, so the JUMP TRIGGERS will occur
ROM:F710                                         ;  once per frame if they happen at all.
ROM:F710                                         ; 
ROM:F712                 bne     WaitUntilIrqCounterIs1
ROM:F714                 puls    x,b,a,cc
ROM:F716                 rts
ROM:F716 ; End of function PR8210A_SEARCH

Notice at $F6A6, IRQs are disabled, and then they are re-enabled at $F703, right after the internal Irq Counter has synced up with vsync and the current field.  The reason that this needs to happen (IMO) is because during searches, there is no sync, and the game relies on being in sync in order to send jump triggers at the right time.  So it makes sense that after a search, the game would need to go through a period of re-sync.

However, this is where things get inconsistent.

ROM:F880 SyncIrqCountToVsyncEnd:                 ; CODE XREF: SyncIrqCounterToVsyncAndField+33 P
ROM:F880                                         ; SyncIrqCounterToVsyncAndField+54 P
ROM:F880                 pshs    cc,a,b,x
ROM:F882                 andcc   #$EF ; 'n'      ; enable IRQ
ROM:F884                 jsr     Wait20msForVsync ; returns carry clear if vsync can be detected within ~20ms or carry set if timeout happens first
ROM:F887                 lbcs    PrepareToReset  ; prepares state to start the ROM program over from the RESET entry point (ie reboot)
ROM:F887                                         ; NOTE : RESET will clobber the log stored at 0x100 and 0x200
ROM:F88B                 orcc    #$10            ; disable IRQ
ROM:F88D                 lda     #$80 ; 'Ç'
ROM:F88F 
ROM:F88F LoopUntilVsyncIsInactive:               ; CODE XREF: SyncIrqCountToVsyncEnd+12 j
ROM:F88F                 bita    PIA_B_DATA      ; read bit 7 from PR-8210A (VSYNC)
ROM:F892                 bne     LoopUntilVsyncIsInactive ; if bit 7 is set, loop until it's clear (ie until vsync signal is inactive)
ROM:F894                 lda     PIA_B_DATA
ROM:F897                 bita    #$40 ; '@'      ; test bit 6 (FIELD) from PIA B port
ROM:F897                                         ; NOTE : field is expected to be up to date when vsync goes inactive
ROM:F899                 bne     TopField        ; if bit 6 is set, it means field is ODD, and to branch
ROM:F899                                         ; NOTE : I think this branch will always be taken because this subroutine only gets called when the bottom field is active.
ROM:F89B                 lda     #4              ; even field
ROM:F89D                 bra     loc_F8A1

This routine will wait 20ms to see a vsync, which seems reasonable since vsync occurs every 16 ms.  However, it also enables IRQs at $F882!!  This means that it is not uncommon for the IRQ handler to be active when a vsync comes in.

Now on a real PR-8210A, the vsync pulse is quite long, so usually, the IRQ handler exits while vsync is still active.  But on Dexter, this vsync pulse is much shorter which means by the time the IRQ handler exits, vsync is no longer active, and the PIF ROM will reboot, starting at $F887.

The 20 ms timeout is really quite aggressive and I can't see any reason for it (I also can't see any reason to enable IRQs right before waiting for vsync).  I suspect that except on a brand new laserdisc player, this aggressive timeout could cause the game to crash needlessly.

My solution?  Increase the 20 ms timeout to something much larger.

ROM:F95E ; returns carry clear if vsync can be detected within ~20ms or carry set if timeout happens first
ROM:F95E 
ROM:F95E Wait20msForVsync:                       ; CODE XREF: RebootIfVsyncIsNotPresent P
ROM:F95E                                         ; ROM:F659 P ...
ROM:F95E                 pshs    a,b,x
ROM:F960                 ldx     #0
ROM:F963 
ROM:F963 loc_F963:                               ; CODE XREF: Wait20msForVsync+14 j
ROM:F963                 jsr     Wait_122uS      ; Delays about .122 milliseconds (confirmed on real hardware)
ROM:F966                 lda     PIA_B_DATA
ROM:F969                 bita    #$80 ; 'Ç'      ; test VSYNC bit
ROM:F96B                 bne     VsyncDetected   ; branch if vsync is active
ROM:F96D                 leax    1,x
ROM:F96F                 cmpx    #$AA ; '¬'      ; wait 20 ms to see vsync
ROM:F972                 bcs     loc_F963
ROM:F974                 lda     #$94 ; 'ö'
ROM:F976                 jsr     AddToLog        ; This writes a code (stored in A) to a buffer at 0x100, then writes the IRQCounter to a buffer at 0x200.
ROM:F976                                         ; It then appends "END" to the end of the buffer.
ROM:F976                                         ; Subsequent calls will append (ie write to 0x101 instead of 0x100, etc) so that the buffer is actually a log.
ROM:F976                                         ; 
ROM:F976                                         ; I believe the PRE_RESET function checks for a flag that this code writes to RAM and will output it
ROM:F976                                         ; (perhaps via the PR-8210A remote control port?) to an engineer who knew what they were doing could
ROM:F976                                         ; read the log.
ROM:F976                                         ; 0x84: have not received FIRQ command 2 (hello) see f63d
ROM:F976                                         ; 0x89: received FIRQ command 2 (hello) see fca4
ROM:F976                                         ; 0x8B: watchdog counter exceeded limit (IRQ starvation)
ROM:F976                                         ; 0x8D: NMI called (video squelch)
ROM:F976                                         ; 0x8E: REJECT command has succeeded, disc is stopped (not an error) 0xf634
ROM:F976                                         ; 0x90: sanity check failed
ROM:F976                                         ; 0x91: sanity check failed inside IRQ
ROM:F976                                         ; 0x93: $F823 (sync irq counter to field) started
ROM:F976                                         ; 0x94: vsync never detected (f974)
ROM:F976                                         ; 0x95: stand by was raised when it shouldn't have been (f993)
ROM:F976                                         ; 0x96: SWI2 occurred
ROM:F976                                         ; 0x97: SWI3 occurred
ROM:F979                 orcc    #1              ; set carry
ROM:F97B                 bra     IsVsyncPresentReturn
ROM:F97D ; ---------------------------------------------------------------------------
ROM:F97D 
ROM:F97D VsyncDetected:                          ; CODE XREF: Wait20msForVsync+D j
ROM:F97D                 andcc   #$FE ; '¦'      ; clear carry
ROM:F97F 
ROM:F97F IsVsyncPresentReturn:                   ; CODE XREF: Wait20msForVsync+1D j
ROM:F97F                 puls    x,b,a
ROM:F981                 rts
ROM:F981 ; End of function Wait20msForVsync

I changed $F96F so instead of waiting until the counter (stored in X) reaches #$AA, I wait until it reaches #$3FF.  Why #$3FF?  This choice is somewhat arbitrary.  I just picked a value that covers many fields instead of just 1 field.

This change did the trick and now Dexter seems to be working perfectly with Star Rider!  Woohoo!

For those curious, there is a function called at $F963 which sleeps for about .122ms and #$AA is 170 in decimal, and 170 * 0.122 is 20.74 which is where I calculated that this method waits about 20 ms for vsync to appear.

The change to make to the PIF ROM to increase this timeout value:
  • Change address 0x005 from #$F2 to #$4A .  This makes it so the internal checksum test still passes.
  • Change address 0x970 and 0x971 from 0x00 0xAA to 0x03 0xFF

Friday, August 11, 2017

Dexter image quality bug discovered, fix is available now!

I've suspected for a while that something was a little off with Dexter's image quality.  However, this is almost unnoticeable on a CRT, so I haven't prioritized investigating it.  Now that I am trying to finish Star Rider support, which relies on data being decoded from the video signal, I looked into video quality issues further and found a couple of minor problems.

After some troubleshooting, I found that there are two issues with Dexter's image quality:
1) the video is shifted one line from what it should be,
2) the video has an unfocused look

Issue #1 is caused by the raspberry pi itself.  I don't have a "proper" fix, but I can compensate by shifting the video 1 line within the Dexter software which seems to do the trick.

Issue #2 is caused because I am using bilinear filtering inside of the OpenGLES2 code that Dexter is using.  Combined with my shader to implement interlaced video, this was creating a bunch of subtle artifacts that give the unfocused look.  I turned off the bilinear filtering and that did the trick!

I've fixed both of these issues internally and am working on a public fix for everyone.  It will be free for all Dexter customers, new and old.

UPDATE: the fix is live now! :)

Here are two images showing before and after.

Before

After (ignore the extra text)

Please ignore the "Current video line shift" and "Scale factor" text in the second screenshot.  Those are debug messages that I added while troubleshooting this problem.