Testing my new seek logic for the Virtual 2315 Cartridge Facility - part 1

PROGRAMMED THE INITIALIZATION MEMORY FOR THE FPGA

Once I had the license in hand for IceCube2 I could synthesize and generate the bitstream for the FPGA device used in the Virtual 2315 Cartridge Facility (V2315CF) main unit. I grabbed the Lattice HA-USBN-2A programming cable and plugged it into the V2315CF, then powered up the V2315CF. fired up the Diamond application and used it to update the FPGA to use my latest logic.

PRIOR PROBLEM WAS HAVING THE V2315CF AND 1130 DISK DRIVE GET OUT OF SYNC

The V2315CF should be shadowing the seek operation as the IBM 1130 system disk controller commands the internal 13SD disk drive to move the arm to various cylinders. After a sequence of moves, the cylinder where the disk arm stopped was sometimes slightly different from the cylinder that the V2315CF believed we had reached. We fed data from the wrong cylinder of the virtual 2315 cartridge, which the diagnostic program flagged as a failure to seek properly. 

My new logic should be more robust and hopefully track the seeks exactly The goal is to have the seek test of the IBM disk diagnostic pass with no errors. All the other functions such as reading and writing were proven to work correctly, thus this is the last issue before the V2315CF has passed its testing.

RUNNING THE DISK DIAGNOSTIC AGAINST THE V2315CF

I set up the V2315CF for real mode, which is where it moves the internal disk drive arm and determines its sector position based on the disk drive generated signals, but feeds data from the cartridge image we loaded into the V2315CF rather than the read/write heads of the 13SD disk drive. I inserted a virtual cartridge into the box, put a real 2315 cartridge into the 13SD drive, and powered up the system. 

I loaded the virtual cartridge image and let the disk drive spin up and become ready. File Ready light turned on at the 1130 console, indicating it was ready to be accessed. I used the memory loader function I added to the IBM 1130 to load the 1130 memory with the disk diagnostic program, then started its execution. 

RESULTS OF SEEK TESTING

The diagnostic reported that this was not a special CE test cartridge - however the same image runs properly on the 1130 simulator. This may be a problem with how I am starting the diagnostic or it could represent some issue in the V2315CF. I brought the virtual disk image home to check it on the simulator and found that it was good. That means I have some debugging to do on the machine.

One possibility is that my seek routine is not working properly yet, since the indication that we have a special cartridge is a particular word pattern 0xCEDC that is read from cylinder 199, head 1, sector 2. If I am not correctly positioned to that cylinder, the data being read would not contain that magic pattern. 

Whiling away the hours waiting for Visual Studio to install

CLEAN INSTALL OF VS AND PICO SDK - AN EXERCISE IN PATIENCE

I need a functional development environment for the Raspberry Pi PICO but after the debacle with AI misdiagnosing problems and directing changes to my prior install, I had to uninstall and start over. AI had me change the terminal type - command shell, power shell, etc - multiple times which impacts how each new suggestion works or doesn't work when typed into the terminal. It had me override so many things that I had no confidence left; it also would not configure to build anything. 

The MS installer was asked to set up C++, Python and the toolchains for devices like the PICO. This resulted in an installation of some 513 packages. I have 1G internet but the installer is averaging about 300K per second which means that 3GB of download is going to take a v-e-r-y long time. However, the reality is much slower than the reported rates. I am guessing that there is a big lag in starting each new package, because this has been running for a couple of hours and is only about 40% done. 

I then will download and install the PICO SDK which should be a much faster operation. That should allow me to build the example code from the carlk3 github that is cited by everybody and by all the AI systems as the most reliable means to accomplish what I want - to present a microSD card as a disk drive to a PC using a USB cable to a PICO that accesses the microSD card via SPI. 

More experimenting with AI for USB microSD PICO project

RESUMING CLAUDE WORK

Another few hours, still zip. I gave up when finally it did a screen scrape and found some report of issues with TinyUSB and the PICO board support. It then recommended giving up on the Arduino IDE approach and going over to the Visual Studio code that all the other AI systems found and regurgitated. 

