On SOUND and Music 5000, B-Em Speed Full-speed (sic) accelerates duration but not pitch. Also accelerated is e.g. key repeat rate.
I guess the program design has chosen which clocks to accelerate (e.g. CPU, 100Hz VIA) and which to leave unchanged (SN76489 and Music 5000).
I wonder if the use cases for Speed and in particular Full have been sufficiently considered here. ISTM the current Full behaviour is if little practical use. And what the user wants of Full is reduce user wait time due to e.g. CPU execution, disc loading etc. but retain key repeat rate and duration. Which perhaps could be by just retaining the VIA clock. Perhaps as an option.
Thoughts?
B-Em speed
Re: B-Em speed
Chris, yes I think we have done what is easy here, rather than starting by thinking what is useful, but there are some technical considerations.
The timing alignment between the core components, i.e. CPU, 6522s and 6845 can be critical, both for games like Elite that re-program the 6845 part way down the screen to have a different trade-off between colours and spacial resolution on different parts of the screen, and for some very clever software protection schemes that attempt to spot any attempt to step/trace the code. These components work in lock-step then, through the 6502 CPU emulation calling out to the emulation of various other components. It does this much more frequently that a frame of video - in some cases after exactly the right number of 2Mhz clock cycles, partway through the execution of a 6502 instruction.
The general speed of the emulated machine is controlled by setting an interval timer to generate an event to which the response is "run one frame of 6502 instructions", i.e. the right number of 2Mhz cycles to generate one frame of video, and that is processed in a loop that processes other events such as keystrokes and mouse movement as reported to B-Em by the OS. To make the emulated machine go faster, we request that this event is generated more frequently so yes, that does speed up the whole of the core machine, not just the CPU.
In the case of the Music 5000 emulation, though, we found that we can't tell Allegro, which will then tell the OS, to set an audio sample rate and then rely on there being no drift between that and the interval timer used for timing the 6502, 6522 etc. That means if we try to push samples to the sound system based on the core machine timing we get underruns/overruns depending on the hardware/OS and maybe even whatever else is running. The solution is that we let the Allegro sound system pull the samples, i.e. we work out approximately how often we want to supply a new buffer full of samples to Allegro, which will then forward them to the OS and on towards the sound card, work out the size of that buffer and then ask Allegro to generate an event whenever a new buffer full of samples is needed.
In practice, that means whatever happens in hardware in a real Music 5000, is tied to the sound system's clock and does not speed up when the speed of the core machine does, whereas whatever is controlled in software in AMPLE will speed up with the rest of the machine.
The timing alignment between the core components, i.e. CPU, 6522s and 6845 can be critical, both for games like Elite that re-program the 6845 part way down the screen to have a different trade-off between colours and spacial resolution on different parts of the screen, and for some very clever software protection schemes that attempt to spot any attempt to step/trace the code. These components work in lock-step then, through the 6502 CPU emulation calling out to the emulation of various other components. It does this much more frequently that a frame of video - in some cases after exactly the right number of 2Mhz clock cycles, partway through the execution of a 6502 instruction.
The general speed of the emulated machine is controlled by setting an interval timer to generate an event to which the response is "run one frame of 6502 instructions", i.e. the right number of 2Mhz cycles to generate one frame of video, and that is processed in a loop that processes other events such as keystrokes and mouse movement as reported to B-Em by the OS. To make the emulated machine go faster, we request that this event is generated more frequently so yes, that does speed up the whole of the core machine, not just the CPU.
In the case of the Music 5000 emulation, though, we found that we can't tell Allegro, which will then tell the OS, to set an audio sample rate and then rely on there being no drift between that and the interval timer used for timing the 6502, 6522 etc. That means if we try to push samples to the sound system based on the core machine timing we get underruns/overruns depending on the hardware/OS and maybe even whatever else is running. The solution is that we let the Allegro sound system pull the samples, i.e. we work out approximately how often we want to supply a new buffer full of samples to Allegro, which will then forward them to the OS and on towards the sound card, work out the size of that buffer and then ask Allegro to generate an event whenever a new buffer full of samples is needed.
In practice, that means whatever happens in hardware in a real Music 5000, is tied to the sound system's clock and does not speed up when the speed of the core machine does, whereas whatever is controlled in software in AMPLE will speed up with the rest of the machine.
Re: B-Em speed
I was assuming Speed Full would not be useful on games.
Just VIDEO PROC, I believe. But AFAICT that should be no promlem for Speed Full, presming acceleration includes both VIA and screen scan.
EDIT: I can that's true if core machine is defined as "every part that's sped up"
AFAICT, that's all parts but sound.So, the acceleration's non-uniformity is a result of and defined by implementation practicalities rather the design objective. I fully appreciate the merit of the choice there. I well remember my attempted AMPLE port to Windows 95 and frustration at it being unable to keep a beat.
Re my idea of a Speed Full mode that excludes duration, I will think more. To have the HMS UI be instant would be ace. The time-critical M5 PHSET code mentioned elsewhere would need to be time-proofed, but all else should work like a dream OOTB.
Thanks.