• Please review our updated Terms and Rules here

Anyone familiar with Wang OIS internals?

For a reason that the label stores the VRSN (sector number) of the VAU map and the VRVN (VAU# of the catalog), The catalog is allocated and accessed by the MASTER code on disc just as any other file. All files hold their first VAU# in the catalog, so it makes sense to store the VAU# of the catalog in the label so that a file open can be performed simply by passing a routine that first VAU# just as all other opens do.
 
Forgive my confusion, then--but why is the VAU map address given as a sector number instead of a VAU number in the label sector? The catalog is give a 2-byte VAU number in the label, after all. Since the VAU size is also given in the label, a sector number is easily calculated from that.
 
Among the first things that MASTER does on mounting a volume will be to read the VAU map, It is NOT a file, so it makes more sense to address it via a sector number. I think that makes sense. The only thing that ever looks at a VAU map is MASTER itself, and one special utility, the volume recovery program (fsck).
 
At offset 0x20 in the volume label, there is a one-word hash code. Do you have any idea how it is computed? I'd like to use it as a sanity check.
 
Chuck(G) said:
Forgive my confusion, then--but why is the VAU map address given as a sector number instead of a VAU number in the label sector? The catalog is give a 2-byte VAU number in the label, after all. Since the VAU size is also given in the label, a sector number is easily calculated from that.
Click to expand...
I don't know for certain why they coded those like that.

A sector number is what the low-level read/write primitive routines use.

VAU# is a layer above, concerned with files. - I can really only image it was coder convenience, when the Catalog is opened during mount as a file.

Also, maybe these values allowed the recovery program an easier task and a way to perform consistency checks. The VAU sector pointer + the VAU sector count could be related to the Catalog VRVN using the VAU size from the label. I would suspect, hey - no almost bet that the volume recovery code would perform checks on the consistency of these numbers.

The two check bytes. - Easy :)

To calculate set them both to 0xff. Then count the number of zero bits in the label sector.

//
// The volume label is checked with a simple checksum. This sum is calculated
// by setting the checksum bytes to 0xff, then counting the number of 0 bits
// in the sector. This value is stored in bytes 0x20..0x21. Validation is performed
// similarly.
//
// This routine checks that the sum in the label block is correct, based on the
// Z80 (PLM???) code.
//
bool COS6Volume::ValidateLabel( )
{
UINT BitCount = 0;
BYTE csum [ 2 ];
csum [ 0 ] = m_Buffer.Data [ 0x20 ];
csum [ 1 ] = m_Buffer.Data [ 0x21 ];
WORD sum = csum [ 0 ] + ( csum [ 1 ] << 8 );
m_Buffer.Data [ 0x20 ] = 0xff;
m_Buffer.Data [ 0x21 ] = 0xff;
//
// Count the zero bits in the block
//
for ( int i = 0; i < 256; i++ )
{
BYTE b = m_Buffer.Data [ i ];
for ( BYTE j = 0; j < 8; j++ )
{
if ( 0 == ( b & 0x80 ) )
BitCount++;
b <<= 1;
}
}
// Put checksum back, just in case.
m_Buffer.Data [ 0x20 ] = csum [ 0 ];
m_Buffer.Data [ 0x21 ] = csum [ 1 ];
return BitCount == sum;
}
 
Liked the popcount version, neat. I was simply recoding an old Pascal version that I wrote, that was almost a transcription of the disassembled Z80 in MASTER.
 
ois100 said:
Liked the popcount version, neat. I was simply recoding an old Pascal version that I wrote, that was almost a transcription of the disassembled Z80 in MASTER.
Click to expand...
Since I don't see myself trying to implement this on period-correct hardware, why not use what I've got? Of course, all of this stuff happens near-instantaneously on modern hardware, so one might argue, "what's the point?" I like to twiddle bits. :) At any rate, I'm now recovering individual files and the issue now becomes how to interpret the contents. Interestingly, two files that I was wondering about on one disk turn out to be bit-exact copies of each other, which solves a major mystery of why I was seeing two copies of the same sector in the raw dump.

Thanks for your assistance!
 
No, mostly the QCCBAM files, which seem to be text and glossary interleaved. If the first block of text is located (at offset 0xC00 in the three samples I have, there's a link to the next text block at offset 7 and 8 in the header. The word at offset 9 and 10 appears to point to self (i.e. if the block is at offset 0x0c00, the link to the next block might be 0x1400 and the pointer to self would be 0x0c00. Other bytes in the header are not the same as WP and neither are the formatting code within the text blocks.

The glossary/index blocks look like this:
Code: 
00002800  11 4f 02 5b 00 ed 00 60  03 00 28 00 00 00 11 0a  |.O.[...`..(.....|
00002810  05 0a 50 52 4f 50 4f 53  41 4c 03 0a 04 82 31 37  |..PROPOSAL....17|
00002820  00 0e 04 83 31 34 33 00  10 02 38 38 00 0f 03 32  |....143...88...2|
00002830  33 30 00 10 02 37 32 00  11 01 39 00 10 02 38 32  |30...72...9...82|
00002840  00 0f 03 33 30 33 00 10  02 35 39 00 0f 03 34 30  |...303...59...40|
00002850  35 00 10 02 34 32 00 0f  03 35 30 31 00 10 02 34  |5...42...501...4|
00002860  38 00 10 02 36 37 00 0f  03 38 30 32 00 0b 08 53  |8...67...802...S|
00002870  03 0a 04 83 34 35 36 00  10 03 36 34 33 00 09 09  |....456...643...|
00002880  45 44 03 0a 04 83 31 34  30 00 0f 03 33 36 30 00  |ED....140...360.|
00002890  11 01 39 00 0f 03 34 32  35 00 0f 03 37 39 37 00  |..9...425...797.|
000028a0  09 0c 49 54 49 4f 4e 03  0a 04 83 31 34 36 00 09  |..ITION....146..|
000028b0  08 4b 49 03 0a 04 82 35  30 00 07 0d 55 4c 53 49  |.KI....50...ULSI|
000028c0  4f 4e 03 0a 04 83 31 31  30 00 06 0d 53 50 45 43  |ON....110...SPEC|
000028d0  54 55 53 03 0a 04 82 36  32 00 06 0c 54 41 42 4c  |TUS....62...TABL|
000028e0  45 03 0a 04 83 34 30 31  00 07 0d 45 43 54 49 4e  |E....401...ECTIN|
000028f0  47 03 0a 04 83 37 36 39  00 0b 09 4f 4e 03 0a 04  |G....769...ON...|

Clearly a tree structure--you can see a root entry of "PROPOSAL" and then leafs of "PROPOSED", "PROPOSITION", "PROPULSION", "PROSPECTUS", etc.

The other files are OIS WP files--very similar to the dedicated WP files, but have an extra sector prepended that has a bitmap, which, I believe, identifies active sectors.
 
The byte at 0x25 in a node is the number of sectors used in last VAU. Size of file is word at 0x1D * byte at 0x23.

If you create a totally empty file, the the word at 0x1D will be zero (no first VAU) as will the next word.

This confirms your suspicion that the VAU count word is a count of the VAUs in addition to the first one.
 
I think you have to look at these internal technical decisions in the light of the hardware that they were running on. Working with 2-byte values was easily done on Z80, 3-byte quantities being added/subtracted/compared required a runtime library call and was much slower. 3-byte length allowed 4GB on-disc storage, from an era before MS bought DOS from whoever it was.
 
Yes, but correct me if I'm mistaken. The sector size in the Wang world for a long time was fixed at 256 bytes. So, for a three-byte length, the two most significant bytes point to a 16-bit sector address, with the least significant byte showing the number of bytes used in the last sector. Simple.
From what I've seen thus far, VAUs were stated in powers of 2; 8, 16,... Do you know of a volume that uses, say 13 sectors for a VAU size?

At Durango, we went one step further--our disk catalog was not only a file, but an ASCII-encoded file, so that a BASIC program could read it without resorting to ASCII-binary conversion games. We didn't even have the luxury of a Z80, but rather an 8085 running at 3MHz and a bit.
 
8085 was better than 8080A anyway.

As Z80 etc had no multiply or divide, powers of two made sense as a shift sorted that out.

3 bytes as you describe limit file size to 64KB. Even CP/M was not that restrictive.

As for complexity, it is a lot simpler than the old System V etc Unix systems. IBM 360 was positively baroque.
 
Very few, two that I can think of were :SYSTEM.MEGACODE and :SYSTEM.MEGAMENU, used on Alliance, WP-Plus and VS-WP-Plus, all the same big ugly file. If I get my VS up and running I can get sizes, but yes, a large part of 16MB, if not more.

The structure we are looking at allows up to 4GB files in an era where disks were rarely > 500MB. When it was coded using 5MB disks, it was very forward looking, and I think, now that I'm looking at it from a distance, that Wang's coding was quite exceptionally efficient and gave them a MASTER platform that was well placed to support a lot of enhancement of the client software. Sadly that didn't happen soon enough. It is all too easy to sit here, some 40 years after the fact and think that it could have been neater/clearer. - In over ten years of working with OIS, I never encountered a MASTER crash. - All faults were hardware based, or if software, were on the client workstations.
 
Of course, now we're dealing with 48 bit relative sector addresses. When I spec-ed out a system configuration table in 1979, I allowed for a 32-bit relative sector address. I thought that would work almost indefinitely. Shows my forward thinking, or lack of it.

Perhaps we ought to go to 128 bit sector addresses; that should hold us for at least a decade.
 
ois100 said:
Very few, two that I can think of were :SYSTEM.MEGACODE and :SYSTEM.MEGAMENU, used on Alliance, WP-Plus and VS-WP-Plus, all the same big ugly file. If I get my VS up and running I can get sizes, but yes, a large part of 16MB, if not more.

The structure we are looking at allows up to 4GB files in an era where disks were rarely > 500MB. When it was coded using 5MB disks, it was very forward looking, and I think, now that I'm looking at it from a distance, that Wang's coding was quite exceptionally efficient and gave them a MASTER platform that was well placed to support a lot of enhancement of the client software. Sadly that didn't happen soon enough. It is all too easy to sit here, some 40 years after the fact and think that it could have been neater/clearer. - In over ten years of working with OIS, I never encountered a MASTER crash. - All faults were hardware based, or if software, were on the client workstations.
Click to expand...
I should add that I suspect that this MASTER structure, developed for the Z80 based 64KB or 128KB master processor (Think pdp/11 I/D space not bank-switched) was a reaction to the limitations of the first OIS master processor using the 8080A, that design limited the master to 32KB and the slaves to at most 32KB - any extra memory in the slaves above 0x7ffff was inaccessible to the master for data transfers. - The Z80 clean-sheet re-design solved many problems, as did the built-in facility to 'network' OIS systems transparently.
 
When we retired the 8085 model in ~1983 and went to 80186/80286 hardware, we offered up to 192KB on the 8085. Accomplished through a 64x9 bipolar RAM on the upper 6 bits of the address bus, so still lots of expansion possibility. The design outlived its usefulness.
 
You must log in or register to reply here.
Back
Top