Result of debugging the initial issues found testing the Virtual 2315 Cartridge Facility in virtual mode on the IBM 1130

INVESTIGATING ANOMALIES OBSERVED DURING INITIAL TESTING

My first testing of the Virtual 2315 Cartridge Facility (V2315CF) hooked to the IBM 1130 resulted in observing a few incorrect results. The File Ready lamp on the V2315CF lit all the time, when it should only light when the simulated disk becomes ready for access. The Fault lamp on the V2315CF lights as soon as the simulated disk becomes ready, but no error condition should have occurred. A phantom bit (bit 10) is injected into the IBM 1130 memory bus when I sense the device status of the disk controller. 

FILE READY LAMP INVESTIGATION

Looking at the debug console output made it clear that the PICO did not believe it had turned on the ready lamp, but it was illuminated. I was preparing to troubleshoot, tracing signals, as well as instrumenting a version of the PICO software with more outputs, when I decided to swap the PICO from the other unit I built since it was a quick test. The Ready  lamp was not lit! 

I hooked up the original PICO and loaded the code base I had on my laptop, but it continued to produce the erroneous Ready lamp. Therefore there is either a damage on the PICO, which was a new one I substituted for the ruined one, or my load file is out of sync with the working code on the final PICO. 

DISK FAULT LAMP INVESTIGATION

I found that the terminator board had a couple of lines I needed that were not fully populated with the paired resistors used for all the others. I moved a couple from lines I don't utilize and soldered them onto the terminator. The disk fault issue disappeared. 

The terminator uses a pair of resistors one pulling up to +5V and one pulling down to ground. Together they set the idle voltage at 3.3V and yield an effective resistance of 120 ohms. These were selected for use with the RK-05 drive and DEC controllers. IBM tends to terminate their long transmission lines with 95 ohm impedance, thus I may need to tweak the resistor values if I see issues caused by ringing or other noise on the lines. 

The most sensitive lines will be those that carry the written data to the disk drive as they are sampled by the drive at specific edges of the clock coming from the drive - thus I might get data corruption if the signals are too marginal. I will scope the lines at a later date to check the suitability of the current terminator and make changes if necessary. 

PHANTOM BIT INVESTIGATION

The phantom bit 10 appears to be in the accumulator register, where it affects computing effective addresses as well as storing the device status from a Sense DSW. I will shoot this later, once the V2315CF is debugged. 

DROP OFF OF 1132 AND 2501 FOR RESTORATION

Today the line printer and card reader for the VCF 1130 arrived. I opened them up for a rapid first assessment. They don't appear too bad, thus I have reasonable hopes that I can restore them both to operation. 

The card reader has a large gear which had plastic teeth attached to an aluminum disk. The plastic had become so brittle that it was already cracking just from movement and breaks further when touched. I will have to make a replacement gear. This operates the joggle plate on the card output which moves the stacked cards back and forth; not a very timing critical part. 

Design changes for Virtual 2315 Cartridge Facility

AS IT WAS DESIGNED, V2315CF IS ALWAYS POWERED ON

The existence of the motorcycle battery and its charger/maintainer will keep the Virtual 2315 Cartridge Facility (V2315CF) main box powered as long as the battery remains charged. That is, as long as the main power plug to the IBM 1130 is connected, even if the system is turned off, the battery is getting some charging even as it is powering the V2315CF. 

Also, if the Fault light comes on, the V2315CF stays latched in that state until power is cycled. This would take many, many hours with the IBM 1130 unplugged with the current design. Clearly, we want to have it turn off when the IBM 1130 is powered down, but it must maintain some power long enough for an emergency unload of the cartridge image if one was loaded. 

The solution is a time delay relay, one that I configure so that when the +12V power from the IBM 1130 comes on, a relay closes. It will remain closed for a time duration N when the +12 from the 1130 shuts off. I can adjust N with a wide range, but it only needs to be long enough to allow the V2315CF to finish its unload that begins when we see the power drop. I believe that two minutes is plenty of time. The relay hooks the battery to the system, so that battery is removed two minutes after 1130 system power turns off. 

