Copying a file under DOS sometimes hangs with the drive selected light on and no error from the computer or the emulator.

Using two emulators with one emulating two drives and a third emulating a single drive the images get corrupted on a Convergent Mightyframe.

Most of the logic needed exists in mfm_read and mfm_emu except for write precompensation.

With a NorthStar Advantage computer if an existing drive is read to create the file for the emulator the computer can't read the emulated drive. It works if it formats a blank emulated drive.

The front end processor can read multiple disks OK but the Lisp processor gives error
Error: %DISK-ERROR-STATE-MACHINE during a %DCW-UNIT on unit 1, cyl 0, surf 2" (or surf 3 or 4, depending.)

So far have not been able to determine what the cause of the error is.

Another unknown format from a Soviet clone on i82062. Please look at it.
https://drive.google.com/file/d/1WJT82QEQqF51DuPAK70SqBv_9C8g7whl/view?usp=drive_link

Photo of the computer here: https://retro-computer.ru/home.aspx#/item/INFORT

Russian Elektronika is DECpro 350 clone. Need another image file to finish adding new format.

Hello!
This is a great project for people restoring retro computers!
Please see the dump of these two disks.
https://www.dropbox.com/s/owzeldjjjggu9n8/cm1810-demos-raw-2.7z?dl=0
https://www.dropbox.com/s/pomwxtfhb5ut621/CM1810-Demos1-raw-1.7z?dl=0
They are from the soviet clone Intel SBC 86/12 with a copy of the MFM controller iSBC 214.
These dumps should contain OS DEMOS, a clone of Unix. Disks is Seagate ST-225

Have image file. Another machine not following any standard for its disk format. Need more staring at schematics to figure out what its doing.

Every time I attempt to run mfm_emu, I see the message "Unable to open pin 30." I am merely trying to initialize a blank image. At first, I thought this might be because the BBB hadn't been connected to the board yet. After connecting and powering everything up (via a PC power supply), I still received the message. Finally, connecting to an actual MFM controller and attempting this causes the same message. As of right now, I can't use the board or software at all.

Am I missing something? Just looking for some assistance.

Sometimes when the board boots the Ethernet lights go out and don't come back on so the Ethernet port is not functional. If you hit the power button to turn off and back on normally it will work the next boot. I was able to reproduce with a board not attached to my emulator so think it is related to OS image running. I have a report that not having the emulator connected to the host system reduces the occurrence. Wasn't able to get DMA working with newer OS image so upgrading image is waiting for more time.

Sometimes it seeks in the opposite direction from requested. If DIR_SETTLE_TIME is set to couple
hundered milliseconds it works. On logic analyzer seek complete drops after 200 ms when
drive selected for no good reason. Also messes up analyze with
Drive prematurely at track 0 after 2 of 1 steps testing fast ST412 seek
Drive prematurely at track 0 after 2 of 1 steps testing slow ST506 seek
Due to first seek in wrong direction

Extracted EMU file works perfectly with the real machine. Analyzing the EMU file, notice it has 18 sectors per track:

root@beaglebone:~/ki3v/mfm/mfm# ./mfm_util --analyze -m ~/plexus-sanitized.emu
Original decode arguments: --format OMTI_5510 --sectors 18,0 --heads 11 --cylinders 754 --header_crc 0x2605fb9c,0x104c981,32,6 --data_crc  0xd4d7ca20,0x104c981,32,6 --sector_length 512 --retries 90,6 --drive 1
Matches count 36 for controller OMTI_5510
Header CRC: Polynomial 0x104c981 length 32 initial value 0x2605fb9c
Sector length 512
Data CRC: Polynomial 0x104c981 length 32 initial value 0xd4d7ca20
Number of heads 11 number of sectors 18 first sector 0
Interleave (not checked): 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Command line to read disk:
--format OMTI_5510 --sectors 18,0 --heads 11 --cylinders 754 --header_crc 0x2605fb9c,0x104c981,32,6 --data_crc  0xd4d7ca20,0x104c981,32,6 --sector_length 512 --retries 90,6 --drive 1

