Thx. This one could be supported, it seems it was "popular".It is activated the same way as LaceScan, but unless I missed something due to the mono detect or the clock, apparently Autoswitch overscan is less impressive than LaceScan overscan: 96 bytes/scanline in monochrome instead of 100, and only 224 bytes at 50hz, instead of 236!

Steven Seagal wrote:Thx. This one could be supported, it seems it was "popular".It is activated the same way as LaceScan, but unless I missed something due to the mono detect or the clock, apparently Autoswitch overscan is less impressive than LaceScan overscan: 96 bytes/scanline in monochrome instead of 100, and only 224 bytes at 50hz, instead of 236!

I finally got the manual scanned. Unfortunately I don't have the tools to make the pdf as orderly as I'd wanted... Perhaps someone with the proper tools/time could sort the page numbers properly.

Anyway, it's not unreadable.

The writer of lacescan is a friend of mine, who sadly left the scene a long time ago and is unlikely to come back, but I talk to him from time to time and I'll bring up lacescan next time. One reason for lacescan's ability to handle higher resolution than the Autoswitch overscan is that it also can work with virtual resolutions, and that way also is useable on STE aswell as STs without overscan hardware at all.

You do not have the required permissions to view the files attached to this post.

Steven Seagal wrote:Thx. This one could be supported, it seems it was "popular".It is activated the same way as LaceScan, but unless I missed something due to the mono detect or the clock, apparently Autoswitch overscan is less impressive than LaceScan overscan: 96 bytes/scanline in monochrome instead of 100, and only 224 bytes at 50hz, instead of 236!

I finally got the manual scanned. Unfortunately I don't have the tools to make the pdf as orderly as I'd wanted... Perhaps someone with the proper tools/time could sort the page numbers properly.

Anyway, it's not unreadable.

The writer of lacescan is a friend of mine, who sadly left the scene a long time ago and is unlikely to come back, but I talk to him from time to time and I'll bring up lacescan next time. One reason for lacescan's ability to handle higher resolution than the Autoswitch overscan is that it also can work with virtual resolutions, and that way also is useable on STE aswell as STs without overscan hardware at all.

Steven Seagal wrote:apparently Autoswitch overscan is less impressive than LaceScan overscan: 96 bytes/scanline in monochrome instead of 100, and only 224 bytes at 50hz, instead of 236!

To correct a previous (hasty) statement...

96 bytes instead of 100 isn't a big difference, and at 96*8= 768, hires was also above monitor specs, not to mention the little HSYNC problem.But apparently you get 480 lines max, compared with 500 for Lacescan.

224 bytes in colour mode are more than enough to reach the maximal resolution, which is still determined by HBLANK.The fact that it's 224 (divisible by 4) at 50hz or 60hz is a big advantage: no GEM problems!

Probably the GLUE clock was needed to stop DE at the right time, there must be a counter in the circuit, with a different threshold for monochrome and colour, hence the mono detect line.

Steven Seagal wrote:apparently Autoswitch overscan is less impressive than LaceScan overscan: 96 bytes/scanline in monochrome instead of 100, and only 224 bytes at 50hz, instead of 236!

To correct a previous (hasty) statement...

96 bytes instead of 100 isn't a big difference, and at 96*8= 768, hires was also above monitor specs, not to mention the little HSYNC problem.But apparently you get 480 lines max, compared with 500 for Lacescan.

224 bytes in colour mode are more than enough to reach the maximal resolution, which is still determined by HBLANK.The fact that it's 224 (divisible by 4) at 50hz or 60hz is a big advantage: no GEM problems!

Probably the GLUE clock was needed to stop DE at the right time, there must be a counter in the circuit, with a different threshold for monochrome and colour, hence the mono detect line.

As I mentioned in the previous post, I talked with Ronald, the maker of Lacescan today, but as I kinda expected, he didn't really remember much of the finer details of the mod...

But you are likely correct that the 2mhz clock is used to shorten DE to make it work in all resolutions and refresh rates. As the original overscan doc states, there's some problems with (lowrez) 60hz in particular. And lacescan has more in common with the original mod than the Autoswitch one when it comes to actually generating overscan.

The basic circuit is the same though, and I doubt lacescan actually achieved 500 lines in practice, although his driver probably took height for it to be possible on some monitors.

