VGA through rpi pico - How many colors possible on border?

[eto]

What artifacts with scandoublers do you see in those games?

I don't know how to describe it. They basically become unplayable as the scrolling will have some weird results. The screen is kind of shaking. 

[gregg]

What artifacts with scandoublers do you see in those games?

I don't know how to describe it. They basically become unplayable as the scrolling will have some weird results. The screen is kind of shaking.

OK. So first I need to have all timings ok, and I think scrolling will be nice test to check if I read input well.
I see two possible reasons (but I am guessing) for the issue you describe. One would be a screen tearing, that I am afraid I may have, too. I am writing from CPC video output to my array and reading from it to push it to VGA output in totally not synchronized way. Input is 50fps, output is 60fps, so there may be a case when I present half of one frame and half of other. That would cause tearing but only in one line.
Other option is some magic that scandoubler does because it tries to support also interlace that we don't have in Amstrad. That should work well in my solution.
I will test it for sure in a couple days, once I am done with remaining (but small) issues in code. Maybe I would make a short video of my screen so you could say if you still see that issue.

[andycadley]

A lot of the more tricky CRTC tricks are around tricking the CRTC to generate signals the monitor won't respond to, but that the rest of the hardware will. That allows you to display multiple "screens" within a single frame of the monitor.

Pushing things to the point that they technically are out of spec, but that the CPC won't notice, is another issue. And finally there are the kinds of things like relying on the analogue response of the monitor to the change in certain registers, letting you do things like put sine waves effects down the screen.

[eto]

nput is 50fps, output is 60fps,

Many VGA screens accept 50Hz input. It would be great to have that at least as an option. 

[gregg]

nput is 50fps, output is 60fps,

Many VGA screens accept 50Hz input. It would be great to have that at least as an option.

Yep... but in the first version I wanted to make it working on as many monitors as possible. The most standard resolutions supported on everything are 640x480 and 800x600. First I wanted to use 640x480, but then I would not fit borders and would not allow for overscan. I guess that is quite a limitation, so next option is 800x600. Universally supported framerates for 800x600 (even by old monitors) are 56, 60, 72 and 75, so no 50hz. At some point I made a bug and I had 58 hz. It worked on my quite new Asus monitor, but was showing "not supported" on older tv. So I decided to stick to 60hz. If there will be a problem with tearing, I will try to switch to 50.
Overall I think the best option would be to have switches for multiple resolutions, multiple frame rates, and screen size adjustments just to be able to choose the best option for each use case - e.g. option to get rid of some artifacts at the price of smaller border. But at this point I am trying to have some working minimal usable version, make it tested, stable, publish it on Github or somewhere and then follow with nice-to-haves.

[McArti0]

CPC has V-synch freq ..... 50,080(128205) Hz sorry.

Pinball Dream has ~280 line  sorry.

[gregg]

CPC has V-synch freq ..... 50,080(128205) Hz sorry.

Pinball Dream has ~280 line  sorry.

Yep. I know it is a bit over 50hz. I took it into account when reading input. And no need to be sorry

Thanks for all the examples, but do you know the answer to my original question? For example in Pinball Dreams, which 280 lines are those? That is the most important for me to find how many lines and which of them I need to read. For example if this time it is the whole bottom border and a part of top one, and in other game using 280 lines it will be the whole top border and a part of bottom one, then I can't use 280 lines but I need more. What about those 10 black lines that I see above top border? Does any game use it? Is it visible on original monitor?
I can think about some other trick with dmas to have maybe not 256 lines but 288 (256+32), but I need to know if it makes any sense. If instead of 10% games causing troubles it will be 9% then I think it is not worth doing.
Also if it will look like I need to use every single input line and find solution for that, I don't want to have monitor filled with a lot of stuff that is rarely used, leaving actual screen area much smaller.

Fortunately it is much simpler in horizontal direction. There is just 800 columns between hsync signals so I just copy all of them.

And thanks for all the examples, I did not expect there are so many exception.

[andycadley]

I suspect the black lines are just part of VSYNC and never actually visible. As to which ones are visible, that's probably impossible to say because it'll be slightly different depending on the adjustment settings on the monitor. Picking the middle-ish bunch to give roughly even border top and bottom is probably the right approach.

[gregg]

I suspect the black lines are just part of VSYNC and never actually visible. As to which ones are visible, that's probably impossible to say because it'll be slightly different depending on the adjustment settings on the monitor. Picking the middle-ish bunch to give roughly even border top and bottom is probably the right approach.

Thanks. I will do it this way. I will get 200 lines from main screen + 28 from each border.
But if I manage to get over that 256 lines limitation and be able to use 256+32=288 lines then I would have both borders + even 2 spare lines. That would make a lot of sense if it is doable. I need to try.

[krusty_benediction]

