If so then today's your lucky day! See attached. It's too work-in-progress yet to justify a formal release anywhere but:
- it's the only emulator that gets the timing right per Dave/hoglet's ever-more-thorough investigation, e.g. everything at http://www.stardot.org.uk/forums/viewto ... =3&t=10069;
- ... which includes producing an interlaced display.
- it's also an ordinary, document-model native app;
- ... so you can run as many Electrons as you like simultaneously;
- ... and normal, properly constrained window resizing rules apply.
- it endeavours to get the DSP side of things correct;
- ... so e.g. audio output is formulated as a 125Khz wave that's subjected to a 22Khz lowpass filter. Sampled speech works, no special cases.
Composite video mode is coming but is temporarily disabled as I've had a bit of a thorough reworking of the OpenGL side of things, endeavouring better to stream (at least up to the somewhat artificial ceiling enforced by Apple's lackadaisical attitude towards GL, though that's arguably academic since my GPU supports only 3.3 anyway).
I'm not sure progress is immediately going to be too speedy as I'm going on holiday this Friday.
* Atari 2600, since you ask. But temporarily broken because that's a composite-only machine. Will crash through failure to conform to the current threading model, as I've been ignoring it. Don't try.
It's a clean cross-plaform core that just currently happens only to have a Mac front-end. OpenGL core profile support is really the only required library. I'm going to ensure ES compatibility but it'll be 3.0 (~50% of Androids right now; every iPhone since the 5s and iPad since the Air). I want slightly to simplify the host to emulation interface before I document it — after that it should be fairly trivial to add a Qt front end and/or a Winforms front end and/or an SDL front end, etc. But I'm concentrating on the CRT stuff for the time being, to reduce CPU to GPU bandwidth* further and to bring back composite video.
* each scan currently costs 640 bytes of pixels plus 96 bytes of geometry; scans are literally a record of raster sweeps and don't need a consistent pixel clock so I can easily change that to 160 bytes for Modes 5 and 2 and 320 for 1, 4 and 6, and half again if I fancy putting two pixels in a byte, and through instancing I can drop the per-scan cost at least to 24 bytes. There's some rounding up due to the desire to pack scans as linearly-addressed subsections of a single 2d texture and because frame draw is permitted to interrupt emulation (as window events are timed arbitrarily) but for most Electron games that'd be a reduction from 736 bytes/line to possibly 104 bytes/line, so if bus bandwidth is a bottleneck then that's an 85% reduction there. Or more than 6 and two-thirds frames in the amount of data I'm currently taking to describe one.
On my 2011-vintage machine, ElectrEm occupies 12–13% of a core while running. With some additional optimisations last night, this hangs around the 19–25% range. Which is not unexpected, since it pays for the abstraction that makes it a multi-machine emulator, and well within the range of current mobile and embedded devices. But it'd be nice to get it down a bit, even if just because arbitrarily many simultaneous Electrons means arbitrarily much processing. And who likes it when their fans come on?
(EDITED: updated version attached. Will continue to try to keep the latest version up here unless or until this actually gets uploaded somewhere formal. The name, Clock Signal, is inherited from my ZX80/81 emulator with the intention the two things will fold together, and because I own clocksignal.com. So it has somewhere to go, eventually)