Philips VP406 LaserDisc Player Repair

Philips VP406 Repair
Primary Contact	Aaron / Tim
Created	2025-03-26
Completed	{{{completeddate}}}
Dormant	{{{dormantdate}}}
Version	{{{version}}}
Members	Tim, JonW, Moop, dpslwk Ali, Olivia, Aaron
Manufacturer	{{{manufacturer}}}
Model	{{{model}}}
Location	[[{{{location}}}]]
GitHub / Repo	https://github.com/mooped/vp406-laserdisc
Status	Active
Type	Undefined
Live Status	{{{livestatus}}}

We're trying to fix a VP406 LaserDisc player. It lived under Tim's bed for many years and now we want to watch LaserDiscs during film night - but first, we must repair it. While the disc plays, and the TV syncs correctly, the video is offset. The issue appears to be before or around the PAL demodulator, since the on screen debugging menu is correctly positioned.

Resources

OCRd Service Manual for VP406 Player

Service manual for VP415 Player, pages 20-35 describe sending 'F-Codes' over RS232 to control things like 'jump to frame and freeze' which might be useful for getting a test pattern.

Schematics

Ali has combined and cleaned up the scematics from the service manual. Much nicer! The wiki won't make thumbnails for them because they're chonky, but you can click through to the original file.

• Aa - TXT Bypass, PAL Demodulator, Luminance Delay, Colour Transient Improver, U/V Processing, RGB Matrix
• Ab - Slave Source, Focus, Focus Drive, Sandcastle Generator, Sync Insert, Vertical Blanking Insert
• B - Radial Drive, Time Base Correction (TBC), Audio CCD, Variable Delay Line, Delay Control, Video CCD
• Ca - HF Processing, Video Demodulation, Dropout Correction,
• Cb - Audio Processing, Slide Drive
• Da - Special Burst Separator, "Reference"
• Db - Sequencing
• F - Power Supply
• N-P - Front Panel Keys
• SRa - Control, Watchdog, RS232
• SRb - CPU, SBUS
• Z - Laser Supply, Servo Pre-Amplifier, Tilt Motor Control

Just the schematics are available in one PDF for easy browsing: File:VP406 AllSchematics.pdf (23MB).

Boards

A Board / "Video Proc Panel"

• 
• 

C Board / "HF+Audio Panel"

• 
• 

D Board / "Motorseq+TBC module"

• 
• 

N Board / "Keyboard module"

• 
• 

P board / "Frontloader module"

Controls the drive tray eject mechanism and drive tray position detection switches.

• 
• 

SR board / "Codrive module"

Contains SRa and SRb circuits combined into one board.

• 
• 

Timeline

26th March 2025

• Video plays, but is offset
• Power switch doesn't work - removed and bridged temporarily
• X2 RIFA capacitor exploded - removed

• 
• 
• 
• 
• 
• 
• 

29th March 2025

• Removed the other X2 capacitor, since it was probably also going to explode.
• Lots of debugging. We think the issue is not with Board A but Board D, which presumably creates a line pulse but out of phase from the video.
• Confirmed that the video feed going into the PAL modulator is alight, since the TV can sync to it.

What we want to check next:

• Verify that HMANCH is being generated correctly by probing CVTBM and HMANCH at the same time (see page 44 of schematic). They should line up.
• Check that HMANCH isn't being inverted in some weird way by the "SLAVE SOURCE" (see page 34)

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 

5th April 2025

• We verified that HMANCH is being generated correctly and in time with the disc's composite video.
• The logic in that area seems to be preferring the RAMP EN pulse instead of HMANCH. We suspect this may be causing the issue issue with the shifted frame.
• The laserdisc player died at some point while trying to figure out what the logic was doing.
  • All power rails are good.
  • Disconnecting the board we were working on does not help.
  • A red LED lights on the front, nothing else happens.

• 
• 
• 
• 
• 
• 
• 
• 

Despite the issues with it turning on, I do want to document our current thoughts before we forget them trying to fix the other issue. Some context from page 129:

The function of the slave source circuit is the generation of sync and timing signals for the video signal processing in the player. These reference signals have to be very accurate and are generated by a sync generator IC 7061 with a feedback oscillator (5MHz).

