One of the Dexter PCBs that I was preparing to ship out to customers had a short circuit on it. After using a multimeter to isolate the approximate area that had the short (by observing voltage drop), I could not find any soldering problems. So I used a FLIR C2 infrared camera to help me. After cranking up the current through the VCC power pin to 4 amps to force the short to get hot, here is what the infrared camera was showing (bright yellow is hottest local area):
This is hard to tell what's going on from this blurry image so I've also included a computer generated image with the hot areas high-lighted.
I have now successfully located where the short is by cutting a few traces (I got it wrong the first time, got it right the second time). Can you do better than I and figure out where the short is without "cutting any traces"? Hint, the area that is getting hot is supposed to be just VCC (without a connection to ground). Hint #2, the voltage had dropped substantially on the resistor pad just above the letter 'C' (in CPC1008N) and had dropped to almost 0 on the pad below the 'O' in DIAGNOSE.
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!
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: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
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
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.
In my previous blog post, I mentioned that there is a bug on Esh's Aurunmilla stage 7. The bug is that if you lose all of your lives, the game over screen does not play properly.
The reason for this is that the game over screen starts at picture number 23253, and Esh's mistakenly tells the laserdisc player to autostop once it reaches picture number 23247 which is before the game over section starts.
The incorrect autostop picture number, 23247, is stored as hex 0x5ACF at memory location $215E in the Esh ROM.
There's been some discussion about an Esh's Aurunmilla bug that shows up on stage 7.
Out of curiosity, I dug into the ROM program a little bit to see how hard it would be to modify the program to start on stage 7 to make testing easier. After all, no one wants to play all the way to stage 7 just to test a fix!
I found that the stage value is stored at 0xE424 + whatever value is at 0xE3C1. Here is code at 0x3d06 that prints out the current stage (before each stage):
seg000:3D06 print_current_stage: ; CODE XREF: seg000:3B4C p seg000:3D06 push af seg000:3D07 push bc seg000:3D08 push de seg000:3D09 push hl seg000:3D0A call sub_0_BC7 seg000:3D0D ld a, 1 seg000:3D0F call sub_0_3AAC seg000:3D12 ld b, 1 seg000:3D14 ld hl, stage_number_txt seg000:3D17 call pre_print_text seg000:3D1A ld hl, 0E424h ; prepare to load current stage data seg000:3D1D ld a, (0E3C1h) ; load optional offset seg000:3D20 ld c, a seg000:3D21 ld b, 0 seg000:3D23 add hl, bc ; HL now contains address that contains stage value seg000:3D24 ld l, (hl) ; load stage value into L seg000:3D25 ld h, 0 seg000:3D27 ld b, 14h seg000:3D29 ld c, 0Eh seg000:3D2B ld e, 3 ; 3 digits for the stage number seg000:3D2D seg000:3D2D while_stage_not_printed: ; CODE XREF: print_current_stage+3D j seg000:3D2D push bc seg000:3D2E ld b, 10 ; base 10 conversion seg000:3D30 call hex2dec ; Hex conversion seg000:3D30 ; Src number is in HL. seg000:3D30 ; Base will in B (ie 10 for base 10 conversion). seg000:3D30 ; Returns the lowermost digit in A and HL will be have been divided by the base (ie if HL originally contained 3387 decimal, it will return as 338 decimal with 7 in A). seg000:3D30 ; seg000:3D33 pop bc seg000:3D34 push de seg000:3D35 add a, 30h ; '0' ; convert to ASCII? seg000:3D37 ld d, a seg000:3D38 ld e, 9 seg000:3D3A ld a, 1 seg000:3D3C call print_letter ; prints one letter to the screen seg000:3D3F pop de seg000:3D40 dec b seg000:3D41 dec b seg000:3D42 dec e ; decrement digits left count seg000:3D43 jr nz, while_stage_not_printed seg000:3D45 pop hl seg000:3D46 pop de seg000:3D47 pop bc seg000:3D48 pop af seg000:3D49 ret
The stage value is incremented around 0xD7D: seg000:0D7D loc_0_D7D: ; CODE XREF: seg000:0D6A j seg000:0D7D ; seg000:0D79 j seg000:0D7D ld hl, 0E424h ; base address where current stage lives seg000:0D80 ld a, (0E3C1h) seg000:0D83 and a seg000:0D84 jr z, loc_0_D87 ; this can increment the current stage seg000:0D86 inc hl seg000:0D87 seg000:0D87 loc_0_D87: ; CODE XREF: seg000:0D84 j seg000:0D87 inc (hl) ; this can increment the current stage
The stage value is initially set at:
seg000:0E69 ld hl, 0 seg000:0E6C ld (0E424h), hl ; set current stage to be 0
So to force the game to start on stage 7 instead of 0, one must do this:
Change the "ld hl,0" at 0xE69 to "ld hl,7". Or change 0x21 0x00 0x00 to 0x21 0x07 0x00.
Star Rider has a RAM that was never installed, U7.
If I write to this address, I can trigger my logic analyzer to start capturing exactly where I want it.
But I need to modify the ROM to make this happen.
Some ideas ...
ROM1:1B68 ThinkActualFrameNumIsExpected: ; CODE XREF: SendPifCmdsAndMore+5E P ROM1:1B68 ; SendPifCmdsAndMore+98 P ROM1:1B68 lda SlowPifCounter ; may throttle how often we check for seek complete among other things ROM1:1B6B beq CompareActualPicNumWithExpected ROM1:1B6D dec SlowPifCounter ; may throttle how often we check for seek complete among other things ROM1:1B70 beq ReadActualPicNumIfAvailable ROM1:1B72 jsr QueueNopCmdToPif ; make sure that this gets called again ROM1:1B75 clra ; sets Z flag to indicate success ROM1:1B76 rts ROM1:1B77 ; --------------------------------------------------------------------------- ROM1:1B77 ROM1:1B77 ReadActualPicNumIfAvailable: ; CODE XREF: ThinkActualFrameNumIsExpected+8 j ROM1:1B77 lda #4 ROM1:1B79 sta SlowPifCounter ; may throttle how often we check for seek complete among other things ROM1:1B7C dec SlowerPifCounter ROM1:1B7F beq Error507 ; if this counter expires, it's an error ROM1:1B81 lda FieldsLeftBeforeStability ; If this is 0, it means it's safe to read the VBI picture number. (See 1B81) ROM1:1B81 ; Gets decremented by IRQ if it is not 0. ROM1:1B81 ; It indicates how many fields the IRQ needs to see before it considers the software/hardware field values to be stable. (see e488) ROM1:1B81 ; It gets set to non-zero any time the hardware field value does not match the software field value. ROM1:1B84 bne Skip4TracksForward ; skip 4 tracks forward ROM1:1B84 ; (to recover from bad VBI read?) ROM1:1B86 jsr ConvertBCDPicNumToHexPicNum ; Converts the last read BCD picture number (from laserdisc VBI) to a hex picture number. ROM1:1B86 ; Carry will be clear on success or set on failure. ROM1:1B86 ; 'D' and $A133 will contain the converted picture number, or 50000 (decimal) on failure. ROM1:1B89 bcc CompareActualPicNumWithExpected ROM1:1B8B ROM1:1B8B Skip4TracksForward: ; CODE XREF: ThinkActualFrameNumIsExpected+1C j ROM1:1B8B lda #$10 ; skip 4 tracks forward ROM1:1B8B ; (to recover from bad VBI read?) ROM1:1B8D sta PifArray1ByteSpecial ; This byte will be sent to the pif board if it is non-zero. ROM1:1B8D ; It is special in that it can receive a higher priority to be sent (I don't fully understand it yet). ROM1:1B90 clra ROM1:1B91 rts
I am going to try writing to D800 at 1B7C and 1B8B to see if it reveals anything.