DISCOVERY ON MY OWN - CODE OFFERED BY AI FLAWED IN KEY WAY

I did my own research and came across an important detail that the code provided by Gemini configured the key hardware configuration file for the SPI connection to the microSD card holder in a way that doesn't make sense. 

The Raspberry Pi PICO has two SPI components - SPI0 and SPI1. For each, there are only certain pins that can be assigned for the clock, MOSI, MISO and chip select operations of those SPI components. The code from Gemini configured the SD card as SPI0 with SCLK on GP10, MOSI on GP11, MISO on GP12 and CS on GP13. Those pins are okay for SCLK, MOSI, MISO and CS but for SPI1, not for SPI0. 

No wonder the SPI component was hanging up or not working properly. No wonder it couldn't read the card descriptor or other data from the card. 

GOING TO HAVE TO REBUILD MY VISUAL STUDIO AND PICO SDK ENVIRONMENT

I had to restore Visual Studio to the point where it can again successfully build software for the PICO. I can then try to get the code built and try it out, now that I have the SPI functionality issue resolved. 

More experimenting with AI to assist in simple tool to use Raspberry Pi PICO to present microSD card as disk drive over USB

HAVING HAD A POOR EXPERIENCE WITH GOOGLE GEMINI, I TRIED COPILOT

I decided to give Microsoft's Copilot a try and posited the same requirement. Use a PICO to connect to a PC over USB as a disk drive showing the contents of a microSD card, accessed by SPI and formatted in FAT13. I chose the approaches that used Visual Studio and the PICO SDK. 

EIGHT HOURS OF HAND TO HAND BATTLE, NO SUCCESS WITH COPILOT

The same kind of tomfoolery happened with Copilot. Plenty of recommendations with 'official links' that got 404 errors or were deprecated, followed by "you are correct, here is the proper site" which sometimes was just another bogus stale recommendation it had screen scraped from Bing searches. 

It was never able to do a clean compile. Many hours of changes, reinstallations of VS and the PICO SDK and the toolchain. Lots of changes to Visual Studio, which I suspect has left it a shambles. Previously it had been able to cleanly compile the C code for the Virtual 2315 Cartridge Facility project. Many claims that "now we have the evidence" and "this is a rare issue", every single one leading to the same error. Unable to configure the compiler and assembler for the build. Many many tests that never led to a successful diagnosis. 

TODAY I TRIED USING CLAUDE

It was the same mission - microSD card accessed by SPI and presented over USB as a disk drive to a PC. It told me there was a straightforward way to do it using the Adafruit PICO board, avoiding a different PICO board due to compile conflicts - but of course that was stale information and it then admitted that the Adafruit board code was not longer supported, to please use the board file it dissed in the first response.

I put up the code in Arduino IDE and the compile failed.  Pasting the messages to Claude gave me recommendations. First about removing the board manager then reinstalling it, testing that a simple Blink script compiles. Then about manually removing the Adafruit SDFat library manually. 

It actually compiled clean. No guarantee it will work correctly but having something I could actually load to the PICO was an accomplishment after yesterday's fiasco. I took my laptop to the workshop, installed the code on the PICO and gave it a try.

No joy. I then went through about five hours of debugging suggested by Claude, up until I ran out of free chats for the day. It appears that the PICO is freezing during its USB initialization and it may have nothing to do with the code generated for the function, other than certain libraries initializing during the PICO startup prior to one line of my setup function running. 

I will return after 2PM when the Claude timeout ends and see where it takes me. I had also started a Grok session since I am interested in seeing how fundamental the issues are with using AI tools for this sort of project, versus different approaches in the various systems. 

GENERAL MUSING ON AI AND ITS USE WITH PROGRAMMING TASKS

A few were more upfront than the others, showing me a running set of web searches they performed before offering the advice. It confirmed my belief that these are just digesting and regurgitating the postings of others, thus only as good as the original postings. There didn't seem to be any understanding of the actual operation of the code being proffered, nor of the failures other than repeating how others had debugged the symptoms. 

