• Please review our updated Terms and Rules here

Anyone familiar with Wang OIS internals?

Chuck(G)

Chuck(G)

Gone, but never forgotten.
Joined
Jan 11, 2007
Messages
46,048
Location
Pacific Northwest, USA
The 8080-based WPs from Wang running OIS. There doesn't seem to be much at all on the OIS internals. I'm not interested in the hardware (I know there are a couple of schematics for OIS boxes on bitsavers), but the interface and organization of the OIS file system.
I'm trying to avoid re-inventing the wheel--I don't want to dedicate time to figuring the system out if someone already has the information.

Thanks in advance!
 
Thanks. I'm also in touch with a fellow who says that he has an OIS internals document. We'll see how this pans out. Worst case, I have to do my own sleuthing. It wouldn't be the first time. But do note that I care little about the hardware--it's the software that matters to me.
 
I'll let you know as soon as he finds it and passes it on. The Baker library at Harvard apparently has some OIS manuals, but nothing that deals with the inner workings.
 
Chuck(G) said:
The 8080-based WPs from Wang running OIS. There doesn't seem to be much at all on the OIS internals. I'm not interested in the hardware (I know there are a couple of schematics for OIS boxes on bitsavers), but the interface and organization of the OIS file system.
I'm trying to avoid re-inventing the wheel--I don't want to dedicate time to figuring the system out if someone already has the information.

Thanks in advance!
Click to expand...
Just seen this request. See bitsavers again (pdf/wang/ois/os-6). Co-incidentally I just posted the software interface spec for the OIS100 master. - This might or might not be what you want. If you are looking for the disk layouts, then that won't help. I'm currently working on a program to obtain 'directory' - Wang said 'Catalog' listings and to allow the extraction of files to local files. - To do that I'm having to memory dump what I can recall about OIS internals. Once my program starts working, I'm going to document the disc structure. There is some stuff on Jim Battle's site http://www.wang2200.org/docs.html but that is NOT OIS, but the earlier WPS systems.
 
What I had to deal with is OIS WPS (the 8080/z80 hosted systems; could be something like an OIS-140 system). I sussed out the disk structure and WP formatting codes and was able to process about 60 8" floppies (about 1,000 files) to correctly-formatted text. No file names, but 3-byte file identifiers. (The first sector of each disk does not contain "WANG").

I still don't have anything for a couple of disks using "Magic Notebook"--if you have anything there, I'd like to see it. The structure isn't like the other disks--allocation appears to be in 1K units and tied into an indexed database. I can find the initial block of a file and run down the links, but still can't figure out how the database ties in.

Jim wasn't able to identify the structure on my OIS stuff--his is mostly the 2200 VS material. The late 70s--mid 80s Wang WP stuff doesn't appear to be documented anywhere.
 
Last edited:
The first thing you describe is the WP document structure. If you have converted docs, then you know how that hangs together.

OIS has a label in block 0 of the disk. That has fields pointing to the Catalog - starts at the centre of the disc, no matter how big or small it is. That contains, like FAT discs a first FAT (VAU in Wang terms) number that addresses the first number of blocks of the file. - The VAU size is the number of blocks (a power of 2) that are allocated to a file at a time. The VAUMAP (located from the label block) can then be used just like a FAT to locate the next VAU's worth of blocks etc.

I'm trying to create an illustration document of this right now. Have you got MS Word?
 
Problem is that my sample size is too small to draw a lot of conclusions. I do have a disk with an OIS game on it "Misty Marsh" if that's any help.

I've already located the "Catalog" area on the disks. Let me show you an excerpt and see if you can figure it out.

Code: 
00026800  0b 43 61 74 61 6c 6f 67  00 00 00 00 00 00 00 00  |.Catalog........|
00026810  06 0e 09 04 52 02 0f 09  04 52 01 4d 00 00 00 00  |....R....R.M....|
00026820  00 00 30 03 00 00 00 00  00 00 00 00 00 00 00 00  |..0.............|
00026830  4e 4f 54 45 42 4f 4f 4b  00 00 00 00 00 00 00 00  |NOTEBOOK........|
00026840  02 0f 09 04 52 00 00 00  00 00 00 01 00 00 00 00  |....R...........|
00026850  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00026900  44 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |D...............|
00026910  02 0f 09 04 52 00 00 00  00 00 00 02 00 00 00 00  |....R...........|
00026920  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00026a00  31 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |1...............|
00026a10  03 0f 09 04 52 03 0f 09  04 52 01 01 00 8c 00 00  |....R....R......|
00026a20  00 00 00 00 00 d1 00 00  00 00 00 00 00 00 00 00  |................|
00026a30  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

