• Please review our updated Terms and Rules here

Using WordStar 3.0 with CP/M 2.2

Mike_Z

Mike_Z

Veteran Member
Joined
Dec 1, 2013
Messages
1,713
Location
Near Milwaukee Wisconsin
My CPM62 system seems to be working fine, the other day, something went wrong. I have successfully obtained a copy of WordStar 3.0 and got it work with the CPM machine. I remember using WordStar at the power plant long ago and some of the functions came back to me and some I had forgotten. Anyway I can load, save, navigate, cut and paste, do a lot of things. The best part of this is that I can do all the work on the CPM machine and do not have to transfer anything from disk/disk or over a link. Everything was looking rosy. So, I converted one of my programs from my old assembler to the ASM, so see how the WordStar would work. Seemed fine, until I tried to assemble it with ASM. Then the whole thing blew up. I was getting bad sector errors all over. My first thought was that one of my disk drives failed again. So I spent days testing each of the three drives, alone and with each other. Seems the drives were OK. Checked my cabling, it was fine. I reformatted a bunch of disks and started over. I figured maybe my old 8 inch disks were catching up with me and causing the errors, but this was not the case either. Turns out that the problem is with WordStar. Seems that every 55 lines of text, WordStar would drop a carriage return. Each line ends with a CRLF, but WordStar would save line 55, 110, 165, 220, etc. with only a LF. This was causing the problem. So after starting over again and getting the CPM system to work I tried doing the same test editing with WordStar this time checking the saved text prior to using ASM and you bet your life every 55 line only had a LF. So using ED.COM I fixed the text and then ASM worked and after LOADing my finished program worked like a champ.

But I can't figure why WordStar is doing this. 55 lines is the default for a page length in the version, I wonder if there is something with that. Any ideas? Perplexed, Mike.
 
Any chance you're using WordStar document mode to create source code, instead of non-document mode?

Andy
 
It sounds like he's printing to a file, else the LF wouldn't line up with page boundaries, I suspect.

Mike, is that the only thing that looks out of place in the file? Would you be able to see if bit 7 is set in any characters?

I don't remember much about Wordstar but it seems to me there was a menu where there might be a setting for how it performs a formfeed. I have absolutely no recollection of a key combination that would get you to such a menu.
 
From my genuine printed in Hong Kong ~1982 WordStar Reference/Installation/General Information Manual:

"Command N - Open a Non-Document File. Same a D (Open a Document File) except that the file is edited as a non-document , without dynamic pagination and with different defaults. Use D, not N, for normal WordStar word-processing..."

Mike
 
I know that the file must be saved prior to printing. Yes I'm using the saved file. Nothing else is changed in the file. At least as far as I can see.

Looks like you (AHM) are correct. I need to use the Non Document option in WordStar. This brought up some questions that I'm still looking for the answers. What is the formatting difference between a WordStar Document and a Non Document. This is what I found

1. Page breaks are not displayed with a non document file. I think that a form feed (page break) is saved with the document file instead of the CRLF at the 55th line (page length) and this is why I get this error, I'm seeing.
2. The ruler is missing.
3. Word wrap is off.
4. Seems the margins are different.

So I think is know how to avoid my problem, by using the non document. My questions are,

1. When starting WordStar with a filename, WS FILE.ASM, assumes the file is a document and loads it as such. Can I load a non document from the command line, or must I use the N command?

2. Seems if I open a document file with the D command, it will have the page breaks in it. If I then load the same file as a non document (N command) it is loaded and saved as a non document (no page breaks). So, the file itself doesn't have a header or anything else that tells WordStar what type of file it is. It is all a matter of how the file is loaded? is that correct?

Thanks Mike
 
Just got back from walking the dog and on the way I thought I'd try an experiment. First make a TEST.DOC as a WordStar document using the D command and then with the N command then compare them with DDT. I made the TEST.DOC with just consecutive numbers only and saved it. Then with DDT I opened the Document. The file was ASCII characters of a number then the CRLF 0D0A. But after the 55th number there was a 0D8A. The 8A must be the page break, I had thought I'd find a form feed, but that was not the case. So I opened the same TEST.DOC again as a non document and saved it. DDT again showed the 8A on the 55th line. Apparently, once a file is saved as a document the 8A's will stay. I then erased all the TEST files and rewrote it, but this time as a non document. DDT reported no 8A's at all. Other than that the files were identical. So, I'll have to start my ASM files as a non document and stay that way. Can't figure why the 8A would have blown up my assembly with ASM, unless I made some other mistake. Been looking around on the net and found some stuff on non documents, but nothing that talks about this specifically. Maybe I'll look for some old books on Amazon or some place. Thanks Mike.
 
$8? would likely be unexpected in a plain text file. For some reason your assembler thinks anything beyond a 7-bit character is a disk error.

Setting bit 7 on a character was a common way to separate words/paragraphs/pages in word processors.
 
Well.... for some reason the 8A is at the end of each 55th line, 55, 110, 165, 220, etc. Just of grins, I thought that I'd look for the 8A's in my original ASM file, they are not there. What I found is at each page break, there are a bunch of spaces (10, maybe they are just filling the line to the end) and then the next line begins, no CRLF, 8A or nothing. Interesting about the Bit 7, that could be a clue. I'll keep it in mind. Thanks Mike
 
IIRC, WS uses the 8th bit to differentiate "hard" vs. "soft" spaces and returns. This is because WS in document mode can justify and paragraph text automatically by inserting "soft" line feeds and spaces. Thus:

All WordStar files terminate normal lines (paragraphs) with the sequence <0Dh,
0Ah> (carriage return, line feed). A "soft return" <8Dh, 0Ah> is inserted in
the text stream at the points where lines are subject to word-wrap. A "soft
space" is inserted for tabbing, justification, and for left-margin
indentation. In normal mid-paragraph lines, the blank characters (usually
space) following words at the end of lines will be retained, so that the
user's text is fully retained.

An "inactive soft hyphen" <1Eh> is inserted in the text stream at places where
hyphenation may be allowed to occur. When the word is actually broken at the
hyphenation spot, the inactive soft hyphen is changed to an "active soft
hyphen" <1Fh>. This active hyphen, since it falls at the end of a
mid-paragraph line, will be immediately followed by the soft return mentioned
above.

In versions of WordStar prior to 5.0, the high bit was set on the last
character of all non-blank text strings that fell within the margins. The
printer drivers relied on this information to determine which text was to be
microjustified. This functionality was dropped in the later versions in
favor of the use of absolute tabs, margin dot commands, and paragraph styles.
Click to expand...

All of which is why you want to use non-document mode to edit program files.
 
About 100 or so years ago I wanted to be able to run a C compiler on my Heathkit H89. Being somewhat short of funds I decided the only feasable way to go was to adapt the Tiny-C compiler that had been published in Dr Dobb's Journal to run on HDOS. So I typed the whole thing into whatever text editor came with HDOS, transmitted it at a blinding 300 baud to one of the PDP 11/70's at work and compiled it. Or tried to anyway. My plan was to create a cross compiler that ran under Unix and generated 8080 assembly code. What I got was more error messages than I has source lines. A more experienced tech then sat me down and explained about how various systems had very different ideas about how to terminate a line in a text file. Live and learn. I eventually got Tiny-C running under HDOS and have pretty much been "playing" with computers in some fashion ever since.
 
Other than the use of the 8th bit, what is the difference between "hard" vs. "soft" spaces and returns? Excuse me, I read the italic text above (which is difficult to read) and now I 'think I understand. Thanks.

Mike
 
The basic difference (and the reason for the use of the 8th bit) is that in document mode, WS performs some formatting, such as line justification, wrapping, page-fitting, etc.

WS needs to be able to differentiate between characters it generates to justify and page-fit ("soft") and those characters that were actually entered by the user ("hard"). For instance, if you specify that text is to be flush-right, there will be a bunch of added spaces to the beginning of a line to create that effect. If text is to be justified (text spread out to fill a line), then spaces will be inserted between words. Those spaces aren't part of the user's text; they're added by WS to create the desired effect--they're "soft" spaces.

Similarly, if WS in document mode is formatting your paragraph text, it inserts a linefeed/carriage return when necessary to ensure that lines contain no incomplete words and fit the space between the margins. So those inserted linefeeds are "soft" and have the high-order bit set. If a user hits the return key while entering, that's a "hard" line break that cannot be removed by WS.

Non-document doesn't do anything with that--what you get is what you enter. No added characters.


And so on.
 
Mike_Z said:
Other than the use of the 8th bit, what is the difference between "hard" vs. "soft" spaces and returns? Excuse me, I read the italic text above (which is difficult to read) and now I 'think I understand. Thanks.

Mike
Click to expand...

Hard spaces and returns are entered by the user. Soft spaces and returns are created by WordStar. Soft returns would show up at the end of every line if all the text was entered in one continuous block. Soft spaces would be added by WordStar to spread out what is typed if the line was to be justified to both margins. As the document is edited, the soft spaces and returns will have their position in the document changed.

WordStar documentation covers this in exhaustive detail.
 
I'm beginning to get rather comfortable with Wordstar and am learning more each day I use it. It sure seems to be a robust program for an 8 bit machine. I picked up a couple of books and downloaded some. One thing that I have not seen any information is are there any command line options with Wordstar. I'm using version 3.0

I have tried typing 'WS FILENAME.DOC' and this will open the filename document as a document file. Is there other command line options? Thanks Mike
 
There is a patch point for starting WS in non-document mode by default. The installation guide mentions it, but also says that you have to buy the WS "Customization Notes". At the time 3.0 was released, it was about $500 for a very thin document. However, the information leaked out.

So to get the option, patch the location "NONDOC" to 0FFH. It should be zero in your copy. If you want to have two separate programs; one document, the other, non-document, just copy your WS.COM to another file, say, WSN.COM and patch that one. So "WS filename" opens filename in document mode and "WSN filename" opens filename in non-document mode.

Easy, isn't it?

P.S. If you're using 3.30 and not 3.0, the locations are different. Herb Johnson has the 3.30 locations somewhere on his retrotechnology site.

FWIW, I also have WS 4.0 for CP/M-80 and I believe that it doesn't keep the non-doc default secret.
 
Thanks, I'll try this after the foot ball, maybe this evening. Not exactly sure how I'll find the 'NONDOC' location. Would I open WS(N).COM with DDT? I am using 3.0. Thanks Mike
 
Check the Winstall program. According to the WS 3.3 documentation, going to menu item "E" Features and then option "C" underneath would allow setting WordStar to default to non-document mode for files opened on the command line. Let MicroPro find the location that needs patching and do the patching for you.

WordStar inspired text editors for programming were practically a cottage industry in the 80s. VDE and ZDE were two of the major offerings for CP/M in that vein. Might be easier having the editor with the excess elements already removed than tweaking WordStar into that.
 
Last edited:
Mike's using WS 3.0. You'll see no mention of that option in the WS 3.0 Installation manual.

I'm still using the same text editor I used under ISIS and CP/M, just ported to DOS. Very small and has the features I'm interested in. One of these days, I'll add long filename support...
 
You must log in or register to reply here.
Back
Top