During the start-up cycle of the player the sync generator will create the timing signals related to the free-running oscillator. The oscillator is readjusted dependent on the input signal of the sync generator, hence the name slave source. On behalf of the synchronism with the video signal of the disc a frame reset takes place, if necessary.

Thus, at the end of the start-up cycle, a unique lock-in performance can be observed in the video picture. The slave source circuit can be split in two parts: the sync generator circuit, frame reset circuit.

... skip to Frame Reset Circuit

If necessary, the frame reset circuit generates a frame reset pulse to lock sync generator IC 7061 to the video signal on the disc. Input signals VMANCH (vertical sync) and HMANCH (horizontal sync) have been derived from the video signal of the disc, CV-TBM (timebase corrected). The input signal of the sync generator, RAMP-EN, has been derived from the reference on module D and sees the to the drive of the turntable motor by means of the MCO signal after comparison with CV-DOC video signal coming from the disc. This CV-DOC signal has not yet been corrected for timebase and might drift relative to CV-TBM. To prevent this from happening the frame rest is required.

The sync pulses in the composite output of the player are aligned with RAMP-EN, rather than HMANCH, which comes slightly before it. The position of HMANCH would make much more sense, as it comes before the colour burst. The oscillator cannot be free running or the picture sync would move in and out of phase with the disc's video.

As for why the thing isn't doing anything now, we're still quite unsure. The red LED on the front suggests it's in standby, but pressing the standby or eject buttons should awaken it - this does not happen. The voltage rails all seem to be alive. A few ideas to check:

• Check to make sure the reset line on either CPU isn't stuck high, as this will cause the CPU to constantly reset.
  • 2060 and 2064 are electrolytics responsible for the output duration of the watchdogs' timer. We should check those, or just replace them. They are 4.7uF and 2.2uF respectively.
• Stick a logic analyser on 7107 - It's an IO expander on the codrive module. The serial lines should show the bit pattern flickering when buttons are pressed.
• Check A0 address line on the control processor, this should be toggling a lot if it's executing the code.

7th April 2025

