Running IBM disk diagnostic 309 against the Virtual 2315 Cartridge Facility - part 7

RESTARTING THE TESTING IN REAL MODE

With the V2315CF set to real mode, the 13SD disk drive inside the IBM 1130 is powered on and participates in the disk activity along with the V2315CF. With the cartridge loaded into the V2315CF and any old physical 2315 cartridge loaded into the 13SD, the motor power switch is flipped on to spin up the drive. 

Once the disk drive finished its 90 second purge of dust from within the spinning drive, the File Ready lamp on the 1130 main console lit up as well as the RDY light on the V2315CF box. This made the disk ready to be accessed by the diagnostic.

Sectors on the 2315 cartridge are usually 321 words long, with the first word holding the relative sector number as its value. Thus cylinder 0 has relative numbers 0 to 7, cylinder 1 starts with relative number 8, and they run up to 1616-1623 on cylinder 202. 

The diagnostic refers to word counts, but they mean the count IN ADDITION to the first word with the relative block number. This way of counting words matches how the Disk Monitor System disk routines read sectors - they read 321 words, check the relative block number in the first word, and then return 320 words to the calling program. 

The diagnostic runs through twelve routines sequentially, with a thirteenth that can be specifically triggered if desired. As the diagnostic starts, it first seeks in reverse to reach the Home (0) cylinder. It watches the sector numbers to verify that the four numbers arrive in sequence, e.g 0, 1, 2 then 3. Finally, it seeks to cylinder 199 and reads a specific word to check for a 'magic' value that marks the 2315 cartridge as suitable for use by customer engineers doing testing.  

Routine 1 is executed twenty times. It moves the arm to cylinder 0 then reads sectors 0 to 7 in order with a sequence of word counts. It starts with 1 word, then reads the eight with 2 words, 4 words, 8 words and doubling each time until it reads 256 words. Next 320 words are read from the eight sectors and the data on sector 7 is verified to match the known contents. Again, this was really 2, 3, 5, 9 . . . 257 and then 321 words. 

Routine 2 executes a pattern of seeks. First it moves forward from cylinder 0 to cylinder 202, moving 2 cylinders forward then 1 cylinder in reverse. At each cylinder, it reads all eight sectors and checks word 1 which has the relative sector number as its contents. On the CE cartridge, cylinders 90 to 110 are protected as they have a special pre-recorded pattern used to align the disk heads. Thus, while moving forward in the +2/-1 pattern it skips direction from 89 to 111. The routine then does the same thing in reverse from cylinder 202 back to Home, stepping 2 cylinders back then 1 forward. 

Routine 3 does 100 random seeks. If the random number is between 90 and 110 it gets another random value for the seek. After each seek it reads and verifies all eight sectors. 

Routine 4 will read cylinder 1 sector 0 fifty times, checking each time that the data consists of the pattern x1313 in each word. 

Routine 5 will read cylinder 201 sector 6 fifty time, checking each time that the data consists of the pattern xe5e5 in every word.

Routine 6 does fifty writes of 320 words, each set to 1313, with the relative sector number as the preceding word. These are written to cylinder 2, sector 0. It reads back and validates the contents each time.

Routine 7 is similar to routine 6, but uses cylinder 2 sector 6 as its location and the data value used is e5e5. It does fifty writes with a readback and comparison after each write.

Routine 8 performs a read check. When requesting to read a sector, there is a bit in the IOCC that tells the controller to read the sector, validate the error checking bits on the data, but not to transfer any into memory. The routine verifies that the read did not receive a data error condition and also that the contents of core memory were not changed by the read check operation. 

Routine 9 performs fifty writes to cylinder 0 sector 2 with random data values in the 320 words, reading back and verifying the contents match what was written. 

Routine 10 performs fifty writes to cylinder 202, sector 6 with 320 random words, which are read back and verified. 

Routine 11 will write 320 words of 1313 to cylinder 2, sector 0. It then writes a single word at the same location. Reading back all 321 words of the sector should return the relative block number 16 plus 320 words of 0000. 

