CPCWiki forum

This is my first post on this forum, so first of all Hello Everyone!

I am just trying to build simple and cheap VGA output for Amstrad based on Raspberry Pi Pico. So far it is going well, except the limitations caused by low amount of available RAM.
I have a little bit above 256k RAM available and I need to squeeze each output video frame there. I am storing each pixel on one byte (actually using only 6 bits). Output resolution is a standard VGA 640x480 (but I could try to use something bigger) so at this point I am keeping 640x400 pixels in memory - max Amstrad resolution with each line doubled to keep reasonable proportions. That means I use exactly 256k RAM.

But... I would like to add at least part of the screen border. So I have 2 questions to you guys:

1. Is border always filled with one color or there may be multiple colors? I think, during loading from tape there are color lines on border, but maybe at least I can assume one color per line? This way I could easily store border info in remaining RAM.

2. In mode 3, what is the real maximum number of colors on screen? I know there are 2 colors, but maybe border can have different color?
I am asking because if my previous idea would not work, then other option (harder but still doable) would be to read only 320 pixels per line and keep twice more pixels in RAM (with at least part of border) except the case when I detect there is a mode 3, and then detect what are the two colors being used and keep high resolution but 1 bit per pixel.

Thanks, and sorry if the questions are too basic, but I am just starting my adventure with Amstrad.

Greg

You kill all software that uses overscan 768 points per line. Better use 2 x less memory and display two copy one lines.

https://youtu.be/DisL4Gj8Tc0?si=iXomUSOhPJkWkVtm

Im so sorry.

Thanks for quick reply.

yep. I forgot about overscan. How big is the max resolution with overscan? You just said 768 pixels per line. Is it max? And how many max lines can be used in overscan?

Idea with one line displayed twice would be the best option i ntheory, but I just did not find a way to do it yet. I was using some open source library to do VGA on Pico, just modified it to use half brightness, too. The idea is that I just set up DMA that send array with the whole frame to PIO that it just displays it line by line. PIO is really dumb and can't have too much logic, also the timing is really tight. I can't also use chained dmas to have one dma per line, because there is not enough dma channels. I would need to use some trick like two PIO state machines, each of them gets 200 line per frame (I would do the same DMA to both of them) then, synchronize them so it is like, first state machine displays first line, then waits and triggers second one. Second one repeats it and lets the first one display second line etc. Overall it would be great to avoid it... still if it is an only option, that is doable.

OK, but that 125 colors are rather POC to show it is possible, right? Not something I would see in games or demos.
Besides that I think it uses dithering? That I think is a separate thing. Alternative (still much more expensive and bigger) for my solution is e.g. GBS8200 that will not do dithering simulation either.
And... RPI pico could potentially do dithering simulation if I manage to squeeze it better in RAM. At least something simple, like adding 2 more levels of brightness, detecting checkerboard pattern and doing something like average for some pixels. At this point one of my ARM cores does literally nothing, and other almost nothing. All the logic to read amstrad video and output vga is in PIOs.

768x256 but ... i can 1024x480  :-\ but not on original CRT.

768x256 sound reasonable (the other one is scary :) ). I would need less than 200kB if I manage to really keep exactly this resolution in RAM, not the doubled one. I could use e.g. 800x600 output resolution, or even something closer to input resolution if monitors support it.
Thanks a lot for all the info! I will focus now on how to display each line twice. It looks like that is the only reasonable option. I hope it will work.

It should be possible to race the beam with PIOs. That would free up the memory. I have not thought it through totally but it should be possible

Aha, as I said... here is something for the Sinclair QL 

Maybe a good starting point
https://forum.tlienhard.com/phpBB3/viewtopic.php?t=4283&sid=13df294b3c7f6cb83516112124a779a6

What you mean by "race a beam? Do you mean converting the input pixel to output ones in a streaming fashion, without storing anything in memory? Or rather do it line by line?
Or something like this - twice more pixels per line on output then on input, read one pixel on input, then write two on output - so we get VGAish timing.
Then PIO need one loop that reads pixel and writes it twice with correct timing. hmmm... It could work.

Thanks for link. I will take a look there

Quote from: SerErris on 18:40, 15 April 24Aha, as I said... here is something for the Sinclair QL

I think that's more or less just a scan-doubler that digitizes the QL output and sends each line twice to the monitor. If I understand gregg correctly he is rather mirroring the screen RAM and listens to the CRTC/GateArray registers.

@gregg in case I am right with that assumption that you are not just digitizing the screen output and replay it again, then you also have to consider double and triple screen buffering.  Many games switch the screen address between frames. If you are mirroring the screen contents you also have to keep 2 or 3 screens in the PICO Ram.

