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

[gregg]

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

[McArti0]

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

[McArti0]

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

Im so sorry.

[gregg]

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.

[gregg]

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.

[McArti0]

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

[gregg]

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.

[SerErris]

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

[SerErris]

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

[gregg]

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.

[gregg]

Thanks for link. I will take a look there

[eto]

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

[gregg]

Aha, 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 

[genesis8]

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

[eto]

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 

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

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

[gregg]

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

[genesis8]

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   ?

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