Vladimir Ivanov wrote:
On Sat, 11 Feb 2012, Michael J. Mahon wrote:Vladimir Ivanov wrote:On Fri, 10 Feb 2012, Michael J. Mahon wrote:I develop on a Zip Chip-equipped //e, so all my cycle-counted code depends on temporarily disabling the acceleration it provides.Yes, as long as they are cyclic enough.In NadaNet, my approach is to reference the "motor off" softswitch repeatedly (more often than every 50ms) in NadaNet arbitrate, send,and receive code. I find this approach much simpler than the IIgs approach of using multiple instructions to set and reset a speedtoggle.This is definitely a very specific corner case. :-)But it is a quite general technique for disabling acceleration in timing-critical code that has a loop period of less than 50ms. In the case of NadaNet, the maximum packet size is 256 bytes, plus an 8-byte header, all of which takes less than 51ms, so a single instruction in serve, send, receive, and arbitrate subroutines does the job, with no need to explicitly switch back to fast mode. I'd venture to say that a very large fraction of timing-critical code cases can be handled in exactly the same way.I can see the utility in the ZipChip one-shot throttle mode. But also I am personally slightly disturbed by the unnecessary debugging it caused me, so a mixture of this and IIgs' disk-on mode would've been better. ;-)
I agree, but for backward compatibility, the 50ms trigger approach was a fine approach--just not perfect. Now if the "fast/slow" switch of the IIgs were a simple softswitch, I'd be even happier.
(After Apple released the IIc+, I supposed that they had endorsed this acceleration switching mechanism, and was surprised to find that only the "go slow/go fast" switch mechanism was supported by the IIgs.)The IIgs predates IIc+. IIgs has only on/off mode because they solved I/O timing differently - mostly by putting the I/O drivers C100..CFFF behind the slow-clocked Mega II. What needed special attention was Disk II and thus the user-configurable slot 4/5/6/7 disk-on detection came.I see the IIgs approach as more deterministic and free from the burden of carefully tuning loops.
I'm afraid that shows how little time I spent thinking about the IIgs... A fairly long 50ms timout allows for pretty simple/sloppy tuning!
PWM can't have problems with ZipChip. I was thinking simpler one-voice output.Certainly the common case, and one that is very common if, for example, animation is interspersed with sound generation.Game would be possibly unplayable under acceleration if the music is not always on. :-)The one that bit me nasty with HDDD A2 - very popular disk copy program (I think it was Locksmith) doing simple timed delay on drive spin-up. With 4 MHz ZipChip this delay goes less than 200 msec and it's a bit of a miracle that regular Disk II drive is still able to write reliable data.Yes, that makes sense. RWTS uses an "interactive" method which is served well by the Zip Chip approach, but a simple long-delay loop would fail.Yes. Locksmith is smart and simple enough to just do a delay.
But the RWTS approach detects that the motor is still on and doesn't wait at all--even smarter. ;-) -michael NadaNet 3.1 for Apple II parallel computing! Home page: http://home.comcast.net/~mjmahon/ "The wastebasket is our most important design tool--and it's seriously underused."