> -----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