Routine 12 will attempt to write 400 words to cylinder 2, sector 0 (actually 401 with the relative block number first). This is too much data to fit within a sector on disk, so the write should be terminated with a data error condition. The routine will do this 50 times, each time reading back the sector to see how many words fit before the write was terminated. The routine will print the average number of words from across those fifty attempts. 

Routine 13 is optional and must be started explicitly with a command to the diagnostic. It does a series of seeks of different lengths - 1, 2, 4, 8 16, 32, 64, 128 and 200 - to record the time it takes for that to complete. For each seek distance, it seeks forward from Home and back to Home ten times, averaging the time that the seek of that size takes to complete. At the end of the ten seeks it prints the average, minimum and maximum time. 

TEST RUNNING ALONG WELL, GOT INTO ROUTINE 3 BUT TYPEWRITER FAILED THEN

I watched the diagnostic proceed through routines 0, 1 and 2 with no errors detected. It was performing the 100 random seeks of routine 3 when the belt from the motor of the console printer (typewriter) snapped. The diagnostic prints various status messages on the typewriter and will not move forward until they are completed. 

I did see two error messages printed. In each case, the diagnostic attempted another seek to get to the intended target and reported success. Thus there were two intermittent seek errors out of somewhere between sixty and 100 that had been attempted. I don't know exactly where we got because the belt on the typewriter snapped at this point. 

I was able to manually turn the typewriter mechanism, so that it reported completion of typing and carrier movement commands. However, when hand cranking the typeball doesn't achieve enough momentum to impress a character on the paper so I don't know what it was typing. Eventually it stalled as some command to the typewriter didn't see a response signal. 

A seek attempted from cylinder 69 to cylinder 1 found that it had actually reached cylinder 0. The Home status bit was on in the device word as well as the relative block number in the sector ranging between 0 and 7. 

The other printed error was a seek attempted from 130 to 19, where the relative block number read proved it had stopped at 21 instead of 19. As with the first error, the diagnostic rectified the situation - with a seek to get to 21 successfully. 

VIDEO OF ROUTINE TWO AND PART OF ROUTINE THREE

You can watch a video here of the disk arm moving from 0 to 202, then from 202 to 0, as part of routine 2. This includes the forward 2, back 1 pattern as well as the jump between 90 and 110. The RD lamp on the V2315CF box is shown briefly to let you see that the diagnostic is reading sectors at every cylinder it reaches. 

It moved on to routine 3 which performs 100 seeks of random distances and directions. Sometime during this routine the belt on the typewriter snapped and stopped further testing.

YET ANOTHER ISSUE CROPS UP TO SLOW DOWN MY FINAL TESTING OF V2315CF

This is the latest in a set of annoyances that have gotten between me and the end of a testing campaign for the V2315CF. I had hoped to finish testing with enough time to get up to Maryland and install one in the 1130 at System Source Museum before my knee replacement surgery. However, with the surgery slated for April 21 and the stream of unexpected snags - core memory sense wire breaks, Raspberry Pi PICO toolchain balkiness, and finally the typewriter issue - I will have to delay it until I have recovered enough to travel - a couple of months probably. 

Replacing a broken belt requires partial disassembly of the operational and print shafts, then a slew of adjustments to get things back in shape after I install the new belt. The typewriter was not performing well anyhow - the program driven space function wasn't working and it sometimes failed to perform carrier returns or tabs properly - so this needs some careful lubrication and adjustment anyway. 

The stale lubricants from many decades ago partially solidified in the time while I was working on other aspects of the restoration, such as core memory stack repairs, peripheral control logic testing, etc. This is best handled by removing the console printer from the machine and working with it on the bench. That alone will probably take up the ten days I have left before surgery. 

Debugging work on the seek issue with Virtual 2315 Cartridge Facility in real mode

NEED TO NARROW DOWN POSSIBLE DEFECT LOCATIONS

It is possible that something in the signal returning from the 2310 (13SD) disk drive inside the IBM 1130 is inducing the errors. The drive modulates the signal +Access Ready to indicate when it can accept seek commands, dropping the signal to low for part of the actual arm movement. If this behaves weirdly, it might cause the 1130 disk controller logic to malfunction. 

