Initial testing of Virtual 2315 Cartridge Facility working on the IBM 1130

CHECKED WIRING AND BEGAN POSITIONING THE V2315CF BOX ON THE 1130

I routed the final power lines within the IBM 1130 and positioned the various boards, boxes and the battery where I believe they will live permanently. The interface board that interposes signals between the 1130 controller logic and the 13SD disk drive sits down low on the right hand side of the machine, while the remainder will sit atop the 13SD drive enclosure. 

The top right of the IBM 1130 swings up for access to the CE switches, also exposing the top of the 13SD drive and other bits of the machine. Thus, when that gray top is swung up, the Virtual 2315 Cartridge Facility (V2315CF) will be visible. The main box of the V2315CF is angled upwards so that the operator can read the screen and lights. Aside it will sit the power distribution/monitoring board, the power supply, the trickle charger/maintainer, and the motorcycle battery. 

I haven't received the power distribution/monitoring board parts yet, but have power connected to both the 1130 main supply and the motorcycle battery at this time. The power supply, charger and battery are sitting loose, but they will be fastened down once I finish this installation. 

INADVERTENT SHORT TO V2315CF BOX - WON'T INITIALIZE

The top plate of the 13SD disk drive enclosure is metal and connected to system ground. Due to the tilt of the main V2315CF box, a few pins on the rear of its main board made contact with the disk enclosure plate. The ones I am certain were affected are the three pins for the debugging serial port, but there are also FPGA programming pins that are a hair higher from the edge of the PCB and thus may not have contacted the plate. 

When I bring up the system, the V2315CF box does not display anything on its OLED screen nor change the lights to its normal initialized state. Hooking up a USB serial connection to the debugging port yielded no messages at all. 

I pulled the Raspberry Pi PICO and attempted to open it as a disk drive on a nearby PC - this is the normal way you program it by holding a BOOTSEL button as it is plugged in. Nothing at all. The PICO is clearly damaged. The remaining question is how much else on the V2315CF box might have been impacted. I grabbed a spare Pi PICO and programmed it with the code. 

POWERED UP V2315CF AND SAW IT INITIALIZE

The new PICO did initialize and go through the process of reading a virtual cartridge image into the SDRAM according to the OLED screen on the box. I tried a number of functions such as toggling Read-Only which appeared to work properly. Based on this, I tentatively proceeded to testing on the IBM 1130 system but remained concerned that other devices in the box had failed due to the issue that fried the PICO. 

VIRTUAL MODE TESTING CAMPAIGN FIRST

I powered up the IBM 1130 with the V2315CF set to pure virtual mode. An initial Sense DSW to read device status showed appropriate values except that bit 10 was set after the sense when it should be at zero. Nothing in the box itself drives bit 10 in any way, thus this phantom bit is coming from somewhere in the IBM 1130 circuits, perhaps the disk controller logic but it could be anywhere since there is a shared bus that feeds bits for operations such as Sense DSW. 

The simulation should begin by emitting sector and index pulses, waiting 90 seconds as the real disk drive would, then turn on File Ready status indicating it is available to accept commands from the 1130. This activity would be triggered by virtually powering up the drive, via loading the virtual cartridge image using the V2315CF. 

I flipped the load/unload switch to load and watched the V2315CF read the image and send it down to the SDRAM. The File Ready lamp on the main 1130 console did indeed light up after 90 seconds. A Sense DSW returned the proper status - the disk was not busy or offline, it marked the arm location as Home (cylinder 0), and a sector number was showing. That sector number changed, reflecting the sector pulses which come from a spinning (virtual) disk. 

 However, I observed three incorrect behaviors in addition to the phantom bit 10 in the device status word. First, the Ready lamp on the V2315CF box was illuminated right after initialization and never changed, even though it should parallel the File Ready lamp on the main 1130 console. Second, the Fault lamp on the V2315CF box lit, which locks out the drive from responding to any further commands from the 1130. Third, the Unlock lamp on the main 1130 console remain lit even though the simulated disk drive had a loaded cartridge once I flipped the load/unload switch on the V2315CF to load. 

The Unlock lamp is an issue I didn't properly deal with for virtual mode. When the disk drive is first powered up, it energizes a solenoid to allow a handle to be opened to insert or remove physical 2315 disk cartridges. The +48V on the main console Unlock lamp is pulled to ground by the same circuit that pulls +48V through the unlock solenoid to ground. 

