-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
How about this: old hard drive sounds emulator?
- Thread starter BadGoldEagle
- Start date
Two things:
First, I have a number of obscure hard drives I could record if there was any interest, including a quasi-functional NEC 3.5” 105MB unit and a Sony SRD2040 (of Quantum infringement lawsuit and Apple recall for stiction infamy).
Second, regarding sound length vs. data transfer speed: what happens if the time it takes to play a sound is longer than the time needed to transfer data? SSDs are markedly faster than spinning disks, especially for seeks (the process that makes the desired sounds) so it’s entirely possible the sound playback/generation will take longer than the actual data access cycle. So: Does the system wait until the sound has completed before moving to the next data transfer task? Does the system queue sound for each access, resulting in the potential for sound generation continuing after data accesses have completed? Does it play random sounds on any access?
The answer is probably at least partly dependent on what’s generating the sounds, whether it’s the computer itself, the controller, or an external device monitoring the bus/controller accesses.
I’m also interested in how authentic it would sound: anybody who has ever tried to move 10MB to/from a 20MB MiniScribe 8425 in an SE knows it involves at least 30 seconds of sound and fury, whereas an SSD would complete the same task in only a fraction of the time, likely eliciting only a couple peeps from the sound generator (assuming sounds are generated only for the duration of the data access rather than one sound per seek event).
First, I have a number of obscure hard drives I could record if there was any interest, including a quasi-functional NEC 3.5” 105MB unit and a Sony SRD2040 (of Quantum infringement lawsuit and Apple recall for stiction infamy).
Second, regarding sound length vs. data transfer speed: what happens if the time it takes to play a sound is longer than the time needed to transfer data? SSDs are markedly faster than spinning disks, especially for seeks (the process that makes the desired sounds) so it’s entirely possible the sound playback/generation will take longer than the actual data access cycle. So: Does the system wait until the sound has completed before moving to the next data transfer task? Does the system queue sound for each access, resulting in the potential for sound generation continuing after data accesses have completed? Does it play random sounds on any access?
The answer is probably at least partly dependent on what’s generating the sounds, whether it’s the computer itself, the controller, or an external device monitoring the bus/controller accesses.
I’m also interested in how authentic it would sound: anybody who has ever tried to move 10MB to/from a 20MB MiniScribe 8425 in an SE knows it involves at least 30 seconds of sound and fury, whereas an SSD would complete the same task in only a fraction of the time, likely eliciting only a couple peeps from the sound generator (assuming sounds are generated only for the duration of the data access rather than one sound per seek event).
You could use a 2 or 3 second sample and play the full sample for each disk access, even it it were just a split second. If the files were a couple hundred Megs and it took say 10 seconds, you could play the sample 3 times or as many times as would fill the transfer time.I don't think the sound would have to match the disk access time precisely to bring pleasure to the user.
By "sample" do you mean "recording"? As discussed previously, it makes far more sense to me to synthesize the audio with a DSP.
On a Mac SE, Classic, etc. there is little to no difference in performance between an HDD and a SCSI2SD due to the 53C80 controller being so slow.
For a machine with a faster scsi controller, only a representative sample of operations would be synthed. The firmware would have minimum and maximum lengths for synthed seeks, reads, and writes based on real scsi drives. If the operations are too fast, then it would discard operations to meet the time constraints.
Another option might be to slow down the flash speed for a more realistic retro experience.
On a Mac SE, Classic, etc. there is little to no difference in performance between an HDD and a SCSI2SD due to the 53C80 controller being so slow.
For a machine with a faster scsi controller, only a representative sample of operations would be synthed. The firmware would have minimum and maximum lengths for synthed seeks, reads, and writes based on real scsi drives. If the operations are too fast, then it would discard operations to meet the time constraints.
Another option might be to slow down the flash speed for a more realistic retro experience.
Last edited by a moderator:
Looks like the added cost would be $18.
https://www.bigmessowires.com/2019/06/25/introducing-noisy-disk/
@Trash80toHP_Mini
The SCSI2SD with zombie hard drive would probably work well for a while, at least until the spindle bearings fail. The only things that would give away the fact that you're using this would be the increased speed and capacity, the lack of the start-up seek sequence, and the thermal recalibration routines like those used on the old Quantum LPS drives.
You could likely program an Arduino to control a zombie drive, initiating seeks off of the SCSI2SD's activity LED, but there would be a few parts required. First you'd need to build a multi-phase motor controller that can maintain constant spindle speed somewhere between 3600 and 5400 RPM, depending on drive model. Most 68k Mac drives operated between 3600 and 4200 RPM, with only high-end drives going up to 5400 RPM. Some AV drives may have spun at 7200, but that speed was more common in the beefier Quadras and Power Macs. Anyway you usually can't just use the original controller board's spindle controller because the drive's main controller often repeatedly cycles and/or completely shuts off the spindle motor if it doesn't POST correctly. Maybe you could isolate the spindle controller from the main controller? It depends on the drive model. Some use that stupid conductive rubber between the PCB and spindle motor, which complicates things.
Anyway, once the spindle motor is sorted, you'd have to program the Arduino to send rapid short voltages to the armature's voice coil to simulate the seeks. Some trial and error would be involved as you figured out the proper voltages and reduce the number of strikes to the limit bumpers. I figure just a constant middle voltage to keep the armature centered and then alternating voltage increase/decrease should be enough to get the clicky seek sound we all know and love.
Synthetic hard drive seeking sounds could be produced through a speaker, which would likely be simpler but you'd lose the spindle sound. I guess you could have the spindle sound on a loop that's interrupted with seek sounds when necessary.
The SCSI2SD with zombie hard drive would probably work well for a while, at least until the spindle bearings fail. The only things that would give away the fact that you're using this would be the increased speed and capacity, the lack of the start-up seek sequence, and the thermal recalibration routines like those used on the old Quantum LPS drives.
You could likely program an Arduino to control a zombie drive, initiating seeks off of the SCSI2SD's activity LED, but there would be a few parts required. First you'd need to build a multi-phase motor controller that can maintain constant spindle speed somewhere between 3600 and 5400 RPM, depending on drive model. Most 68k Mac drives operated between 3600 and 4200 RPM, with only high-end drives going up to 5400 RPM. Some AV drives may have spun at 7200, but that speed was more common in the beefier Quadras and Power Macs. Anyway you usually can't just use the original controller board's spindle controller because the drive's main controller often repeatedly cycles and/or completely shuts off the spindle motor if it doesn't POST correctly. Maybe you could isolate the spindle controller from the main controller? It depends on the drive model. Some use that stupid conductive rubber between the PCB and spindle motor, which complicates things.
Anyway, once the spindle motor is sorted, you'd have to program the Arduino to send rapid short voltages to the armature's voice coil to simulate the seeks. Some trial and error would be involved as you figured out the proper voltages and reduce the number of strikes to the limit bumpers. I figure just a constant middle voltage to keep the armature centered and then alternating voltage increase/decrease should be enough to get the clicky seek sound we all know and love.
Synthetic hard drive seeking sounds could be produced through a speaker, which would likely be simpler but you'd lose the spindle sound. I guess you could have the spindle sound on a loop that's interrupted with seek sounds when necessary.
Moon Roof Zombie Drive in a clear SE/30 case would be the point of the exercise for when the real deal dies.
View attachment 28872
SCSI or IDE interface of the donor mechanism shouldn't matter at that point. SEEING is believing, synths won't cut it for me. When the HDD is bolted up, "bone conduction" occurs and the chassis acts as the "speaker."
What's the voltage on the LED activity circuit?
View attachment 28872
SCSI or IDE interface of the donor mechanism shouldn't matter at that point. SEEING is believing, synths won't cut it for me. When the HDD is bolted up, "bone conduction" occurs and the chassis acts as the "speaker."
What's the voltage on the LED activity circuit?
Should be real low, 1.5-2.5v or so. Not enough to directly drive a voice coil, if that's what you're thinking. Just enough to use as a trigger for an Arduino or something.
One of the potential problems with mounting a skeleton drive in an SE or SE/30 is that the drive is usually upside-down in the original bracket; you'll need an aftermarket/custom bracket if you want it rightside-up. I have a cool old Fuji Electric 40MB hard drive that uses a stepper. It has an external wheel mounted to the stepper shaft that rotates during seeks, with notches around the perimeter including a mark to indicate if the heads are parked before power-down. Super cool but not really useful in upside-down fashion since the wheel is to the inside of the case and partially obscured by the mount in a stock configuration.
Not thinking about sounds so much as triggering a relay for a higher voltage, analog LED chase light circuit. [}
] 
