ldrcpy: AT&T UNIX PC System Install clues to CTIX?

Topic References:

CTIX S-80 MightyFrame Hard Drive root filesystem

CTIX S-80 MightyFrame Hard Drive /usr filesystem

Terminal grab from failed CTIX install on MightyFrame

UNIX PC Hard Drive full filesystem

UNIX PC Install Disk #3 (Floppy Unix)

This is what happens when the AT&T UNIX PC fails to write a new operating system onto a MFM hard drive (Winchester ST506).


I formatted the drive ahead of time, with the wrong parameters, and that "fooled" this system into trying to load, and then failing, giving me error messages with clues to what it was trying to do.

What is ldrcpy: ?  slightly off topic, but related.  I executed these instructions.  Here is the new boot screen I get after execution.

Could  CTIX install itself the same or similar way?

This is the floppy disk that was running when this failure occurred

So, reading the contents of the disk, here is what we see:

Let's see if I can find ALL of these files on the CTIX dump resources I have...then maybe trick the UNIX PC into loading this OS from floppy, or at least starting to...

Make a copy of the "Floppy Filesystem Disk" (Disk 3 of ##) of the Foundation Set as follows.

AT&T UNIX™PC Owners Manual - PDF Page 4: "Floppy disks can now be formatted with either 8 or 10 sectors per track"

Then, figuring out how to transfer files...over RS232 maybe?

Maybe this manual will help:  AT&T UNIX PC Remote Access User's Guide

and Kermit on the 3b1.    Download   and how to open UUE files

And the more specific thought process:

The Unix PC will format hard drives for itself, and if I plug that same drive into the MightyFrame, the MightyFrame seems to like the VHB, and says "executing loader from drive 0", and then hangs.  I'm taking this as a sign that it likes this VHB, and moves on to the loader, which fails to load, because it's for the UNIX PC, of course.

Well, if I get the right CTIX files on this drive using file copy on the UNIX PC, starting with the CTIX loader file (whichever one that is) using the UNIX PC VHB, could I create a bootable hard drive for the MightyFrame?

Overall, can I use the UNIX PC to create a CTIX bootable disk, assuming that the VHBs are either the same or compatible?


On the root of the floppy I take the screen shots of above, see the "list" file?  It must be an executable program, because it is running all of those other failed commands, right?

Well, here it is to download:  list

  .....

This is for my learning curve...
/bin directory
/dev directory
/etc directory
UNIX for DOS users

And what is  @(#)lorder.sh COMMON LORDER ?
One nearly identical to this is found on a MiniFrame tape contents at /fd_exp/bin/

-----

Allright, as far as using a UNIX PC to copy OS files, it seems like it cannot be the same drive that is running the OS for the UNIX PC.   So, I have 2 choices.  

1) Find a way to get the UNIX PC OS to run from floppies

2) Find a way to get the UNIX PC to recognize a 2nd simultaneous ST506 hard drive.
David Gesswein suggests this one:

ICUS II Hard Disk Upgrade


--------------------------------------------------------

Tape drive VHB

by Tom Trebisky on 10/12/2014:

I was fiddling around a bit yesterday, first doing some more study and annotation of the boot rom and then writing a short C program to experiment around.

I think I know now how to produce a VHB for the tape. Interestingly, the tape VHB uses the same format as the disk, but most of the fields are irrelevant and ignored.  As near as I can tell, there are only 3 fields that need to be correct for the boot roms to accept it, namely the UQVQ magic value in the first 4 bytes, a valid checksum in the next 4, and a 2 byte field deeper into the VHB that specifies the number of blocks in the loader image, which must immediately follow the VHB on tape.   Note that a "block" is 1024 bytes, which would be 2 sectors on disk, but on tape, we can write whole blocks of almost any size.

I played around making sure I knew how to write a C program to properly calculate the checksum.

So at some point soon we could try some experiments with this.

Note that the only function of the VHB here is to introduce what they call the "loader", which in actual fact can be any program you might want to run.  I would like to try just a simple "hello world" program to make sure we have all this right, then we could move on to other experiments if we want to.

--------------------------------------------------------

