Quiver

But apparently the esp32 is fast enough to run the g-code as a cnc/3d printer controller. https://github.com/MitchBradley/Esp32PrinterController https://github.com/bdring/Grbl_ESP32_MPCNC_Controller

Given that SIO could be said to be USB v0.5 there is no reason it can't, but I suspect that this would be a low priority for the developers at the moment. I mean you would have to writhe the code for the Fujinet, then you need to write a device handler to replace the device handler that is in the OS in the first place.

So according to Page 6 issue 22: Error-163 Unrecoverable system data I/O error. This error appears to act a, a catch-all for any I/O error not covered by the other I/O error codes, and for which the cause cannot be determined. It appears to be a very rare error. Suggested causes are malfunctioning equipment, corrupted DOS, and damaged disks (though there are presumably others). Are you trying to emulate a real drive without it's ROM? Also could it be a corrupted disk image?

Thanks. This really clears things up. The manual seemed as clear as mud in regards to using string arrays, at least to me. Been working through "Your Atari Computer" translating the example programs to Fast Basic. I figure I'll really know the language if I can "port" every example. Strings though are done differently enough in Fast Basic compared to Atari Basic that it was getting frustrating. Again thanks.

I can't for the life of me figure out how to declare a string array and initialize it. If I try something like this: DIM strARR$(5) strARR$() = "Hello", "this", "will", "not", "work", "to initalize" This will not work naturally. Alright I'll try a DATA statement: DATA strArr() byte = "How","do","I","access","this?" FOR I=1 TO 10 PRINT strArr(I) NEXT I This will produce numerical output. Having the READ statement from the Atari basic is looking more attractive at this point. So how does one use string arrays in Fast Basic?

Well why not make an atx form factor Atari? Combine both the 1090 and say the 1080 XEL. Though using the 576NUC as a base design has some attraction. Just some thoughts.

Updating the FATFS.SYS driver fixed the failed copying from a FAT file system to a non FAT file system. I suspect that what cause the initial failure that started this thread in the first place was a file system already containing errors, which I was unaware of, that I tried to write to. This caused the file system to turn into a steaming pile of non-differentiated data that was beyond reconstruction efforts.

Even if RWCRC is like an indulgent grandma not noticing that the kids are fighting in the back of the car it doesn't explain transfers from a mounted ATR image residing on the FAT filesystem that I'm having problems directly copying from working without any issues. I think I'll check if I'm using the latest version of FATFS.SYS.

I ran RWCRC the partition passed with flying colors. I did though encounter some other odd behavior. I attempted to copy files from the FAT partition to the Sparta partition. It failed with error 144 a write protection error. After running CLX on the partition to clear the resulting inconsistency I mounted an ATR image and copied files from that. No problems. Is there a known issue with copying files directly from a FAT file system to a Sparta or Atari file system?

So the partition was too far gone to fix. After CLX got done with it I was left with a blank partition. I kinda figured that was going to happen given how badly it was corrupted. At least I have a backup image of the APT container. Not the best case but better than what I was left with. Thanks for the help.

I'm sorry about the misunderstanding flashjazzcat. By firmware I was speaking about the SDX software distribution. In any case thank you. I really needed to know the name of the file system repair tool. Couldn't find a thing about it doing a search. Again thank you. I'll have to try this utility tomorrow. Too late to try tonight.

I'm using a U1MB with a side2 cart with an industrial CF card.

So I had decided to copy the latest Fast Basic from an ATR imaged mounted from a FAT partition to my programming partition. It gets partway through copying the files then out of the blue it fails with a file path error. Do a dir of the destination partition and I find that all entries are garbage. Aside from how this shouldn't happen during a file copy how would one go about attempting to fix this? There doesn't seem to be any kind of filesystem check utility included in the firmware, which seems to be asking for trouble IMO. I do have a backup of the APT partition so worst case I can overwrite the container, but it would seem like I'm only resetting the time bomb.

Okay, I had a real tech support moment, which is kinda like a senior moment, but features forgetting about the glaringly obvious in regards to tech. So, I connected the modems together using the PABX that I had gotten a couple of days ago. DTMF from the 1030 was still not recognized. So it was looking pretty grim for the 1030 with exploratory surgery all but scheduled. I then reconnected everything back to the HT701's and swapped out the 800XL for a 65XE. Tone dial worked. Now things are looking grim for the 800XL with the prospect of surgical exploration. I swapped the 800XL back in, and tone dialing worked. Now here's the tech support moment: I never restated the SIO cable at the 800XL itself, only the end connecting to the modem. I must apologize for involving everyone in a problem that could have been fixed with the most basic of tech support procedures. Thank you for your help everyone.

I do happen to have an analog PBX that arrived yesterday. I was planning on possibly doing a video on budget friendly methods on using vintage modem gear. I can try getting that running with the modems.