Re: [M100] Keep getting DS ERROR when loading via serial.
Oh yeah, that too. And unix LF-only line-endings. BASIC (on these machines) can take either CRLF or CR-only, but not LF-only. But I think in most cases pasting into a terminal program would probably generate new line-endings, so even if the original file had LF, the term program may output CRLF to the remote end depending on it's settings. -- bkw On Sat, Oct 22, 2022, 9:09 AM Joshua O'Keefe wrote: > > On Oct 21, 2022, at 10:32 PM, r Gi wrote: > > > > I am repeatedly getting a DS ERROR most of the time when I try to load a > program. It happens a short time after starting the upload. Any help would > be appreciated > > Nearly all of the DS ERRORs I have received while reading BASIC programs > over serial have been victims of formatting errors. There are many on the > internet, particularly in the CompuServ archive, that have been line > wrapped. I've run into this with programs OCRed from books as well. > > Just as if you were typing the program, hitting Enter too early and then > continuing to type would execute a direct statement. Doing so is not > allowed while you're LOADing. That's what happened to me while loading > these various files. > > Fixing the line wrapping solves the issue.
Re: [M100] Keep getting DS ERROR when loading via serial.
For loaing into BASIC, use a bootstrapper to send the file, which inserts a delay in between each byte exactly to avoid that problem. http://github.com/bkw777/tsend for windows or http://github.com/bkw777/dlplus for anything else. Loading a file directly into BASIC is not like a normal plain data transfer that merely copies data, it's essentially typing into the interactive interpreter, which means the interpreter does work on each byte entered, and the amount of work varies depending on the code being entered, what part of a line it is in, what part of a statement it is in, and what kind of statement, etc. So some bytes are simply stored and takes no time and it's ready for the next byte quickly. Some bytes trigger some work behind the scenes and it's not ready for the next byte for several ms. But the sending side has no way to know that (the software-only flow control doesn't work well enough) and just sends bytes without stopping or pausing. Some serial comm programs have an advanced setting for inserting a delay between each byte, but only some, and even some that have it, don't apply it consistently. TeraTerm has a setting for that, but it only applies to the terminal window, not to file transfers. If you set that setting, and then used the file transfer dialog to do an ascii transfer, it does not apply the per-byte sleep. You have to paste the file into the terminal window to mimic typing it. I think another way to handle it is just send the file at a lower baud rate like 4800 or 1200 instead of 19200. But for some reason I've never actually tried that for loading into BASIC, just when using TELCOM to access another machine like a bbs, so I can't say for sure if that actually eliminates the problem reliably. For loading into BASIC I always use a bootstrapper which is designed just for that. Both programs above include a little helper/reminder prompt showing you the exact RUN:.. command to type in BASIC to receive the file and run it on the spot, but you can just use LOAD in place of RUN. And really, I only use a bootstrapper when I want to run-and-discard the program, generally for installers. If I just want to copy a file to the 100, I use TPDD. Use the boostrapper just to install TS-DOS or TEENY or DSKMGR, then use dlplus (link above) or LaddieAlpha (link below)on the pc side and ts-dos etc on the 100 to transfer any kind of file in either direction with no worries about baud rates or corruption or errors. And really, the even better answer is to get a REX# and have ts-dos in rom instead of in ram. Installing ts-dos in ram consumes 5k or so of ram. TEENY is smaller but less convenient. http://bitchin100.com/wiki/index.php?title=LaddieCon#LaddieAlpha http://bitchin100.com/wiki/index.php?title=REXsharp -- bkw On Sat, Oct 22, 2022, 1:33 AM r Gi wrote: > I am repeatedly getting a DS ERROR most of the time when I try to load a > program. It happens a short time after starting the upload. Any help would > be appreciated >
Re: [M100] Keep getting DS ERROR when loading via serial.
> On Oct 21, 2022, at 10:32 PM, r Gi wrote: > > I am repeatedly getting a DS ERROR most of the time when I try to load a > program. It happens a short time after starting the upload. Any help would be > appreciated Nearly all of the DS ERRORs I have received while reading BASIC programs over serial have been victims of formatting errors. There are many on the internet, particularly in the CompuServ archive, that have been line wrapped. I've run into this with programs OCRed from books as well. Just as if you were typing the program, hitting Enter too early and then continuing to type would execute a direct statement. Doing so is not allowed while you're LOADing. That's what happened to me while loading these various files. Fixing the line wrapping solves the issue.
Re: [M100] Keep getting DS ERROR when loading via serial.
DS means "direct statement in a file" you are loading. All program lines are supposed to start with a line number. So the file itself could have this problem... code without a line number. More likely if you are loading the file too fast, sometimes the Model T tokenization process cannot keep up with the incoming code and characters get missed. Flow control can handle this to a degree. Depends on the setup. If it misses the line number (after a newline) due to data loss, then it will see the code following as a "direct statement" and give this error. If it only misses part of the line number, the code could still load and end up on the wrong line. -- John.
[M100] Keep getting DS ERROR when loading via serial.
I am repeatedly getting a DS ERROR most of the time when I try to load a program. It happens a short time after starting the upload. Any help would be appreciated