Quote from: eto on 18:47, 15 April 24

Quote from: SerErris on 18:40, 15 April 24Aha, as I said... here is something for the Sinclair QL

I think that's more or less just a scan-doubler that digitizes the QL output and sends each line twice to the monitor. If I understand gregg correctly he is rather mirroring the screen RAM and listens to the CRTC/GateArray registers.

@gregg in case I am right with that assumption that you are not just digitizing the screen output and replay it again, then you also have to consider double and triple screen buffering.  Many games switch the screen address between frames. If you are mirroring the screen contents you also have to keep 2 or 3 screens in the PICO Ram.

Nope... I am more like doing a scandoubler, just the simplified one that assumes Amstrad palette, so it is easy to use just digital pins, voltage comparators on input and 6 resistors on output.

I was considering mirroring the ram, but I got scared :) double and triple buffering is just a beginning. What about reading the palette etc. That's too much for me  :D

Do you have a github or a web site with more informations about the state of your work ?

Quote from: gregg on 18:56, 15 April 24Nope... I am more like doing a scandoubler, just the simplified one that assumes Amstrad palette, so it is easy to use just digital pins, voltage comparators on input and 6 resistors on output.

I was considering mirroring the ram, but I got scared :) double and triple buffering is just a beginning. What about reading the palette etc. That's too much for me  :D

ah... in that case the QL project might indeed be close to what you want to do. 

Well... I am looking forward to it :-) 

Quote from: genesis8 on 21:39, 15 April 24Do you have a github or a web site with more informations about the state of your work ?

Nope. I just have a messy code on my pc, and messy electronics on a breadboard. I will for sure put everything on GitHub, especially that my knowledge in electronics is really poor, so I would like to get some feedback. But first I need to clean it up at least to the point when code is readable.

As for current status - output is almost OK. Code works well, I was able to display Amstrad palette, or something close to it. I need to experiment more with resistors values to make colors better, e.g. white is a bit greenish. Input in terms of schematics is much more WIP. I am just going to order some new voltage comparators, because old ones were too slow. So far I was testing with only 1 bit per input. Except those limitations with ram, when I was trying to just use 640x200 with no border, it looks ok - just small details to improve like screen is shifted a bit, or problems with catching sync after resetting Pico with Amstrad running. So it should not be much work left.

If you have time and energy, would it be possible to do a short video on youtube to show your work for us poor hungry for informations  ;D ?

It's so more sexy when you can see things.

I envision the process would be implemented as similar to the below (as VGA is 31kHz and input is 15kHz)

Two buffers, 768 pixels each.

Some magic to find out when a scanline starts from VSYNC and HSYNC signals.
Repeat {
  Scan-out 768 pixels VGA from buffer A | Read half-scanline display data into buffer B (384 pixels incorporating left border and LHS of screen)
  Scan-out 768 pixels VGA from buffer A | Read other half-scanline display data into buffer B (384 pixels incorporating RHS of screen and right border)
  Scan-out VGA from buffer B | Read half-scanline display data into buffer A
  Scan-out VGA from buffer B | Read other half-scanline display data into buffer A
}

Presumably for an 800 wide VGA screen you'd publish the first pixel 17 times before the rest of the line, and then the final pixel 17 times, to hit 800 pixels. You might want a configurable black border option too here.
You'd also publish X blank lines before and after the display.

The tough thing is sampling at the right rate to get the precise MODE 2 pixel sampling correct.

The above is how OSSC does it, I believe, but that's overkill hardware for a CPC. It's very low latency.

You will need some magic for R3 horizontal scrolling funkery. You can test that using Relentless.

Quote from: genesis8 on 08:26, 16 April 24If you have time and energy, would it be possible to do a short video on youtube to show your work for us poor hungry for informations  ;D ?

It's so more sexy when you can see things.

I am just learning electronics (I am software engineer), so I think I could rather learn from videos :) It is also my first project on RPI Pico... actually on any microcontroller. I am doing it mostly to learn. I even don't have an Amstrad yet (testing on a prototype of a replica that I am trying to build), so I don't think such a video would be valuable. First I would rather like to at least see it working.