UNLOCK LAMP CONTROL DURING VIRTUAL DISK MODE

When we are the normal real disk mode, the 13SD disk drive inside the IBM 1130 is producing the Unlock drive to the main console Unlock lamp. My interface board watches that Unlock drive signal in order to control the Unlock lamp on the V2315CF and to control the state machine in the PICO. It should be able to turn the main console Unlock lamp on and off when we are in the alternative virtual disk mode. 

The main console Unlock lamp has +48V on one side. Inside the 13SD drive, an unlock solenoid is also connected to +48V on one side. The other sides of the lamp and the solenoid are connected to an open collector circuit in the disk drive than can ground the lamp and solenoid when the drive should be unlocked. 

My original design, which does not do the correct thing, would ground the lamp and solenoid to turn both on even if the disk drive was not asking for it. That could be dangerous in a particular case - if the unit is set to virtual mode, but the disk drive was powered on, then the operator opens the handle while the cartridge is spinning. 

I will have to instead switch the lamp wire to either the disk drive or to my MOSFET circuit output from the interface board, depending on the real versus virtual mode of the machine. I will implement this on the interface board, using a relay to switch the wiring and the MOSFET to ground the lamp when switched to the virtual mode. 

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. 

FPGA programmer arrived; updated FPGA in Virtual 2315 Cartridge Facility

READY TO GET THE FPGA WORKING IN THE VIRTUAL 2315 CARTRIDGE FACILITY

The RK-05 Emulator from George Wiley, which is the basis for my Virtual 2315 Cartridge Facility, has an FPGA, a Raspberry Pi Pico and SDRAM that work together to emulate a disk drive, using data from a file on a microSD card to serve to the disk controller. 

I redesigned the emulator to form my virtual cartridge facility. My code is a significant modification of George's,  to accommodate the differences between the IBM 13SD disk drive and the DEC RK-05 drive, as well as to implement the unique hybrid mode of operation of my facility. A real disk drive, with a cartridge installed, will spin up and run. 

The virtual cartridge facility interposes between the 13SD disk drive and the controller logic in the IBM 1130 computer. The drive arm moves in and out as the controller operates the drive, but the data stream to and from the controller comes from my facility, based on the file in the microSD card. This gives the operator of the computer the sounds and movements from the real disk drive, but avoids disk heads riding on the real disk cartridge. This is valuable as the disk cartridges are precious and the disk heads are basically unobtainium. 

LATTICE PROGRAMMER CONNECTED TO DOWNLOAD BITSTREAM

The FPGA chip is a Lattice ICE40HX1K chip. Using the IceCube2 software toolchain, I synthesized my code and produced a bitstream to be loaded into the chip. The Lattice HW-USBN-2B programmer arrived Friday afternoon; it is hooked to the JTAG programmer connector on the RK-05 Emulator box and its software connects to and updates the ROM holding the FPGA code. The flash RAM is an N25Q032A13ESC40F device that is wired to the JTAG interface, providing 32Mbit storage that is used to initialize the FPGA. 

TESTING BEGINS WITH PAIRED CODE IN FPGA AND PICO

I brought up the box and repeated the testing I had done with the Pico code previously. That is, I had it load a virtual cartridge image from the microSD card, pushing the data down to the SDRAM using the FPGA. The inputs that would come from the disk drive and the disk controller logic are sensed as logically low, since they are not currently connected. 

This default asserted that the disk drive was ready to be accessed, allowing the Virtual 2315 Cartridge Facility to show the Ready lamp. However, another signal asserted that a fault occurred in the disk drive, rendering it unsafe to use. The Fault lamp lit on the screen. However, I couldn't unload the virtual cartridge because that requires the File Ready to turn off by going high, which won't happen with the default input state. 

My prior tests used the unmodified code from George's emulator, as the data download/upload function didn't change. It showed that the data from the virtual cartridge image was downloaded and when uploaded was a match, both to what was downloaded and to what was on the virtual cartridge file. 

My future testing will simulate signals from the 1130 and watch the results to see if it appears to be correct. I can then watch the unload and verify that the virtual cartridge file is still correct. The real testing will take place on the IBM 1130 soon. 

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