We've been investigating the watchdog for the drive processor and the control processor. The 2.2uF capacitor (2064) was discharging very quickly, so determined to be suspect. We decided to replace it with two 4.7uF capacitors in parallel, roughly giving 2.5uF. We also replaced the 4.7uF capacitor (2060) as a precaution. We then spent some time monitoring the signals involved in preventing the drive module's watchdog from triggering (via it's reset line).

• 
• 
• 

We have determined that the drive processor's watchdog is being correctly reset via the output of shift register 7110, but still triggering after the data to the shift register stops. We suspect the processing is crashing, or waiting for information off the sbus. Will continue investigating...

21:32

The control processor is resetting its watchdog frequently, and the watchdog is not resetting the CPU. That's good. So, why is the drive processor crashing?

Ideas for next time

• Since the control processor appears to be running fine, we can probably talk to it over serial. Maybe we can get an error code.
• Check for VR pulses going into the drive processor. They should always be present. This comes from the "V-SLAVE" signal from Ab via B.
• Get a logic trace of all the inputs to the drive processor, ensure we understand what they are doing, and use this to find out what might be wrong.
• Dump the drive program EPROM and disassemble it.
• Get a logic trace of the PD0011A handshake. This chip is responsible for decoding the manchester encoded data at the start of each frame. I can't find anywhere to buy this chip, so having a logic trace of it, even if working, is valuable, as it can potentially be reimplemented with a CPLD or MCU.

9th April 2025

Not much time, we took ROM dumps. You can find them in this zip: File:VP406 ROMs.zip

12th April 2025

We had some fun today. Attaching a logic analyser to the address bus was slightly tricky. We built an intercepter-type thing which the ROM plugs into, and gives us access to the 14 address lines.

• 
• 
• 
• 
• 
• 
• 

What we did:

• Confirmed that we were decoding the addresses correctly by finding a trace where the CPU had just been reset. Address decoded as 0x0000 and jumped to 0x1903 as the code in ROM dictates. Good!
• Took 1000 logic analyser traces trying to find a case with address line activity prior to the watchdog resetting the CPU.
  • There are no such cases - the first bit to toggle, and therefore trigger the Glasgow, was the reset line. This indicates that the address lines were not changing prior to the reset, and so the CPU is actually crashed, not just stuck in a loop.
• Monitored the 5v rail at the decoupling capacitor for the drive control CPU. It's a little noisy, and you can see when the CPU is and is not running in the oscilloscope trace. There doesn't appear to be any drops so big that it'd cause the CPU to crash though?
• We checked that the VR line is doing what it should - and it is. A pulse roughly every 20ms.

13th April 2025

Tim and Aaron met up because we wanted to measure the ripple on the 5v line near the other CPU. Much healthier. We added another 47uF capacitor in parallel with the current one on the drive processor and the ripple decreased, but still crashes.

We also managed to run and test CPU disconnected from the laserdisc player by putting 5v across one of the capacitors. This may make it easier to debug some issues.

Aaron asked Graham for advice about ripple and filter caps and he suggested to replace the 22nF decoupling cap with a 1uF ceramic capacitor. We'll try that next time.

Tim hooked up his Basys fpga dev board and wanted to test the use of a 74xx245 to level shift to 3.3v so he could write a logic trace bitsteam. We saw LED's flash to test this :)

• 
• 
• 
• 
• 
• 
• 

New theory: Do we have 12v? We should check (again, more carefully this time...). If we don't, it could be putting excessive load on the drive processor, as this CPU has some pins which go through a level shifter to 12v and then into a shift register (outputting at 12v).

14th April 2025 Not a meetup, just playing with the logic traces we took on the 12th. I wanted to find the most common end address from the logic traces.

# Convert all vcd files to csv
$ ls | grep vcd$ | xargs -L1 -I{} -P14 ~/git/sigrok-cli/sigrok-cli -i {} -O csv -o {}.csv

# Find the last address in each, matching a low psen line (second to last)
$ for csv in *.csv ; do tac $csv | grep '0,[01]$' | head -n1 | tr -d ',' ; done > last-addr

# Find most common end address
$ wc -l last-addr 
605 last-addr
$ cat last-addr | sort | uniq -c | sort -h | tail 
     26 1111011011100000
     28 0001111011100000
     38 0010111011100000
     40 0110111011100000
     43 0011000010011000
     46 1101000010011000
     48 1010111011100000
     55 1011000010011000
     62 1111000010011000
    107 0111000010011000

# Identify files which contain that binary pattern
$ cat -n last-addr | grep 0111000010011000 | tail -n3 
   594	0111000010011000
   595	0111000010011000
   600	0111000010011000
$ for csv in *.csv  ; do echo "$csv" ; done | cat -n | grep -P '600\t'
   600	rom-trace-95.vcd.csv

The entry 01110000100110 (flip) decodes to address 0x190e. This is an instruction pretty early on after startup, i.e. after the reset line, so it's probably more commonly occurring because that point the glasgow's buffer is full. A useless detour

18th April 2025

It was a very intense day of LaserDisc debugging.

• 
• 
• 
• 

Notably, we made a few realisations / discoveries / etc:

• The CPU is still executing instructions up until the watchdog resets it. This was found by monitoring the PSEN, and separately address 0, while triggering off the reset line. We know that it has stopped outputting the window signal though, meaning it's asking to be reset?
• The DRIVE processor does have external RAM. 128 bytes of it, provided by the second I/O port expander.

Additionally, we got:

• A large number of traces showing various I/O activity on pins going to the CPU. These include:
  • CL-RAD, which never reaches a point of changing - likely because there's no disk.
  • LDI, which is pulsed 180 times after startup
  • ATN, doesn't change. This goes to the Manchester Decoder
  • TX/RX, also doesn't change, and also goes to the Manchester Decoder
  • STB, also doesn't change and also goes to the Manchester Decoder
  • IQR, which is an input, and doesn't get triggered.
  • VR, which comes from the slave source, and is raised every 20ms or so.
• A larger number of traces of the first I/O expander - we've not parsed these yet.
• A much longer trace, thanks to Tim and his FPGA, showing the addresses of execution for 100,000 instructions. This is helpful!
  • From this we can see that one of the functions is jumping back to 0x0000, because of something - otherwise it would continue on from where it left of. This function is at 0x072f. This may be because the state of some register is not set correctly. Lots of poking about required.

21st April 2025

Well, we did some things today.

• Got some more logic traces, some with more regions collapsed.
  • Tim noticed something odd with the memory initialisation - it should only happen 128 times, but after a soft reset (i.e. jumping to 0x000), the loop continues endlessly.
• Tested the power supply some more
  • While doing this, popped a fuse. Temporarily replaced 3.15 amp fuse with a 2.5 amp fuse.
  • Confirmed voltage rails were stable while providing a 500mA load on the 5v rail.

Feeling suspicious. Next time we will:

• Monitor power rails from the back of the power supply during start up
• Try replacing the 27C128 ROM (which contains the drive control software)
  • How do EPROMS degrade? Do they become slow before deleting everything?
  • There are a number of cases in our I/O Expander traces, which mostly just logged ROM accesses, where bits are not in sync.
• Tim wants to try running the drive processor with the control processor disconnected.
  • This is because the control processor is likely the thing turning other stuff on, which could be responsible for power blips.

23rd April 2025

• We replaced the 27c128 ROM with a 28c256 ROM - the high address sits on what would be the Vpp pin, meaning the second half of the 256 ROM was being used. This did not change the behaviour.
• We removed the control processor and its ROM to see what would happen - very much the same, nothing when pressing eject / standby, but the light was green. The front LED is controlled by the control processor.
• Another read was taken of the control processor ROM, it seems better now, so holding the paperclip in place lead to a ROM which was repeated, as the broken leg was the highest address.

We did not monitor the power rails from where they get distributed to the rest of the system, we'll save that for next time.

26th April 2025

We mostly focussed on measuring the voltage rails at various points in the player to see how wirespread the CPU noise was. It was slightly visible back at the power supply, but maybe it was acceptable for the era.

Started to ponder whether another chip may be getting enabled during the initial run after a watchdog/power-on reset, i.e. after the internal memory initialisation. Perhaps that chip is doing something weird to the datalines. Next time we should monitor the address lines, and data or various chip select / output enable lines.

4th May 2025

• 
  The setup
• 
  Intense hacking
• 
  Probing

A big day of LaserDisc hacking. We got logic traces from several points of the following pins:

LA pin, CPU pin, name
0 39 A0/D0
1 38 A1/D1
2 37 A2/D2
3 36 A3/D3
4 35 A4/D4
5 34 A5/D5
6 33 A6/D6
7 32 A7/D7
8 21 A8
9 22 A9
10 23 A10
11 24 A11
12 25 A12
13 26 A13
14 29 !PSEN
15 30 ALE
16 16 !WR
17 17 !RE
18  x watchdog

these were taken using Tim's fpga. moop wrote a script to trace what the CPU was doing (latching the ROM address and instruction where appropriate).

• Confirmed (again) that it gets stuck in the loop after it gives up and jumps back to 0x0000.
• moop came up with a good explanation as to why:

This would explain it getting stuck. The loop won't run less times if we're using a different bank it will never terminate.

The loop at 190b doesn't write the a zero to bytes 127 through 0, it writes 127 through 1. We exit the loop when R0 becomes 0.

If we're in bank 0 this means we write everything down to the R0 we're using and then stop. The DJNZ leaves a 0 in bank 0 R0 anyway.

If we're not in bank 0 we stomp R0 with the MOV instruction instead of letting DJNZ decrement it to zero. Then DJNZ decrements it from zero.It wraps around to 255 and jumps back to the MOV which starts again from 255. It will never terminate because it's stomping its own counter register and DJNZ never sees the transition to zero!

• (context: apparently the 8051/8031 has four register banks which can be switched between and these are mapped into the internal ram starting at 0x00. Something that happens before that loop switches to register bank 2)

next:

• need to figure out why it would give up from that function (0x072f)
  • maybe we can modify the ROM to help with this