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. 

More this and that, while waiting

BUILDING BRACKETS AND COATING THE 1130 MRAM BOARD FOR INSTALLATION

The gates in a Solid Logic Technology (SLT) generation mainframe have multiple compartments, each hosting as many as 96 SLT printed circuit cards which plug into a printed circuit board that interconnects those 96 card slots plus some top and bottom signal cables. One side of the compartment has the large board with about 2,500 wire-wrap pins that form the 104 sockets for SLT cards or cable connectors. 

The other side of the compartment is a metal cover behind which the SLT cards are inserted. These cards are oriented so that air flows in the 'aisles' between the cards, from bottom to top, to remove heat. Fans sit on the bottom of the compartment and pull air through filters to blow it up over the SLT cards. The top of the compartment is a grill through which the warmed air exits.

Compartment C1 in gate B housed the original core memory for this IBM 1130. It has a three dimensional core memory stack installed on the big board in place of about half the card slots. The remaining card slots have SLT cards which provide the addressing, driving and sensing circuitry for the core memory. 

Since the core memory stack has irreversible corrosion that is eating internal traces, it is no longer feasible to use it on the 1130. I developed a printed circuit board to replace all of the functionality of that card compartment. The three cables which connect this compartment to the rest of the 1130 circuitry are plugged into my PCB instead of the big board in the compartment. All power connections to that compartment are removed, thus nothing is operating in the compartment; my PCB serves as the core storage for the system. 

My PCB is mounted inside the compartment, just below the top grill where the hot air would escape. The three cables originally plugged into the compartment backplane in the top connector slots T1, T3 and T4. My board has those cables fitted and is suspended at an angle inside the gate just below the grill so that it is cooled by the airflow from the fans below. 

SLT backplane/compartment

mounting method

I cut some brass to form the brackets that will hold the PCB at a diagonal under the grill, permitting the existing SLT cards that are inactive to remain in place. The PCB and its brackets were given conformal coating to keep the electrical components insulated from any contact with the compartment walls or grill. The coating should be fully dry by Wednesday when I intend to bolt the memory PCB in place and close up the 1130 system. 

STILL FIGHTING WITH THE HEAD CLAMPS OF THE DIABLO 31 DRIVE

The Diablo model 31 disk drive mounts two read/write heads on the arm, one each for the upper and lower side of the disk platter that is inside the 2315 disk cartridge. These are held in place by three clamps - one each for the upper and lower head holders and a third that holds both head holders in place.

These had been loosened too much and could not be tightened into their proper position. The upper and lower head holder clamps have a tang at the bottom that nestles into a groove on the drive, keeping the clamp upright so that the bolt simply loosens or tightens it. The bolts had been turned too many times and now the tang was not in place, allowing the clamp to spin around. 

Access to the area where the clamps sit is exceedingly restricted and hard to even see into. I finally pulled out a fiber optic camera on a cable that I could push into the area and try to get enough visibility to work. Below is a view from the camera of one of the two head holder clamps, rotated out of position but at least with the bolt still threaded into the end. 

View through the fiber optic camera - not great

I was able to finally work the lower head holder clamp into position so that it tightened up, held from rotation by the tang. That took quite a bit of fussing and work until I finally got the clamp in place.

I then began working on the upper head holder clamp, but that seems jammed against the lower clamp or perhaps against the third (common) clamp. I need to get this one sorted out before I can move on to the third clamp which should be easier to orient once I slide one of the head holders into place. I ran out of steam; this will be waiting for me when I get back into the shop.

CREATING THE BUILD AND INSTALLATION MANUAL FOR THE V2315CF PROJECT

I am now at a point where I will be finalizing the debugging of the Virtual 2315 Cartridge Facility (V2315CF), an ambitious feature that works with the internal disk drive of the IBM 1130 to allow access to a wide range of cartridge images either archived from real disk cartridges or created on IBM simulators. These can be mounted and accessed as if they were real physical disk cartridges, with the internal drive spinning and the arms moving in and out. 

However, the heads do not actually load down onto the one physical cartridge that is inside the drive, thus eliminating the risk of crashes that could destroy the rare disk heads or the disk cartridges. The data for a virtual 2315 cartridge is held on a microSD card inside a little 2" replica of a cartridge which is plugged into the V2315CF main box. The data that is ready by the 1130 comes from the virtual disk image, rather than the heads in the drive. Any data written or changed by the 1130 will be stored on the virtual cartridge's microSD card. 