As I test, I tried to turn the extracted image back into an EMU, but it does not work and creates a non working EMU file:

root@beaglebone:~/ki3v/mfm/mfm# ./ext2emu -m ~/plexus-reanimated.emu --format OMTI_5510 --heads 11 --cylinders 754 -e ~/plexus-sanitized.img
Calculated extract file size 72190976 bytes, actual size 76437504
At cyl 750

Analysis of the newly created EMU file:

./mfm_util --analyze -m ~/plexus-reanimated.emu
Original decode arguments: --format OMTI_5510 --sectors 17,0 --heads 11 --cylinders 754 --header_crc 0x2605fb9c,0x104c981,32,6 --data_crc  0xd4d7ca20,0x104c981,32,6 --sector_length 512 --track_words 5209
Found matching format OMTI_5510: good count difference 0
Number of heads 11 number of sectors 17 first sector 0
Interleave (not checked): 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Command line to read disk:
--format OMTI_5510 --sectors 17,0 --heads 11 --cylinders 754 --header_crc 0x2605fb9c,0x104c981,32,6 --data_crc  0xd4d7ca20,0x104c981,32,6 --sector_length 512 --retries 50,4 --drive 0 --track_words 5209

Notice it has 17 sectors per track. Analyzing the source code, the value of 17 is hardcoded. We tried altering the source code in a few spots that looked relevant, but it resulted in a broken conversion process.

