Revision B, C & D Board testing and usage

Top of MFM project information

If you have any questions, improvements, or corrections email me at the address at the bottom of the page or use the forum.

Issue tracker is here.

Forum for discussing this project is here,

I have tested the BeagleBone Green (BBG) and it works fine for the MFM emulator and is slightly cheaper. The green has some functions removed that are not needed for the MFM board. The micro USB cable it comes with is only 7" long. All references in these pages to BeagleBone Black (BBB) also apply to BBG unless otherwise noted. The recent C3 revision of the BeagleBone Black along with the New OS image fix the Ethernet issue.

** Changes to instructions **

I haven't had time to update all these pages for the new OS image so here are summary of changes you need to know about. The new images were released end of September.

For the OS 11 image you now need to log in as debian, password temppwd. Use sudo for commands that need root or sudo su - to get a root shell. For OS 7.11 login is root with no password. If in doubt which version is running try root no password first.

For v4.00 or later the executables are in debian's path for OS 11 or root's path for 7.11. You don't need to cd to the executable and you don't need ./ in front of the command. The setup* scripts and emulator executables don't need root on OS 11. The MFM code is in /opt/mfm. For OS 11 you don't need to reboot if switching emulator mode (read/write/emulator).

For current images you can just do

mfm_read [rest of command line]

mfm_emu [rest of command line]

If when running mfm_emu you get error

**Write and step are active, is J2 cable reversed?**
make sure you ran setup_emu. If you don't you will get that error.

File Information

The board was created using the KiCad software suite. See License file for license of this board and license information and attribution for included files.

The directory pdf has the board schematic (top.pdf) for the actual PCB layout.

The directory info has a spreadsheet of the BeagleBone Black (BBB) pins used, and the board license.

The directory bom has the bill of materials for building the board. See page linked to under Assembly Notes if building a board.

The directory datasheets has datasheets for the chips used.

Mechanical Information

The board is laid out such that it matches the normal drive connector locations and orientation when installed with the component side up. The BBB plugs into the bottom solder side of the board. The assembled height should allow installation in a half height 5.25" drive bay.

The mounting holes in the board match the standard 5.25" drive bottom mounting holes. If the drive being emulated was mounted with screws into the bottom of the drive the board can be mounted using standoffs. The board is shorter than a normal drive so the connectors will be further back.

For drives that mounted using screws into the side, mounting blocks for the board will need to be made. Space has been left along the side of the board to allow the board to be screwed to the blocks using #6 screws and then screwed to mounting rails or the drive cage as needed. This is a partially assembled example of the original revision A board with a mounting rail:

Richard Muse created 3D printable mounts for his boards. See his post to the discussion list with picture here
He created a new version that works with the upright capacitors on the bottom. Picture of new mount and STL file

Assembly Notes

See this page if you are assembling the PCB or for some notes on the board design.

You may wish to remove or move P9 caps jumper to drain until you are ready to install the board in a computer to use for MFM emulation. This way the board won't have any voltages on it after you remove power.

Software Install and Update. Also how to access board

See this page for installing and updating the software. Also how to access the board. If you bought an assembled board from me it was shipped with the latest software installed.

Board Testing with BBB

Login to the BeagleBone is root with no password.

MFM board testing Power functions

If you bought a pre-assembled board this testing has already been performed. It may be worth running the powerfail command below to test the input 12V power.

Power up board. With the MFM board installed the power must be supplied from the MFM board power connector J5. If U12 isn't installed skip these tests. Ssh into the BBB.

If you installed the holdup capacitors first try the powerfail command.

cd ~/powerfail
./powerfail --debug --powercmd true --threshold 0
It should print after several seconds something like
Average 12.27V max 12.30V min 12.24V
Control-c it after it prints the message. Verify the voltage matches the input voltage and min to max difference is reasonable for your supply ripple. For more information see the command documentation. If the voltage is off the --scale parameter can be used to adjust. Boards I ship assembled should be good to around 1% with the default scale. Also if the voltage is close to or below 11.5V the powerfail auto shutdown will trigger prematurly. Use --threshold option on powerfail to adjust threshold to 0.25 to 0.5V lower than the reported minimum value. See autostart information