The lamp thus lights when the solenoid end is pulled to ground by the drive. The circuit I established in the V2315CF for virtual mode will also pull that line to ground when activated, thus I can force the lamp to light (and the unlock solenoid to energize) from the V2315CF. 

This is the opposite of what I needed to do. I instead need to extinguish the Unlock lamp on the main 1130 console when in pure virtual mode, based on a signal from the V2315CF, rather than lighting it. I have to rethink this portion of the design.

The File Ready lamp on the V2315CF box should not be lit except when the main console File Ready is set. The code in the PICO drives the lamp based on the main state machine - when it is initialized or a cartridge is not loaded, it is turned off by changing the general purpose input-output (GPIO) pin on the PICO. Once a cartridge image is loaded, it turns on that GPIO pin. 

The signal from the PICO GPIO pin flows over a cable to the front panel board, where a buffer chip drives the LEDs including the File Ready one. Other LEDs are responding appropriately - Unlock - while Fault may be lighting instead of File Ready. Thus the places that might be in error are PICO software, the PICO itself, a cable, of the buffer chip. 

The Fault lamp is driven from the PICO in two situations - the simulated disk drive sends a Write Select Error signal via the FPGA or an error is detected in a data word being written from the IBM 1130 to the simulated disk during the writing of a sector. In addition, the fact that this lights when File Ready should go on may indicate a flaw unrelated to the real causes of a Fault. 

ADDING INSTRUMENTATION TO CHECK THE ISSUES ABOVE AND DO CHECKOUT

I will add some diagnostic messages to the box so that I can tell when the Fault lamp and the File Ready lamp on the V2315CF is turned on by the code in the PICO. I will also hook up the scope to watch the signals going in and out of the V2315CF to check for correctness. 

Today I expect to have an IBM 1132 line printer, an IBM 2501 card reader and an IBM 1627 plotter delivered to my show from the Infoage museum (Vintage Computer Federation museum) where I will restore them and make sure they work with the IBM 1130 I previously restored for the museum. This will minimize time available for debugging of the V2315CF. 

Virtual 2315 Cartridge Facility connected to IBM 1130 for testing

INTERRUPTING THE NORMAL SIGNAL FLOW BETWEEN DISK AND CONTROLLER

A cable from the IBM 1130 controller electronics is plugged into the small electronics box on the rear of the 13SD disk drive, carrying all the signals between the two ends. The Virtual 2315 Cartridge Facility (V2315CF) interposes between the two ends. Some signals are transported directly between the 13SD and the controller. Some signals are transported between 13SD and controller but also watched in the V2315CF since it must remain in sync with the state of the 13SD in order to perform its functions. Some signals are sent from V2315CF to the controller.

In the real mode - hybrid operation of the 13SD and V2315CF - the disk drive generates signals such as Sector Pulse, Index Pulse and File Ready. In virtual mode, where the disk drive is not active at all, the V2315CF must generate all these signals. Thus the choice of whether a signal passes through the V2315CF between 13SD and controller or not is determined by the mode. The real mode is the normal, intended way to run with the V2315CF. 

The cable from the IBM 1130 controller electronics is removed from the back of the 13SD drive. It plugs into an interface board instead. A cable from the interface board plugs into the rear of the 13SD drive. Two ribbon cables from the interface board hook it to the V2315CF main box. The interface board also contains the real/virtual mode switch. 

BUILT NEW VERSION OF THE INTERFACE BOARD

My updated interface board design includes the Real/Virtual mode switch and has a redesigned circuit to drive the Unlocked lamp using a MOSFET. I used my rework tools to carefully pull the connectors, pins and other parts from the old board, then soldered them onto the new version. I removed the wires from the disk interface cable, one by one, and soldered them to the new board. 

I did loose a couple of the gold plated pins that substitute for IBM SLT backplane pins, into which the.  cable from the CPU controller logic plugs. I had some spares which I made use of. I did have a 10uF surface mount capacitor spring out of the jaws of the tool I was using to solder it to the new board. I couldn't locate it and didn't have another compatible capacitor - I have some at lower voltage levels or different form factors. I will tack a through hole part on the board and replace that when my latest parts order is delivered. 

V2315CF SET UP IN THE IBM 1130 FOR TESTING CAMPAIGN

