|Re: [hatari-devel] looking for someone with a mono monitor|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 05/10/2014 22:42, Troed Sångberg a écrit :
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
by the way, regarding top/bottom border, did you measure at what HBL
display starts/stops in mono screen ? (this is something I haven't done
yet on my STF).
for example something like this (set an empty VBL and wait increment a
counter until video address changes) :
# print D0 value after converting it into cycles