Re: Test: the cycle

["Michael J. Mahon" <mjmahon@aol.com>]

Vladimir Ivanov wrote:
> On Thu, 9 Feb 2012, Michael J. Mahon wrote:
>
> > That's what the Zip Chip does with speaker and joystick access, but it
> > also slows down for Disk ][ access, since it won't work with a real
> > disk unless it's running at exactly 1MHz.
>
>
> It's the Apple IIgs that slows down on Disk II access - "motor on" 
> ($C0x9) is the key.
>
> ZipChip simply does about 50 msec slow down after I/O access. For normal 
> disk I/O that will be re-triggered constantly by the nibble read ($C0xC) 
> polling loop, but a longer than ~50 msec delay will be broken.
>
> http://www.bootzero.com/forum/viewtopic.php?f=3&t=12
>
> http://www.bootzero.com/forum/viewtopic.php?f=3&t=15
>
> I guess that they choose ~50 msec to not interfere with disk stepper. Of 
> course a track-synchronized copy protection might fail with ZipChip if 
> it has track-to-track delay of more than ~50 msec.
>
> Same goes for sound - if you have longer than ~50 msec pause/rest, tempo 
> becomes wrong.
>
> Same goes for any I/O that is separated by longer than ~50 msec lack of 
> I/O activity.

Exactly.  But the net effect is to slow down on Disk ][ access.

I develop on a Zip Chip-equipped //e, so all my cycle-counted code
depends on temporarily disabling the acceleration it provides.

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.

In my sound synthesis code, the problem of rests does not arise,
because a "rest" is actually a continuous stream of 22kHz speaker
pulses, so speaker references never actually stop.

I've never heard of any program that is incompatible with the
"50ms slowdown" approach, though as Vlad points out, one could
easily be constructed by using a timed disk access delay in
excess of 50ms.

Besides not being particularly useful, such a timed delay would
need to be quite tolerant of variations, since 50ms is 1/4th of
a rotation, and normal disk speed variations would result in a
significant variance in track position after such a long delay.

For cases where a shorter slowdown is appropriate, a reference
to the paddle timer trigger will cause the Zip Chip to slow down
for about 7ms, IIRC, if the chip's mode is set for paddle slowdown.

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