The interface board is back in place inside the IBM 1130. I temporarily placed the main V2315CF box and the power supply on top of the internal disk drive cover, then proceeded to wire up the final electrical connections. IBM 1130 +12V power is connected through diodes to the V2315CF power supply, the trickle charger/maintainer and the motorcycle battery. 

NEW PCB DESIGNED TO SIMPLIFY POWER DISTRIBUTION, CHARGING AND MONITORING

I whipped up a simple PCB to hold the various diodes that connect the 1130's +12V supply, the 12V lead-acid battery, the trickle charger/maintainer that ensure the battery is topped up, and the connections to the power supply for the Virtual 2315 Cartridge Facility. It is on order, but I did a prototype soldering together components to test with the board while I wait for the production parts. 

TESTING PLAN

I will test first in virtual mode, leaving the 13SD drive powered off. This should allow me to debug most of the functionality (and look for defects in the 1130 controller electronics that weren't previously identified). 

I can hand toggle simple input output commands to validate quite a bit of the functionality. The 1130 uses an instruction (XIO) that points to an input-output control command (IOCC). The IOCC specifies a device number, in our case 4 for the internal 13SD disk drive. It specifies a command type (Read, Write, Sense Device, Sense Interrupt, Control, Initiate Read and Initiate Write). There is a pointer to a memory location used for some of the command types, plus a few bits that can be used for unique purposes by some devices.

The 13SD disk drive uses three bits to indicate the head and sector desired for read or write operations. It has another bit it uses to show the direction of arm movement - towards higher or lower cylinder numbers. A final bit is used to block data transfer when doing a read, used to validate the parity of a sector without actually transferring the 321 words into core memory. 

The 13SD uses Initiate Read and Initiate Write, rather than Read or Write, to perform data transfer. The memory address in the IOCC points to an area. The first word contains a count of the number of words to transfer, up to the maximum possible in a sector of 321 words. The subsequent sequential locations in core memory will hold the data to be written or receive the data during a read. 

I will program some Sense DSW commands to monitor the status bits and the sector number being displayed from the simulated rotating disk at the time the XIO is executed. I will use this after other commands I run later, to see the outcome of each test. 

Next I can issue Control commands to move the disk arm, watching on the debug console (serial USB link) of the V2315CF for the command to be recognized and the box identify the correct end cylinder number for the movement. 

When satisfied with this, I will issue an XIO Initiate Read to read in a sector so that I can compare the core memory contents with the known value in the virtual 2315 cartridge image. 

When the reading is considered to work properly, I will modify some locations in core memory that had been read in from the disk, then issue an XIO Initiate Write. If the status appears good to this, I can then reread the sector with XIO Initiate Read to see that the changes were indeed placed on disk and retrieved. 

All of this will be done with the Read-Only mode set on the V2315CF box so that I am not damaging the virtual image if things don't work properly. Only when all of the above seem to be working properly will I Unload the virtual cartridge without Read-Only, updating the file on SD card. I can look to see that the changes I made do appear in the proper location of the resulting file on SD card. 

I can load the disk drive diagnostic program into the IBM 1130, execute it and let it work against the virtual disk drive we are emulating. Assuming a passing result, it would be time to flip the switch over to real mode on the V2315CF interface board and do this all again with the 13SD drive running.

The real drive will have a cartridge inserted - contents don't matter as the hV2315CF eads will not actually read or write nor touch the surface - and the drive powered on. I will load a virtual 2315 image on the V2315CF main box and wait for the File Ready lamp on the 1130 console (and V2315CF box) to illuminate. I can then run the disk diagnostic with V2315CF in Read-Only mode, validating that the hybrid mode also works. 

Lastly, I can hand code an XIO Initiate Write to write content of my choosing on a sector of the virtual cartridge, having turned off Read-Only, then unload it to look for the updated contents in the SD card file. 

All of the above should be proper testing to consider this facility operational. I can begin to use the IBM 1130 with disk images that don't require the peripherals I have not yet restored. The main operating software DMS2 expects a working line printer and card reader. At startup it tries to print a banner and then read a control card. If either peripheral is not working, the processor sits in a wait state, where nothing but the correct response of the requested device will allow it to move forward. 

SECOND V2315CF BOX CONSTRUCTED FOR SSM MUSEUM INSTALLATION

This initial V2315CF system is installed in the IBM 1130 belonging to the museum operated by the Vintage Computing Federation up in Wall, NJ. I ordered another kit from George Wiley and built it so that I can install it on the IBM 1130 I previously restored for the System Source Museum in Hunts Valley, MD. I will have to do the install on-site there. 

I ordered parts to build the interface and power distribution/monitoring boards to go with this. I haven't yet ordered a motorcycle battery or charger/maintainer for this system, but will do so once I am scheduling the time for its installation. 

Enhanced Virtual 2315 Cartridge Facility to gracefully handle abrupt power down of the 1130 system

SCENARIOS THAT I HAD TO ADDRESS

Imagine that the system is up and running, with software running on the IBM 1130 that is writing changes to the disk cartridge. If the building power fails, the Virtual 2315 Cartridge Facility (V2315CF) would have the disk drop out of ready but all data changed during the session would be stuck in SDRAM in the V2315CF and not rewritten to the SD card. Thus, perhaps hours of work would be lost.

In fact, even if the operator finished up a session by switching off the physical disk drive switch, the data would remain inside the V2315CF until the Load/Unload switch was moved to Unload. If the operator forgot that step and later powered down the machine, the same loss of the day's work would happen. 

An even more pernicious failure might occur if the V2315CF box had its switch turned to Unload but was in the middle of rewriting the file on the SD card when power abruptly dropped or the operator flipped the 1130  power switch off. The cartridge image would be truncated and therefore unusable. 

TWO ELEMENTS WERE NEEDED TO GRACEFULLY TOLERATE THOSE SCENARIOS

The V2315CF must have sufficient power to recognize an outage and complete rewriting the updated data from the SDRAM into the SD card file, before it stops working. Secondly, it must be able to recognize that the power has failed even though it has the reserve power from the first element allowing it to continue running for a bit of time. 

A motorcycle lead-acid battery with a battery trickle charger/maintainer will be the easiest way to provide the reserve power needed to gracefully wrap up what it is doing including rewriting if a cartridge was unloaded. The charger/maintainer can be continuously connected to the battery without doing any harm, as the microprocessor inside the maintainer only issues pulses of charging when the battery charge drops below full. 

A diode between the IBM 1130 +12V supply and the V2315CF facility isolates the reserve power such that it only flows into the V2315CF. However, a connection from the 1130 side of the diode gives us a way to detect when the 12V has dropped. A simple transistor circuit converts the 12V into a pulldown of a general purpose IO pin on the PICO processor.

Fortunately for me, George Wiley had a spare pin (GP5) which was routed to a connector JP27 on the main board. Thus, I only need to wire that to an NPN transistor that conducts whenever the +12V from the 1130 is present. 

CHANGES MADE TO THE STATE MACHINE IN THE PICO

The state machine in the PICO is what determines when and how we load, unload and rewrite cartridge images. It must check for the power outage and immediately unload any cartridge that is active. It also must unload a cartridge if it is in the pre-ready stage where it was loaded into SDRAM but the physical disk drive has not come ready yet. 

When it unloads the file, the physical Load/Unload switch remains in its Load state. We have no way to force the switch off, but we can ignore it for the transition from idle to begin loading a cartridge. Thus, before we look at the Load/Unload switch, we check to see if there is a power outage and do nothing when that is true. 

At worst case, if the switch remains physically set to Load, at some later time with the IBM 1130 system is powered up by an operator, the virtual cartridge will load, waiting for the disk drive to come ready. The operator can always turn the switch to Unload if they want to plug a different virtual cartridge into the V2315CF, otherwise it is ready when the disk is turned on. 

TESTED WITH A JUMPER WIRE 

I did some initial testing of the changes to the state machine. I hooked a jumper wire between connector J27 and a ground connector on the V2315CF. That is the state it will assume when there is +12V power from the IBM 1130. The system came up and ran normally. I disconnected the jumper at various times to see how it behaved. It did immediately unload any cartridge that was in SDRAM, then refuse to acknowledge the Load position of the Load/Unload switch until I reconnected the jumper. 

Holder for virtual cartridge image SD card - shaped like a 2315 cartridge

IDEA FOR THE SD CARDS USED TO HOLD A VIRTUAL 2315 CARTRIDGE IMAGE

The main V2315CF box has a slot with an SD card connector. An SD card holds a virtual 2315 cartridge image in a file - any file with the suffix .dsk and the proper header and length will be accepted by the V2315CF. Since the micro SD cards are small, fragile and awkward to insert or remove, I am planning for an alternative.

The SD card connector is on a small PCB in the opening on the V2315CF box. I purchased a 125 of the same connector, so that I can put a connector on a object that represents a cartridge. The rear of the object will have a connector pin that mates with a ribbon cable that currently hooks to the PCB of the original design. By inserting the object in the slot, the connection is made to the card connector and SD card that is hidden inside the object.

Thus, an object that represents a 2315 cartridge will exist for each cartridge image a user wants to have. By plugging the appropriate object into the V2315CF main box, it is ready to be loaded. Best would be something that looks exactly like a 2315 cartridge, in miniature. 

I designed a circular white PCB with lines on the top that makes it an obvious but tiny 2315. The socket and a couple of passive components would mount on the underside, leaving the top surface to resemble a cartridge cover. An enhancement might be a white plastic part that snaps onto the bottom of the PCB to fully hide the SD card and other parts, as well as giving it a realistic height in proportion to its size. 

Top of the white PCB

I plan to produce a good supply of the holder objects to mount the connector and pins, then modify the V2315CF main box to support insertion and removal (via some kind of guides). Each of these objects would have a micro SD card inserted, containing the disk image file. I have 125 PCBs on order as well as 125 each of the resistor and capacitor that goes on each PCB. 

wrong color 3D view of underside

wrong color 3D view of top focusing on connector

Passed final tests on Arduino testbed for Virtual 2315 Cartridge Facility

DUAL MODE STARTUP AND SHUTDOWN WORKING PROPERLY

The changes I made for startup and shutdown, where the method of moving the state machine to full ready and then to unload is quite different in pure virtual versus hybrid (real drive) mode, were implemented. Below you can see the process of updating the flash for the FPGA code.

Updating flash with SPI protocol

For startup in pure virtual mode, a state machine will move through the 90 second power up sequence that a 13SD disk drive would perform, manipulating the correct signals at the appropriate time. The Unlocked lamp is lit on both the Virtual 2315 Cartridge Facility box and on the IBM 1130 console at the start. When the box is switched to Load, Unlock goes off and the timing begins. We emit these signals:

• Unlock turned off
• 90 second relay on for 90 seconds
• File Ready asserted at the end to indicate the virtual heads are loaded and ready to go

In real mode, the disk drive's signals are passed through and used to move the state machine to its running condition. The same signals are produced, but by the hardware in the 13SD drive. In either case, when File Ready is on, the box shows the Ready lamp as does the IBM 1130 console. 

For shutdown in pure virtual mode, the box sees that we are not in real mode, so it continues on to check for the box switched to Unload. That triggers an unload of the virtual cartridge and turns on the Unlock lamp on both the box and the 1130 console. 

For shutdown in real (hybrid) mode, the box ignores the Unload switch until File Ready is turned off. This occurs when the 13SD drive is physically switched off by the operator (or if there is a disk speed or other fault in the disk drive). That triggers the unload. The Unlock lamp on both the box and the 1130 console are driven directly by the Unlock circuit of the 13SD drive. 

I tested this to confirm that the startup and shutdown worked correctly, doing runs in both real drive and pure virtual modes. I also performed the scripted sequence of seeks and a sector read to ensure that I didn't regress anything else with my most recent changes. Everything checked out. I even did a comparison of the virtual cartridge image file against its master copy on my laptop, with no changes found in spite of being rewritten from the box's SDRAM several times during shutdowns. 

IMPROVED THE ARDUINO TESTBED WITH DIRECT PORT MANIPULATION

Since the Arduino is using various time tests to trigger events, any delays might cause the time to move past a target value and spoil the signal sequences being emitted. The original version used the Arduino digitalWrite statement to vary each signal, which is relatively slow. 

The GPIO (general purpose input-output) pins of the Arduino are mapped to various port registers on the microprocessor. These can be directly addressed by statements such as PORTA |= 1<<2; which sets bit 2 of port A to 1 in order to emit a logic high out of pin 24 on a Mega 2560. 

This removed a couple of glitches I was observing on earlier runs and gave me clean consistent results during my testing. 

Preparing to Unload when in Read-Only mode

NEXT STEPS FOR TESTING

I will bring the Virtual 2315 Cartridge Facility box over to the workshop and begin cabling everything together on the IBM 1130 system. I expect to accomplish all the remaining testing on the system itself, unless I identify some issue that is easier to iterate through a fix using the earlier testbeds or simulation.

I have to spend the day at the Space Force Museum at LC26 inside Cape Canaveral SF Station, being a docent for visitors to that launch complex. Hopefully I can do some of the wiring and installation work later in the afternoon when I return.  

Testing access operations of Virtual 2315 Cartridge Facility using Arduino testbed

TESTING SEEK OPERATIONS 

I set up the Arduino to pulse the Access Go and Access Ready signals to cause it to perform seek operations. That should light the Seek lamp on the box as an indication of the activity. 

The unique hybrid operation mode means that the seek is actually taking place on the 13SD while the Virtual 2315 Cartridge Facility is shadowing that operation in order to keep track of the current cylinder for eventual read or write operations. Thus my tester is simulating both ends just to verify that the shadowing appears to work properly. 

This worked as expected, moving forward and backward in steps of 1 or 2 cylinders at a time. Too, I verified that it won't back up to a negative cylinder number nor advance past the last cylinder 202. 

I wrote macros to perform seeks at a target time (in millseconds since bootup). The code above is an example of those being used in the Arduino test code. 

TESTING BY READING A SECTOR

Another test I programmed on the Arduino turned on the Read Gate thus I should see the Read lamp flicker on. I could, with an oscilloscope, view the stream of clock and data pulses that is generated by the box based on the virtual cartridge contents. 

You can see above my test which first did a one cylinder seek and then read a sector. I didn't have a scope at home where I am testing, but since the simulations seemed so good, for the time being I feel optimistic about reading. 

NEXT STEPS IN TESTING TO CHECK OUT WRITE

Testing a write is too complicated to perform with the testbed I, since the timing of the change in the write clock and data line must be tightly aligned with the 720KHz clock being generated by the emulator. I therefore will move forward to testing on the live 1130 system and its disk drive. 

STILL SOME TESTING TO VERIFY THE PURE VIRTUAL MODE

When I flipped the signal to tell my design that there was no physical disk drive running, it generates all the signals like Sector and Index pulses that normally will come from the disk drive. Where it is most different is in the startup and shutdown.

My design depends upon the 13SD disk drive to spin up, ensure it is at speed, believe it has loaded the heads and then signal File Ready, in order for the Virtual 2315 Cartridge Facility to get to full running mode, permitting the IBM 1130 to issue disk commands. When the drive power switch is flipped off, the drive spins down, believes it retracts the heads and turns off File Ready.

There is no analogous power switch in virtual mode, thus I need to simulate the disk drive coming up to speed with a state machine and generate signals equivalent to what the drive does. Even worse, I realized that my logic in the Virtual 2315 Cartridge Facility waits for File Ready to drop before it is ready to unload the virtual cartridge image. With no power switch, there was no way to tell it to stop 'spinning'.

I identified these misbehaviors in my final tests today and went off to refactor the startup and shutdown to work properly in both hybrid and virtual mode. I changed code so that it knows if we are in real drive or pure virtual mode, so that it can unload the cartridge and turn off the disk drive purely by switching the Load/Unload switch on the emulator box to Unload. 

In hybrid (real) mode, it is the physical drive that must turn off before we even look at the Load/Unload switch. I need another round of testing (tomorrow) to satisfy myself that I didn't break the operation in real (hybrid) mode and that I corrected the issues for virtual mode. 

Arduino to drive signals into the box to further test the Virtual 2315 Cartridge Facility

USING AN ARDUINO TO DRIVE TEST SIGNALS INTO THE EMULATOR BOX

I will use an Arduino to simulate key signals to do the next steps in testing. The circuitry of the RK-05 Emulator handles 5V inputs and outputs, using level converters, perfectly suited for using an Arduino to test the emulator box.

I selected eleven signals to be generated by the Arduino as input to the emulator box, and observed another four that are output from the emulator box. My generated signals included ones that would be produced by the 13SD disk drive in the IBM 1130 and signals that would be emitted from the disk controller logic in the 1130. 

MINIMAL SIMULATION TO TEST THE EMULATOR

All the input signals that affect the operation of the emulator must be put at an appropriate default level, only changed when being asserted. For example, Read Gate and Write Gate, which request reading or writing to a sector, must be high to be inactive, only pulled low to assert the function. Real Drive is on to indicate we have the normal hybrid mode where the 13SD drive performs some functions as we emulate the virtual cartridge.  These are set at startup of the Arduino test code. 

The tester produces signals to emulate the Sector and Index pulses that normally come from the 13SD disk drive, as they would occur with it spinning at the correct speed. 

Asserting the File Ready while keeping Disk Fault off will allow the facility to be open to commands. It will then respond to other requests from the controller for disk actions. 

CHECKING LOAD AND UNLOAD OF A VIRTUAL CARTRIDGE IMAGE

This will let me repeat the testing I did before, loading a cartridge so its data is down in the SDRAM, then unloading the cartridge to rewrite the file on microSD card. Assuming it ends up with the proper content matching the original cartridge image, I can assume the RAM is working well. 

Everything worked exactly as it should as far as loading and unloading the data. The file that was rewritten when we switched off the simulated drive and unloaded the cartridge was an exact match to the virtual cartridge file on the SD card. 

However, the state of the RDY lamp was opposite to what I thought I was driving. This highlighted something I got wrong in my setup. I also noticed the WR lamp steadily illuminated, which should flicker on and off when we are doing a write operation but be steadily off otherwise. 

The WR issue was because my test code in the Arduino didn't set up the output pin to drive Write Gate. It was corrected, along with some logic.

I saw the proper data both downloaded and uploaded to rewrite to the virtual cartridge file. The state machines interlock correctly with the state of the disk drive as simulated by the Arduino. I also verified that I can toggle the machine between normal and Read Only mode, where it would skip writing back the changed contents, essentially making the virtual cartridge image on the SD card remain as it was, ignoring any writes done by the 1130 during operation. 

FIXING DESIGN WEAKNESS RELATED TO READ-ONLY MODE

The read only condition is reset when the Cart Ready state is revoked, which happened BEFORE I interrogated the state of the read only flag. Thus my state machine didn't see it and instead wrote the cartridge image back. I reorganized the code a bit and had it performing as intended.

Replacing bad heads on Diablo 31 to use for archiving IBM 1130 disk cartridges - part 2

MARKING POSITIONING OF HEADS ON THE DIABLO MOUNTS

In order to get the geometry of the head aligned with the drive properly, I marked the outline of the crashed heads on the metal holder that inserts into the Diablo arm mechanism. This will ensure I can get the replacement heads tightened down exactly where the original heads sat. 

Damaged head on right, attached to Diablo arm

REMOVING HEADS FROM 2302 ARMS

The screws mounting the heads to the 2301 arm have epoxy over them to protect them from unloosening accidentally. It was easy to chip the epoxy away as it is brittle. The screws were then removed and the head disconnected from the connector at the end of the 2302 arm. This is a very different connector than the one used on the IBM 1130 or Diablo drives. 

MOUNTING AND CHECKING OUT HEADS

I put the replacement head on the Diablo mount, with the screws slightly loose, then maneuvered it until it exactly matched the outline I had scribed from the original head. Tightening this up gave me a Diablo mount with a serviceable head. I will put epoxy on the screw, just as IBM had, to lock it down. 

Heads swapped, bad one loose on right

SWAPPING SIGNAL CONNECTOR 

I had to cut the connector off the crashed head and splice it to the wires from my replacement head. I needed to determine where each wire was connected inside the metal head. The read/write head has three wires connected to it plus a ground wire that provides shielding for the cable. Grey and Violet wires are connected to the two sides of the read/write coil, with a red wire hooked to the end of the erase coil. 

wiring as shown on 2310 document

The center tape of the three windings seen above are carried on the fourth wire that was attached on the 2302 arm. I looked at the use of the heads on 2311, another drive that utilizes the part and for which I have documentation.

Head wiring as used on 2311

I believe that the 1130's grey and violet wires are the two white wires from the diagram above, with the blue wire unconnected when used on an IBM 1130. The cable running through the disk drive, from the connector down to the drive electronics, uses the black wire for shield grounding but the black wire is unconnected to the heads. 

This gave me the information I need to splice the connector from the bad head with the wires from the good head. I will make the connections to give the same length to the cable as it had with the bad head, so that the cable routing and hold-downs in the Diablo would be good.