Recent posts

#91

Technical support - Hardware related / Re: cable DDI-1 for CPC 6128

Last post by willow3411 - 17:51, 26 April 24

Hi all !
So here is my return
A 1:1 tablecloth is what you need.
No need to unplug the 5v in the FD1
we connect as in my photo (I printed stickers so as not to get the wrong direction), and it is recognized on disk B
Thank you Eto and all the others for your always valuable information!!!

Thanks @eto @Rabs @Bryce 

Willow3411

#92

CPCWiki Discussion / Re: Possible spam uptick

Last post by Gryzor - 17:48, 26 April 24

Didn't we have a user or two like that a while ago?

#93

CPCWiki Discussion / Re: Possible spam uptick

Last post by ComSoft6128 - 17:45, 26 April 24

Maybe not now but wouldn't a Forum (like this) be a good vehicle for an AI chatbot to be put thru its paces and indeed to see if it could pass the Turing test? 

#94

Amstrad CPC hardware / Re: VGA through rpi pico - How...

Last post by McArti0 - 17:28, 26 April 24

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

#95

Amstrad CPC hardware / Re: VGA through rpi pico - How...

Last post by Deevee - 17:20, 26 April 24

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.

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.

#96

CPCWiki Discussion / Re: Possible spam uptick

Last post by Gryzor - 17:10, 26 April 24

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

I know a couple of more forums that are suffering the same kind of attack.

How do you deal with this kind of situations?

Thanks for the feedback. 

Nothing special on our end. Regarding new accounts it's always on manual approval, so if something suspicious appears (username, email, IP) they're either required to verify (99% of spam accounts never do) or are denied right away. 

Regarding connections, haven't checked since the server is doing fine but I'll try to take a look. 

I'm sure that at least some spammy accounts have gone through, so I'm wondering what they're up to...

#97

CPCWiki Discussion / Re: Possible spam uptick

Last post by robcfg - 17:06, 26 April 24

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

I know a couple of more forums that are suffering the same kind of attack.

How do you deal with this kind of situations?

#98

G

Amstrad CPC hardware / Re: VGA through rpi pico - How...

Last post by gregg - 16:46, 26 April 24

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.

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)

#99

A

Amstrad CPC hardware / Re: VGA through rpi pico - How...

Last post by andycadley - 16:40, 26 April 24

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.

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.

#100

G

Amstrad CPC hardware / Re: VGA through rpi pico - How...

Last post by gregg - 16:39, 26 April 24

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.

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