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
|
14adcd2096
|
Had a quick bash at timer overflow.
|
2015-07-30 16:09:32 -04:00 |
|
Thomas Harte
|
58908b60ac
|
So, provisionally: this looks like (i) the one cycle to write; plus (ii) the number of cycles to get to the end of the pixels (which is _horizontalTimer+1 for me because _horizontalTimer = 0 is a pixel); plus (iii) one cycle of latency to wake up. Am I making that up? Time will tell.
|
2015-07-30 15:49:38 -04:00 |
|
Thomas Harte
|
f5475369d6
|
Fixed foreshadowing of sprites yet to come. Put flipMask back the other way around.
|
2015-07-30 12:07:28 -04:00 |
|
Thomas Harte
|
f653b5dff3
|
Made a first tentative attempt at supporting all eight sprite modes.
|
2015-07-30 11:52:28 -04:00 |
|
Thomas Harte
|
151c6b4421
|
Quick fix: add one cycle to get to the genuine end of the line (i.e. after cycle 0, not on it). Not 3, with the video then becoming desynchronised from the CPU clock.
|
2015-07-30 00:00:35 -04:00 |
|
Thomas Harte
|
d1ae2caf91
|
Did the absolute minimum necessary to get some sprites showing in some capacity.
|
2015-07-29 23:48:52 -04:00 |
|
Thomas Harte
|
23df94d011
|
Got at least as far as putting a single dot at the player 0 and player 1 positions. Which may or may not be accurate.
|
2015-07-29 22:37:37 -04:00 |
|
Thomas Harte
|
164866d613
|
Collapsed two methods into one, to avoid redundant pixel copying.
|
2015-07-27 22:12:13 -04:00 |
|
Thomas Harte
|
3c25ead1f3
|
Started working out some of my retain cycles and general failures to release. Switched .mm filename so that Xcode will stop getting confused when I try to switch between implementation and interface files.
|
2015-07-27 21:15:10 -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
|
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
|
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
|
8efd449834
|
Switched to a down counter and a reset test that remains unconditional but doesn't depend on % (which seems to turn into a big imul-powered deal). Probably pointless mulling around the edges at this point.
|
2015-07-26 15:45: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
|
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
|
529f61caa1
|
Removed a stray newline.
|
2015-07-22 20:45:21 -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
|
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
|
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
|
4d1e410150
|
Fix 1: _horizontalTimer should be treated as read only out here.
|
2015-07-19 16:51:11 -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 |
|
Thomas Harte
|
03a25c8ff2
|
Fixed playfield pixel logic.
|
2015-07-19 10:56:04 -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
|
6558ae1425
|
Imported what little I have so far in the way of a memory-access cycle complete 6502 and just enough of a pretend Atari 2600 on top to be able to see some playfields in ASCII art.
|
2015-07-16 19:56:02 -04:00 |
|