• Please review our updated Terms and Rules here

SYmbolic Editor EDIT

Mike_Z

Mike_Z

Veteran Member
Joined
Dec 1, 2013
Messages
1,713
Location
Near Milwaukee Wisconsin
For the past week or so, I have been working on understanding the code for RESORC. I have been using EDIT to look at the code and PAL8 to assemble it. Everything seems to be working pretty good. Yet I have trouble with examining the RESORC.LS listing using EDIT. When I get to page 9-1 of the RESORC.LS file, EDIT reports 'FULL' and goes back to the command prompt. I pretty sure that the FULL is not referring to the text buffer, but it could be the output buffer. I also thought that maybe it was my Drive was full, so I removed a bunch of files. There is plenty of drive space. Anyway, I'm thinking that I'm approaching the limits of EDIT to examine larger files. Is there a better program that will work with larger files.
When I first used CP/M, I used EDLIN, which is much the same as EDIT, and can also be a pain in the cerebral cortex. Then I discovered that WordStar worked much better. Is there a screen editor vs this line editor available for OS/8? Thanks for the help, Mike
 
Sure,
Code: 
.R EDIT
*RESORC.LS<RESORC.LS
#R
#L
This will list the first page of the listing file. Then I will do a bunch of #N's to move the text buffer to the desired area and #L to see where I am.. This requires about 25 #N's/ #L's. Can look at all the pages up to and including page 9-1 but a request for the next page results in the 'FULL' response.
Just to verify what I'm saying, I tried just a bunch of #N's and after 25 of them EDIT came back with a ?, then a new line with #, but would not respond to any command except CTRL C. Mike
 
There's some new terms. After doing a DIR/E, I find quite a few <EMPTY> listings, ranging from 15 to 280. After doing a SQUISH SYS: seems all the the <EMPTY> is on one area and is equal to the available space on the drive. I assume that, programs use this 'empty' space, but can not bridge a gap between empty spaces? I'll re try using EDIT and see if I can get past were I was.
I read the document on TECO, It seems to be an incremental step above EDIT. The user still has to keep track of where you are and there is still a buffer, which segments the code if it is large. Anything closer to WordStar? I suppose that a WordStar like editor would be difficult to use on the ASR33, Thanks for the help, Mike
 
Mike_Z said:
I assume that, programs use this 'empty' space, but can not bridge a gap between empty spaces?
Click to expand...
Yes, that's correct.

