The Amiga sounds different

[Nightfox]

I've noticed the seeking pitch of the floppy drive is higher when my Pistorm32 accelerator is connected in my A1200 vs if disconnected and just using the stock 68020.

How is it that a faster CPU makes the floppy drive header move faster? surely the CPU would instruct the floppy drive to seek as fast as possible to the required location and its speed would be detached from the CPU speed?

I thought it was my imagination at first but I've tried it with different floppy based games and I can hear the pitch of the header movement is of a higher frequency. Maybe half an octave if we are talking in musical terms.

Anyone know what is going on here?

[Daedalus]

Floppy drives are a little simpler than that. You can't tell a floppy drive head to "move to track 52" for example - all you can do is "move one track up" or "move one track down". And the CIAs that actually issue the control signals to the drive don't offer anything like that sort of automation either. As a result, the frequency of the steps is a result of the software that controls the drive. It may be timer or interrupt driven, which will regulate the speed somewhat, but if the CPU is too busy, the time between steps in the head movement will be longer and thus the frequency lower. Having lots of CPU speed available with a fast accelerator means the CPU is less likely to be busy enough to delay the steps, resulting in a higher step frequency.

Custom loading routines that disable multitasking also sound different to the OS floppy access routines in part for this reason too.

[Nightfox]

Ah interesting. Floppy drives are a lot dumber than I thought

[zipper]

I remember it did happen as I got a Supra 28 in to my A500.

[Galahad/FLT]

Depends entirely on the delay for the stepper motor.
Lots of old custom loaders did a simple dbra loop for the delay, obviously if the cpu is above 68000 then that delay is going to be gotten through much quicker.

If a vertical blank loop is used, there will be again a slight speed difference between PAL and NTSC Amigas.

And also whatever delay is used inbetween steps of the stepper motor, a faster processor is likely going to simply be quicker by enough of a degree that a slight noise difference is detectable.

If you want to showcase extremes, try Fire Force by ICE for a non existent delay, and then try Powermonger with a ridiculously long delay.

[Thomas Richter]

Psst.... even the trackdisk.device uses a dbra loop for timing of the stepper frequency. Since 3.2 or so at least with an access to the custom chips in the middle to limit the maximum frequency and make it at least somewhat CPU independent.

[Nightfox]

can you get a super fast CPU to make the floppy drive move super fast such that it causes damage or is there a limit to the influx of move commands the floppy drive will accept?

[Photon]

Originally Posted by Nightfox

can you get a super fast CPU to make the floppy drive move super fast such that it causes damage or is there a limit to the influx of move commands the floppy drive will accept?

For stepping, the step will probably be ignored if the pulse train is of too small width. The drive is saved from damage because any stepping will fall short and just read the wrong track, and any stepping to track 0 will stop on the dedicated signal, instead of stepping and failing forever. Possibly the stepper motor could be worn out if you don't reset or eject the disk when the infinitely failing step loop tries to step dozens or hundreds of times per seconds (should sound like a low or high beeeeeep forever).

This ignoring the signal is individual per floppy make and model, because they may have individual specs.

More importantly, the width will be smaller than the generic safe values in the HRM Appendix. Possibly these are for the floppy model used in the internal drive of the A1000 and the external A1010.

Even for a single Amiga model, there may be more than one make/model for the internal floppy drive. Later Amiga models have different floppy drives, and external drives probably have several.

CPU wait loops can be so fast on fantasy CPUs that the pulses fail on all floppy drives. The same is possibly true for the fastest Motorola CPUs as well, but not to the same extent as something running the same CPU hundreds of times faster.

It's perhaps extra devious when the emulated CPU running hundreds of times faster is a 68000. If the code is written well and adapts its floppy signal timing per CPU, the detection will say 68000 and it will run the code adapted for it. But it will be fooled by the fantasy speed and the timing will be hundreds of times too short.

[Megalomaniac]

Possibly dumb question, but was this also a cause of some games with custom loaders not working on A1200s and other accelerated systems?

[Galahad/FLT]

Originally Posted by Megalomaniac

Possibly dumb question, but was this also a cause of some games with custom loaders not working on A1200s and other accelerated systems?

Yes, in the majority of cases, the cpu timed delay for the stepper motor was why a load of games didn't load on A1200.

Did a lot of AGA fixes back in the day, and this was a common problem on lots of early games.

Once Rob Northens sector leader started getting used by devs then the problem largely went away.

[hooverphonique]

I would think that the minimum pulse width produced by the CIA GPIO's is E-clock dependent, and thus it shouldn't be possible to create a pulse so narrow, the drive misses it.

[pandy71]

Or perhaps decoding/encoding is faster so steps can be more frequent and for example drive may resonate less (every mechanical circuit has own resonance frequency, less frequent steps may be closer to primary or harmonic related resonance frequencies where faster steps may be less close to this resonance).
At some point stepper motor will start to loose steps if they are too frequent but i doubt if this is case for modern floppy drives - this could be for older designs with large stepper motors and some tricky solutions but modern, small FDD was way faster.