If you want some more info, it is a short summary:
I connected vsync and hsync to pi's input GPIOs. RGB will go through voltage comparators (now they are just a bunch of resistors and capacitors to adjust voltage levels) to convert it to 6 pins total. Each pair represents one color. There is 00 (no color), 01 or 10 (half brightness) or 11 (full brightness). Pico works in 128Mhz so it makes it really easy to synchronize because one pixel in mode 3 is 7 cycles on Pico. PIO code that reads it just waits for HSYNC to go up, then down, then waits a couple more cycles (will not do it when I will support overscan). After each pixel is read, PIO sends it to queue, then it goes through DMA to host that stores it in an array that represents one line. Once line is done (next HSYNC starts), host copies line to two consecutive lines on output buffer (that will change if I want to store each line only once). I repeat it 312 times and start again from beginning (next frame). (I will rather sync it using VSYNC in future). 
On output side, second PIO generates HSYNC, VSYNC and just reads the buffer representing VGA screen that it receives through DMA from host (the one that I was filling so far). For each pixel it sets again 6 output GPIO, using the same format - 00 is no color, 01 or 10 is half brightness, 11 is full brightness. Each GPIO has a resistor, that are connected on other side, so we have "analog" signal there that goes directly to VGA. That's it.

Quote from: gregg on 18:44, 15 April 24What you mean by "race a beam? Do you mean converting the input pixel to output ones in a streaming fashion, without storing anything in memory? Or rather do it line by line?
Or something like this - twice more pixels per line on output then on input, read one pixel on input, then write two on output - so we get VGAish timing.
Then PIO need one loop that reads pixel and writes it twice with correct timing. hmmm... It could work.

Just to fill that answer, as I was away some days:

Race the beam is a programming technique often used in games (ATARI was famous for it). It means, that you actually read only the current pixel and then directly output it. So you do not do anything other than that. This will convert it to a 15khz VGA signal.

If you need a 30khz VGA signal, you would need to buffer a single line, and then output it two times.

gregg has already answered that.

Thanks Guys again and I have some more questions, and some good news.

First a quick question to McArti0 - which exactly 256 lines I should use? I looked at the output from Amstrad with an oscilloscope and I see the following for each frame:
16 lines - hsync signal
10 lines - totally black
46 lines - top border
200 lines - actual screen
40 lines - bottom border
In total 312 lines.

So far I used 200 lines from the actual screen with a similar sized parts of both borders that gave me 256 and I am not 100% sure I am using the right part.

My second question is to everyone. I am getting close to be done with programming (still some electronics work left after that) and I am thinking what else I am missing. One of those is potentially a support for using csync instead of separate vsync and hsync. That may be needed depending on how it will be installed. I am considering a couple options. At this point I need: rgb output from gate array or video connector, hsync and vsync e.g. from gate array pins, 5v for rpi and ground. So I see a couple solutions. Which one would be the best in your opinion:

1. Put everything on a board that is installed outside of amstrad. It would be connected to video port, and it needs 5v. Maybe it could be plugged to both video output port and power input port. Then it would have a connectors for vga input and power adapter input. Something like - power goes into the board, then it powers pico and also goes to power socket in amstrad to power amstrad.
Pros: Simple to install - no need to change anything inside Amstrad or case.
Cons: The board would be bigger. I need to handle csync, that I am not yet 100% sure is doable in Pico.

2. Put it inside, on a board that plugs into Gate Array socket, and Gate Array is plugged into the board. It could be really small especially is we would not use the whole Pico board but rather directly install processor and a couple or parts on our board. I get all the signals from Gate Array. There would be e.g. a pin connector to connect vga socket on a tape that could go to anywhere, even potentially outside of Amstrad through some existing hole in case.
Pros: No need to cut anything in case, or remove any existing socket. I don't need csync. Smaller board. Lower total cost.
Cons: Need to open Amstrad. Need to put vga socket somewhere.

3. The same as 2 but vga socket is installed on the same board close to main board edge. Cut the hole in case for vga socket.
Pros: It is very simple.
Cons: Need to cut hole in case. Separate version for each Amstrad.

4. The same but different board shape so vga socket replaces video socket.
Pros: The same + no modifications to the case.
Cons: Need to remove original video socket. Separate version for each Amstrad.

Which option would be the best? Maybe some other, better solution I did not think about?
In my case it will be simpler because I plan to make it a part of my Amstrad clone board - much simplified to just play some games in living room, but I would like to make it useful for normal Amstrads.

And some good news:
I managed to make Pico double each line using a weird trick with two dmas. The only limitation is that number of lines that goes to VGA must be a power of 2. I am keeping 800x312 screen from Amstrad in memory and then output part of it with doubled lines (800x512) to 800x600 vga (actually I think it is svga) screen. It works well with all the monitors I found at home. The only bad thing are spare black 88 lines on a screen. I will try to do something about them, but I don't have idea yet.

Quote from: gregg on 16:01, 22 April 24First a quick question to McArti0 - which exactly 256 lines I should use?

if you meet a malicious programmer's code, you will have to use 286 lines.

Quote from: McArti0 on 18:02, 22 April 24

Quote from: gregg on 16:01, 22 April 24First a quick question to McArti0 - which exactly 256 lines I should use?

