Would there be any benefit/point to 60 Hz CPC? Also, connecting to PC via 3" etc

[db6128]

I would have replied to this old thread about the 60 Hz link and its implications, but I got the 120-day warning and thought it might be better to start a new thread; if staff would prefer to merge it into that, then please do so.

Anyhow, I'm starting to get sucked back into the CPCverse, partly due to my recent attempts to learn programming; the subsequent realisation that my childhood forays into BASIC were, well, too basic; and the fact that both this same curiousity and the intrinsic sluggishness of interpreted language make me want to try ASM - to see whether the CPC can handle a much-downscaled version of the my main hobby-project, and partly because it's annoyed me in C++ so much that I'm seeking a break somewhere else

Also, my inner geek has been rapidly unleashed by the idea of being able to transfer stuff between the CPC and a 'normal' PC. In the short term, this would seem to involve connecting the FD-1, once I've solved its inevitable drive-belt issue - or at least I hope it's something that simple. I have a different 3" drive - some Hitachi model that I still have no idea where I got but that recent research suggests was also used in the Tatung Einstein - that used to work on an old DOS machine, but it doesn't seem to agree with my 'newer' (Socket A/462, Windows XP crying out to be downgraded to 98SE) PC, which I hope is due to the PC, the cables, or something . . . rather than a broken drive. Anyway, In the long term, I dare say I'll end up dropping the £80 or so for an HxC; I tell myself it's a sound investment for many other reasons too . . . potential reasons, at least

So, with those ramblings aside (but feel free to give tips or suggestions about the disk drives!), back to the actual topic. I read in my copy of The Amstrad CPC 464 Whole Memory Guide that there's a link on the board that determines the screen's refresh rate, and I promptly found the aforementioned thread giving a few more details. I'm likely to soon buy a SCART cable and power adaptor so that I can run my 6128 on my Sony Trinitron CRT TV (widescreen :/ ) rather than ye olde GT65. And since learning about the 50/60 Hz dichotomy, I've always assumed that the latter is superior, usually because I place more value on speed of motion than vertical resolution in games. I acknowledge that the CPC is unlikely to reach 50 or 60 fps in most contexts, so is there any point to even considering modding mine to 60 Hz for the TV? Since I didn't quite understand the discussion of the hardware in that thread, does either option result in (even marginally) faster execution speeds? I'd take that as reason enough to do the mod if it wouldn't screw up existing software, which I acknowledge as a possibility.

Yeah, sorry for how meandering and dense this became, but I hope that some people have opinions and that we can get an interesting discussion out of it! I'm definitely looking forward to participating in the forum and wiki wherever I can.

[arnoldemu]

Welcome!

I would say 60Hz is not supported by anything except the OS. Sad fact but true.

Even Soft968 mentions that the values for 60hz are wrong too, so if you made it work software may go wrong, and you need to do some kind of patch to correct them.
http://www.cpctech.org.uk/docs/manual/s968ap13.pdf

I expect most programs don't even check this link, so they will force themselves into 50Hz anyway. (Some software will set the crtc values so go into 50hz).
All demos will setup 50Hz timings.

I think you'd gain little by making this change, but if you want to do it anyway, it would be an interesting experiment to see exactly what results you get. (do it with a switch so you can go back to 50Hz ).

Please don't let me put you off it you want to give it a try.

I know that with 60hz games may be a little smoother.

Back to programming: There are more options now, BASIC, C, ASM, compiled BASIC. And various code examples that will help you.

If you don't get the drive to work, but I hope you do because it is so much better with a drive, you can use tape files and play the music through your pc's soundcard. I do this, but it takes time to load, so only really worth it for testing short pieces of code.

Please feel free to ask about coding and things.

[SyX]

I think the same than arnoldemu, most programs are going to set the CRTC in 50Hz, only the programs don't change the actual system values are going to work with your mod, and in these cases you could always make a basic program with the necessary OUTs to put the CRTC at 60Hz.

At the end, it will be more effective to patch the programs that you are most interested, usually it's not a difficult task.

With respect at nobody checking for 60Hz, it's logical, has anybody seen an NTSC CPC? 

