Found another LDP-1450 interpreter bug

Looks like there is another bug in my LDP-1450 interpreter:

I got Dragon's Lair 2 playing but then it dies at a "resurrection" scene, after you lose a life.  I looked at the serial I/O and here is what is happening:


Search to 2108 received

----------------------------

lair2: -> 80
lair2: <- 0A
lair2: -> 01
lair2: <- 0A
lair2: -> 14
lair2: <- 0A
lair2: -> 32
lair2: <- 0A
lair2: -> 20
lair2: <- 0A
lair2: -> 20
lair2: <- 0A
lair2: -> 20
lair2: <- 0A
lair2: -> 20
lair2: <- 0A
lair2: -> 4C
lair2: <- 0A
lair2: -> 49
lair2: <- 0A
lair2: -> 56
lair2: <- 0A
lair2: -> 45
lair2: <- 0A
lair2: -> 53
lair2: <- 0A
lair2: -> 1A
lair2: <- 0A

--------------------------

lair2: -> 60
lair2: <- 30
lair2: <- 32
lair2: <- 31
lair2: <- 30
lair2: <- 38

So it looks like the DL2 code sends a change to the video overlay while a seek is in progress.  And then my code never sends a seek complete code (0x01) so DL2 just sits there waiting and eventually reboots.

I should note that in the old Daphne LDP-1450 interpreter, this is not a problem and works.  However, I wrote a new one so that it would work properly with Dexter.  That's why I am having to make it work "all over again" with Dragon's Lair 2.

I probably will need to send this sequence of commands to my real LDP-1450 and see how it responds.  If I were to predict its behavior, I'd say that it probably sends the seek complete (0x01) result somewhere in the middle of the ACKnowledgement bytes (0x)A that it is sending in regards to the text overlay change command.

-----------------------------------

UPDATE:
Ok, I just sent these same bytes to my real LDP-1450 (with the Dragon's Lair 2 disc in the player, no less!) and here is the actual input and output:


matt_sony: -> 0x3A
matt_sony: <- 0x0A
matt_sony: -> 0x27
matt_sony: <- 0x0A
matt_sony: -> 0x24
matt_sony: <- 0x0A
matt_sony: -> 0x43
matt_sony: <- 0x0A
matt_sony: -> 0x30
matt_sony: <- 0x0A
matt_sony: -> 0x32
matt_sony: <- 0x0A
matt_sony: -> 0x31
matt_sony: <- 0x0A
matt_sony: -> 0x30
matt_sony: <- 0x0A
matt_sony: -> 0x38
matt_sony: <- 0x0A
matt_sony: -> 0x40
matt_sony: <- 0x0A
matt_sony: -> 0x80
matt_sony: <- 0x0A
matt_sony: -> 0x01
matt_sony: <- 0x0A
matt_sony: -> 0x14
matt_sony: <- 0x0A
matt_sony: -> 0x32
matt_sony: <- 0x0A
matt_sony: -> 0x20
matt_sony: <- 0x0A
matt_sony: -> 0x20
matt_sony: <- 0x0A
matt_sony: -> 0x20
matt_sony: <- 0x0A
matt_sony: -> 0x20
matt_sony: <- 0x0A
matt_sony: -> 0x4C
matt_sony: <- 0x0A
matt_sony: -> 0x49
matt_sony: <- 0x0A
matt_sony: -> 0x56
matt_sony: <- 0x0A
matt_sony: -> 0x45
matt_sony: <- 0x0A
matt_sony: -> 0x53
matt_sony: <- 0x0A
matt_sony: -> 0x1A
matt_sony: <- 0x0A
matt_sony: -> 0x60
matt_sony: <- 0x30
matt_sony: <- 0x30
matt_sony: <- 0x35
matt_sony: <- 0x30
matt_sony: <- 0x34
matt_sony: <- 0x01

So here are my conclusions:

- It is valid to query the current frame even in the middle of a seek (this surprised me).

- It is also valid to change text overlay in the middle of a seek.

- Seek complete (0x01) byte is sent at the very end.