To test the auto power on when power available ssh into the BBB and enter the command:

poweroff -f
The board should power down then immediately power back on. This function is to ensure the BB does not get stuck in a powered off state if you turn off for a short time the computer you have it installed in as an emulator using the capacitors and powerfail shutdown.

If you really wish to power off the board you need to remove the 12V either before or during the poweroff. I use halt -f then remove the 12V when I'm shutting down the board. This halts but doesn't power off the board. Someone decided to be "helpful" and do poweroff when you use the halt command unless you specify -f. The -f prevents running the shutdown scripts.

If you don't want this behavior you can either put a short across R27 or short U17 pin 2 or 3 to ground. You could glue down jumper pins or a little switch if you want it selectable.

MFM board testing disk reading

The write jumper P1 should be removed before reading a disk to ensure that it can't be written to. I have seen corruption of disk contents when connected to a drive with jumper installed and hot plugging cables and power cycling beaglbone. I haven't seen it when the jumper is removed. Powering the drive up after the beaglebone is booted and setup_mfm run is advisable.

To test disk reading attach cables from J3 and J4 to a drive Ensure the cables are attached in the proper orientation. Data can be erased if they are plugged in backward. Note that PC hard and floppy cables look similar but are not interchangeable. Verify the drive has a terminating resistor installed. Power up the board and drive. Note that setup_mfm_read only needs to be done once per boot. It will give errors if you run it twice or after setup_emu is run. If you set up automatic starting of the emulator at boot you will need to turn that off. For now you need to reboot the board to switch between reading disks and emulating. Mfm_read may take a minute or two to detect the format without visible progress indication so don't give up.

cd ~/mfm
./mfm_read  --analyze --emulation_file ../emufile_a --extracted_data_file filename
./mfm_read --emulation_file ../emufile_a --cylinders # --heads # --drive #
If you specify the extracted_data_file the program will retry on read error and report uncorrectable errors. This way you get the best emulation file and know where the errors are. If analyze doesn't understand your drive format use the second command where you will need to specify the number of cylinders, heads, and which drive select your drive is on. For reading important drives you should also use --transitions_file filename to archive the drive since it retains the most information if further work is needed and it least likely to be corrupted by software errors. You may also wish to use the script command to capture the messages from reading the disk and store it with the image so you know what errors the drive had.

If you use --analyze verify that the number of cylinders and heads found match your drive specifications. If they don't and retries weren't needed to recover marginal sectors use the second form of the command to read the entire disk. Otherwise you can use the parameters mfm_read prints out adjusted for your drive to manually read the entire disk. You can use mfm_util to see what errors are in the file read. Sometimes the mismatch is due to the system not using all the cylinders or heads. Others are due to how the controller formats the tracks and limitations in my decoding software. You can contact me if you need help understanding why the mismatch.

If you get "Unable to find drive. If just powered on retry in 30 seconds" it didn't see the drive selected signal come back when it raised any of the drive select lines. If your drive had a light did it come on? If you have test equipment test J4 pin 26, 28, 30, and 32 are being driven low and see if the drive responds by pulling J3 pin 1 low.

If analyze doesn't find the format see adding new formats.

I have found with some drives that if you are getting read errors reorienting the drive may get rid of them. I normally start with lying flat then try on the sides. Probably best to start with the orientation the drive was originally used.

I have found that with Seagate ST-251 drives if I am getting read errors that if I push on the shaft of the head stepper motor during the retries most of the time it will get a good read. This may work with other drives with external stepper motors. I first do a read without touching anything in case it damages the drive. Then I increase the retries and position the drive so I can touch the shaft. When I hear it retrying I put a little pressure on the shaft and hopefully it will say all sectors recovered. If I press too hard I get seek errors. The program will recover from seek errors. Users results with ST-225.

