1
0
mirror of https://github.com/TomHarte/CLK.git synced 2024-11-06 12:07:57 +00:00
Commit Graph

55 Commits

Author SHA1 Message Date
Thomas Harte
28fad66272 Okay, so I had those constants transposed. What a klutz I've been! 2015-08-19 09:09:00 -04:00
Thomas Harte
f74d9ee373 Copied in quote. So that I can stop looking it up. 2015-08-18 22:36:32 -04:00
Thomas Harte
a62c7f5c56 At last! Discovered CRT scanning bug; was always moving by the full proposed run length along the scan, not the time until the next event. Using this, have implemented proper vertical sync at last (I think). Have disabled scanline banding too, as now everything meets up it's more helpful to be able to see with clarity. 2015-08-18 22:22:47 -04:00
Thomas Harte
902795d61c Switched vertical sync detection method, at least for now. They never happen automatically (I need to fix that) and just always take effect if detected in the lower half of the display. PAL/NTSC is determined just by looking at the refresh rate. 2015-08-18 00:17:03 -04:00
Thomas Harte
083b678785 Quickie: observed that the initial position is one scanline dirty, not zero. Also switched to a size_t on the write pointer, size_t being the correct C size for into-memory offsets. 2015-08-17 00:25:32 -04:00
Thomas Harte
cde9bb7ebc Put common shift step into a macro. 2015-08-16 16:12:20 -04:00
Thomas Harte
a693c081f8 Switched on the appropriate compiler warnings re: signed comparisons and implicit conversions. Fixed all less-than-explicit calls. 2015-08-16 16:08:29 -04:00
Thomas Harte
b440fed323 Fixed a couple of incorrect references to horizontal constants or calculations where the intention is to use vertical. 2015-08-13 18:29:07 +01:00
Thomas Harte
59c872ada6 Attempted to reintroduce suitably noted emergency flyback. To re-enable auto-selection of PAL. 2015-08-13 14:55:53 +01:00
Thomas Harte
aebf636528 Ensured the PIA timer resumes its normal tick rate after being read; fixed those spaces that had crept in where tabs should be. 2015-08-10 16:55:16 +01:00
Thomas Harte
fd36f13baf The cathode ray view no longer hard codes the frame size. So that's one less coupling. Doubled pixel output size to give sufficient sampling detail to capture the NTSC colour clock (ummm, hopefully). 2015-08-05 21:45:47 -04:00
Thomas Harte
67e82c713f Broke assumption that every item in a vertex description is a short, specifically turning lateral into a byte. Which buys me a byte for phase, if that's sufficient. 2015-08-05 21:12:33 -04:00
Thomas Harte
5644b3a1cc Fixed scanline sizing and fill issues, as well as shortening vsync to the correct Atari length. 2015-08-05 20:55:27 -04:00
Thomas Harte
265d1d5b24 Merge branch 'EdgeTriggeredVSync' 2015-08-05 20:30:02 -04:00
Thomas Harte
84d1c2e47d Fixed end of sync time calculation and ensured the pretend capacitor is emptied by the decision to retrace and doesn't refill during retrace. 2015-08-05 20:29:20 -04:00
Thomas Harte
04c2640b15 Made a quick attempt to allow vsync triggers only on the raising edge of a sync signal. Will need to investigate more thoroughly. 2015-08-03 08:42:05 -04:00
Thomas Harte
5313b48ebd I'm ashamed to admit, I: played with numbers until enough things looked stable such that I can investigate other things. Discovery: my PAL autodetection was way off. Fixed, hopefully. 2015-08-02 20:32:18 -04:00
Thomas Harte
55017b78a5 Made an attempt to unify my variable storage (and, technically, to get beam size correct across the frame). 2015-08-02 19:30:45 -04:00
Thomas Harte
6e52e5df1c Full separate 'lateral' usage is go. Also probably at some point I need to throw in a phase property, which this new flexibility will help with. 2015-08-02 14:32:29 -04:00
Thomas Harte
3ab6585789 Started making the format of data included in a CRTFrame less a matter of variously hard-coded magic constants. Which will allow me to separate the idea of an internal lateral position from the direct texture coordinate, avoiding precision sampling errors at the top and bottom. 2015-08-02 14:25:21 -04:00
Thomas Harte
be421587ad Eliminated the vertical retrace counter; vertical retrace ends when the beam gets back to the top. 2015-08-02 13:48:35 -04:00
Thomas Harte
de4f2bf5dd Maybe the 10 lines resource I saw meant 10 lines including charge time? 2015-07-31 19:00:40 -04:00
Thomas Harte
5f1d76e855 Can't seem to find any documentation: assumed horizontal sync is generated during vertical. 2015-07-31 18:49:02 -04:00
Thomas Harte
c1a12ad4df Fix to make sure end of vertical sync is always correctly spotted as an event, rather than just happening off the books. So I can now watch Joust roll to its heart's content. 2015-07-31 18:15:59 -04:00
Thomas Harte
9c91f1a2eb Added an attempt at NTSC/PAL autodetection, based on number of missed vertical syncs. 2015-07-31 18:04:33 -04:00
Thomas Harte
a5d66e9dd6 Factored out a few more constants, started trying to ensure there's enough slack and the mechanisms in place for the CathodeRayView to hold onto two frames if it desires, for potential phosphor simulation, switched once again to additive blending — much more like a real CRT — and added a sine function across the width of spans per my understanding of how an electron gun actually fires.
Why do all this when overall timing is still so far off? It helps me more easily see how overall timing is so far off.
2015-07-31 17:47:10 -04:00
Thomas Harte
6ad3fbbaf2 Slowed flywheel adjustments a little, the better to highlight phase errors for the time being. 2015-07-30 23:00:54 -04:00
Thomas Harte
cfe758daa0 A tweak here, a tweak there, to help with debugging. 2015-07-30 21:29:40 -04:00
Thomas Harte
20c2d98b9a Converted remaining spaces to real tabs. 2015-07-30 20:51:32 -04:00
Thomas Harte
1fa7a77793 Continuing in my attempts to figure out the complete absence of graphics from some games: there are 262 lines on an NTSC screen, not 256. Also ensured that the CRT has a little spare range at the edges so that its generated triangles don't wrap around just because of integer overflow. 2015-07-30 20:07:20 -04:00
Thomas Harte
98efae2536 Reintroduced emergency vertical sync — so that output occurs even when the emulation isn't catching syncs properly — and switched some spaces to tabs. 2015-07-30 17:16:49 -04:00
Thomas Harte
596d34190c Fixed: write pointer is calculated only after write x and y are known. This is probably the memory handling problem? 2015-07-28 08:15:54 -04:00
Thomas Harte
1f229ee6f7 More tweaks to provide a stable image, at least for the time being. 2015-07-27 20:18:25 -04:00
Thomas Harte
01109d441b Made an attempt at NTSC colours. Hard coded in RGB, not composite. Short cuts, tsk. 2015-07-27 19:04:03 -04:00
Thomas Harte
31e9a53a44 Removed some debugging code. 2015-07-27 16:43:51 -04:00
Thomas Harte
caffe56a2d Slightly expanded width of cathode ray gun, decided to figure out exactly how to deal with off-by-one lengths and precision at a later date, ensured that failure to catch vertical sync doesn't cause out-of-bounds buffer access on the hard-coded, assumed large enough, 512x512 data textures. 2015-07-27 00:28:47 -04:00
Thomas Harte
65bb31d55b With around about a thousand issues, not the least of which being sometimes unsafe memory accesses, I've at last got pixels on screen. 2015-07-26 23:50:43 -04:00
Thomas Harte
dd428c5d4d Slightly relaxed time it takes to recognise vertical sync; considered what to do about reviving proper vertical sync but then gave up. 2015-07-24 23:56:25 -04:00
Thomas Harte
cea2580000 Upped internal precision a little. 2015-07-24 23:36:44 -04:00
Thomas Harte
ecb2898bd5 The overall architecture of who has responsibility for what is now very askew but: the CRT now outputs a tightly packed short buffer, with the probable OpenGL destination in mind. So it's now all fixed arithmetic internally. CRTFrame is reduced to a plain C struct with the intention that the OpenGL view will take responsibility for it and stop doing the back-and-forth sprint on getting buffer data. The Atari 2600 now outputs explicit blanks rather than level blacks for its border, so that it's easier visually to debug the CRT in its form as far as it has currently progressed: to drawing lines where the cathode ray gun would run while outputting pixel. I note that I'm still not quite getting vertical sync right yet — I'm just accepting it anywhere in teh frame — but that should be an easy fix. 2015-07-24 23:29:45 -04:00
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