This is different from how I have experienced the AI tools building code for algorithms I requested. They do seem to understand how to structure code and do a very good job with what they produce. I believe the key difference here is that I am asking to do things that involve very complex nested systems, libraries and functions built into the microcontrollers, which are not fully documented other than the source code. 

Since the failures occur deep in those nested systems, the AI falls back on web scraping to find similar symptoms and thus reverts to surface level simplistic analysis. If the AI tool were to ingest and study all of the IDE, microcontroller and various libraries, building up an algorithmic understanding of everything, then it might be able to truly evaluate the issues and chart out successful code at the top level calling or interfacing with these complex systems. 

Wrapping up the successful 1130 memory substitute project

RESOLUTION OF THE ISSUE

As I covered in my last blog post, the addition of a braided ground wire with many fine strands was sufficient to solve the high frequency impedance of the ground connection. The board is now solid as a rock. 

RERAN CPU DIAGNOSTIC AND MEMORY DIAGNOSTIC SUCCESSFULLY

All diagnostics run clean, thus the memory and indeed the CPU are working properly. I can move back to testing of my Virtual 2315 Cartridge Facility which expands the usefulness of the internal disk drive tremendously. 

DECLARING VICTORY AND FINISHING UP THE MOUNTING INTO THE 1130

Based on this, my 1130 MRAM board appears to be working properly. It replaces the core memory stack and associated logic cards that sat in compartment B-C1 of the 1130 system, since that core stack was unrepairable. Three ribbon cables plug into my board instead of into the backplane in compartment B-C1. I disconnected all the power connectors to that compartment, but left all the components in place. 

My design includes two holes for attachment of the printed circuit board onto mounting brackets to hold the board inside the compartment. I fabricated something and have the board in its permanent home. It was necessary to remove the top row of SLT cards from the compartment to allow the PCB, cable connectors and FPGA daughtercard to fit within the air plenum at the top of compartment B-C1. I ran the braided ground conductor from my board to the ground bus of the 1130 to shunt any high frequency noise around the 16 gauge stranded wire ground connections for +12V and ground.

The 1130 is pretty insensitive to the noise generated but it can cause the ground of the board to shift a bit relative to the ground of the rest of the 1130 due to the impedance of the stranded wire at higher frequencies. The braided conductor bypasses the stranded wire for high frequencies. I dressed all the power lines to the board to make things neat. 

GITHUB FINALIZED

The github repository for the 1130 MRAM substitute project is now up to date with all the files, documents and other information needed by anyone who wants to build a replacement core memory for their 8K 3.6us IBM 1130. 

Failed testing of mechanism to read virtual 2315 cartridges conveniently from a PC

VIRTUAL 2315 CARTRIDGES STORE THE IMAGE ON A MICROSD CARD INSIDE HOLDER

The Virtual 2315 Cartridge Facility (V2315CF) makes use of microSD cards to hold a file with the contents of a 2315 Disk Cartridge for use in the disk drive of an IBM 1130 system. The microSD card is kept in a holder that appears to be a miniature 2315 cartridge, presenting pins on the edge that plug into the main box of the V2315CF to use that image for access on the 1130.

In order to read and change the files on the microSD from a PC, one would normally have to remove the microSD card from inside the holder's socket and place it into a card reader plugged into the PC. It is preferable to have the mini 2315 cartridge assembly remain glued together rather than opening it for access. 

I decided to build a simple component that the mini cartridge could plug into, with the component connected by USB cable to a PC. The microSD card will appear on the PC as a disk drive, thus it can be accessed just as if it were removed and put into a card reader but leaving the mini 2315 cartridge sealed.

The unit is implemented on a Raspberry Pi PICO with just a few resistors and the socket added so that the mini 2315 cartridge can plug into the unit. The PICO was programmed to open the microSD card as a FAT file system and present that on the PC in the same way that a USB memory stick appears to be a disk drive. The first design made use of Carl J Kugler III's library no-OS-FatFS-SD-SPI-RPI-PICO after suggestions from Google Gemini. The code did not open the microSD card successfully. 