But it's a nice feature, i love how arcadish looks my cpc attached by scart to a crt tv  . I have added this mode to my programs; for example, the Pac-Man emulator has an smoother gameplay at 60Hz (enter in Service Menu with TAB, and with SPACE toggle between 50/60Hz).

[db6128]

Thanks for the replies and welcome!

I did think it might not be worth the time, but it's perhaps something worth bearing in mind if I ever get skilled and/or OCD enough to need whatever small amount of extra speed it might provide.

I would say 60Hz is not supported by anything except the OS. Sad fact but true.

Even Soft968 mentions that the values for 60hz are wrong too, so if you made it work software may go wrong, and you need to do some kind of patch to correct them.
http://www.cpctech.org.uk/docs/manual/s968ap13.pdf

This is very interesting, so thanks. And I think this document will provide plenty of reading on other topics, too!

I expect most programs don't even check this link, so they will force themselves into 50Hz anyway. (Some software will set the crtc values so go into 50hz).
All demos will setup 50Hz timings.

Interesting. By no means do I want to suggest you're wrong, especially given your obvious levels of knowledge (the name is a hint ) and my lack thereof, but I'd assumed it might be a system-/session-wide change due to this passage in the Whole Memory Guide (which is basically another firmware guide, compiled by Don Thomasson):

Main Reset

At switch-on, or in response to instruction code &C7 [= rst &00], location [&]0000 is entered. [. . .]

The CRT Controller is then set up. There are two alternative sets of values for this, one for 50 Hz frame scan and the other for 60 Hz. The set to be used is determined by reading port B, bit 4. [. . .] this being determined by the presence of Link 4 on the main printed circuit board.

But again, both myself and this explanation might be wrong (myself being more likely!) I'm just going to see what the official firmware manual and the modern firmware guide have to say, which might well differ.

I think you'd gain little by making this change, but if you want to do it anyway, it would be an interesting experiment to see exactly what results you get. (do it with a switch so you can go back to 50Hz ).

Please don't let me put you off it you want to give it a try.

Haha, thanks, but I think I will leave it after all. Perhaps if I ever get savvy with switches, soldering, etc. - which is on the (very, very long) list - I'll try it out some other time!

Back to programming: There are more options now, BASIC, C, ASM, compiled BASIC. And various code examples that will help you.

Yeah, I'm looking forward to trying SDCC, perhaps even before ASM since I think the latter might be a bit too much at first. Compiled BASIC is a nice idea, too, and I know there's a BBC version somewhere as well as good old Locomotive.

If you don't get the drive to work, but I hope you do because it is so much better with a drive, you can use tape files and play the music through your pc's soundcard. I do this, but it takes time to load, so only really worth it for testing short pieces of code.

Thanks for the info; I have in fact done something very similar before using recordings of tapes burned onto CDs after being sped up by considerable amounts - which made my younger self feel like quite a wizard!
It probably is just the belt, but I've not had enough patience to wrangle open the FD-1 yet: the circuit board seems to have more wires than the two guides I've seen suggest, and it doesn't want to leave! I'll get around to it eventually, haha. Although I do foresee myself switching to an HxC ultimately, especially if I get further on with development - or just engrossed in the back-catalogue.

[Axelay]

Interesting. By no means do I want to suggest you're wrong, especially given your obvious levels of knowledge (the name is a hint ) and my lack thereof, but I'd assumed it might be a system-/session-wide change due to this passage in the Whole Memory Guide (which is basically another firmware guide, compiled by Don Thomasson):

The firmware will be setting the hardware as described, the point arnoldemu makes is that the CRTC is readily reprogrammed by software later with the firmware typically sidelined or disabled, and the chances that any other software is checking for the 60Hz case is close to nil.

Bearing in mind that I'd also say you should do whatever interests you and not pay attention to anyone else  , but in my view, the 'benefits' of 60Hz are greatly over exaggerated.  So far as I can tell it's largely based on comparing original 60Hz games with their 50Hz counterparts, where those 50hz games have not been optimised or re-tuned for 50Hz in the slightest.  It's akin to looking at a spectrum port on the CPC and presuming the spectrum is 'superior', when all it really shows is that software runs better in the environment it was designed for.

