From 51c1562eeeb09e17bb07710e8eb7201c06da5302 Mon Sep 17 00:00:00 2001 From: Thomas Harte Date: Mon, 25 Apr 2016 10:19:51 -0400 Subject: [PATCH 1/3] Update README.md Provided further exposition --- README.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index e401b924b..413ba9411 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,10 @@ # CLK -An attempt to unify my various bits of emulation; we'll see. +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. From 3341e3550b231a56b641537ff4fad46a18600055 Mon Sep 17 00:00:00 2001 From: Thomas Harte Date: Mon, 25 Apr 2016 13:08:22 -0400 Subject: [PATCH 2/3] Filled in some detail on the TV emulation. --- README.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/README.md b/README.md index 413ba9411..1d996b46c 100644 --- a/README.md +++ b/README.md @@ -8,3 +8,13 @@ All code is motivated by a signals processing approach and a distinction between 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. From 973a53744b20341e49180d36cdc6ac2690751004 Mon Sep 17 00:00:00 2001 From: Thomas Harte Date: Mon, 25 Apr 2016 13:09:35 -0400 Subject: [PATCH 3/3] Switched from asterisks for footnote marks, per Markdown requirements. --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 1d996b46c..dea9d6b80 100644 --- a/README.md +++ b/README.md @@ -13,8 +13,8 @@ The hard emulation parts are C++11 and assume the OpenGL Core Profile; an Object 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**. +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). +† 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. +†† 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.