Revision B 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 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.

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.

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

Assembly Notes

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

I ship with a cardboard spacer under the big capacitors. Remove it before using the board. It prevents the leads under the capacitors from poking through the insulation if the box gets squished during shipping.

You may wish to remove P9 caps jumper 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.

Reflashing BBB

If you got a prebuilt board with BBB you can skip this step since the latest software at time of shipping was installed. You can check your software against the website version to see when updated or subscribe to the forum announcements.

You may wish to follow the Getting started instructions to first power up and log into the BBB without attaching it to the MFM board to verify you know how to access it before changing its configuration.

The easiest way to get stuff setup is to copy This prebuilt image BBB-mfm-emu_v1.17.img.xz (last modified Sunday, 21-May-2017 20:36:43 EDT ) to a micro SD card and flash your BBB from windows. From Linux use xzcat imagefile.xz | dd of=/dev/sdx where sdx is the device your microSD card was detected at. May also be detected as mmcblkx. Make sure you get the device right or you may wipe out your hard disk.

Note that is it is not securely configured so don't use it if it will be accessible from untrusted machine or the Internet. I think my image will work on all BBB revisions. This image is based on the console version so most of the flash storage is free but doesn't have graphical tools installed. If you wish to do it manually see software installation

Install the microSD card in the BBB and power it on. The lights should switch to one LED on running back and forth after a minute if programming is working. If it doesn't power off the board and power it on while holding down the boot button. The LEDs go out when flashing is done. Wait 10 seconds after lights go out to ensure it's done and then remove the microSD card and then reset the BBB.

I'm not planning to update the image with each software release so you likely will need to update the software.

MFM software installation/update

You can check your current version with ./mfm_util --version in the mfm directory. If later download latest mfm code .tgz file and copy it to BBB and build. I had some requests so the code is also on github at https://github.com/dgesswein/mfm

It is probably easiest to connect the USB cable for installing the software. I use the Ethernet which needs a DHCP server on your network. It allows access to the Internet the way my network is configured. If the Ethernet cable isn't plugged in at boot it may take 20 seconds for the board to activate the Ethernet after the cable is plugged in.

It is also possible to access the board using the USB serial port and move files using a USB stick. The USB stick doesn't automount with my image. Use mount /dev/sda /mnt or mount /dev/sda1 /mnt.

Note that after the MFM daughter card is installed the board will not power up from the USB port. You will need to power the board through the drive power connector. Don't use the barrel jack when the MFM board is installed if the DC/DC converter U12 is also installed on the MFM board.

If you are using windows you will need a scp and ssh program. I use putty and pscp from here. Login to the BBB is root with no password. ipaddr in the commands below is the IP address of the BBB. The USB IP address is 192.168.7.2. Delete (rm) all except the latest file for the * in the following commands to work.

#if your BeagleBone has Internet access you can download on BBB using wget
#otherwise from machine you downloaded image to
scp mfm_emu_powerfail*.tgz root@ipaddr:
#On BBB
tar -xzf mfm_emu_powerfail_*.tgz
cd mfm
make
cd ../emu
make
cd ../powerfail
make
exit (or poweroff)

Board Testing with BBB

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.

echo cape-bone-iio > /sys/devices/bone_capemgr.*/slots
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.



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.

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 triggers a bug where you will get some error messages that don't seem to affect anything. -f also prevents running the shutdown scripts.

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. 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. For now you need to reboot the board to switch between reading disks and emulating. If you get the error permission denied verify user has permission (I just use root) and the execute bit is set (chmod +x setup_mfm_read). mfm_read may take a minute to detect the format without visible progress indication so don't give up.

cd ~/mfm
./setup_mfm_read
./mfm_read  --analyze --emulation_file ../emu_file --extracted_data_file filename
   or
./mfm_read --emulation_file ../emu_file --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 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.

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.

For more information see the command documentation.

MFM board testing disk emulation

Remove cables for reading a drive before trying to emulate a drive.

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
./setup_emu
./mfm_emu  --drive 1 --file ../emu_file
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 ../emu_file --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. This will only work if the system uses the same control cable for both drives being emulated.

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 2V that gives 220 ohms rounded to nearest 5% value or 215 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.

Starting Emulation on Power On

Using my prebuilt image the default when enabled is to emulate a single drive from /root/emufile_a. 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.

Debugging

If the emulator fails to start see /var/log/syslog, /var/log/daemon.log and /root/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
To see output of mfm_emu started by systemd 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.

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.



Feel free to contact me, David Gesswein djg@pdp8online.com 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

Mirror site if this site is slow highgate.comm.sfu.ca