David Greetings! I'm already becoming your regular guest! I've had the NEC D5124 disc for two years now. He did not want to blink his heads, I tried to repair him, changed transistor keys, head controls ... facepalm =(
But today I was able to read it, but the format is not known.
The disk was connected to the controller: WD1002-HDO (Like Kaypro-10) https://retrocmp.de/kaypro/kay-p2_hrdw.htm#hdc
But this controller was in a very, rare Labtam 3000 computer, and the program in the controller's rom may have been changed.
Please have a look at it:

./mfm_read -a
Board revision B detected
Found drive at select 1
Returning to track 0
Drive RPM 3595.0
0, 0
1, 0
2, 0
3, 0
4, 0
5, 0
6, 0
7, 0
8, 0
9, 0
10, 0
11, 0
12, 0
13, 0
14, 0
15, 0
16, 0
17, 0
18, 0
19, 0
20, 0
21, 0
22, 0
23, 0
24, 0
25, 0
26, 0
27, 0
28, 0
29, 5
30, 3
31, 6
32, 6
33, 2
34, 2
35, 2
36, 2
37, 4
38, 16
39, 1053
40, 15990
41, 25364
42, 26284
43, 10595
44, 714
45, 10
46, 4
47, 4
48, 1
49, 1
50, 3
51, 3
52, 1
53, 2
54, 3
55, 2
56, 1
57, 2
58, 4
59, 2
60, 3
61, 0
62, 2
63, 2
64, 2
65, 0
66, 1
67, 2
68, 0
69, 3
70, 2
71, 5
72, 1
73, 1
74, 1
75, 0
76, 0
77, 4
78, 3
79, 0
80, 1
81, 4
82, 5
83, 2
84, 2
85, 2
86, 3
87, 2
88, 0
89, 0
90, 4
91, 1
92, 4
93, 1
94, 0
95, 2
96, 2
97, 2
98, 1
99, 2
No more peaks in histogram
0, 0
1, 0
2, 0
3, 0
4, 0
5, 0
6, 0
7, 0
8, 0
9, 0
10, 0
11, 0
12, 0
13, 0
14, 0
15, 0
16, 0
17, 0
18, 0
19, 0
20, 0
21, 0
22, 0
23, 0
24, 0
25, 0
26, 0
27, 0
28, 1
29, 3
30, 4
31, 3
32, 6
33, 3
34, 3
35, 3
36, 1
37, 3
38, 23
39, 1187
40, 16593
41, 24404
42, 25849
43, 11184
44, 767
45, 12
46, 1
47, 3
48, 2
49, 3
50, 6
51, 3
52, 1
53, 6
54, 1
55, 3
56, 4
57, 3
58, 1
59, 2
60, 2
61, 1
62, 1
63, 2
64, 3
65, 3
66, 0
67, 3
68, 0
69, 0
70, 3
71, 2
72, 2
73, 4
74, 2
75, 2
76, 1
77, 4
78, 2
79, 2
80, 3
81, 2
82, 0
83, 2
84, 0
85, 2
86, 1
87, 4
88, 0
89, 2
90, 1
91, 2
92, 0
93, 0
94, 0
95, 0
96, 1
97, 1
98, 1
99, 0
No more peaks in histogram

David, please look at this image. the controller is based on the Intel 82062 chip.

Issue

I'm unable to use setup_mfm_read or setup_emu successfully. Here's the error I'm seeing:

sudo ./setup_mfm_read 
./setup_mfm_read: line 4: echo: write error: Invalid argument
Rev B Board

To help debug things, I tried running the commands at the start of the script by hand. Here's what I'm seeing when I try to run the script steps from setup_mfm_read manually:

1. running sudo dtc -O dtb -o mfm_read-00A0.dtbo -b 0 -@ mfm_read-00A0.dts succeeds.

2. running sudo cp mfm_read-00A0.dtbo /lib/firmware succeeds.

3. running echo mfm_read:00A0 | sudo tee /sys/devices/bone_capemgr.*/slots FAILS with the following message:

   tee: /sys/devices/bone_capemgr.9/slots: Invalid argument
   

Note that I get the same error if I try to manually run the steps from setup_emu.

Examining dmesg shows the following messages:

[   93.928254] bone-capemgr bone_capemgr.9: part_number 'mfm_read', version '00A0'
[   93.928434] bone-capemgr bone_capemgr.9: slot #6: generic override
[   93.928480] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 6
[   93.928876] bone-capemgr bone_capemgr.9: slot #6: 'Override Board Name,00A0,Override Manuf,mfm_read'
[   93.931450] bone-capemgr bone_capemgr.9: slot #6: Requesting part number/version based 'mfm_read-00A0.dtbo
[   93.931514] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 'mfm_read-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[   93.935219] bone-capemgr bone_capemgr.9: slot #6: dtbo 'mfm_read-00A0.dtbo' loaded; converting to live tree
[   93.935678] bone-capemgr bone_capemgr.9: slot #6: Incompatible with baseboard for 'mfm_read'
[   93.944715] bone-capemgr bone_capemgr.9: slot #6: Failed verification

After this failure, I'm not able to use mfm_read. The error I get is:

sudo ./mfm_read --emulation_file ~/st251.img --cylinders 820 --heads 6 --drive 0
Board revision B detected
prussdrv_open open 0 failed

Environment

The host is a BeagleBone Green manufactured 10/31/15. MFM emulator is a Rev B., which I assembled myself. No EEPROM is installed.

If begin_time is not set correctly so a sector straddles the end to beginning of the track capture the jitter of index pulse relative to the data will cause bit errors. For archiving unknown format drives if some extra data is read it should be possible to then find the overlap and extract the proper bits. Reading enough to not have to try to piece the data back together makes processing easier but some formats have one sector per track so not always possible.

David, please look at this image. the controller is based on the Intel 82062 chip.
https://mega.nz/file/WgAUGLRC#ru14Sf-jWIq9ufd3AsNQrC2gVIrK3enmnM34g1RwkhE

For some controllers the sector headers indicate that a track has been assigned an alternate. For formats that know how assignments are done the sparing information is printed but alternate track is not written to the correct location in the extract file. The information provided can be used to manually fix the file. Other controllers store that information in data tables stored on the disk. Handling those data tables is not planned.