As I understand the situation, if you were to try and take 50Hz games and make them run at 60Hz without optimisation and tuning, you would face exactly the same problem, as even though the screen refresh rate changes, the CPU speed does not.   So where going from 60hz to 50hz results in the CPU waiting longer for that next screen refresh that is further away than expected and a lower frame rate as a result, for code designed to make the most of 50hz, the next screen refresh would have already been and gone by the time the code is waiting for it with a 60hz refresh, so it will actually wait for an additional screen refresh and also result in a lower frame rate.   A 50fps game at 50hz would then end up at 30fps at 60hz, a 25fps game at 20fps.  Or possibly worse, if the cpu time used is not entirely consistent, you could end up with a game going at 60fps frequently dropping to 30fps, or 30fps frequently dropping to 20fps.  So I dont think there would be much to gain from a 60hz CPC.

[arnoldemu]

As I understand the situation, if you were to try and take 50Hz games and make them run at 60Hz without optimisation and tuning, you would face exactly the same problem, as even though the screen refresh rate changes, the CPU speed does not.   So where going from 60hz to 50hz results in the CPU waiting longer for that next screen refresh that is further away than expected and a lower frame rate as a result, for code designed to make the most of 50hz, the next screen refresh would have already been and gone by the time the code is waiting for it with a 60hz refresh, so it will actually wait for an additional screen refresh and also result in a lower frame rate.   A 50fps game at 50hz would then end up at 30fps at 60hz, a 25fps game at 20fps.  Or possibly worse, if the cpu time used is not entirely consistent, you could end up with a game going at 60fps frequently dropping to 30fps, or 30fps frequently dropping to 20fps.  So I dont think there would be much to gain from a 60hz CPC.

If a game waits for the next frame before doing a "present", which is normally how it works, then in theory 60Hz can be smoother because there are more updates, so you have potentially less wasted frame time waiting until the next "present" time compared to 50Hz.

[db6128]

 Great points, everyone. I don't think it's worthwhile right now.

I'm also guessing that CPCs in the US (which, if you believe Wikipedia, is where the 6128 was first released) were just the same as the European ones but with adapted PSUs?

Anyhow, I still have to figure out how to lift the circuit board far enough from the drive to try changing the belt, especially without breaking any circuitry, wires, etc. :/ From what little I can see at the moment, the belt appears to be intact, at least around the capstan, but I previously verified that the spindle is not turning, so I really hope it is just the belt and it's broken in some other location/way.

[Axelay]

If a game waits for the next frame before doing a "present", which is normally how it works, then in theory 60Hz can be smoother because there are more updates, so you have potentially less wasted frame time waiting until the next "present" time compared to 50Hz.

I guess I was thinking in terms of games with a consistent frame rate, assuming they've been worked out to a 'CPU budget' for the target frame rate.  What you're describing makes me think more of CPU time being some 'arbitrary' value that is as long as it takes and just waits for the next screen refresh to come along.

[ivarf]

Anyhow, I still have to figure out how to lift the circuit board far enough from the drive to try changing the belt, especially without breaking any circuitry, wires, etc. :/ From what little I can see at the moment, the belt appears to be intact, at least around the capstan, but I previously verified that the spindle is not turning, so I really hope it is just the belt and it's broken in some other location/way.

It don't need to broken to not work, it may be to loose

[arnoldemu]

I guess I was thinking in terms of games with a consistent frame rate, assuming they've been worked out to a 'CPU budget' for the target frame rate.  What you're describing makes me think more of CPU time being some 'arbitrary' value that is as long as it takes and just waits for the next screen refresh to come along.

Yes it's a choice. Lock you game to a specific number of frames, or let it take as many frames as it needs for "1 update", then switch when you're ready.

If it's "as many as it needs for 1 update" the game can slow down and speed up. In this case 60Hz may result in smoother play compared to 50Hz. Some games do this, but they keep track of this and adjust times that must be in exact seconds using a "frame adjustment" or how long the frame took compared to how long it should take. So that if something needs to take 5 seconds, it really does regardless of actual frame rate.

True, if the game is locked at a specific number of frames, you'll have less time in 60Hz, especially if you're doing that measuring using vsyncs.