- Welcome to CPCWiki forum.
The ultimate Amstrad CPC community!
News:
Printed Amstrad Addict magazine announced, check it out here!
Recent posts
#91
A
Amstrad CPC hardware / Re: VGA through rpi pico - How...
Last post by andycadley - 19:36, 22 April 24A 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.
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.
#92
Quote from: eto on 19:15, 22 April 24OK. So first I need to have all timings ok, and I think scrolling will be nice test to check if I read input well.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.
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.
#93
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.
#94
So, yeah, triple-buffering has the advantage that you (OP) describe.
You can work with a single buffer, but it's got to remain clean enough at all times (e.g. constantly working incrementally).
You can work with a double buffer, where one buffer (front) is clean and gets displayed while you work into the other buffer (back). If you can't immediately page-flip (either because the hardware doesn't support it or because you don't want the tearing to be visible), you end up in a situation where you've finished drawing into your back buffer and you have to wait for the page-flip before you can draw your next frame.
With a triple buffer, you have 2 back buffers, once you're done drawing into one of them, you can immediately start drawing into the other one, so you have a higher frame rate compared to double-buffer since you can always start drawing (with the understanding that there'll be some judder). This is not useful if you can draw faster than your refresh rate, but that's a good problem to have.
Double- and Triple-buffering on the CPC face 3 main challenges:
-all the buffers must fit in the low 64kB of RAM.
-if you use the firmware, it carves out 2 chunks of RAM in those low 64kB.
-bank mapping only has a small number of configurations, which creates constraints. E.g. using banks 1 and 3 for buffers feels natural, until you realize that no memory config maps bank 1 at the same time as banks 4-6, so you can't directly copy graphics from banks 4-6 to bank 1.
For triple-buffering specifically, the smaller your screen, the easier things get. Smaller than 5.33kB, 3 buffers fit in 1 banks, that's very easy. Smaller than 8kB, 3 buffers fit in 2 non-contiguous banks, that's very feasible and very similar to regular double-buffering. Smaller than 10.66kB, 3 buffers fit in 2 contiguous banks. Up to 16kB, 3 buffers need 3 banks, Beyond that and up to 21.33kB, you need all 4 banks and madness lies ahead (you can do resolutions like 312x280, 352x248, 376x232 in mode 1).
You can work with a single buffer, but it's got to remain clean enough at all times (e.g. constantly working incrementally).
You can work with a double buffer, where one buffer (front) is clean and gets displayed while you work into the other buffer (back). If you can't immediately page-flip (either because the hardware doesn't support it or because you don't want the tearing to be visible), you end up in a situation where you've finished drawing into your back buffer and you have to wait for the page-flip before you can draw your next frame.
With a triple buffer, you have 2 back buffers, once you're done drawing into one of them, you can immediately start drawing into the other one, so you have a higher frame rate compared to double-buffer since you can always start drawing (with the understanding that there'll be some judder). This is not useful if you can draw faster than your refresh rate, but that's a good problem to have.
Double- and Triple-buffering on the CPC face 3 main challenges:
-all the buffers must fit in the low 64kB of RAM.
-if you use the firmware, it carves out 2 chunks of RAM in those low 64kB.
-bank mapping only has a small number of configurations, which creates constraints. E.g. using banks 1 and 3 for buffers feels natural, until you realize that no memory config maps bank 1 at the same time as banks 4-6, so you can't directly copy graphics from banks 4-6 to bank 1.
For triple-buffering specifically, the smaller your screen, the easier things get. Smaller than 5.33kB, 3 buffers fit in 1 banks, that's very easy. Smaller than 8kB, 3 buffers fit in 2 non-contiguous banks, that's very feasible and very similar to regular double-buffering. Smaller than 10.66kB, 3 buffers fit in 2 contiguous banks. Up to 16kB, 3 buffers need 3 banks, Beyond that and up to 21.33kB, you need all 4 banks and madness lies ahead (you can do resolutions like 312x280, 352x248, 376x232 in mode 1).
#95
Quote from: eto on 18:53, 22 April 24Idea is LM1881 is great. Thanks. I will do it with if I don't manage to handle it in code.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.
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.
#96
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.
#97
Quote from: McArti0 on 18:02, 22 April 24OK, but if I understand correctly it is some extreme case? How many existing software use 286 lines?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.
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.
#98
Quote from: cpcitor on 23:56, 20 April 24Absolutely, no practical problem. Like having a machine that behaves exactly like a CPC for all practical purposes, but doesn't have the same appearance. It would not be the real thing. "Oh you mean like a AZERTY CPC" Oh. Well... never mind.Quote from: chinnyhill10 on 15:11, 20 April 24It's not a huge problem. Stocks won't be running low any time soon. So many have been made in fact I doubt we'll see a shortage in our lifetimes.
I agree. This is not a practical problem. I would be tempted to compare this to (like: a smaller case of) having a machine that behaves exactly like a CPC for all practical purposes, but doesn't have the same appearance. It would not be the real thing. "Oh you mean like a Schneider CPC." Oh. Well... never mind.
Moreover, the Z80 in the real CPCs weren't made by Zilog anyway, right.
#99
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.