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.