There's also that super-cool emacs-like editor that someone wrote a year or two ago. I'd have to look up the details, but I think maybe it comes in the PiDP build now? (I wanted it to be NANO comapatible for the Linux crowd, but it isn't quite.)

Vince
 
I found this 'E8 is an Emacs-like text editor created by Bill Silver for the PDP-8 family of minicomputers.' I'll look it over and see if I can use it, Thanks, Mike
 
If I remember correctly, when OS/8 opens a file for write it uses the first open block (the first <EMPTY>) unless the program tells it the output file size. I suspect the first open block was too small. The squish should resolve it for a while.

Of course if you want to do it the way we did back in the day you would print the listing (preferably on green bar) and then just read the printed listing.

I am not saying you should do it that way but it would be one way.
 
Yup, but it takes a LOOOONNNGG time at 110 baud. Well anything seems to take a long time at 110 baud.
I'm intrigued with this E8 editor. I down loaded the files and figured out a way to transfer them to the PDP8 using KERMIT on my IBM XT. This will take some time. Then once it is installed, I'll have to use my CIT - 101 monitor instead of the ASR 33. Let you know how it works out. Thanks, Mike
 
Over the weekend, I downloaded the E8 files and have attempted to move them to the PDP8E memory, but so far I have failed to get them to assemble properly. The problem has been with the transfer methods that I've used. First, the downloads were on my Win7 machine. Then I moved them over my network to my IBM XT machine. From the XT I tried to use KERMIT to send them to the PDP8E. Although using Kermit was only for a terminal connection. I would start EDIT and define a file name
Code: 
.R EDIT
*E8.PA<
#A
Then I would exit KERMIT and via DOS do a
Code: 
COPY B:\E8.PA/B COM1:
Then returned to KERMIT to save the transfer, but OS/8 would not respond. After thinking about this, I needed a CTRL L to bring EDIT back to the command mode, so I added a 0CH to the end of all the E8 files and tried again. This time the transfer worked. Upon returning to KERMIT I could do the #E to save the file.
Then I tried to assemble them and got 730 errors. I think the problem was that I used the /B, binary to transfer the files. Looking at E8.PA, for example in EDIT, it appeared goofy.
Started over with the transfer, this time using the /A to do a ASCII transfer
Code: 
COPY B:\E8.PA/A COM1:
This worked better, The files looked more like real text, yet the assembly still reported a boat load of errors. I still think that there is some problem with my file transfer method. Next step is to compare the files in the PDP8E with the Win7 machine. Still hopeful that I can get the E8 editor and display program to work, Mike
 
Mike,

Why do you start poking hornets nests!

The line terminator comes to mind as a problematic area!

Can you post a small section of the error listing?

Dave
 
I'm working on it. After walking the dog, I figured that maybe I have to remove the FormFeed from the end of each program. I'll give that a try later. Thanks, Mike
Hornets? Just having fun.
 
Ten to one Windows will have changed the line terminator into a CR/LF pair.

I can't just remember offhand what OS/8 requires.

I have the same problem copying between Windows and OS/X (if I forget). Easily remedied though.

However, when I first did it wrong many years ago, I got an assembly error on each and every line of source code - that was the clue...

Dave
 
Well.... I don't think that the CRLF is the problem. After I transferred a file and compared the original to the received file in the PDP8E, I found that a number of the problems are related to a TAB 09H character. Seems that when a TAB character is encountered the characters after the TAB are lost. Sometimes one character sometimes more. So as an experiment I changed the first TAB in the E8.PA file to a SPACE 20H character, then resent the file. This time the associated error was not there, the characters of the original and the sent file, at least for this line was correct. Looking over the first page of text, it appears that most of the errors occur after a TAB character is sent. I've seen in the Doc's that two or more spaces are converted to a TAB, but how are TAB's handled? Could it be that when a TAB is encountered, in a read of EDIT, does it convert that character to 4, 6 or 8 spaces. Then does the time needed to do this cause EDIT to miss a few sent characters? The IBM XT does not stop sending. Then when EDIT starts receiving characters again the text looks good. This seems to match what is happening. I tried to connect the RTS/CTS, but it appears that the 8650 does not have handshaking. I want to investigate how EDIT handles a TAB and look at the files and see how many TAB's are in them and how difficult it would be to change them to spaces. Thanks for the help, Mike
 
I was going to suggest the TAB character next, but you found that yourself. Well done!

I can't help you with EDIT at the moment, I am on a business trip - so access to not much for a few days.

But, yes, RTS/CTS (hardware handshake) is not supported at all.

You could try XON/XOFF (software flow control) to see if that is supported.

Failing that, it is "transmit and pray" mode (slowest baudrate).

Incidentally, I generally use PIP to read in files rather than EDIT. This may be quicker?

Dave
 
Don't worry about helping, although I appreciate it. Especially from a still working man. Currently I'm transferring at 9600, but could slow down to 110. That does take some time, my attention can wonder. I changed all the TAB's to SPACES's and that corrected some stuff, but there are still a LOT of US errors and others. I think that maybe the US errors are more spelling problems. I'll have to look for some of the problems. I will try PIP next, just to see if the same trouble arises. Thanks, Mike
 
US errors? Your machine must be an import from the UK then :)...

Set transfer going then take dog for a walk...

Dave
 
You must log in or register to reply here.
Back
Top