DIABLO 31 WITH STANDARD DENSITY IS COMPATIBLE WITH IBM 1130 DISK DRIVE

The Diablo disk drive accepts 2315 style cartridges and was used on a range of minicomputer and microcomputer systems. Evolved from technology licensed from IBM from the design for the 2310 and 1130's 13SD disk drive, most shipments used high density ceramic heads and wrote at twice the rate of the 13SD. 

However, Diablo provided a single density version with a chrome plated metal head identical to those on the 13SD and therefore the drive would compatibly read and write cartridges for an 1130 system. The electrical interface was not compatible, just the bit rate, track width, track spacing and sector pulse specifications that allow the signal on the disk platter to be identical. 

MINE CAME WITH CRASHED HEADS WHEN I PICKED UP MY 1130 SYSTEM

When I picked up my personal IBM 1130 system, it came with a frame with a Diablo 31 single density drive inside, plus a controller to use it with the 1130. In addition, the frame supported a third party line printer. The heads had previously crashed, being all scratched up and unsafe to use again. 

The disk heads on this generation of disk drive technology are available in very limited quantities from sources such as eBay, but only in the high density form that is not compatible with the 1130 cartridges. In more than a decade, with searches set up on eBay and many independent searches, I only found one head of the single density metal type. Therefore my Diablo sat on the shelf waiting for a future acquisition of heads. 

RECENT ARRIVAL OF 2302 DISK ARMS PROVIDES SOURCE OF GOOD HEADS

The heads for the 13SD were the same as the heads used on the 2311 and other 360 disk drives, including a rather rare device, model 2302, that did not have interchangeable media like the 2310, 2311 or 2314. Although the platters were fixed, the heads moved on arms unlike the 2305 drum that had each head fixed in place over its track. 

I was given a set of arms from a 2302, each of which has two disk heads on it. These were identical to the heads I need for the IBM 1130 and they were in good clean condition. The entire arm is completely incompatible, but the head portion mounts onto an arm via two screws. This allows a common head type to be used on 2302, 2310, 2311 as well as Diablo 31 standard density. 

The picture above shows the Diablo 31 disk head on the top and two heads from one arm of the 2302 arms below it. You can see the portion of each arm that is the interchangeable head assembly in the picture below, marked with a red rectangle. The screws that mount this interchangeable head onto the specific arm for a disk drive type are circled in green.

Matching the data read from virtual 2315 image file to the 1130 disk file - more validation of the functionality

DISK FILE FORMATS FOR USE WITH THE VIRTUAL 2315 CARTRIDGE FACILITY

The IBM 1130 Simulator(s) use a version of the simh disk format which stores each word as two bytes in little endian 8086 format. Each sector is 321 words of 16 bits on the 1130, thus 642 bytes in the disk file. These are stored sequentially in the file, sectors 0 to 3 within each of the two heads, within the 203 cylinders. Thus cylinder 1, head 0 sector 0 begins at byte 5,135 in the file. The entire file is 1,042,608 bytes in size.

The Virtual 2315 Cartridge Facility has a header with information about the cartridge followed by the data in big-endian format. The data is sector 0 to 3, within heads 0 to 1, within cylinders 0 to 203. The header is 365 bytes long and the entire file is 1,042,973 bytes in size. Thus, cylinder 1, head 0, sector 0 begins at byte 5500 in this type of file. 

FINDING THE SECTOR DATA FOR CYL 10, HEAD 1, SECTOR 2

Opening the IBM 1130 Simulator format disk file, I calculated the start location for Cylinder 10, Head 1, Sector 2 which is the data I emitted in the debug log when testing the system. This starts at byte 55,212 which is hex 0xD9A0. Below is a hex editor showing the contents of locations 0xD9A0 to 0xDA2D so that we can compare it to the debug log. 

THE DATA MATCHES UP

The only conversion needed when comparing these is to swap the two bytes of each word in the sector, since the file I dumped is in little-endian integer mode while the Virtual 2315 Cartridge Facility implements big-endian integers as does the IBM 1130 hardware. 

