Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: PUTR OS8 file size limit?

  1. #11
    Join Date
    Oct 2019
    Location
    Rapid City, SD USA
    Posts
    22

    Default

    I am confused. Copying a PDP8 text file can be a different thing from copying a binary. In today's world DATA is DATA and BITS are BITS (most of the time) but that is not true of these old files and file systems. I can see how copying a binary like the FORLIB.RL will result in a short corrupt file unless you tell it to copy the file as a binary. An ASCII mode copy will stop when it sees a ^Z embedded in the decompressed two 12 bit words to three 8 bit characters. I have never used PUTR but I did just read through the .doc for it. It looks like you should be using the /binary option when copying the FORLIB.RL. The manual specifically states:

    Files are assumed to be ASCII (NULs are squeezed out, two 12-bit words are unpacked to three 8-bit characters, etc.) unless the /BINARY switch is given; this default may be changed with the SET COPY command.

    They don't specifically say it but since they honor so many other PDP-8 isms I am pretty sure they stop when they see a ^Z when copying from a 12 bit media to the local dos drive. I am assuming that you didn't specify the FORLIB.RL copy as /binary. But none of this would explain why you get an output device full error. What program generated that? PUTR or PIP?

    How about copying your session here so we can see what is happening.

    Doug

  2. #12

    Default

    Hi Doug,

    Your the best! That /binary switch did the trick to copy the FORLIB.RL file.
    I've got a 87040 Byte file on my local hard disk so I think that is solved.

    I've made a new OS/8 disk image within PUTR and then I could copy the source file too.
    So that works also fine now...

    I had plenty of space on the disks with a lot of empty parts next to each other....
    But as for what I understand now, the file system doesn't take the next empty spot
    when it heeds it for a bigger file? Never used PUTR before but OS/8 seems to handle that
    without a problem. Or maybe it has been a coincidence that it has always worked well for me?

    Regards, Roland
    WTB: Case for Altair 8800 ...... Rolands Github projects

  3. #13
    Join Date
    Mar 2004
    Location
    Wilmette, IL (north of Chicago)
    Posts
    700
    Blog Entries
    1

    Default

    Welcome to SQUISH! This is invokes a PIP option to essentially copy a disk to itself, consolidating empty space in the process. Check it out in the OS/8 Handbook.

  4. #14

    Default

    Quote Originally Posted by jackrubin View Post
    Welcome to SQUISH! This is invokes a PIP option to essentially copy a disk to itself, consolidating empty space in the process. Check it out in the OS/8 Handbook.
    Thanks Jack!
    WTB: Case for Altair 8800 ...... Rolands Github projects

  5. #15
    Join Date
    Oct 2019
    Location
    Rapid City, SD USA
    Posts
    22

    Default

    Quote Originally Posted by Roland Huisman View Post
    I had plenty of space on the disks with a lot of empty parts next to each other....
    But as for what I understand now, the file system doesn't take the next empty spot
    when it heeds it for a bigger file? Never used PUTR before but OS/8 seems to handle that
    without a problem. Or maybe it has been a coincidence that it has always worked well for me?
    I think I understand your confusion now. When a program asks OS/8 to open a file for output it normally finds the largest <EMPTY> directory entry. In another reply I believe I said the first <EMPTY> entry which was not correct. It hands a number back to the calling program which is the block number of this empty space and the size of the space and marks that entry as tentative. If you know the number of blocks you will need then you can request this size and the system will find the smallest <EMPTY> entry that is greater than or equal to the specified size. If no <EMPTY> of at least this size exists then it is an error. You can only have one file open for writing at a time. There is nothing in OS/8 that automatically will combine adjacent empty spaces. PIP with the /S for Squish is what can combine all the empties into one large block at the end of the device. This can take quite a while if you squeeze a DECtape to itself. Optimally you would squeeze from one device to another. I was always nervous when doing this because a crash during a squeeze on a device to itself pretty much trashes your device.

    So what was probably happening was there was no single <EMPTY> large enough to hold the output file and you were assuming that the system would auto magically combine <EMPTY>'s to make a space large enough. PUTR would probably have similar restrictions although it would not necessarily have to.

    Keep in mind that OS/8 is for all practical purposes little more than a glorified program loader. The file-system is extremely rudimentary! I hope all of that is clear.
    Doug Ingraham
    2nd owner of Straight 8 SN1173
    5 other PDP-8's including an 8/i and a DECSet 8000
    SOL-20

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •