Monday, July 17, 2017

Esh bug explained

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.

Friday, July 14, 2017

Where Esh's Aurunmilla stores its 'current stage'

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.

Tuesday, April 4, 2017

Modifying Star Rider to send triggers to logic analyzer

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.

Monday, April 3, 2017

Major Star Rider / PR-8210A / Dexter break through!

I'm pleased to announce that I've finally made a break through with regards to understanding in a very detailed way how Star Rider and the PR-8210A interact with each other, and thus how to properly support Star Rider with Dexter.

In order to explain why the knowledge I've gained is significant, I need to step back and give some context.

Star Rider is the only laserdisc game that I know of that uses the PR-8210A.  How is the PR-8210A different from a regular PR-8210?  The PR-8210 (and also PR-8210A) uses commands which are relatively slow to be transmitted.  A command must be sent 2-3 times (all of the games send it 3 times) in a row in order for it to be accepted by the player and this can take a complete frame or two if the disc is playing.  The PR-8210A exposes some internal signals on a centronics-24 connector (the PR-7820 and LD-V1000 also use this connector) that allow a connecting device (such as an arcade PCB) to control the forward/backward motion of the disc both quickly and accurately.  This allows one to develop the kind of game that Star Rider is: a racing game where the disc speeds up and slows down.  The way that this is done is via a signal called the Jump Trigger.

What is the jump trigger?  It's normally an internal signal that tells the disc whether to jump ahead a track or backward a track.  For example, if the disc is paused, at the beginning of every frame, the player will internally generate a jump trigger to tell the disc to jump back 1 frame.  This creates the illusion to the viewer that the disc isn't moving at all but it actually is moving, it is just skipping backward continuously to achieve this illusion.  The jump trigger is also used for stuff like 2X and 3X forward and reverse playback.

Since the PR-8210 commands are so slow, as I mentioned before, they are not suitable for a racing type game.  However, if the game (Star Rider) can instead control the jump trigger, then a racing game suddenly becomes possible.  This is what the PR-8210A provides that a normal PR-8210 does not.

So why have I been having so much trouble with Dexter and Star Rider?  It's because the exact behavior of the jump trigger is not documented (at least not where I can find) so I basically have to take some guesses and/or observe how a real player works.

For the past N years, I've been doing the former, taking educated guesses, and getting close.  But I was running into things like the jump trigger getting sent at odd times from the game and not understanding how Dexter should respond in this situation.  So I finally broke down and got a real PR-8210A setup going (as shown in a previous blog post).  Coupled with a logic analyzer, I was able to finally see what I've been missing for years!

First, how does a search look?


Star Rider will send each command three times in a row.  It looks something like this if it wanted to search to frame 68:
seek seek seek
disp disp disp null
0 0 0 null
0 0 0 null
0 0 0 null
6 6 6 null
8 8 8 null
seek seek seek

Notice "Z2-5 jtrg in" from the above screenshot.  This is the internally generated jump trigger from the player that comes out to the external centronics-24 connector on the back of the player.  It is maintaining the disc in a paused state during the incoming search command.  Notice "Z2-6 jtrg out."  It is the 'final' jump trigger signal that the player actually acts upon.  The Star Rider PCB has the opportunity to override this signal and provide its own.  In this case, Star Rider is not overriding the signal (jtrig int/ext', line #1, is raised) and so what comes into the centronics-24 connector is the same thing that goes back out.

What happens during a search?



A few things happen here:

  • "Stand by" starts toggling at approximately 2 Hz.
  • Video sq' (video squelch) goes low.
  • Z2-5 and Z2-6 start becoming very active.  The player actually uses jump triggers in order to perform a search.  Neat, eh?

What happens when a search completes?



  • Video squelch goes high.
  • The player starts internally generating jump triggers via Z2-5 again (ie the disc is in a paused state)


Notice toward the end of the above screenshot, Star Rider sends three play commands.  This is where I was getting hung up because it was very unclear to me what would happen here.  I could tell that Star Rider wanted take over jump trigger duties and that by putting the player in the 'playing' state that the player would stop generating internal jump triggers.  But I couldn't tell whether there was a bug in Star Rider that caused the player to jump an extra track forward or backward.

Examining these three play commands more closely is very interesting.


In the high-lighted area, the player is generating internal jump triggers and Star Rider is also generating them AND trying to override the player's internal jump triggers.  This appears to be a defect in Star Rider's program.  It should not be trying to do this.  But it is what it is.  There seems to be a contention here.  So what actually happens?  Does the player process two jump triggers?  Does Star Rider manage to override the internal jump trigger before it kicks off?  Is a second jump trigger ignored?  It's really hard to say... unless we zoom in :)


This may seem to be a straight forward screenshot of straight forward information, but let me assure you, it took me YEARS to finally figure this out!  I can only guess, but my speculation is that the Star Rider developers were not aware of this bug in their code because, conveniently, the PR-8210A apparently ignores the second jump trigger.    The reason that this is a bug is because Star Rider overrides the PR-8210A's jump trigger after the PR-8210A has already generated it.  Why does the PR-8210A ignore the second jump trigger?  Perhaps because it occurs to close to the first one?  I really have no way of knowing without further study.

Conclusion: I should be able to make Dexter ignore an external jump trigger from Star Rider the same way that the PR-8210A ignores it.  It will take a bit of trial and error, but I am confident that I can make it happen.  Having the original player available to study was extremely helpful!

Thursday, March 30, 2017

PR-8210 to PR-8210A conversion! (successful!)

I'm really close with Star Rider support for Dexter but there are a few quirks of the game that make me want a real laserdisc player for research.  I decided to try Andrew Hepburn's guide to convert a dead PR-8210A to a working PR-8210.


Sunday, February 26, 2017

Wrote a custom analyzer for Saleae Logic 16

Trying to troubleshoot Star Rider was hard enough without trying to decode the laserdisc commands "by hand."  I wrote a custom analyzer for my Saleae Logic 16 to decode the commands automatically:


Tuesday, February 21, 2017

Star Rider : Playing a 1984 piece of hardware with an xbox 360 wireless controller?


It started innocently enough... the 'DISC SEARCH' test wasn't working and I wanted to fix this.  Eventually, I ended up creating a custom PCB in conjunction with an xbox 360 wireless controller just to get the dang test working :)

I use a (IMO) very cool troubleshooting technique involving the ROM program disassembly and a logic analyzer to track the issue down.