Human 1, AI 0 - 40 minutes of debugging and my PICO tool projects microSD card as USB thumb drive to PC

CARTINTERFACE - TOOL TO MOUNT MINI 2315 CARTRIDGE ON PC VIA USB

The Virtual 2315 Cartridge Facility (V2315CF) employs microSD cards to hold a disk volume with a file that is a virtual image of a 2315 disk cartridge. These cards are mounted on a small circular PCB that is the top of a mini cartridge, looking like a tiny version of the 2315 cartridge, with a 2x4 header that plugs into the V2315CF main box so that the disk image can be accessed by the IBM 1130 system. 

The PCB has a microSD card socket on board and is wired so that the V2315CF can access it via Serial Peripheral Interface (SPI) over the header pins. The card socket and other components are on the underside of the small PCB. The mini cartridge has a 3D printed shell glued under the PCB, forming a 2315 cartridge shape. 

For convenience, I wanted a tool that allowed me to plug the mini cartridge into a socket and have the file on the microSD card appear on a PC as a virtual disk drive, just as a USB thumb drive appears. I whipped up a small box with a Raspberry Pi Pico, a 2x4 socket and some pullup resistors as an interface box, which I call CartInterface. 

The mini cartridge is plugged into the 2x4 socket and the USB cable from the PICO is plugged into a PC in order to open the microSD card FAT file system as a virtual drive on the PC. The file on the card can be accessed (or replaced on the PC to update the mini cartridge).

WORKED WITH AI TOOLS TO BUILD THE PROJECT

Since this would use a number of libraries that I was not familiar with, plus be a first time I tried to project a mass storage (disk) device over USB, I looked for advice from four AI systems - Gemini, Copilot, Claude and Grok. They all identified the two examples of the same functionality that were published on the internet - one using the Arduino development environment and the Adafruit TinyUSB library, the other using the No-FS-FatFS-SD-SDIO-SPI-Rpi-PICO library from Carl J Kugler III in his carlk3 github repository. 

Each of the AI systems burned through eight hours, offering code and setup instructions and then bumbling through build errors, toolchain configuration changes and then fruitless debugging. I tried both methods - the library from carlk3 which had an example inside that was almost exactly what I wanted to achieve, and the Arduino IDE version, alternating which method I used with the next AI tool.

STOPPED USING THE AI TOOLS AND DID IT MYSELF

Since the AI systems appeared to simply be conducting web searches and scanning posts and documents they found, but failing to understand what was occurring enough to properly advise or debug, I dropped the tools and did my own searches. 

I decided to work on the Arduino version leveraging Adafruit TinyUSB. It did involve looking into library code in a few places but I quickly zoomed in on what was going wrong. Within 40 minutes, which included web searches and reading of code, I had the CartInterface working properly. 

ENCLOSING CARTINTERFACE IN A PROJECT BOX AND UPDATING MY V2315CF GITHUB

I have a small plastic project box into which I installed the CartInterface board, exposing the 2x4 header socket on the face and routing the USB cable through a hole. It is now complete and ready for productive use whenever I want to transfer 2315 cartridge images between the physical IBM 1130 with its V2315CF and an IBM 1130 simulator running on a PC. 

I added the code and instructions to the V2315CF repository on github thus others who build this in order to use virtual cartridges with an IBM 1130 computer have this convenience tool. 

Grok joins Claude, Copilot and Gemini in my hall of shame; pleased to hear my 1627 Plotter card was built successfully for another 1130

1627 CONTROLLER CARD SUBSTITUTE WAS ADOPTED AND IS IN USE

Friends at a museum in Europe have made use of the 1627 github project to build a substitute card and install it per the instructions. They have already restored a 1627 Plotter but did not have the controller card installed in their 1130 to make use of it. Today they first tested it out - it is working perfectly and soon they will try out a special feature I added above and beyond the IBM functionality. 

It emits a stream of movement messages on a serial link over USB - that will allow programs to draw plots virtually through the link rather than consume the very rare plotter paper stocks. Those virtual graphs can be displayed live on a monitor and/or printed on a color printer. 

PUT IN THE SAME EIGHT HOURS WITH GROK AS I GAVE THE OTHER AI SYSTEMS

I have a very simple objective in mind, a way to access the virtual disk cartridge files from the Virtual 2315 Cartridge Facility (V2315CF) from a PC without having to open the mini cartridge and transfer the microSD card into a card reader on the PC. It should be easy to have a microcontroller access the mini cartridge in much the same way that the V2315CF does, then present the fat32 file system from the card as a disk drive on the PC. 

The V2315CF makes use of a Raspberry Pi PICO to read and write on the microSD cards, accessing the files through a 2x4 socket that the mini cartridge plugs into. There are several successful projects that people have done with a PICO that accomplished exactly what I want - accessing a microSD card then projecting it to a PC as a disk drive. However, I have yet to get this to work even starting with each of the previously successful projects.

I attempted to lean on the various AI systems to work my way through the creation and testing of the project, but was not impressed at all with the quality of the advice. My impression was that these were good a doing extensive web searches and read through many accounts and documents, but lacked much understanding of the subject. As a result, the advice was often stale or wrong, leading in circles and taking pointless diversions. 

Grok was the last of the AI systems I attempted with this. If the question I asked was straightforward, one whose answer comes out of a manual or is simple syntax, the results were quite satisfactory. When things are going wrong but it is a misbehavior or misconfiguration rather than straightforward syntax, the results were poor. 

I gave Grok the chance to help me implement the example from the no-OS-FatFS-SD-SDIO-SPI-RPi-PICO library that is essentially exactly what I want to accomplish. There is only a very minor difference between what I want and the example - the microSD card socket was accessed by SDIO instead of SPI - thus it should have been a simple matter of building it and being done.

That is not how this went, however. Between configuration issues with Visual Studio Code, problems with the build process and other issues that arose, it did take about seven hours just to get the code to build but somehow it is not working on the PICO. 

I believe I would have made faster progress on all of these by doing my own google searches and read the documents and source code myself, so that I understood what is going on and can achieve some success. 

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.