Write image with MFM Reader/Emulator to a second Harddiskdrive

[Fritz Chwolka]

Hi,

I got a call for help from a ICL owner who pleased me to write a image from an old ICL PC Quattro computer  running CP/M86 or CCP/M to another harddisk of the same type. As I didn't this before I like to know if this is possible. I read about in the documents that this is in experimental state. Are there some hints for me? For interest about ICL look here, floppyimages here.

[David Gesswein]

> <http://www.vintage-icl-computers.com/>, floppyimages here
> <http://oldcomputers.dyndns.org/public/pub/rechner/ICL/>.
>
If you have an emulator image you are wanting to write to another drive
it is likely to work. A recent release fixed picking up the drive
geometry from the emulator file. The pre compensation and drive to
write to are still hard coded in the source and will need to be set
for your drive.
drive_params.write_precomp_cyl = 512;
drive_params.early_precomp_ns = 10;
drive_params.late_precomp_ns = 10;
drive_params.drive = 1;

Looks like that format uses begin_time. I haven't tested that it works. If
it doesn't I can fix it.

Rereading with the emulator will give some indication the write is good though
that won't guaranteed if will work on the real computer. I think you will
be the first person to use this code other than me. You will need to
reboot after writing before a read will work. Also pull the write jumper
before the reboot (and install before trying to write).

If you are needed to create a disk from a extracted data file the format
info would need to be added to inc/mfm_decoder.h

[Fritz Chwolka]

Am Mittwoch, 6. September 2017 13:27:52 UTC+2 schrieb David Gesswein:

...some text deleted

If you are needed to create a disk from a extracted data file the format
info would need to be added to inc/mfm_decoder.h

Thanks for that usefull information.  The running ICL I can use is 70miles away  in the basement of georgs home  who has no emulator. We missed time for a visit the last months but now he have a need for that. I will get some more information about the harddisk. I just will make a try at home with my NCR DM-V and a bootable MSDOS system - or will it be better using a CP/M86 system for comparing to the ICL CPP/M system? The call for help came from Martin Jambor from the  Czech Republic.

[David Gesswein]

On Wed, Sep 06, 2017 at 04:52:24AM -0700, Fritz Chwolka wrote:
>
> > If you are needed to create a disk from a extracted data file the format
> > info would need to be added to inc/mfm_decoder.h
> >
> >
> Thanks for that usefull information. The running ICL I can use is 70miles
> away in the basement of georgs home who has no emulator. We missed time
> for a visit the last months but now he have a need for that. I will get
> some more information about the harddisk. I just will make a try at home
> with my NCR DM-V and a bootable MSDOS system - or will it be better using a
> CP/M86 system for comparing to the ICL CPP/M system? The call for help came
> from Martin Jambor from the Czech Republic.
>

If one of the controllers for the systems you have to test with
use begin_time that would be the better one to test with. The begin_time
setting will print out when you read the disk.

Another issue I didn't previously say is that my code doesn't attempt
to deal with bad sectors on the disk. If the target disk has bad sectors
whatever ends up on them will get errors when read. Any flagging of bad
tracks/sectors on the original disk will still be marked bad though they
are likely good on the target disk.

[Fritz Chwolka]

Am Donnerstag, 7. September 2017 04:04:57 UTC+2 schrieb David Gesswein:

If one of the controllers for the systems you have to test with
use begin_time that would be the better one to test with. The begin_time
setting will print out when you read the disk.

Hi David,

as I'm not a programmer I have some question.

What do you mean with "controllers for the systems you have to test with  use begin_time"

1. "controllers for the system " do you mean the MFM-Emulator hardware (I have several) or the MFM-Controller of the old computer?

2. "begin_time".. with this I have to look into your documents and hope I understand a little bit. Please explain the "begin_time" for a novice like me.

Best Regards

[David Gesswein]

On Sun, Sep 10, 2017 at 03:07:27AM -0700, Fritz Chwolka wrote:
>
> 1. "controllers for the system " do you mean the MFM-Emulator hardware (I
> have several) or the MFM-Controller of the old computer?
>

The controller in the old computer. The only way you would know would be
to read the disk with the MFM emulator or use mfm_util on an emulator file.

> 2. "begin_time".. with this I have to look into your documents and hope I
> understand a little bit. Please explain the "begin_time" for a novice like
> me.
>

Its a command line option.
http://www.pdp8online.com/mfm/code/mfm/mfm_read_util_doc.html

If you read a drive with mfm_read --analyze it will print the value in
option list when it prints "Command line to read disk:"

When reading a disk it reads the transitions from index pulse to index
pulse. If a index pulse occurs in the middle of a sector it then can't
decode it. Begin time shifts the actual start and end of reading by that
time interval so it happens in the fill data between sectors. Index pulse
is a signal that goes active one per revolution of the disk. Most
controllers when formatting the disk wait for the index pulse then
start writing from the first sector. Some controllers seem to be really
slow getting to writing the first sector so the last sector straddles
the index pulse.

