Not at work, but at home I run both emulators with a PAL 50 Hz CRT.
I would expect that you would have a pretty smooth playback in this kind of configuration (barring the occasional dropped/duplicated frame from the difference in video/audio timing), what kind of CRT are you using? I haven't had much luck with composite/S-Video output from computers being nicely synced with the video refresh, which is why I think 100Hz monitors are more likely to produce a good result with a PC.
Hey, and I absolutely believe ZXDS runs smoothly (I'll try to check it out this afternoon!). I have only ranted about Windows, Mac OS X and linux! LOL!
I also expect that you will often see issues with totally smooth scrolling on those platforms, though as I said I reckon the big issue encountered on those platforms is the Spectrum/Monitor frame rate.
I don't think that the big advantage of the DS is not having a multi-tasking OS, but I'm also sure it doesn't hurt.
But the accuracy of even cheap quartz crystal oscillators is such that to have sufficient drift caused by the clocks at something at audio frequencies would probably take hours of runtime to actually manifest itself as a glitch - certainly not 1/50th of a second.
For an audio glitch - doesn't take long to be out a fraction of a sample in my experience with Fuse, and the human ear is quite sensitive to this type of glitch. As I recall I would get them in a couple of minutes. Maybe other emulator bods have had different experiences?
For a video frame drop/gain I don't know, but I wouldn't be shocked if you would get them more often than you suggest. Say you are long 1 sample per frame, with 44100Hz you will have a frame size of 820 samples, it would take 820/50 = 16.4 minutes till you need to drop a frame to catch up with the audio.
Incidentally, I don't just see this with computers, my PVR plays back recordings slightly faster than realtime. If I rewind live TV a few seconds it only takes a few minutes before the buffer is extinguished and it goes back to live TV.
Edit: See a the accuracy of a sound card clock being measured at http://www.leapsecond.com/pages/sound-1pps/, he finds 44ppm in general for his card, which I think is just under 2 samples/sec at 44.1KHz so a lot longer till you get your dropped/duped frame than my suggested error rate of 1 sample/frame. Once you consider similar accuracy on CPU & video card all out of sync with each other, and with different errors there may be a few more to account for per second.
For an audio glitch - doesn't take long to be out a fraction of a sample in my experience with Fuse, and the human ear is quite sensitive to this type of glitch. As I recall I would get them in a couple of minutes. Maybe other emulator bods have had different experiences?
For a video frame drop/gain I don't know, but I wouldn't be shocked if you would get them more often than you suggest. Say you are long 1 sample per frame, with 44100Hz you will have a frame size of 820 samples, it would take 820/50 = 16.4 minutes till you need to drop a frame to catch up with the audio..
But it ain't going to have anything to do with the various different crystal oscillators in the PC, the cause will be something else, and in any case (shooting from the hip, not looking at the source code) I suspect the movement of the emulated ULA speaker output isn't just free running, rather, is going to be synchronized with whatever the basic time constant of the emulator happens to be. It doesn't really make sense for it to be done any other way, since the emulator isn't likely to try and predict what's supposed to be happening far in the future as far as toggling the speaker bit from 1 to 0 and vice versa.
But to take your hypothetical example, a cheap quartz crystal typically has an accuracy of 30ppm. But being off 1 sample in 820 is 1219ppm - i.e. grossly inaccurate - even my Dad's ancient pendulum grandfather clock is much more accurate than 1219ppm, so even the worst case of the CPU clock being, say, fast by 30ppm and the sound card clock being, say, slow by 30ppm, 1 sample in 820 is still several orders of magnitude worse than the worst possible case caused by the actual timing hardware.
I can quite confidently say that any sound glitches will have nothing to do with the variations between different clocks in a PC.
Reminds me of a book I was reading the other day which explains that one of the reasons Sinclair used a 7Mhz crystal was that by halving it to 3.5Mhz, they reduced the variance. I'm guessing this is one of the problems with over-clocking.
A trusty Trinitron. I don't see any video playback sync problem at 50 Hz, but it's perfectly possible that frame drops are actually occurring; they are unnoticeable on real video, but blatant on 50 Hz video game scrollers.
I also expect that you will often see issues with totally smooth scrolling on those platforms, though as I said I reckon the big issue encountered on those platforms is the Spectrum/Monitor frame rate.
I've just downloaded ZXDS! I'll stuff Cobra in and test it in a couple of minutes!
NB: 128K models actually DO NOT pass the test, so they are not COBRA-COMPLETE.
If memory serves well, I'd say that the "toastrack" and "+2 grey" models do implement the floating bus behaviour, and the only 128K models that don't implement it are the +2A/+3 (except my +3 of course :D )
But it ain't going to have anything to do with the various different crystal oscillators in the PC, the cause will be something else,
It's probably best to be clear about what you mean by "it", presumably dropped frames? I don't think I see any dropped/duplicated frames in the normal course of events - there will be some over a course of time due to the lack of sync between video and sound on much hardware, as at least in Fuse there is a specific bias to keeping the sound continuous at the expense of 50Hz video.
and in any case (shooting from the hip, not looking at the source code) I suspect the movement of the emulated ULA speaker output isn't just free running, rather, is going to be synchronized with whatever the basic time constant of the emulator happens to be. It doesn't really make sense for it to be done any other way, since the emulator isn't likely to try and predict what's supposed to be happening far in the future as far as toggling the speaker bit from 1 to 0 and vice versa.
In fact Fuse timing is based in terms of emulated tstates per sound frame when sound is enabled, when sound is disabled it is in terms of tstates per 20ms of OS measured time.
It caps the number of frames ahead of time that are run so there will be some input latency as the emulator has already emulated the frame ahead of the one you are looking at when you are playing. I wouldn't call that "prediction" as such - more a 20ms input latency, but it is how it's done.
But to take your hypothetical example, a cheap quartz crystal typically has an accuracy of 30ppm. But being off 1 sample in 820 is 1219ppm - i.e. grossly inaccurate - even my Dad's ancient pendulum grandfather clock is much more accurate than 1219ppm, so even the worst case of the CPU clock being, say, fast by 30ppm and the sound card clock being, say, slow by 30ppm, 1 sample in 820 is still several orders of magnitude worse than the worst possible case caused by the actual timing hardware.
I can quite confidently say that any sound glitches will have nothing to do with the variations between different clocks in a PC.
Am I making a mistake with my maths? 44/1000000 * 44100 = 1.9404 which is just under 2 samples/sec? I think that equals 1 sound glitch per second - very noticeable!
My concrete experience with Fuse is that trying to emulate 20ms of sound every 20ms of real time will quickly lead to full sound buffers or sound underruns, and with a 44ppm error as measured above you will be out by nearly 2 samples per second which will glitch very quickly.
Of course I may have stuffed up in Fuse, so would be happy to have any suggestions for improvements that could be made!
If memory serves well, I'd say that the "toastrack" and "+2 grey" models do implement the floating bus behaviour, and the only 128K models that don't implement it are the +2A/+3 (except my +3 of course :D )
I don't quite remember whether my "toastrack" can run Cobra... but I'm afraid it cannot. Dunno if it's actually a floating bus issue or other pesky incompatibility.
Glad you've found emulator nirvana - is that a real Speccy now? ;)
It is, thanks! At last, I can play Cobra in the train, LOL!
I'm still in the process of figuring out how the save slot, custom keyboard and preferences work. They seem to have a strange behaviour in my setup. Sometimes the saved preferences are read, sometimes not, etc.
The first "Spectrum" I ever experienced was a Portuguese Timex belonging to my cousin the first time I went to Portugal one summer. Among the first games played were Chuckie Egg, Spy Hunter, and Yie Ar Kung Fu.
After I moved there a year or two later I befriended a guy who had a Spectrum 48.
I wanted one and against all odds I finally got to get one but all the shop had was the gray +2 so that's what I got and I was happy with it. At least the man threw in a few free games.
Another friend had the +2a and another some other Spectrum.
A year or two later the other guy with the Spectrum 48, his father worked in a post office, and in some way I don't understand this gave him some leverage at getting a Sam Coupe earlier than most (late but early as far as Portugal went - we seemed to always get everything late), and so I got to experience that, too. My glasses helped keep my eyeballs inside my head when I saw the King Tut and Neil Armstrong picture in that SAM paint program.
Lots of game copying going on. I don't think it mattered. Most Spectrum software I ever saw in Portugal for sale in shops, in the little city I lived in, had a pirated look to it (the one that didn't were mostly Your Sinclair and Sinclair User tapes - I never did see Crash there)
This didn't last very long. I got into it late.
I guess I'm all over the place and never just got to use one thing, so to me if it is a Spectrum derivative and can play most original software, and looks and feels like a Spectrum when I'm looking at the screen, then to me it's Spectrum.
I don't consider a SAM Coupe a Spectrum really, but I do consider it its brother, and feel no shame in copping to it when defending the Spectrum against, well, you know. I don't mind calling it Super Spectrum.
If Sinclair/Amstrad had continued on with the Spectrum evolving it who is to say later resulting models wouldn't be Spectrums?
An Amiga 1200 is still an Amiga even though it's not a 1000.
But I can understand this being partial to what you used or had the most. I still have any emulator I use start as a +2 by default cause that's what I got and am more familiar with.
At Amiga forums the have this debate a hella lot even now with OS4, MorphOS and AROS and the AmigaOne X1000 (supposedly) coming out except they're usually not as civil as in this topic :-)
I don't care what you bolt on to augment a spectrum to improve it. Hard drives, sd adapters, network cards as long as at it's heart it's still that humble little machine with it's graphgical limitations that is instantly recognisable as a spectrum. As long as it still ran old games and we can develop games on it that can run on the original hardware I'd still hug it.
I'm even thinking of getting on of those ay addons for my 48k speccy.
Anyone thought of doing an add on for hardware sprites, masking and colour scrolling? hehe :razz:
That ound's like my crazy idea of havin a graphics card for the speccy.
Comments
I would expect that you would have a pretty smooth playback in this kind of configuration (barring the occasional dropped/duplicated frame from the difference in video/audio timing), what kind of CRT are you using? I haven't had much luck with composite/S-Video output from computers being nicely synced with the video refresh, which is why I think 100Hz monitors are more likely to produce a good result with a PC.
I also expect that you will often see issues with totally smooth scrolling on those platforms, though as I said I reckon the big issue encountered on those platforms is the Spectrum/Monitor frame rate.
I don't think that the big advantage of the DS is not having a multi-tasking OS, but I'm also sure it doesn't hurt.
For an audio glitch - doesn't take long to be out a fraction of a sample in my experience with Fuse, and the human ear is quite sensitive to this type of glitch. As I recall I would get them in a couple of minutes. Maybe other emulator bods have had different experiences?
For a video frame drop/gain I don't know, but I wouldn't be shocked if you would get them more often than you suggest. Say you are long 1 sample per frame, with 44100Hz you will have a frame size of 820 samples, it would take 820/50 = 16.4 minutes till you need to drop a frame to catch up with the audio.
Incidentally, I don't just see this with computers, my PVR plays back recordings slightly faster than realtime. If I rewind live TV a few seconds it only takes a few minutes before the buffer is extinguished and it goes back to live TV.
Edit: See a the accuracy of a sound card clock being measured at http://www.leapsecond.com/pages/sound-1pps/, he finds 44ppm in general for his card, which I think is just under 2 samples/sec at 44.1KHz so a lot longer till you get your dropped/duped frame than my suggested error rate of 1 sample/frame. Once you consider similar accuracy on CPU & video card all out of sync with each other, and with different errors there may be a few more to account for per second.
But it ain't going to have anything to do with the various different crystal oscillators in the PC, the cause will be something else, and in any case (shooting from the hip, not looking at the source code) I suspect the movement of the emulated ULA speaker output isn't just free running, rather, is going to be synchronized with whatever the basic time constant of the emulator happens to be. It doesn't really make sense for it to be done any other way, since the emulator isn't likely to try and predict what's supposed to be happening far in the future as far as toggling the speaker bit from 1 to 0 and vice versa.
But to take your hypothetical example, a cheap quartz crystal typically has an accuracy of 30ppm. But being off 1 sample in 820 is 1219ppm - i.e. grossly inaccurate - even my Dad's ancient pendulum grandfather clock is much more accurate than 1219ppm, so even the worst case of the CPU clock being, say, fast by 30ppm and the sound card clock being, say, slow by 30ppm, 1 sample in 820 is still several orders of magnitude worse than the worst possible case caused by the actual timing hardware.
I can quite confidently say that any sound glitches will have nothing to do with the variations between different clocks in a PC.
A trusty Trinitron. I don't see any video playback sync problem at 50 Hz, but it's perfectly possible that frame drops are actually occurring; they are unnoticeable on real video, but blatant on 50 Hz video game scrollers.
I've just downloaded ZXDS! I'll stuff Cobra in and test it in a couple of minutes!
Let's play!!
If memory serves well, I'd say that the "toastrack" and "+2 grey" models do implement the floating bus behaviour, and the only 128K models that don't implement it are the +2A/+3 (except my +3 of course :D )
It's probably best to be clear about what you mean by "it", presumably dropped frames? I don't think I see any dropped/duplicated frames in the normal course of events - there will be some over a course of time due to the lack of sync between video and sound on much hardware, as at least in Fuse there is a specific bias to keeping the sound continuous at the expense of 50Hz video.
In fact Fuse timing is based in terms of emulated tstates per sound frame when sound is enabled, when sound is disabled it is in terms of tstates per 20ms of OS measured time.
It caps the number of frames ahead of time that are run so there will be some input latency as the emulator has already emulated the frame ahead of the one you are looking at when you are playing. I wouldn't call that "prediction" as such - more a 20ms input latency, but it is how it's done.
Am I making a mistake with my maths? 44/1000000 * 44100 = 1.9404 which is just under 2 samples/sec? I think that equals 1 sound glitch per second - very noticeable!
My concrete experience with Fuse is that trying to emulate 20ms of sound every 20ms of real time will quickly lead to full sound buffers or sound underruns, and with a 44ppm error as measured above you will be out by nearly 2 samples per second which will glitch very quickly.
Of course I may have stuffed up in Fuse, so would be happy to have any suggestions for improvements that could be made!
Glad you've found emulator nirvana - is that a real Speccy now? ;)
I don't quite remember whether my "toastrack" can run Cobra... but I'm afraid it cannot. Dunno if it's actually a floating bus issue or other pesky incompatibility.
It is, thanks! At last, I can play Cobra in the train, LOL!
I'm still in the process of figuring out how the save slot, custom keyboard and preferences work. They seem to have a strange behaviour in my setup. Sometimes the saved preferences are read, sometimes not, etc.
After I moved there a year or two later I befriended a guy who had a Spectrum 48.
I wanted one and against all odds I finally got to get one but all the shop had was the gray +2 so that's what I got and I was happy with it. At least the man threw in a few free games.
Another friend had the +2a and another some other Spectrum.
A year or two later the other guy with the Spectrum 48, his father worked in a post office, and in some way I don't understand this gave him some leverage at getting a Sam Coupe earlier than most (late but early as far as Portugal went - we seemed to always get everything late), and so I got to experience that, too. My glasses helped keep my eyeballs inside my head when I saw the King Tut and Neil Armstrong picture in that SAM paint program.
Lots of game copying going on. I don't think it mattered. Most Spectrum software I ever saw in Portugal for sale in shops, in the little city I lived in, had a pirated look to it (the one that didn't were mostly Your Sinclair and Sinclair User tapes - I never did see Crash there)
This didn't last very long. I got into it late.
I guess I'm all over the place and never just got to use one thing, so to me if it is a Spectrum derivative and can play most original software, and looks and feels like a Spectrum when I'm looking at the screen, then to me it's Spectrum.
I don't consider a SAM Coupe a Spectrum really, but I do consider it its brother, and feel no shame in copping to it when defending the Spectrum against, well, you know. I don't mind calling it Super Spectrum.
If Sinclair/Amstrad had continued on with the Spectrum evolving it who is to say later resulting models wouldn't be Spectrums?
An Amiga 1200 is still an Amiga even though it's not a 1000.
But I can understand this being partial to what you used or had the most. I still have any emulator I use start as a +2 by default cause that's what I got and am more familiar with.
At Amiga forums the have this debate a hella lot even now with OS4, MorphOS and AROS and the AmigaOne X1000 (supposedly) coming out except they're usually not as civil as in this topic :-)
That ound's like my crazy idea of havin a graphics card for the speccy.