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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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
> another night)

Hi

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) :

 move.l #vbl,$70
 move.b #2,$ff8260
 lea $ff8209,a0
 moveq #0,d0
 stop $2300
 stop $2300

wait:
 addq.l #1,d0
 tst.b (a0)
 beq.s wait

 # print D0 value after converting it into cycles
 rts

vbl:
 rte


Nicolas