If getting error free read took multiple retries its possible the emulator file will have errors since the way it puts together the sectors from multiple reads doesn't always work. Use mfm_util to check the emulator file to see if it has more sectors with errors than the original read. If this is an issue I may be able to adjust some parameters to help.

For more information see the command documentation.

MFM board testing disk emulation

Remove cables for reading a drive before trying to emulate a drive. Set P9 jumper as desired for caps used or disabled.

To test disk emulation attach cables from controller to J1 and J2. Set the P7 jumper to the drive number you wish to emulate. Leave P8 open. RN1 should be installed unless you are trying to use it with another drive that is terminated at the end of the cable. Make sure RN1 is installed with the dot on the resistor at the pin 1 of the socket marked with dot and square pad. Power up board and run the following if you previously read the drive you wish to emulate. Note that setup_emu only needs to be run once per boot.

cd ~/emu
./mfm_emu  --drive 1 --file ../emufile_a
Then try to boot the computer attached to the drive emulator or access the emulated disk drive. The mfm emulator should print messages like shown in the documentation and the computer should act like it has the disk attached.

If you didn't read a disk to emulate you will need to start with an unformatted drive:

cd ~/emu
./mfm_emu  --drive 1 --file ../emufile_a --initialize --cylinders # --heads #
Replace # with the proper numbers for the drive you wish to emulate (you don't need number of sectors). Then run the low level format command on the computer attached to the drive emulator. The mfm emulator should print messages like shown in the documentation and the format should complete without errors.

If you wish to try emulating two drives connect J6 to your controller and use --drive 1,2 --file file1,file2 on the command line and set P8 to the drive select you want the second drive to be detected as. This will only work if the system uses the same control cable for both drives being emulated. The Bill of materials at the bottom has possible cables for J6 if you don't have a suitable female-female 20 pin cable.

For more information see the command documentation.

Note: mfm_emu has a number of internal consistency checks where if they fail the program will dump its state and exit. This is a large amount of hex data. If you see this send me the logfile.txt from the directory you start the program from.

Board Usage

See the usage information in Board Testing.

J7 is for connecting operator controls or status displays. Currently only drive selected LED's are supported. Any I/O must be 3.3V to prevent damage.

The emulator software will drive pin 16 low when the first drive emulated is selected and pin 10 low when the second drive is selected. The LED anode (+) should be connected through a resistor to pin 1 (3.3V). Since only one LED is on at a time both LED's can share the same resistor. The BBB outputs are rated for 6 mA current. The resistors values should be (3.3V - LED Vf) / .006. For Vf (LED forward voltage) of 1.6V that gives 300 ohms rounded up to 5% value or 287 for 1%. Other usage of this connector is expected to be developed by the user community. See BBB_Pins for what functions the BBB supports for the expansion connector pins. See the bottom of the BOM for possible mates to J7 for making LED cable.

Starting Emulation on Power On

This also enables the automatic clean shutdown when power is lost. You should install P9 jumper for rev B or move P9 caps jumper to fill for rev C boards to allow clean shutdown. The red LED on the board will come on if the capacitors have charge.

Using my prebuilt image the default when enabled is to emulate a single drive from /root/emufile_a for old OS or /home/debian/emufile_a for new OS. The emulation file will not be backed up on boot. If you want to start the emulator at boot with these options execute the following command

systemctl enable mfm_emu.service

If you wish to change the options edit /etc/mfm_emu.conf. The file has comments describing what the configuration variables do. For example if you wish to emulate two drives set EmuFN2 to the second file name. If your emulated drive has information you wish not to lose you may wish to enable backup. Set the Backup variable to the type of backup. Copy just copies the emulator file. rdiff and xdelta do a binary difference between the files to take less space. If you do something that changes most of the image file such as defragment the binary difference may take long enough for your computer to timeout. The straight copy is quicker but for small changes will take much more space. I didn't find a clear winner between rdiff and xdelta.

