ahh, the HP 9133A - the largest and heaviest external 3 1/2" floppy drive ever built. let's get it working! 🧵

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.
i'm taking it apart this far because the drive mech needs to be cleaned and relubricated. the old grease hardens and makes the mechanism go sticky, so you'll be able to insert a disk, but when you try to remove it, it'll tear the head right off!
and it tests good! the weird 26-pin HP interface is natively supported by my Floppy Exerciser board (https://github.com/schlae/FloppyExerciser)
on to the surprise hard drive. but, no surprise, it won't spin up and pulls a bunch of current on 12v. hmmm.
the motor won't move. I think it is stiction. ugh.
yeah all the heads are stuck. trying a heat gun now...
it spins, but it sounds bad. not much hope for this drive, unfortunately.

the Gesswein MFM emulator was able to capture a flux transition dump! i used their mfm_util to analyze it, and it is a very odd format: check out the command line:

--format EC1841 --sectors 32,0 --heads 4 --cylinders 153 --header_crc 0x0,0xa00805,32,4 --data_crc 0x0,0xa00805,32,4 --sector_length 256

example output of the analyze command... some bad sectors, but a lot of good ones!

@tubetime

My AutoArchaeologist toolkit can turn the LIF filesystems into static HTML files so you can spelunk the contents.

Example:

https://phk.freebsd.dk/misc/fatfs/05/056ab17c6.html

Software:

https://codeberg.org/Datamuseum-dk/AutoArchaeologist

⟦056ab17c6⟧

@bsdphk useful, can it handle partially corrupted images?

@tubetime

I dont know how robust the LIF excavator is, I have only written/tried it on good images, but the general idea of AA is to handle whatever you throw at it, as well as possibe.

@tubetime

The fastest way to find out, is probably if you send me the image, but I can also walk you through the setup so you can run AA yourself.

(I've never finished the proper python packaging so it's a bit manual)

@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'

@tubetime

Sorry forgot to mention that dependency, that repos is also on our codeberg account:

https://codeberg.org/Datamuseum-dk/DDHF_bitstore_metadata

DDHF_bitstore_metadata

Metadata file handing for DDHF's bitarchive.

Codeberg.org
@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

Google Docs
@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.

@tubetime

Ok, figured the interleave out:

https://phk.freebsd.dk/misc/LIF9133/

Now we just need an examiner for the AutoArchaeologist to list the HP-BASIC programs

FATFS

@tubetime

Hmm, i think there's still something not quite right about the interleave: I'm seeing too much 0x6d 0xb6 in places it should not be.

Or maybe there is a bad-block remapping we need to figure out.

@tubetime

Ok, I think I got it now.

The interleave is:

[0, 9, 18, 27, 4, 13, 22, 8, 17, 26, 3, 12, 21, 30, 7, 16, 25, 2, 11, 20, 29, 6, 15, 24, 1, 10, 19, 28, 5, 14]

I've also added a very rudimentary BASIC-detokenizer (git pull to get it), and updated the output here:

https://phk.freebsd.dk/misc/LIF9133/_index__HP85_20Basic.html.html

(Bedtime in Denmark now :-)

Master Index: HP85 Basic

@tubetime

First time I see a LIF.version==0 🙂

I'll see what I can figure out.