The first two words from the dump are 5600 and 2461. The debug log shows these are 0056 and 6124. The final word of the dump is 204C and the final word from the debug log is 4C20. 

Continuing Pico code debug - everything looking good with the Pico code, moving on to load FPGA and test

THE TEST

I set up the logic to pretend that the disk drive goes ready and stays that way for almost two minutes, then drops File Ready status. I instrumented various print statements to watch on the serial terminal (debug console). 

I turned on the unit and waited for it to initialize. I then flipped the Load/Unload switch up to the Load position where I saw the code open the virtual 2315 cartridge file and purportedly download the contents to the FPGA to be stored in the SDRAM chip. I displayed the individual bytes being transferred for a specific sector (cylinder 10, head 1, sector 2). 

After the time limit expired, I expected to see the Ready light go out but the box remain loaded until I flipped the Load/Unload switch down to Unload. At that time, it should rewrite the cartridge image file on SDcard with the contents of SDRAM as pulled up from the FPGA. After that completed it would return to its idle condition until a cartridge image was loaded again. 

ANOMALIES I OBSERVED

First, during the entire time that the image was loaded, the SEEK lamp remained lit. In my design this should only flicker when a seek is requested by the IBM 1130 controller. However, lamp was originally labeled On Cylinder in the RK-05 code; because the FPGA side is still running the original code, that might explain the lamp. Otherwise, the FPGA is continually executing seeks. 

Second, when the time limit expired and the File Ready lamp extinguished, I immediately saw the unit rewriting the cartridge image back to SDcard although the Load/Unload switch remained in the Load position. Something is not working as I expected here.

Third and most serious, the bytes printed for loading SDRAM don't match the bytes printed when retrieving the data from SDRAM. Initially it appeared that the test failed, but I did see that the exact same stream of bytes is returned on every rewrite, even with power cycling between tests. This means that the data is consistently written and read back but somehow I am not displaying it correctly. 

FIXES FOR MOST ANOMALIES AND RETEST

I ignored the Seek lamp since in a few days I will be running with my version of the FPGA code, when this becomes worth chasing.

I found code I inherited from the original RK-05 Emulator code where the Pico treated the Load/Unload switch as being in Unload while in the run state RLST10 - the normal running condition. Instead, I need to see the actual value since my code will drop ready but wait before writing back until the Load/Unload switch is physically manipulated. 

I altered my instrumentation to display the sector at Cylinder 10, Head 1 Sector 2 in a way that should be consistent on both load and unload. 

The retest went much better. I did indeed see the same data consistently, both when downloading it to the FPGA/SDRAM and when uploading it from there as the virtual cartridge was unloaded. The state machine did wait for me to manually flip the Load/Unload switch to Unload, exactly as it should. 

This first log output is the startup of the Virtual 2315 Cartridge Facility, before I switch to Load.

This log output below shows the loading of the virtual cartridge image from when I switch to Load until the process is complete. It includes a dump of the bytes for Cylinder 10, Head 1, Sector 2 as a means of validating the ability to move data into and out of SDRAM. 

Switch toggled from UNLOAD to LOAD
  Drive_Address = 0, RLST1, 1, 0
Card present, microSD card detected
  DISPLAY STATUS: "microSD", "detected"
  Drive_Address = 0, RLST2, 1, 0
filesystem started
  DISPLAY STATUS: "filesystem", "started"
  Drive_Address = 0, RLST4, 1, 0
file_open_read_disk_image
sd_spi_go_low_frequency: Actual frequency: 398089
V2-Version Card
R3/R7: 0x1aa
R3/R7: 0xff8000
R3/R7: 0xc0ff8000
Card Initialized: High Capacity Card
SD card initialized
SDHC/SDXC Card: hc_c_size: 121811
Sectors: 124735488
Capacity:    60906 MB
sd_spi_go_high_frequency: Actual frequency: 12500000
Disk image file is open
  DISPLAY STATUS: "image file", "is open"
  Drive_Address = 0, RLST5, 1, 0