The seek is begun when an XIO instruction is issued pointing to an IOCC with a type of Control for the unit address of the internal disk drive. Bit 13 of the IOCC second word determines the direction of the arm movement, with a 0 moving the arm towards higher cylinder numbers. The first word of the IOCC is the count of the number of cylinders to move. From when the XIO instruction is received until the end of the entire seek operation, -Access Busy is asserted by the 1130 disk controller logic. 

The disk controller logic issues +Access Go to the 2310 drive asking it to move the arm in the direction we set from bit 13 and for a step size of either 1 or 2 cylinders - 10 or 20 mils. The drive begins the movement. It drops +Access Ready about 5ms after it begins and keeps it low until a total of 15ms has elapsed. 

When +Access Ready becomes low, the +Access Go signal is removed. When +Access Ready again goes high at the end of the step, if the Word Count (WC) register is not all ones, +Access Go is again asserted to make the next step.

The WC register is loaded with the 1s complement of the seek count from the IOCC. It is incremented as each +Access Go is raised, increasing by 2 in all cases except the first step for an odd seek count. Bit 15 of the WC register is the step size signal, choosing either 10mil or 20mil. If the low order bit of the seek count is 1, Bit 15 is off but it is forced to 1 by the next assertion of +Access Go so that all subsequent steps are 20mil. 

When the WC register gets to all ones, the arm has been moved the number of cylinders requested by the IOCC. This blocks the assertion of +Access Go thus no more steps are taken. As +Access Ready goes high after the final step, it turns off  -Access Busy and turns on Operation Complete. 

This condition requests interrupt level 2 and when the software subsequently senses the device status (XIO instruction for disk unit number with type of Sense and reset bit turned on), Operation Complete is presented to the 1130 and simultaneously reset in the disk controller logic. Operation Complete also resets the WC and other registers since the seek operation is over. 

The WC register logic is where the value is incremented, where the step size is determined and what tells the logic that our seek operation is complete. All of this is implemented on a single SLT card, 6220, which also handles some other disk related functions. Thus my first suspect for the defect is within the 6220 card, but if the +Access Ready signal is wonky that might induce misbehavior inside the 1130 disk controller logic, so the disk drive is an alternate suspect. 

ADDING CHAIN OF FF TO AVOID METASTABILITY ON INCOMING SIGNALS

I had previously assumed that the pure multiplexers used to assign signals coming in from the 1130 or 2310 to outputs wouldn't suffer from metastability problems, but these are external signals that could be changing unrelated to the clock edges in the FPGA. Even though the multiplexer controls are switched before startup and not dynamically, if IceCube2 somehow introduces any clocked element in the implementation an issue could arise.

I set up chains of four flipflops per incoming signal in the switching module bus_outputs.v and passed along the output of the chain to the next destination. This will delay the signal by 50 nanoseconds but that shouldn't cause any problems. 

OBSERVATIONS WITH NEW VERSION OF FPGA BITSTREAM

I loaded the new bitstream that implemented the metastability protections for incoming signals into both Virtual 2315 Cartridge Facility (V2315CF) main boxes. I used the scope to watch various signals coming from and going to the 2310 disk drive and/or the IBM 1130 disk controller logic. I did this for a simple seek of 1 cylinder forward from home.

I can see that bit 15 of the WC is dropping as soon as  +Access Ready goes low not at the end of the seek operation. This is why my code is getting fouled up - it sees a changing or changed value, not the one that would command the 10 mil step. 

The purple trace is bit 15 - when low, it requests a 10 mil step. The yellow trace is +Access Go triggering the seek. Green is +Access Ready, which we see dropping just as bit 15 flips to 1. Bit 15 is also called -10 20 Mil to reflect its role as the step size. 

RESOLUTION

I changed the design so that it holds the value of the step size (and direction of motion) right at the moment that + Access Go is asserted, so that it uses the saved value when +Access Ready goes low and then returns to high at the end of the movement. After loading the new bitstream into the FGPA, the tests worked well. I can begin to run the disk function diagnostic (309). 

