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.

Sadly I don't have an ATA like that. I'm using a Walmart basictalk that I flashed the firmware to to be the Grandstream ht701 that it actually is. Hopefully I won't need to remove the U1MB. I'm afraid the original MMU didn't survive the upgrade. I'll start with the modem first, as the audio system of this model was close to being a complete kludge, and would be the most likely place of failure.

I'm currently using an 800XL with a U1MB. It and an 800 with 48k was our family's first computers. I remember dad getting them, a 1050, 410, and this 1030 in trade for a pest control job, as well as all the software, cartridges, and many copies of Antic magazine. Quite a bit of the software was pirated, but most was not. Our family's next computer sadly was not an Atari but a 386DX by a company called PCpositive.

So I isolated the modem on the SIO chain. Unusual tone removed, tone dialing still not recognized by the ATA. The source of the tone was from the SIO2PC electronics. Very strange as there is no connection to audio in the SIO2PC. I'm suspecting that the tones might not be loud enough. It looks like I may need to crack it open and check components. ATA is not at fault as a regular phone dials just fine. I added the same tuning that Nezgar used for jitter. Much improved reliability.

Yes, it's 1030 on one extension, and PC modem on the other. I certainly need to do some tuning to improve reliability, it's fairly solid, but not solid enough. The issue though, is the fact that the DTMF from the 1030 is too deficient to be recognized by the ATA now. It was working great the previous day.

So I decided to drag out the 1030 from storage to see if I can connect to the Linux server in my house over a VoIP connection. The answer is yes, but not to be trusted for data transfers. I have a couple of DAHDI cards ordered to see if I can improve on that. However I had an issue crop up with tone dialing, my ATA stopped recognizing the tones. So I dialed the PC modem with the phone handset connected to the 1030 then pressed 'F' on Bobterm, and it connected. So the ATA seemed to be fine then. I then listened on the phone handset while the Atari dialed, and heard a curious thing. There was what almost sounded like a recording prompt tone, the low and almost bell like kind followed by DTMF tones with an audio glitch of the previous sound. I'm sure this is what is causing the ATA from recognizing the tones and causing a dialing failure. Now the question before I open the modem up is: should I expect this to be an issue caused by bad caps, or some other part?

The best way to do this would be with an SIO2PC cable. I'd recommend Lotharek's offering: https://lotharek.pl/productdetail.php?id=157 Of course you could also build your own if you have a real serial port on your PC or a USB to serial adapter: http://www.b-pahl.de/atari8bit/sio2pc/floppy2pc/prosys.html I personally use the schematic featuring the 14C89. It's a good project to get started with soldering and has very little chance to damage anything other than your pride if you get it wrong. From there you can use Respeqt to load ATR disk images from the PC or sector copy them to disks if that's your prefrence. You can shop around still for 5.25" disks, but it'll be new old stock at best. Be sure to get dual density disks, not High Density. The HD stuff isn't as good with our low density drives.

Because the computer uses an external 5v power supply. So, connecting mains voltage, any countries mains voltage, would result in letting the magic smoke out of the machine in spectacular fashion.

The gun is just a fancy looking joystick. If you wanted to you probably could use the paddle analog pins on the joystick port if you want the analog control feel. Everything as far as colors and speed is concerned might be challenging if software sprites have to be used.

Okay, cool. Would rather have a properly fitting connector. It's just very hard to find a good SIO receptacle these days, and seemingly impossible to find a 3d printable one.

Any chance that you could point us to where we could get the STL files for those SIO connectors?