This is an interesting project, but probably useless if the converter is too academic with the video signal.
Most demos would not be rendered properly when hsync/vsync timings are not correct (on purpose or by programming mistake).
CTM totally accepts that, but not oscc, which make it useless. It would be sad your product suffers of the same issue

[gregg]

This is an interesting project, but probably useless if the converter is too academic with the video signal.
Most demos would not be rendered properly when hsync/vsync timings are not correct (on purpose or by programming mistake).
CTM totally accepts that, but not oscc, which make it useless. It would be sad your product suffers of the same issue

I am sure I am never going to match what exactly CTM can display or even get close to it or even to any CRT monitor. My goal is to have something close to what you can get from a scandoubler, but with the total cost of a couple dollars, much smaller size, but working only with Amstrad and skip support for all the features that other scandoublers have. I would not support interlace, other resolutions and timings than amstrad one, or no other palettes. And even if it will be useless I am doing it first of all to learn stuff, so for me it is a win-win situation

[McArti0]

Many emulators show the screen as 40+200+32 (+/- 8 lines up or down)

[gregg]

Many emulators show the screen as 40+200+32 (+/- 8 lines up or down)

Thanks! That is a very useful info!

[krusty_benediction]

Maybe this file would be useful
https://www.cpc-power.com/index.php?page=detail&num=16027

[gregg]

Maybe this file would be useful
https://www.cpc-power.com/index.php?page=detail&num=16027

That would be very very useful. Thanks a lot!

[SerErris]

I would still do it line by line.

Start from the hsync singnal and scan to the next hsync, then output it twice to the target monitor with double pixel frequency.

That would catch everything the CPC will do, regardless of video modes or anything else. 

If you just do that this needs only one line of memory and is never wrong, whatever the demo might do and it is also very fast (no additional delay) in the output. So even any mode switch will be done immediately without any adaption time. 

[gregg]

I would still do it line by line.

Start from the hsync singnal and scan to the next hsync, then output it twice to the target monitor with double pixel frequency.

That would catch everything the CPC will do, regardless of video modes or anything else.

If you just do that this needs only one line of memory and is never wrong, whatever the demo might do and it is also very fast (no additional delay) in the output. So even any mode switch will be done immediately without any adaption time.

To be honest that is what I wanted to do first. This way there is for sure no issues with ram or with tearing that could happen when frame in RAM is being displayed and overwritten in the same moment, but there are two main issues I found. First is timing. When reading Amstrad video, it has to be extremely accurate. For VGA output it also has to be quite accurate. That leaves not much space for any extra operations like doubling the line etc. and keeping everything in sync at the same time. Still maybe this potentially could be made at some point.
Other issue is related to possible resolutions and frame rates. In your solution we have to keep the same vertical frequency/frame rate on output as on input. Looking at available frequencies for monitors, like my main one: http://dlcdnet.asus.com/pub/ASUS/LCD%20Monitors/PB277/ASUS_PB277Q_English.pdf the options for available resolutions with 50hz fps is quite limited. When I checked some old TV I have, it was even more limited. Some monitors have so huge tolerance that even when not officially supporting 50hz they would probabaly handle it. Still I don't want to end up with something that works only on a fraction of monitors. When we add requirement about resolution it will be even harder. Actually my only option is 800x600 (or something close) to be able to fit the whole amstrad screen and still be able to send pixels quick enough. That gives even smaller number of possible frame rates.
On the other hand when I think about pros and cons of keeping the whole frame in memory, then first of all it just works and so far I don't see tearing. It could also open the possibilities to do any postprocessing of a frame. In future, I could e.g. handle some special cases, like mentioned earlier smooth scrolling or even try to simulate dithering, getting closer to what can be seen on original monitor rather than on typical scandoubler. All that stuff would be harder having access to one line only.

... and some good news - I managed to work around the limitation of number of lines being the power of 2. So now I have the totally full Amstrad screen displayed, even with a bit of those black lines just after vsync signal. Any overscan should not be a problem. This weekend I plan to finish the electronics part, and then I will follow with more detailed testing to know better what works and what doesn't.

[Deevee]

I would still do it line by line.

Start from the hsync singnal and scan to the next hsync, then output it twice to the target monitor with double pixel frequency.

That would catch everything the CPC will do, regardless of video modes or anything else.

If you just do that this needs only one line of memory and is never wrong, whatever the demo might do and it is also very fast (no additional delay) in the output. So even any mode switch will be done immediately without any adaption time.

I might be wrong, but I think some demos force multiple hsyncs per line, to allow multiple modes in a line.

[gregg]

I would still do it line by line.

Start from the hsync singnal and scan to the next hsync, then output it twice to the target monitor with double pixel frequency.

That would catch everything the CPC will do, regardless of video modes or anything else.