It seems to take about 12 seconds from power on until the mfm emulator is running if no backup is performed.

To stop automatic starting of the emulator

systemctl disable mfm_emu.service

If you see the board continually reboot after enabling auto start its likely the powerfail process is seeing voltage below 11.5V. Check your input 12V. If its low you may need to edit /etc/mfm_emu.conf and change PowerFailOptions line to specify the threshold to shut down at such as 11.3. Also check the voltage being measure is correct, see MFM board testing Power functions

PowerFailOptions="--threshold 11.3"

Manual Backing up emulator file
If you copy the emufile_a while the emulator is running the last write may not have been written back to the file. To ensure the write is done stop and start the emulator.

systemctl stop mfm_emu
cp emufile_a newfile
systemctl start mfm_emu


If the emulator fails to start see /var/log/syslog, /var/log/daemon.log and /root/emu/logfile.txt. For autostarted emulator on new image its /opt/mfm/emu/logfile.txt. If they don't show anything useful try changing StandardOutput=null to StandardOutput=journal+console in /etc/systemd/system/mfm_emu.service then execute:
systemctl --system daemon-reload
systemctl restart mfm_emu.service
You can then see the output with
journalctl -u mfm_emu
grep mfm_emu /var/log/syslog

If you want to see the last couple lines of output you need to stop the emulator.
systemctl stop mfm_emu
To see output of mfm_emu started by systemd in real time change /etc/mfm_emu.conf NoLineBuffer to yes, restart as above, then run:
reptyr -s `ps -C mfm_emu -o pid=`
Without setting NoLineBuffer the output will be delayed by output buffering.

Working with disk images

I wrote up how to work with DOS disk images hear. Some of the information is useful for other disk formats also. Tools to work with the disk images are outside the scope of my software. I support converting to/from disk images as long as all the information in contained in the sector headers for mapping spare sectors/tracks. If the controller or operating system has hidden tables for remapping sectors that the image tools don't know about you may get some corrupted files. Not all disk formats are supported by ext2emu. Additional formats can be added. Spare sector handling may also not be correct if disk sample I made format from didn't obviously use spare sectors.

Editing Files

I used vi for editing files. If you haven't used vi there are manuals online. Here is one.

You may use any editor. The nano editor may be easier to use if you are not familiar with vi.

You can also copy off the file to another system to edit and copy back. You may need an editor under windows that can handle Unix line ending conventions.


I have used old RTL8192/8188CUS wireless N adapters with my Debian image. Wireless had pretty poor performance for me unless close to access point. The new 11.8 image will support newer adapters though not all will work. Ones that people have reported working with Debian Bullseye without having to install additional drivers are more likely to work. Also remember that my image has no root password etc so need to decide what security you need.

Plug the adapter into the USB port

See what wlan is listed and change below to match.

Assuming your using DHCP edit /etc/network/interfaces and add

# wireless network interface
allow-hotplug wlan0
auto wlan0
iface wlan0 inet dhcp
   wpa-ssid "thessidofyournetwork"
   wpa-psk  "yourpersonalpassphrase"
For static address
# wireless network interface
allow-hotplug wlan0
auto wlan0
iface wlan0 inet static
   wpa-ssid "thessidofyournetwork"
   wpa-psk  "yourpersonalpassphrase"

ifup wlan0
See if interface comes up ok. Should autostart on boot. If you get ssid or password wrong it will fail to set up the interface but won't have clear messages why. iwconfig will say not-associated.

Feel free to contact me, David Gesswein with any questions, comments on the web site, or if you have related equipment, documentation, software etc. you are willing to part with.  I am interested in anything PDP-8 related, computers, peripherals used with them, DEC or third party, or documentation. 

PDP-8 Home Page   PDP-8 Site Map   PDP-8 Site Search