- Welcome to CPCWiki forum.
The ultimate Amstrad CPC community!
News:
Printed Amstrad Addict magazine announced, check it out here!
Recent posts
#21
M
Technical support - Hardware related / Re: CPC 6128 - white screen, b...
Last post by mmldrm - Yesterday at 20:55After I short IORQ and READY, then turn on the CPC, pin20 of Z80 is 0 (well, 0.14v so I guess 'low' is correct).
Should I continue to short IORQ and READY? Or stop?
I removed IORQ->READY and added the RED connection. But voltage was 5v.
I expect you will say I must keep IORQ->READY so the Z80 remains stopped, while I do RED connect and measurements. But I wanted to confirm.
Should I continue to short IORQ and READY? Or stop?
I removed IORQ->READY and added the RED connection. But voltage was 5v.
I expect you will say I must keep IORQ->READY so the Z80 remains stopped, while I do RED connect and measurements. But I wanted to confirm.
#22
CPC has V-synch freq ..... 50,080(128205) Hz sorry.
Pinball Dream has ~280 line sorry.
Pinball Dream has ~280 line sorry.
#23
Applications (CPC and CPC-related) / Re: HDCPM - boot and run CP/M ...
Last post by d_kef - Yesterday at 20:29HDCPM v1.11 is here!
The new features are:
As always, you can download the new release at the HDCPM wiki page.
There you can also find a new .IMG containing many .EMS system files to try.
d_kef
The new features are:
- You can mount up to 100 different .IMG files and up to 4 Partitions to the 4 available mount points. As a consequence, CP/M (virtual) hard disks are now treated as removable. Use the new utility MOUNT.COM to list your available hard disks and mount them. So you can make your library of up to about 800MB of programs and data in mountable image files.
- RTC.COM now supports the NOVA interface.
- A couple of bugs were fixed.
As always, you can download the new release at the HDCPM wiki page.
There you can also find a new .IMG containing many .EMS system files to try.
Quote from: pollito on 20:35, 23 March 24d_kef would it be possible for you to update the version of the CP/M disk images ZIP on the HDCPM wiki page to include this version of CPMDSK01.IMG, so my 464 bretheren will suffer no more?That's also been included.
d_kef
#24
In maybe ten years, everything will go fpga. So no worries. Even now, a custom chip wonder gizmo such as C64's the most sought-after incarnation is the Ultimate 64... A computer made of over the shelf components such as CPC will always be available in some form.
#25
Quote from: eto on Yesterday at 19:39Yep... 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.Quote from: gregg on Yesterday at 19:29nput is 50fps, output is 60fps,Many VGA screens accept 50Hz input. It would be great to have that at least as an option.
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.
#26
Quote from: gregg on Yesterday at 19:29nput is 50fps, output is 60fps,Many VGA screens accept 50Hz input. It would be great to have that at least as an option.
#27
A
Amstrad CPC hardware / Re: VGA through rpi pico - How...
Last post by andycadley - Yesterday at 19:36A 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.
#28
Quote from: eto on Yesterday at 19:15OK. 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 Yesterday at 19:01What 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.
#29
Quote from: gregg on Yesterday at 19:01What 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.
#30
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).