1
0
mirror of https://github.com/TomHarte/CLK.git synced 2024-11-24 10:31:15 +00:00
Commit Graph

527 Commits

Author SHA1 Message Date
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
cd0a62d21e With a slight tweak to the informal protocol used for 6502 memory access cycles, ensured the wait strobe actually halts the CPU, to give a more accurate linking of machine time to real time. 2015-07-26 15:55:19 -04:00
Thomas Harte
6252f6030f Switched to idiomatic source name, ensured latest project name is in all appropriate header places, threw texture coordinates slightly into the shader mix. 2015-07-26 15:25:11 -04:00
Thomas Harte
e53fbcf9ea Reshuffled to make the OpenGL view explicitly a conduit for CRT-style output, and to give it responsibility for frame drawing. Which is still an awkward thread hop for the time being, but I've yet to read up on the advocated approach to multithreading with an NSOpenGLView; it looked like special provisions were available. 2015-07-26 15:13:46 -04:00
Thomas Harte
78a91b67c5 Quickie: make sure the correct context is adjusted; use the intended convertPointToBacking:. 2015-07-24 23:42:19 -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
5ab47e600a Got through the requisite amount of invisible pain to get something onto my GL display. But clearly this is factored in entirely the wrong way. Work to do. 2015-07-24 20:37:08 -04:00
Thomas Harte
31338ef754 Okay; having no minimum size is a user experience nightmare. Fixed. 2015-07-23 22:54:17 -04:00
Thomas Harte
44e8ffd01c Ensured windows start and remain 4:3, made sure I request a GL 3.2 context and that an exception is raised if I call any old-fashioned GL functions. 2015-07-23 22:51:53 -04:00
Thomas Harte
02c786520a More fiddling in the margins in advance of doing the OpenGL stuff: window now supports full-screen display. 2015-07-23 20:53:26 -04:00
Thomas Harte
b9721d1d3f Okay, treading water slightly, ensured window content is correct aspect ratio. 2015-07-23 20:50:50 -04:00
Thomas Harte
7276c77027 A full communication pathway now leads to Atari2600.mm (for now) being in possession of a frame and receiving a command to draw, with a suitable OpenGL context being active and whatever is drawn subsequently appearing. 2015-07-23 20:45:07 -04:00
Thomas Harte
0611646181 This then is what the serial dispatch queue and the triple buffer achieve together: I can post the runs over to the main thread for processing while emulation continues separately. 2015-07-23 20:16:48 -04:00
Thomas Harte
e7237c7bd5 Switched to forcing all processing onto a common queue and piping the completed frame over into the Objective-C class. 2015-07-23 20:07:35 -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
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
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
Thomas Harte
12746b35e3 Ensured there's no overflow while changing base. 2015-07-19 10:54:19 -04:00
Thomas Harte
412e02fdd8 Merge branch 'master' of github.com:TomHarte/CLK 2015-07-19 10:52:15 -04:00
Thomas Harte
e0aa1e9f19 Minor project rearrangement to aid findability. 2015-07-17 09:10:23 -04:00
Thomas Harte
195c8a87d8 Introduced enough logic that the Atari 2600 is being run, at least. No output yet though because (i) it has no-one to send output to; and (ii) there's nobody that knows how to display output. Hmmm. 2015-07-16 22:14:40 -04:00
Thomas Harte
4496493e85 Performed the bare necessary steps to get my little OpenGL view to create a CVDisplayLink and then repaint itself in time with the display. 2015-07-16 21:16:21 -04:00
Thomas Harte
1df2c48668 Introduced my GL view as the window content. 2015-07-16 21:01:49 -04:00
Thomas Harte
5160b6bbb8 Separated out different test suites into different XCTest subclasses. 2015-07-16 20:52:16 -04:00
Thomas Harte
3e0679235a This now goes just far enough to create an instance of Atari2600::Machine and push a ROM to it. Next jobs are to get a basic CRT emulation wired up, outputting to the window. 2015-07-16 20:40:46 -04:00
Thomas Harte
24c0579b94 Shuffled things and guessed at things until the Xcode project was happy being subservient to the project proper. 2015-07-16 20:27:31 -04:00