strange that these never had light board problems. at least our proto didn't.
the tornado with lights is cool. wish they didn't axe it.

Can this prototype run the latest code? At least some of them cannot.

LE # 5??

Looks like it says proto #14 on coin door

Last woz at this auction had 8k reserve plus 15-20% fees and never went higher then $6500

To those asking if it can run the new code the answer is no.

It's more than a harddrive.

we kept getting updated HDDs from Jack during the development on WoZ.
It's not like there's 1 software version for "protos" and that was it.
1.16 was the last one we got.
we're running 1.22 on ours now and it works for the most part. occasionally the light boards flicker some that it didn't do before the update. Not brave enough to try 1.24, then 3.0.
If I had a spare hard drive I would though.

Don't count on it running new code.

It's a prototype, a piece of "Pinball History" - so would you buy a classic car and do engine and body work- why?

The game is what it is, done. It's a Prototype. Don't count on upgrading it. Buy it for what it is for a collection.

Oh I can't wait for Saturday!

+1

Perfectly said. Best luck to the highest bidder

Says it sold on site for $6650 plus ups and extras. Doesn't appear to be a "pass".

$8133 out the door with the fee to the auction house and state sales tax. Apparently below original reserve which was then lifted (mentioned during the bidding).

Other pins sold today with fees and sales tax:

Bally El Toro $257
Gottlieb Rocket Ship $978
Williams Lucky Ace $336
Bally Sky Kings $336
Haunted House (LEDs, supposedly new boards) $2510

viperrwk

Hope the new owner enjoys their museum piece. All I know is the "early " code I played at TPF 2013 sucked, so I hope they're not having to play that same code. On the upside, if they are, this game might stay mint forever once they get tired of shooting for multiball 40 times without anything else to do.

I just hope the new owner KNEW that the game could not be updated.

I'd hate to see someone with a $8200 boat anchor in their house, that they thought was a complete game....

There are some collectors who like to buy prototypes and low serial numbers. I have a bad feeling this was not the case here. Was there a "buyer beware" announcement when this one came on the block? Or was it the usual auction song and dance saying a routed beater WOZ just sold for $10K on eBay?

I played the prototypes and IAAPA and SPF and they were dreadful compared to the new machines with 3.0 software.

Hard to believe I'm saying this; kudos to Alex and Jack for chiming in here with words of warning.

With all the light board issues I had for the first four months, I thought my WOZ WAS a prototype!

That's great material.

not exactly a boat anchor, its still playable. (kinda) : P

Originally there were 8 prototypes that went to iappa first. I have #5 of 8 in my shop.
It can be sold if someone is interested.
Pincades
JT

What would you roughly want for it?

It would be fun to P-Roc it and make a darker themed, faster version of the game.

Wicked Witch edition?

It's not supported by JJP, and it isn't updateable.

LTG : )™
Disclaimer : No idea who you talked with at JJP, but you got the wrong answer.

Yes, and I'd definitely get rid of that dancing scarecrow.....

P-Roc can't handle the real time events that the lighting and video in parallel require but you're welcome to try .

Interesting, I wonder, then, how they are managing the video and lighting on the P3, which. as I understand it, uses the P-Roc? (Not being smart, genuinely interested)

If it didn't run right you're damn straight I'd do some engine work.

it can handle lighting and video just not the lighting the way we do it. Think about the transitional colors, fades, and shades. Each interstitial color change is a real time event.

I saw the guys at MCP have an RGB LED controller that blows everything else into the weeds.

One board can address 256 RGB LEDs updated at 72 times per second.

Oh yah - well my dad P-roc can kick your dads P-roc's butt
Happy Fathersday Guys

72 times a second. That's cute . You need another digit in front of that number.

That's what I believe they said, but I could have it wrong (Wouldn't be the first time).

Whatever refresh rate it is, their demo playfield looks like the most sweeping, mood and mind altering color wheel I have ever seen. Waves of water or flickering of flame.

Everything, including the GI is swept with live action color.

Very bad-ass this next generation of pinball.

Agreed. It's very cool times.

Thanks to those of you who emailed me about this thread.

These statements are both incorrect. The P-ROC and associated driver boards are certainly capable of being updated just as fast as you're able to update them, whether it's at typical OS USB servicing speeds or optimized speeds (ie. 1ms cycle USB servicing times that you can achieve with an optimized linux kernel and USB driver).

The beauty of the P-ROC (and PD-LED board) is that you don't have to do any host side optimizations to achieve beautifully smooth fades on one LED or even on hundreds of LEDs simultaneously. The PD-LED is an intelligent LED controller that you can send commands to fade each LED from one color to another, even at different speeds per LED. This intelligent control happens at nanosecond resolutions, which is MUCH faster than you can get with host side commands even on an optimized system. That's why color fading with a P-ROC and one or more PD-LEDs appears perfectly smooth, whereas on systems with slower update resolutions, you can see the incremental steps as LEDs 'fade' from one color to another.

If you don't want to use the built-in functionality the P-ROC and PD-LED provide, you don't have to. You can push incremental color changes down to the hardware as fast as you want, and they'll work just fine. So if you really think you need to keep the low level coordination in software by doing the incremental color changes there, you certainly can. I'd propose there's a better way to architect your system though.

I'm happy to go into more detail, but I don't want to derail the thread.

All that said, the current version of the P-ROC does not plug directly into a WoZ without modifying the machine's hardware and/or wiring. You could replace the entire driver board with a P-ROC + PDBs if you really wanted to, but it's by no means a plug and play solution.

- Gerry
http://www.multimorphic.com

Hmmm nanosecond. At the beginning of your calls would be a gtod function for start timing and you couldn't get that to NS if you tried across that many LED's. I'd bet even across a handful. You are saying greater than 1000 updates a second across the string with full responses or dumb sends with no return processing? The former I would agree with the latter no way. Absolutely not round tripping in that time. We spoke on the phone Gerry and had this discussion not too long ago

Gerry is correct though it's not going to work in a woz without major modifications.

But I digress. Back to the topic at hand.

Anyone serious about buying it shoot me pm's or call me! 219-924-PINS
JT

WoZ updates the lights at more than 172 frames a second?

Jack has a heap of these Protos and I am sure at $8k each he would be Thrilled to get rid of them

Already had one of those. It was called an early standard.

It certainly is a piece of .... "something".

and you can't be serious about not doing work on a classic car. i must be reading this wrong.

Yep, we spoke on the phone about a year ago. I remember it being a nice conversation.

The intelligence is in an FPGA, not a microcontroller. Yes, decisions are made every few nanoseconds, and all LEDs (even across PD-LEDs) are controlled independently and simultaneously. That means each and every LED in the system, even in a system with thousands of LEDs, can smoothly fade from one color to another at individual speeds at the same time with no software involvement other than setting up the fade params.

There's no concept of a 'function' in an FPGA. All of the logic is running in parallel, at the same time. Also no need to 'get time of day'. The timing in each circuit is fixed relative to the oscillator.

The P-ROC receives commands from the host over USB, and it can receive and process them as fast as the host can send them. So if you can get your host to send commands faster than 1000 times a second, receiving them and optionally responding to them is no problem for the FPGA. Multiply that by another 1000 for 1,000,000 commands a second (one command every microsecond), and you're still not taxing the FPGA.

- Gerry
http://www.multimorphic.com

Holy crap! You lost me at Yep.....

PM sent.