Sidequest: VGA scan doubler

[troed]

That's not a bad idea really. I wonder if the system will run slower with it having more video data access to RAM on full screen though..

Nope. The ST interleaves video/CPU regardless of whether DE is active. I believe on the Amiga there is a difference though (CPU can access memory on "video cycles" when in the border) - but I might be wrong.

On ST hardware fullscreen really is a mod with no negatives, beyond having to run an AUTO program to get the right resolution into VDI and then all the programs that assume things about ST resolutions and don't ask the virtual display.

/Troed

[Smonson]

If you find yourself lacking stuff to do, then it would be neat if it would take the DE signal and a switch to enable/disable the borders in the output image

Sorry, I don't hold out a lot of hope that it can work. The HDMI mod can do that trick because you can tell the HDMI monitor how big the frame is. With a VGA monitor it guesses the size of the active video part of the frame by itself. For the ST's frame timing, my monitors tend to guess that it's a 720x576 mode. But that will depend on which modes the monitor supports. Note that 50Hz is outside the standard entirely.

The physical frames are 1024x626 for 50Hz, 1016x524 for 60Hz, and 896x501 for 71.2Hz.

[Smonson]

This is monochrome passed through the scandoubler (not through the original ST monitor port though, yet):

scandoubler2-mono1.png (1.55 MiB) Viewed 5213 times

There is some kind of random noise in the image, which you can see toward the bottom of that pic. Where the noise is and what it looks like depends on what image is displayed on the screen, so I think it's the monitor having trouble with the monochrome frame parameters (tried on 2 monitors, same effect).

You can see different noise in this pic which has a window opened (especially in the last few lines, and on the right edge just after the active area):

scandoubler2-mono2.png (1.37 MiB) Viewed 5213 times

This is the native Atari frame timing for monochrome which I don't have at hand at this moment. There was a post on the other forum with the timing parameters which is now gone, I should have saved it somewhere. Since mono doesn't use blanking, the monitor could be getting confused... it's my working hypothesis. I'm going to try synthetically generating hsync at a different position in the scanline to see if that improves it.

The intentional part of the image is pretty good though, and my DACs are constructed in a similar way to the ST's internal ones (R-2R ladder plus a BJT). So hopefully it would still look crisp after passing through the original ones.

[beel1]

Maybe this can help?
http://powerphenix.com/rodolphe.czuba.f ... hifter.jpg

[Smonson]

Maybe this can help?
http://powerphenix.com/rodolphe.czuba.f ... hifter.jpg

Thanks, that's perfect. It looks like it confirms my hazy memory that hsync comes very close after the end of the pixel data at the end of each scanline.

In mono, we have 224 cycles (28 uS) and 160 of those are pixel data, leaving 64 remaining (8 uS). This matches the diagram, where we have 12 cycles front porch, 24 cycles for hsync, then 28 cycles for the back porch.

It actually sounds pretty reasonable. But what I'd like to know now after seeing it in the diagram is whether there is really a "blank" level for mono pixels or not. I thought there wasn't, but perhaps I'm wrong.

[troed]

Not sure this is the latest I have, I went from cycles to pseudo code (building on Ijor's) but that's not as easily read.

Code: Select all

Mono statemachine

4:        IF(71) DE = TRUE
164:    IF(71) DE = FALSE
184:    IF(71) BLANK = TRUE
188:    IF(71) HSYNC = TRUE
212:    IF(71) HSYNC = FALSE, hSYNC_COUNTER reset
214(?): IF(71) hVID_COUNTER reset - maybe this is BLANK = FALSE as well

[czietz]

It actually sounds pretty reasonable. But what I'd like to know now after seeing it in the diagram is whether there is really a "blank" level for mono pixels or not. I thought there wasn't, but perhaps I'm wrong.

Iirc, on the ST (but not on the STe), a BLANK signal is generated even in mono mode, but it isn't used for anything. I remember posting something about it to AF, but, alas, it's still off-line.

[Smonson]

Iirc, on the ST (but not on the STe), a BLANK signal is generated even in mono mode, but it isn't used for anything. I remember posting something about it to AF, but, alas, it's still off-line.

Hmmmmm that's basically what I thought as well. I guess the question is, am I the only person who gets this effect when using mono on a VGA monitor - or is it something specific to this setup.

Next time I have a chance to play around with it I have a few things to experiment with.

[chue]

... am I the only person who gets this effect when using mono on a VGA monitor - or is it something specific to this setup.

Not sure if I understand you correctly, but my STF / STE monochrome signals are crisp when sent to my VGA monitor.

[PaulJ]

Hmmmmm that's basically what I thought as well. I guess the question is, am I the only person who gets this effect when using mono on a VGA monitor - or is it something specific to this setup.

Smonson, all my machines have a nice crisp pretty much flawless display in mono. The presentation for me is highly influienced by the cable. I have a best cable with the mono/color switch integrated, the ube switch, and Exxos's latest that has the mono/color jumper for 8 pounds. The Best cable is my worst cable... extremely overdriven, the ube has an ok presentation but it gets very confused what resolution I have set it for and likes mono when confused. The best performing one is Exxos's new 8 pound adaptor, best display for mono and color, never gets confused and has the best presentation not to mention you can plug in the external floppy cable on a mega when in use. As a side note when in mono the monitor can show vertical bars if the display is adjusted with the video off to the side or the size is set to large for the screen. All in all no mono artifacts if adjusted correctly. Looking forward to getting my hands on a Smonson HDMI interface.