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!