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

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


Hi Carsten,

(And thanks Thomas for the comments on my STNICCC talk ;))

Let me add some current insight regarding what you write about your mono demo - and yes - you're probably the one that innovated the most in that resolution mode :D

On Sun, Nov 27, 2016 at 1:55 PM, Carsten Jacobi <carsten@xxxxxxxxxxxxxxxxxxx> wrote:
 
The demo should open the right border and should also - in some respect - open the left border (but here I just saw a "gain" of maybe 4 to 8 pixels).

The right border can indeed be opened "as usual" in mono. In color the border can be opened both with a frequency switch (which everybody does) or by resolution (which, as you also see in mono, causes black pixels for the duration of the resolution switch). I've replicated this myself when researching the "state machine".

Left border cannot be "opened" - the earliest possible display start is the mono one, that's why it's used in color. What can be done however is to cause the Shifter to be "preloaded" with some words already available sooner. I'm assuming this is what you manage to do. It will of course cause graphics to be displayed "earlier" so in some sense it's could be considered to be semantics.
 
You should also see a picture wobbling up and down and the funniest feature should be seeing the "colour" grey (and I really mean grey, no interlace!) on an SM-124 monitor.
I found switch spots that made an STF (indeed I played with this on my 1040STF) skip lines (that's why scrolling the full picture without wasting mem is possible). The left border then does not "open" the same way it does in colour mode. Instead, the line is "shifted" 4 to 8 pixels to the left end also "ends earlier". However, the right border "opens" and that to a really long extend ... the grey part will remain my secret, demo programmers should not disclose to much to keep the "community" challenged >8-E3= (if you really want to know, you already have the source ... the only drawback is that the comments may be in "native language")

Scrolling using 0-byte lines is quite effective - there exists ways to do it "cleanly" and ways to do it that disturb sync and might work on analogue monitors but not digital etc. I don't know which method you use but while clean 0-byte lines were tricky to do in color they should actually be quite easy in mono (i.e, not needing understanding of wakestates). What you do is to skip the regular line start.
 
I was even able to draw graphics in the lower border ... but only on "some models". I switched to external synchronization for some cycles and then back to internal synchronization. That made the MMU begin a completely new frame (starting with the video-counter at the new-VBL address again even though the frame didn't end yet!) and so even vertical screen splitting was possible. On monochrome, the "newly begun" frame then could also extend into the lower border, so the actual "opening" of the lower border as in colour mode didn't take place ... I never found a method how to do that in monochrome.

I haven't been able to do a regular lower border opening (by switching mode so that the screen does not end) either, Ijor has commented that the spot needed is the exact same as for the hsync pulse which means it's impossible. However, the very latest ST sync tricks development is that we're not able to not only poke values at 2 cycle intervals but also in some cases with 1 cycle precision. It's on my todo to see if that would make a regular lower border possible.

However! What you just described above sound amazing - and would be the first time external sync (oh how much I tried doing tricks with it in color in the good old days .. ) has been used for any sync trick - and a proper _split screen_ at that is incredible! I need to think about this for a while - my naïve first guess would be that you manage to skip the actual vsync pulse but not the reset-vbase that happens during the vsync phase. If so then there's an 800 lines long 30.5Hz frame being displayed which would be very much non-sync-clean ... but I'll have to look into it.

I wanted to know how "compatible" screen splitting would be (one example is that on the STE in contrast to the STF you had to stay in monochrome mode for 20 and not just for 16 cycles to open the left border, so there are demos that open the left border but are not "STE"-compatible) to other STs, so I started my prototype on 7 different STs on one demo party ... and only 2 of them started a new frame after the External/Internal synch switch, the others just showed "black" as long as the ST ran with external synchronisation. One striking fact was that those 2 STs were my 1040ST and the other was a 520ST with a "13 line Glue-Chip", my was a "29 line Glue-Chip" (that measure refers to the size of the upper border in colour 50 Hertz).

This, like Thomas said, is surely all about wakestates. The fact that it did work on both short and long top-border GLUEs should mean it works on all STFs. STEs would need verification. For your info, the GLUE and MMU can be offset 0-3 cycles selected "at random" (but with huge machine dependent attractors) at cold boot. This affects when you from the CPU need to poke your values into the freq and res registers - see this wiki page for my documentation of this phenomena: http://www.atari-wiki.com/index.php/ST_STE_Scanlines

If you ever feel like coding again, I've published a one line wakestate-detection routine that tells you which ST wakestate (or if it's an STE) you're currently in, by manipulating the GLUE and checking the results.

was, that the spot where you have to open the right border in monochrome depended on moon wetness, weather situation, whatsoever .... it was different any time I turned on my ST. So I had to "extend" the time I switched to colour mode to make sure the "critical spot" was within that time, hence I had to stay in colour mode for more than 24 cycles (would have to look into the source to see for how long).

The shortest switch I know how to do is 4 cycles long, 16 pixels in mono, and if you know which wakestate you're in you don't need better accuracy than that (actually 1 cycle would do, but I know of no way to do such a switch back'n'forth). 
 
It was a surprise for me to see, that 20 years after I wrote this people still tried to run my screen.

 
:D Doesn't it feel great?

/Troed of SYNC



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