Found and corrected reason that magic smoke was released

PUFF OF SMOKE FROM V2315CF MAIN UNIT WHEN FIRST CONNECTED TO IBM 1130

The Virtual 2315 Cartridge Facility (V2315CF) main unit was the second one I built. I had swapped it onto this 1130 system to check an unrelated issue. However, as I powered up the computer, white smoke escaped from a chip inside. 

ERROR ON 2310 INTERFACE BOARD HOOKED +12V TO AN OTPUT OF THE V2315CF

The V2315CF outputs a signal for when it is in virtual mode - when the 2310 (13SD) disk drive in the 1130 will not be spinning - to control the Unlock lamp on the 1130 console. This output is wired to the gate of a MOSFET which can light the lamp. 

Unlock is a signal generated by the 2310 disk when the platter is not rotating, allowing the operator to open a handle for sliding the 2315 disk cartridge into or out of the disk drive. It goes off once the drive begins spinning up. 

When we are in the more usual real mode of operation, spinning the 2310 disk as part of the operation of V2315CF, the disk drive itself is controlling unlock by grounding a wire coming from the drive to the 2310 Interface Board. A relay on the board just connects this wire to the outgoing wire from the board to the Unlock lamp itself on the 1130 console. 

If in virtual mode, the V2315CF lights Unlock when a virtual cartridge is not loaded, but extinguishes it upon loading. The relay connects the Unlock lamp to the MOSFET on the 2310 Interface Board, which is controlled by the signal coming from the V2315CF. 

Somehow I had the +12V input to the 2310 Interface Board connected to the output signal wire from the V2315CF. The output is driven by a 75451 open collector buffer chip, grounding the line to the MOSFET gate or letting it float up to the 3.3V that the terminator resistors supply. However, this chip was not designed to have +12V fed directly through the open collector output to ground. The result was the puff of smoke. 

The first V2315CF unit I had been using also had been subjected to +12V through the chip. It failed more quietly so I wasn't aware. I would not have tested the Unlock lamp function in virtual mode until later, so I didn't catch this.

IMMEDIATE FIX APPLIED

I cut traces on the current 2310 Interface Boards to sever the MOSFET gate and V2315CF output line from the +12V supply. A bodge wire was added to complete the connectivity as designed. This allows me to use the current version of the PCB until a new version arrives from the fab. 

I also removed the dead chips from both V2315CF units. These are only driving the Unlock lamp operation in virtual mode, so they aren't needed just yet. 

ORDERED REPLACEMENT 75451 CHIPS

I placed an order with DigiKey to have a stock of the 75451 chips used for outputs, as well as some 74LVC244 level shifters that are used for inputs. I will use a couple to repair the damaged V2315CF units.

REDESIGNED THE 2310 INTERFACE BOARD AND SENT TO FAB

I corrected the error on the 2310 Interface Board. In addition, I beefed up the traces that will drive the Unlock lamp just to minimize heating on the PCB for long periods when the real or virtual drive is unlocked. 

Mystery smoke when testing second V2315CF main unit

TWO UNITS BUILT FOR TO MUSEUM MACHINES

I had constructed a Virtual 2315 Cartridge Facility (V2315CF) for the IBM 1130 I am currently restoring on behalf of the Vintage Computer Federation's InfoAge museum. I had previously restored an 1130 for the System Source Museum which I plan to upgrade with a V2315CF as soon as I finalize the testing.

NAGGING ISSUE WHERE LOGGING IS NOT WORKING

The design of George Wiley's RK-05 Emulator upon which I based the V2315CF included a capability to log read, write and seeks over the debugging serial link. That is, by typing an L into the serial terminal connected to a V2315CF, it should print a line for each seek, read or write performed. It sets up an interrupt handler when the command is processed. 

The FPGA has an output line which has a pulse emitted by my Verilog code whenever I am beginning one of those three actions. This line is connected to an input pin on the PICO whose code sets that pin up for interrupt detection upon any leading edge. This should enter a handler to fetch details on the operation from the FPGA (over the SPI link that bridges the two) and then print a line to the debug console. 

