This is a great looking project, just stumbled onto it. This runs on original boards rather than PC /PROC?

How close are the games to the originals?

Randomly the Rocket leff causes the GI to stay off, hitting a feature that cycles the GI brings them on again

void ballsave_launch (void)
{
if defined(CONFIG_TZ)
autofire_add_ball ();
elif defined (DEVNO_TROUGH)
device_request_kick (device_entry (DEVNO_TROUGH));
endif

CONFIG_TZ needs changing to MACHINE_TZ

The template feature allows a body of code to be reused across machines. These templates allow each instantiation to fill in some parameters that complete it. For example, jet bumpers and slingshots are all instances of a "special solenoid" template.

However, every game has to fill in all of those same parameters to distinguish a jet from a sling. It would be better if we could create a partial specialization: create another template called "slingshot" and fill in some of the parameters related to slings, but not necessarily all of them. Then allow "slingshot" to be instantiated all the way to produce a final driver.

in build/mach-config.h, genmachine is creating the following entry:

undef MACHINE_SHOOT_AGAIN_LAMP

This causes the shoot again lamp to not work, I think this happens to wcs as well.

Normally the diverter works using consistantly the same power and with more than enough to move the divertor.

Very occasionally it will not activate with enough power, causing the diverter to not move. What happens next is that the ball becomes stuck, as the ball search appears not to activate the diverter, although it may be just that it is not giving it enough power.

I may be wrong, but I don't think that the included fonts/free/twizone.fon is used at all. It would be nice to have a TZ themed font for the score.

The solenoid locking logic has several flaws and needs improving.
The number one problem is that if solenoid #0 is being pulsed, another request coming in behind it can override it.

When a ball becomes hopelessly stuck somewhere, the current ball search routine will try forever. It needs to try different approaches after so many attempts. Different games have done this differently over the years; I am not sure what the best approach is right now.

I should image it's something to do with drivers/duty2.ct?

The flipper processing is extremely fragile at the moment. It does not handle switch problems at all, and it is power-inefficient. It is also more CPU intensive than it needs to be.

Very minor issue, the following line needs to be updated:

Set to the version of gcc6809 installed.

The 4.3.x releases are recommended, although 4.2.x releases

should still work.

GCC_VERSION := 3.4.6

GCC_VERSION := 4.2.3

GCC_VERSION := 4.3.1

GCC_VERSION := 4.4.0

to:

GCC_VERSION := 4.3.4

To be the same as current gcc6809 version.

The coin switches need to be handled special; there is no room for error in missing these closures. Also, requirements for minimum pulse length and time between pulses requires a dedicated driver.

Rework the way that display effects are queued up, when low priority but important effects wait around to try to display later. The main problem is that if multiple effects are waiting, the order in which they get retried is essentially random. It would be better if priority were considered here.

Pressing start during match (replay) causes the game to restart, but the attract mode deff and leff carry on going.

The way flashlamps are controlled now is perhaps not the best, then again maybe it is OK. It seems like it could be made more efficient.