20 Sep
2016
20 Sep
'16
6:42 a.m.
Does anyone know of documentation for the HP9895A format with its own M2FM encoding?
I have a kryoflux preservation stream but so far can make no sense of it.
Denise
________________________________
20 Sep
20 Sep
6:13 p.m.
On Tue, Sep 20, 2016 at 7:42 AM, Denise de Vries
<denise.devries at flinders.edu.au> wrote:
Does anyone know of documentation for the HP9895A
format with its own M2FM encoding?
I have a kryoflux preservation stream but so far can make no sense of it.
I've successfully decoded Intel M2FM disks. The track-level format
isn't the same as the HP 9895A, but the channel code is. I'd be happy
to take a look at a 9895A image.
11:59 p.m.
On Tue, 20 Sep 2016, Eric Smith wrote:
On Tue, Sep 20, 2016 at 7:42 AM, Denise de Vries
<denise.devries at flinders.edu.au> wrote:
I've already written a decoder for the HP 9885/9895 format. Denise already
sent me his image, but I haven't had the time to try decoding it yet...
Here's a rough sketchup of what my decoder does:
- Find the sync pattern (several 0x55)
- Swap the bits in each byte (i.e. MSB<-->LSB)
- Look for an address mark (clock pattern always 0x0E)
- 0x70: ID address mark
Calculate CRC16 (initial value 0xFFFF) over four bytes
- 0x50: data address mark
- 0xF0: defective track address mark
- 0xD0: ECC data address mark
- The ID address mark contains the following information:
0: cylinder
1: head in bit 7, sector in bits 5..0
2: CRC byte 1
3: CRC byte 2
Christian
Does anyone know of documentation for the HP9895A
format with its own M2FM encoding?
I have a kryoflux preservation stream but so far can make no sense of it.
I've successfully decoded Intel M2FM disks. The track-level format
isn't the same as the HP 9895A, but the channel code is. I'd be happy
to take a look at a 9895A image. 
21 Sep
21 Sep
10:19 a.m.
On 9/20/16 11:59 PM, Christian Corti wrote:
Here's a rough sketchup of what my decoder does:
- Find the sync pattern (several 0x55)
- Swap the bits in each byte (i.e. MSB<-->LSB)
- Look for an address mark (clock pattern always 0x0E)
- 0x70: ID address mark
Calculate CRC16 (initial value 0xFFFF) over four bytes
- 0x50: data address mark
- 0xF0: defective track address mark
- 0xD0: ECC data address mark
- The ID address mark contains the following information:
0: cylinder
1: head in bit 7, sector in bits 5..0
2: CRC byte 1
3: CRC byte 2
I wonder if this is the same format the Amigo used?
10:24 a.m.
[HP9895 format deleted]
I wonder if this is the same format the Amigo used?
Which was the Amigo?
FWIW every 5.25" and 3.5" HP drive unit that I've seen (and the
internal drives on the 9826 and 9836) use a Western Digital or
compatible disk controller chip. The low-level format (sync
bytes, headers, etc) are what you'd expect for such an IC.
-tony
10:35 a.m.
HP300
On 9/21/16 10:24 AM, tony duell wrote:
[HP9895 format deleted]
I wonder if this is the same format the Amigo
used?
Which was the Amigo?
FWIW every 5.25" and 3.5" HP drive unit that I've seen (and the
internal drives on the 9826 and 9836) use a Western Digital or
compatible disk controller chip. The low-level format (sync
bytes, headers, etc) are what you'd expect for such an IC.
-tony
2:37 p.m.
On Wed, Sep 21, 2016 at 11:19 AM, Al Kossow <aek at bitsavers.org> wrote:
I wonder if this is the same format the Amigo used?
The Amigo used the 7902A floppy drive, which supports the same formats
as the 9895A. This includes HP M2FM, single or double-sided, and IBM
3740 FM single-sided single-density.
2:44 p.m.
On Wed, Sep 21, 2016 at 12:59 AM, Christian Corti
<cc at informatik.uni-stuttgart.de> wrote:
I've already written a decoder for the HP
9885/9895 format. Denise already
sent me his image, but I haven't had the time to try decoding it yet...
I'd still like to get a 9885/9895/7902 M2FM flux-transition disk
image, if anyone has one handy that they'd be willing to share.
25 Sep
25 Sep
1:32 a.m.
On Tue, Sep 20, 2016 at 7:42 AM, Denise de Vries
<denise.devries at flinders.edu.au> wrote:
Does anyone know of documentation for the HP9895A
format with its own M2FM encoding?
I have a kryoflux preservation stream but so far can make no sense of it.
On Wed, Sep 21, 2016 at 12:59 AM, Christian Corti
<cc at informatik.uni-stuttgart.de> wrote:
I've already written a decoder for the HP
9885/9895 format. Denise already
sent me his image, but I haven't had the time to try decoding it yet...
Denise sent me the image as well.
dfitoimd has now been renamed to fluxtoimd, as it now supports both
DiscFerret and KryoFlux image input. I've partially added HP M2FM
format; it now correctly decodes the address fields, but I have a bit
more work to do on the data fields. I expect to have it completed
tomorrow.
- 0xD0: ECC data address mark
Any idea how they use that? Aside from that being included in the list
of address marks in the service manuals, it's not described at all.
Since the 7902/9885/9895 don't do ECC, perhaps it was reserved for
future use.
4:48 p.m.
fluxtoimd now successfully decodes HP M2FM double-density floppy
format, as used by the HP 7902, 9885, and 9895, from either DiscFerret
images or ZIP files of KryoFlux stream files.
https://github.com/brouhaha/fluxtoimd
5:25 p.m.
Is it doing better on Intel M2FM now?
On 9/25/16 4:48 PM, Eric Smith wrote:
fluxtoimd now successfully decodes HP M2FM
double-density floppy
format, as used by the HP 7902, 9885, and 9895, from either DiscFerret
images or ZIP files of KryoFlux stream files.
https://github.com/brouhaha/fluxtoimd
5:34 p.m.
On Sun, Sep 25, 2016 at 6:25 PM, Al Kossow <aek at bitsavers.org> wrote:
Is it doing better on Intel M2FM now?
No, but since it had no trouble with the HP M2FM, I'm starting to
think that perhaps my PLL code is OK and the drive used to read those
Intel disks might have been suboptimal.
I need more double-density flux transition disk images to test with.
5:55 p.m.
OK, I'll see what I can do. You left some Intel floppies of them out here, and
I've got some Amigo OS disks that are pretty important to image.
Guess I need to get the Diskferret set up ;-)
On 9/25/16 5:34 PM, Eric Smith wrote:
On Sun, Sep 25, 2016 at 6:25 PM, Al Kossow <aek at
bitsavers.org> wrote:
Is it doing better on Intel M2FM now?
No, but since it had no trouble with the HP M2FM, I'm starting to
think that perhaps my PLL code is OK and the drive used to read those
Intel disks might have been suboptimal.
I need more double-density flux transition disk images to test with.
2790
days inactive
2796
days old
12 comments
5 participants
participants (5)
-
aek＠bitsavers.org -
ard＠p850ug1.demon.co.uk -
cc＠informatik.uni-stuttgart.de -
denise.devries＠flinders.edu.au -
spacewar＠gmail.com