Reading image file header
Reading header from file '2315.dsk'
controller = 1130 internal disk controller
bitRate = 720000
numberOfCylinders = 203
numberOfSectorsPerTrack = 8
numberOfHeads = 2
microsecondsPerSector = 10000
Image file header read successfully
Reading disk image data from file
  DISPLAY STATUS: "Reading", "image data"
  Drive_Address = 0, RLST7, 1, 0
Reading disk data from file '2315.dsk'
  1130 internal disk controller
 cylinders=203, heads=2, sectors=8
  cylindercount = 0
  DISPLAY STATUS: "Read card", " Cyl 0"
  DISPLAY STATUS: "Read card", " Cyl 10"
address for c10 h1 s2 is ac00
loading for sector c10 h1 s2
00
5661 246d 0000 78c0 f34c 207c 5865 807a 2469 22c1
0018 01e0 2990 294c 187c 5890 1c48 2090 1b48 2090
1a48 2090 1948 2090 1848 2090 174c 187a 7090 154c
207a 586c 007c 6f70 1b65 807a 61c1 0018 02e0 0cd0
0175 0000 0070 dd00 00f8 003c 00dc 0030 00fc 0030
0008 0001 ff00 0b7c 0008 0000 0000 0000 0010 10d4
007c 6fd0 fbd4 007c f969 0167 0000 00c3 0048 0473
0118 01e0 ed90 2e4c 207a b7c3 0190 2b4c 207a b7c3
0290 284c 207a b773 01c3 0390 294c 187a b790 214c
207a 94c0 00d0 2170 f590 1c4c 207a 99d0 1c70 f090
184c 207a 89c0 174c 207a 89c3 0490 154c 187a a690
0f48 2070 e3c0 89e8 8a4c 207a b762 324c 007b 4718
00ae 24c5 17ff ef00 1000 0e02 0000 0000 1ee8 0071
01c1 0048 1070 0271 0170 fb94 007c fb48 2070 06c0
ab4c 207c fc71 014c 007a 3ec1 0090 a14c 187a cc70
efc0 a24c 187a d569 9ec0 9d94 007c 624c 187b 4671
ffc1 0048 0870 fc6d 007c 6210 1062 05d6 007c 6872
ff70 fc62 05d6 007b 2072 ff70 fcd4 007d 2a71 01d0
40d4 007d 2bd4 007c 6844 007d 2d94 007b 16d0 224c
187b 714c 087a fa90 1f4c 087b 2bc0 264c 207b 01c0
1790 194c 187b 78c0 204c 207b 08c0 1090 134c 187b
7ec0 1a4c 187b 89c0 0990 0d4c 187b 1390 0b4c 207b
8968 11d0 0f70 d900 0000 3000 09ff dbff d5ff de00
1200 6400 c000 0100 0500 0000 0000 0000 0000 0000
0000 0000 0a00 00a0 0800 00c0 f64c 207b 3868 f6c0
e544 007d 63c0 ee4c 187a ee74 017b d670 b6c0 eda0
ed10 9080 d9d0 e910 10d0 e4c0 e690 db4c 107b 4674
017b 2070 a862 176a e065 807a 61c1 0018 02e4 007a
6984 007a 61d0 0166 0000 00c4 007a 2590 fcd0 0167
0000 0073 01c1 00e0 c2e8 ccd1 00f0 bf4c 047b 6480
bdd1 0071 01c0 c3d1 01c2 00d1 0272 0171 0173 ff70
fa71 016d 007a 254c 007a 58c0 b04c 207b 38c0 b04c
20
  cylindercount = 20
  DISPLAY STATUS: "Read card", " Cyl 20"
  DISPLAY STATUS: "Read card", " Cyl 30"
  cylindercount = 40
  DISPLAY STATUS: "Read card", " Cyl 40"
  DISPLAY STATUS: "Read card", " Cyl 50"
  cylindercount = 60
  DISPLAY STATUS: "Read card", " Cyl 60"
  DISPLAY STATUS: "Read card", " Cyl 70"
  cylindercount = 80
  DISPLAY STATUS: "Read card", " Cyl 80"
  DISPLAY STATUS: "Read card", " Cyl 90"
  cylindercount = 100
  DISPLAY STATUS: "Read card", " Cyl 100"
  DISPLAY STATUS: "Read card", " Cyl 110"
  cylindercount = 120
  DISPLAY STATUS: "Read card", " Cyl 120"
  DISPLAY STATUS: "Read card", " Cyl 130"
  cylindercount = 140
  DISPLAY STATUS: "Read card", " Cyl 140"
  DISPLAY STATUS: "Read card", " Cyl 150"
  cylindercount = 160
  DISPLAY STATUS: "Read card", " Cyl 160"
  DISPLAY STATUS: "Read card", " Cyl 170"
  cylindercount = 180
  DISPLAY STATUS: "Read card", " Cyl 180"
  DISPLAY STATUS: "Read card", " Cyl 190"
  cylindercount = 200
  DISPLAY STATUS: "Read card", " Cyl 200"
