Re: [hatari-devel] looking for someone with a mono monitor

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Well, of course I had to try my theory based on the state machine ;) This is all of course information simply for the fun of it.

There's no problem making the actual switch stable - that's a simple case of sync locking and switching at the correct position.. I didn't manage to stabilize the Shifter with the tests I just did however (thus the garbled graphics), which were all done on my STE. Maybe things are different on STF (and possibly in different wakestates).

I can't say the result matched what I expected exactly (an easy gain of 80 pixels) - it seemed more to just extend the line beyond HBLANK as well - so whether it was a state-machine success or not I'm unsure.

What makes removing the right border very different in mono compared to low/med is that it must be done using a resolution switch - and as soon as the switch away from mono happens the signal is no longer output from the shifter. That means that the actual switch itself will invert the graphics on the screen. A naïve move.b/move.b switch will lose 64 pixels while a clr.b/move.b (same trick as "NoCrew 4 pixel rasters") will only lose 32 as in the attached picture.

(I forgot to test opening a lower border - that will have to wait for another night)

/Troed



On Fri, Oct 3, 2014 at 10:33 PM, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:
Le 03/10/2014 21:13, Troed Sångberg a écrit :
Next time I have my STF connected I will try this, however, it should be
possible to deduce what can be done from the research I've done into the
GLUE state machine. So, I'll wager a guess that they remove the right
and lower borders. Top and left I don't see how that could be done - the
mono line start timing is what's used for left border in the other
screen modes and Alien documented mono screen start to be the same as
60Hz screen start (i.e, top border position in 50Hz).

If so, it's done by _not_ being in mono at cycle 164 on each line (and
letting HBLANK at 184 take care of line end) as well as making sure not
to be in mono at the end of (mono) line 400 (should correspond to ~212.5
in 50Hz timing-speak).

The latter position I'll definitely research since it's not documented
in the state machine at the moment ("mono screen end") - and the likely
accompanying "mono vblank" as well.

/Troed


Hi

Miguel Saro / Cocoapos posted a video here http://cocoa.pod.free.fr/P1050814.mp4

As you can see, it more or less removes right border, but not bottom border, but it doesn't seem really stable in fact.

Nicolas




Attachment: DSC_0035.JPG
Description: JPEG image



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/