[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Test: the cycle


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 speed 
toggle.



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. ;-) 


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


Giving a Disk ][ about one rotation to get up to speed is
certainly pushing the specification!
It's even slightly short of one revolution with 4 MHz Zip (IIc+). Higher speeds will shrink some more.
But I suppose it isn't surprising that it can do it. The drive motor is quite capable, the belt is relatively "stiff", and the disk and spindle moment of inertia is small.
It might oscillate when the writing begins (it was track writing after the big delay) so the written pulses will jitter. Hopefully Disk II sequencer handles that.
I have tested then with a 3rd party half-height floppy drive that is direct-drive (no belt, heavy spindle load for inertia) and it still seemed to work. Pure luck.
If somebody has 8 MHz or more Zip/IIc+ they can test - it must've been Locksmith Fast Disk Copy, when the target drive spins up and begins writing tracks. The first track written after spin up might fail. 


Yes, I can imagine a copy-protection scheme that used track sync
with a delay, though I can't quickly come up with anything that
would benefit from using such a delay...
Internal memory movement, decompression or decryption, then track change to an expected sector for further encrypted code/data.