ahh, the HP 9133A - the largest and heaviest external 3 1/2" floppy drive ever built. let's get it working! 🧵
ahh, the HP 9133A - the largest and heaviest external 3 1/2" floppy drive ever…
Posted in
懷舊技術、產品
ahh, the HP 9133A - the largest and heaviest external 3 1/2" floppy drive ever built. let's get it working! 🧵
Comments (19)
whoops, surprise hard drive inside!
this one is a Seagate ST-506, a MFM drive with a whopping 5MB capacity!
after taking out 894375037 screws, the actual drive reveals itself.
oh yeah, the hard drive has a controller board on top of it. and on the controller board is this super weird potted electronics module. i'll have to look into that later.
the floppy drive is the extremely ancient Sony OA-D31V-1. it's not the first one to come out. more like the second one.
transmissive optical sensors hate dust bunnies. they'll produce false readings, so they must be cleaned!
a single-sided 3.5" drive head is something you don't see every day. they were never that common.
@mwichary worse, it is 270K and it uses 256 byte sectors. it also runs at 600 rpm!
@vk3kri yes
@bsdphk useful, can it handle partially corrupted images?
@bsdphk i'm going to try and get a better image file, then i will give it a shot.
@bsdphk
Traceback (most recent call last):
File "/home/eric/src_other/AutoArchaeologist/run_example.py", line 11, in <module>
from autoarchaeologist.container import argv
File "/home/eric/src_other/AutoArchaeologist/autoarchaeologist/container/argv.py", line 17, in <module>
import ddhf_bitstore_metadata
ModuleNotFoundError: No module named 'ddhf_bitstore_metadata'
@bsdphk ahh that solved it. new issue though, it looks like this hard drive image has 4 volumes but each has lifver set to 0, and the volume header is missing the track, head, and sector count fields, triggering a bug:
@bsdphk if you want to experiment, i put the whole disk image here: https://drive.google.com/file/d/1aTSBuvYilyCwlMffqJVZQTnmUwSarSrB/view?usp=sharing
hp9133a_st506_2.bin
drive.google.com@bsdphk David Gesswein pointed out to me by email that this image file has a software interleave of 9 and each track has a spare sector 31 which contains just a fill pattern and can be ignored. so that might explain some of the parsing difficulties.
@xan they are HPIB which is technically not GPIB. but basically yeah.
@bsdphk sent you the file in an email.
@wyatt this disk predates the standard
@JennyFluff iirc it is still just MFM
@RueNahcMohr yeah at some point the counters hit the limit and the disk automatically goes read-only. hp didn't support this for very long.