Greenious wrote:Oh, you want pics! Sorry, I didn't pick that up earlier.

Seeing how it works on HW is always instructive. For instance, I didn't even know that borders are always black in high res.There's also doubt on the exact positioning, not that it's so important.Is the image distorted on the edges?, etc.Also noticed there's a clock displayed on the top right in Autoswitch. In Steem, it's right but I think it's a hack.

Greenious wrote:Oh, you want pics! Sorry, I didn't pick that up earlier.

Seeing how it works on HW is always instructive. For instance, I didn't even know that borders are always black in high res.There's also doubt on the exact positioning, not that it's so important.Is the image distorted on the edges?, etc.

There is a option in LaceScan to position the screen and some other options in the auto program. I'll send pictures when I get back home.

Steven Seagal wrote:Also noticed there's a clock displayed on the top right in Autoswitch. In Steem, it's right but I think it's a hack.

If I get this right...There was the "original overscan", with 236 byte scanlines at 50hz and 234 at 60hz.Later the same authors produced Autoswitch with 224 byte scanlines at 50 and 60hz, which is better for GEM.Later Lacescan, by different authors, was based on the original circuit and also featured 234/236 byte scanlines.Hence my confusion.

Steven Seagal wrote:If I get this right...There was the "original overscan", with 236 byte scanlines at 50hz and 234 at 60hz.Later the same authors produced Autoswitch with 224 byte scanlines at 50 and 60hz, which is better for GEM.Later Lacescan, by different authors, was based on the original circuit and also featured 234/236 byte scanlines.Hence my confusion.

I think that's correct as far as I know. Here are some more pictures.

IMG_0679.JPG

IMG_0675.JPG

IMG_0677.JPG

IMG_0676.JPG

You do not have the required permissions to view the files attached to this post.

Thx, it's funny, the images are upside down in the forum (IE11), I thought you messed up, but OK in IrfanView It's a VGA connection, I guess? The top lines are apparently missing. Unfortunately, there doesn't seem to be a way to shift the display down.

Steven Seagal wrote:If I get this right...There was the "original overscan", with 236 byte scanlines at 50hz and 234 at 60hz.Later the same authors produced Autoswitch with 224 byte scanlines at 50 and 60hz, which is better for GEM.Later Lacescan, by different authors, was based on the original circuit and also featured 234/236 byte scanlines.Hence my confusion.

Yes, that would be correct!

I'll download you beta and play with it a bit this weekend, thanks a million for your efforts!

troed wrote:That's interesting (I'm sure the schematic is right). There's thus unnecessary logic in GLUE handling BLANK in mono without it actually being used (unless you trick the GLUE by triggering the BLANK position for mono while otherwise in color).

Yes, GLUE processes BLANK exactly with the same logic as DE, just with different values. Even when at the board level it seems that BLANK doesn't affect the mono output, there are specific comparators for HBLANK and VBLANK at 70Hz.

Steven Seagal wrote:In Steem currently it's supposed to be 3 scanlines in all frequencies, but it is true only for 50hz, not really tested at other frequencies.

It is 3 scanlines in color, 50Hz and 60Hz. But at 70Hz it's just a single scan, IIRC.

It's easy to test because the video counter is reloaded when the MMU sees VSYNC changing. Guess I'll do a little test program...

MMU reloads the video pointer it at the falling edge of VSYNC only (start of VSYNC).

Yet, some programs seem to rely on the counter being reloaded again at the end of VSYNC, when the VBL interrupt is set pending, at least in Steem (so it could be something else). Example: Beyond/Universal Coders

Steven Seagal wrote:Yet, some programs seem to rely on the counter being reloaded again at the end of VSYNC, when the VBL interrupt is set pending

Sorry, I was wrong. The video pointer is updated whenever VSYNC is asserted. But it is not exactly that it is reloaded again at the end of VSYNC, it is constantly being reloaded during the whole period that the signal is asserted.

ijor wrote:But it is not exactly that it is reloaded again at the end of VSYNC, it is constantly being reloaded during the whole period that the signal is asserted.

Another little mystery solved, thx.So the emulator approach of reloading it twice was mostly correct (reloading it all the time would be a... load). We just need to make sure that any read in between returns the base address.On the STE, someone could try to change the video counter during vsync for whatever reason.