if you meet a malicious programmer's code, you will have to use 286 lines.

OK, but if I understand correctly it is some extreme case? How many existing software use 286 lines?
If I understood correctly your previous post, there is quite much software that uses overscan with 256 lines. So my question is just which 256 lines? Is it always the same 256 lines or each software use different ones?

Or maybe I can ask it in a different way - if you turn on Amstrad with original monitor, how many lines and columns do you see and which ones?
I would like use vga monitor and see about the same, and if some software draws anything on a border that would be visible on original Amstrad monitor, I would also like to see it.

Quote from: gregg on 16:01, 22 April 24I need to handle csync, that I am not yet 100% sure is doable in Pico.

You can split sync with a LM1881. That might help.

I would prefer option 1. I have different CPC machine and connect them to different screens. An external solution would be more flexible here.

Option 2-4: Keep in mind that there are 2(3) variations of the GateArray. You would need 2 different PCBs to cover that. And the 40007 GateArray requires to have a heat sink installed. I'm not sure if there is still enough space and if the heat sink can still be mounted with another PCB in between.

Btw: did you do some tests with games and demos that use scrolling and/or overscan? Many scandoublers fail with scrolling. A good test is e.g. Ghosts'n Goblins (easy, many scan doublers work fine) or Super Edge Grinder and Relentless (haven't found a scan doubler yet that works fine). Overscan will reduce/remove the borders so you will get up to 288 lines with content and no more borders.

Quote from: eto on 18:53, 22 April 24

Quote from: gregg on 16:01, 22 April 24I need to handle csync, that I am not yet 100% sure is doable in Pico.

You can split sync with a LM1881. That might help.

I would prefer option 1. I have different CPC machine and connect them to different screens. An external solution would be more flexible here.

Option 2-4: Keep in mind that there are 2(3) variations of the GateArray. You would need 2 different PCBs to cover that. And the 40007 GateArray requires to have a heat sink installed. I'm not sure if there is still enough space and if the heat sink can still be mounted with another PCB in between.

Btw: did you do some tests with games and demos that use scrolling and/or overscan? Many scandoublers fail with scrolling. A good test is e.g. Ghosts'n Goblins (easy, many scan doublers work fine) or Super Edge Grinder and Relentless (haven't found a scan doubler yet that works fine). Overscan will reduce/remove the borders so you will get up to 288 lines with content and no more borders.

Idea is LM1881 is great. Thanks. I will do it with if I don't manage to handle it in code.
Yep... forgot about different gate arrays. That would make it complicated.

I am only testing it with start screen and boulderdash that I have in rom. There is no real scroll there, so for sure I will test it with games you suggested. I am a bit afraid of potential screen tearing. What artifacts with scandoublers do you see in those games?
And first I need to fix one more issue with hsync timing. There is some jitter added by Pico that makes lines moving to the sides a little bit sometimes, so that would probably affect those tests.

Quote from: gregg on 19:01, 22 April 24What 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. 

Quote from: eto on 19:15, 22 April 24

Quote from: gregg on 19:01, 22 April 24What 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.

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.

Quote from: gregg on 19:29, 22 April 24nput is 50fps, output is 60fps,

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

Quote from: eto on 19:39, 22 April 24

Quote from: gregg on 19:29, 22 April 24nput 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.

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

Pinball Dream has ~280 line  sorry.

Quote from: McArti0 on 20:31, 22 April 24CPC 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 :D

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.

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.

Quote from: andycadley on 21:53, 22 April 24I 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.

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

Quote from: krusty_benediction on 22:13, 22 April 24This 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 :)

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

Quote from: McArti0 on 06:18, 23 April 24Many emulators show the screen as 40+200+32 (+/- 8 lines up or down)

Thanks! That is a very useful info!

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

Quote from: krusty_benediction on 11:29, 23 April 24Maybe 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!

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. 

Quote from: SerErris on 10:23, 26 April 24I 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.

Quote from: SerErris on 10:23, 26 April 24I 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.

Quote from: Deevee on 16:32, 26 April 24

Quote from: SerErris on 10:23, 26 April 24I 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 :)

Quote from: Deevee on 16:32, 26 April 24

Quote from: SerErris on 10:23, 26 April 24I 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.

Quote from: andycadley on 16:40, 26 April 24

Quote from: Deevee on 16:32, 26 April 24

Quote from: SerErris on 10:23, 26 April 24I 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)

Quote from: gregg on 16:46, 26 April 24

Quote from: andycadley on 16:40, 26 April 24

Quote from: Deevee on 16:32, 26 April 24

Quote from: SerErris on 10:23, 26 April 24I 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.

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

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

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.