Disk image data read successfully
  DISPLAY STATUS: "Image data", "read OK"
  Drive_Address = 0, RLST8, 1, 0
Disk image data read, file closed successfully

The final log output shows the process of rewriting the cartridge data to the virtual cartridge file after I switched to Unload until the write is complete. 

Requested unload

  Drive_Address = 0, RLST11, 0, 0

file_open_write_disk_image

sd_spi_go_low_frequency: Actual frequency: 398089

V2-Version Card

R3/R7: 0x1aa

R3/R7: 0x40ff8000

R3/R7: 0xc0ff8000

Card Initialized: High Capacity Card

SD card initialized

SDHC/SDXC Card: hc_c_size: 121811

Sectors: 124735488

Capacity:    60906 MB

sd_spi_go_high_frequency: Actual frequency: 12500000

finished file open for write, code 0

Disk image file is open

  DISPLAY STATUS: "Image file", "open"

  Drive_Address = 0, RLST12, 0, 0

Writing header to file '2315.dsk'

Disk image header written

  DISPLAY STATUS: "Writing", "image data"

  Drive_Address = 0, RLST13, 0, 0

Writing disk image data to file '2315.dsk':

 cylinders=203, heads=2, sectors=8

  cylindercount = 0

  DISPLAY STATUS: "Write card", "Cyl 0"

  DISPLAY STATUS: "Write card", "Cyl 10"

retrieval address for c10 h1 s2 is ac00

fetching for sector c10 h1 s2

00

5661 246d 0000 78c0 f34c 207c 5865 807a 2469 22c1

0018 01e0 2990 294c 187c 5890 1c48 2090 1b48 2090

1a48 2090 1948 2090 1848 2090 174c 187a 7090 154c

207a 586c 007c 6f70 1b65 807a 61c1 0018 02e0 0cd0

0175 0000 0070 dd00 00f8 003c 00dc 0030 00fc 0030

0008 0001 ff00 0b7c 0008 0000 0000 0000 0010 10d4

007c 6fd0 fbd4 007c f969 0167 0000 00c3 0048 0473

0118 01e0 ed90 2e4c 207a b7c3 0190 2b4c 207a b7c3

0290 284c 207a b773 01c3 0390 294c 187a b790 214c

207a 94c0 00d0 2170 f590 1c4c 207a 99d0 1c70 f090

184c 207a 89c0 174c 207a 89c3 0490 154c 187a a690

0f48 2070 e3c0 89e8 8a4c 207a b762 324c 007b 4718

00ae 24c5 17ff ef00 1000 0e02 0000 0000 1ee8 0071

01c1 0048 1070 0271 0170 fb94 007c fb48 2070 06c0

ab4c 207c fc71 014c 007a 3ec1 0090 a14c 187a cc70

efc0 a24c 187a d569 9ec0 9d94 007c 624c 187b 4671

ffc1 0048 0870 fc6d 007c 6210 1062 05d6 007c 6872

ff70 fc62 05d6 007b 2072 ff70 fcd4 007d 2a71 01d0

40d4 007d 2bd4 007c 6844 007d 2d94 007b 16d0 224c

187b 714c 087a fa90 1f4c 087b 2bc0 264c 207b 01c0

1790 194c 187b 78c0 204c 207b 08c0 1090 134c 187b