If you just do that this needs only one line of memory and is never wrong, whatever the demo might do and it is also very fast (no additional delay) in the output. So even any mode switch will be done immediately without any adaption time.

I might be wrong, but I think some demos force multiple hsyncs per line, to allow multiple modes in a line.

Oh wow! That will be a cool use case to handle. So far my logic is like: wait for hsync to go up, then to go down, then read the line in a loop with constant number of pixels (assuming mode 2, in other case it just reads one pixel multiple time). I will have to change it completely to handle something like that. I can't wait to have it working with basic use cases and start working on cases like that one

[andycadley]

I would still do it line by line.

Start from the hsync singnal and scan to the next hsync, then output it twice to the target monitor with double pixel frequency.

That would catch everything the CPC will do, regardless of video modes or anything else.

If you just do that this needs only one line of memory and is never wrong, whatever the demo might do and it is also very fast (no additional delay) in the output. So even any mode switch will be done immediately without any adaption time.

I might be wrong, but I think some demos force multiple hsyncs per line, to allow multiple modes in a line.

Yeah, if you want to support that you'd need to make sure to ignore shorter HSYNC pulses. And obviously be aware that Mode could change mid line, but if you're just sampling colours periodically that probably doesn't matter so much.

[gregg]

I would still do it line by line.

Start from the hsync singnal and scan to the next hsync, then output it twice to the target monitor with double pixel frequency.

That would catch everything the CPC will do, regardless of video modes or anything else.

If you just do that this needs only one line of memory and is never wrong, whatever the demo might do and it is also very fast (no additional delay) in the output. So even any mode switch will be done immediately without any adaption time.

I might be wrong, but I think some demos force multiple hsyncs per line, to allow multiple modes in a line.

Yeah, if you want to support that you'd need to make sure to ignore shorter HSYNC pulses. And obviously be aware that Mode could change mid line, but if you're just sampling colours periodically that probably doesn't matter so much.

Sorry, for a dumb question, but I think most of the demos and games that I will need to test are disc only? At this point my self-made frankensteiny Amstrad can only load tapes and roms, so I guess I will need to finally buy real 6128 or 464 with disc interface? (plus gotek or something)

[Deevee]

I would still do it line by line.

Start from the hsync singnal and scan to the next hsync, then output it twice to the target monitor with double pixel frequency.

That would catch everything the CPC will do, regardless of video modes or anything else.

If you just do that this needs only one line of memory and is never wrong, whatever the demo might do and it is also very fast (no additional delay) in the output. So even any mode switch will be done immediately without any adaption time.

I might be wrong, but I think some demos force multiple hsyncs per line, to allow multiple modes in a line.

Yeah, if you want to support that you'd need to make sure to ignore shorter HSYNC pulses. And obviously be aware that Mode could change mid line, but if you're just sampling colours periodically that probably doesn't matter so much.

Sorry, for a dumb question, but I think most of the demos and games that I will need to test are disc only? At this point my self-made frankensteiny Amstrad can only load tapes and roms, so I guess I will need to finally buy real 6128 or 464 with disc interface? (plus gotek or something)

There are many games on tape, but very few demos (if any?), because of loading shenanigans.
Anyway, if you want to be sure that your adapter works with a CPC, you'll have to test it with a CPC at some point I guess.

[McArti0]

Możesz kupić Dandanator mini lub DDI-5.

[gregg]

@eto  I did some of the tests you recommended. Could you take a look if it looks OK? Please ignore noise (flickering pixels) and sometimes screen shifted to the right - I am already working on these issues.

IMO Vertical overscan (Ultima Ratio) looks OK. I also tried horizontal overscan with Super Cauldron and it was OK.

Scrolling it much more interesting. I tried Ghost'n'Goblins and I think they are OK, but please take a look, too. Sorry for blurry video, my camera went out of focus.

Smooth vertical scroll (Mission Genocide) also looks OK, but sometimes a little bit choppy. I am not sure if it is expected.

Horizontal smooth scroll totally does not work. I tried Skate Wars, and it was a total mess. I am just reading about tricks with HSync here: https://shaker.logonsystem.eu/ACCC1.7-EN.pdf and I have some ideas how to fix it, but first for sure I will need to use csync from Gate Array instead of Hsync from CRTC.
Besides that I found a lot of issues with how I handle or do not handle syncs. e.g. Mission genocide has less lines (305 it total), so instead of hardcoded value I will need to start actually use VSync. And BTW how I use HSync also sucks - sometimes screen is shifted to the right.

I did not manage to load Relentless yet, but I believe issues will be similar to Skate Wars.

[eto]

Ghosts'n Goblins looks good. 

If you have issues loading Relentles, you can try Edge Grinder and Super Edge Grinder. These are also two candidates that rarely work on anything but a CRT.