Hardware Overscan

A place to discuss current and future developments for STeem

Moderators: Mug UK, Steem Authors, Moderator Team

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1945
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Hardware Overscan

Postby Steven Seagal » Sat Jul 15, 2017 9:05 am

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.
You do not have the required permissions to view the files attached to this post.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1945
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Hardware Overscan

Postby Steven Seagal » Sun Jul 16, 2017 8:10 am

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.
You do not have the required permissions to view the files attached to this post.

bj
Captain Atari
Captain Atari
Posts: 466
Joined: Sun Sep 21, 2003 10:30 am
Location: London

Re: Hardware Overscan

Postby bj » Sun Jul 16, 2017 4:05 pm

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

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1945
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Hardware Overscan

Postby Steven Seagal » Mon Jul 17, 2017 9:33 am

More teasers.
But I can't find images/videos, maybe it wasn't that big in the ST community after all?
You do not have the required permissions to view the files attached to this post.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1945
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Hardware Overscan

Postby Steven Seagal » Mon Jul 17, 2017 3:30 pm

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.
You do not have the required permissions to view the files attached to this post.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2795
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Hardware Overscan

Postby AtariZoll » Mon Jul 17, 2017 3:55 pm

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 :D
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.
Negative feedback has usually positive effect.

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 1160
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Re: Hardware Overscan

Postby Greenious » Mon Jul 17, 2017 6:36 pm

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.
Updated my guides as of june 28th, 2016. Check'em out and feedback!
viewtopic.php?t=5040

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 1160
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Re: Hardware Overscan

Postby Greenious » Mon Jul 17, 2017 6:48 pm

Steven Seagal wrote: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.
Updated my guides as of june 28th, 2016. Check'em out and feedback!
viewtopic.php?t=5040

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 1160
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Re: Hardware Overscan

Postby Greenious » Mon Jul 17, 2017 7:00 pm

Steven Seagal wrote: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...
Updated my guides as of june 28th, 2016. Check'em out and feedback!
viewtopic.php?t=5040

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1945
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Hardware Overscan

Postby Steven Seagal » Mon Jul 17, 2017 8:49 pm

Greenious wrote: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. :)


Greenious wrote: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.

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 1160
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Re: Hardware Overscan

Postby Greenious » Mon Jul 17, 2017 9:08 pm

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... :)
Updated my guides as of june 28th, 2016. Check'em out and feedback!
viewtopic.php?t=5040

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1945
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Hardware Overscan

Postby Steven Seagal » Mon Jul 17, 2017 9:17 pm

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...

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1945
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Hardware Overscan

Postby Steven Seagal » Tue Jul 18, 2017 5:00 pm

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.
You do not have the required permissions to view the files attached to this post.

User avatar
troed
Atari God
Atari God
Posts: 1197
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Hardware Overscan

Postby troed » Tue Jul 18, 2017 6:08 pm

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
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2795
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Hardware Overscan

Postby AtariZoll » Tue Jul 18, 2017 6:11 pm

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.
Negative feedback has usually positive effect.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1945
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Hardware Overscan

Postby Steven Seagal » Wed Jul 19, 2017 9:56 am

troed wrote: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.

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 1160
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Re: Hardware Overscan

Postby Greenious » Thu Jul 20, 2017 12:54 am

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...
Updated my guides as of june 28th, 2016. Check'em out and feedback!
viewtopic.php?t=5040

User avatar
1st1
Atari Super Hero
Atari Super Hero
Posts: 668
Joined: Mon May 07, 2012 11:48 am

Re: Hardware Overscan

Postby 1st1 » Thu Jul 20, 2017 5:08 am

Very interesting! Are your modifications compatible with the AutoSwitchOverscan-driver?
Power without the Price. It's not a bug. It's a feature. _/|\_ATARI

1040STFM in PC-Tower (PAK68/2, OvrScn, 4 MB, 1GB SCSI, CD-ROM...) * 2x Falcon 030 32GB/14MB+ScrnBlstrIII * 2x TT030 73GB/20MB+Nova * 520/1040STFM * 520/1040STE * 260/520ST/+ * some Mega ST * 2x Mega STE 500MB/4MB+M.CoCo * Stacy * STBook * SLM605 * SLM804 * SLM605 * SMM804 * SH 204/205 * Megafile 30/44/60 * SF314 * SF354 * 5x Pofo * PC3

User avatar
troed
Atari God
Atari God
Posts: 1197
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Hardware Overscan

Postby troed » Thu Jul 20, 2017 8:23 am

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.

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 1160
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Re: Hardware Overscan

Postby Greenious » Thu Jul 20, 2017 8:32 am

overscan.jpg


I had huge problem posting last night, here is the picture.
You do not have the required permissions to view the files attached to this post.
Updated my guides as of june 28th, 2016. Check'em out and feedback!
viewtopic.php?t=5040

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1945
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Hardware Overscan

Postby Steven Seagal » Thu Jul 20, 2017 8:54 am

1st1 wrote: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.

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 1160
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Re: Hardware Overscan

Postby Greenious » Thu Jul 20, 2017 8:59 am

Steven Seagal wrote:
1st1 wrote: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.
Updated my guides as of june 28th, 2016. Check'em out and feedback!
viewtopic.php?t=5040

User avatar
troed
Atari God
Atari God
Posts: 1197
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Hardware Overscan

Postby troed » Thu Jul 20, 2017 9:13 am

troed wrote: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

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 1160
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Re: Hardware Overscan

Postby Greenious » Thu Jul 20, 2017 9:36 am

troed wrote:
troed wrote: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.
Updated my guides as of june 28th, 2016. Check'em out and feedback!
viewtopic.php?t=5040

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1945
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Hardware Overscan

Postby Steven Seagal » Thu Jul 20, 2017 9:39 am

troed wrote: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.
You do not have the required permissions to view the files attached to this post.


Social Media

     

Return to “Development”

Who is online

Users browsing this forum: No registered users and 3 guests

cron