A few years ago I was having the same issue (EOF as last chr in the file). I
traced it to my use of an early version of VirtualT.
Note:
When a file is loaded into ModelT memory (as seen on MENU), the OS
automatically appends an EOF character to it.
This is for later use by BASIC when finding the end of that file in memory.
Subsequent moving of that file out of memory to CAS or wherever, the EOF is
automatically stripped off.
While this is true for .DO files, I am not sure about .BA or .CO files.
If I recall correctly, it turned out that VirtualT (at that time) failed to
strip off the appended EOF when it moved the file from ModelT memory out to a
hard disk.
Then subsequent inloading and use of that file in a real ModelT would crash it.
Ken Pettit quickly fixed that bug, of course.
So, if your ADVENT files were once loaded into an early version of VirtualT and
subsequently saved for use in a real ModelT, those files might be "EOF
corrupted". I remember having to use us a HEX Editor program on my PC to
examine the end of each .DO file that I had saved out to hard disk from
VirtualT. I found many and fixed them by deleting that EOF. I even found
multiple EOFs on a few files that I had loaded and saved back out several times.
I hope this is helpful.
Bob
-----Original Message-----
From: M100 <[email protected]> On Behalf Of Eric LK
Sent: Saturday, February 09, 2019 2:12 AM
To: [email protected]
Subject: Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)
Gary Weber wrote:
> I corrupted my file system over and over trying to figure out what was
> going on when loading in the various ADVx.DO files for the ADVENT adventure
> game using TS-DOS. Turns out those .DO files had an EOF character at the
> end. And that ended up in the files because I'd manipulated them on
> an OS at the time that appended the character to each file.
Thanks for the feedback Gary!
Since the only weird thing I've seen on the file itself was the presence of the
EOF character, I assume that's exactly the same case.
By the way, is this ADVENT game any good? I didn't really look into games on
the M100 yet but I'd like to find something nice to try.
John R. Hogerhuis wrote:
> I have some hooks in LaddieAlpha to fix some stuff like filenames or
> do filters, I could fix that in LaddieAlpha. I already show file ASCII
> files misnamed as .BA as .DO to prevent corruption.
>
> I don't think I do any banned control character checks yet.
That may be a nice thing to have, especially if it just silently corrupt the
whole filesystem :o) I'm using mComm at the moment but I may give LaddieAlpha a
try someday.
Kurt McCullum wrote:
> It could be something as simple as a CR vs CR/LF problem at the end of
> every line. mComm doesn't change the file when sending it. That's
> something laddieAlpha does do which I probably should add to mComm.
> Open the file with something like Notepad++ and turn on invisible
> characters. If every line ends with just a CR instead of a CRLF then
> you have to file the file.
I'm not sure if bad CRLF can cause issues (except perhaps in TEXT; In basic I
had no issues with any special characters except $00) but the trailing ^Z is
definitely something to filter out.
Did you guys consider having a plugin API so we can write simple scripts for
this kind of things?
I have been working (very loosely) on a "Tandy ASCII" / Unicode conversion of
special characters (everything above 127) so the files can be edited on the PC
and be re-imported to the M100 without any issues (that's probably a feature
only non-English speakers would require (for é è ê à ç and friends)).
That's something I'd like to be transparent when I transfer files to/from the
PC, so a mComm and/or LaddieAlpha plugin would be great.
Eric
