Hi
I'm reaching out to see if anyone has experience of the Motorola MVME320B disk controller card.
This is quite a long posting, but the bones of it are: I have hooked everything up and to all intents and purposes, the disk controller does not show any sign of life on the HD interface ports no matter what I do. I can see evidence that the disk controller is not dead on the VME bus side.
The detail is as follows;
My hardware set up is a VME rack containing two cards;
- MVME110 processor card with a 68000 running 110Bug V4.1. It's fitted with 32K bytes static RAM
- MVME320B disk controller card with V4.2 firmware. This is the later version of the card which does all the disk I/O through ribbon cables out the front of the rack.
The processor is in the left most slot and the disk controller is directly to the right of that.
I am only trying to connect a hard disk, I've not attempted anything with floppy disks.
I don't have any instructions for 110Bug but reviewing the source, I can see that there are basically two families of disk related commands;
- VersaDos boot through the "B*" commands. These have options on what to do after the boot blocks are loaded
- Low level interaction with the disk controller through the "IO*" commands
I don't have a valid VersaDos image so my investigations only relate to the low level commands.
Actually I don't even have a real hard disk. I'm using one of these;
https://www.pdp8online.com/mfm/mfm.shtmlthis has the advantage that you get some diagnostics while it's running and I can create just about any topology of disk that I want.
The processor card serial port is connected to a Terminal Server like this;
https://amzn.eu/d/3c6rNQYwhich comes in handy as I'll explain in a minute. Basically I can run puTTY across my LAN and at the same time send sequences of keystrokes to the processor using a little program I wrote.
A characteristic of VME cards of this era is JUMPERS! They're everywhere. Also there seems to be a sensitivity to hardware/firmware revision status plus of course, the card(s) might be faulty. Anyway back to jumpers, I used the information here to set the jumpers;
https://bitsavers.computerhistory.org/pdf/motorola/versados/MVMEVDOS_D2_VMEHwSwConf_May85.pdfThis works well for the processor card but unfortunately the disk controller card information relates to an earlier version of the card and the jumper layout has totally changed.
So what I did was write down all the settings for the earlier version of the disk controller in the guide. Then I used the old disk controller user manual here;
http://www.bitsavers.org/pdf/motorola/VME/MVME320/MVME320_D1_Disk_Controller_Users_Manual_Feb85.pdfto figure out what each jumper does and what it's set to.
Then I went to the user manual for the new version of the card which is here;
http://www.bitsavers.org/pdf/motorola/VME/MVME320/MVME320B_D1_Disk_Controller_Users_Manual_Jan88.pdfand using the information from the old card, I made sure that my settings are correct. I was heartened to see that actually there are no changes required from "default" which is good (I think).
There are two problems with this process
- There are many more jumpers on the new card so I just them to "default". I don't think this is a problem because most of the new jumpers relate to Floppy Disk options which I'm not too bothered about.
- In the User Manual for the older card, there is a section on "MVME320 backplane settings". This does not exist in the new card manual. Am I missing something to do with the backplane? Do I need to set something here too? I've assumed that the old manual is referring to the breakout panel, an MVME702 I think it's called. Anyway this mystery table is attached as a photo if you take a look.
So I turn everything on and set my HD emulator running. It starts without error. I think it works because I've used it on PC's without a problem. I have a crude Logic Analyser connected to the HD control signals and although it's crude, I know that if anything moved, I'd at least see a trigger trace on the LA screen. As I implied back at the top of this posting, it's always showing "Everything high"; in other words, fairly dead.
Because I don't have any documentation for 110Bug, I don't really understand what each command does. There is Bug documentation on cards like the MVME177 but the functions of each IO* command is massivly expanded and so is of limited use. I'm not good enough to figure out what the commands do by reading the source (sorry). I find it amazing that the code could contain so much annotation without actually explaining what user function is provides anyway the authors will have assumed the reader had the User Manual....
I have figured out that in general, all the disk related command seem to take two arguments representing the HD ID and the controller. My HD is a number 0 and my controller is a number 4. I got this from the card user manuals.
So first of all we have IOT and IOP. I think IOT teaches the controller about the geometry of the connected drives and IOP enables direct physical interaction with the drive. So getting to actually try something, if I enter;
IOTor
IOT 0,4or
IOPor
IOP 0,4The bug hangs and after about 20 seconds, the Fault LED lights up on the processor card. The only way out is a reset.
This leaves us with IOC which enables the user to set up a control block in RAM and then (I'm assuming) point the disk controller at it and let it carry out the command.
I don't know, but I'm assuming that the difference between IOC and IOP is that the former uses a RAM based control block (called an ECA in the manual) where as the IOP command enables you to poke the disk controller registers directly. That's just a guess of course.
So if I enter;
IOCThen there is a delay of about 60 seconds and I get a prompt to enter the drive number, then the controller number. I enter 0 and 4.
I am then presented with a PARTIAL memory dump of the ECA and I'm asked if I'm sure. I say "Y" and the bug goes dead for about 30 seconds and finally returns a PACK error.
It's interesting that the ECA is longer than the memory dump. Don't know why this should be but it's missing the geometry section at the end. Not really a problem but interesting.
When I do a dump of the ECA following the command running, I can see that the main status is $07 which is "Card busy". I don't think any other part of the ECA is altered.
This is really good because I'd like to think that the disk controller tried to do something and timed out.
Turning to the memory locations used by the disk controller card, if I dump the odd addresses, I see values. If I dump even addresses, I get bus errors. If I remove the card and try again, all memory addresses I try to dump give bus errors. This gives me hope that the disk controller is not totally dead.
Returning to the ECA, loading it by hand is error prone so I wrote a little loader program that sends keystrokes to the serial port. This is a dumb process, but it does seem to work. Here's a list of the ECA I set up;
# Start loading the ECA as per MVME320 User Manual pg C-9
# Commands described pg 6-1
# Zap the buffer back to 00
bf 110 170 00
# Zap my sector buffer (not that I need one for the command I'm using)
bf 1000 1800 00
# Fill the ECA
m 110
# Command code (Recalibrate to track 0) $00
00
# Main status $01
00
# Extended status (Should be 00 before command) $02
00
00
# Max retries $04
0a
# Actual retries $05
00
# DMA type $06
00
# Command options $07
00
# Buffer address (Hi word) $08
00
00
# Buffer address (Lo word)
10
00
# Buffer length requested $0C
00
01
# Buffer length transferred $0E
00
00
# Cylinder number $10
00
00
# Head number
00
# Sector number
01
# Current cylinder position $14
00
02
# Reserved $16
00
00
00
00
00
00
00
00
00
00
# Pre index gap $20
00
# Post index gap
00
# Sync byte count
00
# Post ID gap
00
# Post data gap
36
# Address mark count
03
# Sector length code
01
# Fill byte
e5
# Reserved $28
00
00
00
00
00
00
# Drive type - Soft sectored, Hard disk with CRC $2E
03
# Number of surfaces $2F
04
# Sectors per track $30
0a
# Stepping rate $31
06
# Head settling time $32
46
# Head load time $33
46
# Seek type $34
02
# Reserved (Phase count) $35
00
# Low write current $36
00
50
# Precomp cylinder $38
00
50
# ECC remainder $3A
00
00
00
00
00
00
# Appended EEC remainder $40
00
00
00
00
00
00
# Reserved $46
00
00
00
00
# MVME320 working area $4A
00
00
00
00
00
00
00
00
00
00
00
00
# Reserved for the controller $56
0f
f0
# Get out of data entry mode
.
# Present a dump of the commannd
md 110 5f
# Actually send the command to the MVME320
# ioc 0,4
and here's the program that loads it (via that Terminal Server I mentioned before).
# Send a series of keystrokes to an MVME110 serial port via a terminal server connected
# on the LAN. The keystrokes are held in a file, e.g. keystrokes.key
# D. Waine 27/04/24
# In order that this program function, you need to have the TS and the MVME110 switched on (!)
# then start a terminal session using puTTY to the TS. Run this program and the
# key strokes will load.
import sys
import os
import socket
from time import sleep
# Location of the TS on the LAN
terminalAddress = '192.168.0.3'
terminalPort = 8234
if len (sys.argv) != 2:
print ('Incorrect number of arguments. You need to supply the input .key file without an extension')
sys.exit (2)
filename = sys.argv [1]
fileExtension = '.key'
inputFile = filename + fileExtension
lineCounter = 0
outputCounter = 0
# Open the input file
print ('Opening input file: ', inputFile)
with open(inputFile) as inFile:
print ('Opening output stream to MVME110')
sock = socket.socket()
sock.connect((terminalAddress, terminalPort))
print ('Connected')
sleep (0.1)
# Read it a record at a time
for line in inFile:
# Trim the input line of CR/LF & any spaces
inputLine = line.strip()
# Bump the correct input record type counter
lineCounter += 1
if inputLine [0] != '#':
sock.send ((inputLine + '\r').encode())
sleep (0.1)
outputCounter += 1
sock.close()
print ('Input records: ', lineCounter)
print ('Sent records: ', outputCounter)
If anyone can shine a light on any of this, I'd be grateful.
Thanks for your attention.
Dave