1
0
mirror of https://github.com/TomHarte/CLK.git synced 2024-06-09 17:29:36 +00:00

Added a small pictorial example. Hardly the best, but a step in the right direction.

This commit is contained in:
Thomas Harte 2017-01-12 22:06:45 -05:00
parent 4a4b31a15c
commit 6f78ecd12b
3 changed files with 6 additions and 0 deletions

View File

@ -30,6 +30,12 @@ Similar effort is put into audio generation. If the real machine normally genera
If your machine has a 4k monitor and a 96Khz audio output? Then you'll get a 4k rendering of a composite display and, assuming the emulated machine produces source audio at or above 96Khz, 96,000 individual distinct audio samples a second. Interlaced video also works and looks much as it always did on those machines that produce it. If your machine has a 4k monitor and a 96Khz audio output? Then you'll get a 4k rendering of a composite display and, assuming the emulated machine produces source audio at or above 96Khz, 96,000 individual distinct audio samples a second. Interlaced video also works and looks much as it always did on those machines that produce it.
Classic emulation:
![The Electron start screen, with a classic 1:1 pixel emulation](READMEImages/NaiveElectron.png)
Composite CRT emulation:
![The Electron start screen, decoded from an interlaced composite feed](READMEImages/CompositeElectron.png)
## Low Latency ## Low Latency
The display produced is an emulated CRT, with phosphor decay. Therefore if you have a 140Hz monitor it can produce 140 distinct frames per second. Latency is dictated by the output hardware, not the emulated machine. The display produced is an emulated CRT, with phosphor decay. Therefore if you have a 140Hz monitor it can produce 140 distinct frames per second. Latency is dictated by the output hardware, not the emulated machine.

Binary file not shown.

After

Width:  |  Height:  |  Size: 19 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 309 B