This had been working in earlier iterations of my design, but at some point it stopped working. Among the events which had occurred to the unit was an inadvertent connection of +12V to a Pico input pin, frying the processor, as well as my code adding another input pin to receive a signal when the IBM 1130 power supply drops out. I have replaced the PICO hardware. 

This latter signal triggers my code to drop File Ready on the disk and unload the potentially changed contents from the RAM chip on V2315CF into a file on the microSD card which holds the virtual cartridge image. This should have nothing to do with the logging scheme. However, there may be some subtlety in how the Raspberry Pi PICO software development kit handles the interrupts or input pins that led to the cessation of the logged action print lines.

SWAP OF V2315CF MAIN BOXES

Just in case a damaged component on the V2315CF main unit has caused the connection between FGPA and PICO to not work, blocking the pulse that triggers the interrupt, I removed the box I had been working with and connected the second V2315CF box I had built. These have had power applied many times as I update the FPGA bitstream with design changes.

MAGIC SMOKE RELEASE TO MY SURPRISE

When I powered up the IBM 1130 with the second V2315CF box installed, I saw white smoke puff away from the inside of that box. I immediately powered off the 1130 system and removed the box for inspection. 

At this point I don't understand what caused this to occur. The wiring to the 1130 was unchanged other than plugging the new unit in place of the first one. Looking physically at the unit I see indications that chip U20 was what released the smoke. 

Signal line T2 on the cable is BUS_UNLOCKED_LIGHT_H which should drive the MOSFET that lights the Unlock lamp on the 1130 main console when the V2315CF is in virtual mode. The line on the cable is connected to the gate of the MOSFET below to pull it to ground when the signal is driven by U20. 

As you can see the design is will work since the 2310 Interface Board has this pulled down to ground when not activated, and U20 works by either pulling it to ground or leaving it float. The terminator board has resistors to +5 and to ground, thus this line will float to 3.3V when U20 is not conducting, enough to fire the MOSFET.  In real mode, the MOSFET is bypassed by a relay and the lamp is hooked directly to the signal from the 2310 (13SD) disk drive unlock switch instead of to the MOSFET. 

In any case, I don't see any way this should short out U20 to cause it to fail. I will need to look for solder bridges or other shorts that are exclusive to the second V2315CF main unit and not the first one. That U20 chip did not fail in the first box I had connected as far as I know, although it could have failed silently without smoke I guess. I will have to investigate this, find the cause, fix it and replace at least U20 to restore the second box to functionality. 

When I power it up unattached to the IBM 1130 it does come up with its logo on the OLED screen on the box and appear to be working okay. I know that U20 is shot but that only drives the one signal for the Unlock lamp in virtual mode thus it can be replaced when the part comes while still being tested today. 

Running IBM disk diagnostic 309 against the Virtual 2315 Cartridge Facility - part 6

NEW PICO SOFTWARE SHOWS CYLINDER SEEN IN V2315CF

The Virtual 2315 Cartridge Facility (V2315CF) uses a Raspberry Pi PICO as the user interface processor, also handling reading and writing virtual cartridge images on microSD cards. Having just recovered my ability to compile new code for the PICO, I set it up with a periodic status message showing the current cylinder as tracked by the V2315CF.

HAND TRIGGERED VARIOUS SEEK DISTANCES AND OBSERVED CAREFULLY

As before, I had set up code to seek forward, seek in reverse, read sector 0 of the current cylinder, and display the device status. I would look at the disk actuator gauge on the 2310 disk drive and compare it to where I intended to move the arm. In addition I could see where the V2315CF thought the arm had reached. 

ANOMOLOUS RESULTS

I started moving the arm in small steps, trying single, double, triple and bigger steps. The first very odd event was when I was directing for a eight cylinder forward seek. The arm zoomed all the way to the end, cylinder 202. That was observed on the 2310 disk arm as well as the V2315CF reported cylinder position. 

I did a series of seeks, each time pulling the arm back to the home cylinder (0) before the next one. I began with zero - which of course did not try to move the arm at all, then moved 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 and 12 cylinders from home. Some worked correctly but others left the arm at the wrong position. 

