Quote from: gregg on Today at 16:46Quote from: andycadley on Today at 16:40Sorry, 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: Deevee on Today at 16:32Yeah, 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: SerErris on Today at 10:23I 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: robcfg on Today at 17:06On the forum I'm administrator of we're getting an insane amount of connections and login attempts, to the point that it's almost impossible to do anything.Thanks for the feedback.
I know a couple of more forums that are suffering the same kind of attack.
How do you deal with this kind of situations?
Quote from: andycadley on Today at 16:40Sorry, 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: Deevee on Today at 16:32Yeah, 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: SerErris on Today at 10:23I 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 Today at 16:32Yeah, 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: SerErris on Today at 10:23I 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 Today at 16:32Quote from: SerErris on Today at 10:23I 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: SerErris on Today at 10:23I 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 Today at 10:23I would still do it line by line.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.
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.
Page created in 0.054 seconds with 16 queries.