1
0
mirror of https://github.com/TomHarte/CLK.git synced 2024-12-29 13:29:46 +00:00
A latency-hating emulator of 8- and 16-bit platforms: the Acorn Electron, Amstrad CPC, Apple II/II+/IIe and early Macintosh, Atari 2600 and ST, ColecoVision, Enterprise 64/128, Commodore Vic-20 and Amiga, MSX 1, Oric 1/Atmos, Sega Master System, Sinclair
Go to file
2016-05-03 18:15:24 -04:00
Machines Eliminated redundant variable. 2016-04-26 19:57:05 -04:00
OSBindings/Mac It's 2016. 2016-05-02 22:02:06 -04:00
Outputs Tweaks here, tweaks there. 2016-05-03 18:15:24 -04:00
Processors/6502 Attempted to normalise some style decisions.` 2016-04-24 22:32:24 -04:00
SignalProcessing Fixed run extension, temporarily forced colour amplitude. 2016-04-23 14:16:49 -04:00
Storage/Tape Started attempting to clarify instance variable usage. 2016-03-12 23:19:10 -05:00
.gitignore
LICENSE
README.md Switched from asterisks for footnote marks, per Markdown requirements. 2016-04-25 13:09:35 -04:00

CLK

An attempt to unify various bits of emulation; features:

  • a best-in-class emulation of the Acorn Electron; and
  • a mediocre emulation of the Atari 2600.

All code is motivated by a signals processing approach and a distinction between execution units and bus logic.

If simulating a TV, the CRT emulation uses your GPU to decode (and, as required by the emulated platform, possibly to encode) a genuine composite video stream — dot crawl et al are present and correct as a natural consequence, not as a post-processing effect. If a machine generates audio at 2Mhz then the source wave is modelled at 2Mhz and a standard windowing filter produces a 44Khz-or-so stream.

The hard emulation parts are C++11 and assume the OpenGL Core Profile; an Objective-C++/Swift UI binding for the Mac is present, making this completely native for Mac users. The intention is to provide additional OS bindings and ensure operation within ES 3.0 environments.

TV Emulation

Composite decoding is currently performed purely by notch filtering; this produces worse separation than a comb but remained the predominant method for cheap TVs into the 1980s so is nevertheless not unrealistic. As I have yet to introduce any sort of inter-line processing, when running in PAL mode mine is the equivalent of a PAL-S. Since all signals propagate within a closed circuit there's no opportunity for a phase change that would produce Hanover bars but it's probably something that needs addressing regardless.

I've hesitated on a comb since it becomes complicated with machines — including the already-supported Atari 2600 — that use a not-strictly-conformant line length†, or, more substantially, with those that reset phase every line††.

† per the documentation, its 228 cycles per line make each of its pixels exactly one NTSC colour clock long. There are 228.5 NTSC colour clocks per line so its hardware would appear to produce shorter-than-specified lines (albeit still well within tolerable variation).

†† I suspect that a real TV will switch to a notch if adjacent colour bursts appear to keep resetting the colour oscillator, amongst other sanity checks, as analogue delay lines have a physically-fixed duration. I just need to do the same.