7ec0 1a4c 187b 89c0 0990 0d4c 187b 1390 0b4c 207b

8968 11d0 0f70 d900 0000 3000 09ff dbff d5ff de00

1200 6400 c000 0100 0500 0000 0000 0000 0000 0000

0000 0000 0a00 00a0 0800 00c0 f64c 207b 3868 f6c0

e544 007d 63c0 ee4c 187a ee74 017b d670 b6c0 eda0

ed10 9080 d9d0 e910 10d0 e4c0 e690 db4c 107b 4674

017b 2070 a862 176a e065 807a 61c1 0018 02e4 007a

6984 007a 61d0 0166 0000 00c4 007a 2590 fcd0 0167

0000 0073 01c1 00e0 c2e8 ccd1 00f0 bf4c 047b 6480

bdd1 0071 01c0 c3d1 01c2 00d1 0272 0171 0173 ff70

fa71 016d 007a 254c 007a 58c0 b04c 207b 38c0 b04c

20  cylindercount = 20

  DISPLAY STATUS: "Write card", "Cyl 20"

  DISPLAY STATUS: "Write card", "Cyl 30"

  cylindercount = 40

  DISPLAY STATUS: "Write card", "Cyl 40"

  DISPLAY STATUS: "Write card", "Cyl 50"

  cylindercount = 60

  DISPLAY STATUS: "Write card", "Cyl 60"

  DISPLAY STATUS: "Write card", "Cyl 70"

  cylindercount = 80

  DISPLAY STATUS: "Write card", "Cyl 80"

  DISPLAY STATUS: "Write card", "Cyl 90"

  cylindercount = 100

  DISPLAY STATUS: "Write card", "Cyl 100"

  DISPLAY STATUS: "Write card", "Cyl 110"

  cylindercount = 120

  DISPLAY STATUS: "Write card", "Cyl 120"

  DISPLAY STATUS: "Write card", "Cyl 130"

  cylindercount = 140

  DISPLAY STATUS: "Write card", "Cyl 140"

  DISPLAY STATUS: "Write card", "Cyl 150"

  cylindercount = 160

  DISPLAY STATUS: "Write card", "Cyl 160"

  DISPLAY STATUS: "Write card", "Cyl 170"

  cylindercount = 180

  DISPLAY STATUS: "Write card", "Cyl 180"

  DISPLAY STATUS: "Write card", "Cyl 190"

  cylindercount = 200

  DISPLAY STATUS: "Write card", "Cyl 200"

Disk image data written

  Drive_Address = 0, RLST14, 0, 0

Disk image data write, file closed successfully

WAITING FOR MY FPGA PROGRAMMER TO ARRIVE IN THE MAIL

Ebay and other sites are awash with clones from China for the Lattice programmer, but either have the usual delays waiting for overseas transport or they came with a healthy 'scalper' premium from sellers who kept them in the US. Further, others who offered them locally didn't ship particularly promptly as it appears they order from China to fulfill. 

I stepped up and purchased from Lattice directly - at a considerable premium over the clones - which was to be fulfilled by Mouser. I paid for two day UPS shipment when I ordered it on Saturday, but the order wasn't marked as shipped until today (Tuesday) and UPS states it is not yet in their possession.

Thus best case is Thursday delivery but that is only if Mouser hands it over to UPS before their cutoff today, otherwise my 2 day order will arrive Friday or later. If I wasn't eager to debug further with functions that require my code in the FPGA, it wouldn't be worthy of mention. 

I will program the FGPA once I have the gear in hand and run through more checks to verify how it interacts with the Pico code. I am getting much closer to testing with a real hookup to the IBM 1130 and its 13SD internal disk drive. 

Pico code testing of Virtual 2315 Cartridge Facility - started up properly now

SOLVED STARTUP ISSUE DISCOVERED YESTERDAY

The problem from yesterday was caused by residual code I had modified that tried to send an SPI message to the FPGA to clear the fault latch. Since the SPI link and the FPGA were both uninitialized at the time, this hung the Pico. The state upon startup for both FPGA and the Pico is to have the fault clear anyway, so I simply removed the code. 