The incorrect results were:

• Seek of 1 ended at cylinder 2 instead of 1
• Seek of 2 ended at cylinder 1 rather than 2
• Seek of 3 ended at cylinder 1 rather than 3
• Seek of 5 ended at 2 instead of 5
• Seek of 7 ended at 4 instead of 7
• Seek of 9 ended at 6 instead of 9
• Seek of 11 ended at 8 rather than 11
• Seeks of 4, 6, 8, 10 and 12 produced the correct position of the arm. 

SUSPICION IS POINTED AT THE 1130 DISK CONTROLLER ELECTRONICS

Except for the case of a seek of 2 cylinders, every failure involved a seek of an odd number of cylinders. The disk controller logic will issue a seek of 10 mils (single cylinder) then issue 20 mil seeks while decrementing the count until the total movement has been achieved. 

The controller loads the Word Count (WC) register in the logic with the complement of the distance requested by the seek instruction. In other words, a seek of 1 - b00000001 in binary - will load the WC with b11111110 as its initial value. Each time a seek is performed, the WC is bumped and the seek ends when the WC is all ones.  

I suspect there is a flaw in the logic of the WC or the circuits bumping it, producing the wrong counts. All but the lowest two bits of the WC are implemented on a single SLT card, type 3793. I swapped the card with another 3793 from the machine but the failure didn't go away. 

I am looking at the first two bits which includes the special logic for handling odd counts. That circuitry is contained on card type 6220 held in A gate, C1 compartment at slot M6. 

The value is loaded into the WC by the excerpt below - when the -load word count sp signal goes low (asserted as a pulse when it is time to load), the WC is set to 1 if the corresponding bit of the seek count is 0. 

Each time a seek is commanded, the signal +access drive is dropped by the 2310 disk drive during the movement and brought back to logic high at the end. When that signal drops and the signal -drive busy is asserted low, it sets Bit 15 of WC to 1. 

The portion below is how the WC is incremented. Primarily this occurs when -incr word count is asserted low, generating pulses that change the two flipflops for bits 14 and 15. 

IBM flipflops are set or reset by pulses arriving at the top or bottom left side; they don't operate based on the level of the input only by a falling edge. They also misbehave if they receive a set input while already set, or if they receive a reset input when not set. Some of the circuitry in the diagram above blocks those conditions, so that a set pulse is only passed on if the flipflop was in the unset state. 

In the diagram above, I stripped out that detail to make it a bit easier to follow the logic. Since the flipflop is controlled by pulses, the gates in front of the inputs produce a pulse when their trigger line has a falling edge. 

Since the output of Bit 15 is the signal +10 -20 mil that steps only one cylinder when low, every seek after the first will be for two cylinders (20 mils).  If the seek count from the seek instruction is odd, then bit 15 is left off initially. In the middle of each seek step, it sets WC bit 15 to 1 if it wasn't already set. Thus we get only the first seek step at 10 mils before the flipflop is turned on and stays on. 

The -Incr Word Count falling edge also triggers the change of Bit 14. If B14 was on, B14 is reset. If B14 was off, B14 is set on. In other words, it toggles the state of B14. The changes in B14 flow to the remaining WC register, bits 7 to 13, counting up by two 

However, if you look closely you will see that B14 is also toggled if B15 flips off. This logic is irrelevant in this circuit since B15 is only turned off during the start of a seek instruction, only if the seek count was odd, and then is turned on permanently for the remainder of the seek instruction execution. The WC is also used during read and write when it counts words from a sector; that always increments WC by 1 using this circuitry. 

NOT SURE OF EXACT FAILURE MECHANISM YET BUT HAVE A THEORY

The results from my testing, with a seek of 2 failing and every other failure being an odd count, hint that the issue is here somewhere close to B14 but also involving B15. A seek request of seven should load the WC with b11111000 which sets B14 and B15 to zero initially. The 0 value for B15 would make the first seek move just 10 mils, with B15 set to 1 by the seek operation itself. 

