1
0
mirror of https://github.com/TomHarte/CLK.git synced 2024-12-25 03:32:01 +00:00
Commit Graph

115 Commits

Author SHA1 Message Date
Thomas Harte
d72287a776 Looked up normal retrace time (it's a lot less than 16µs and 26 scanlines — more like 7 and 10) and that the visible portion of a line is defined to start about 12 µs after the start of hsync, put the first two numbers into my CRT to make that more accurate, then derived a newer guess about what the Atari 2600 does for each of its 228 cycles. The text version of a frame is now looking pretty good. So it's probably time to hit OpenGL and the OS X side of things. Though I'll have a quick look to find out whether I can learn the exact real Atari 2600 timings before moving on. 2015-07-23 19:24:25 -04:00
Thomas Harte
33c06baffa Explicitly separated vertical and horizontal sync event tracking, so as explicitly to be able to handle a coincidental simultaneous occurrence of both. Also for clarity. 2015-07-23 18:53:18 -04:00
Thomas Harte
5203f31bf4 Reintroduced a console examination of the output runs being received after fixing a failure to complete or restart frames over in the CRT; weirdly it seems that sync is being obeyed but raster position is off. So work to do. 2015-07-22 20:45:10 -04:00
Thomas Harte
065050115f Made an attempt to switch to a triple-buffering scheme for CRT outputs, with an eye towards asynchronicity. 2015-07-22 20:33:20 -04:00
Thomas Harte
b503e13380 Fix one: vertical scan speed was failing to allow for the number of cycles in a line. 2015-07-22 18:56:35 -04:00
Thomas Harte
963cb2f6fb Attempted to switch to slightly more meaningful names within the CRT and implemented a delegate to investigate output. Working on it. 2015-07-22 18:15:18 -04:00
Thomas Harte
908c171d2d Commented the heck out of this thing, to put my thoughts in order if nothing else. 2015-07-21 16:37:39 -04:00
Thomas Harte
a1a1b15d18 Made a quick attempt to accumulate a list of detected output runs. Which means finally having to specify normal frame height. I'm already at too many magic formulae though, so this will need proper revision when I'm next awake. Definitely my horizontal position advancement is way off. 2015-07-20 23:18:56 -04:00
Thomas Harte
4fa315ab4d This looks a lot closer to correct. The loss of horizontal sync during vertical sync is odd but the two should be fully decoupled in here. I'll have to check. Probably I've got something wrong. There are approximate sinusoidals when re-establishing sync, so that's promising as to the flywheel. 2015-07-20 21:58:32 -04:00
Thomas Harte
4695295dd1 Made complete attempt at sync discrimination. But I seem somehow to be locking such that horizontal sync is in the middle of the line. Obviously my flywheel is at fault somehow. 2015-07-20 21:43:00 -04:00
Thomas Harte
4e4c082a05 Made some minor attempt at proper sync response. I think I've gone way off piste and overcomplicated it. 2015-07-19 23:43:22 -04:00
Thomas Harte
4a1e9fe2a8 Rephrased the CRT as owning an arbitrary number of buffers and vending storage space for pixel output. That much better maps to potential implementations of this thing in GLSL, with ES 2.0's limitations kept in mind. 2015-07-19 21:21:34 -04:00
Thomas Harte
7df5025eef Started sketching out the delegate interface that will allow a branch from the CRT into whatever native display system is used by a particular platform. 2015-07-19 18:32:42 -04:00
Thomas Harte
6f78ecdc9c Made first genuine attempt at outputting a meaningful CRT stream. Which shows some significant errors. So work to do. 2015-07-19 16:48:14 -04:00
Thomas Harte
2d0f861474 Incoming: a 'CRT' class, to receive information intended for a cathode ray tube. To decode sync, etc. 2015-07-19 13:36:27 -04:00