> Another solution would be to not convert it to a pattern that requires cycle exact > scheduling.
Reading from a sound device (which pokey was before) is trying to look into the future.
The old code looked "forward" only for reading the random number generator, whilst everything else was returned in a state about a frame old.
The current "kludge" is just exact emulation.
What we actually need in MAME are "slave" cpu devices: - can't have a time in advance of the "master" cpu. - Reads from the slave trigger the device to advance to the master cpu time *before* the read is finished.
Using a sound device and stream_update may be a possibility. However, interrupts may be triggered too late. OK, one can use timers. This can become really complex and hides the way a device works.
The rewrite as far as I remember was triggered when I rewrote the keyboard emulation which was a big HLE kludge. Same applied to paddle support. I found it a lot easier to implement those features in an "execute" device.
MAME has an issue with bidirectional communication between clocked devices. The framework supports a number of ways to deal with that.
I prefer clear and readable code and eventually take a performance hit and compensate that hit by buying contemporary hardware about every 5 years. My i7-950 (about 4 years old) runs tempest at ~400%. So I don't understand the issue here. Tempest is cycle exact now and runs at 400% on four year old hardware.
Index 
Flat 
Re: Noticed some slow-downs....
Reply