After that first single cylinder move, the -incr word count signal should toggle B14 to 1, resulting in WC being b11111011 to drive the next seek for 20 mils. Another -incr word count signal toggles B14 off, that causes B13 to toggle on, and we have the value b11111101 in WC. A third -incr word count signal toggles B14 again, with the WC now b11111111 so after this seek, the seek instruction is complete. 

We should have moved 1, then 2, then 2, then 2 for a total of seven cylinders. Instead the result was just four cylinders moved. This may be due to the defect always signaling the drive to move 10 mils. The four seek steps thus only move to 4 not to 7. 

This could occur if the gate fails that should turn on B15 when +Access Drive falls and -Drive Busy is low. When we set B15 to 0, it would never be incremented and our seek wouldn't stop - WC is never all ones. That is not what is happening, so the issue is not in the gate that should turn on B15. 

Any even count starts B15 out as 1, thus every seek step is 20 mils and the results look good. We only have problems if B15 starts out as 0. We might have a failure in the gates that reset B15, where they should be blocked due to B15 being on but they reset it. The timing may be such that the drive sees the 10 mil seek step but the bit flips on long enough for the seek instruction to see all ones in WC in order to stop. 

Found a solution to building the code for the PICO processor - Google Colab

BATTLING VARIOUS BRICK WALLS WITH VISUAL CODE ON WINDOWS

I put in too many hours trying to figure out why I couldn't simply build the executable using the same files that had worked before on the Raspberry Pi OS. I kept getting complaints about build.ninja files, errors with CMake and other chases through a sea of barely helpful web hits and truly not useful documentation from RPi. 

As is often the case, the documentation works perfectly to build stupid simple programs to blink an LED or display Hello World, but doesn't cover all the details for a complex program with multiple source files, included libraries and the like. 

RASPBERRY PI ENVIRONMENT STOPPED WORKING FOR PICO BUILD

I had originally set up the Raspbian Linux on a RPi 5 to build PICO executables, using the documentation from RPi. This had worked very well indeed. However, this RPi was modified extensively for the Space Force Museum display project and issuing 'make' no longer produced the proper results. I needed to keep the display project version of the Pi around so I couldn't change it too significantly. 

FOUND SOME POINTERS TO USING GOOGLE COLAB TO INSTALL THE PI PICO TOOLS

Pete Warden produced a YouTube video about using Google's Colab and a link to fire up Colab and load a Jupityr notebook page to use it for PICO code production. This is the link if you are interested - Link to notebook page to run 

The page is set up to load the various Raspberry Pi PICO code examples and to compile the simple blink program, but it is easy to upload your source code and then issue the make command for your own project  - as I did. 

Firing up a colab gave me a running Linux image on my web browser. I could then pull down the tool chain for the Raspberry Pi PICO build system from github and install everything in the online image. I uploaded my source and related files that would not compile on Windows VS Code or on the modified Rasbian system. They built perfectly, producing the object files I needed to load onto the PICO processor and resume my testing. 

Running IBM disk diagnostic 309 against the Virtual 2315 Cartridge Facility - part 5

STILL INVESTIGATING FAILURE TO STAY SYNCED DURING SEEK OPERATIONS

During my testing of the Virtual 2315 Cartridge Facility (V2315CF) I discovered errors in operation when running the disk function diagnostic (309) while operating in real mode. That is when the 2310 (13SD) internal disk drive in the IBM 1130 is spinning a physical cartridge to provide some of the signals for operation while the V2315CF provides the read and write data streams from a virtual 2315 cartridge. 

The issue I experienced was mismatch between the cylinder that the software expected the disk arm to have reached and the data being read. Each sector on a 2315 disk cartridge holds up to 321 words, with the first word traditionally holding the relative sector number. Each cylinder has eight sectors, thus a cartridge with 203 cylinders holds relative sectors 0 to 1623. The software read the first word of a sector and found that it was NOT for the cylinder expected.

I set up some direct instructions on the 1130 to seek specific amounts, as well as instructions to read one word of a sector and to check the status of the disk drive. I used that to try various movements of the disk arm. On the IBM 1130, a seek (arm movement) moves a relative number of cylinders and a direction, either forward to higher cylinders or reverse back towards 0. 