I may have to make changes to turn on a fault if the cartridge loading in the Pico encounters an error, because the fault latch should block any access to the drive from the IBM 1130. 

WATCHED SYSTEM FULLY INITIALIZE 

From the point that the startup was failing yesterday, it initialized the SPI links, initialized the FPGA and set up the OLED display. The goal was to wait in the idle state, with a phony drive number visible on the OLED screen, waiting for the Load/Unload switch to be moved to the Load position.

It did complete the startup as you can see from the terminal screenshot below, however, some code I changed caused a problem at that point. Whenever the Pico is idle (cartridge not loaded) the original emulator code threw up a large numeral indicating the drive number of this virtual disk drive. I wanted to change it to display a bitmap image of a disk platter or cartridge - limited by the small resolution and lack of color of the installed OLED display. 

LOOPING ERROR MESSAGE TRYING TO LOAD BITMAP IMAGE

My code did not use the SD card code that mounts the card as a VFAT file system and does I/O, instead using code from previous programs running under Linux where the standard file I/O support existed. This led to an error on the attempt to open the file. 

The SD card is opened, mounted and a file searched for only when the Load switch is activated. It is possible for me to do a similar set of actions when the image is going to be displayed in the idle condition, but there is the risk of conflict if the Load switch is closed just as I begin to open the card for the bitmap 

For the time being, I disabled the attempt to throw up the image, leaving the splash screen which displays Virtual 2315 Cartridge Facility. If I want a bitmap to be displayed during idle time, I will have to work on an alternate method such as including the bitmap in the code itself. Further, with the screen only 80 x 40 pixels in black or white, there isn't much meaningful I could show. 

IGNORING THE LOAD SWITCH

The next issue in debugging was that it ignored the load/unload switch being turned to Load. After a quick examination of the code, it was because the FPGA was not returning a 1 bit indicating that the drive was unlocked and ready to receive a (virtual) 2315 cartridge. I did a temporary bypass to continue testing. 

Looping without trying to open cartridge file

LOADED MY 2315 CARTRIDGE IMAGE VIA LOAD SWITCH

The logic when Load is activated will open the SD card reader link, open the VFAT file system, look for the first file with a suffix of .dsk, and open that file. Some checking is done to validate the file, then the logic will read the file and write its disk data over the SPI link to the FPGA in order to get the data into the SDRAM. 

The load began but partway through reading (and downloading to FPGA) an I/O error was encountered. I instrumented the code in order to figure out why this is happening - it looks like something is doubled up so that about halfway through the file we run out of data. 

The instrumentation made it immediately clear that I was reading twice as many sectors per track as exist on the file. This is an artifact of the 2310 drive, which has eight sectors (generating 8 sector pulses) per rotation, but the controller combines them to treat the disk as having four logical sectors. 

For much of the simulation, I need to account for the physical sector count, but not here where I am reading or writing the cartridge data. I divided the parameter in half for the read and write loops and retested. 

Everything loaded properly. I couldn't try writing back the contents of SDRAM because my state machine is smart enough to know that if you load a cartridge but the disk drive never goes ready, then there is no need to write it back since nothing could have changed. This is the same path taken if the Read Only state is toggled on by the front panel switch at the time the load/unload switch is put back to Unload - the image on SD card is not updated. 

TRYING TO FORCE A WRITE-BACK WHEN I UNLOAD

I made a temporary change to report the drive went ready, so that the state machine moved to the normal running state and from there an unload would lead to overwriting the file on SD card with the SDRAM contents.

When I turn the load/unload switch to Unload, it didn't unload. The logic requires that the disk drive be switched off, with File Ready turning off, before we unmount the data. This ensures that the 1130 does not do any further writing to the drive. 

I might be able to do some more sophisticated patching to force the unloading to occur - somehow change what I report for ready status depending on where we are in the overall state machine - but it isn't a single line type of change. 

The potential value of achieving an unload where we update the cartridge image on the SD card is that I could compare the two. If they are identical, then the data was preserved properly in SDRAM and however we are addressing it from the Pico, we get the same data we put in each location.

I am close to the end of the workday so this is something I will mull over until tomorrow.