Why not have soren add in code for the VUK?

He rewrote a lot of the code already so he's going to be intimately familiar with it.

Does the vuk use some existing switch that in the final game is used in a different way? That would be the easiest way to change the code, tag it onto that switch routine.... or if anyone has the proto code the routine can be moved from one software base to another.

I'm not familiar at all with the nuances of Radical since I haven't played one since it came out.... is there an equivalence between the proto and the production run in terms of the switch that triggers all that?

I don't think taking the new rules if that's what you want and adding the new rules to the proto roms would be the way to go and I can see why Soren wasn't interested in doing that (it's like taking an entirely new rom and duplicating everything added to the other) - but adding in the proto stuff TO the new rom (or just taking the newer stock rom) seems like the way to go.

There's a TON of room in the L1 radical roms. Large swaths of unused areas.

How would the software have to treat it differently? I know there's going to be a pause on a vuk vs. not.... is that it? I see there's also an extra slingshot on the prototype - do those switches do anything on the non-proto (are there even switches there?) Is that the only different, the vuk is switch 16.... what does the regular switch 16 do just go around the upper loop?

The vuk puts it up onto the top ramp is all? Is it always accessible like Earthshaker's is?

Any source is re-created.... there's a ton of 68xx cross assemblers available for the PC, so it's no big deal to assemble. The rub with custom roms is always the beta testing.... as in, is the beta tester going to give good feedback when things don't work right? Does the beta tester even have eproms and a burner? Beta testers in my experience run the gamut of never even telling you if they tried the software, or telling you ANYTHING about how it worked/didn't work, to saying "something went wrong. I don't know when or what the state was. Fix it." to detailed notes and videos on reproducible errors.

The changes to roms can be applied as patches that wedge into the existing software, or can be an entire re-created source code package. It depends on the nature of the change. Patches get messy really quickly if a lot of changes need to be made, but they are a lot quicker to create. Re-creating source code is a relatively large task.... it really depends on the goal.

Not having the game to test can be a big stumbling block, it's very difficult to "play" a game on pinmame to test.

For people who want to see what williams "pinbol" code was in the system 11 era, it's not too far from the system 7 stuff posted here:
http://gamearchive.askey.org/Pinball/Manufacturers/Williams/PinBuilder/text/williams_lvl7_programming.html#compatibility

System 7-11 have a switch parameter attached to each switch that determines how long the switch must be continuously active before the game will service it - a standup needs a very short activation time, and a vuk (as well as eject holes, drop targets, and trough switches) need a longer time. It might be as simple as changing the switch timing for switch 16 in the production/soren software to the longer timing needed for the vuk, and then adding the code to the end of the vuk routine to do the light show/eject the ball. If what that standup does is substantially the same, other than the flasher/vuk activation that is the way I'd approach it.

I'd think that the sling in the proto would activate anyway since it's a special solenoid, but I'd say with the newer software it won't score or make a sound effect - that could probably be added back in as well.