• Please review our updated Terms and Rules here

SYmbolic Editor EDIT

We have just as many errors on this side of the pond as you guys have the other side.
Update, I copied the E8 files into simH and they assembled, the program would not run, but there were no assemble errors. So, I wanted to compare the original E8 files to that was what I got into the PDP8E. Turns out when I used EDIT, I would get 14 or 15 blocks, which equates to between 1/3 or 1/2 of the the original file. I then tried PIP and all I could get was about 3 blocks, but the code was not continuous. So this is the reason I was getting errors, not all the code was there. The next thing I want to try is to make even smaller files to transfer and try to see if I can get 'all' code into the PDP8E.
Not sure why PIP will not receive more, but I believe that EDIT is limited to the size of the input buffer, more to come, Thanks, Mike
 
Well..... I split the E8 file into two smaller files. Then transferred them to the PDP8E. Both made it in complete form. Is there a way to concatenate files in OS/8?, Mike
 
DEC ASCII on the PDP-8 is not the ASCII used today. It is expected that the MSB of the 8 bit character is set to a 1. Many but not all programs on the 8 will AND the character with 0177 octal to strip the bit. Because of this most of the time this does not matter. I can't think of any programs that don't treat TAB as a space.

The OS/8 file system does not have a length in characters, the file length is in blocks of 12 bit words. For text files it is expected that the file ends with control Z which in DEC ASCII is 0232 octal. Some programs will pad to the end of the block with 000.

Text files are packed three 8 bit characters to two 12 bit words. The handlers are expected to do this packing and unpacking. Programs that read and write text files will need to do this packing as well. This means a 14 block file would be up to 5376 bytes. A file of 16 blocks is exactly 4096 words or 5144 bytes. Does EDIT use more than 4k words of buffer space? I don't know, maybe I did at one time.

There can be a lengthy delay when the carriage return at the end the line is seen while the packing is done. Since there is no concept of flow control you can expect overrun errors. One approach would be to wait for the character to echo before sending the next one. This cuts transfer rate in half. Most of the time you only need to wait when a carriage return is sent. SIMH does not have these problems because overruns don't occur in the simulation.

For all these reasons it is a good idea to use a file transfer program.
Mike_Z said:
Well..... I split the E8 file into two smaller files. Then transferred them to the PDP8E. Both made it in complete form. Is there a way to concatenate files in OS/8?, Mike
Click to expand...
Sure. PIP will do it.

*COMBO.TXT<FILE1.TXT,FILE2.TXT/A

Is what I think will do it.
 
I use FileZilla to transfer between WIN7 and the IBM XT, but that is over my network. I've tried KERMIT between the IBM XT and the PDP8E, but seems that Kermit adds formatting characters to the transfer. Doug, what file transfer program works? Any suggestions? Thanks, Mike
Tried the Combo.tx<F1.TX,F2.TX/A and it works fine, thanks
 
Last edited:
I use putty and minicom.

We use putty and hyperterminal on a PC and minicom on Linux (but it is also available for Windoze of course as well). I can't remember whether both putty and hyperterminal can transfer plain ASCII or just one of them.

In both cases you want plain old ASCII - but noting that DEC ASCII has the top bit set. That confused me the first time I saw it! Most programs ignore the top bit, but I have identified the odd program that does check. You have been warned!

One advantage of minicom is that it doesn't transfer the ASCII characters itself, but invokes separate programs to do that. I have been thinking of writing a little 'C' filter program to set the top bit.

Dave
 
Hmmm.... I use Putty to start Serial Disk on my Raspberry PI. I'll have to look into how to use it on a RS232 connection. First I want to bust up the E8 files into smaller ones, transfer them to the PDP8E and see if I can assemble the program there. So far it seems to be working, but it is labor intensive. Thanks for the help, Mike
 
Kermit should work. What do you mean when you say it adds formatting characters?

And almost anything should work if the file length is short enough. Something under 3k characters.
 
Actually, MS DOS copy works, if the file length is <3k. I have tried KERMIT, but have had trouble, At the time I blamed what the Book calls packages. I assumed that KERMIT transferred data in packets. Maybe there is a different mode I can use. I'll have to take some time and try again. Mike
 