And preceding that, we have what appears to be an allocation map:
Code: 
00026000  fe ff 02 00 03 00 04 00  05 00 06 00 07 00 08 00  |................|
00026010  09 00 0a 00 0b 00 0c 00  0d 00 0e 00 0f 00 10 00  |................|
00026020  11 00 12 00 13 00 14 00  15 00 16 00 17 00 18 00  |................|
00026030  19 00 1a 00 1b 00 1c 00  1d 00 1e 00 1f 00 20 00  |.............. .|
00026040  21 00 22 00 23 00 24 00  25 00 26 00 27 00 28 00  |!.".#.$.%.&.'.(.|
00026050  29 00 2a 00 2b 00 2c 00  2d 00 2e 00 2f 00 30 00  |).*.+.,.-.../.0.|
00026060  31 00 32 00 33 00 34 00  35 00 36 00 37 00 38 00  |1.2.3.4.5.6.7.8.|
00026070  39 00 3a 00 3b 00 3c 00  3d 00 3e 00 3f 00 40 00  |9.:.;.<.=.>.?.@.|
00026080  41 00 42 00 43 00 44 00  45 00 46 00 47 00 48 00  |A.B.C.D.E.F.G.H.|
00026090  49 00 4a 00 4b 00 54 00  fe ff 4e 00 4f 00 50 00  |I.J.K.T...N.O.P.|
000260a0  51 00 52 00 53 00 00 00  55 00 56 00 57 00 58 00  |Q.R.S...U.V.W.X.|
000260b0  59 00 5a 00 5b 00 5c 00  5d 00 5e 00 5f 00 60 00  |Y.Z.[.\.].^._.`.|
000260c0  61 00 62 00 63 00 64 00  65 00 66 00 67 00 68 00  |a.b.c.d.e.f.g.h.|
000260d0  69 00 6a 00 6b 00 6c 00  6d 00 6e 00 6f 00 70 00  |i.j.k.l.m.n.o.p.|
000260e0  71 00 72 00 73 00 74 00  75 00 76 00 77 00 78 00  |q.r.s.t.u.v.w.x.|
000260f0  79 00 7a 00 7b 00 7c 00  7d 00 7e 00 7f 00 80 00  |y.z.{.|.}.~.....|
00026100  81 00 82 00 83 00 84 00  85 00 86 00 87 00 88 00  |................|
00026110  89 00 8a 00 8b 00 8c 00  8d 00 8e 00 8f 00 90 00  |................|
00026120  91 00 92 00 93 00 94 00  00 00 ff ff ff ff ff ff  |................|
00026130  fa ff f9 ff fd ff fd ff  fd ff fd ff fd ff fd ff  |................|
00026140  fd ff fd ff fd ff fd ff  fd ff fd ff fd ff fd ff  |................|
I've gathered that the "fe ff" words refer to system-reserved areas, both at the start and in the catalog area.

We have text blocks interleaved with glossary (looks to be a tree) blocks. As far as having Word, sure--I use Libre Office for correspondence.
When I can extract the files reliably, then the next job is figuring out all of the formatting codes, which appear to be similar, but not identical to the WP ones.
 
Last edited:
OK, I have started on creating a document with all this in it, with as best a verbal description to help preserve this knowledge. You mentioned earlier that you had a contact who had an OIS internals document. - That should, if possible, find its way onto Bitsavers. So far it appears that I have been one of the largest contributors to pdf/wang - certainly as far as OIS is concerned and maybe largely for the VS. - Jim Battle gave be a large collection of VS related docs that I must send to Al Kossow.

The address for the VAU MAP (Volume Allocation Map) is found in the disc label (block 0) at byte 0x18 .. 0x1a (low byte first, 3 bytes to allow for large discs)

The start of the catalog are is also pointed to by the label in bytes 0x16 and 0x17. In this case is is held as a WORD value holding the VAU# of the catalog. The get the block no, multiply this word by the byte value in byte 0x1C.

There are 8 special VAU map entry word values:
//
// VAU Map Allocation Codes
//
#define VAU_FREE 0xffff
#define VAU_MAP_LABEL 0xfffe // VAU MAP or label
#define VAU_NOTEXIST 0xfffd
#define VAU_MASTER 0xfffc
#define VAU_MASTER_TRANSIENT 0xfffb
#define VAU_ALTERNATE_VAU 0xfffa
#define VAU_ALTERNATE_LABEL 0xfff9
#define VAU_DAMAGED 0xfff8
 
Ooops, accidentally posted that before finishing.

The catalog is a set of 0x30 byte records, 5 to a block. A link in the catalog is composed of 4 bytes. The first three are the file-relative block # of the next logical record in the tree, and the fourth byte is simply the byte offset in that record of the record being referenced. There are two such pointer fields in a catalog record. The first at offset 0x1e is called the same level pointer and links nodes at the same level. In your example it contains 00 00 00/30 which is in the same record (0) of the catalog file at offset 0x30, so is the NOTEBOOK node. This is a non-terminal (think directory) node so there is a pointer at 0x15 pointing to block 2, offset 0. That is a node called '1' and as byte 0x1A is a 1, then it is a terminal node (a file). In this case the 4 bytes at 0x1b onwards hold two words, the first being the first VAU number for the file, and the second is the number of VAUs allocated to the file. Other fields are the times and dates of last access and either creation of last write.

To locate a file called A.B.C, you start at the beginning of the catalog and follow the same-level links until you find A, checking then that A is non-terminal. Then follow the next-level link starting at 0x1b but now look for a node called B. Repeating the next and follow same-level links until you either find C of hit a zero link. - File not found. Also you should not from the requested file name that C must be a terminal node, so must also be a terminal node when found in the catalog.

The node for the file gives the first VAU#, multiply by the VAU size in the label (yours is likely 1) and you have the address of the first vau of the file. From here you use the Catalog First VAU number to get the VAU'th word entry in the VAU map. That value will be the VAU# of the next VAU. - Rinse and repeat for all VAUs in the file. - Remember that there will be VAUSIZE sectors in each addressed VAU. The last VAU may not be full. - Cannot recall where the marker byte for last block is in the catalog.
 
Thanks--I'll roll some code and see if it makes sense. My contact says he has some handwritten notes he made years ago, but to date, he's been unable to find them.
On the Magic Notebook files, the header (16 bytes) of each 1K block appears to contain a forward and backward link and I bunch of other information that I've not decoded yet. The links do not appear to compensate for the catalog blocks in the middle of the disk, so if the block numbers are higher than the catalog area, you add 48 sectors to them; if they're lower, you add 8. The blocks are not (most often not) full; figuring out where the valid data stops is another problem.
If you can run OIS emulation, I do have a demo disk image of Magic Notebook...
 
I feel that you are missing something. A file when accessed by a slave (Workstation, printer etc) is just a bunch of sectors. Any block numbers within an OIS data file will be just that, relative sector numbers within the file. If you have a file that appears to encroach on VAU map or Catalog, then my guess is that you are not following the VAUMAP chains. If your floppy has 1block/vau (check byte 0x1C of label), then only the first 256 bytes are directly pointed to be the Catalog entry for the file. To get the second, you will have to look in the VAUMAP by taking that first VAU number from the catalog entry, doubling it for word access and obtain the contents of the VAUMAP at that offset - That will be the address of the next VAU. For the 3rd block, use that VAU number to obtain it following VAU entry from the VAUMAP. I'm attaching a PDF of what I have done so far. Not necessarily 100% accurate. Another gotcha is the catalog itself is treated by the master software as just another file, and can become non-contiguous if the original allocation for it proves inadequate.
 

Attachments

I've got another real puzzler here. It's definitely OIS with a catalog area, but the content is odd--WP sectors, whose links don't correspond to the sector locations on disk. There are multiple versions of any sector (i.e. products of editing), so it's not a straightforward representation and I'm not entirely sure that the entire document is intact. I can pick out sectors belonging to the WP file because of the file ID in each sector's header, but assembling them into something that makes sense will be a challenge. I'm trying to figure out how this originated--part of a conversion program perhaps?

If you're wondering what I've got--it's a collection of disks from Wang's executive offices, circa 1979-1982. Since they belong to the client, I can't share any non-public content.
 
Thanks for the document--I'll let it stew a bit. Note that I'm working exclusively with floppies--I doubt that any hard drives with intact information from 40 years ago are still lurking around. I'd understood that the VAU map is pretty much the exact correspondent to the DOS FAT, with the exception it seems that if you lose the Catalog area, you're out of luck reconstructing files (with FAT, you lose only the file name and metadata). Of course, record formats can vary wildly--I was using the links in the Magic Notebook files, which seem to work and give a definite ending point (next link = 0000) without the catalog information. I'll work next from the catalog, now that the layout is known to me and the VAU map.

Here, for your edification, is the Magic Notebook demo disk image (16s/track).

 
Last edited:
Chuck(G) said:
Thanks for the document--I'll let it stew a bit. Note that I'm working exclusively with floppies--I doubt that any hard drives with intact information from 40 years ago are still lurking around. I'd understood that the VAU map is pretty much the exact correspondent to the DOS FAT, with the exception it seems that if you lose the Catalog area, you're out of luck reconstructing files (with FAT, you lose only the file name and metadata). Of course, record formats can vary wildly--I was using the links in the Magic Notebook files, which seem to work and give a definite ending point (next link = 0000) without the catalog information. I'll work next from the catalog, now that the layout is known to me and the VAU map.

Here, for your edification, is the Magic Notebook demo disk image (16s/track).

Click to expand...
Thanks, I'll have a look.
 
I'm going to put a few new docs on bitsavers. Mostly this sort of WPS stuff, as I have no original Wang OIS docs - I used to, but cannot find them (two house moves - they might exist here still, but I suspect not.)
 

Attachments

Looking at your magic notepad disc - never seen that before.

Dump of VAU Map for Volume 'SP041011'

Each word represents 16 sectors of space on disc

The VAU Map begins at VRSN 0x000250
The Catalog behins at VRVN 0x0026 (Sector 0x000260)

0000: fffe ffff ffff ffff ffff ffff ffff ffff
0008: ffff ffff ffff ffff ffff ffff ffff ffff
0010: ffff ffff ffff ffff ffff ffff ffff ffff
0018: ffff ffff 0000 0000 001b 001c 001d 001e
0020: 001f 0020 0021 0022 0023 fffe 0027 0028
0028: 0029 0000 002b 0000 0000 0000 0000 0030
0030: 0031 0032 0033 0034 0035 0000 ffff ffff
0038: ffff ffff ffff ffff ffff ffff ffff ffff
0040: ffff ffff ffff ffff ffff ffff ffff ffff
0048: ffff ffff ffff fffa fff9 fffd fffd fffd
0050: fffd fffd fffd fffd fffd fffd fffd fffd
0058: fffd fffd fffd fffd fffd fffd fffd fffd
0060: fffd fffd fffd fffd fffd fffd fffd fffd
0068: fffd fffd fffd fffd fffd fffd fffd fffd
0070: fffd fffd fffd fffd fffd fffd fffd fffd
0078: fffd fffd fffd fffd fffd fffd fffd fffd

The label gives the VAU map start and Catalog starts. The Catalog according to the Label starts at VRSN x260 of VRVN x26.

Looking at entry x26 of the VAU map, it contains x27, in turn x27 contains x28, with x28 containing x29. x29 contains 0. Therefore the Catalog seen as a regular file occupies 4 VAUs (64 sectors) and physically resides in VAUs (x26,x27,x28 and x29). This means that the catalog can in this case be treated as a contiguous sequential file on disk, - do not assume that on discs that have been heavily used. As the VAU size is 16 sectors, space is effectively allocated in tracks. As there are onlt 77 (x4D) tracks VAUs 4D and higher contain 0xfffd (NON_EXISTENT). As a zero indicates the END vau of a file, there are eight files on the disc (including the Catalog).

Also note that OS-6 allocates files from the centre of the disc outwards. The free areas (xffff) are at the start and end of the disc. There is a file starting at x24, which is before the VAUMAP so it allocated towards the outside, so the links are running x24,x23... downto x1A. That is something that I 'knew' but had never seen so clearly. This might well explain your seeing all your data, but not necessarily in the right order. If a file is extended then it will be extended either towards the end or to the start depending on whether it started in the first or second half of the disc. If that half if full, then it will start allocating wherever space can be found.

The links that you are following in WP documents for example, are file-relative and only apply within the document file. They are only related to disk locations by use of the VAU map.

You mentioned OIS emulation, I got one from Jim Donohue years ago, but it was lost in a disc failure half way through copying it to a new laptop. He moved jobs a few times and I lost contact.

What are you using?

I might try installing Magic notebook on my VS, with some judicious file renaming I think I should be able to get it to run. - What is it?
 
You must log in or register to reply here.
Back
Top