6809 Assembly and a custom bytecode. You can probably load one up in pinmame and start watching the ram in the debugger to try to track down what memory location is used.

How are you planing on getting the data out of the WPC CPU board to your computer?

I'd be willing to bet that the only practical way you can pull/intercept things that aren't manifest in the lights/solenoids/sound/display is through an emulator. It's fairly simple to intercept solenoids and lights on WPC hardware. Sound and display are substantially more complicated. Getting to the contents of memory while the machine is running will probably require a fairly involved hardware project.

Involved, but definitely possible to hook a latch up to the data lines that's triggered by a certain memory address. Probably not worth the effort though.

I wonder if a Raspberry pi or something would be able to read all the input pins of the ram fast enough to just keep a copy of it up to date...

Sounds like a first step would be to make a 'bypass' ram adapter that plugs into the ram socket and has hookups for the actual ram and the rpi gpio on it, and see if you can manage to read in the memory writes as they occur and keep a consistent clone of the actual ram on the rpi. At that point you can then verify against pinmame and try to find the score locations in ram

This is an interesting post.
Polling Raspberry Pi GPIO is very slow,< 1mhz and funnily enough RPi B+ can poll the GPIO pins much faster than RPi 2 or 3. However your idea is very interesting, I have had moments of madness where I thought it would be fun to interface directly with the cpu for various reasons. But it always seemed liked more work than I was prepared to do. I however have a suggestion for you that might work...
1. You don't have to "find" the high scores etc. in the cpu, because the machine tells you all you need to know on the display!
2. Intercept the display data.
3. identify the data you want, like the high scores.
4 send the data to your pc/rpi or whatever.

The previous post, the ram idea is also interesting, but more wires, might be cool to play with if you had an extra wpc cpu to play with, maybe some soldering ... Also probably not needed to clone the ram, but see how long you can delay comms between the ram and the cpu before it complains, to give you time to read your addresses ..
Good luck

This wouldn't be as easy, unfortunately.
Since the MPU generates the bitmap data for the display - that means, it gets the score, uses the font programmed into the ROM to generate how the score would look with that font and then send it to the display board - your code would neeed to be able to re-decode that bitmap display data back into raw numbers. Once you finish with one game, you'd then need to do it to games that used a different or custom font.

The CPU is only 2MHz, it doesn't seem that far out. Where did you hear that? Everything I find says at least 10MHz... If a RPi can't, I'm sure some other board can.

Plus, you've got to deal with the numbers moving around on the display, games with animated backgrounds, etc. I can't even imagine what trying to read the numbers on a BSD as they drip blood would be like

Another board will be better, if you need to read the pins faster than 1Mhz. But also you will need to wait for the clock signal and then read the pins, so half that maybe 1/2Mhz.
Your idea is cool , it got me thinking ... but why interface with the ram directly, it is soldered onto the board, but the CPU chip itself is socketed ,so easier to interface with, wait for it to write to the ram address and listen in.

Yes but you have al the time in the world (the display refreshes at 120hz) all you need to get high scores is the font and location on the screen used to display the scores and you would be looking for "1)" or "2)" etc. in all the frames it pushes out. It will be different for every machine. It won't be easy, but it won't be super hard either.

Not to sound overly positive but if you can read it, you can program a machine to read it.

Oh yeah, they're not socketed by default on WPC... yeah I guess it wouldn't really matter, the CPU would work just as well. Anywhere that all the proper address lines are getting to.

And my phone can understand my dictation to it so well! I just don't think that programming a board to read multiple separate fonts per game individually is a good use of time when you can have a 'perfect' solution for all games.

Not sure what you mean here... Any time one of the CE pins changes, I'd just evaluate them and see if they're enabled for a write, and if so decode the address and store the byte of data from the data lines...

Yes I agree a single universal solution would be the best. Nice ideas all round. Might be a fun project. I might try.