The one ICL computer I have information on uses the Xebec S1410 which
needs non zero begin time. Other models may use different controllers which
don't need it.
The system I tried mfm_write with uses 0 begin time so non zero
may never have been tested, I was just saying if one of the two systems
you had to test with used non zero begin time that would be a better
test.

You can also test by making an emulator file that uses begin time, writing
to a drive, and reading it back. Since Xebec isn't currently supported by
ext2emu you can test using northstar format.
Create a file with 16*heads*cylinders. For this example 4 heads and 100 cyl.
Adjust as needed for your drive

dd if=/dev/zero of=/tmp/zeros bs=512c count=6400
ext2emu --emu /tmp/emu --ext /tmp/zeros --cyl 100 --heads 4 --format NorthStar_Advantage

Then use mfm_write to write /tmp/emu to a drive and then use mfm_read to read
it.

You need to look up the drive and see what cylinder is recommended for
write precompensation and edit line in mfm_write.c. Unless you have
more information leave the precom_ns values as is.

Also see http://www.pdp8online.com/mfm/code/mfm/mfm_write_doc.html
for change needed to mfm_read-00A0.dts. Will need to reboot each time
the file is changed. Will need to be changed back to read. Also write
jumper needs to be installed for write and best to remove it for reading.

mfm_write --emu /tmp/emu

mfm_read --ana --ext /tmp/t

Should get something like
Command line to read disk:
--sectors 16,0 --heads 4 --cylinders 100 --header_crc 0x0,0x0,16,0 --data_crc 0x0,0x0,32,0 --format NorthStar_Advantage --sector_length 512 --retries 50,4 --drive 0 --begin_time 230000

And the disk reads with only the number of errors expected from the bad
sectors on the disk.

[Fritz Chwolka]

I gave a MFM Reader / Emulator to Georg (who is mostly a Wang collector) to read and write the ICL harddisk as we didn't find  time  for a meeting.
I post his question as I can't help at the moment.

Georg:

First I read som other harddisks I own.

- A old Seagate ST 506 was mostly read, but there were also a lot of errors. But she has become a roving stag - she is slowly approaching her life.
- Two 10 or 20 MB disks from a Wang 2275 drive do not go at all
- A presumably RLL-formatted disk is also not read of cause
- The disk of an ITT3030, on the other hand, was read completely fault-free - unfortunately it seems to be freshly formatted, there everything is empty. A second will come later ...

- The hd from the ICL PC quattro  was - hurray! - also error-free read.
Looking into the image  there seems to be a problem with the interleave, because the image begins with a fragmented text, the beginning of which then farther back. Since I next want to make a copy of this disk, this may not matter I hope. Otherwise I wonder why the sector is scrambled - I mean is nevertheless the sector number (as well as the track) in the individual sectors coded?
Is there something I can do with unsupported formats to read at least some data? Currently, the analyzer already breaks.

[David Gesswein]

On Fri, Sep 22, 2017 at 06:18:20PM -0700, Fritz Chwolka wrote:

> - A presumably RLL-formatted disk is also not read of cause
>

> - The hd from the ICL PC quattro was - hurray! - also error-free read.

> Looking into the image *there seems to be a problem with the interleave*,

> because the image begins with a fragmented text, the beginning of which
> then farther back.
>

Post the output from the read or mfm_util --ana on a transitions or
emulator file. The EC1841 is the only format I know that does
strange things with the sector mapping.

> Since I next want to make a copy of this disk, this may
> not matter I hope. Otherwise I wonder why the sector is scrambled - I mean
> is nevertheless the sector number (as well as the track) in the individual
> sectors coded?
>

Other than the EC1841 the extracted data file is output in the order
of the sectors numbers in the header, not the physical sector order.
Some systems may do strange things.

> Is there something I can do with unsupported formats to read at least some
> data? Currently, the analyzer already breaks.
>

See "To read an unknown format drive" www.pdp8online.com/mfm/
You can create an emulator file but not an extracted data file.
If your interested I can give you information on how to add new formats.
That requires code changes. You can also upload preferrably a transitions
file though emulator file is useable to
http://www.pdp8online.com/upload/abuploadab.html
Best to compress the file first. I can look at adding support for the format.
Send me an email with what you uploaded and what system & disk controller.
Also if you know if there is any documentation on the disk controller.

[Georg Schäfer]

Hi, this is Georg, I am the one with the ICL Quattro.

Thanks to Fritz and David's great mfm emulator I was able to dump the drive and write the image back onto another hard disk.

The image is obviously mixed up, but another dump of the second disk shows the same schema, so I hope that the disk drive is identical with the original and will work in the real computer. I guess that I can do this test tomorrow.


Here is a dump from the analysis:

Board revision B detected
Found drive at select 1
Returning to track 0
Drive RPM 3601.8
Matches count 34 for controller Xebec_104786
Header CRC: Polynomial 0xa00805 length 32 initial value 0x0
Sector length 512
Data CRC: Polynomial 0xa00805 length 32 initial value 0x0
Selected head 4 found 0, last good head found 3
Read errors trying to determine sector numbering, results may be in error
Number of heads 4 number of sectors 17 first sector 0
Interleave (not checked): 0 3 6 9 12 15 1 4 7 10 13 16 2 5 8 11 14
Drive supports buffered seeks (ST412)

 No sectors readable from cylinder 612