You know, maybe my problem with using Kermit was that I was using msdos Kermit on one end and OS/8 programs on the other side. I didn't realize that there was a Kermit-12 for the PDP8. More stuff to look at! Mike
 
Hot Dog! I finally got all the E8 files into the PDP8E and they assembled without an error. This E8 Emacs editor is pretty neat. Apparently the Emac editor has been around for some time. I was completely unaware of it. I may have a little tuning to do to get the screen size optimal, but I can start E8, load a text file, navigate around in the text and save and quit. There is more functionally that I need to learn, but first I want to attempt to figure out why I could use EDIT to transfer files and had so much trouble using PIP. For some reason, using the same procedure as I used with EDIT, PIP would get a few lines of text, then miss a bunch of text, get a few more lines and continue in this fashion. When EDIT received a transfer of a file about 4k or so, the PDP8E DIR reported a file size of 12-13 blocks. The same transfer using PIP resulted in a file of only 3 blocks. Obviously, I was doing something wrong. This is how I started PIP;
Code: 
R PIP
*E8.PA<TTY:/A
I guessing that PIP would receive some text, but then stop to save the text, all the while text was still being sent. This part of the text would be lost. I'll have to read more about PIP and try a few things. Maybe I can get it to work better. I'm guessing that PIP also has a buffer of some sort that fills and needs to be emptied. Maybe that buffer size can be increased?
The other item I want to try prior to learning about E8 editor, is if I can load KERMIT-12 into my PDP8E. I believe that if I can get that to work, then I can transfer larger files between any KERMIT computer and the PDP8E. I found some software, but do not know exactly what I need or how I will load it. The adventure continues, Thanks for the help, Mike
 
Today, I experimented with PIP to transfer files. But nothing I did transferred a file completely. I tried ASCII, IMAGE and BINARY. ASCII works the best, but still losses much of the file. At 9600 baud, PIP will only save between 2 to 3 blocks of data, that EDIT saves 14 to 15 blocks. The BINARY or IMAGE modes really mess up the file. The next test was to slow down the Baud rate to 110, This time more of the file was saved, but still not completely. At 110, PIP would save 10 blocks, but not the entire 15. Either, I'm doing some wrong or this method of input was meant for a TTY typist, who types slower than 110 baud. I suspect that PIP takes time to convert and save the received data, resulting in lost data while it is doing it. Apparently, EDIT does not do anything like this, it just loads the received data into it's input buffer and as long as the received data does not over run the EDIT input buffer, it works.
On another file transfer method, KERMIT, I got KERMIT-12 installed on the PDP8E and it works. I have successfully transferred a 10K file from KERMIT-80 from my IBM XT to the KERMIT-12 on the PDP8E at 9600 baud. The transfer was complete and had no errors. Then I got a little greedy. I attempted a transfer from the PDP8E to the IBM XT over KERMIT. This did not work.
The method I used for IBM to PDP was to start KERMIT-12 and enter a RECEIVE command, then switch to the IBM and enter a SEND B:/E8.PA command. I had to do this promptly, otherwise the KERMIT-12 would time out. But if I hustled the file would transfer with no errors.
I tried the same method for a transfer from PDP to IBM. The problem here is that a KERMIT RECEIVE command will wait a little for transmission, whereas the SEND command starts immediately. So I tried to start the RECEIVE on the IBM and hoped to switch to the PDP to SEND, But once the IBM KERMIT-80 entered receive mode I was not allowed to switch to KERMIT-12.
I wonder if my physical connection could be part of the problem. I have one RS-232 cable between the IBM XT and the PDP8E. On the IBM side the keyboard and monitor are not dependent on the RS232 connection, where as the PDP8E is. I'm not sure how I could connect the two machines to get a PDP to IBM transfer to work. Has anyone used KERMIT-12? AND I have been looking for more information or a users manual for KERMIT-12. There is a boat load of information regarding KERMIT-80, but most of the KERMIT-80 commands do not work on KERMIT-12. Thanks, Mike
 
You must log in or register to reply here.
Back
Top