Since debugging was going to be a bit awkward since I was using the PICO USB cable to appear as a disk drive to the PC, requiring me to wire up a UART link for debugging messages. I tried blinking the LED on the PICO board to let me know where it went astray, but it was some issue the library found with the microSD card image that I couldn't readily determine. 

I went back to the drawing board, this time accepting advice from Gemini to use an Arduino IDE approach, leveraging the PICO core from Earle Philhower to access the microSD card in a more direct and hopefully more successful way. I built that version and loaded it onto the PICO for testing. 

That failed and failed and failed. Lots of unrecognized USB device errors. Gemini seems to be doing brainless google searches of symptoms and steering me to each fix from those posts, without truly understanding what is happening. It gave me fifteen different attempts before doing a test and blaming a timing race between Windows and the PICO. 

It then had me download CircuitPython onto the PICO and load some scripts. That continued to show errors, which several iterations worked on but ultimately it decided that now we had to switch to MicroPython. About a dozen iterations later, including one where it reported that its previous code had an error crashing the boot, it reached the point where it proudly chimed when the USB cable was connected but showed no drive at all.

Now it is recommending that I go to direct C/C++ code, a precompiled load file for the PICO at a repository link. When I went to the github repository, there are no xxx.uf2 files at all. I pointed that out, got a "you are correct, it is only source code" response and then directed to yet another method. Useless. Completely useless. This is simply regurgitating posts it scrapes from the web. 

I am going back to the Visual Studio C code I originally worked with, but asking MS Copilot for how to accomplish it. Hopefully I will find the deviation from what Gemini offered. It is hard to believe that companies believe they can replace programmers with AI at least based on my experiences. 

Needed to wait for Lattice Semi to send the hobbyist license file

FOUND ONLINE COMMENTS THAT SUGGEST FORMATTING OF MAC IS AN ISSUE

Some internet messages suggested that Lattice expects the MAC address of the network interface to be formatted a specific way, without hyphens or colons as most systems display them. My first request changed the subject line to Renewal from their boilerplate New iCEcube2 License Request wording. I then changed it to what they had, since they may have a simple script grabbing the license requests. 

When I still had radio silence for a long period, I did some searches to see if others were experiencing delays or other problems. That is where I found hints that they expect the MAC to be 12 contiguous hex digits although their boilerplate simply asks "MAC address for license generation: " without any format guidance. I sent off a third request just now, hopefully matching the unspoken rules and allowing me to receive the license file shortly.

RESPONSE RECEIVED - LOG ON AND REQUEST LICENSE FILE

I was given a subscription number as the response to my earlier email requests. That had me log onto the Lattice website and request a license for the subscription. With that number entered plus my MAC address without hyphens or spaces, it told me to wait for an email. 

Great news, however, because the license file arrived almost immediately. I set up the program to point at the license and was able to synthesize and create the bitmap which I have to flash onto the FPGA memory device so that the new logic becomes active. 

SUBSTANTIAL PROGRESS DOCUMENTING BUILD OF V2315CF

It is a complex project that requires building and then modifying George Wiley's RK-05 Emulator, building several custom PCBs, modifying the internal disk drive of the IBM 1130, making wiring changes in the 1130, connecting quite a few units together and then installing them in a custom enclosure or inside the 1130 system. 

There is also the need to create Solid Logic Technology (SLT) compatible male and female connectors since we are intercepting signals that run between the disk drive and the 1130. Mini 2315 cartridge replicas are constructed to hold the contents of the virtual disk cartridges, and software is used to manage theses mini cartridges. 

I have generated many images to help guide the builder in these steps, then written about each step with those pictures in support. I had to cross reference many schematics and design files to be able to clearly identify where wires are connected or removed. 

I estimate that the document is now 75% complete. A few more days work and I should be able to upload it to the github repository.