Closed thrust26 closed 7 years ago
Thanks for the pointer in the right direction. The conclusion that I draw from debugging is the following:
Even and odd frames are shifted relative to each other by one pixel in order to get nice circles. It seems that, similar to RESPx during draw counter decode, there are side effects of NUSIZx during draw counter decode on the decode circuit, leading to a delay on each odd frame. In fact, you can see that the code tries to compensate for that by reloading GRPx with the pattern shifted one bit to the right when drawing the second copy (resulting in a two pixel shift left since the player is wide and reflected).
In d77d2f2, I have tried to model this delay, and the result in phosphor mode looks pretty much perfect to me
As I cannot compare yet to real hardware (and can't find any footage of the real thing out there on the web), I have built a windows test binary. However, this is crosscompiled from linux using mingw, so it is pretty limited and should really be only used for testing --- in particular, it needs -video software
, doesn't support joysticks and is build with -O0
:smirk:
stella_e618a6c_test.zip
That download doesn't work for me (crash). And without joystick, I cannot test well anyway.
The screenshot looks OK, but you can check your solution yourself:
Hmm, too bad. With 'without joystick', I meant 'without gamepad / joystick support'; of course, the cursor keys work fine, at least in wine. Too bad it doesn't work on real windows.
Cursor alignment is interesting; it is different between the four columns, but funnily, the rightmost ones look correct to me. I'll crosscheck with MESS.
Can you make screenshots with the cursor being on the left and right?
The alignment of the old core above the left two columns is correct.
Also, interestingly, the four columns are equistant already, so any error should likely be a total shift.
All rods look shifted by one pixel to the right.
OK, next try, I indead have found a typo I made when fixing Missile Command. Fixing this has now shifted the left rods one pixel to the right. Do you still think the right rods should also be shifted by one pixel (currently, they are not strictly equidistant any more)?
Assuming the old core is correct here, the cursor is at 28, 61, 92, 125. Since on real hardware all rods are aligned identical to the cursor, this means that the gap between column 2 and 3 is different.
Still another try. The gap between 2 and 3 is now noticably different, but the cursor is really the same for all columns
. What do you think?
Looks correct now.
Great :smirk: I'll crosscheck with MESS once it has finished compiling and will close the ticket after that. Thanks for your time, Thomas.
39ee43e matches MESS.
Thomas, here is a Windows build for you to test the latest changes: http://minbar.org/Stella-5.0.0-pre2.5-windows.zip
Also, HOLY CRAP. This last commit or two fixes the rendering issues in "Mega Bitmap Demo", which I've never seen work in any emulator up to this point! See the following snapshots.
From the old core, where it was completely broken:
From MESS, which was the closest so far:
With the most current code:
Yay! :)
🤘Even on 6502.ts, and even on my mobile (that's where I just tested it) 😀.
BTW: The 32 character demos are all working correctly with the new core too.
http://atariage.com/forums/topic/180632-32-character-text-display
The right two rods do flicker not together correctly.
Reason: The non-reflected copy displays 1 pixel too far left, the reflected copy 1 pixel too far right.