stage 1 loader, ldrcpy and all that
by Tom Trebisky on 10/13/2014:


We have talked about this before, but this is something else that will need to be gotten right before ctix will boot.  Inside the boot partition is a "stage 1 boot loader".  The game in booting is:

1) the roms run and look for a vhb on some device.
2) they find a vhb and the vhb points to the stage1 loader hidden in the boot partition.
3) the boot roms load the stage1 loader and transfer to it.
4) the stage1 loader loads /unix from the root filesystem

Two things about the stage1 loader.  One is that the UnixPC setup no doubt put one there (and in general set up the boot partition).  However the UnixPC loader will for any number of reasons crash and burn on the Mightyframe.  It will be built to run at a different address from one thing, and it will reference UnixPC hardware addresses for another.

The other thing about the stage1 loader is that I believe (but need to do some homework) that it needs to have block addresses injected into it to load the /unix kernel.  I may be disremembering this from some other system and/or even if this is true on the UnixPC, the Mightyframe may be different.

So, we need a mightyframe stage1 loader (and of course one is hidden in the Kossow disk image). I pulled that one out of the disk image, and maybe it will be possible to figure out how ldrcpy works and get it to reinstall it for us (along with injecting all those blocks numbers).

Anyway, I am not sure of a definite procedure here yet, just letting you know about the issues.

One problem might be that the loader on Kossow's disk is scsi specific. A positive thing might be that if I/we look around we may find a stash of loaders on one of the mightyframe images (I have looked a little without luck, but need to be thorough).

Well, looking on Al's disk image, I don't see ldrcpy or anything with the word "ldr" as a substring.

However, the is a directory /install that has some interesting scripts I am looking at. Are you aware of shell scripts?  At the first level they are just like a DOS "BAT" file, i.e. just a bunch of commands in a file, but at the next level the shell is an actual programming language with loops and if statements.  Anyway all the files in this directory are shell scripts.

There is some loader stuff in /usr/lib/iv that is referenced by those install scripts.
that I don't understand .....


--------------------------------------------------------

/dev/ - floppy drive and hard drive "slices"

by AJ at MightyFrame.com on 10/15/2014:

So, in this article, DoN Nichols, the surviving oracle of the 3b1, (whom will still respond to posts on comp.sys.3b1), says in this article:  

http://www.linuxmisc.com/4-linux/da79d399163dabe9.htm

"Normally the cpio files go to /dev/rfp021 on the 3b1, which is the second slice of the floppy, the first contains the VHB (Volume Home Block), wich tells the system how it is formated.  You may need to use dd to skip over this part of the floppy.  You can use "iv -t /dev/rfp020" to find out just how much of the floppy is claimed by the VHB. "

Does this give us some insight into how those /dev/ devices handle the hard drive and floppy?  Evidently these dev/xx can refer to all or part of the drive.  Interesting.

I've made a list of what I have figured out so far.:

Floppy Drive = /dev/fp021

Floppy Drive VHB = /dev/fp020

Hard Drive = /dev/fp002

Hard Drive VHB = /dev/rfp000

Verbose Loader = /dev/rfp020

---------------

Response by Tom Trebisky on 10/16/2014:

Don Nichols is a hero.  He was helpful and an absolute expert back when I was struggling with the 3b1.  The only thing that makes no sense in the list in the bottom is the one for "verbose loader".  Here is my take on this:

Consider a name /dev/fp0xy

Here x is the drive number and y is the slice.

  x = 0 is the hard drive.  x = 1 is never used on the 3b1, x = 2 is the floppy

  y=0 ignores all the slices (partitions) and shows you the whole drive,

  so it will give you the VHB as the first 1024 bytes, but then continues

  to procede through the entire disk, ignoring partition boundaries.

  y=1,2,... rattle through the partitions

Two notes here.  One is that the VHB is in a "header" section of the disk outside of any partitions and can only be seen by using the "whole disk device" /dev/fp000.

The other is that I know of no way to know how many partitions are in use and what for other than examining the VHB with one of my tools.  the s4diag program would probably tell you (but use it with great care).  Modern unix systems have a command "fdisk" that shows you the partition structure (and allows you to modify it).  Very dangerous.