Gary,
Sometime back I was having the same problem.
Using a HEX editor on the .DO files on my PCs hard drive, I found that some .DO
files had an EOF (1Ah) as the last character. Model Ts do not like this as
the operating system appends its own 1A to the end when the file is in-loaded
to RAM. And as long as that .DO file sits in RAM it needs that 1Ah. But when
a file is out-loaded from RAM, the op sys removes that 1Ah.
I traced this problem to an early version of VirtualT. When I created a .DO
file in VT then saved it to my PC’s hard drive, VT was not stripping off the
1Ah when saving the file to the host’s hard drive. So, when in-loading that
.DO file I ended up with two 1Ah’s causing a weird phenomenon where the RAM
file directory was corrupted, shifting the directory values. Of course Ken
quickly found that bug and fixed it.
I also found that some PC word processors append either a 1Ah or a null to the
end of their text files, but I could not pin down which applications were doing
that. I am still finding some if my old .DO files that have the nasty 1Ah at
the end. Ugh!
Having a CR/LF at the end of the .DO file was not a problem, but I did not run
into the CR only (or lack of the LF) at the end of a .DO file, but perhaps my
study did not create and test that condition.
Hope this helps a little.
Bob
From: M100 [mailto:[email protected]] On Behalf Of Kurt McCullum
Sent: Friday, August 25, 2017 3:37 PM
To: [email protected]
Subject: Re: [M100] Loading multiple .DO files with TS-DOS
That may be true, John. I have not had to deal with the CR vs CR/LF issue for
quite some time. As I recall it messes up the file but I'm not sure about the
file system.
Could this be an EOF problem? Looking at the memory editor in Virtual-T, every
DO file has an EOF (0x1A or CTRL-Z) at the end of the file. BA and CO files
don't have that.
Kurt
On Friday, August 25, 2017 11:54 AM, John R. Hogerhuis <[email protected]> wrote:
On Fri, Aug 25, 2017 at 11:46 AM Kurt McCullum <[email protected]> wrote:
I've been using the tag feature for .DO files quite a bit and I've never seen
this happen. I'll do a specific test when I get back to the house and let you
know what I find. Seems really strange. I doubt a bug like that would have
survived testing.
I just did a quick test under Virtual-T and it worked fine.
One thought. The Model-T needs a CR/LF and sometimes when a file is saved on a
different system this can get converted to CR only.
Kurt
That shouldn't affect the file system.
I thought only nul's and EOF were disallowed in DOs?
-- John.