Stopping end of disk search due to two unreadable tracks in a row
Number of cylinders 612, 21.3 MB

Command line to read disk: --sectors 17,0 --heads 4 --cylinders 612 --header_crc 0x0,0xa00805,32,5 --data_crc 0x0,0xa00805,32,5 --format Xebec_104786 --sector_length 512 --retries 50,4 --drive 1 --begin_time 100500

Tomorrow I hope to be able to tell about the final test in the machine.

As for the unreadable drive from my Wang2275: I have created a transition file, if you are interested I can upload it. But it is not urgent for me because I can dump these drives by other means.

The controller is a custom build device, integrated on a huge board containing a microprocessor, ROM, RAM, floppy controller and winchester controller based on a WD2010.
I'm afraid there is no more information available.

Thanks again,
Georg

[Georg Schäfer]

David, your tool is really awesome!!

This morning I set up the ICL computer, plugged in the "new" harddrive with the copy of the image from the original drive - and it bootet and worked without any problems!

It's phantastic! I am surprised how easy and fast this was. It was a matter of three sessions to learn, test, dump, and write. I think reading the documentation is the most time-consuming part - the tool itself works unbelievable fast!

So I like to say thank you for this great tool, and also many thanks to Fritz for sending me one of his items!

[David Gesswein]

On Sat, Sep 23, 2017 at 04:37:23PM -0700, Georg Schäfer wrote:
> As for the unreadable drive from my Wang2275: I have created a transition file, if you are interested I can upload it. But it is not urgent for me because I can dump these drives by other means.
>
> The controller is a custom build device, integrated on a huge board containing a microprocessor, ROM, RAM, floppy controller and winchester controller based on a WD2010.
> I'm afraid there is no more information available.
>

Might as well get a copy. Upload to my site or send me a URL I can download
from.

If its using a standard WD chip it shouldn't be too hard to add support for.
Likely just the header fields have been arranged in yet another pointless
variation.

[David Gesswein]

Glad it worked. I think you are the first user other than me since I wrote
that a yearish ago.

If your computer has some type of surface scan tool like DOS chkdsk it would be
interesting to see how read errors if any you got from rereading the disk you
wrote with my board compare to what the computer sees.

[Georg Schäfer]

I am just uploading the transition file of the Wang drive.
Thank you for your effort.

One more detail: your tool states that the system uses a sector size of 512 byte. That may be right - fact is, that the access from the CPU always uses a sector size of 256 byte. Maybe this gets translated, similiar to the 128 byte logical sectors in CP/M. But maybe your tool is wrong (or ways it my duty to define the sector size?)

[Georg Schäfer]

I had this idea already, but I haven't found something like that yet. It's an Concurrent CP/M, and I have no experience with this system.
But since I have done much reads and program starts without any problem I am rather sure that there is at least no systematical error.
Well done!

Btw, I made a copy onto another drive, but this drive had an error in a single sector - this drive doesn't work, because this sector seems to be used by a part of the system. So writing an image to a drive makes high demands on the quality of the drive.

[Fritz Chwolka]

The CCP/M-86 has a tools for format floppy and harddrives on disc1  called  diskinit.cmd  (http://oldcomputers.dyndns.org/public/pub/rechner/ICL/image/ICL31S-1/). For generating a new system on a hard disc you have to boot from
http://oldcomputers.dyndns.org/public/pub/rechner/ICL/image/ICL31S-1/index.html and then call setup.cmd.
If you have a fixed disc, SETUP ensures that all of the necessary files are installed on it, and helps you to copy from your software issue diskettes, any essential files which are missing. If you have two diskette drives (and no fixed disc) SETUP helps you to make copies of your software issue diskettes. So you can make a new fresh system onto the hard disc with the  bad sector(s), sadly the ICL can only have one internal hard disc but  2 external hard disk drives can be added. (I must look if that can bee more).
 
That the mfm_write  can't test for bad sectors  is written in the documents 

[d...@pdp8online.com]

I have released version 1.20 that now supports the Wang format WANG_2275. The last 3 cylinders are in a different format WANG_2275_B and are all zero. This may space for spare sectors. Drive seems to be error free.  I don't see how a WD2010 can generate the sector header format on the disk (header has 8 bit checksum, data 24 bit CRC). Found some documentation at http://www.wang2200.org/docs.html but not enough to know how it really works. The tool I use to determine the polynomial didn't work for this drive so it took a while to get time to dig into it more.

[Georg Schäfer]

That are really good news, thanks a lot for this update.
I will give it a try the next days.

As for the controller: Maybe this device doesn't actually use a WD2010 - it seems as if this information applies to the successor of the 2275. I just found a hint in the docs that the original 2275 uses a WD1100 - but that's not confirmed yet. I will take a look inside the drive and check it asap.