Virtual cartridge images can be transferred to and from the IBM 1130 simulators that run on modern computers. As well, the collection of physical 2315 cartridges that I have collected will be archived by the other current project, the Diablo Archiver, so that they can be used on the V2315CF. 

The only issue that was outstanding when I had to walk away from the debugging (due to the core memory of the 1130 failing) was the coordination of seeks (disk arm movement between the 203 cylinders of a 2315 cartridge) between the internal disk drive, IBM 1130 and the V2315CF. I am optimistic that this will shortly be resolved, after which I can finalize the installation of the V2315CF in the IBM 1130 that belongs to the Vintage Computer Federation and which I am restoring. 

This is a complicated system that involves modifications to the internal disk drive, several printed circuit boards, a complex power system with battery backup, and the main box of the V2315CF. The main box is an extensively modified derivative of George Wiley's RK-05 Emulator which he built to emulate the DEC disk drive which is a derivative of the internal disk drive from the IBM 1130. There are also the virtual cartridges, software to transfer the disk images and changes to the RK-05 Emulator kit. Finally, a plexiglass case mounts the main box and some of the other components inside the top cover of the IBM 1130, right atop the internal disk drive. 

I began writing a manual which details all the modifications, construction details and other tips necessary for someone to build and install a V2315CF for use with their own IBM 1130. The project is shared on Github along with PCB design files, Verilog and C code and other essential files, but the manual covers the essentials for putting it all together. This manual will be at least 50 pages long and may grow substantially beyond that as I validate that a reader will have all the information they need to successfully implement the project.

WAITING TO PROCEED ON OTHER TASKS

I have no response yet from Lattice about the license file I need to synthesize the FPGA logic for the V2315CF - those changes are what I must test to finish debugging the seek behavior of the project.  

I am waiting for filter and gasket materials to get the Diablo model 31 disk drive in good working order for the Diablo Archiver project to begin reading and saving the contents of the 2315 cartridges from my collection. 

I will also be tied up all day Wednesday providing a tour of Cape Canaveral Space Force Station and its historical facilities to 200 undergrad and graduate college interns, a Brigadier General and other brass in support of the Air Force Civilian Services organization. It is likely that my progress is mostly stalled until Thursday when the awaited items may be on hand and when I can get time to go back into the workshop.

This and that - waiting while moving several projects along

WAITING FOR FILTER FOAM AND MATERIAL TO REPLACE HEPA FILTER ON DIABLO

The Diablo archiver project depends upon the Diablo model 31 disk drive being ready to safely read the pile of 2315 disk cartridges I have with IBM 1130 software and data on them. The heads are not yet mounted but I also have to ensure that the air supply is clean enough to protect the drive from head crashes that dust or other tiny contaminants might cause.

Bits of foam and gasket material have degraded over the years and must be replaced. They have to provide a tight seal for the purified air that comes in through the main filter on the drive. This filter has a HEPA 13/14 level filter to block all the tiny particles, with a foam prefilter to stop bigger junk from reaching the HEPA filter. There are also gaskets where the filter joins the drive body and also where the clean air enters the 2315 disk cartridge - these are degraded and must be replaced.

I have ordered products I can use to replace the gaskets, the prefilter foam and the HEPA filter so that the drive is again able to provide a clean air environment for reading the cartridges.

MUST WAIT FOR NEW LICENSE FROM LATTICE FOR ICECUBE2 TO TEST V2315CF

Having completed the simulation of the improved seek functionality for the Virtual 2315 Cartridge Facility, I started up iCEcube2 to synthesize the Verilog and prepare to program the FPGA. When it started, I was informed that the free hobbyist license had expired. I submitted the email for a renewal/replacement license, but as it is Sunday I expect it to take a day at minimum and probably more. 

WORKED WITH BETTER BRAIDED GROUND WIRE FOR 1130 MRAM

I received this tinned copper mesh ground wire today and began to install it on the 1130 to provide a low impedance ground path from the 1130 MRAM memory substitute board to the 1130 power rails. There is a bit of work to do with the mounting brackets to place the board safely inside gate B compartment C1 which was where the IBM core memory circuitry resided. 

That wire mesh is enormous overkill, but I want the memory to run clean and after fighting mysterious issues due to the ordinary stranded ground wire, I don't want to accept any risk at all of memory problems in the future.