Trying (and failing) to low level format a track

[David Waine]

Hi

I am trying to use my Emulator/Reader to emulate a very old HD, model CM5412.  My HD controller is a MVME320-1 which is also quite old.  The controller has a published API and more importantly a way of exercising many of the functions through a simple user interface.

I think I have everything connected and configured correctly because I can move the heads reliably and using a 'scope, I can see good looking waveforms on the head signals ("good looking" to my eye anyway).

I'm not going to get any further unless I can do a low level format of the emulator using the controller.  This will enable me to progress to actually reading/writing user data which is obviously my ultimate goal.

When I attempt a low level format, I have to do quite a lot of preparation including setting up an area in memory which holds a track/head/sector map (it is this map that defines the interleave and sector size).  I think I'm doing this correctly, but when I try to do a read of the freshly formatted area, it fails.  Looking at a hex dump of the emulator's formatted track, I can see that something has happened, but because I don't understand the layout of the file used by the emulator to store the HD image, I can't really diagnose the issue any further.

In broad terms, by comparing a before and after dump of the emulator data file, I can see that the whole of track 0, head 0 seems to be written but only the first three sectors seem to have a meaningful configuration.

This could be because my track/head/sector maps is wildly mis-formed or even that it's not being read at all by the controller firmware that does a format. 

I'm reaching out to see if anyone can look at the before/after dump and make a comment about what might be going wrong.  I have to zip them up, but there's two files in there, with self-explanatory file names.

Thanks for your attention.

[David Gesswein]

> Hi

>
> I'm not going to get any further unless I can do a low level format of the
> emulator using the controller. This will enable me to progress to actually
> reading/writing user data which is obviously my ultimate goal.
>

Its possible that you could use ext2emu to create a formatted image.
~/corvus/mfm/ext2emu --ext /dev/zero --emu emufile --heads 4 --cyl 306 --format mvme320
This may not work since what you formatted has a different header byte
This is side effect of using /dev/zero for data
Calculated extract file size 10027008 bytes, actual size 0

You could see if you can read above. If you are reading single sectors any
can't read sector 32 but can others its the sector numbering. Also different
byte 6 could cause problems. Both can be changed in mfm/inc/mfm_decoder.h

Sector numbering is changing 32, 1 to 32, 0
{"MVME320", 256, 10000000, 0,
4, ARRAYSIZE(mfm_all_poly), 4, ARRAYSIZE(mfm_all_poly),
0, ARRAYSIZE(mfm_all_init), CINFO_CHS,
7, 2, 0, 0, CHECK_CRC, CHECK_CRC,
0, 1, trk_mvme320, 256, 32, 1, 5209,
0, 0,
{0xffff,0x1021,16,0},{0xffffffff,0x10210191,32,6}, CONT_ANALYZE,
0, 0, 0, 0
},
To change the header field to 0 change after DEF_EXTERN TRK_L trk_mvme320[]
{1, FIELD_FILL, 0x01, OP_SET, 6, NULL},
to
{1, FIELD_FILL, 0x00, OP_SET, 6, NULL},

Then make

> When I attempt a low level format, I have to do quite a lot of preparation
> including setting up an area in memory which holds a track/head/sector map
> (it is this map that defines the interleave and sector size). I think I'm
> doing this correctly, but when I try to do a read of the freshly formatted
> area, it fails.

Are you trying to read all sectors or just one. Looks like you only formatted
sectors 0-2. Would be good to see if those sectors are readble.

> Looking at a hex dump of the emulator's formatted track, I
> can see that something has happened, but because I don't understand the
> layout of the file used by the emulator to store the HD image, I can't
> really diagnose the issue any further.
>

You can see the general layout if you look at the emulator file routines
in emu_tran_file.c. I haven't documented otherwise. Since it is still
MFM encoded not a easy format to look at.

You can use mfm_util to decode it.
mfm_util --format MVME320 --emu test-After\ format --ext /tmp/out --data_crc 0xffffffff,0x10210191,32,6 --header_crc 0xffff,0x1021,16,0 --sector_length 256 --sectors 32,0

If you want hex dump of the data add --quiet 0

Looking at the entry in my code for MVME320 it has sectors numbered starting
at 1. You have them numbered starting at zero. Another header byte is different
so could be different versions of MVME320. I think format was from B version.

Header Byte 6 not 1, byte 00 on cyl 0 head 0 sector 0

> In broad terms, by comparing a before and after dump of the emulator data
> file, I can see that the whole of track 0, head 0 seems to be written but
> only the first three sectors seem to have a meaningful configuration.
>

Correct.

[David Waine]

Good morning David,

Thanks for your prompt and content-rich reply.  It's going to take me a while to digest and act on your suggestions so I thought I would just send a quick thanks and acknowledge receipt.