> -----Original Message-----
> When I looked at this, I saw that it was based on the z80 code written
> [...]
> Trying to access the unix fs directly, I could run the ws.com in the
> tests directory and it save the file to my unix filesystem. Winstall
> there gave an error, but I've seen this before when the ws.ins file
> doesn't match the version of ws. This program certainly needs further
> investigation.
I hadn't even looked in the tests folder! It seems to be WS3.0, and yeah, I
get the same error about WS.INS when I try using my good copy of WS3.3 that I
installed on my M100, so I know there's nothing wrong with my WS.INS. Coupled
with what Joshua was saying about having issues with saving files that don't
end in .BAK (which I guess implies that the crash is caused when WS attempts to
create a .BAK file, which it can't do if you're already editing a .BAK file), I
think there are some issues with the unix filesystem access functionality.
As I mentioned in an earlier message, I was hoping the 'cpmtool' utility
bundled with this emulator would be of some help to get around the
getunix/putunix issues, but it just seems to corrupt the directory in disk
images I've tried it on...
Hey, maybe you know (or maybe someone else does): some time ago I posted on
this list when I first got WS3.3 working, but SpellStar had the wrong terminal
emulation settings and I couldn't find a list of patch addresses for
SPELSTAR.OVR to fix it. Well, it turns out after some experimenting that there
aren't any... SpellStar just uses the terminal settings from WS.COM, except it
seems to have a bit of a bug when it comes to VT100. I realized what the issue
was when I was working on editing the aforementioned Star Wars arcade game from
Heath H19 terminal codes to VT100. The Heath terminal (and a lot of other
terminals) use a more efficient cursor positioning sequence where the row and
column are represented by the decimal value of two characters in the escape
sequence, often with an offset of 32 so that a space character represents row
or column 1, ! is 2, " is 3, # is 4... you get the idea. VT100 uses numeral
characters instead, so the string <ESC>[12;40H puts the cursor at row 12 column
40. Simpler for humans to understand, but less efficient because it transmits
six to eight bytes rather than four (<ESC>Y+G for the H19 to go to row 12
column 40).
Anyway, WordStar accommodates this in the terminal configuration by having
multiple fields for specifying the cursor positioning codes - the leading
sequence, the separator (if any), the trailing sequence, and a flag for
parameter order (R,C or C,R). There's also a flag to specify whether the row
and column values are numeral characters or the ASCII value of the characters,
and what offset (if any) they use. After I came to realize that some terminals
use the ASCII value of the characters, I paid a little more attention to the
output of SpellStar because I had noticed that it *IS* using VT100 sequences
(some text is in inverse video) and that they do change if I reconfigure WS.COM
for a different terminal, it's just the VT100 cursor positioning sequence that
it's getting wrong, and it's not entirely wrong because there are [;H sequences
littered all over the output. The thing is that it's just not paying attention
to the flag that says it should send the row and column values as numeral
characters rather than byte values, so it's sending stuff like
<ESC>[<Formfeed>;(H for row 12 column 40 instead. This, of course, doesn't
work, and makes me wonder if this is a known bug in SPELSTAR.OVR that can be
fixed - how could nobody have noticed this, unless VT100s were really really
uncommon in the CP/M days?
jim