I found that the data returned by the read would sometimes match where I had asked to move the arm and sometimes not match. The disk drive provides a signal, Home, that indicate that the arm is at cylinder 0. When it is at 0, reverse movements are not attempted. However, if the V2315CF is at some higher cylinder, there is no way to back up because reverse seeks won't take place. 

One example was a long seek, from the Home cylinder moving 202 forward, then moving 201 backwards. That should leave the arm at cylinder 1, with Home not turned on, and the relative sector number of the sector read would be 8. However, the Home switch was on indicating that the disk drive movement wasn't correct and the data read was off by multiple cylinders. 

I made changes to force the cylinder used by V2315CF to zero if the Home switch of the drive is on, but that doesn't keep the V2315CF and 2310 in sync for other movements. I also made changes to track the interlocked signals between the 2310 and the IBM 1130 disk controller logic, but I still experienced mismatches. 

REPORTING CURRENT CYLINDER ON DEBUG OUTPUT OF V2315CF

The V2315CF sends debug information out on a USB serial link, which I modified so that periodically it reports the current cylinder that it believes the arm has reached. That will help me compare what my instructions executed on the IBM 1130 produce in terms of V2315CF cylinder location. This required a new version of the PICO software. See my prior post - the toolchain is on strike so this is pending.

WATCHING THE 2310 ACTUATOR POSITION DIRECTLY

With the top cover removed from the 2310 disk drive, I can view the scale on the side of the disk actuator which points to the current cylinder location of the arm. That will help me compare what the instructions executed on the 1130 intended with the achieved location of the arm. I need to know what is misbehaving - 2310, 1130 disk controller logic, V2315CF or some combination - before I can formulate a correction plan. 

RESULTS OF THE OBSERVED MOVEMENTS VERSUS MY INTENTIONS

The actual movement of the disk arm exactly matched the positions I intended. Given the 2310 and the IBM 1130 were in sync, I did a few more tweaks to the FPGA logic for the V2315CF. I finally got code that seemed to always stay in sync and be correct. I tried many variations of seeks followed by reads which were all correct. 

I hand entered a program to repeatedly seek in and out by a configured number of cylinders, letting the disk move the arm as fast as it could back and forth. This seemed to also stay in sync with the V2315CF. This raised my hopes that the problems were solved.

I LOADED THE 309 DIAGNOSTIC AND RAN IT AGAIN - STILL ISSUES

In spite of the correct operation for all the seek patterns I threw at the system, the diagnostic still failed the seek testing. The diagnostic does a seek from what it records as its current position to a target cylinder, then reads a sector from that location to check the relative sector number in word 1. 

The first error reported that in an attempt to seek from cylinder 0 to cylinder 199, the sector read proved the arm was at cylinder 196. The code then kept trying to get to 199, with a succession of failures. From 196, where it believed it was to 199, but the sector showed it reached 200. From 200 back one cylinder to 199 but the sector read showed it was at 198. From 198 up one cylinder to get to 199 but the sector proved it was at 200. 

I am particularly confused by the pattern that occurs after the first seek comes up short. Once it is within one cylinder and overshooting, the V2315CF would have to be doing something really bizarre to act that way. There is a signal line 10-20-mil that controls whether the drive does a single or a double step for each seek. The 1130 controller logic will attempt a 10 mil step if the count to move is odd, followed by 20 mil steps until the total movement count is achieved. 

With the one cylinder movements, the only seek will be a 10 mil step, yet the V2315CF seems to be seeing these as 20 mil steps. The initial long seek seems to be counted as an even number of steps, yet the program should have requested 199 steps thus generating an initial 10 mil step followed by 99 steps of 20 mil. For it to believe it got to 196 means it missed one 10 mil and one 20 mil step entirely but saw 98 correctly. 

The diagnostic 309 works correctly on an IBM 1130 simulator thus it is unlikely that the code is incorrect when running on the real machine. I am assuming that the 2310 disk is going to the intended cylinder properly, but I can't verify it while the diagnostic is trying to move the arm to 199 because the action is too quick for me to spot.