Hardware Overscan

[Steven Seagal]

This too was requested in another thread, support for hardware hacks that intercept the 'DE' line between the GLUE and the Shifter.
Hence only possible on the STF/Mega ST.

Little teaser pictures but it's just a dirty hack (how appropriate) in Steem for the moment.

Steem_lace_02.png

It is with borders on!

Steem_lace_01.png

What is "Off"?

Any info you have is welcome.
Basic use (in addition to the hyp file).
Does it work at 60hz?
Is the picture shifted on the left, the right?
How many lines are displayed? Where does the overscan start? Sooner than in fullscreen demos (line -29)?
In low res, the overscan lines are 236 byte long. In high res? (not tried yet)

A potential problem is that adapting Steem display sizes would be a pain.

Another one in med res:

Steem_lace_03.png

But if you check GEM options, it is "med res" also in low res.

[Steven Seagal]

Now in high res:

Steem_lace_04.png

Steem_lace_05.png

Maybe this can be improved (centring?), it's just a temporary hack.

For reference, no overscan:

Steem_lace_06.png

To answer my questions, lines are 100 byte long (80 normal + 20 overscan).
What was the max resolution on a SM124 monitor? (here it's 704x480)
I think "off" is some offset in the video ram, bytes that are not displayed.

[bj]

Great thanks. Looks like a useful size increase in High Res.

[Steven Seagal]

More teasers.
But I can't find images/videos, maybe it wasn't that big in the ST community after all?

[Steven Seagal]

Steem_lace_09.png

This is the circuit as documented.
Maybe the experts here can deduce what it's doing exactly, if it's detailed enough?
Notice the switch (ACIA RTS) isn't emulated in Steem because hardware overscan is emulated as a new ST model, you don't switch it off.

[AtariZoll]

I made overscan circuit, not exactly same as that on schematic - it is with simple mechanical switch instead flip-flops. It is still in my Mega ST. But I did not use it in last 10 years for sure
The principle is simple: instead original /DE from Glue using vertical and horizontal sync. signals - properly combined, they will make longer /DE duration in 1 hor. line - so more pixels, wider pic. , and it will be active in more lines - so higher pic. And less border, of course.
I don't think that it was ever much popular. Number of SW what worked in it was pretty limited - practically only those which used not rigid line size.

[Greenious]

Hardware overscan on the ST works with every well written gem programs, and I knew many people using it on their STs. If it works with a graphics card it works with overscan.

It actually works in all modes, 50/60Hz and mono. But unfortunately in 60Hz there are some things that don't work so well with gem itself, even though you do indeed have working overscan.

The original overscan-archive contains a lot more technical details about the actual workings of overscan, exact screen sizes and such.

Lacescan improved upon the switching by syncing it to vblank in such a way that you seldom had to "toggle" to get it working, often with the original overscan circuit you had to toggle it a few time for it to display correctly, also it was a pure "manual" switch...

And of course, using the unused RTS pin on the ACIA to make everything controllable by software so that you automatically can disable overscan when you start software that's incompatible, etc.

From original overscan archive:

Code: Select all

The difference between 50 and 60 Hertz color mode :

In 50 Hz mode with using the Composite Sync signal You have 236 Bytes
per scan line.
210 Bytes are visible .
The other 20 Bytes aren't visible because of horizontal flyback
blanking ( the BLANK signal of the GLUE is doing his job during this
time period !)
Well, 236 Bytes can be divided by 4 , this is what GEM needs.
So 50 Hertz GEM SHELL installation is no problem.

In this moment our Overscan.PRG (version 1.6) runs the GEM SHELL only in
50 and 71 Hz.

In 60 Hertz mode You have 234 Bytes per scan line.
This is only dividable by 2!
So it might be that we will get GEM only to work in Mid-Res-mode in 60
Hz, but a special written Cyberpaint could also handle 60 Hertz, if the
color palettes are adapted the right way in Lowres.
There would have to be 2 different versions of Cyberpaint like Spectrum
512, because in 50 Hz there are 512 clock cycles and in 60 Hz there are
508 Clock cycles per scan line.
In 60 Hz there are also only 238 visible scan lines instead of 284 of the
50 Hz mode.
----------------
Aufl”sung  Breite  H”he   BytesProZeile  Theoretische Breite  Offset
---------------------------------------------------------------------
Niedrig     400     280       236             464              252
Mittel      832     280       236             928              248
Hoch        672     480       100             800             9800

Die Breite ,H”he und Offset sind jeweils Monitor abh„ngig und mssen
eingestellt werden. Die bisher erreichten MaximalWerte auf blichen
Monitoren mit geringer Modifikation (Verschieben und Verkleinern des
Monitorbildes mit den vorhandenen Monitorreglern) :

    Fernseher     : Niedrig 416x280, Mittel 848x280
    SC1224        : Niedrig 400x280, Mittel 832x280
    SM124         : 688x480
    NEC-Multisync : Niedrig 432x280, Mittel 864x280, Hoch 732x480


As you can see, screen size in bytes almost doubles, but the actual visible screen depends on you monitor.

[Greenious]

Steem_lace_09.png

This is the circuit as documented.
Maybe the experts here can deduce what it's doing exactly, if it's detailed enough?
Notice the switch (ACIA RTS) isn't emulated in Steem because hardware overscan is emulated as a new ST model, you don't switch it off.

It's a more advanced switch circuit, the flip-flop sync the switching with v-blank, the original circuit would just be a toggle switch to feed the new DE to mmu/shifter, which often required you to do it several times to get a working, in sync, overscan. But having the circuitry sync the switch with vblank more or less eradicated that problem.

The switch in lacescan toggles between off/auto. With auto letting the ACIA RTS control overscan on/off.

[Greenious]

This too was requested in another thread, support for hardware hacks that intercept the 'DE' line between the GLUE and the Shifter.
Hence only possible on the STF/Mega ST.

Little teaser pictures but it's just a dirty hack (how appropriate) in Steem for the moment.

What is "Off"?

Any info you have is welcome.
Basic use (in addition to the hyp file).
Does it work at 60hz?
Is the picture shifted on the left, the right?
How many lines are displayed? Where does the overscan start? Sooner than in fullscreen demos (line -29)?
In low res, the overscan lines are 236 byte long. In high res? (not tried yet)

A potential problem is that adapting Steem display sizes would be a pain.

Off is offset between end of line and next line. There are bytes read/counted by mmu/shifter that never makes it to the screen.

Hardware overscan does work in 60hz aswell, but each line is 234 bytes in lowres which causes problems with gem. I don't know if lacescan ever solved that problem.

The original overscan hack contains a lot more technical info pertaining to actual screen sizes etc, I should have thought of that...

[Steven Seagal]

The original overscan-archive contains a lot more technical details about the actual workings of overscan, exact screen sizes and such.

Thx for all this info, helps a lot. Is that original overscan-archive available somewhere? I don't think I saw such precisions in the 'lascan35' archive.

And of course, using the unused RTS pin on the ACIA to make everything controllable by software so that you automatically can disable overscan when you start software that's incompatible, etc.

I misunderstood that, I thought it was some hardware switch, which of course doesn't make sense if it's connected to that pin.

Off is offset between end of line and next line. There are bytes read/counted by mmu/shifter that never makes it to the screen.

I found Off to be close to the #bytes of video ram Steem should skip at the start of the screen.

[Greenious]

Yes, the original hack can be found here:
http://atari4ever.free.fr/hardware/zip/overscn3.zip

Inside the zip, overscan.doc (in german) and overscan.txt (english) contains everything you need I think. Some stuff is unfortunately only covered in the german doc. But I think it is obvious enough.

Tbh, I've more or less only installed and used the overscan mod, so I'm not really that good at the technical aspects of it, but while it works, it is slightly different from software overscan, and I don't think I can explain it better than the original docs.

But if something is unclear, just ask. I'll do my best...

[Steven Seagal]

Right, in fact I did download it before but didn't realize it was a previous version of the same hack. Authors are not the same.
Now I will read it carefully. Thx again. And if you have some pictures...

[Steven Seagal]

Hardware overscan had to be impressive at claimed 420x284, which is bigger than a fullscreen demo.
But LaceScan doesn't feature this setting, only 416 and 432x280.
# scanlines is no big problem, but #horizontal pixels is, in Steem it should be a multiple of 8 (same kind of problem as in GEM!) or rendering is too complicated, so we're limited at 416 max.
Only some monitors were able to display that much.
That is in low res.

Max size for Steem in med res is 832x280.

Steem_lace_11.png

Steem_lace_12.png

In high res, Steem's normal border size is enough for 768x496, which is beyond the SM124 and other monitors.
Higher sizes show rendering issues like here, the impossible 800x496:

Steem_lace_10.png

Code: Select all

    Fernseher     : Niedrig 416x280, Mittel 848x280
    SC1224        : Niedrig 400x280, Mittel 832x280
    SM124         : 688x480
    NEC-Multisync : Niedrig 432x280, Mittel 864x280, Hoch 732x480


Note than I doubt the NEC measures, >420, the ST will HSYNC (and BLANK) before?
Also, the med res horizontal resolution is superior to the high res, but the pixels were maybe blurry.

[troed]

Indeed.

Horisontal max # pixels, in 50Hz:

cycle 28: BLANK = FALSE
cycle 448: BLANK = TRUE

448-28 = 420

To show more than 420 pixels you'd need to cancel out HBLANK, which these modifications do not do by just keeping DE on.

Unfortunately I seem to not have researched where VBLANK ends so can't say what the maximum numbers of lines is I have a vague memory of having read something that would lead me to believe it would be line 26. If so (a big if) it would be 308-26 = 282 lines. But, as I said, it would need testing.

(And if anyone's interested, test by being in mono over cycle 502 on line 26 and see if the screen is kept blank, i.e, V never signals which means DE never signals)

/Troed

[AtariZoll]

I was thinking today at morning about related - more bitplanes. Then realized that in active line phase ST(E) always reads (video) RAM in 500nS intervals. That's the reason why can have wider overscan in medium res than in high - just look what are horizontal scan frequencies.
It's normal that in med. res it is not that sharp. But someone should try it on some LCD monitor capable to work with TV scan frequencies.

[Steven Seagal]

Unfortunately I seem to not have researched where VBLANK ends so can't say what the maximum numbers of lines is I have a vague memory of having read something that would lead me to believe it would be line 26. If so (a big if) it would be 308-26 = 282 lines. But, as I said, it would need testing.

(And if anyone's interested, test by being in mono over cycle 502 on line 26 and see if the screen is kept blank, i.e, V never signals which means DE never signals)

/Troed

Or using some demos:

Musical Wonder 90 and Dragonnels/Great Plazma to check the top lines (palette effects)
Overscan Demos F6 to check the bottom lines.

Wonder if the max #lines isn't 283.
Supposing the limits are reached.

[Greenious]

Digging through my wast pile of stuff in storage, I found the english manual, and driver disk, of the commercial version of the overscan circuit.

overscan.png

This is the maximum resolutions achievable with various monitors.

Note, newer SM124 were capable of doing 704 x 480, and MG11 units could vary wildly, but listed are "good" MG11's.

I think some of these resolutions also required some tweaking on the actual monitor aswell. I'll try to have the manual scanned and the driver disk dumped asap, as they are dated nov 1990, more than a year after the "pd overscan".

Interestingly enough, the commercial version also uses the 2MHz clock from GLUE...

[1st1]

Very interesting! Are your modifications compatible with the AutoSwitchOverscan-driver?

[troed]

Theoretical maximum mono horisontal resolution should be (184-4)*4 = 720

I also don't know of a VBLANK in mono, so while some lines should be hidden by VSYNC I would expect close to 501 lines.

[Greenious]

overscan.jpg

I had huge problem posting last night, here is the picture.

[Steven Seagal]

Very interesting! Are your modifications compatible with the AutoSwitchOverscan-driver?

I can't find this driver, if you have a link to it (and maybe some doc) I will test.

[Greenious]

Very interesting! Are your modifications compatible with the AutoSwitchOverscan-driver?

I can't find this driver, if you have a link to it (and maybe some doc) I will test.

It works just as Lacescan, enabling overscan by setting the ACIA RTS pin.

I'll dump my driver disk and try to get the manual scanned asap.

[troed]

Theoretical maximum mono horisontal resolution should be (184-4)*4 = 720

Right, that was wrong. I was counting from regular H = TRUE. With DE constantly on it might be (184-(212-224))*4 instead, that is, 784. This is assuming there's no BLANK = FALSE done later than HSYNC = FALSE (I don't know of one).

Mono statemachine
4: IF(71) H = TRUE
164: IF(71) H = FALSE
184: IF(71) BLANK = TRUE
188: IF(71) HSYNC = TRUE
212: IF(71) HSYNC = FALSE, BLANK = FALSE, hSYNC_COUNTER reset

[Greenious]

Theoretical maximum mono horisontal resolution should be (184-4)*4 = 720

Right, that was wrong. I was counting from regular H = TRUE. With DE constantly on it might be (184-(212-224))*4 instead, that is, 784. This is assuming there's no BLANK = FALSE done later than HSYNC = FALSE (I don't know of one).

Mono statemachine
4: IF(71) H = TRUE
164: IF(71) H = FALSE
184: IF(71) BLANK = TRUE
188: IF(71) HSYNC = TRUE
212: IF(71) HSYNC = FALSE, BLANK = FALSE, hSYNC_COUNTER reset

The lacescan circuit and the original overscan circuit just combines vb and hb for DE generation regardless of resolution. AutoSwitchOverscan circuit also uses the 2MHz clock from GLUE, and mono detect, which adds a dimension to this.

[Steven Seagal]

Mono statemachine
4: IF(71) H = TRUE
164: IF(71) H = FALSE
184: IF(71) BLANK = TRUE
188: IF(71) HSYNC = TRUE
212: IF(71) HSYNC = FALSE, BLANK = FALSE, hSYNC_COUNTER reset

But maybe only HSYNC is used in mono, not HBLANK?

I uploaded a beta here:

http://sourceforge.net/projects/steemsse/files/DevBuilds/Steem.SSE.Beta.Win32.D3D.zip/download

And based on that file:

http://atari4ever.free.fr/hardware/zip/lascan35.zip

This is the test disk I used (had to correct the inf file...):

lace_tst.zip

You must choose ST model 'STF Overscan' and, of course, enable the borders!
The setting screen appears if you press left shift at boot.