https://gunkies.org/w/api.php?action=feedcontributions&user=Tor&feedformat=atomComputer History Wiki - User contributions [en]2024-03-29T10:28:00ZUser contributionsMediaWiki 1.30.0https://gunkies.org/w/index.php?title=Talk:Word_processor&diff=33563Talk:Word processor2024-02-18T12:53:19Z<p>Tor: editadd</p>
<hr />
<div>Then we have the "physical" word processors.. dedicated computers for word processing only. I can't recall the name of one I saw demonstrated somewhen in the eighties.. it had a portrait monitor.<br />
And my father-in-law had a Toshiba word processor, it looked like an early laptop. We still have it somewhere (in Japan). [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 13:52, 18 February 2024 (CET)</div>Torhttps://gunkies.org/w/index.php?title=Talk:Word_processor&diff=33562Talk:Word processor2024-02-18T12:52:38Z<p>Tor: Word processor devices</p>
<hr />
<div>Then we have the "physical" word processors.. dedicated computers for word processing only. I can't recall the name of one I saw demonstrated somewhen in the eighties..<br />
And my father-in-law had a Toshiba word processor, it looked like an early laptop. We still have it somewhere (in Japan). [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 13:52, 18 February 2024 (CET)</div>Torhttps://gunkies.org/w/index.php?title=Talk:Intel_4004&diff=30479Talk:Intel 40042023-07-13T08:13:33Z<p>Tor: /* Word size */</p>
<hr />
<div>==Word size==<br />
<br />
Per the data sheet, it's actually ''sort of'' an 8-bit computer:<br />
<br />
* Instructions are all multiples of 8 bits long<br />
* Instruction addresses (in jumps, etc) are 8 bits long<br />
* Immediate data is sometimes 8 bits wide<br />
* Register pairs, the target of 'load immediate' instructions, are 8 bits wide <br />
* Some data is 8 bits wide (in the FIN instruction, the data goes to a register pair, so 8 bits wide)<br />
<br />
On the other hand:<br />
<br />
* The accumulator is only 4 bits wide<br />
* The ALU (and thus all data handling in arithmetic instructions) is only 4 bits wide<br />
* Some data is 4 bits wide (it's not clear if in the LDM instruction, the 'DDDD' bits are immediate data, or the address of the data [probably immediate]; either way, it goes to the accumulator, so only 4 bits wide)<br />
<br />
So, it's truly half and half. Because instructions and addresses are 8 bits long, I would say its word size is 8 bits. But I can see an argument for saying it's a 4-bit machine. Addresses on the early PDP-10's are only 18 bits, so address length is not definitive to word size. Similarly, the PDP-10's full support for half-word math is sort of irrelevant. The two conclusive things in 'word size' seem to be i) instruction size, and ii) ALU size (which defines the longest data item it can handle in hardware). But that last isn't absolutely definitive - PDP-11's with hardware floating point handle multi-word data. And the [[UNIVAC I]] has a word size of 72 bits, with two instructions per word! I give up!!<br />
<br />
Interestingly, it seems to have limited support for off-chip RAM; the 16 4-bit-wide internal registers seem to be the primary locations for writing data; there's no 'store' instruction. But SRC seems to send an address out, for later used by the Wxx instructions. And the CM-RAM[1023] lines seem to control "4002 RAM chips". [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 20:58, 11 July 2023 (CEST)<br />
<br />
: I don't think there's any exact definition of the "bit widthness" of a processor. And maybe that's just as well, as people would never be able to agree on one. And obviously many processors will defy a neat classification.<br />
: Maybe we all have a hierarchy of features we'd like to consider in order to assign a number. I'm my view, instruction width isn't at the top of my list. Address space width even less soo, e.g. consider "8-bit" processors usually have a 16-bit address space. I think the ALU and register size the the most important aspect for me. (Hopefully they match, but I'm sure there are the odd example were they don't.)<br />
: For the 4004 specifically I haven't even studied it at all, I just went by the common wisdom which has it a 4-bit processor.<br />
: There's also the 68000 which is supposedly "16/32-bit". Instructions are architected to be 16-bit units. The data bus and ALU are also 16 bits wide, but that's more of a hardware implementation detail. The programming model is pretty much 32 bit throughout.<br />
: [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 13:57, 12 July 2023 (CEST)<br />
<br />
:: I've been thinking about it, and I'm still somewhat lost. I think ''actual'' ALU width isn't such a big deal (e.g. the LSI-11's ALU is only 8 bits wide); it's more the 'architectural' ALU size - i.e. the size of the largest data item the instruction set will handle.<br />
:: I'd forgotten the 68K had 16-bit instructions (even though I used them for several years, including writing a debugger for it); I think I just had this idea that the PDP-11 got as much out of a 16-bit instruction as one could, so the 68K 'must' have had a 32-bit instruction. The 68000 had a 24-bit address bus, and a 16-bit data bus; but the 68020 had 32-bit wide address and data buses - with the same instruction set. So the ''physical'' bus width is kind of like the 'actual ALU' width - less important than the ''architectural'' width.<br />
:: So the architectural address space and data size are important. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 17:46, 12 July 2023 (CEST)<br />
<br />
:: Hey, I have a list of all thing things that might be used for computer 'sizes' - along with counter-examples (e.g. bus width and the 68K). an you thing of a counter-example for the accumulator/register size? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 04:29, 13 July 2023 (CEST)<br />
<br />
::: I think in my view register/accumulator size and ALU width is the most important critera deciding the bitness. I'm not aware of any counter-examples, but then that may be because of my bias. I'm sure somewhere out there, there must be some wacko computer where the ALU doesn't match the register(s).<br />
::: Having thought about it a little more, I have a strong impression people don't consider internal hardware implementation details overly important for deciding bitness. For example, a microcoded processor may have a very small hardware ALU to implement the architectural ALU. The 68000 and LSI-11 are examples of this, and I think some of the low end 360 models too. So I believe the abstract programming model is more important.<br />
::: Regarding address width, in recent times it does seemingly almost almost match register size. This goes back at least to the PDP-11, which really feels like one of the first "modern era" programming models. But before that, many architectures had the idea that a full address should fit in an instruction: e.g. most earlier DEC computers. For that era at least, address width doesn't seem like an important consideration for bitness.<br />
::: Also in that early era, many machines were "word oriented", where a single word size really permeated almost all aspects of the computer: addressing unit, registers, ALU, instruction size, etc. With byte addressable computers, this has changed, and there are more opportunities for mixing and matching different word sizes throughout the machines.<br />
::: [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 09:07, 13 July 2023 (CEST)<br />
:::: The Z80 has a 4-bit ALU.. though it hides that by loading 8-bit values through internal latches. And 8-bit microprocessors typically have a 16-bit address range, but we think of them as 8-bit CPUs. After 32-bit CPUs had been on the market for some years, address range started to feel more important than data width, and the shift to 64-bit was more about address range than general register width. Things have changed over the years. Minis used to have more physical memory than their CPU address range, for example, and that's been the other way around for the last few decades. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 10:13, 13 July 2023 (CEST)</div>Torhttps://gunkies.org/w/index.php?title=Talk:Multics&diff=30031Talk:Multics2023-06-12T05:38:35Z<p>Tor: Upper case/acronyms</p>
<hr />
<div>==Conditions==<br />
<br />
I have this idea was the first OS to make extensive use of conditions inside the OS (something that even today I suspect not many do). This needs to be verified, and can then be added. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:21, 6 October 2017 (CEST)<br />
<br />
== Multics BCPL ==<br />
<br />
Interesting; the Multics [[BCPL]] note spells Multics as "MULTICS". ISTR that either Jerry (possibly) or Corby (likely) insisted that it was not a acronym, and thus was not all upper-case. And most original documentation does spell it that way.<br />
<br />
(Sorry I get so wound up about case, etc; I've always been that way a bit, and then the AP decided that 'Internet' should be spelled 'internet', ignoring the fact that 'internet' was an existing (older) word with a slightly different meaning. I've never recovered.) [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 20:22, 11 June 2023 (CEST)<br />
<br />
: Agreed, that one in particular stands out. Otherwise Multics is rather consistently capitalized. With regards to your passion: go for it, run with the wind! [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 07:04, 12 June 2023 (CEST)<br />
<br />
: Another agreement.. as for MULTICS/Multics, with no personal historical knowledge about the OS, I do remember that in that time period it was common to use all uppercase for a lot of names in computing, in real life as well as in fiction. Didn't matter if the name was an acronym or not. The ones I'm personally familiar with are all the "[[NORD-1|NORD]]" computers - that's "NORTH" in Norwegian and wasn't an acronym. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 07:38, 12 June 2023 (CEST)</div>Torhttps://gunkies.org/w/index.php?title=FAT_file_system&diff=28473FAT file system2023-01-23T13:19:31Z<p>Tor: Fixed typo (superfluous "by")</p>
<hr />
<div>The '''File Allocation Table file systems''' (usually abbreviated to '''FAT''') are the name of a group of related [[file system]]s used in [[MS-DOS]] and early [[Microsoft Windows|Windows]] [[operating system]]s. The first was '''FAT12''' (used by [[floppy disk]]s), from which descended '''FAT16''' and '''FAT32''' (the last used only by [[hard disk]]s).<br />
<br />
The name comes from the way they indicate which [[disk block]]s of the [[disk]] are used by any given [[file]], and which blocks are free and available for use - the 'file allocation table'. The disk contains, at the start of the disk, a large [[array]] of entries, one for each 'cluster' (group of blocks) of the disk; each entry indicates whether that cluster is free (and thus available for allocation), or part of a file. (For robustness, there are two identical copies of the FAT.) (FAT file systems were not the first to use this approach; others OS's, such as [[Incompatible Timesharing System|ITS]], had used a similar approach long before.)<br />
<br />
For clusters which are part of a file, their entries in the FAT are used to tie them together. The array elements are of size 12, 16 and 32 bits in FAT12, FAT16 and FAT32 file systems. FAT32 was a relatively late addition; it was added in [[Windows 95]] OSR 2.<br />
<br />
Unlike the [[UNIX file system]], which strictly separates the functions of the ''naming'' of files (via [[directory|directories]]), and indicating ''where'' the files are stored, FAT file systems to some extent merge these two - again, like earlier file systems. The directory entry of a file indicates which cluster is the first cluster of the file; from there, FAT elements form a [[linked list]] of all the clusters in the file.<br />
<br />
Like the UNIX file system, most directories are stored in what are effectively files; the root directory is a special case, and is stored in a specially allocated area at the start of the disk.<br />
<br />
==File names==<br />
<br />
Early FAT filesystems used [[8.3 file names]] exclusively; starting with Windows 95, file names of us to 255 bytes were possible, but the operating system automatically produced a second file name for such files, one which conformed to the [[syntax]] of 8.3 file names, for [[backward compatibility]] at the [[system call]] level..<br />
<br />
{{semi-stub}}<br />
<br />
==See also==<br />
<br />
* [[BSD Fast File System]]<br />
<br />
==External links==<br />
<br />
* [https://learn.microsoft.com/en-US/windows/win32/fileio/exfat-specification exFAT file system specification] - also covers FAT12, FAT16 and FAR32<br />
* [https://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html The FAT filesystem]<br />
* [https://www.betaarchive.com/wiki/index.php?title=Microsoft_KB_Archive/142982 How Windows Generates 8.3 File Names from Long File Name]<br />
<br />
[[Category: File Systems]]<br />
[[Category: Microsoft Operating Systems]]</div>Torhttps://gunkies.org/w/index.php?title=Talk:A_UNIX%E2%84%A2_Operating_System_for_the_DEC_VAX-11/780_Computer&diff=28441Talk:A UNIX™ Operating System for the DEC VAX-11/780 Computer2023-01-20T12:30:08Z<p>Tor: Page comment missing, adding it here</p>
<hr />
<div>==Revised version==<br />
<br />
So, this is a revised version?<br />
Is there a link to the original?<br />
<br />
*[https://www.bell-labs.com/usr/dmr/www/otherports/32v.pdf A UNIX™Operating System for the DEC VAX-11/780 Computer]<br />
<br />
[[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 01:02, 6 September 2019 (CEST)<br />
<br />
: You mean to the original "internal Bell Labs memo by Reiser and London, dated July 7, 1978"? There's a scan of the original [https://www.bell-labs.com/usr/dmr/www/otherports/32vscan.pdf here]. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 02:13, 6 September 2019 (CEST)<br />
<br />
There are still some errors in the text, presumably leftovers from the original OCR scanning and not all were caught by DMR. E.g. 'paves' instead of 'passes' - definitely an OCR error and not an original typo. Should they (there are others) be left in, or fixed? [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 08:45, 17 January 2023 (CET)<br />
<br />
: I'd fix them, and put a note in the header that additional errors have been caught and fixed past DMR's fixes. In fact, I'll start the process; if you see any I missed, please do them as well. 14:27, 17 January 2023 (CET)<br />
: OK, done; I read the complete text, and found a few more errors (see [https://gunkies.org/w/index.php?title=A_UNIX%E2%84%A2_Operating_System_for_the_DEC_VAX-11/780_Computer&curid=630&diff=28425&oldid=28424 here]). The hard-copy did contain an error ("disk-to-ta;" for "disk-to-tape") which had already been fixed, presumably by DMR (although I didn't check that); I left it. I also added back a bunch of ''italics'' and '''bold''' which had been lost; I hope I got the bold ones right, they can be somewhat difficult to be certain of in the scan. I did find one error in the original text: "RH-11 controller on a PDP-11/70 MASSBUS" - that's actually an [[RH70]]; the [[RH11]] is a UNIBUS MASSBUS controller. I suppose we should probably put a ''(sic - RH70)'' on that? I didn't want to change the original text. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 17:17, 17 January 2023 (CET)<br />
:: Managed to save page without my comment: Fixed a few more OCR errors (1l -> 11, l -> 1, fix dash, missing '(', "disassembles" -> "disassembler", "an" -> "can") [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 13:29, 20 January 2023 (CET)</div>Torhttps://gunkies.org/w/index.php?title=A_UNIX%E2%84%A2_Operating_System_for_the_DEC_VAX-11/780_Computer&diff=28440A UNIX™ Operating System for the DEC VAX-11/780 Computer2023-01-20T12:24:21Z<p>Tor: </p>
<hr />
<div>A UNIX™ Operating System for the [[Digital Equipment Corporation|DEC]] [[VAX-11/780]] Computer<br />
Thomas B. London<br />
<br />
John F. Reiser<br />
<br />
== Notes ==<br />
NOTE: This is a revived version of an internal Bell Labs memo by Reiser and London, dated July 7, 1978. This rendition was generated by OCR from a scanned copy of the original memo, with the result edited by Dennis Ritchie. <br />
[https://www.bell-labs.com/usr/dmr/www/otherports/32v.html This improved version] of the HTML fixes some typos and adds markup that is missing even in the PDF and PS renditions. It was kindly supplied by Naoki Hamada. I am responsible for remaining problems.<br />
--DMR <br />
<br />
''Additional errors have since been fixed, by inspection of [https://www.bell-labs.com/usr/dmr/www/otherports/32vscan.pdf a scan of the original hard-copy]; for changes since DMR's version, see [https://gunkies.org/w/index.php?title=A_UNIX%E2%84%A2_Operating_System_for_the_DEC_VAX-11/780_Computer&curid=630&diff=28425&oldid=28424 here].''<br />
<br />
== ABSTRACT ==<br />
A UNIX operating system together with a complete user environment has been implemented on the VAX-11/780 computer manufactured by Digital Equipment Corporation. The VAX-11/780 system provides 32-bit addresses and data. It uses the same input/output devices as the PDP-11 family and is controlled through a console computer which can be remotely accessed. Additionally, the VAX-11/780 is priced nearly the same as a PDP-11/70 and executes most programs somewhat faster than a PDP-11/70. <br />
This memorandum describes the VAX-11/780 hardware and the UNIX operating system and the C programming language software implementation, records some observations on program portability, and speculates ways in which the operating system overhead can be significantly reduced. The authors conclude that the VAX-11/780 provides an excellent hardware environment for running UNIX and C software.<br />
<br />
== Introduction ==<br />
The VAX-11/780 [1] is a new, general-purpose, stored-program electronic digital computer manufactured by Digital Equipment Corporation. At minicomputer prices it provides addresses and data which are 32 bits wide; the traditional minicomputer address space bound of 64K is gone. This memorandum describes the VAX-11/780 and the implementation of a UNIX operating system and complete user environment for it. Section 2 contains an overview suitable for general consumption; details normally of interest only to devotees of computer system architecture appear in Section 3. The authors comment on software portability in Section 4. <br />
<br />
== Overview ==<br />
'''Environment.''' A user of UNIX and C software on the PDP-11 will find that the VAX-11/780 provides a very similar environment. There are no apparent differences in the command language or the vast majority of programs which are customarily invoked directly from the shell. A casual user probably will not be able to distinguish the hardware, except by issuing the command "who am i" (which identifies the hardware and the current user) or by noting that one of the columns printed by the process status command ps is in hexadecimal rather than octal. The C language programmer will find that int, long, and pointer data types all occupy 4 bytes (a short still occupies 2 bytes), and that a long has its two halves stored in a different order on the PDP-11 than on the VAX-11. Characters still suffer sign extension when converted to longer integer types, but one may use the declaration unsigned char. <br />
<br />
'''Hardware.''' The VAX-11 is a follow-on computer to the PDP-11. The architecture seen by the user-mode assembly-language programmer of a VAX-11 is "culturally compatible" with the PDP-11. Specific details differ, but a programmer familiar with the PDP-11 can quickly understand the differences. The VAX-11 provides UNIBUS and MASSBUS interfaces and uses the same input/output peripheral devices as a PDP-11. <br />
<br />
Significant new features of the VAX-11 include an extended virtual address space, intelligent console, and dramatically improved physical packaging. The address space of a process is divided into a few gigantic segments. Each segment is further divided into a large number of small pages. Sufficient hardware exists to make demand paging a viable memory management strategy. All console functions are handled by an LSI-11 microcomputer through a standard ASCII terminal. The terminal may be remotely located from the processor and can still halt, boot, or diagnose the VAX-11. The mechanical and physical design of the VAX-11/780 is well done. The processor contains no sliding drawers or moving cables. All parts are easily accessible for servicing. Adequate airflow is maintained even under maintenance conditions. <br />
<br />
'''Configuration.''' The actual configuration purchased by Department 1353 is: <br />
<br />
* VAX-11/780 cpu<br />
* 0.5 megabytes memory with battery backup<br />
* floating-point accelerator<br />
* 12Kbyte user-writeable control store<br />
* UNIBUS adaptor with DZ11 (8 RS-232C lines)<br />
* MASSBUS adaptor with TE16 tape drive (800/1600 bpi)<br />
* MASSBUS adaptor with two RP06 disk spindles (176M bytes per spindle)<br />
* additional BA11KE UNIBUS box<br />
<br />
The list price of the above configuration in February 1978 was $241,255; the price including a DEC discount to a Bell Labs purchaser was $200,242. <br />
<br />
'''Software.''' We have implemented a UNIX operating system [2] and complete user software environment on the VAX-11/780. The operating system is Research version 7 as of April 15, 1978. The environment includes the Bourne shell, C compiler, code improver ''c2'', assembler, loader, debugger, standard I/O subroutine library libS, C subroutine library libc, source code control system SCCS, ''nroff/troff'' and more than 130 commands. Maintenance programs for file system checking, bootstrapping, and physical disk pack handling have also been implemented. <br />
<br />
We began with the C language code of Research version 7 of the UNIX operating system, and a PDP-11/45 running UNIX as a bootstrap machine. Creating a C compiler which produced VAX-11 native-mode assembly code was the first task. The code generator portion of the portable C compiler was rewritten to do this. An assembler and loader, based on similar code for the Interdata 8/32, completed the basic support software. Existing PDP-11/70 device drivers for disk, tape, and terminal communication lines were adapted to the VAX-11/780. Assembly language interfaces (trap handlers, hardware initialization, etc.) were completely rewritten. We then created magnetic tapes in the proper format for an initial file system and for deadstart load, and physically carried these tapes from the PDP-11/45 to the VAX-11/780. <br />
<br />
Work on the C compiler began in mid-December 1977. The hardware arrived on March 3. We held a party on May 19 to celebrate successful multiuser operation of the system. <br />
<br />
'''Performance.''' Identical documents were formatted by ''nroff'' on our VAX-11/780 and on a PDP-11/70 running Research version 7 UNIX; both systems used RP06 disks. Identical C programs were compiled and assembled on the VAX-11/780 and on the PDP-11/70. As reported by the ''time'' command, the results (converted to seconds) were: <br />
<br />
<pre><br />
nroff -ms -e -T450-12 ios.r >/dev/null <br />
<br />
real user sys <br />
VAX-11/780 47.0 28.6 8.7 <br />
PDP-11/70 54.0 36.9 7.9 <br />
<br />
cc -c -O pftn.c <br />
real user sys <br />
PDP-11/70 (Ritchie compiler) 86.0 43.5 11.8 <br />
VAX-11/780 (portable compiler) 82.0 64.0 10.5 <br />
PDP-11/70 (portable compiler 153.0 114.6 16.6 <br />
for Interdata 8/32) <br />
</pre><br />
<br />
From the statistics on ''nroff'' one should conclude that, based on user-mode CPU time, the VAX-11/780 can execute the code produced by the VAX-11 C compiler approximately 22% faster than the PDP-11/70 an execute the code produced by the PDP-11 C compiler. This is a measure of the combined power of the hardware and efficiency of the code generated by the compiler. Except as an upper limit, the figures give no indication as to the throughput, response time, or efficiency of the operating system. The differences in real time and system time between the VAX-11/780 and the PDP-11/70 are not significant. <br />
<br />
The times given for compilation of the file ''pftn.c'' are an attempt at a "black box" comparison of apples and oranges. The black box is any program (compiler) which takes C language input and produces executable instructions. The black-box comparison is that the current VAX-11 C compiler running on the VAX-11/780 and compiling code for the VAX-11 requires 49% more user-mode CPU time than the current PDP-11 C compiler running on the PDP-11/70 and compiling code for the PDP-11. The apples and oranges aspect arises because the two compilers, while equivalent from the black box viewpoint, are (on the inside) totally different pieces of software. The PDP-11 compiler is a production compiler written by D. M. Ritchie; the VAX-11 compiler is a portable compiler based on work by S. C. Johnson. The figures for the portable compiler running on the PDP-11/70 and compiling for the Interdata 8/32 are included for those who wish to compare two portable compilers. We have no VAX-11 equivalent to the Ritchie compiler, and thus cannot run the tests which would enable comparison of two production compilers. <br />
<br />
The loaded size in bytes of the operating system and seven other programs appears in Table 1. One should note the general similarity between the text (instructions) sizes on the PDP-11 and on the VAX-11, and between the bss (uninitialized data) sizes on the VAX-11 and on the Interdata 8/32. The particular PDP-11 UNIX system chosen has several more input/output device drivers and experimental multiplexing software not in the VAX-11 system, which accounts for its larger text size. If many global integer variables (or large arrays) are used, there is a tendency for the data and bss portions to double in size when going from a PDP-11 to a VAX-11 or an Interdata 8/32 because an int occupies two bytes on the PDP-11 and four bytes on the other machines. However, character arrays occupy the same amount of space on all machines. An unusually large number of references to global variables in the nroff program accounts for its increase in text size on the VAX-11 compared with the PDP-11. A program can be written to automatically change the addressing modes used in the VAX-11 code so that most references to global data become shorter than at present, but this has not been done. <br />
<br />
'''Evaluation.''' We believe that the VAX-11/780 provides an excellent hardware environment for running UNIX and C software. With the software in its current state, we view the system as operationally equivalent to a PDP-11/70 running UNIX software, except that the 64K limit on process address space is gone and programs run faster. We believe that the advanced memory management and user/system communication capabilities of the VAX-11/780 offer an opportunity to construct future UNIX-like systems with substantially higher throughput than provided by today's UNIX on a PDP-11/70.<br />
<br />
== Details ==<br />
=== Hardware ===<br />
<br />
Four main subsystems — the central processor, console, main memory, and input/output — constitute the VAX-11/780 computer system. The central processor, memory, and input/output subsystems are connected by the Synchronous Backplane Interconnect (SBI), an internal synchronous bus with a maximum data throughput of 13.3 megabytes per second. The SBI deals in physical addresses which are 30 bits wide. Half of the SBI address space is reserved for memory addresses, and half for input/output device registers. Arbitration for bus cycles on the SBI is distributed; each subsystem decides if it will use the next bus cycle. <br />
<br />
The central processor is a microprogrammed 32-bit general-register computer. The architecture seen by the user-mode assembly-language programmer is "culturally compatible" with the PDP-11; an expert programmer familiar with the PDP-11 can learn and understand the differences in one day or less. The processor handles binary integers of 8, 16, and 32 bits; single precision (32 bit) and double precision (64 bit) floating-point numbers; character strings up to 65535 bytes long; bit fields up to 32 bits wide; and IBM-style packed decimal strings up to 31 digits long. Bit fields have no alignment restrictions whatsoever, all other data types require alignment only to a byte (8 bit) boundary. The central processor provides sixteen 32-bit general registers. Register 15 is the program counter '''pc'''. Software operating in one of the privileged access modes (see below) must use register 14 as a stack pointer '''sp'''. The instructions which implement high-level procedure call and return ('''pushl''', '''calls''', '''callg''', '''ret''') assume a convention about the use of sp, register 13 ('''fp''', the frame pointer) and register 12 ('''ap''', the argument pointer). The instructions which handle character and packed decimal strings use registers 0 through 5 to hold pointers and counters, so as to be interruptible. Floating-point operations may use the general registers; there are no separate floating-point registers. Instructions take from zero to six operands. The operation code occupies one byte and is followed by the operands, which require from one to nine bytes each. Nine addressing modes (including all the PDP-11 modes except *-(r)) are allowed, and the addressing modes are independent of the operation code. When the central processor is executing in the context of a process, there are four access privilege modes (user, supervisor, executive, kernel), each with its own stack pointer; software which desires a per-process kernel stack is easy to implement. A fifth stack pointer is used when executing in a special system-wide interrupt context. The VAX-11/780 processor includes an eight kilobyte, two-way set associative, write-through, memory data cache; an eight-byte instruction stream buffer; and a 128-address virtual address translation buffer. Most of the processor is implemented in Schottky TTL MSI logic. A programmable realtime clock and a time-of-year clock (battery operated during loss of line voltage) are standard equipment. Options include a hardwired floating-point accelerator and user-writeable control store. <br />
<br />
The console subsystem consists of an LSI-11 computer, local memory, floppy disk, DECwriter terminal, and remote-access communications port. The console is connected directly to the central processor and performs all the functions of a conventional "lights and switches" front panel. The floppy disk serves as the initial bootstrap device for normal operation and holds special microcode for diagnostic operation. When activated by a key switch on the central processor, the remote-access port becomes the console. A terminal connected through the remote-access port can halt the central processor, boot it, diagnose it, etc. <br />
<br />
The virtual address space of a process running on the VAX-11/780 consists of 2**32 8-bit bytes. The two high-order bits of a 32-bit address determine one of four segments. Two of these segments are system segments common to the address space of all processes. One of the system segments is reserved for future use. The other two segments are separately defined for each process and are automatically managed by the context switching instructions. One of the per-process segments is designed for a stack which grows towards lower-numbered memory addresses. Segments are divided into pages of 512 bytes. Memory mapping hardware translates virtual addresses into physical addresses using page tables. A page table contains one four-byte entry for each page mapped; the entry contains a valid bit, a four-bit field which encodes access privileges, a modify bit, and the physical page-frame number where the page is mapped. (There is no reference bit which is maintained by hardware!) A base register and a limit register describe the page table of each segment. The base register of a per-process segment contains a virtual address within the system segment; the base register for the system segment contains a physical memory address. The VAX-11/780 central processor contains a virtual address translation buffer holding 128 virtual address-page frame number pairs which eliminates the need for extra memory references during address translation for (typically) 98% of all memory references. The memory is implemented using MOS semiconductor RAMs with an error correcting code which corrects all single-bit errors and detects all double-bit errors and 70% of all greater-than-double bit errors. A memory controller can handle 8 memory boards; using 4K chips each board can hold 128K bytes. There can be two memory controllers, thus the maximum amount of physical memory is currently 2 megabytes. When 16K chips are used [forecasted for late 1978], each board will hold 512K, and physical memory can be 8 megabytes. There is a battery backup option for maintaining data in the event of a power failure. Each optional battery will maintain 1 megabyte for 10 minutes. <br />
<br />
The input/output subsystem consists of UNIBUS adaptors and MASSBUS adaptors. A UNIBUS adaptor (UBA) is an interface between a standard UNIBUS and the SBI. The UBA does the bus arbitration and everything else necessary to administer the UNIBUS. It also contains a set of registers for mapping UNIBUS addresses to and from SBI addresses. The maximum throughput on a UBA is 1.5 megabytes per second. A MASSBUS adaptor (MBA) is an interface between the SBI and MASSBUS devices (RP06 disk, TE16 tape, etc.). An MBA would be more properly called an RH-780 controller, analogous to the RH-11 controller on a PDP-11/70 MASSBUS; only one unit may transfer data at a time, although several similar units connected to the same MBA can execute control functions simultaneously. The MBA contains the device control registers normally found in an RH controller. The registers lie in the I/O section of SBI addresses. An MBA also contains a set of mapping registers which translate device byte addresses to and from SBI addresses. The maximum throughput on a MBA is 2.0 megabytes per second. The published limits are 1 UBA and 4 MBAs per system. Theoretically one could have any number of either kind as long as the sum of the number of central processors, memory controllers, MBAs, and twice the number of UBAs were 15 or less, since the SBI has 15 "ports". <br />
<br />
The physical packaging of the system has been dramatically improved compared with the PDP-11. The VAX-11/780 processor cabinet contains no drawers or moving cables. The SBI is fixed and rigid. Three one-third horsepower squirrel-cage blowers provide sufficient air flow &mdash; even while servicing the CPU. Any logic card, power supply, or blower can be replaced within twenty minutes by one person using only a screwdriver. The CPU stands 1.53m x 1.17m x 0.77m (HWD); cabinets housing the CPU, UNIBUS devices, and tape drive are usually bolted together to form a single unit 1.53m x 2.51m x 0.77m. Our configuration (see section 2) weighs 3452 pounds and requires 42050 BTU/hr cooling. <br />
<br />
=== C Compiler ===<br />
A VAX-11 "native mode" C compiler was constructed using S. C. Johnson's portable compiler as a base. After one month, a reasonable version began to evolve: it produced code which was good enough to exercise the assembler, loader, and debugger (on the bootstrap PDP 11/45). This initial version did not make use of VAX-11 indexed addressing (which does single-level array subscripting including appropriate index shifts), bit field instructions, or autoincrement/decrement addressing. It contained its share of bugs, particularly since the hardware had not arrived and could not be used to actually run the generated code. <br />
<br />
Substantial effort has been subsequently directed towards improving all aspects of the compiler: bugs have been corrected, routines have been made to execute more efficiently, and the quality of the generated code has been improved. All addressing modes are supported, bit field instructions are used for programmer-defined bit fields, and autoincrement and autodecrement addressing as well as three-address instructions are used. <br />
<br />
Overall, our experience with the compiler has been very favorable. When the VAX-11/780 was delivered, the compiler worked well enough to compile itself, the UNIX kernel, and many user-level commands. In fact, since the delivery of the machine, only about a half-dozen serious bugs have been detected. Additionally, the framework of the compiler has proven itself to be flexible: a compiler for the Interdata 8/32 was transformed into a compiler for the VAX-11/780, some improvements and extensions were easily added, and, in general, a quickly evolving compiler has remained stable and productive. The authors feel that, with a few extensions to the model of the compiler and a certain amount of tuning, the current VAX-11 compiler could easily remain as the production VAX-11 compiler. <br />
<br />
There are still some deficiencies in the current version of the compiler, as well as in the basic "product" itself. The compiler is slow and quite large; see the statistics in section 2 and Table 1. Some of the blame for the size and lethargy of the first pass can be attributed to the use of ''lex'' for the scanner and ''yacc'' for the parser, and to the use of ASCII to communicate information between passes. Both ''lex'' and ''yacc'' produce large routines: the scanner is 17K bytes in length (over 4.5K bytes of instructions), and the parser is 16K bytes long (over 5.5K bytes of instructions). On the average, the first pass spends 20% of its time in the lexical scanner ''yylook'', and 9% of its time in the parser ''yyparse''. <br />
<br />
Using ASCII to communicate between the two passes causes an additional speed penalty for character conversion. On typical programs, the fast pass (parser) spends roughly 30% of its time performing output services (i.e.,, calls to ''_doprnt'' (18%), ''_strout'' (8%), and ''printf'' (4%), while the second pass (code generator) spends roughly 21% of its time reading it back in (i.e., calls to ''read'' (18%) and ''rdin'' (3%). (Additionally, the routine used to convert from ASCII to binary contained a bug which caused "-2147483648" (which is -(2**31) ) to be read as zero on our PDP-11/45.) <br />
<br />
The above problems are not inherent to the compiler model. To speedup compilation, the scanner can be hand-coded (as in the standard PDP-11 compiler), and the interpass data can be formatted in binary (or the two passes can be combined). With these simple modifications (some are already in progress), it should be possible to produce a compiler almost twice as fast as the current one. <br />
<br />
Two features of the VAX-11 architecture — three-address instructions and indexed addressing mode — were difficult to model within the basic structure of the compiler. The full implementation of three-address instructions proved to be so difficult that it was not really attempted. Instead, ''c2'', the assembly language code improver, tries to merge several instructions into an appropriate three-address instruction. For example, the statement a = b + c compiles <br />
<pre><br />
addl3 b,c,r0<br />
movl r0,a<br />
</pre><br />
which the improver can change to: <br />
<pre><br />
addl3 b,c,a<br />
</pre><br />
for a savings of three bytes and over 400 nanoseconds. However, ''c2'' will not always succeed in this shortening. It cannot tell the difference between <br />
<pre><br />
a = b + c<br />
return;<br />
</pre><br />
and <br />
<pre><br />
return(a = b + c);<br />
</pre><br />
since register r0 must be considered "live" (i.e., contains a value which may be required later) across the return statement. <br />
<br />
The VAX-11 has six indexed addressing modes which yield the address of an element of a one-dimensional array of a base type ('''char''', '''short''', '''int''', '''long''', pointer, '''float''', or '''double'''). The statement <br />
<pre><br />
a[i] = b[j] * c[k];<br />
</pre><br />
where ''i'', ''j'', and ''k'' are declared '''register int''' and ''a'', ''b'', and ''c'' are '''double''' arrays (either external or local) can be compiled into the single instruction: <br />
<pre><br />
muld3 b[j],c[k],a[i]<br />
</pre><br />
Although the index specifier (e.g. ''i'' in the above example) must be a register, the base address specifier can be any addressing mode except register, literal, or another indexed mode. For example, the C-language constructs ''a[i]'', ''(*p)[i]'', ''(--p)[i]'', ''(p++)[i]'' and ''(*p++)[i]'' (or their equivalents ''*(a+i)'', ''*(*p+i)'', ''*(--p+i)'', ''*(p++ +i)'', and ''*(*p++ +i)'', respectively) all can be done with a single VAX-11 address (where ''a'' is an array of base type, ''p'' is a pointer to the same type, and ''i'' is of type register int). It is usually difficult to recognize or conveniently represent such constructs (e.g., ''(-p++)[i]'' is fun), or generate the possible cases (e.g., ''a[i]'' where ''a'' is not readily addressable). <br />
<br />
The fact that the code generator can easily recognize only expression trees of height one (two if OREG and UNARY MUL nodes are taken into account) causes substantial difficulty in making use of indexed mode, three address instructions, and indirect addressing. Expression trees of non-trivial height occur not infrequently (e.g. as a worst case, the statement <br />
<pre><br />
a = b + (*p++)[i];<br />
</pre><br />
has an expression tree of height six, but can be compiled into the single instruction <br />
<pre><br />
addl3 b,*(p) + [i],a<br />
</pre><br />
if ''p'' and ''i'' are register variables). The complexity of the code generator is raised by forcing the compression of subtrees into single nodes which are then treated with special checks, special code, etc. <br />
<br />
The size and alignment attributes of data objects are logically independent, even though previous hardware architectures (IBM 360, PDP-11, Interdata 8/32, ...) have imposed alignment restrictions based on size. The VAX 11/780 has no such restrictions, although programs run faster with data aligned on natural boundaries. The C language has little notion of alignment; because of run-time penalties, the VAX-11 C compiler aligns all the basic data types on address boundaries which are a multiple of sizeof the basic type. Due to questions about alignment, both the language and the compiler have difficulty with the declaration ''char c:10;''. <br />
<br />
The decision to naturally align most data items has undesirable side effects which cannot be ignored. Consider the structure declaration <br />
<pre><br />
struct foo {<br />
char c;<br />
float f;<br />
} bar;<br />
</pre><br />
On the PDP-11, sizeof(''foo'') is 6 bytes while on the VAX-11, sizeof(''foo'') is currently 8 bytes (the offset of ''f'' within ''bar'' is 2 and 4 respectively). sizeof(''foo'') could be 5 bytes in each case. Although both machines use the same data formats for chars and floats, the differing alignment imposed by the the VAX-11 C compiler means that the two machines cannot speak directly to one another using media which record structures containing binary information. Since alignment is important, we feel that it ought to be specifiable in the C language. <br />
<br />
=== Operating system conversion ===<br />
A UNIX system running on a PDP-11/45 was used as the base for transporting software to the VAX-11/780. The software itself originated with the code produced by members of Center 127, Computing Science Research, for the Interdata 8/32. Programs were cross compiled, assembled, loaded, and put an magnetic tape in ''tp'' format; absolute bit-string files were put on tape in ''dd'' format. Tapes were then carried across the room to the VAX-11/780. An absolute tape boot (in machine language), ''tp'' boot and primary disk boot (in assembly language), secondary disk boot (in C), and stand-alone utilities (disk formatter, disk verifier, tape-to-disk, disk-to-tape, disk-to-disk, and disk-to-console, all in C) were then used to bring up the system. <br />
<br />
Establishing an initial file system on the disk took longer than expected. The PDP-11/45 was running USG issue 3 of the UNIX operating system with a "16-bit" file system and the VAX-11/780 was to have a Research version 7 "32-bit" file system. Also, C-language code on the VAX-11 expects the bytes of a 32-bit integer to be stored in a different order than C-language code on the PDP-11. We swallowed these two red herrings hard, and suffered. We now know that the proper way to create an initial file system is to modify the program ''mkfs'' so that its output (on the bootstrap machine) is a file containing the proper bits, put that file on tape, and use the tape-to-disk utility on the target machine. <br />
<br />
Mapping the software architecture of the UNIX operating system onto the hardware architecture of the VAX-11 required a number of decisions. Commentary on these decisions follows.<br />
<br />
The SCB (system context base) processor register contains a page-aligned physical memory address which is the base of the hardware interrupt vector. The UNIX system puts this vector at physical memory address zero. <br />
<br />
Operating system code, data, kernel stacks, and interrupt stack occupy the VAX-11/780 system segment (virtual addresses 80000000 to bffffff). User code and data are loaded into segment zero (0 to 3fffffff) and the user stack is initialized in segment one (7fffffff to 4000000). User processes pass arguments to system service code using the ordinary '''calls''' subroutine calling sequence. The '''ckmk''' instruction is then used to gain kernel privileges. The '''chmk''' instruction switches the stack pointer '''sp''' from the user stack to the kernel stack, but does not change the argument pointer '''ap''' or the frame pointer '''fp'''. The kernel uses the value in '''ap''' to copy the arguments into ''u.u_arg''. The VAX-11 hardware allows the values to be directly addressed, but the kernel software requires the copy. <br />
<br />
The ''u area'' is a per-process data structure in which the operating system keeps swappable information about a process. The kernel virtual address of the ''u area'' must be a constant across all processes. The PDP-11 implementation puts the ''u area'' at kernel address 0160000; when process switching occurs the ''u area'' is switched by changing a kernel data space segmentation register. Since the operating system can address user memory on a VAX-11, the ''u area'' could be placed in (protected) user memory, say at address 0 or at 7fffe000. However, it was desirable for the first implementation to make the page tables for user segments part of the ''u area'', which creates timing problems unless the ''u area'' lies in system space. The base of the ''u area'' was assigned kernel virtual address 80020000. When process switching occurs, the ''u area'' is changed by changing the system-space page table and invalidating the page-table translation cache for the appropriate pages. <br />
<br />
Since the operating system can directly address the memory of the current user process, the procedures ''fubyte'', ''subyte'', ''fuword'', etc., are unnecessary and could be made into macros which would merely do the appropriate load or store. However, these procedures (along with ''copyin'' and ''copyout'') were kept to ensure that each access to user space is valid. <br />
<br />
A VAX-11/780 internal processor register called the PCB (process context base) points to an area in which the VAX-11/780 saves the hardware state of the machine (96 bytes) when switching context. This save area was put in the ''u area'' as ''u_rsav''. <br />
<br />
The implementation of context switching required major effort. The VAX-11 has two very nice instructions ('''svpctx''', save process context; and '''ldpctx''', load process context) which facilitate context switching. Unfortunately, they do not implement the mechanism which the UNIX system expects. (The mechanism used by UNIX is so dispersed and intricately detailed that it is hard to imagine any hardware which implements it directly.) The temptation to drastically change the UNIX code has been resisted so far. The ''savu/retu/aretu'' tar pit was VAX-inated, but it took more than a week. The newer ''save/restore'' primitive does make the C-language code prettier, but the assembly-language side (at least for the VAX-11) is just as dirty as ever. The UNIX context switching mechanism requires three state save areas, ''u.u_rsav'', ''u.u_ssav'', and ''u.u_qsav'' because the same mechanism is also used for abnormal returns. The VAX-11 context-switching instructions use only a single state save area. To make use of the VAX-11 instructions, the software simulates a great deal of microcode and bastardizes call frames in a most ugly manner. Context switching is certainly high on the list of things to rewrite in the second implementation (even for the PDP-11!). <br />
<br />
The procedures ''sureg'' and ''estabur'' were also tricky to implement. They were designed with the assumption that only a small number (16 or fewer) of registers would be needed to map the address space of a user process, while on the VAX-11 a 32K process requires 64 page table entries. Furthermore, the memory map of a process is diddled in tricky ways, particularly in ''expand'' and ''getxfile''. <br />
<br />
Handling DMA I/O hardware was the other major implementation bottleneck. The UBA and MBA mapping registers contain physical memory page numbers, and physical addresses are hard to handle. It is not pleasant to deal with the hardware which implements the mapping registers. If an I/O transfer is in progress then the mapping registers may be neither read nor written; this applies even to registers which would not be used by the transfer. As a result, the map for the next I/O operation cannot be setup during the current I/O operation. Furthermore, a single transfer is limited to 64K bytes because the byte counter is only 16 bits wide. Thus swapping a process to the disk can require multiple I/O operations. The solution to these problems involved permanently reserving the last 129 registers in each map to service both swap and physical I/O operations. The remaining map registers are available to map the system buffers, and are loaded at system initialization time. Disk ECC error correction is currently done only for I/O involving the system buffers. Disk errors on raw I/O cause process termination; the swap area on disk had better be error-free. <br />
<br />
Like the UNIX system for the PDP-11, the current implementation for the VAX-11/780 maintains each process in contiguous physical memory and swaps processes to disk when there is not enough physical memory to contain them all. Reducing external memory fragmentation to zero by utilizing the VAX-11/780 memory mapping hardware for scatter loading is high on the list of things to do in the second implementation pass. To simplify kernel memory allocation, the size of the user-segment memory map is an assembly parameter which currently allows three pages of page table or 192K bytes total for text, data, and stack. This also deserves to be rewritten, both to allow varying process size, and to allow processes larger than physical memory through demand paging. Dynamic page table size would mean dynamic ''u area'' size if the page table remained part of the ''u area''. <br />
<br />
The code in ''sendsig'' for sending a signal to a process involves a tedious simulation of the '''calls''' instruction due to the problem of "inward return" across privilege modes upon termination of the routine which handles the signal. Making a portion of the kernel code readable by a user-mode process would simplify ''sendsig''. Motivated by a problem with the Bourne shell, the signal number is passed as a parameter to the signalled routine. <br />
<br />
Interprocess communication via signals (''signal'' and ''kill'') uses the low-order bit of a machine address for something other than addressing. This implies that a procedure which handles signals must start on an even byte boundary, which means that every procedure must start on an even byte boundary. The C compiler thus issues a pseudo-op to the assembler to align the beginning of each procedure. This can waste memory on a VAX-11. It also imposes a nontrivial requirement on the assembler, since if the resolution of conditional jump instructions can change the parity of the length of a procedure then the alignment directive must also be handled like a conditional jump. In hindsight, it would have been better if a distinct value (say +1 or -1) were used for ''ignore'', rather than multiplexing the bottom bit. <br />
<br />
The VAX-11/780 provides a (non-maskable) trap for integer division by zero. The system would like to turn this into a signal to the process. A similar situation exists for subscript range trap. Integer overflow, floating overflow, floating underflow, and reserved operand also need signal numbers. Perhaps only one "error" signal is needed with some other means for determining the true fault. The whole business of interrupts, signals, asynchronous I/O, and the use of the hardware AST mechanism deserves more attention. <br />
<br />
A bug was discovered in the UNIX code for process termination involving the ''proc'' and ''xproc'' structures. (The problem also existed on the PDP-11, but it would only be noticed if a process had accumulated more than 65535 ticks of system time, which is highly unlikely.) When a process dies its resource utilization statistics (currently only exit status, system, and process CPU time) are temporarily saved so that they can be added to the totals for the descendents of the parent process. The actual accumulation is done by the kernel when the parent process issues a '''wait''' system call; the child process is then completely erased. The kernel was overlaying the statistics in a part of the ''proc'' structure normally used by the scheduler to contain the pointer ''p_textp''. Ordinarily the exit was processed immediately, causing no harm. But if the system was loaded so that swapping was necessary, then the scheduler could sneak in after the child exited and before the parent read the statistics, and would interpret the timing data in the zombie ''xproc'' structure as a pointer. This invariably caused an illegal memory reference from kernel mode on the VAX-11/780. <br />
<br />
One of the greatest disappointments with the current system stems from a design quirk in the FP-11 floating-point processor for the PDP-11. When converting between floating-point and 32-bit integer, the FP-11 expects the high-order 16 bits of the integer to be stored at the lower memory address; this is not in line with the general "right to left" design of the PDP-11, which would place the low-order 16 bits in the lower memory address. C code for the PDP-11 uses the FP-11 convention for storing '''long''' integers. The VAX-11 hardware stores the least significant bit of ''any'' integer data type in the lowest addressed byte. C code for the VAX-11 uses the hardware convention. This means that files containing long integers represented in the local convention are not binary compatible between a UNIX system on the VAX-11 and a UNIX system on the PDP-11. This is the only exception for data types common to both machines: '''char''', '''short''', '''float''', and '''double''' all have a common representation. Except for this (and the structure alignment problem noted earlier), disk packs containing 32-bit file systems, tapes, etc., would have been interchangeable. The fact that DEC's Fortran-IV Plus for the PDP-11 avoided the FP-11 convention, and that RSX-11 files ''are'' binary compatible between the VAX-11 and the PDP-11, is only salt on an open wound! <br />
<br />
=== Subroutine libraries ===<br />
'''libc'''. Conversion of the system-call interface routines was straightforward but tedious. Most routines are merely <br />
<pre><br />
.word 0x0000<br />
chmk $nn<br />
bcc L1<br />
jmp cerror<br />
L1: ret<br />
</pre><br />
The routines ''printf'', ''ecvt'', and ''fcvt'', were left to '''libS''' and were not implemented in '''libc'''. <br />
<br />
'''libS'''. Conversion of the standard input/output library '''libS''' posed no problems except for ''_doprnt'', the routine which constructs character representations of other datatypes for the printing routines ''printf'', ''fprintf'', and ''sprintf''. Since many programs spend 15% to 20% of their execution time within ''_doprnt'', it pays to code the routine for speed in assembly language. Packed-decimal instructions handle decimal, unsigned, and floating-point conversions. The algorithm chosen for converting from floating-point to character string revealed a microcode bug in the VAX-11/780's '''ashp''' (arithmetic shift and round packed) instruction. Under certain conditions a carry from the rounded digit propagated both to the adjacent digit and to the digit eight places further left. This usually caused an overflow, since the destination packed-decimal string was typically not long enough to represent the spurious carry. DEC claims to have a fix for the bug, but the FCO has not arrived. In the meantime a five-instruction patch detects and corrects the spurious overflow. <br />
<br />
=== Commands ===<br />
'''as''', '''ld'''. Code developed by Center 127 for the Interdata 8/32 was the model for an interpretation by a VAX-11/780 artist. The assembler uses an algorithm described in [3] with heuristic improvement of [4] to resolve conditional jump pseudoinstructions. Variable-length, unaligned instructions and address constants forced the relocation information in object tiles to include the explicit segment-relative address for each relocatable datum, rather than deducing the address from a one-to-one correspondence between the position in the segment and the corresponding position in the relocation table. This caused a slight change in the header information within object files. <br />
<br />
'''c2'''. The code improver for the assembly language generated by the VAX-11 C compiler is based on a similar program for the PDP-11. A "backwards" register usage pass, performed once and before anything else, was a major addition. Knowing that no temporary register is live across a backwards jump, the register usage pass introduces three-address instructions wherever possible. It also recognizes situations where jump on bit ('''jbc''', '''jbs''', '''jlbc''', '''jlbs'''), extract field ('''extzv''', '''movzbl'''), and move address ('''moval''', '''movab''', '''pushal''', '''pushab''') instructions can be used. The code for insertion of fancy loop control instructions '''sob''', '''aob''', '''acb''' was also extended. <br />
<br />
'''adb'''. The most significant change to the symbolic debugging routine was the writing of a disassembler for VAX-11 native-mode instructions. Additionally, the character input and output routines were modified to use a default radix for all numeric values. The radix is initialized to sixteen. <br />
<br />
'''sh'''. The (Bourne) shell is the standard user command interpreter. It required by far the largest conversion effort of any supposedly portable program, for the simple reason that it is not portable. Critical portions are coded in assembly language and had to be painstakingly rewritten. The shell uses its own ''sbrk'' which is functionally different from the standard routine in libc. The shell wants the routine which fields a signal to be passed a parameter giving the number of the signal being caught; ''signal'' was also a private routine. This was handled by having the operating system provide the parameter in the first place, doing away with the private code for ''signal''. The code in ''fixargs'' (for constructing the argument list to an '''exec''' system call) had to be diddled. <br />
<br />
'''ps''', '''iostat'''. The process and input/output status commands consistently referenced ''/dev/mem'' (physical memory) when they should have referred to ''/dev/kmem'' (kernel virtual memory). ''iostat'' also assumed that certain variables maintained by the kernel were allocated contiguously, even though they were not declared as part of a structure. <br />
<br />
'''pr'''. The command which formats and prints files had a bug that caused a division by zero when it was asked to print several files and the fist file in the list did not exist. On a PDP-11 division by zero returns the dividend, but on a VAX-11 it gives an unmaskable trap. <br />
<br />
'''cat''', '''dc'''. These two commands did not count their arguments using the first parameter ''argc'', but rather assumed that an additional argument (''argv[argc]'', initialized as -1) could be used as a pointer. On the PDP-11 the resulting address references the fixed end of the stack; on the VAX-11, -1 is an illegal address. <br />
<br />
'''nroff/troff''' The source code for the document preparation and phototypesetter commands is not portable; several weeks were required to produce properly running version of these commands. Use of the explicit (or worse, implicit) constant "2" instead of '''sizeof(int)''' was quite common. The code assumes that variables which are adjacent in external declarations occupy contiguous memory at execution time. Several tables are initialized by assembly-language programs. Converting the tables was merely tedious; changing the code which thought it knew the format of an ''a.out'' file required some effort. This memorandum was created using the converted ''nroff/troff'' programs on the VAX-11/780. <br />
<br />
'''SCCS'''. Version 4 of the Source Code Control System [5] is used to provide version backup for software in case disastrous bugs are introduced. The source for SCCS itself had not quite been converted to version 7 UNIX, and the header files required some massaging. The PWB routines ''logname'' and ''pexec'' had to be simulated. The utility procedures for dynamic storage allocation required some work to integrate them with '''libS''' and to remove PDP-11 dialect. The exit status of the ''diff'' command changed in version 7, causing ''delta'' to bomb. The code implicitly assumed that all checksums were computed modulo 65536. The documentation is incorrect: everywhere "99999" appears it should really say "65535". The procedure ''satoi'' returns two values, storing one of them indirectly through a pointer parameter. Naturally, ''satoi'' and its callers did not agree on '''sizeof''' the stored value; this took a day to track down. <br />
<br />
== 4. Software portability ==<br />
We thank the members of Center 127, Computing Science Research, for their efforts in producing the basic software and for their recent efforts towards making the software portable. The fact that people other than the original developers can quickly create a running system for a new machine is a tribute to how well the original work was done. <br />
<br><br />
Yet in our effort to transport a complete UNIX system to the VAX-11/780 we stumbled across a large number of nonportable constructions and were dismayed by the seeming lack of appropriate facilities to detect and prevent them. Based on our experience, we strongly recommend that the C language and its compilers be enhanced so that <br />
<br />
# The actual arguments in a procedure call are type checked against the procedure declaration, and a "dummy" declaration which specifies types is permitted even if the called procedure is not actually declared in the same compilation.<br />
# The '->' operator is checked to insure that the structure element on the right is a member of a structure to which the pointer on the left may point.<br />
# A structure element may be declared with any name as long as the name is unique within the immediately surrounding structure. (The current requirement that a structure element name must uniquely correspond to an offset from the beginning of the structure, across all structures in a compilation, creates naming problems and frequently leads to errors of the type noted in item 2 above.)<br />
# The issue of alignment to an even-byte (or other) boundary is brought into the open, so that arbitrary data structures can be accurately described.<br />
<br />
There is a program called ''lint'' [6] which, if conscientiously used throughout the life of a piece of software provides type checking which partially addresses the first two points in the above list. The problem is that ''lint'' is big, noisy, relatively recent and unknown, and (partially as a result) infrequently used. There is little incentive for the average programmer to use ''lint'' as a matter of course. The authors believe that type checking belongs in the everyday compiler as the default, where it is very inexpensive to implement. Those who wish to do "dirty" work may request that type checking be disabled; those who wish to bless their dirty work may use type casts. <br />
<br />
We believe that these four enhancements would go a long way towards making C language software portable as a rule rather than as an exception, thus preserving Bell Laboratories' investment in present and future C software. <br />
<br />
''Acknowledgements''. Thank you, D. M. Ritchie and S. C. Johnson, for answering questions at key moments; G. K. Swanson, for assistance with boot procedures and stand-alone utilities; J. F. Jarvis, for the mathematical function library; and D. K. Sharma, for help in bringing up user-level commands. Additional thanks go to many other members of Centers 127 and 135, and Department 8234, for helpful comments and suggestions.<br />
<br />
== References ==<br />
<br />
# Digital Equipment Corporation, ''VAX-11/780 Architecture Handbook'', Maynard, Massachusetts, 1977. <br />
# D. M. Ritchie and K. Thompson, The UNIX Time-Sharing System, CACM 17, 7 (July 1974), 365-375. See also BSTJ 57, 6 (July-August 1978), 1905-1929. <br />
# W. Wulf, R. K. Johnsson, C. B. Weinstock, S. O. Hobbs, and C. M. Geschke, ''The Design of an Optimizing Compiler'', American Elsevier, New York, 1975. <br />
# J. F. Reiser, Common Instances of Pathological Span-dependent Instructions, TM 78-1353-3. <br />
# ''SCCS/PWB User's Manual, The Source Code Control System''. <br />
# S. C. Johnson, ''lint'', a C Program Checker. Computing Science Technical Report #65, Bell Laboratories, December 1977.<br />
<br />
<pre><br />
Program System Text Data Bss Total <br />
/unix <br />
PDP-11 48064 2470 44040 94574 <br />
VAX-11 34476 4292 39448 78216 <br />
Interdata 8/32 79976 11904 39208 131088 <br />
C, pass 1 <br />
PDP-11 36736 19826 17656 74218 <br />
VAX-11 37520 29492 23512 90524 <br />
Interdata 8/32 60606 32192 24920 117718 <br />
C, pass 2 <br />
PDP-11 21248 6254 5246 32748 <br />
VAX-11 23408 9092 7552 40052 <br />
Interdata 8/32 35652 9032 7560 52244 <br />
ed <br />
PDP-11 10752 302 4390 15444 <br />
VAX-11 11552 212 4556 16320 <br />
Interdata 8/32 21886 480 4576 26942 <br />
grep <br />
PDP-11 4736 408 1906 7050 <br />
VAX-11 4864 476 1936 7276 <br />
Interdata 8/32 11950 1160 1936 15046 <br />
ls <br />
PDP-11 7104 768 3856 11728 <br />
VAX-11 6884 1140 5764 13788 <br />
Interdata 8/32 15660 1920 5768 23348 <br />
nroff <br />
PDP-11 29312 6684 7842 43838 <br />
VAX-11 36360 9408 10636 58836 <br />
Interdata 8/32 – – – – <br />
sort <br />
PDP-11 6656 1578 2104 10338 <br />
VAX-11 6580 1764 2788 11132 <br />
Interdata 8/32 13886 2208 2792 18886 <br />
</pre><br />
Table 1. Loaded Program Sizes (in bytes)<br />
<br />
[[Category: Unix OS's]]<br />
[[Category: UNIX Documentation]]</div>Torhttps://gunkies.org/w/index.php?title=A_UNIX%E2%84%A2_Operating_System_for_the_DEC_VAX-11/780_Computer&diff=28438A UNIX™ Operating System for the DEC VAX-11/780 Computer2023-01-20T11:33:45Z<p>Tor: Fix and-> an in Abstract (which is not part of the original PDF)</p>
<hr />
<div>A UNIX™ Operating System for the [[Digital Equipment Corporation|DEC]] [[VAX-11/780]] Computer<br />
Thomas B. London<br />
<br />
John F. Reiser<br />
<br />
== Notes ==<br />
NOTE: This is a revived version of an internal Bell Labs memo by Reiser and London, dated July 7, 1978. This rendition was generated by OCR from a scanned copy of the original memo, with the result edited by Dennis Ritchie. <br />
This improved version of the HTML fixes some typos and adds markup that is missing even in the PDF and PS renditions. It was kindly supplied by Naoki Hamada. I am responsible for remaining problems.<br />
--DMR <br />
<br />
''Additional errors have since been fixed, by inspection of [https://www.bell-labs.com/usr/dmr/www/otherports/32vscan.pdf a scan of the original hard-copy]; for changes since DMR's version, see [https://gunkies.org/w/index.php?title=A_UNIX%E2%84%A2_Operating_System_for_the_DEC_VAX-11/780_Computer&curid=630&diff=28425&oldid=28424 here].''<br />
<br />
== ABSTRACT ==<br />
A UNIX operating system together with a complete user environment has been implemented on the VAX-11/780 computer manufactured by Digital Equipment Corporation. The VAX-11/780 system provides 32-bit addresses and data. It uses the same input/output devices as the PDP-11 family and is controlled through a console computer which can be remotely accessed. Additionally, the VAX-11/780 is priced nearly the same as a PDP-11/70 and executes most programs somewhat faster than a PDP-11/70. <br />
This memorandum describes the VAX-11/780 hardware and the UNIX operating system and the C programming language software implementation, records some observations on program portability, and speculates ways in which the operating system overhead can be significantly reduced. The authors conclude that the VAX-11/780 provides an excellent hardware environment for running UNIX and C software.<br />
<br />
== Introduction ==<br />
The VAX-11/780 [1] is a new, general-purpose, stored-program electronic digital computer manufactured by Digital Equipment Corporation. At minicomputer prices it provides addresses and data which are 32 bits wide; the traditional minicomputer address space bound of 64K is gone. This memorandum describes the VAX-11/780 and the implementation of a UNIX operating system and complete user environment for it. Section 2 contains an overview suitable for general consumption; details normally of interest only to devotees of computer system architecture appear in Section 3. The authors comment on software portability in Section 4. <br />
<br />
== Overview ==<br />
'''Environment.''' A user of UNIX and C software on the PDP-11 will find that the VAX-11/780 provides a very similar environment. There are no apparent differences in the command language or the vast majority of programs which are customarily invoked directly from the shell. A casual user probably will not be able to distinguish the hardware, except by issuing the command "who am i" (which identifies the hardware and the current user) or by noting that one of the columns printed by the process status command ps is in hexadecimal rather than octal. The C language programmer will find that int, long, and pointer data types all occupy 4 bytes (a short still occupies 2 bytes), and that a long has its two halves stored in a different order on the PDP-11 than on the VAX-11. Characters still suffer sign extension when converted to longer integer types, but one may use the declaration unsigned char. <br />
<br />
'''Hardware.''' The VAX-11 is a follow-on computer to the PDP-11. The architecture seen by the user-mode assembly-language programmer of a VAX-11 is "culturally compatible" with the PDP-11. Specific details differ, but a programmer familiar with the PDP-11 can quickly understand the differences. The VAX-11 provides UNIBUS and MASSBUS interfaces and uses the same input/output peripheral devices as a PDP-11. <br />
<br />
Significant new features of the VAX-1l include an extended virtual address space, intelligent console, and dramatically improved physical packaging. The address space of a process is divided into a few gigantic segments. Each segment is further divided into a large number of small pages. Sufficient hardware exists to make demand paging a viable memory management strategy. All console functions are handled by an LSI-11 microcomputer through a standard ASCII terminal. The terminal may be remotely located from the processor and can still halt, boot, or diagnose the VAX-11. The mechanical and physical design of the VAX-11/780 is well done. The processor contains no sliding drawers or moving cables. All parts are easily accessible for servicing. Adequate airflow is maintained even under maintenance conditions. <br />
<br />
'''Configuration.''' The actual configuration purchased by Department 1353 is: <br />
<br />
* VAX-11/780 cpu<br />
* 0.5 megabytes memory with battery backup<br />
* floating-point accelerator<br />
* 12Kbyte user-writeable control store<br />
* UNIBUS adaptor with DZ11 (8 RS-232C lines)<br />
* MASSBUS adaptor with TE16 tape drive (800/1600 bpi)<br />
* MASSBUS adaptor with two RP06 disk spindles (176M bytes per spindle)<br />
* additional BA11KE UNIBUS box<br />
<br />
The list price of the above configuration in February 1978 was $241,255; the price including a DEC discount to a Bell Labs purchaser was $200,242. <br />
<br />
'''Software.''' We have implemented a UNIX operating system [2] and complete user software environment on the VAX-11/780. The operating system is Research version 7 as of April 15, 1978. The environment includes the Bourne shell, C compiler, code improver c2, assembler, loader, debugger, standard I/O subroutine library libS, C subroutine library libc, source code control system SCCS, nroff/troff and more than 130 commands. Maintenance programs for file system checking, bootstrapping, and physical disk pack handling have also been implemented. <br />
<br />
We began with the C language code of Research version 7 of the UNIX operating system, and a PDP-11/45 running UNIX as a bootstrap machine. Creating a C compiler which produced VAX-11 native-mode assembly code was the first task. The code generator portion of the portable C compiler was rewritten to do this. An assembler and loader, based on similar code for the Interdata 8/32, completed the basic support software. Existing PDP-11/70 device drivers for disk, tape, and terminal communication lines were adapted to the VAX-11/780. Assembly language interfaces (trap handlers, hardware initialization, etc.) were completely rewritten. We then created magnetic tapes in the proper format for an initial file system and for deadstart load, and physically carried these tapes from the PDP-11/45 to the VAX-11/780. <br />
<br />
Work on the C compiler began in mid-December 1977. The hardware arrived on March 3. We held a party on May 19 to celebrate successful multiuser operation of the system. <br />
<br />
'''Performance.''' Identical documents were formatted by ''nroff'' on our VAX-11/780 and on a PDP-11/70 running Research version 7 UNIX; both systems used RP06 disks. Identical C programs were compiled and assembled on the VAX-11/780 and on the PDP-11/70. As reported by the ''time'' command, the results (converted to seconds) were: <br />
<br />
<pre><br />
nroff -ms -e -T450-12 ios.r >/dev/null <br />
<br />
real user sys <br />
VAX-11/780 47.0 28.6 8.7 <br />
PDP-11/70 54.0 36.9 7.9 <br />
<br />
cc -c -O pftn.c <br />
real user sys <br />
PDP-11/70 (Ritchie compiler) 86.0 43.5 11.8 <br />
VAX-11/780 (portable compiler) 82.0 64.0 10.5 <br />
PDP-11/70 (portable compiler 153.0 114.6 16.6 <br />
for Interdata 8/32) <br />
</pre><br />
<br />
From the statistics on ''nroff'' one should conclude that, based on user-mode CPU time, the VAX-11/780 can execute the code produced by the VAX-11 C compiler approximately 22% faster than the PDP-11/70 an execute the code produced by the PDP-11 C compiler. This is a measure of the combined power of the hardware and efficiency of the code generated by the compiler. Except as an upper limit, the figures give no indication as to the throughput, response time, or efficiency of the operating system. The differences in real time and system time between the VAX-11/780 and the PDP-11/70 are not significant. <br />
<br />
The times given for compilation of the file ''pftn.c'' are an attempt at a "black box" comparison of apples and oranges. The black box is any program (compiler) which takes C language input and produces executable instructions. The black-box comparison is that the current VAX-11 C compiler running on the VAX-11/780 and compiling code for the VAX-11 requires 49% more user-mode CPU time than the current PDP-11 C compiler running on the PDP-11/70 and compiling code for the PDP-11. The apples and oranges aspect arises because the two compilers, while equivalent from the black box viewpoint, are (on the inside) totally different pieces of software. The PDP-11 compiler is a production compiler written by D. M. Ritchie; the VAX-11 compiler is a portable compiler based on work by S. C. Johnson. The figures for the portable compiler running on the PDP-11/70 and compiling for the Interdata 8/32 are included for those who wish to compare two portable compilers. We have no VAX-11 equivalent to the Ritchie compiler, and thus cannot run the tests which would enable comparison of two production compilers. <br />
<br />
The loaded size in bytes of the operating system and seven other programs appears in Table 1. One should note the general similarity between the text (instructions) sizes on the PDP-11 and on the VAX-11, and between the bss (uninitialized data) sizes on the VAX-11 and on the Interdata 8/32. The particular PDP-11 UNIX system chosen has several more input/output device drivers and experimental multiplexing software not in the VAX-11 system, which accounts for its larger text size. If many global integer variables (or large arrays) are used, there is a tendency for the data and bss portions to double in size when going from a PDP-11 to a VAX-11 or an Interdata 8/32 because an int occupies two bytes on the PDP-11 and four bytes on the other machines. However, character arrays occupy the same amount of space on all machines. An unusually large number of references to global variables in the nroff program accounts for its increase in text size on the VAX-11 compared with the PDP-11. A program can be written to automatically change the addressing modes used in the VAX-11 code so that most references to global data become shorter than at present, but this has not been done. <br />
<br />
'''Evaluation.''' We believe that the VAX-11/780 provides an excellent hardware environment for running UNIX and C software. With the software in its current state, we view the system as operationally equivalent to a PDP-11/70 running UNIX software, except that the 64K limit on process address space is gone and programs run faster. We believe that the advanced memory management and user/system communication capabilities of the VAX-11/780 offer an opportunity to construct future UNIX-like systems with substantially higher throughput than provided by today's UNIX on a PDP-11/70.<br />
<br />
== Details ==<br />
=== Hardware ===<br />
<br />
Four main subsystems — the central processor, console, main memory, and input/output — constitute the VAX-11/780 computer system. The central processor, memory, and input/output subsystems are connected by the Synchronous Backplane Interconnect (SBI), an internal synchronous bus with a maximum data throughput of 13.3 megabytes per second. The SBI deals in physical addresses which are 30 bits wide. Half of the SBI address space is reserved for memory addresses, and half for input/output device registers. Arbitration for bus cycles on the SBI is distributed; each subsystem decides if it will use the next bus cycle. <br />
<br />
The central processor is a microprogrammed 32-bit general-register computer. The architecture seen by the user-mode assembly-language programmer is "culturally compatible" with the PDP-11; an expert programmer familiar with the PDP-11 can learn and understand the differences in one day or less. The processor handles binary integers of 8, 16, and 32 bits; single precision (32 bit) and double precision (64 bit) floating-point numbers; character strings up to 65535 bytes long; bit fields up to 32 bits wide; and IBM-style packed decimal strings up to 31 digits long. Bit fields have no alignment restrictions whatsoever, all other data types require alignment only to a byte (8 bit) boundary. The central processor provides sixteen 32-bit general registers. Register 15 is the program counter '''pc'''. Software operating in one of the privileged access modes (see below) must use register 14 as a stack pointer '''sp'''. The instructions which implement high-level procedure call and return ('''pushl''', '''calls''', '''callg''', '''ret''') assume a convention about the use of sp, register 13 ('''fp''', the frame pointer) and register 12 ('''ap''', the argument pointer). The instructions which handle character and packed decimal strings use registers 0 through 5 to hold pointers and counters, so as to be interruptible. Floating-point operations may use the general registers; there are no separate floating-point registers. Instructions take from zero to six operands. The operation code occupies one byte and is followed by the operands, which require from one to nine bytes each. Nine addressing modes (including all the PDP-11 modes except *-(r)) are allowed, and the addressing modes are independent of the operation code. When the central processor is executing in the context of a process, there are four access privilege modes (user, supervisor, executive, kernel), each with its own stack pointer; software which desires a per-process kernel stack is easy to implement. A fifth stack pointer is used when executing in a special system-wide interrupt context. The VAX-11/780 processor includes an eight kilobyte, two-way set associative, write-through, memory data cache; an eight-byte instruction stream buffer; and a 128-address virtual address translation buffer. Most of the processor is implemented in Schottky TTL MSI logic. A programmable realtime clock and a time-of-year clock (battery operated during loss of line voltage) are standard equipment. Options include a hardwired floating-point accelerator and user-writeable control store. <br />
<br />
The console subsystem consists of an LSI-11 computer, local memory, floppy disk, DECwriter terminal, and remote-access communications port. The console is connected directly to the central processor and performs all the functions of a conventional "lights and switches" front panel. The floppy disk serves as the initial bootstrap device for normal operation and holds special microcode for diagnostic operation. When activated by a key switch on the central processor, the remote-access port becomes the console. A terminal connected through the remote-access port can halt the central processor, boot it, diagnose it, etc. <br />
<br />
The virtual address space of a process running on the VAX-11/780 consists of 2**32 8-bit bytes. The two high-order bits of a 32-bit address determine one of four segments. Two of these segments are system segments common to the address space of all processes. One of the system segments is reserved for future use. The other two segments are separately defined for each process and are automatically managed by the context switching instructions. One of the per-process segments is designed for a stack which grows towards lower-numbered memory addresses. Segments are divided into pages of 512 bytes. Memory mapping hardware translates virtual addresses into physical addresses using page tables. A page table contains one four-byte entry for each page mapped; the entry contains a valid bit, a four-bit field which encodes access privileges, a modify bit, and the physical page-frame number where the page is mapped. (There is no reference bit which is maintained by hardware!) A base register and a limit register describe the page table of each segment. The base register of a per-process segment contains a virtual address within the system segment; the base register for the system segment contains a physical memory address. The VAX-11/780 central processor contains a virtual address translation buffer holding 128 virtual address-page frame number pairs which eliminates the need for extra memory references during address translation for (typically) 98% of all memory references. The memory is implemented using MOS semiconductor RAMs with an error correcting code which corrects all single-bit errors and detects all double-bit errors and 70% of all greater-than-double bit errors. A memory controller can handle 8 memory boards; using 4K chips each board can hold 128K bytes. There can be two memory controllers, thus the maximum amount of physical memory is currently 2 megabytes. When 16K chips are used [forecasted for late 1978], each board will hold 512K, and physical memory can be 8 megabytes. There is a battery backup option for maintaining data in the event of a power failure. Each optional battery will maintain l megabyte for 10 minutes. <br />
<br />
The input/output subsystem consists of UNIBUS adaptors and MASSBUS adaptors. A UNIBUS adaptor (UBA) is an interface between a standard UNIBUS and the SBI. The UBA does the bus arbitration and everything else necessary to administer the UNIBUS. It also contains a set of registers for mapping UNIBUS addresses to and from SBI addresses. The maximum throughput on a UBA is 1.5 megabytes per second. A MASSBUS adaptor (MBA) is an interface between the SBI and MASSBUS devices (RP06 disk, TE16 tape, etc.). An MBA would be more properly called an RH-780 controller, analogous to the RH-11 controller on a PDP-11/70 MASSBUS; only one unit may transfer data at a time, although several similar units connected to the same MBA can execute control functions simultaneously. The MBA contains the device control registers normally found in an RH controller. The registers lie in the I/O section of SBI addresses. An MBA also contains a set of mapping registers which translate device byte addresses to and from SBI addresses. The maximum throughput on a MBA is 2.0 megabytes per second. The published limits are 1 UBA and 4 MBAs per system. Theoretically one could have any number of either kind as long as the sum of the number of central processors, memory controllers, MBAs, and twice the number of UBAs were 15 or less, since the SBI has 15 "ports". <br />
<br />
The physical packaging of the system has been dramatically improved compared with the PDP-11. The VAX-11/780 processor cabinet contains no drawers or moving cables. The SBI is fixed and rigid. Three one-third horsepower squirrel-cage blowers provide sufficient air flow &151; even while servicing the CPU. Any logic card, power supply, or blower can be replaced within twenty minutes by one person using only a screwdriver. The CPU stands 1.53m x 1.17m x 0.77m (HWD); cabinets housing the CPU, UNIBUS devices, and tape drive are usually bolted together to form a single unit 1.53m x 2.51m x 0.77m. Our configuration (see section 2) weighs 3452 pounds and requires 42050 BTU/hr cooling. <br />
<br />
=== C Compiler ===<br />
A VAX-11 "native mode" C compiler was constructed using S. C. Johnson's portable compiler as a base. After one month, a reasonable version began to evolve: it produced code which was good enough to exercise the assembler, loader, and debugger (on the bootstrap PDP 11/45). This initial version did not make use of VAX-11 indexed addressing (which does single-level array subscripting including appropriate index shifts), bit field instructions, or autoincrement/decrement addressing. It contained its share of bugs, particularly since the hardware had not arrived and could not be used to actually run the generated code. <br />
<br />
Substantial effort has been subsequently directed towards improving all aspects of the compiler: bugs have been corrected, routines have been made to execute more efficiently, and the quality of the generated code has been improved. All addressing modes are supported, bit field instructions are used for programmer-defined bit fields, and autoincrement and autodecrement addressing as well as three-address instructions are used. <br />
<br />
Overall, our experience with the compiler has been very favorable. When the VAX-11/780 was delivered, the compiler worked well enough to compile itself, the UNIX kernel, and many user-level commands. In fact, since the delivery of the machine, only about a half-dozen serious bugs have been detected. Additionally, the framework of the compiler has proven itself to be flexible: a compiler for the Interdata 8/32 was transformed into a compiler for the VAX-11/780, some improvements and extensions were easily added, and, in general, a quickly evolving compiler has remained stable and productive. The authors feel that, with a few extensions to the model of the compiler and a certain amount of tuning, the current VAX-11 compiler could easily remain as the production VAX-11 compiler. <br />
<br />
There are still some deficiencies in the current version of the compiler, as well as in the basic "product" itself. The compiler is slow and quite large; see the statistics in section 2 and Table 1. Some of the blame for the size and lethargy of the first pass can be attributed to the use of ''lex'' for the scanner and ''yacc'' for the parser, and to the use of ASCII to communicate information between passes. Both ''lex'' and ''yacc'' produce large routines: the scanner is 17K bytes in length (over 4.5K bytes of instructions), and the parser is 16K bytes long (over 5.5K bytes of instructions). On the average, the first pass spends 20% of its time in the lexical scanner ''yylook'', and 9% of its time in the parser ''yyparse''. <br />
<br />
Using ASCII to communicate between the two passes causes an additional speed penalty for character conversion. On typical programs, the fast pass (parser) spends roughly 30% of its time performing output services (i.e.,, calls to ''_doprnt'' (18%), ''_strout'' (8%), and ''printf'' (4%), while the second pass (code generator) spends roughly 21% of its time reading it back in (i.e., calls to ''read'' (18%) and ''rdin'' (3%). (Additionally, the routine used to convert from ASCII to binary contained a bug which caused "-2147483648" (which is -(2**31) ) to be read as zero on our PDP-11/45.) <br />
<br />
The above problems are not inherent to the compiler model. To speedup compilation, the scanner can be hand-coded (as in the standard PDP-11 compiler), and the interpass data can be formatted in binary (or the two passes can be combined). With these simple modifications (some are already in progress), it should be possible to produce a compiler almost twice as fast as the current one. <br />
<br />
Two features of the VAX-11 architecture — three-address instructions and indexed addressing mode — were difficult to model within the basic structure of the compiler. The full implementation of three-address instructions proved to be so difficult that it was not really attempted. Instead, ''c2'', the assembly language code improver, tries to merge several instructions into an appropriate three-address instruction. For example, the statement a = b + c compiles <br />
<pre><br />
addl3 b,c,r0<br />
movl r0,a<br />
</pre><br />
which the improver can change to: <br />
<pre><br />
addl3 b,c,a<br />
</pre><br />
for a savings of three bytes and over 400 nanoseconds. However, ''c2'' will not always succeed in this shortening. It cannot tell the difference between <br />
<pre><br />
a = b + c<br />
return;<br />
</pre><br />
and <br />
<pre><br />
return(a = b + c);<br />
</pre><br />
since register r0 must be considered "live" (i.e., contains a value which may be required later) across the return statement. <br />
<br />
The VAX-11 has six indexed addressing modes which yield the address of an element of a one-dimensional array of a base type ('''char''', '''short''', '''int''', '''long''', pointer, '''float''', or '''double'''). The statement <br />
<pre><br />
a[i] = b[j] * c[k];<br />
</pre><br />
where ''i'', ''j'', and ''k'' are declared '''register int''' and ''a'', ''b'', and ''c'' are '''double''' arrays (either external or local) can be compiled into the single instruction: <br />
<pre><br />
muld3 b[j],c[k],a[i]<br />
</pre><br />
Although the index specifier (e.g. ''i'' in the above example) must be a register, the base address specifier can be any addressing mode except register, literal, or another indexed mode. For example, the C-language constructs ''a[i]'', ''(*p)[i]'', ''(--p)[i]'', ''(p++)[i]'' and ''(*p++)[i]'' (or their equivalents ''*(a+i)'', ''*(*p+i)'', ''*(--p+i)'', ''*(p++ +i)'', and ''*(*p++ +i)'', respectively) all can be done with a single VAX-11 address (where ''a'' is an array of base type, ''p'' is a pointer to the same type, and ''i'' is of type register int). It is usually difficult to recognize or conveniently represent such constructs (e.g., ''(-p++)[i]'' is fun), or generate the possible cases (e.g., ''a[i]'' where ''a'' is not readily addressable). <br />
<br />
The fact that the code generator can easily recognize only expression trees of height one (two if OREG and UNARY MUL nodes are taken into account) causes substantial difficulty in making use of indexed mode, three address instructions, and indirect addressing. Expression trees of non-trivial height occur not infrequently (e.g. as a worst case, the statement <br />
<pre><br />
a = b + (*p++)[i];<br />
</pre><br />
has an expression tree of height six, but can be compiled into the single instruction <br />
<pre><br />
addl3 b,*(p) + [i],a<br />
</pre><br />
if ''p'' and ''i'' are register variables). The complexity of the code generator is raised by forcing the compression of subtrees into single nodes which are then treated with special checks, special code, etc. <br />
<br />
The size and alignment attributes of data objects are logically independent, even though previous hardware architectures (IBM 360, PDP-11, Interdata 8/32, ...) have imposed alignment restrictions based on size. The VAX 11/780 has no such restrictions, although programs run faster with data aligned on natural boundaries. The C language has little notion of alignment; because of run-time penalties, the VAX-11 C compiler aligns all the basic data types on address boundaries which are a multiple of sizeof the basic type. Due to questions about alignment, both the language and the compiler have difficulty with the declaration ''char c:10;''. <br />
<br />
The decision to naturally align most data items has undesirable side effects which cannot be ignored. Consider the structure declaration <br />
<pre><br />
struct foo {<br />
char c;<br />
float f;<br />
} bar;<br />
</pre><br />
On the PDP-11, sizeof(''foo'') is 6 bytes while on the VAX-11, sizeof(''foo'') is currently 8 bytes (the offset of ''f'' within ''bar'' is 2 and 4 respectively). sizeof(''foo'') could be 5 bytes in each case. Although both machines use the same data formats for chars and floats, the differing alignment imposed by the the VAX-11 C compiler means that the two machines cannot speak directly to one another using media which record structures containing binary information. Since alignment is important, we feel that it ought to be specifiable in the C language. <br />
<br />
=== Operating system conversion ===<br />
A UNIX system running on a PDP-11/45 was used as the base for transporting software to the VAX-11/780. The software itself originated with the code produced by members of Center 127, Computing Science Research, for the Interdata 8/32. Programs were cross compiled, assembled, loaded, and put an magnetic tape in ''tp'' format; absolute bit-string files were put on tape in ''dd'' format. Tapes were then carried across the room to the VAX-11/780. An absolute tape boot (in machine language), ''tp'' boot and primary disk boot (in assembly language), secondary disk boot (in C), and stand-alone utilities (disk formatter, disk verifier, tape-to-disk, disk-to-tape, disk-to-disk, and disk-to-console, all in C) were then used to bring up the system. <br />
<br />
Establishing an initial file system on the disk took longer than expected. The PDP-11/45 was running USG issue 3 of the UNIX operating system with a "16-bit" file system and the VAX-11/780 was to have a Research version 7 "32-bit" file system. Also, C-language code on the VAX-11 expects the bytes of a 32-bit integer to be stored in a different order than C-language code on the PDP-11. We swallowed these two red herrings hard, and suffered. We now know that the proper way to create an initial file system is to modify the program ''mkfs'' so that its output (on the bootstrap machine) is a file containing the proper bits, put that file on tape, and use the tape-to-disk utility on the target machine. <br />
<br />
Mapping the software architecture of the UNIX operating system onto the hardware architecture of the VAX-11 required a number of decisions. Commentary on these decisions follows.<br />
<br />
The SCB (system context base) processor register contains a page-aligned physical memory address which is the base of the hardware interrupt vector. The UNIX system puts this vector at physical memory address zero. <br />
<br />
Operating system code, data, kernel stacks, and interrupt stack occupy the VAX-11/780 system segment (virtual addresses 80000000 to bffffff). User code and data are loaded into segment zero (0 to 3fffffff) and the user stack is initialized in segment one (7fffffff to 4000000). User processes pass arguments to system service code using the ordinary '''calls''' subroutine calling sequence. The '''ckmk''' instruction is then used to gain kernel privileges. The '''chmk''' instruction switches the stack pointer '''sp''' from the user stack to the kernel stack, but does not change the argument pointer '''ap''' or the frame pointer '''fp'''. The kernel uses the value in '''ap''' to copy the arguments into ''u.u_arg''. The VAX-11 hardware allows the values to be directly addressed, but the kernel software requires the copy. <br />
<br />
The ''u area'' is a per-process data structure in which the operating system keeps swappable information about a process. The kernel virtual address of the ''u area'' must be a constant across all processes. The PDP-11 implementation puts the ''u area'' at kernel address 0160000; when process switching occurs the ''u area'' is switched by changing a kernel data space segmentation register. Since the operating system can address user memory on a VAX-11, the ''u area'' could be placed in (protected) user memory, say at address 0 or at 7fffe000. However, it was desirable for the first implementation to make the page tables for user segments part of the ''u area'', which creates timing problems unless the ''u area'' lies in system space. The base of the ''u area'' was assigned kernel virtual address 80020000. When process switching occurs, the ''u area'' is changed by changing the system-space page table and invalidating the page-table translation cache for the appropriate pages. <br />
<br />
Since the operating system can directly address the memory of the current user process, the procedures ''fubyte'', ''subyte'', ''fuword'', etc., are unnecessary and could be made into macros which would merely do the appropriate load or store. However, these procedures (along with ''copyin'' and ''copyout'') were kept to ensure that each access to user space is valid. <br />
<br />
A VAX-11/780 internal processor register called the PCB (process context base) points to an area in which the VAX-11/780 saves the hardware state of the machine (96 bytes) when switching context. This save area was put in the ''u area'' as ''u_rsav''. <br />
<br />
The implementation of context switching required major effort. The VAX-11 has two very nice instructions ('''svpctx''', save process context; and '''ldpctx''', load process context) which facilitate context switching. Unfortunately, they do not implement the mechanism which the UNIX system expects. The mechanism used by UNIX is so dispersed and intricately detailed that it is hard to imagine any hardware which implements it directly.) The temptation to drastically change the UNIX code has been resisted so far. The ''savu/retu/aretu'' tar pit was VAX-inated, but it took more than a week. The newer ''save/restore'' primitive does make the C-language code prettier, but the assembly-language side (at least for the VAX-11) is just as dirty as ever. The UNIX context switching mechanism requires three state save areas, ''u.u_rsav'', ''u.u_ssav'', and ''u.u_qsav'' because the same mechanism is also used for abnormal returns. The VAX-11 context-switching instructions use only a single state save area. To make use of the VAX-11 instructions, the software simulates a great deal of microcode and bastardizes call frames in a most ugly manner. Context switching is certainly high on the list of things to rewrite in the second implementation (even for the PDP-11!). <br />
<br />
The procedures ''sureg'' and ''estabur'' were also tricky to implement. They were designed with the assumption that only a small number (16 or fewer) of registers would be needed to map the address space of a user process, while on the VAX-11 a 32K process requires 64 page table entries. Furthermore, the memory map of a process is diddled in tricky ways, particularly in ''expand'' and ''getxfile''. <br />
<br />
Handling DMA I/O hardware was the other major implementation bottleneck. The UBA and MBA mapping registers contain physical memory page numbers, and physical addresses are hard to handle. It is not pleasant to deal with the hardware which implements the mapping registers. If an I/O transfer is in progress then the mapping registers may be neither read nor written; this applies even to registers which would not be used by the transfer. As a result, the map for the next I/O operation cannot be setup during the current I/O operation. Furthermore, a single transfer is limited to 64K bytes because the byte counter is only 16 bits wide. Thus swapping a process to the disk can require multiple I/O operations. The solution to these problems involved permanently reserving the last 129 registers in each map to service both swap and physical I/O operations. The remaining map registers are available to map the system buffers, and are loaded at system initialization time. Disk ECC error correction is currently done only for I/O involving the system buffers. Disk errors on raw I/O cause process termination; the swap area on disk had better be error-free. <br />
<br />
Like the UNIX system for the PDP-11, the current implementation for the VAX-11/780 maintains each process in contiguous physical memory and swaps processes to disk when there is not enough physical memory to contain them all. Reducing external memory fragmentation to zero by utilizing the VAX-11/780 memory mapping hardware for scatter loading is high on the list of things to do in the second implementation pass. To simplify kernel memory allocation, the size of the user-segment memory map is an assembly parameter which currently allows three pages of page table or 192K bytes total for text, data, and stack. This also deserves to be rewritten, both to allow varying process size, and to allow processes larger than physical memory through demand paging. Dynamic page table size would mean dynamic ''u area'' size if the page table remained part of the ''u area''. <br />
<br />
The code in ''sendsig'' for sending a signal to a process involves a tedious simulation of the '''calls''' instruction due to the problem of "inward return" across privilege modes upon termination of the routine which handles the signal. Making a portion of the kernel code readable by a user-mode process would simplify ''sendsig''. Motivated by a problem with the Bourne shell, the signal number is passed as a parameter to the signalled routine. <br />
<br />
Interprocess communication via signals (''signal'' and ''kill'') uses the low-order bit of a machine address for something other than addressing. This implies that a procedure which handles signals must start on an even byte boundary, which means that every procedure must start on an even byte boundary. The C compiler thus issues a pseudo-op to the assembler to align the beginning of each procedure. This can waste memory on a VAX-11. It also imposes a nontrivial requirement on the assembler, since if the resolution of conditional jump instructions can change the parity of the length of a procedure then the alignment directive must also be handled like a conditional jump. In hindsight, it would have been better if a distinct value (say +1 or -1) were used for ''ignore'', rather than multiplexing the bottom bit. <br />
<br />
The VAX-11/780 provides a (non-maskable) trap for integer division by zero. The system would like to turn this into a signal to the process. A similar situation exists for subscript range trap. Integer overflow, floating overflow, floating underflow, and reserved operand also need signal numbers. Perhaps only one "error" signal is needed with some other means for determining the true fault. The whole business of interrupts, signals, asynchronous I/O, and the use of the hardware AST mechanism deserves more attention. <br />
<br />
A bug was discovered in the UNIX code for process termination involving the ''proc'' and ''xproc'' structures. (The problem also existed on the PDP-11, but it would only be noticed if a process had accumulated more than 65535 ticks of system time, which is highly unlikely.) When a process dies its resource utilization statistics (currently only exit status, system, and process CPU time) are temporarily saved so that they can be added to the totals for the descendents of the parent process. The actual accumulation is done by the kernel when the parent process issues a '''wait''' system call; the child process is then completely erased. The kernel was overlaying the statistics in a part of the ''proc'' structure normally used by the scheduler to contain the pointer ''p_textp''. Ordinarily the exit was processed immediately, causing no harm. But if the system was loaded so that swapping was necessary, then the scheduler could sneak in after the child exited and before the parent read the statistics, and would interpret the timing data in the zombie ''xproc'' structure as a pointer. This invariably caused an illegal memory reference from kernel mode on the VAX-11/780. <br />
<br />
One of the greatest disappointments with the current system stems from a design quirk in the FP-11 floating-point processor for the PDP-11. When converting between floating-point and 32-bit integer, the FP-11 expects the high-order 16 bits of the integer to be stored at the lower memory address; this is not in line with the general "right to left" design of the PDP-11, which would place the low-order 16 bits in the lower memory address. C code for the PDP-11 uses the FP-11 convention for storing '''long''' integers. The VAX-11 hardware stores the least significant bit of ''any'' integer data type in the lowest addressed byte. C code for the VAX-11 uses the hardware convention. This means that files containing long integers represented in the local convention are not binary compatible between a UNIX system on the VAX-11 and a UNIX system on the PDP-11. This is the only exception for data types common to both machines: '''char''', '''short''', '''float''', and '''double''' all have a common representation. Except for this (and the structure alignment problem noted earlier), disk packs containing 32-bit file systems, tapes, etc., would have been interchangeable. The fact that DEC's Fortran-IV Plus for the PDP-11 avoided the FP-11 convention, and that RSX-11 files ''are'' binary compatible between the VAX-11 and the PDP-11, is only salt on an open wound! <br />
<br />
=== Subroutine libraries ===<br />
'''libc'''. Conversion of the system-call interface routines was straightforward but tedious. Most routines are merely <br />
<pre><br />
.word 0x0000<br />
chmk $nn<br />
bcc L1<br />
jmp cerror<br />
L1: ret<br />
</pre><br />
The routines ''printf'', ''ecvt'', and ''fcvt'', were left to '''libS''' and were not implemented in '''libc'''. <br />
<br />
'''libS'''. Conversion of the standard input/output library '''libS''' posed no problems except for ''_doprnt'', the routine which constructs character representations of other datatypes for the printing routines ''printf'', ''fprintf'', and ''sprintf''. Since many programs spend 15% to 20% of their execution time within ''_doprnt'', it pays to code the routine for speed in assembly language. Packed-decimal instructions handle decimal, unsigned, and floating-point conversions. The algorithm chosen for converting from floating-point to character string revealed a microcode bug in the VAX-11/780's '''ashp''' (arithmetic shift and round packed) instruction. Under certain conditions a carry from the rounded digit propagated both to the adjacent digit and to the digit eight places further left. This usually caused an overflow, since the destination packed-decimal string was typically not long enough to represent the spurious carry. DEC claims to have a fix for the bug, but the FCO has not arrived. In the meantime a five-instruction patch detects and corrects the spurious overflow. <br />
<br />
=== Commands ===<br />
'''as''', '''ld'''. Code developed by Center 127 for the Interdata 8/32 was the model for an interpretation by a VAX-11/780 artist. The assembler uses an algorithm described in [3] with heuristic improvement of [4] to resolve conditional jump pseudoinstructions. Variable-length, unaligned instructions and address constants forced the relocation information in object tiles to include the explicit segment-relative address for each relocatable datum, rather than deducing the address from a one-to-one correspondence between the position in the segment and the corresponding position in the relocation table. This caused a slight change in the header information within object files. <br />
<br />
'''c2'''. The code improver for the assembly language generated by the VAX-11 C compiler is based on a similar program for the PDP-11. A "backwards" register usage pass, performed once and before anything else, was a major addition. Knowing that no temporary register is live across a backwards jump, the register usage pass introduces three-address instructions wherever possible. It also recognizes situations where jump on bit ('''jbc''', '''jbs''', '''jlbc''', '''jlbs'''), extract field ('''extzv''', '''movzbl'''), and move address ('''moval''', '''movab''', '''pushal''', '''pushab''') instructions can be used. The code for insertion of fancy loop control instructions '''sob''', '''aob''', '''acb''' was also extended. <br />
<br />
'''adb'''. The most significant change to the symbolic debugging routine was the writing of a disassembles for VAX-11 native-mode instructions. Additionally, the character input and output routines were modified to use a default radix for all numeric values. The radix is initialized to sixteen. <br />
<br />
'''sh'''. The (Bourne) shell is the standard user command interpreter. It required by far the largest conversion effort of any supposedly portable program, for the simple reason that it is not portable. Critical portions are coded in assembly language and had to be painstakingly rewritten. The shell uses its own ''sbrk'' which is functionally different from the standard routine in libc. The shell wants the routine which fields a signal to be passed a parameter giving the number of the signal being caught; ''signal'' was also a private routine. This was handled by having the operating system provide the parameter in the first place, doing away with the private code for ''signal''. The code in ''fixargs'' (for constructing the argument list to an '''exec''' system call) had to be diddled. <br />
<br />
'''ps''', '''iostat'''. The process and input/output status commands consistently referenced ''/dev/mem'' (physical memory) when they should have referred to ''/dev/kmem'' (kernel virtual memory). ''iostat'' also assumed that certain variables maintained by the kernel were allocated contiguously, even though they were not declared as part of a structure. <br />
<br />
'''pr'''. The command which formats and prints files had a bug that caused a division by zero when it was asked to print several files and the fist file in the list did not exist. On a PDP-11 division by zero returns the dividend, but on a VAX-11 it gives an unmaskable trap. <br />
<br />
'''cat''', '''dc'''. These two commands did not count their arguments using the first parameter ''argc'', but rather assumed that an additional argument (''argv[argc]'', initialized as -1) could be used as a pointer. On the PDP-11 the resulting address references the fixed end of the stack; on the VAX-11, -1 is an illegal address. <br />
<br />
'''nroff/troff''' The source code for the document preparation and phototypesetter commands is not portable; several weeks were required to produce properly running version of these commands. Use of the explicit (or worse, implicit) constant "2" instead of '''sizeof(int)''' was quite common. The code assumes that variables which are adjacent in external declarations occupy contiguous memory at execution time. Several tables are initialized by assembly-language programs. Converting the tables was merely tedious; changing the code which thought it knew the format of an ''a.out'' file required some effort. This memorandum was created using the converted ''nroff/troff'' programs on the VAX-11/780. <br />
<br />
'''SCCS'''. Version 4 of the Source Code Control System [5] is used to provide version backup for software in case disastrous bugs are introduced. The source for SCCS itself had not quite been converted to version 7 UNIX, and the header files required some massaging. The PWB routines ''logname'' and ''pexec'' had to be simulated. The utility procedures for dynamic storage allocation required some work to integrate them with '''libS''' and to remove PDP-11 dialect. The exit status of the ''diff'' command changed in version 7, causing ''delta'' to bomb. The code implicitly assumed that all checksums were computed modulo 65536. The documentation is incorrect: everywhere "99999" appears it should really say "65535". The procedure ''satoi'' returns two values, storing one of them indirectly through a pointer parameter. Naturally, ''satoi'' and its callers did not agree on '''sizeof''' the stored value; this took a day to track down. <br />
<br />
== 4. Software portability ==<br />
We thank the members of Center 127, Computing Science Research, for their efforts in producing the basic software and for their recent efforts towards making the software portable. The fact that people other than the original developers an quickly create a running system for a new machine is a tribute to how well the original work was done. <br />
<br><br />
Yet in our effort to transport a complete UNIX system to the VAX-11/780 we stumbled across a large number of nonportable constructions and were dismayed by the seeming lack of appropriate facilities to detect and prevent them. Based on our experience, we strongly recommend that the C language and its compilers be enhanced so that <br />
<br />
# The actual arguments in a procedure call are type checked against the procedure declaration, and a "dummy" declaration which specifies types is permitted even if the called procedure is not actually declared in the same compilation.<br />
# The '->' operator is checked to insure that the structure element on the right is a member of a structure to which the pointer on the left may point.<br />
# A structure element may be declared with any name as long as the name is unique within the immediately surrounding structure. (The current requirement that a structure element name must uniquely correspond to an offset from the beginning of the structure, across all structures in a compilation, creates naming problems and frequently leads to errors of the type noted in item 2 above.)<br />
# The issue of alignment to an even-byte (or other) boundary is brought into the open, so that arbitrary data structures can be accurately described.<br />
<br />
There is a program called ''lint'' [6] which, if conscientiously used throughout the life of a piece of software provides type checking which partially addresses the first two points in the above list. The problem is that ''lint'' is big, noisy, relatively recent and unknown, and (partially as a result) infrequently used. There is little incentive for the average programmer to use ''lint'' as a matter of course. The authors believe that type checking belongs in the everyday compiler as the default, where it is very inexpensive to implement. Those who wish to do "dirty" work may request that type checking be disabled; those who wish to bless their dirty work may use type casts. <br />
<br />
We believe that these four enhancements would go a long way towards making C language software portable as a rule rather than as an exception, thus preserving Bell Laboratories' investment in present and future C software. <br />
<br />
''Acknowledgements''. Thank you, D. M. Ritchie and S. C. Johnson, for answering questions at key moments; G. K. Swanson, for assistance with boot procedures and stand-alone utilities; J. F. Jarvis, for the mathematical function library; and D. K. Sharma, for help in bringing up user-level commands. Additional thanks go to many other members of Centers 127 and 135, and Department 8234, for helpful comments and suggestions.<br />
<br />
== References ==<br />
<br />
# Digital Equipment Corporation, ''VAX-11/780 Architecture Handbook'', Maynard, Massachusetts, 1977. <br />
# D. M. Ritchie and K. Thompson, The UNIX Time-Sharing System, CACM 17, 7 (July 1974), 365-375. See also BSTJ 57, 6 (July-August 1978), 1905-1929. <br />
# W. Wulf, R. K. Johnsson, C. B. Weinstock, S. O. Hobbs, and C. M. Geschke, ''The Design of an Optimizing Compiler'', American Elsevier, New York, 1975. <br />
# J. F. Reiser, Common Instances of Pathological Span-dependent Instructions, TM 78-1353-3. <br />
# ''SCCS/PWB User's Manual, The Source Code Control System''. <br />
# S. C. Johnson, ''lint'', a C Program Checker. Computing Science Technical Report #65, Bell Laboratories, December 1977.<br />
<br />
<pre><br />
Program System Text Data Bss Total <br />
/unix <br />
PDP-11 48064 2470 44040 94574 <br />
VAX-11 34476 4292 39448 78216 <br />
Interdata 8/32 79976 11904 39208 131088 <br />
C, pass 1 <br />
PDP-11 36736 19826 17656 74218 <br />
VAX-11 37520 29492 23512 90524 <br />
Interdata 8/32 60606 32192 24920 117718 <br />
C, pass 2 <br />
PDP-11 21248 6254 5246 32748 <br />
VAX-11 23408 9092 7552 40052 <br />
Interdata 8/32 35652 9032 7560 52244 <br />
ed <br />
PDP-11 10752 302 4390 15444 <br />
VAX-11 11552 212 4556 16320 <br />
Interdata 8/32 21886 480 4576 26942 <br />
grep <br />
PDP-11 4736 408 1906 7050 <br />
VAX-11 4864 476 1936 7276 <br />
Interdata 8/32 11950 1160 1936 15046 <br />
ls <br />
PDP-11 7104 768 3856 11728 <br />
VAX-11 6884 1140 5764 13788 <br />
Interdata 8/32 15660 1920 5768 23348 <br />
nroff <br />
PDP-11 29312 6684 7842 43838 <br />
VAX-11 36360 9408 10636 58836 <br />
Interdata 8/32 – – – – <br />
sort <br />
PDP-11 6656 1578 2104 10338 <br />
VAX-11 6580 1764 2788 11132 <br />
Interdata 8/32 13886 2208 2792 18886 <br />
</pre><br />
Table 1. Loaded Program Sizes (in bytes)<br />
<br />
[[Category: Unix OS's]]<br />
[[Category: UNIX Documentation]]</div>Torhttps://gunkies.org/w/index.php?title=OS/2&diff=28437OS/22023-01-20T09:15:21Z<p>Tor: Fixed a few typos (and possessive "its") and links.</p>
<hr />
<div>[[Image:OS2 1.x neonlogo.jpg|thumb|150px|right|OS/2's early logo]]<br />
<br />
'''OS/2''' started as a collaborative effort between [[International Business Machines|IBM]] and [[Microsoft]] to put together the next generation [[operating system]] for the [[IBM AT]] and [[IBM PS/2|PS/2]] machines. <br />
<br />
Microsoft, famous for hedging bets, started the [[Microsoft Windows|Windows]] project around the same time, as a low cost entry interface with rudimentary (cooperative) [[multi-tasking]].<br />
<br />
Needless to say, Microsoft wanted to target the [[Intel 80386|i386]] processor, and work on 32-bit software, while IBM wanted to deliver to the IBM AT customers it had sold to, and the upcoming [[PS/2 model 60]], hence the demand for the [[Intel 80286|i286]] 16-bit version. Someone at IBM even got the idea that the development tools should be a revenue stream, and needless to say, the $3,000 SDK was '''NOT''' a big seller. Instead, the industry worked around OS/2, and developed [[DOS extender]] technology, and Microsoft practically gave away the Windows SDK, allowed for [[OEM]] customizations, and famously released the [[QuickC for Windows]] product.<br />
<br />
Microsoft leapt at the chance to formalize DOS extenders into [[DOS Protected Mode Interface|DPMI]], and use it in Windows, cementing OS/2's 1.x inability to run DPMI programs. Microsoft was also upset that IBM locked them out of the graphical components of the OS, and that OS/2 worked BACKWARDS compared to Windows... the 0/0 in the screen coordinates is the bottom right, while everywhere else it's the top left..<br />
<br />
There is a great writeup on the divorce on Google's [http://groups.google.com/group/comp.os.ms-windows.misc/msg/d710490b745d5e5e usenet archive], or locally here [[Gordon Letwin OS/2 usenet post]]. There is also a perspective from an Autodesk programmer available [http://www.sibbald.com/windows/windows01.html here].<br />
<br />
With a bit more research and having things in hand, OS/2 as mentioned in the book ''Inside OS/2'', is clearly an evolution from the [[MS-DOS]] 4.00M, the multi-tasking version of DOS. There was clearly a need for an 'advanced' operating system on the desktop, unfortunately in retrospect Microsoft had to get involved with IBM and derail the industry for nearly a decade.<br />
<br />
== Versions ==<br />
<br />
=== Pre-Release version ===<br />
In the beginning there are several known pre-release versions, then followed up with the infamous $3,000 SDK package. These include:<br />
<br />
* A/DOS<br />
* SIZZLE<br />
* FOOTBALL<br />
<br />
The SDK versions have recently surfaced on archive.org and are currently known to be:<br />
* [[Microsoft OS/2 beta 1.00|1.00]]<br />
* 1.01<br />
* 1.02<br />
* 1.03<br />
* 1.05<br />
* 1.06<br />
<br />
=== 16 bit versions ===<br />
All of these versions require an i286 [[Central Processing Unit|CPU]], and an IBM AT, or PS/2 compatible computer. All of the 16-bit versions were limited to a SINGLE MS-DOS compatibility box, greatly reducing the overall usefulness of OS/2 with the ever increasing prevalence of MS-DOS based applications. At the same time, the 16-bit version supported swapping, DLL's, threads and preemptive multi-tasking. There was an excellent overview of the original OS/2's in the book [http://ebooks.znu.edu.ua/files/comp_books1/cd0/isos2.txt Inside OS/2].<br />
<br />
*1.0<br />
[[Image:Microsoft OS2 1.0 - Heathkit Zenith OEM.jpg|thumb|right|150px|OS/2 1.0]]<br />
This version was all textmode, and had an interface that was inspired from [[TopView]]. Although it could multi-task, most people didn't realize it, as all programs ran full screen. It ran in 286 protected mode, except for the single "DOS" mode session. As a result all device drivers for OS/2 had to be able to run in [[real mode|real]] & [[protected mode]]. Until 1.3 all versions were released by OEM hardware vendors ([[Compaq]], [[Zenith]] etc, along with IBM), this was normal practice for Microsoft at the time.<br />
<br />
The IBM OS/2 1.0 announcement can be read [[IBM OS2 1.0 announcement|here]].<br />
<br />
*1.1<br />
[[Image:IBM OS2 1.1 full package.jpg|thumb|right|150px|OS/2 1.1 full package]]<br />
OS/2 1.1 was released in 1988, and was the first version to include the [[Presentation Manager]]. It 'looked' identical to that of [[Windows 2.0]]. IBM OS/2 1.1 included the PM version of [[Borland Sidekick]] to fill in the gap of accessories for OS/2. While there was some initial excitement over this version of OS/2, it quickly faded as you had to either buy a new computer with it installed, or jump through OEM channels to get OS/2. Microsoft didn't sell OS'es to end users in the 1980s (This didn't change until OS/2 1.3, MS-DOS 5 & Windows NT 3.1). Version 1.1c was 386 aware, in that it could use the 80386's ability to quickly & easily transition from real & protected modes, bypassing the [[triple fault]] method of the 286. <br />
<br />
*1.2<br />
[[Image:IBM OS2 1.2 box cover.jpg|thumb|right|150px|OS/2 1.2 box]]<br />
I think this version was released in September of 1988. This release was significant with the inclusion of the [[HPFS]] [[file system]]. HPFS was significantly faster then the aging [[FAT]] file system as it placed its tables in the middle of the disk, and it allowed for larger file systems, long filenames and extended attributes. A later [[service pack]] allowed for 386 and above CPUs to use the 386 method of switching between real & protected mode, allowing it to operate significantly faster (1.2c). From what I understand this was the last version of OS/2 that included direct involvement from Microsoft.<br />
<br />
OS/2 1.2 from IBM included the 'standard' edition, along with the EE or extended edition. The EE edition included basic communications capability (x.25, rs232 terminal), and a SQL database.<br />
<br />
[[InfoWorld]] included an excellent review of OS/2 1.2 [http://books.google.com/books?id=1DsEAAAAMBAJ&lpg=PT79&dq=%22OS%2F2%201.2%22&pg=PT66#v=onepage&q=%22OS/2%201.2%22&f=false|here].<br />
<br />
*1.21<br />
I think this version was a Microsoft exclusive, and the final version that they were directly involved in.<br />
<br />
*1.3<br />
[[Image:Microsoft OS2 front.JPG|thumb|right|150px|Microsoft OS/2 1.3]]<br />
This was the last version of the 16 bit OS/2 family. The 1.3 user interface resembled that of [[Windows 3.0]]. Microsoft did include a 32-bit HPFS driver in their [[Lan Manager]] package which allowed for the fastest HPFS implementation prior to OS/2 2.0 & Windows NT 3.1 <br />
<br />
Around this time, Microsoft had released a beta of the WLO or Windows library for OS/2. The beta included a copy of all of the applettes & games from Windows 3.0 that could run in the Presentation Manager of OS/2. These libraries were also used to deliver the last versions of Microsoft Word & Excel for OS/2. Microsoft had planned on releasing these libraries to allow people to easily port their Windows applications to OS/2, but the rift had happened right before that date, so the beta (which is easy to find) was the only thing released. You can read more about it [http://pages.prodigy.net/michaln/history/pr/wlo.html here].<br />
<br />
Additionally, market penetration and OEM interest in OS/2 had dwindled so quickly by this point that Microsoft had decided to do a retail version of OS/2 (pictured to the right) to support its new [[Microsoft SQL Server]] product. Windows NT on the i386 platform included support for 16-bit OS/2 applications, namely for the Microsoft Languages (Fortran/Assembler & C) and SQL Server. Since they all were text mode, they would run un-modified up through Windows 2000.<br />
<br />
=== 32-bit versions ===<br />
All of these versions require an i386 SX or better CPU running on either an IBM AT compatible [[motherboard]], or the IBM PS/2 32-bit machines. <br />
<br />
==== OS/2 2.x ====<br />
<br />
*2.0 LA (LA Internal revision 6.167 91-10-08)<br />
[[Image:IBM OS2 2.0 LA cover.jpg|150px|thumb|right|OS/2 2.0 LA]]<br />
This was the first 32-bit version. It was released after the IBM/Microsoft divorce, and was strictly an IBM release. There was no seamless Windows in this release, and Win-OS/2 only featured Windows 3.0a in standard mode.<br />
<br />
The LA version does not include 'seamless' WIN-OS/2 sessions, and much like OS/2 2.0 GA it does not support Windows's 386 enhanced mode. While it is possible to launch Windows in a Window the display corrupts and it is exceptionally unstable.<br />
<br />
Attempting to use any production GA drivers will result in a [[kernel]] crash.<br />
<br />
*2.0 GA (GA Internal revision 6.307 92-03-01)<br />
[[Image:IBM OS2 2.0 cover.jpg|150px|thumb|right|OS/2 2.0]]<br />
This release included [[Windows 3.0]] for use in Win OS/2. At the time of the release the Presentation Managers graphic drivers were still 16 bit, although a later service pack was released which included 32-bit drivers. It's interesting to note that OS/2's market share was so low at this time, that OS/2 2.0 included the ability to load older 16-bit device drivers as the kernel was still a hybrid 16-bit/32-bit kernel.<br />
<br />
The GUI had radically changed from 1.3 to 2.0 as it now included the Workplace Shell, a full OO GUI. Many people considered WPS to be 'the' killer application at the time, as Windows still had the program manager.<br />
<br />
The new Presentation Manager replacement, Workplace Shell, included a deal with Commodore for the "look and feel" of [[AmigaDOS]], and as part of the deal, Commodore picked up a license for [[REXX]] into its products as first seen by AmigaDOS 2.0 .<br />
<br />
The default syslevel for OS/2 2.0 is XR02000. The last known service pack for OS/2 2.0 brings it up to XR06100. The XR06100 update also installs the OS/2 32-bit Graphics Engine, XR02010.<br />
<br />
*2.1 (06/1993)<br />
This release brought the Win OS/2 functionality up to [[Windows 3.1]]. From the user standpoint it still looked like 2.0 . OS/2 2.1 also included the [[multi-media]] update which would allow for sound effects for almost every conceivable motion. It was very annoying. <br />
<br />
OS/2 2.1 also supported more video cards, more printers, and included support for [[PCMCIA]] and [[APM]], making it acceptable for laptop use.<br />
<br />
The update XR06200 brings OS/2 2.1 up to 2.11 functionality.<br />
<br />
*2.11 (02/1994)<br />
*2.11 SMP (08/1994)<br />
<br />
OS/2 2.11 supported multiple processors, and from a user standpoint it was halfway between 2.11 and Warp. I remember this version being insanely expensive, as it was targeted to the '[[server]]' crowd, IBM had shortsightedly decided end users wouldn't want SMP. While [[Windows NT]] Workstation always supported two physical processors.<br />
<br />
==== OS/2 Warp 3 ====<br />
[[Image:IBM OS2 Warp 3.0 blue spine cover.jpg|150px|thumb|right|OS/2 Warp 3.0 BlueSpine]]<br />
*3.0 (09/1994)<br />
This was the WARP release. At the time this release preempted the [[Windows 95]] release. IBM had done their best to tune OS/2 to run in 4MB of [[Random Access Memory|RAM]] on a 386SX CPU. Warp also included the 'bonus pack' which included SLIP/[[PPP]] [[TCP/IP]], a dialer application and a [[word processor]] & spreadsheet. A simple [[Gopher]] [[client]] & [[Network News Transfer Protocol|NNTP]] client were also included.<br />
<br />
IMHO this is where IBM missed the boat, by making TCP/IP difficult to configure, and by not including [[local area network|LAN]] drivers (that was WARP CONNECT), while [[Windows 95]] & [[Windows_NT#Windows_NT_3.5|NT 3.5]] both included SLIP/PPP *AND* LAN drivers.<br />
<br />
I *THINK* it was this release that included the ability to run [[Win32s]], which was a boon for Netscape & Mosaic.<br />
<br />
*3.01 (1995)<br />
OS/2 Warp with Win-OS/2<br />
<br />
*3.02 (1995)<br />
OS/2 Warp Connect<br />
OS/2 Warp Server <br />
OS/2 Warp Server Advanced<br />
<br />
*3.05 (01/1996)<br />
OS/2 Warp Server Advanced for SMP<br />
<br />
==== OS/2 Warp 4 ====<br />
[[Image:logo-warp.gif|thumb|150px|right|OS/2 Warp Logo]]<br />
*4.0<br />
OS/2 4.0 included both Java and Netscape in this release. Sadly IBM had still not 'gotten it' with regards to TCP/IP and insisted on a 'connect' version of 4.0 that included the LAN drivers. 4.0 also included the ability to install servicepacks online.<br />
<br />
*4.01<br />
Workspace on-Demand 1.0 (WSOD)<br />
Workspace on-Demand 2.0<br />
<br />
*4.5<br />
IBM OS/2 Warp Server for e-business<br />
Fixpak >=13 applied to OS/2 Warp 4 or WSOD<br />
<br />
*4.51<br />
Aurora Convenience Package 1 (ACP1), Merlin Convenience Package 1 (MCP1)<br />
<br />
*4.52<br />
Aurora Convenience Package 2 (ACP2), Merlin Convenience Package 2 (MCP2)<br />
<br />
This was the last IBM release of OS/2.<br />
<br />
== PowerPC port ==<br />
<br />
It's a deep secret that the PowerPC version ended up sucking up so much time, effort and money from IBM's development of OS/2, that it ended up bleeding the group dry, and without a product to ship. IMHO it's a shame, as partnered with the [[PowerPC 615]] CPU it could have revolutionized the industry.. But then back then everyone expected Intel to hit a wall, IBM had the 615 in their pocket which was a PowerPC CPU which was pin compatible with a 486, and could run [[Intel x86|x86]] code (albeit slow..) and then switch to PPC mode. The company [[NexGen]] opened up everyone's eyes that a specialized [[Reduced Instruction Set Computer|RISC]] CPU could in fact run x86 instructions much quicker then a real Intel CPU... This opened the way to the Pentium CPUs and effectively killed the RISC revolution.<br />
<br />
There is a most excellent review to be found [http://www.os2museum.com/wp/?page_id=30 here] that also includes screenshots.<br />
<br />
== Running OS/2 under an Emulator ==<br />
<br />
=== 16 bit versions ===<br />
The latest version of VirtualBOX from SUN is capable of installing & Running the 1.x version of OS/2 provided that they have had a [[Patching OS/2 for fast machines|timing patch]] in place. I have found that the 'best' profile is to use the "Oracle Solaris 10 5/09 and earlier" profile. Be sure to limit the VM to 16MB of RAM, add both a floppy drive, and a serial port, otherwise you'll have difficulty booting.<br />
<br />
Right now the best solution is either [https://pcem-emulator.co.uk/ PCem] or [http://ci.86box.net/ 86Box]. With the appropriate [http://tinyurl.com/rs20170821 ROMS] it's possible to install onto an emulated 286/386 class based machine.<br />
<br />
==== OS/2 1.0 ====<br />
[[Image:OS2 1.0.png|thumb|200px|right|OS/2 1.0 under VirtualBOX]]<br />
*First version from November 1987 - no success.<br />
*There is a later 1987 version that does run, it may be an OS/2 1.1 beta?<br />
It seems the 1.0 IBM kernels rely on 286 triple faults and Virtual Box does not emulate it. However there is an early Microsoft OS/2 1.1 beta that uses the 386 method of switching to protected mode, and will run on modern machines (as long as the speed fix in place.).<br />
<br />
==== OS/2 1.1 ====<br />
[[Image:OS2 1.1.jpg|thumb|200px|right|OS/2 1.1 under Bochs]]<br />
There are some hacks available to run OS/2 1.1 under [[VMWare]], and [[Bochs]]. There are some [[Patching OS/2 for fast machines|binary patches]] you can do to allow old 1.x OS/2 on fast machines. Even without an emulator you'd need to do this on anything in Pentium II speeds.. With the speed stuff in hand, you can now run 1.1 on VirtualBOX as its floppy driver now works with OS/2 to detect speed/density correctly.<br />
<br />
OS/2 1.1c is the first version that supports the 386's method of switching from protected mode to real mode. Prior to level c of OS/2 1.1 the method was a 286 triple fault, which almost all emulators do not fully support, or it may simply be in the IBM versions. I'm still not sure as early versions of OS/2 are hard to track down.<br />
<br />
==== OS/2 1.2 ====<br />
[[Image:OS2 1.2.png|thumb|200px|right|OS/2 1.2 on VirtualBOX]]<br />
With the above hex edits in place, OS/2 1.2 installs somewhat ok. The big 'issue' I found was that the IBM version of OS/2 1.2 does not support PS/2 [[mouse|mice]] on the IBM AT computers. However you can take the PS/2 driver from OS/2 1.3 and use it.<br />
<br />
==== OS/2 1.21 ====<br />
[[Image:OS2 1.21.png|thumb|200px|right|OS/2 1.21 on VirtualBOX]]<br />
Again there is an issue of no included working mice drivers, and poaching the driver from 1.3 works fine.<br />
<br />
==== OS/2 1.3 ====<br />
[[Image:Os213.png|thumb|200px|right|OS/2 1.3 under Virtual PC.]]<br />
The only version of OS/2 1.x that can run under an emulator without any hacks applied. The three problems that you will run into is emulated floppy disks are too quick, and other various timing anomalies that will lead to a COUNTRY.SYS failure.<br />
<br />
The method for install requires you to install OS/2 1.3 on a physical machine, update it, then make a whole disk image of it. I can confirm that OS/2 1.3 runs under [[Virtual PC 2007]] just fine. While it does have some issues with the floppy (it'll throw an error reading the floppy every time you put in a new disk) it will allow you to use the floppy. This makes OS/2 1.3 the easiest to install programs into.<br />
<br />
At the moment, none of the 1.x versions will install under emulation, they all must be imaged from a physical machine.<br />
<br />
* [http://support.microsoft.com/kb/102628/en-us Microsoft OS/2 1.3 HCL]<br />
<br />
=== 32 bit versions ===<br />
<br />
==== OS/2 2.0 ====<br />
OS/2 2.00 ended up being a [[death march]] of a project, taking far too long, straining the joint agreement between Microsoft and IBM to the breaking point and leading to the infamous divorce. As it'd come to light decades later Microsoft really had been trying to bring an 80386 version of OS/2 to market since inception, and version 2.00 was the chance to bring this to fruition in codename 'Cruiser'. Sadly many of these betas did not survive. There are 3 main branches of these early versions, the Microsoft versions where they were directly involved, the IBM transition to where IBM was now responsible for Cruiser, and finally the Workplace Shell versions, where IBM decided to add a new shell to OS/2 to make 2.00 more 'substantial' but also ended up delaying OS/2 2.00 further.<br />
<br />
===== Betas =====<br />
These are the ones I currently have access to, or directly know about:<br />
<br />
====== Microsoft Developer's Relase 1 ======<br />
====== Microsoft Developer's Relase 2 ======<br />
<br />
====== Build 123 ======<br />
[[Image:OS2 2.0 6.123.png|thumb|200px|right|OS/2 2.0 Build 123 on 86Box.]]<br />
The best way to install this is on 86Box/PCem using the AMI 486 clone with a Pentium Overdrive processor and use the [[Microsoft InPort|InPort]] [[Bus mouse]] adapter, along with the generic VGA adapter.<br />
<br />
This build is the 'divorce' edition when IBM started to ship the betas itself, this version uses the OS/2 1.2 Presentation Manager. The MS-DOS is built around MS-DOS 4.0 and includes no DPMI support at all.<br />
You can read more about it [http://www.os2museum.com/wp/os-2-2-0-spring-91-edition/ on OS/2 Museum]. The disks can be downloaded from archive.org [[https://archive.org/details/os2-2.0-6.123 here]].<br />
<br />
To install I used [[86box]] i486 Socket 2, IBM PS/ValuePoint 433DX/Si, with a Pentium OverDrive 63 MHz processor, and a 'type 9' disk setup on IDE. The mouse is set to PS/2 mode.<br />
<br />
The kernel has the following version string:<br />
<br />
Internal revision 6.123, 91/02/04 $<br />
<br />
<br />
The Copyright dialog has this dated for 1990.<br />
<br />
====== Build 605 ======<br />
Not sure why it's build 605 as it is way out of sequence. Perhaps they thought they were close to the end. This is one of the last Presentation Manager based releases. It can be downloaded from [[https://archive.org/details/os2-2.0-6.605 archive.org here]].<br />
<br />
The kernel string reports as:<br />
<br />
Internal revision 6.605, 91/09/11<br />
<br />
The accessories are more fleshed out than 6.123, and to me despite it not supporting DPMI it feels like something that could have shipped in '89.<br />
<br />
605 also introduced the minimal text setup spanning install disk 1-4, with the rest being setup under the Presentation Manager.<br />
<br />
====== Build 177 ======<br />
[[Image:OS2 2.0LA in VirtualBOX.png|thumb|200px|right|OS/2 2.0 LA running under VirtualBOX.]]<br />
<br />
At the moment the only way I've been able to install OS/2 2.0 LA on Virtual PC/VirtualBOX is to 'cheat' and use the install & disk 1 from OS/2 2.0 GA, and replace the following files on disk1, from LA's disk 1:<br />
<br />
*CMD.EXE<br />
*HARDERR.EXE<br />
*SYSINST1.EXE<br />
*SYSINST2.EXE<br />
*FDISK.COM<br />
*SYSLEVEL.OS2<br />
*DISK.NUM<br />
<br />
Then boot from GA's install, then use its disk 1. Then use LA's disk from that point onward, and it'll install.<br />
<br />
====== Build 304 ======<br />
<br />
===== GA =====<br />
[[Image:OS2 2.0 in Qemu.png|thumb|200px|right|OS/2 2.0 running under Qemu.]]<br />
[[Image:Vpc5x os2v20 wps.png|thumb|200px|right|OS/2 2.0 running under Virtual PC 5 for OS/2]]<br />
<br />
I've run OS/2 2.0 & 4.0 under Virtual PC, and [[Qemu]]... I guess it really comes down to if you move disk images around between various hardware platforms. Anything prior to version 3.0 should be run in an ISA emulation mode (-M isa) to let the peripherals work in a more compatible manner... Virtual PC 2007 works fine as well, and includes extensions that allow the guest VM to use drives that are installed on the host PC. I've heard that VMWare has given up the compatibility mode fixes.<br />
<br />
I'm now running OS/2 2.0 under VMWare Player, and it seems to be running OK. I've found one issue with networking, the Set PermaNet Server feature must be set to TRUE, under the LAPS configuration tool.<br />
<br />
*Qemu<br />
*[[Virtual PC 2007]]<br />
<br />
==== OS/2 2.1 ====<br />
<br />
Adds 32-bit Graphics Subsystem. S3 display drivers are usable under Virtual PC.<br />
<br />
* [http://drivers.s3graphics.com/en/download/drivers/legacy/Trio64V_765/eng30316.zip eng30316.zip] S3 drivers<br />
<br />
==== OS/2 Warp 3 ====<br />
*For installation with XDF diskettes, Virtual PC works, however you'll need to use the floppy drivers & xdf driver from OS/2 4.0<br />
*You should first apply the latest fixpak (XRGW040) to use Guest Additions from Virtual PC.<br />
*After this also GRADD device drivers (from Additions, IBM or Scitech SNAP) can be installed.<br />
<br />
==== OS/2 Warp 4 ====<br />
<br />
Fixpak 5 or better 9 should be applied for GRADD.<br />
<br />
==== OS/2 Warp Server for e-business (4.5) ====<br />
<br />
Works with Virtual PC.<br />
<br />
==== OS/2 Convenience Package 1 (4.51) ====<br />
<br />
Works with Virtual PC.<br />
<br />
==== OS/2 Convenience Package 2 (4.52) ====<br />
<br />
Works with Virtual PC and VirtualBox.<br />
<br />
== Popular Applications ==<br />
<br />
=== Autodesk ===<br />
* AutoCad <br />
<br />
=== IBM ===<br />
* IBM DisplayWrite5/2<br />
<br />
=== Informix ===<br />
* Wingz<br />
<br />
=== Lotus ===<br />
* Lotus 1-2-3/G<br />
* Lotus Freelance Graphics<br />
<br />
=== Micrografx ===<br />
* Micrografx Designer 3.0<br />
* Micrografx Draw for OS/2<br />
<br />
=== Microsoft ===<br />
Microsoft did port over a bunch of their languages, along with a few applications, namely:<br />
<br />
* Languages<br />
** Microsoft MASM 6.0<br />
** Microsoft C 5.1, 6.0<br />
** Microsoft COBOL PDS<br />
** Microsoft Basic 6.0<br />
** Microsoft Basic PDS 7.0, 7.1<br />
** [[Microsoft Fortran]]<br />
* Productivity<br />
** Microsoft Word 5.0, 5.5<br />
** Microsoft Word (for Presentation Manager) 1.1<br />
** Microsoft Excel 2.2, 3.0<br />
<br />
All of these products are 16 bit only. While there were two pre-releases of MS OS/2 2.0 that included CL386 & MASM386 none of these are fully out in the wild so I'm not sure if they could produce programs that would run on the IBM OS/2 2.0 GA and beyond.<br />
<br />
=== StarDivision ===<br />
* StarWriter 2.0 for OS/2<br />
* StarOffice 3.0<br />
<br />
=== Watcom ===<br />
* Watcom C / C++<br />
* Watcom Fortran 77<br />
* Watcom SQL<br />
<br />
[[Category: Microsoft Operating Systems]]</div>Torhttps://gunkies.org/w/index.php?title=Talk:A_UNIX%E2%84%A2_Operating_System_for_the_DEC_VAX-11/780_Computer&diff=28422Talk:A UNIX™ Operating System for the DEC VAX-11/780 Computer2023-01-17T07:45:51Z<p>Tor: OCR errors</p>
<hr />
<div>==Revised version==<br />
<br />
So, this is a revised version?<br />
Is there a link to the original?<br />
<br />
*[https://www.bell-labs.com/usr/dmr/www/otherports/32v.pdf A UNIX™Operating System for the DEC VAX-11/780 Computer]<br />
<br />
[[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 01:02, 6 September 2019 (CEST)<br />
<br />
: You mean to the original "internal Bell Labs memo by Reiser and London, dated July 7, 1978"? There's a scan of the original [https://www.bell-labs.com/usr/dmr/www/otherports/32vscan.pdf here]. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 02:13, 6 September 2019 (CEST)<br />
<br />
There are still some errors in the text, presumably leftovers from the original OCR scanning and not all were caught by DMR. E.g. 'paves' instead of 'passes' - definitely an OCR error and not an original typo. Should they (there are others) be left in, or fixed? [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 08:45, 17 January 2023 (CET)</div>Torhttps://gunkies.org/w/index.php?title=Computer_Emulation_Framework&diff=25687Computer Emulation Framework2022-04-26T15:57:07Z<p>Tor: Fixed spelling of "Altair"</p>
<hr />
<div>CEF (the Computer Emulation Framework) is a specification describing an OOP framework for the creation of computer emulators. The basic idea is that each virtual computer component (memory, CPU, I/O devices, terminals, etc) is a stand-alone component with a standard API that allows components to be easily connected together.<br />
<br />
The CEF specification can be found at [http://cef.sourceforge.net sourceforge].<br />
<br />
CEF32 is the reference implementation of CEF for 32-bit Windows. Under this implementation, each CEF component is provided via a DLL that serves up an instance of the object. The CEF32 application manages the loading of these DLLs and initialization of the objects according to a CEF script. Each emulator thus consists of a CEF script which indicates which components to load and how to connect them together. CEF32 also provides several services to reduce the burden of coding new components, including a master assembler, symbol manager, multi-threading management, and a UI. The UI provides an IDE-like interface to CPU, Memory, and other components. It provides for manual connection of components and allows signal monitoring and manipulation. The CEFUtil.DLL provides several additional utilities, such as watchpoint management, key mapping, and character set management.<br />
<br />
The CEF site has links to CEF32, which is public domain source.<br />
<br />
Inherent in the CEF specification for CPUs is optional support for profiling, breakpoints/watchpoints, assembly and disassembly. This overhead, plus the overhead of calls between the components, means that tCEF emulators almost surely run slower than dedicated emulations, but should not be noticeable for older computers. On the other hand, the advantages are that it is often quicker to develop a new emulator since much of the common feature set is already present. For instance, you can use an existing RAM component (with its support for latency, access restrictions, and watchpoints) instead of writing your own. And the UI provides GUI access to that memory, plus the ability to load/store/modify/examine the memory contents.<br />
<br />
CEF32 was written in Delphi, but so long as the components are CORBA compliant, they can be written in any language. Note: CORBA objects are like OLE objects, but without the Object Factory method.<br />
<br />
CEF/CEF32 are updated about once or twice a year, although with component contributors, that could become more often. Currently, CEF32 comes with the following emulators: [[Altair 8800]], [[Cosmac Elf]], [[Intellec8]], and [[PDP-11]]. (I've been concentrating on those systems for which I have personal experience and adequate documentation.) A [[SOL-20]] emulator is also available, but with no ROMs. <br />
<br />
The available CPU components are DEC PDP-11 (up to 11/34), Intel 8008, Intel 8080/8085, Zilog Z80, RCA CDP1802/1806, and Fairchild 3850/3853.<br />
<br />
Available peripheral components are DEC EAE, DEC DL11 and DL11W, IMM860 serial I/O, MITS 88-SIO, DEC VT05/VT52, generic front panel, S100 VDM-1, various keyboards, master clock, and several types of RAM (64Kb, 4Mb, and 64-bit address).<br />
<br />
Available Bus/System Unit components are UNIBUS (with PDP-11 front panel), SOL-20, Altair 8800/IMSI 8080 (with front panel), and Cosmac Elf.<br />
<br />
The next CEF32 release will probably include only bug fixes and a Media Manager. The Media Manager is the next step before I start to release I/O devices, which include DEC RL11 disk drives (in final debugging), Paper tape reader/punches (in final testing), and so forth. Today I was able to create a DOS-11 tape using the Media Manager and copy the files to disk under RSTS/E running on a SimH PDP-11. I only need to fix a couple of minor UI issues and it should be ready for prime time. But I will probably add support for CEF media containers (at least for tapes) and do a little code clean-up before I package it all up for distribution - hopefully sometime this summer.<br />
<br />
[[Category:Emulators]]</div>Torhttps://gunkies.org/w/index.php?title=BASIC&diff=25686BASIC2022-04-26T15:54:24Z<p>Tor: Fixed spelling of "Altair"</p>
<hr />
<div>BASIC is the "Beginner's All-purpose Symbolic Instruction Code" [[programming language]], created by John G. Kemeny and Thomas E. Kurtz at Dartmouth College for pedagogical use, and first introduced in 1964. That original version was an [[interpreter]] which ran under a [[time-sharing]] [[operating system]] on a small [[mainframe]].<br />
<br />
It later became popular on [[minicomputer]]s, in exactly the same usage mode. Since it was very simple for users to understand, many [[microcomputer]]s from the 1970's and 1980's would include BASIC as a feature.<br />
<br />
One of the more popular versions was the Microsoft ROM version, which was used in many machines.<br />
<br />
Microsoft went on to improve BASIC with [[Quick Basic]] which removed line numbers, and made BASIC more procedural, then the next evolution was [[Visual Basic]] a pseudo Object Oriented version for programming the [[Microsoft Windows]] environments. And finally the [[Visual Basic .net]] language which is for the .net framework.<br />
<br />
== Early versions ==<br />
Early versions of Basic were known for needing line numbers, and it allowed direct hardware access via PEEK,POKE keywords. Many of these programs were NOT portable, as the hardware was not standardized, and many vendors added their own extensions to the language.<br />
<br />
<pre><br />
10 PRINT "HELLO WORLD."<br />
</pre><br />
A sample basic program.<br />
<br />
== Procedural Versions ==<br />
With Quick Basic, programs no longer needed line numbers, and the language was able to use the medium & large memory models with later versions. Quick Basic was also included in MS-DOS 5.0 replacing the older GWBasic.<br />
<br />
A sample QuickBasic program:<br />
<br />
<pre><br />
PRINT "HELLO WORLD."<br />
</pre><br />
<br />
== Popular versions ==<br />
Just a quick grouping of popular BASIC programming languages<br />
<br />
*[[HP BASIC]] (1969)<br />
*[[Altair BASIC]] (1978)<br />
<br />
*[[Integer BASIC]] (1977)<br />
*[[Applesoft BASIC]] (1978)<br />
<br />
*[[BBC BASIC]] (1981)<br />
<br />
*[[Microsoft BASIC#IBM Cassette BASIC|Cassette BASIC]] (1981)<br />
*[[Microsoft BASIC#IBM Advanced BASIC|BASICA]] (1981)<br />
*[[Microsoft BASIC#GW-BASIC|GWBASIC]] (1988)<br />
*[[Microsoft BASIC#Quick Basic|Quick BASIC]] (1990)<br />
<br />
{{semi-stub}}<br />
<br />
[[Category:Languages]]</div>Torhttps://gunkies.org/w/index.php?title=BCPL&diff=25358BCPL2022-03-28T09:50:57Z<p>Tor: Two small typo fixes (is is -> it is, and removing an extra 'in' further down).</p>
<hr />
<div>'''BCPL''' is a [[programming language]] that was first developed in the late 1960's. Although little-used nowdays, it is historically important as the [[C programming language]] is derived from it. (C can be crisply, and aptly, described as 'BCPL with types and terser syntax'.)<br />
<br />
Like [[ALGOL]], from which it is descended, it includes modern [[control flow]], including 'block structure'. Unlike Algol, it did not have types; the only type spported was 'word'.<br />
<br />
It was intended by Martin Richards, its designer, mostly for systems programming (such as [[operating system]]s, [[compiler]]s, etc), for which the type limitation was not severe. (The lack of any support for [[floating point]] made it a poor choice for classic computational applications.)<br />
<br />
BCPL was also used in a number of other significant places, including much of the early work on the [[Xerox Alto]].<br />
<br />
==History==<br />
<br />
BCPL is based on Combined Programming Language (CPL), an ambitious collaboration between Cambridge University and the University of London, by a team including Christopher Strachey. BCPL was defined in part as a interim (originally the name apparently stood for 'Bootstrap CPL'; it later became 'Basic CPL') while waiting for CPL to appear (which it never did).<br />
<br />
BCPL retains much of the syntactic richness of CPL, but did so while considerably limiting its complexity - thereby producing a very elegant language.<br />
<br />
It was first implemented on the [[CTSS]] operating system, while Richards was visiting MIT. A number of the early [[UNIX]] personnel from Bell Labs became familiar with it there, while working on [[Multics]]. <br />
<br />
==Portability==<br />
<br />
Portability was a significant goal of BCPL, both in the language itself, and also in the openly available original BCPL compiler, itself written in BCPL; this compiler was ported to a large number of machines.<br />
<br />
The compiler was structured as three phases, the third of which converted a machine-independent intermediate language called OCODE, generated by the second phase, into the target machine's [[object code]].<br />
<br />
Porting the compiler involved writing a new third phase; compiling that with the existing compiler on the host machine, producing a [[cross-compiler]]; and then running the compiler itself through the cross-compiler, producing a native compiler for the target machine.<br />
<br />
==External links==<br />
<br />
* [https://www.bell-labs.com/usr/dmr/www/bcpl.html Martin Richards's BCPL Reference Manual, 1967]<br />
** [https://www.bell-labs.com/usr/dmr/www/bcpl.pdf BCPL Reference Manual]<br />
* [https://www.cl.cam.ac.uk/~mr10/BCPLCTSS.html CTSS BCPL] from MIT.<br />
* [https://github.com/PDP-10/essex-bcpl Essex BCPL] for TOPS-10.<br />
* [https://github.com/PDP-10/tenex-bcpl TENEX BCPL] from BBN - source code only.<br />
<br />
[[Category:Languages]]</div>Torhttps://gunkies.org/w/index.php?title=Talk:List_of_Programmed_Data_Processors&diff=23617Talk:List of Programmed Data Processors2021-05-11T18:28:53Z<p>Tor: PDP: Picture of front label</p>
<hr />
<div>===Meaning of "PDP"===<br />
<br />
Was this changed at some point? I've seen it as "Programmed Data Processor" elsewhere (e.g. https://www.computerhistory.org/pdp-1/introduction/) and I'm looking at a picture of the front of a PDP-1 where a label also uses the same. Edit: The [https://retrocomputingforum.com/uploads/default/original/2X/8/83190734dd3f93e1278ad84b1652675511921709.jpeg picture] [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 08:47, 10 May 2021 (CEST)<br />
<br />
: Oooh, good catch! Thanks very much for catching that!! I just used 'Programmable', going from my memory (which had clearly dropped a few bits over time). That's a lesson to ''always'' check! [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 17:11, 11 May 2021 (CEST)<br />
: Just to confirm, I looked in my (original) PDP-4 manual, and it confirms 'Programmed'. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 18:24, 11 May 2021 (CEST)<br />
<br />
:: There's also the matter of "Programmed '''Digital''' Processor" versus "'''Data'''". Most sources say the latter. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 18:43, 11 May 2021 (CEST)<br />
<br />
:: Another brain bubble on my part; that PDP-4 manual confirms. Sigh. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 20:08, 11 May 2021 (CEST)<br />
<br />
===PDP-2 ½===<br />
<br />
Doug Jones' [https://homepage.cs.uiowa.edu/~jones/pdp8/faqs/ PDP-8 FAQ] says "''There is also a story about the PDP-2 1/2, built by Ed Rawson of the American Science Institute out of surplus modules that were originally used in the prototype PDP-2.''" Searching for clues we find this alt.sys.pdp10 message by Max ben-Aaron dated February 1997:<br />
<br />
<blockquote>In the late 60's & early 70's I worked for a company (Medidata, later Searle Medidata) which started life as a not-for-profit spin-off from Lincoln Lab. (as I have heard), called American Science Institute. The chief engineer, Ed Rawson was a friend of Dec's Olsen and he managed to get hold of the modules used for the prototype PDP-2 which never reached the market. ASI used them to build their own machine (designed, I believe, by Chuck Corderman) which they called "Casino" and was sometimes jocularly referred to as a PDP-2 1/2. Casino was noteworthy for having, very early in trhe game, graphics capabilities. It also had some special terminals which had labels that cannot be repeated on this (family) newsgroup.</blockquote><br />
<br />
Interestingly, this says there '''was''' a PDP-2 prototype, implying it was in fact designed to some degree.<br />
[[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 08:07, 11 May 2021 (CEST)</div>Torhttps://gunkies.org/w/index.php?title=Talk:List_of_Programmed_Data_Processors&diff=23585Talk:List of Programmed Data Processors2021-05-10T06:48:04Z<p>Tor: Created page with "Was this changed at some point? I've seen it as "Programmed Data Processor" elsewhere (e.g. https://www.computerhistory.org/pdp-1/introduction/) and I'm looking at a picture o..."</p>
<hr />
<div>Was this changed at some point? I've seen it as "Programmed Data Processor" elsewhere (e.g. https://www.computerhistory.org/pdp-1/introduction/) and I'm looking at a picture of the front of a PDP-1 where a label also uses the same. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 08:47, 10 May 2021 (CEST)</div>Torhttps://gunkies.org/w/index.php?title=PALM&diff=23506PALM2021-05-05T06:27:15Z<p>Tor: Just fixing an "its" (possessive)</p>
<hr />
<div>"Put All Logic in Microcode."<br />
<br />
IBM processor used in SCAMP and IBM 5100. It was made out of discrete logic on a board, but was referred to as a microprocessor due to its use of [[microcode]].<br />
<br />
{{stub}}</div>Torhttps://gunkies.org/w/index.php?title=Talk:Microprocessor&diff=23342Talk:Microprocessor2021-04-08T14:27:27Z<p>Tor: Re - microcode</p>
<hr />
<div>==Another meaning==<br />
<br />
"Microprocessor" also meant "microcoded processor" in some circles. I have seen it used about the [http://bitsavers.org/pdf/xerox/alto/Alto_Hardware_Manual_Aug76.pdf Alto] and [http://bitsavers.trailing-edge.com/pdf/xerox/maxc/MAXC_8.1_Spec.pdf MAXC] processors, so maybe it was a PARC thing. If those two examples are all I can find, I will not bring it up any more. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 20:56, 7 April 2021 (CEST)<br />
<br />
: Hunh. I have never heard that one; I've always heard the term 'microcoded' for that. I wouldn't mind listing it as 'rare second meaning', if you think it's desirable. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 21:57, 7 April 2021 (CEST)<br />
<br />
:: Thanks. I think I'd like to see at least one occurrence outside Xerox PARC for it to be worthwhile. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 07:39, 8 April 2021 (CEST)<br />
<br />
:: The term "microprocessor" was sometimes used to describe the unit that decoded the microcode in CPUs designed before the arrival of the "microprocessor" as we know it. I had a look on a couple of manuals for the [[NORD-10]] (1973) and the term is occasionally used there (and that's presumably why it's also used in the page linked here on the Wiki, which was originally from Wikipedia in its earliest form). The concept of using microcode for a processor was something I believe the designers of the NORD-10 brought over from the US, and presumably they brought the terminology as well. When I checked the documentation for the later [[ND-100]] (1979), a compatible, slightly larger system with newer technology, the term 'microprocessor' was only used to describe the bit-slice units used, not the microcode decoder. This was of course after the "modern" microprocessor CPU had been introduced. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 09:52, 8 April 2021 (CEST)<br />
<br />
::: Ok, that counts as one more occurrence! [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 10:19, 8 April 2021 (CEST)<br />
<br />
:: You say "brought over from the US"? Did one of the designers of the NORD-10 have some contact with a US project which used microcode? I ask because the concept of microcode is generally attributed to Wilkes (in "The Best Way to Design an Automatic Calculating Machine", 1951, re-printed in ''The Early British Computer Conferences'', MIT Press, 1989); although he used the term "micro-operation" and "micro-programming", the term 'microcode' seems to have been a later (albeit obvious) formulation. Although [[Whirlwind]] used an early form of microcode - without the conditional branching (which seems to have been Wilkes' idea; he mentioned it in the 1951 note). [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 13:27, 8 April 2021 (CEST)<br />
<br />
:: That was only speculation on my part. One of the engineers at ND visited MIT as a student, and brought ideas back - although the most important part was probably about always looking for the latest semiconductor technology). But the first ND, the [[NORD-1]], was not microcoded. The second major revision, the NORD-10, was (but otherwise the architecture was quite similar, and compatible). [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 16:27, 8 April 2021 (CEST)</div>Torhttps://gunkies.org/w/index.php?title=Talk:Microprocessor&diff=23337Talk:Microprocessor2021-04-08T07:52:58Z<p>Tor: "Microprocessor' about microcode execution units</p>
<hr />
<div>==Another meaning==<br />
<br />
"Microprocessor" also meant "microcoded processor" in some circles. I have seen it used about the [http://bitsavers.org/pdf/xerox/alto/Alto_Hardware_Manual_Aug76.pdf Alto] and [http://bitsavers.trailing-edge.com/pdf/xerox/maxc/MAXC_8.1_Spec.pdf MAXC] processors, so maybe it was a PARC thing. If those two examples are all I can find, I will not bring it up any more. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 20:56, 7 April 2021 (CEST)<br />
<br />
: Hunh. I have never heard that one; I've always heard the term 'microcoded' for that. I wouldn't mind listing it as 'rare second meaning', if you think it's desirable. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 21:57, 7 April 2021 (CEST)<br />
<br />
:: Thanks. I think I'd like to see at least one occurrence outside Xerox PART for it to be worthwhile. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 07:39, 8 April 2021 (CEST)<br />
<br />
::: The term "microprocessor" was sometimes used to describe the unit that decoded the microcode in CPUs designed before the arrival of the "microprocessor" as we know it. I had a look on a couple of manuals for the [[NORD-10]] (1973) and the term is occasionally used there (and that's presumably why it's also used in the page linked here on the Wiki, which was originally from Wikipedia in its earliest form). The concept of using microcode for a processor was something I believe the designers of the NORD-10 brought over from the US, and presumably they brought the terminology as well. When I checked the documentation for the later [[ND-100]] (1979), a compatible, slightly larger system with newer technology, the term 'microprocessor' was only used to describe the bit-slice units used, not the microcode decoder. This was of course after the "modern" microprocessor CPU had been introduced. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 09:52, 8 April 2021 (CEST)</div>Torhttps://gunkies.org/w/index.php?title=Zork&diff=22558Zork2020-10-08T12:22:21Z<p>Tor: Source links updated to ifarchive.org (ftp.giga.or.at is gone)</p>
<hr />
<div>[[Image:QuickWin.jpg|200px|thumb|right|Dungeon 2.5.6 on Windows 3.0]]<br />
[[Image:Map of Dungeon.jpg|200px|thumb|right|A map of Dungeon]]<br />
<br />
Zork is one of the most popular, and ported games for mini and personal computers. Zork was written in MIT (Marc Blanc, Joel Berez and others) in the [[MDL]] language. It was VERY popular and was ported to various other languages and systems. The [[FORTRAN]] port by Bob Supnik is perhaps one of the more popular versions.<br />
<br />
There is a little confusion as the the name, Zork started out as the original name, but as time went on, it became "Dungeon". However TSR threatened [[Infocom]] that Dungeon sounded too much like Dungeons & Dragons, so the name was changed back to Zork.<br />
<br />
A better introduction can be found here:<br />
<br />
http://www.csd.uwo.ca/Infocom/dungeon.html<br />
<br />
== Introduction ==<br />
<br />
Zork started the genre that would be better known as interactive fiction. You simply type in what you would want to do, and the story unfolds..<br />
<br />
<pre><br />
# ./zork<br />
You are in an open field west of a big white house with a boarded<br />
front door.<br />
There is a small mailbox here.<br />
>open mailbox<br />
Opening the mailbox reveals:<br />
A leaflet.<br />
>take leaflet<br />
Taken.<br />
>read leaflet<br />
Welcome to Dungeon!<br />
<br />
Dungeon is a game of adventure, danger, and low cunning. In it<br />
you will explore some of the most amazing territory ever seen by mortal<br />
man. Hardened adventurers have run screaming from the terrors contained<br />
within.<br />
<br />
In Dungeon, the intrepid explorer delves into the forgotten secrets<br />
of a lost labyrinth deep in the bowels of the earth, searching for<br />
vast treasures long hidden from prying eyes, treasures guarded by<br />
fearsome monsters and diabolical traps!<br />
<br />
No DECsystem should be without one!<br />
<br />
Dungeon was created at the Programming Technology Division of the MIT<br />
Laboratory for Computer Science by Tim Anderson, Marc Blank, Bruce<br />
Daniels, and Dave Lebling. It was inspired by the Adventure game of<br />
Crowther and Woods, and the Dungeons and Dragons game of Gygax<br />
and Arneson. The original version was written in MDL (alias MUDDLE).<br />
The current version was translated from MDL into FORTRAN IV by<br />
a somewhat paranoid DEC engineer who prefers to remain anonymous.<br />
<br />
On-line information may be obtained with the commands HELP and INFO.<br />
><br />
<br />
</pre><br />
<br />
== Source code ==<br />
<br />
The MDL source code is available from the SIMH software site [http://simh.trailing-edge.com/games/zork-mdl.zip here]. Likewise, Bob's port to Fortran is available [http://simh.trailing-edge.com/games/dungeon.zip here]. The Fortran version was last updated from 1990.<br />
<br />
Various versions can be retrieved from https://www.ifarchive.org/indexes/if-archive/games/source/<br><br />
<br />
{| class="wikitable"<br />
|-<br />
!Source Code<br />
!Description<br />
|-<br />
|[https://www.ifarchive.org/if-archive/games/source/Dungeon_source.sit Dungeon_source.sit]<br />
|C source code for Dungeon (the more or less public domain version of the original MIT Zork) for the Macintosh.<br />
|-<br />
|[https://www.ifarchive.org/if-archive/games/source/dungeon-2.5.6.tar.gz dungeon-2.5.6.tar.gz]<br />
|FORTRAN source code of Dungeon, the more or less public domain version of the original MIT Zork, version 2.5A, 30-Aug-90. This version is Robert M. Supnik's DECUS version 2.5A (18-Jul-80), ported to Linux with f2c.<br />
|-<br />
|[https://www.ifarchive.org/if-archive/games/source/dungeon-3.2A.tar.Z dungeon-3.2A.tar.Z]<br />
|Dungeon version 3.2A, 1-Oct-94; contains all the rooms and puzzles of the original MIT Zork. DEC FORTRAN source code by Robert M. Supnik; see dungn32b.zip for a port to DOS.<br />
|-<br />
|[https://www.ifarchive.org/if-archive/games/source/dungeon-3.2B.patch dungeon-3.2B.patch]<br />
|Source code patch by Robert M. Supnik to upgrade Dungeon version 3.2A to version 3.2B.<br />
|-<br />
|[https://www.ifarchive.org/if-archive/games/source/dungeon-3.2B.unidiff dungeon-3.2B.unidiff]<br />
|Same patch, converted to Larry Wall's 'patch' utility format (unified diff) by David Bristow.<br />
|-<br />
|[https://www.ifarchive.org/if-archive/games/source/dungeon-glk.tar.Z dungeon-glk.tar.Z]<br />
|Dungeon, the more or less public domain version of the original MIT Zork, version 3.2B. Andrew Plotkin ported this version to C |and added the Glk interface.<br />
|-<br />
|[https://www.ifarchive.org/if-archive/games/source/dungn26b-src.zip dungn26b-src.zip]<br />
|FORTRAN source code of Dungeon, the more or less public domain version of the original MIT Zork, version 2.6B, 07-Apr-88. This |version is Robert M. Supnik's DECUS version 2.6A (18-Oct-80), ported to MS-DOS by Kevin Black. (an MS-DOS executable of this |version is in games/pc/dungn26b.zip)<br />
|-<br />
|[https://www.ifarchive.org/if-archive/games/source/dungn27s.zip dungn27s.zip]<br />
|C source code of Dungeon, the more or less public domain version of the original MIT Zork, version 2.7A, 11-Mar-91. (an MS-DOS |executable of this version is in games/pc/dungn27a.zip, an Amiga port is in games/amiga/Dungeon.lzh, and a port to the Acorn |Archimedes is in games/archimedes/dungeon.spk)<br />
|-<br />
|[https://www.ifarchive.org/if-archive/games/source/dungn32b.zip dungn32b.zip]<br />
|Dungeon, the more or less public domain version of the original MIT Zork, version 3.2B, 1-Oct-94. DOS executable for 386+ only and |FORTRAN source code, ported from DEC FORTRAN to GNU G77 FORTRAN by Volker Blasius and David Kinder. The original source code is in |dungeon-32A.tar.Z (file is linked to games/pc/dungn32b.zip)<br />
|}<br />
<br />
== Notable Platforms ==<br />
<br />
=== Zork running on ITS ===<br />
[[Image:Zork on infoton terminal.jpg|150px|thumb|right|Zork on the PDP-10]]<br />
Zork's [[MDL]] source on [[ITS]] for the [[PDP-10]].<br />
<br />
There is now a [http://github.com/PDP-10/its/blob/master/src/mudsys working MDL interpreter] for [[ITS]]. (It's not yet know what it would involve to have it run Zork.)<br />
<br />
There is a MDL interpreter called [http://ifarchive.org/indexes/if-archiveXprogrammingXmdlXinterpretersXconfusion.html Confusion] that is capable or running a slightly patched version of the original MDL Zork code.<br />
<br />
From the US NEWS & DUNGEON REPORT:<br />
<br />
<pre><br />
US NEWS & DUNGEON REPORT<br />
7/22/81 Last G.U.E. Edition<br />
<br />
This version of ZORK is no longer being supported on this or any other<br />
machine. In particular, bugs and feature requests will, most likely, be<br />
read and ignored. There are updated versions of ZORK, including some<br />
altogether new problems, available for PDP-11s and various<br />
microcomputers (TRS-80, APPLE, maybe more later). For information, send<br />
a SASE to:<br />
<br />
Infocom, Inc.<br />
P.O. Box 120, Kendall Station<br />
Cambridge, Ma. 02142<br />
</pre><br />
<br />
The ITS repository on GitHub has 1979 and 1981 version of Zork sources checked in, but they can't yet be compile. There is also a 1978 binary file which can be played.<br />
<br />
=== Zork on RT-11 ===<br />
[[Image:Zork I for the PDP-11.jpg|thumb|150px|right|The cover for Zork I on the PDP-11]]<br />
<br />
I've managed to track back some source & binaries for this [[RT-11]] version. Also the fabled manual was recently found, sold and scanned. It's even autographed. <br />
<br />
[http://www.getlamp.com/pdf/Zork_PDP_11.pdf Zork Manual]<br />
<br />
[http://pdp11.saracom.com/ Saracom link]<br />
<br />
This version can be converted to disk images with [http://www.dbit.com/pub/putr putr], which you can then copy to a larger disk and run it. At the moment this is the oldest known runnable version of Zork.<br />
<pre><br />
RT-11SJ V04.00C<br />
<br />
.D 56=5015<br />
<br />
.TYPE V4USER.TXT<br />
Welcome to RT-11 Version 4. RT-11 V04 provides new hardware support<br />
and some major enhancements over Version 3B.<br />
<br />
Please use the HELP command; it describes the new options in many<br />
of the utilities.<br />
<br />
If you are using a terminal that requires fill characters,<br />
modify location 56 with a Deposit command before proceeding with<br />
system installation. LA36 DECwriter II and VT52 DECscope terminals<br />
do NOT require such modification.<br />
<br />
<br />
.D 56=0<br />
<br />
.RUN DUNGEO<br />
Welcome to Dungeon. This version created 10-AUG-78.<br />
You are in an open field west of a big white house with a boarded<br />
front door.<br />
There is a small mailbox here.<br />
>HISTORY<br />
Revision history:<br />
<br />
10-AUG-78 DECUS version.<br />
14-JUL-78 Bug fixes.<br />
6-JUL-78 Multiple system play test version.<br />
28-JUN-78 Complete play test version.<br />
18-JUN-78 Play test public version.<br />
14-JUN-78 Initial public version.<br />
4-MAR-78 Initial version.<br />
</pre><br />
<br />
There is also some rx50 disk images, here [http://www.pdp11.co.uk/2009/05/17/rt-11-rx50-disk-images/ here] dungeon1,dungeon2 & asc are the disks needed for dungeon. This version however is the source code version, Instructions on compiling it can be found in the tutorial [[Compiling Dungeon on RT-11]]. Extracting the strings I see this for the history portion:<br />
<pre><br />
10-OCT-78 Puzzle Room (V2.1A)<br />
10-SEP-78 Endgame (V2.0A).<br />
10-AUG-78 DECUS version (V1.1B).<br />
14-JUN-78 Public version with parser (V1.1A).<br />
4-MAR-78 Debugging version (V1.0A).<br />
</pre><br />
<br />
I've also managed to track back the source to a newer version, and setup some instructions on how to build it with RT-11 in the tutorial aptly named [[Compiling Dungeon on RT-11]].<br />
<br />
=== Zork on TOPS-20 ===<br />
<br />
I came across this looking at old UseNIX software, and oddly enough in the [http://tuhs.gcu.info/Applications/Shoppa_Tapes/usenix878889.tar.gz 1987 tape], I found this.. I haven't tried to build it or run it, but it does include source, and in the text files I could extract the following:<br />
<br />
<pre><br />
Welcome to Dungeon.<br />
This version created Sep 21, 1981<br />
</pre><br />
<br />
And the history<br />
<br />
<pre><br />
Revision history:<br />
<br />
28-nov-78 Minor cleanups (v2.1a).<br />
10-sep-78 Endgame (V2.0a).<br />
10-AUG-78 DECUS version (V1.1b).<br />
14-JUN-78 Public version with parser (V1.1a).<br />
4-MAR-78 Debugging version (V1.0a).<br />
</pre><br />
<br />
So, while this isn't the oldest one, it's got to be more portable....<br />
<br />
=== Zork on the IBM 370 mainframe ===<br />
<br />
Recently I've found an [http://web.archive.org/web/20050914173504/http://pucc.princeton.edu/~melinda/ archive of Zork] that includes source that runs on CMS for the IBM [[System/370]] mainframe.. I've run it under [[VM/370]].<br />
<br />
<pre><br />
<br />
version<br />
V1. 2C<br />
><br />
history<br />
Revision history:<br />
<br />
V1.0 Appeared fully-formed in someone's VM reader.<br />
><br />
</pre><br />
<br />
It's scored in 500 points, and the dates all seem to point to 1980 and 1981.<br />
<br />
<pre><br />
US NEWS & DUNGEON REPORT<br />
01-MAR-81 Late Dungeon Edition<br />
This is a version of Zork on VM/370<br />
<br />
The problems with it are:<br />
-Lack of an endgame.<br />
-Simple parser (no compound sentences).<br />
-Numerous bugs and spelling errors.<br />
But so what.<br />
<br />
If you encounter problems or find logic, spelling, or usage bugs,<br />
keep them to yourself.<br />
</pre><br />
<br />
=== Zork on the PDP-11 running BSD ===<br />
<br />
This version of Zork contains the following readme, with some information as to the history of Zork on the mini's:<br />
<br />
<pre><br />
This is a patched up RT-11 binary which ran on an LSI-11.<br />
This program was originally distributed on a Purdue mailing and<br />
was full of bugs. Many bugs in that distribution have been fixed.<br />
This is not a pristine, elegent implemention but it works!<br />
<br />
DUNGEON expects following files:<br />
<br />
/usr/chris/dungeon/zork UNIX a.out file for Dungeon root<br />
segment and RT-11 Fortran Runtime<br />
/usr/chris/dungeon/dtext.dat Text file in random access-format<br />
/usr/chris/dungeon/dindex.dat Indicies (probably into dtext.dat)<br />
/usr/chris/dungeon/doverlay Original RT-11 DUNGEO.SAV<br />
(reads overlays from here)<br />
<br />
<br />
If you don't like these pathnames, "dungeon.c" may be modified to<br />
reflect the desired names. Pathnames were originally in "o.s" but<br />
"dungeon.c" was implemented at Purdue as an easier way to change them<br />
than patching binaries. However, we have standardized the d/o.s<br />
interface. It now would be an simple task to put pathnames in o.s<br />
if one so desired.<br />
<br />
Other files of interest:<br />
<br />
dungeon.c C program with date and UID check and exec of dungeon.<br />
<br />
o.s Assembler driver to make dungeon run under UNIX.<br />
Loads overlays, save/restore games, etc. This must<br />
be relocated to 0146000 and stuck on the end of the<br />
dungeon binary file "d". (We don't have sources)<br />
<br />
p1 sh file to patch up a.out file "dung" so interface<br />
between "d" and "o.s" works.<br />
<br />
1.s kludge file to achive . = .+ 0146000<br />
<br />
mkovl sh file to make overlay driver, attach it to "d",<br />
and make a UNIX a.out file by attaching the<br />
proper header.<br />
<br />
--ccw<br />
</pre><br />
<br />
=== Zork on BSD/VAX ===<br />
<br />
This version is infact the same version that runs on the PDP-11 versions of BSD Unix. What is interesting is that this version uses a PDP/11 emulator to run the above binary. It's also worth noting from the VAX's readme:<br />
<br />
<pre><br />
!cmd (the usual shell escape convention)<br />
<br />
> (to save a game)<br />
<br />
< (to restore a game)<br />
</pre><br />
<br />
Using the save/restore commands will cause the program to crash.<br />
<br />
The following is a quick session of the [[4.2 BSD]] version of zork. I think this was the same under all 4.x BSD vax releases.<br />
<pre><br />
myname# zork<br />
You are in an open field west of a big white house with a boarded<br />
front door.<br />
There is a small mailbox here.<br />
>history<br />
Revision history:<br />
<br />
10-SEP-78 Endgame (V2.0a).<br />
10-AUG-78 DECUS version (V1.1b).<br />
14-JUN-78 Public version with parser (V1.1a).<br />
4-MAR-78 Debugging version (V1.0a).<br />
><br />
</pre><br />
<br />
=== Zork on micro's ===<br />
<br />
Zork was also available on various microprocessors, including z80, 6502, 8086.<br />
<br />
From what I can find, here is a list of all the platforms:<br />
<br />
*Amiga<br />
*Amstrad CPC<br />
*Apple II<br />
*Apricot<br />
*Atari 8-bit<br />
*Atari ST<br />
*Commodore 128<br />
*Commodore 64<br />
*Commodore Plus/4<br />
*CP/M<br />
*DECmate<br />
*DEC Rainbow<br />
*Epson QX-10<br />
*Kaypro II<br />
*Macintosh<br />
*NEC APC<br />
*PC<br />
*PDP-9 RT-11<br />
*PDP-10<br />
*PDP-11 RT-11<br />
*Tandy<br />
*TI-99/4A<br />
*TI Professional<br />
*TRS-80 [Model I and III.]<br />
*TRS-80 Color<br />
<br />
=== TRS-80 ===<br />
<br />
[[Image:Zork1 trs80.jpg|thumb|150px|right|Zork 1 for the TRS 80]]<br />
Zork was first available on the [[TRS-80]] requiring 32kb of ram, and a floppy disk drive!<br />
<br />
You can download it from here:<br />
<br />
http://www.classic-computers.org.nz/system-80/disks/zork1_80sssd_jv1.DSK<br />
<br />
----<br />
<br />
=== CP/M (8080/8086) ===<br />
<br />
[[Image:zork1 CPM kit.jpg|thumb|right|150px|Zork 1 for CP/M]]<br />
Zork was made available on the [[i8080]] running [[CP/M]]. You can run this game on [[SIMH]], and also [[emu8080]].<br />
<br />
You can download this version here:<br />
*[http://www.retroarchive.org/cpm/games/zork123_80.zip zork123_80.zip]<br />
<br />
Zork was also available for the [[i8086]] running CP/M, and you can find it here:<br />
*[http://www.retroarchive.org/cpm/games/zork123_86.zip zork123_86.zip]<br />
<br />
Besides the 8080/8086 versions, I'm unaware of any CP/M 68k, or Z8000 version of Zork for CP/M.<br />
<br />
One thing of interest, is that the executable for zork1 for the 8080 is only 8704 bytes!<br />
<br />
----<br />
<br />
=== 6502 (Apple II, Atari, Commodore 64) ===<br />
<br />
[[Image:Commodore OEM Zork 1.jpg|150px|thumb|right|Commodore Zork]]<br />
Of the 6502 based micro's the [[Apple II]], [[Atari 800]], and the [[Commodore 64]] both possesed ports of the interpeter required to run Zork.<br />
<br />
*[http://cbmfunet.retro-server.de/plus4/Games/misc/z/Zork%20I.d64.gz Zork] for the Commodore 64.<br />
*[http://plus4world.powweb.com/software/Zork_I Zork] for the Commodore Plus/4<br />
<br />
Commodore OEM'd Zork onto their computer, and they had unique artwork done.<br />
<br />
=== 8086 ===<br />
<br />
The IBM PC was also able to run Zork, as shipped from Infocom.<br />
<br />
== History of Zork ==<br />
<br />
The [[History of Zork]] can be found here http://www.csd.uwo.ca/Infocom/Articles/NZT/zorkhist.html<br />
<br />
=== The GDT command ===<br />
<br />
The [[FORTRAN]] version of zork was interesting as it included a built in debugger. Depending how old they are, the question would be different.<br />
<br />
For example some of the earlier ones look like this:<br />
<pre><br />
.RUN DUNGEO<br />
Welcome to Dungeon. This version created 6-JUL-78.<br />
You are in an open field west of a big white house with a boarded<br />
front door.<br />
There is a small mailbox here.<br />
>HISTORY<br />
Revision history:<br />
6-JUL-78 Multiple system play test version.<br />
28-JUN-78 Complete play test version.<br />
18-JUN-78 Play test public version.<br />
14-JUN-78 Initial public version.<br />
4-MAR-78 Initial version.<br />
>GDT<br />
A booming voice calls out, "Who summons the right hand of<br />
the translator? State your name, cat, and serial number!"<br />
SUPNIK,BARNEY,70524<br />
At your service!<br />
GDT><br />
</pre><br />
<br />
And as Bob put it on a mailing list:<br />
<pre><br />
Barney was the name of the cat I had when I did the bulk of the porting<br />
work.<br />
<br />
I'm fairly sure that 70524 was my DEC badge number.<br />
<br />
So I guess my cat was working for DEC, indirectly.<br />
<br />
/Bob<br />
</pre><br />
<br />
And more on the nature of GDT:<br />
<pre><br />
GDT dates from a very early version of the game, in fact, before the<br />
game was actually finished. I realized early on that debugging an<br />
interactive program with the traditional PRINT statements was going to<br />
be very cumbersome, and that the interactive debug tools of the day<br />
(1978) had no semantic understanding of the program. GDT was the<br />
answer. It enabled me to track when things went wrong, and to simulate<br />
parts of the game that hadn't been implemented yet.<br />
<br />
Originally, GDT was just a command like any other. Once the game was<br />
released, players quickly realized that it offered a simple way to short<br />
circuit the game and to undo mistakes. Lost something to the thief?<br />
Take it back. Getting killed too often? Turn on immortality mode. So<br />
I implemented a variety of challenges to prevent players from entering<br />
GDT without making the mechanism too difficult for me to remember. I<br />
think the INCANT mechanism might have been the final PDP-11 challenge.<br />
<br />
When I did the VAX version, I abandoned all that and went back to GDT as<br />
universally enabled, under control of a run time flag, GDTFLG. I think<br />
I intended to turn GDTFLG off before releasing the VAX version, so that<br />
it would be impossible to get into GDT without patching the binaries;<br />
but in fact the final VAX sources have GDTFLG=1.<br />
<br />
/Bob<br />
</pre><br />
<br />
== Interrupters ==<br />
<br />
=== InfoTaskForce ===<br />
<br />
Started as a side project back in the mid 1980's as first decompiling the 8080 version of Zork. Afterwards they reimplemented it in [[C (language)|C]], and thus were able to run [[Infocom]] games on any machine that they could compile on. I have been able to track down [http://www.planetemu.net/rom/tandy-radio-shack-trs-80-model-1/infocom-adventure-executor-source-files-1987-infotaskforce-c version 1.0], which included support for various mini-computers & personal computers of 1987. Version 1.0 is only capable of playing [[Infocom Game Versions|version 3]] games. I've been able to get this running on the [[x68000]] platform via emulation. Notes for this port are [http://virtuallyfun.superglobalmegacorp.com/2014/12/15/tracking-down-the-infotaskforce-from-1987/ on my blog]. Also I did a port to the [[cisco]] [[1700]] router platform. Again notes are [http://virtuallyfun.superglobalmegacorp.com/2015/09/27/infotaskforce-running-on-powerpc-dynamips/ on my blog].<br />
<br />
The much later [http://www.ifarchive.org/indexes/if-archiveXinfocomXinterpretersXoldXitf.html Version 4.01] build of InfoTaskForce includes support for more platforms, and more versions of Infocom games. This also served as the base for later intpreters<br />
<br />
=== Pinfocom ===<br />
<br />
Pinfocom is a fork from InfoTaskForce, I'd guess version 3?<br />
<br />
== See Also ==<br />
<br />
* [[Zork hints]]<br />
<br />
[[Category:Games]]</div>Torhttps://gunkies.org/w/index.php?title=AIX&diff=22515AIX2020-08-17T09:38:12Z<p>Tor: Infobox: AIX is at 7.2 (7.2.4 as of now)</p>
<hr />
<div>{{Infobox OS <br />
| image = logo-aix.gif<br />
| caption = Logging into an AIX system<br />
| name = AIX<br />
| creator = [[IBM]]<br />
| current version = 7.2 for RS/6000, PPC, up to POWER9<br />
| year introduced = 1986<br />
| type = Multitasking, multiuser UNIX<br />
| architecture = [[RT/PC]], [[RS/6000]], [[IBM 386]], [[System/370]]<br />
}}<br />
<br />
'''Advanced Interactive eXecutive (AIX)''' is the version of [[UNIX]] developed by IBM, initially for the [[RT PC]], and subsequently for [[RS/6000]], [[PS/2]] and [[System/370]].<br />
<br />
(See '[https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/ Let’s start at the very beginning… 801, ROMP, RT/PC, AIX versions]', which describes the initial 3 versions.)<br />
<br />
== Version 1.x ==<br />
AIX 1 was jointly developed by IBM Austin, IBM Yorktown and Interactive Systems Corporation, based on [[System III]] and [[SVR1]] of [[Unix SYSV]], and released for the [[RT PC]]. It suffered from the expected limitations of a first release. See [http://technologists.com/sauer/SA23-1057_IBM_RT_Personal_Computer_Technology_1986.pdf IBM RT Personal Computer Technology]. Later, October, 1992, AIX version 1.3 ran on the PS/2 and some compatibles.<br />
<br />
== Version 2.x ==<br />
AIX 2 supported the second version of the RT PC hardware and capabilities planned for the first release. See '[http://technologists.com/sauer/Advanced%20Interactive%20Executive%20(AIX)%20Operating%20System%20Overview.pdf Advanced Interactive Executive (AIX) Operating System Overview]'.<br />
<br />
== Version 3.x ==<br />
AIX 3 was designed to overcome limitations of prior versions and support the RS/6000. In addition, companion versions ('[https://archive.org/stream/bitsavers_ibmpcrtaixefinitionOverviewJul88_4100993/GC23-2002-0_AIX_Family_Definition_Overview_Jul88_djvu.txt IBM AIX Family Definition Overview]') were released for PS/2 and System/370, including TCF (Transparent Computing Facility) based on [https://en.wikipedia.org/wiki/LOCUS_(operating_system) LOCUS]. See [http://ieeexplore.ieee.org/document/109275/ AIX 3 Technology]<br />
<br />
== Version 4.x ==<br />
Version 4.x introduced CPU support for the [[PowerPC]] family of processors, and included minor [[CHIRP]]/[[PReP]] compatibility, and at least one [[Apple]] server that ran AIX.<br />
<br />
== Version 5L ==<br />
As it remains now, it's a [[Unix_SYSVr3|SYSVr3]] based OS with many enhancements from [[BSD]] and [[Linux]].<br />
<br />
== Version 6.x ==<br />
More Linux- and [[POSIX]] compatibility. Some POSIX thread library functions that are only stubs in 5.x are actually working in 6.1 (e.g. some locking functions that appear to be available in 5.1 but aren't locking anything!)<br />
<br />
== Version 7.x ==<br />
Adds virtualization support for AIX 5.3 environments. Built-in clustering support.<br />
7.2 adds live kernel updates and some other improvements, including Power9 support.<br />
{{stub}}<br />
<br />
{{Nav Unix}}<br />
<br />
[[Category: Unix-based OS's]]</div>Torhttps://gunkies.org/w/index.php?title=User_talk:ForOldHack&diff=22512User talk:ForOldHack2020-08-13T14:17:11Z<p>Tor: /* Real mode */</p>
<hr />
<div>==Sigs on Talk: pages==<br />
<br />
We generally try and follow the Wikipedia style of signing posts on Talk: pages (so that people reading them will know straight off, without having to look in the history, who made comments, and when). There's even special Wiki syntax to do this easily; just add <nowiki>~~~~</nowiki> to the end of your post, and it will be automagically transformed in this sig, with the user and time. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 13:21, 11 March 2019 (CET)<br />
<br />
: Hmm, something else is going on. '[[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 01:41, 12 March 2019 (CET)' gives me date and time, and <nowiki>~~~~</nowiki> gives me 4 tildies.<br />
<br />
: Oh, now I understand to escape the wiki process and get tildies, use <nowiki>~~~~</nowiki>, but to get the sig use [[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 01:42, 12 March 2019 (CET)<br />
<br />
:: I have not seen such a funny time stamp in 34 years, when we were using uwasa.fi as a mail relay. ( Time is Wasausa, Finland ) [[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 01:45, 12 March 2019 (CET)<br />
<br />
: Please don't forget; I can add the sig manually, but it's easier for you. Thanks! [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 14:52, 22 March 2019 (CET)<br />
<br />
== Note ==<br />
<br />
I would like to print to npib78003.local [[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 05:45, 27 March 2019 (CET)<br />
<br />
== Infobox line captions ==<br />
<br />
The captions in info boxes are specified in the template, as are the argument names; trying to change either in the invocation has no effect.<br />
<br />
If you want to change the 'Year introduced' caption, I'd be OK with that, but just to 'Introduced' I think might be potentially confusing without something to indicate that it's a temporal meaning - e.g. 'Date introduced', or something. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 12:04, 7 April 2019 (CEST)<br />
<br />
:Introduced sounds like marketing speak, I would prefer Release dates, since that would cover both people receiving mag tapes, and downloading comparable source. I got Redhat 5.0 on the day of release, and was able to torrent it, and was able to install it quickly. I went to a user group meeting, and for the cost of $5, got 1) a backup CD, 2) a great Tshirt, 3) a great how-to manual, and 4) some nifty stickers. Needless to say, from that day forward, I saw the lack of value in Microsoft Products. [[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 11:52, 12 April 2019 (CEST)<br />
<br />
:: OK, 'Date released' would work in [[Template:Infobox Software]], [[Template:Infobox OS]], and [[Template:Infobox App]]. I'll go ahead and make that change (although it will only be in the caption, not in the argument name - if I change that, I'd have to change every article that calls those templates).<br />
:: Not sure that to do about [[Template:Infobox Machine]], etc - would 'Date introduced' work there? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 16:20, 16 April 2019 (CEST)<br />
<br />
: Back to the Temporal part, We want a label to indicate its first start of general use, so that a corresponding date tag, could map to what hardware it would run on, i.e. XENIX would have a 1985 release date, and the current hardware was XTs, Turbo XTs, ATs and a few clones, <br />
:Verses ATT SYS V, I guess I see through the eyes of my first C teacher, Barry Kercheval, who liked Sun workstations, because of their OS, and their compiler. The MS-DOS C compilers at the time were hacks, Microsoft C was bad, Aztek C was a bit better, Manx C would make code easy to port from Amiga to PC, and we would get constant diffrences between those and XENIX, and the other boxes we would remote into to look at their compilers. [[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 11:52, 12 April 2019 (CEST)<br />
<br />
:: The way I'd handle OS's where they were released on different dates on different hardware would be to put multiple entries in the 'Date released' box (sort of like the mutiple entries under 'Capacity' [[RL0x disk drive|here]]); one line for each type of hardware. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 16:20, 16 April 2019 (CEST)<br />
<br />
:For RT-11, A list of boxes that it could run on, and the corresponding CPUs and memory cards that would support it, would be useful. i.e. It would not run on this hardware, but certainly would run on the current hardware of the day. [[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 11:52, 12 April 2019 (CEST)<br />
<br />
== External link syntax ==<br />
<br />
We generally like to give the title of our external links, using the syntax <nowiki>'[URL title]'</nowiki>, so instead of:<br />
<br />
[http://ana-3.lcs.mit.edu/~jnc/tech/DECIndicatorPanels.html]<br />
<br />
one sees this:<br />
<br />
[http://ana-3.lcs.mit.edu/~jnc/tech/DECIndicatorPanels.html Digital Equipment Corporation Indicator Panels]<br />
<br />
Much nicer for our readers! The title is formally given inside <title> tags in the HTML of the page, and displayed by the browser (often in the window title bar, but exactly how will depend on the browser and OS).<br />
<br />
PS: You shouldn't stick a sig in additions to ''content'' pages (where it intrudes), you only need to do it on Talk: pages. The reasoning (it dates to a very early stage on Wikipedia, before even I started there) seems to be that if one wants to know where something in a content page comes from, one looks at the History of that page; on Talk: pages (especially if one is reading one later - see for example the discussion at [[Help talk:Introduction to Categories]]), one can easily see who posted a given item directly, without needing to grub around in the history. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:25, 7 April 2019 (CEST)<br />
<br />
:Very sorry, I had forgot, and even forgot to look it up. I am so amazed by the tiny bits I have found, I only used some of those machines a few times, they were apprently very popular because they were so fantastic. <br />
:Ill follow this convention on. [[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 04:57, 8 April 2019 (CET)<br />
<br />
Sure. BTW, [https://en.wikipedia.org/wiki/Wikipedia:SIG here] is the Wikipedia sig policy, which we follow (although we don't follow Wikipedia in most things, in this one we do). [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:12, 9 April 2019 (CEST)<br />
<br />
:When a user sees this: [[http://mercury.lcs.mit.edu/~jnc/humour/sys286.notes System 286 release notes]] it had me choking with laughter. [[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 10:59, 12 April 2019 (CET)<br />
<br />
:: Actually, I didn't write that - someone else at MIT did (don't recall who). The only humour thing I did was the first "Alice's" hack - Alice's PDP-10, maybe? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 14:36, 13 April 2019 (CEST)<br />
<br />
== new user ==<br />
<br />
I don't see a new user. You are the newest user since 8 March 2019.<br />
[[User:Dugo|Dugo]] ([[User talk:Dugo|talk]]) 11:25, 11 April 2019 (CEST)<br />
<br />
Right, you created a new page, [[User talk:ForOldHack/My sandbox]], in the 'User talk' namespace. On this wiki, only [https://en.wikipedia.org/wiki/Wikipedia:Administrators admins] can create new user accounts. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 14:12, 11 April 2019 (CEST)<br />
<br />
Yes, I understand. Page deleted. It does help a lot that you have more Wikipedia experience then I. Thanks. [[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 10:35, 12 April 2019 (CEST)<br />
<br />
: Technically, you 'blanked' the page; it (and its history) are still there. It is actually possible to remove a page totally, but only admins have that ability. Please let me know if you ever want a page (e.g. that one) nuked. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 14:43, 13 April 2019 (CEST)<br />
<br />
:Yes, I have grabbed the information off that page, it can go into the great bit bucket (trash/recycler/ /dev/null)<br />
<br />
:How many euphemisms can we come up with for deleting a file/page? [[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 19:43, 17 April 2019 (CEST)<br />
<br />
:: OK, I have deleted that page. If I misunderstood you, or you change your mind, please let me know and I can restore it. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 16:45, 24 April 2019 (CEST)<br />
<br />
No, I copied the information here. It was an experiment and it did not come out as planned. ( silent back pages ).<br />
Good to know we can bring back pages if we make mistakes. <br />
<br />
But the more I read here about DEC/PDP/VAX, The more I agree with your respect for its elegance. I wish I had had more time with the hardware, and could have worked with it the way I have worked with PCs. <br />
<br />
Got a Mac Performa 630CD running today, just by cleaning it thoroughly, and giving it time to ... coalesce. <br />
<br />
It seems as though this Wiki is coming along with the company of a few devoted fans. Great work.<br />
<br />
== Visualization ==<br />
<br />
This is an exercise to create a text based<br />
visualization tool to categorize memory boards and their resultant available operating systems:<br />
<br />
Chips: Motherboard OS<br />
1x16 DRAM IBM PC V1 DOS 1.0 ( August 1981 ) <br />
DOS 1.1 ( August 1981 )<br />
CPM-86<br />
UCSD-p <br />
<br />
<br />
<br />
<br />
Hm... Chart:<br />
<br />
[https://d1k5w7mbrh6vq5.cloudfront.net/images/cache/01/fd/0f/01fd0fcde84b7edd8bcbb946c2729d01.png?c8c3be714 Dos chart, and early windows, no server.]<br />
<br />
[[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 10:35, 12 April 2019 (CEST)<br />
<br />
<br />
== Kirk CD set! ==<br />
<br />
You can find them on his site [https://www.mckusick.com/csrg/index.html here for sale]. Its a KLUNKY ordering thing, straight out of 1993, but I got my CD/DVD set in Hong Kong no worries!<br />
Totally worth it!<br />
<br />
[[User:Neozeed|neozeed]] ([[User talk:Neozeed|talk]]) 14:03, 25 September 2019 (CEST)<br />
<br />
:Thanks, All I needed was the correct search terms. Found them. <br />
:The two talks I went to were the fixing the C port, and getting VM running on the VAX, both were fantastic lectures<br />
:on UNIX history. It was nice that Kirk was so accessible, vs meeting Bill Joy at USENIX, and him walking off because he was busy.<br />
<br />
Links: ( not on the article, so best of luck finding them.. :)<br />
<br />
:https://archive.org/details/The_CSRG_Archives_CD-ROM_1_August_1998_Marshall_Kirk_McKusick<br />
:https://archive.org/details/The_CSRG_Archives_CD-ROM_2_August_1998_Marshall_Kirk_McKusick<br />
:https://archive.org/details/The_CSRG_Archives_CD-ROM_3_August_1998_Marshall_Kirk_McKusick<br />
:https://archive.org/details/The_CSRG_Archives_CD-ROM_4_August_1998_Marshall_Kirk_McKusick<br />
<br />
<br />
== Tapes ==<br />
<br />
"So I had a source tape of GNU 0.1." Do you still have that tape? Or any other old tapes? [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 14:10, 29 May 2020 (CEST)<br />
<br />
No, I do not have that tape, or any tapes. Lost 10+ years ago. [[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 09:23, 14 June 2020<br />
<br />
== RS-232 ==<br />
<br />
We actually already have an [[EIA RS-232 serial line interface]] article, linked to at the top of the article, which defines 'DCE', 'DTE' etc. Also, higher speeds were more common later, but early interfaces only supported lower speeds - e.g. the [[KL11]] only went up to 2400 baud, but even lower speeds were common; e.g. early [[KD11-B CPU]]s only supported 110 baud. What character coding was used with 5-bit characters? With only 32 available values, there aren't enough for letters and numbers. Etc, etc, etc. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 00:06, 23 June 2020 (CEST)<br />
<br />
:Ah-HA, baud is short for Baudot code, which was a 5 bit character encoding, which was 26 letters, a space and a peroid, and STOP which was carried over to Telegrams, NULL, delete, and one more... FS?!?!?! It was known as Baudot-Murry, and is still used as ITA2 "ITA2 is still used in telecommunications devices for the deaf (TDD), telex, and some amateur radio applications, such as radioteletype ("RTTY"). ITA2 is also used in Enhanced Broadcast Solution (an early 21st century financial protocol specified by Deutsche Börse) to reduce the character encoding footprint"<br />
<br />
:Why would the KD-11-B CPU support a serial link? For a debugging terminal or a logging printer?<br />
:The TTYs that were at Lawrence Hall Of Science, and Willard Jr High school, <br />
<br />
::VT-52s supported 75,110,150, 300,600, 1200,2400,4800, 9600 bps.<br />
:ASR-33s supported 110, 10 cps, but the modems, The LDS I remember had a 75/110 switch.<br />
<br />
== PDP-11/03 ==<br />
Whist grabbing all the DEC documentation off Archive.org, I came across a MiniMINC manual, apparently a dual 8" Floppy PDP-11/03 variant. [https://archive.org/details/TNM_MiniMINC_desktop_computer_-_Digital_Equipment_20180102_0716/page/n5/mode/2up PDP-11/03 variant. Do we have room at the VERY low end of the PDP line for this?<br />
<br />
== Real mode ==<br />
<br />
I've never heard the term 'real mode' applied generally to machines, only to x86 machines. A quick Web search seems to confirm this; see e.g. [https://en.wikipedia.org/wiki/Real_mode Wikipedia]. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 14:47, 2 July 2020 (CEST)<br />
:I would be in favour of renaming the page to something else than "Real mode" - it *is* x86 specific and it should therefore be named accordingly - not sure what's the best title, but e.g. "x86 Real Mode Memory Model" maybe? Or something better. Or a general "x86 Memory Models" with a section "Real Mode"? [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 16:17, 13 August 2020 (CEST)<br />
<br />
"Real mode, also called real address mode, is an operating mode of all x86-compatible CPUs. The mode gets its name from the fact that addresses in real mode always correspond to real locations in memory. Real mode is characterized by a 20-bit segmented memory address space (giving exactly 1 MiB of addressable memory) and unlimited direct software access to all addressable memory, I/O addresses and peripheral hardware. Real mode provides no support for memory protection, multitasking, or code privilege levels. "<br />
<br />
:The word memory, occurs 5 times, and address occurs twice. I/O Does not have addresses, it has numbered ports. <br />
Real mode does not apply to x64 CPUs. <br />
Something else applies: and DEC was one of the first, and all others followed:<br />
Memory partitioning: VMS Partitions the 4GB address space into 4 parts, P0 ~ P4:<br />
<br />
"VAX has a byte-addressable 32-bit virtual address space divided in 512<br />
byte pages. The page is basic unit of mapping and protection. The<br />
address space of a process is divided into P0, P1, P2 regions each 1GB.<br />
P2 is the system address space that is shared between all processes. "<br />
<br />
"The address space is split so that 2 GB of address space is directly accessible to user-mode processes (applications, for example your Opera Browser and the other 2 GB is only accessible to kernel-mode processes (Windows operating system, drivers, etc.)."<br />
<br />
From Raymond Chen: [https://devblogs.microsoft.com/oldnewthing/20200728-00/?p=104012 A look back at memory models in 16-bit MS-DOS]<br />
<br />
<blockquote>Yep. All of these memory models are still possible in protected mode (and still useful on the 286). But when the first OSes written for the 386 showed up, they basically all decided to make all the segments† 4GB large covering the entire (virtual) address space, which is technically the same as the Tiny model. Then when AMD designed x86-64 long mode, they pretty much deleted support for the other models. It doesn’t matter nowadays, because the segments point into the same virtual address space, so the other models really don’t have much benefit except for a very small number of edge cases.<br />
<br />
† In protected mode, segments are regions of memory described by descriptors in the GDT or LDT and identified by selectors loaded into the *S registers; that’s my position on the terminology as backed up by the Intel IA-32 Architecture Software Developer’s Manual, Raymond.</blockquote><br />
<br />
<br />
VAX for the Win. Much more flexible and much more responsive, it can cache VM for both Applications and DATA, as well as for system processes. Which leaves it up to the OS to manage the caching for databases. I wonder what the benchmarks say... <br />
<br />
:That is what I had thought. Keep in mind, I have over 50 edits on the Wikipedia IBM PC page, mostly to reflect IBMs documentation, after all, they made the machine. The same is true of Intel, I quote the manual, because they made the processor.<br />
<br />
[https://courses.cs.washington.edu/courses/csep551/04wi/Messages/paper20/0020.html Review for VAX/VMS Virtual Memory Management paper]<br />
<br />
There are a number of other errors (e.g. it's not ''just'' about addressing, as the intro currently implies), and the new revision is poorly organized. I was going to fix it, but as I started to do that, I realized it would take a lot of time, and I have other things I have to get to this morning, I can't just disrupt my entire day to jump on this. So I' going to have to leave it in its current state for the moment. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:16, 2 July 2020 (CEST)<br />
<br />
:If "it's not ''just'' about addressing." and your citation says "also called real address mode" I fail to see why you cited an article that compelling supports the case.<br />
:If you would prefer only finished articles, I can edit offline, and make my own scratch pad, and citations.<br />
:I am mostly interested in the GDT of the 286 used by XENIX right now. ( The port of GNU C to 286 Xenix is still in limbo, while the Port of GNU C, was done a long time ago, and is kept current. Microsoft crippled 286 Xenix just to sell more software at $500.00 a pop. ( The College paid for 1 copy, and installed it 6 times. Since the computers were not networked, they had no way to complain.<br />
<br />
::No its just just about addressing, and included both register file, and virtual IO, which are now features of the Intel Processor line.<br />
::Some guidance would be good. No need to disrupt your day. Thanks [[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 02:30, 3 July 2020 (CEST)<br />
<br />
:A place for references, but fraught with errors: https://wiki.osdev.org/Virtual_8086_Mode<br />
<br />
:Less errors https://www.singlix.com/trdos/archive/OSDev_Wiki/Protected%20Mode%20Software%20Architecture.pdf<br />
"<br />
<br />
== AIX for PS2 ==<br />
http://ohlandl.ipv7.net/AIX_1-3/AIX_Index.html ; Many broken links but there are mirrors.<br />
<br />
= AIX for PS/2 RS6000 S/370 =<br />
Documentation<br />
http://ps-2.kev009.com/aixps2/boo2pdf/<br />
<br />
RT for MCA<br />
http://ohlandl.ipv7.net/CPU/RT_Accelerator.html<br />
<br />
Where all the boos are:<br />
http://ps-2.kev009.com/tavi/ps2pages/aix.html<br />
<br />
Timeline for OSs<br />
https://en.wikipedia.org/wiki/Timeline_of_operating_systems<br />
<br />
== Real Mode test ASM ==<br />
NVIRT8086.BIN ;The "E" and "F" lines below create the EXE header.<br />
E100 'MZ'<br />
E102 B1 00 02 00 01 00 20 00 11 00<br />
E10C FF FF 0C 00 00 01 00 00 00 00<br />
E116 00 00 3E 00 00 00 00 01 FB 30<br />
E120 CA 72<br />
F122 13D 00<br />
E13E 01<br />
F13F 2FF 00<br />
A300<br />
MOV AX,0003<br />
MOV DS,AX ;next line is MOVE EAX, CR0<br />
DB 0F 20 CG<br />
DB 66<br />
TEST AX,0001 ;with line above & below, TEST EAX, 00000001H<br />
DB 99 99<br />
JZ 325 ;jump to GotReal if protection disabled<br />
NOP<br />
NOP<br />
MOVE DX,0000 ;offset of 'protect w/ no paging' message <br />
DB 66<br />
TEST AX,0000 ;with line above & below, TEST EAX, 00000000H<br />
DB 00 80<br />
JZ 328 ;jump to WriteIt if no paging<br />
NOP<br />
NOP<br />
MOV DX,033 ;offset of 'protect w/ paging' message<br />
JMP 0328 ;jump to WriteIt<br />
NOP<br />
;next line is label GotReal<br />
MOVE DX, 0065 ;offset of 'real mode' message<br />
;next line is label WriteIt<br />
MOV AH,09<br />
INT 21<br />
MOVE AH,4C<br />
INT 21<br />
; Message area; <br />
E 330 'CPU IS RUNNING IN PROTECTED MODE...PAGING DISABLED$'<br />
E 363 'CPU IS RUNNING IN PROTECTED MODE...PAGING ENABLED$'<br />
E 395 'CPU IS RUNNING IN REAL MODE$'<br />
RCX<br />
2B1<br />
W<br />
Q<br />
<br />
You must rename NVIRT8086.BIN to NVIRT8086.EXE and execute from the command line.</div>Torhttps://gunkies.org/w/index.php?title=386BSD&diff=21955386BSD2020-01-20T10:01:59Z<p>Tor: Fixed a possessive "its" typo.</p>
<hr />
<div>[[Image:386BSD logo.jpg|thumb|150px|left|386BSD logo]]<br />
{{Infobox OS <br />
| image = 386bsd.png<br />
| caption = Logging into a 386 BSD system<br />
| name = 386 BSD<br />
| creator = CSRG, University of California, Berkeley<br />
| current version = 1.0 (1993)<br />
| year introduced = 1992<br />
| type = Multitasking, multiuser<br />
| architecture = [[i386]], theoretically portable<br />
}}<br />
<br />
'''386BSD''' (occasionally called '''Jolix''', a tribute to its creators Lynne Jolitz and William Jolitz) was the first time that the [[Net/2]] project was put into a functional release onto commodity hardware, and into the public under the BSD license. As the project eventually stalled, it became the starting point for both [[NetBSD]] & [[FreeBSD]], via the patchkits. While 386 BSD may be of historical significance, it's not up to the challenge of day to day usage, as it hasn't received any updates or patches in over 15 years.<br />
<br />
== Releases ==<br />
There seems to have been four releases of 386 BSD, starting with it being freely available on the Internet, then only available to those who purchased CD-ROMs.<br />
<br />
=== 0.0 ===<br />
This is the first version of 386 BSD that was released, on March 17, 1992. This version doesn't share its disk with MS-DOS or any other OS's, and uses a VAX style disktab/disklabel, making it difficult to install.<br />
<br />
*[[386BSD 0.0]]<br />
<br />
=== 0.1 ===<br />
The 0.1 release was the most popular, as 0.0 proved to be very difficult to install, I'd think because it was more "VAX" like in how it treated the disks, and most people are not familiar with disklabels. There were 2 revisions to 0.1, with the patchkits, that eventually gave birth to both [[NetBSD]] and [[FreeBSD]]. Once patchkit 023 is installed, 386BSD will then run under [[Qemu]] 0.11.x<br />
<br />
*[[386 BSD 0.1]]<br />
*[[386 BSD 0.1 pl23]]<br />
*[[386 BSD 0.1 pl24]]<br />
<br />
*X11 I've found a massive lead [http://cd.textfiles.com/ldr199410/DISC2/X11/XFREE861/ here]. Thanks to shovelware CD makers!<br />
<br />
=== 0.2 ===<br />
An update for ISO-9660 and Rock Ridge extensions. See DrDobbs July 1993.<br />
<br />
=== 1.0 ===<br />
This was the CD-ROM / DrDobbs release<br />
<br />
=== 2.0 ===<br />
In an email with Lynne Jolitz, she has confirmed that there was a 2.0 release. In 2016 it was re-released on [https://github.com/386bsd/386bsd github]<br />
<br />
== Where can I get a copy ==<br />
<br />
At the moment the only known places to get copies are:<br />
<br />
* [http://www.oldlinux.org/Linux.old/distributions/386BSD/ oldlinux.org] 0.0, 0.1 and the two patchkits.<br />
* [ftp://minnie.tuhs.org/BSD/ tuhs.org] 0.0, 0.1 and the two patchkits.<br />
* [ftp://ftp1.am.freebsd.org/pub/ancientBSD/386BSD/cd1.iso freebsd.org] ISO with 0.0, 0.1, the patchkits in various states, a large number of other contributions to 0.0 and 0.1 and a USENET archive of comp.unix.bsd.<br />
<br />
== How do I get this to run?! ==<br />
Right now the only version fully running in emulation is 0.1<br />
The quickest way is to use [https://sourceforge.net/projects/bsd42/files/4BSD%20under%20Windows/v0.4/386BSD-0.1.exe/download 386BSD-0.1exe] which is a ready to run package for Windows users that includes a preconfigured Qemu & disk image.<br />
<br />
==Description==<br />
<br />
The system (releases 0.0 and 0.1) was described in a series of 17 articles in [[Dr. Dobb's Journal]], from January 1991, to July 1992:<br />
<br />
* [https://www.drdobbs.com/open-source/porting-unix-to-the-386-a-practical-appr/184408470 Designing the Software Specification]<br />
* [https://www.drdobbs.com/open-source/porting-unix-to-the-386-three-initial-pc/184408496 Three Initial PC Utilities]<br />
* [https://www.drdobbs.com/cpp/porting-unix-to-the-386-the-standalone-s/184408513 The Standalone System]<br />
* [https://www.drdobbs.com/open-source/porting-unix-to-the-386-language-tools-c/184408529 Language Tools Cross Support]<br />
* [https://www.drdobbs.com/porting-unix-to-the-386-the-initial-root/184408547 The Initial Root Filesystem]<br />
* [https://www.drdobbs.com/porting-unix-to-the-386-research-the-co/184408566 Research & The Commercial Sector]<br />
* [https://www.drdobbs.com/parallel/porting-unix-to-the-386-a-stripped-down/184408583 A Stripped-Down Kernel]<br />
* [https://www.drdobbs.com/open-source/porting-unix-to-the-386-the-basic-kernel/184408600 The Basic Kernel]<br />
* [https://www.drdobbs.com/porting-unix-to-the-386-the-basic-kernel/184408617 Multiprogramming and Multitasking I]<br />
* [https://www.drdobbs.com/porting-unix-to-the-386-the-basic-kernel/184408637 Multiprogramming and Multitasking II]<br />
* [https://www.drdobbs.com/open-source/porting-unix-to-the-386-the-basic-kernel/184408655 Device Autoconfiguration]<br />
* [https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-device-drivers/184408710 Unix Device Drivers I]<br />
* [https://www.drdobbs.com/embedded-systems/porting-unix-to-the-386-device-drivers/184408727 Unix Device Drivers II]<br />
* [https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-device-drivers/184408747 Unix Device Drivers III]<br />
* [https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-missing-pieces-p/184408764 Missing Pieces I]<br />
* [https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-missing-pieces-i/184408782 Missing Pieces II]<br />
* [https://www.drdobbs.com/porting-unix-to-the-386-the-final-step/184408800 The Final Step]<br />
<br />
They're not totally open access; you have to register with DDJ to get all of them. However, there is this:<br />
<br />
* [https://www.386bsd.org/releases 386BSD]<br />
<br />
which appear to be the same as the above.<br />
<br />
==See also==<br />
<br />
* [[BSD/386]]<br />
<br />
{{Nav Unix}}<br />
<br />
[[Category: Unix-based OS's]]</div>Torhttps://gunkies.org/w/index.php?title=Talk:Hercules&diff=21947Talk:Hercules2020-01-16T14:28:30Z<p>Tor: Hercules feasibility for newbies..</p>
<hr />
<div>Maybe it's worth adding a note from the document that Scott just linked to?<br />
NOTE: Hercules is intended ONLY for ADVANCED, HIGHLY EXPERIENCED, TECHNICAL USERS.<br />
It is almost impossible for a new, unfamiliar user to use it to accomplish anything.<br />
It is NOT a Point-And-Click system or anything close to it.<br />
10-20 years of technical experience with IBM Mainframes is required.<br />
[[User:Tor|Tor]] ([[User talk:Tor|talk]]) 15:28, 16 January 2020 (CET)</div>Torhttps://gunkies.org/w/index.php?title=Talk:DDT&diff=21703Talk:DDT2019-10-07T11:36:09Z<p>Tor: CP/M DDT</p>
<hr />
<div>How should we best separate this DDT from CP/M DDT (Dynamic Debugging Tool)? [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 13:36, 7 October 2019 (CEST)</div>Torhttps://gunkies.org/w/index.php?title=BASIC&diff=21131BASIC2019-06-11T09:20:24Z<p>Tor: Typo fix: laguages -> languages</p>
<hr />
<div>BASIC is the "Beginner's All-purpose Symbolic Instruction Code" [[programming language]], created by John G. Kemeny and Thomas E. Kurtz at Dartmouth College for pedagogical use, and first introduced in 1964. That original version was an [[interpreter]] which ran under a [[time-sharing]] [[operating system]] on a small [[mainframe]].<br />
<br />
It later became popular on [[minicomputer]]s, in exactly the same usage mode. Since it was very simple for users to understand, many [[microcomputer]]s from the 1970's and 1980's would include BASIC as a feature.<br />
<br />
One of the more popular versions was the Microsoft ROM version, which was used in many machines.<br />
<br />
Microsoft went on to improve BASIC with [[Quick Basic]] which removed line numbers, and made BASIC more procedural, then the next evolution was [[Visual Basic]] a pseudo Object Oriented version for programming the [[Microsoft Windows]] environments. And finally the [[Visual Basic .net]] language which is for the .net framework.<br />
<br />
== Early versions ==<br />
Early versions of Basic were known for needing line numbers, and it allowed direct hardware access via PEEK,POKE keywords. Many of these programs were NOT portable, as the hardware was not standardized, and many vendors added their own extensions to the language.<br />
<br />
<pre><br />
10 PRINT "HELLO WORLD."<br />
</pre><br />
A sample basic program.<br />
<br />
== Procedural Versions ==<br />
With Quick Basic, programs no longer needed line numbers, and the language was able to use the medium & large memory models with later versions. Quick Basic was also included in MS-DOS 5.0 replacing the older GWBasic.<br />
<br />
A sample QuickBasic program:<br />
<br />
<pre><br />
PRINT "HELLO WORLD."<br />
</pre><br />
<br />
== Popular versions ==<br />
Just a quick grouping of popular BASIC programming languages<br />
<br />
*[[HP BASIC]] (1969)<br />
*[[Altar BASIC]] (1978)<br />
<br />
*[[Integer BASIC]] (1977)<br />
*[[Applesoft BASIC]] (1978)<br />
<br />
*[[BBC BASIC]] (1981)<br />
<br />
*[[Microsoft BASIC#IBM Cassette BASIC|Cassette BASIC]] (1981)<br />
*[[Microsoft BASIC#IBM Advanced BASIC|BASICA]] (1981)<br />
*[[Microsoft BASIC#GW-BASIC|GWBASIC]] (1988)<br />
*[[Microsoft BASIC#Quick Basic|Quick BASIC]] (1990)<br />
<br />
{{semi-stub}}<br />
<br />
[[Category:Languages]]</div>Torhttps://gunkies.org/w/index.php?title=HP_BASIC&diff=21130HP BASIC2019-06-11T09:14:59Z<p>Tor: One remaining typo fixed</p>
<hr />
<div>'''HP Time-Shared BASIC''' ('''HP TSB''') is a [[BASIC]] [[programming language]] [[interpreter]] for [[Hewlett-Packard]]'s [[HP 2100]] line of [[minicomputer]]s. The system implements a dialect of the BASIC language and a rudimentary user account and program library system.<br />
<br />
The software was also known by its versioned name, tied to the hardware version on which it ran, such as '''HP 2000C Time-Shared BASIC''' and the operating system came in different varieties&nbsp;— 2000A, 2000B, 2000C, High-Speed 2000C, 2000E, 2000F, and 2000/Access.<br />
<br />
Except for the 2000A and 2000E systems, the system is implemented using a dual-[[central processing unit|processor]] [[architecture]]. One fully configured HP 2100-series processor is used for execution of most of the system code and all of the user code, while a second, smaller HP 2100-series processor is used to handle the [[EIA RS-232 serial line interface|RS-232]] [[serial line]]s through which the [[time-sharing]] users connected. Depending on the hardware configuration, the system supports up to 16 or up to 32 simultaneous remote users.<br />
<br />
The usual terminal for a TSB system was a [[Teletype]] Model 33 ASR and connected directly to the I/O processor or through a [[modem]] or [[acoustic coupler]]. Account names are a combination of one alphabetic character, followed by three decimal digits, ''e.g.'', B001. Privileged accounts started with the letter "A" and had some additional command and program storage capabilities, such as the ability to use the Storage Drum, or to prevent a program from being listed ( Protected ). The [[superuser]] account is A000. This scheme allows up to 24,999 user accounts: The accounts ending in 00 were group accounts, and the Z999 account held the login program. <br />
<br />
== HP TSB accounts ==<br />
<br />
The System Master (A000) and all Group Masters (A100~Z900) are privileged users. <br />
<br />
The System Master (A000) can save programs and files into the system Library.<br />
<br />
Semi-privileged Users: User accounts beginning with the character A, specifically A000 through A999, can alter files sumultaneously. <br />
<br />
Protected programs cannot be saved, punched or listed.<br />
<br />
Semi-privileged Users with accounts ending with 00 can save programs and files into the group libraries.<br />
<br />
{{Wp-orig}}</div>Torhttps://gunkies.org/w/index.php?title=Talk:Unix_SYSVr3&diff=21016Talk:Unix SYSVr32019-04-16T11:43:08Z<p>Tor: Capitalization..</p>
<hr />
<div>== Capitalization problems ==<br />
<br />
[[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Capital_letters Wikipedia Manual of Style: Capitalization ]]<br />
<br />
I recognize on this page the need to make it a bit less <i>shouty.</i><br />
<br />
For this page/wiki I would like to only capitolize acronyms: i.e. <br />
<br />
Unix is not an acronym but a trademark.<br />
Sys V is a version, and by convention is represented by a roman numeral,<br />
and AT&T must remain AT&T.<br />
<br />
Editing will commence. [[User:ForOldHack|ForOldHack]] ([[User talk:ForOldHack|talk]]) 11:05, 16 April 2019 (CEST)<br />
:While in general I agree about Wikipedia's ideas about readability, my personal opinion is that the correct way to capitalize retro names is the way their various vendors did back then. E.g. the NORD-1 computer was named that way, so I grumbled a lot when Wikipedia changed that to Nord-1. SYSVr3 was written SYSV3r when new, wasn't it? One reason I prefer other wikis than Wikipedia these days is that we're not so strict about their rules.. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 13:43, 16 April 2019 (CEST)</div>Torhttps://gunkies.org/w/index.php?title=Talk:IBM_5150&diff=20923Talk:IBM 51502019-03-28T13:43:58Z<p>Tor: Roalty for IBM clones? Ref?</p>
<hr />
<div><h3>Roalty fee?</h3><br />
"IBM would license them for a 5% royalty fee,".. is there a reference for this? I can't remember seeing this anywhere else. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 14:43, 28 March 2019 (CET)</div>Torhttps://gunkies.org/w/index.php?title=BASIC&diff=20884BASIC2019-03-19T07:57:42Z<p>Tor: Spellfix: Casette -> Cassette</p>
<hr />
<div>BASIC is the "Beginner's All-purpose Symbolic Instruction Code" [[programming language]], created by John G. Kemeny and Thomas E. Kurtz at Dartmouth College for pedagogical use, and first introduced in 1964. That original version was an [[interpreter]] which ran under a [[time-sharing]] [[operating system]] on a small [[mainframe]].<br />
<br />
It later became popular on [[minicomputer]]s, in exactly the same usage mode. Since it was very simple for users to understand, many [[microcomputer]]s from the 1970's and 1980's would include BASIC as a feature.<br />
<br />
One of the more popular versions was the Microsoft ROM version, which was used in many machines.<br />
<br />
Microsoft went on to improve BASIC with [[Quick Basic]] which removed line numbers, and made BASIC more procedural, then the next evolution was [[Visual Basic]] a pseudo Object Oriented version for programming the [[Microsoft Windows]] environments. And finally the [[Visual Basic .net]] language which is for the .net framework.<br />
<br />
== Early versions ==<br />
Early versions of Basic were known for needing line numbers, and it allowed direct hardware access via PEEK,POKE keywords. Many of these programs were NOT portable, as the hardware was not standardized, and many vendors added their own extensions to the language.<br />
<br />
<pre><br />
10 PRINT "HELLO WORLD."<br />
</pre><br />
A sample basic program.<br />
<br />
== Procedural Versions ==<br />
With Quick Basic, programs no longer needed line numbers, and the language was able to use the medium & large memory models with later versions. Quick Basic was also included in MS-DOS 5.0 replacing the older GWBasic.<br />
<br />
<pre><br />
PRINT "HELLO WORLD."<br />
</pre><br />
A sample QuickBasic program.<br />
<br />
== Popular versions ==<br />
Just a quick grouping of popular basics<br />
<br />
*[[HP BASIC]] (1969)<br />
*[[Altar BASIC]] (1978)<br />
<br />
*[[Integer BASIC]] (1977)<br />
*[[Applesoft BASIC]] (1978)<br />
<br />
*[[BBC BASIC]] (1981)<br />
<br />
*[[Cassette BASIC]] (1981)<br />
*[[Basica]] (1981)<br />
*[[GWBasic]] (1988)<br />
*[[Quick_Basic]] (1990)<br />
<br />
{{semi-stub}}<br />
<br />
[[Category:Languages]]</div>Torhttps://gunkies.org/w/index.php?title=Multics&diff=20865Multics2019-03-18T07:58:27Z<p>Tor: Typo fix: to -> too</p>
<hr />
<div>{{Infobox OS<br />
| name = Multics<br />
| image = MITMultics.jpg<br />
| caption = H6180 Multics at MIT <br />
| creator = MIT, with assistance from GE and Bell Labs<br />
| current version = MR 12.6f<br />
| year introduced = December, 1967 (first boot); July, 1969 (experimental use)<br />
| year discontinued = June, 1985 (discontinuation decision); October, 2000 (last system shut down)<br />
| type = Information utility<br />
| architecture = [[GE-645]] initially, various [[Honeywell 6000 series|Honeywell 6000]] models later<br />
}}<br />
<br />
Multics (''Multi''plexed ''I''nformation and ''C''omputing ''S''ervice) was an early [[time-sharing]] [[operating system]] for which has influenced every operating system created since; especially via [[Unix]] (the name of which is a play on 'Multics'), which was created by Bell Labs personnel who had worked on Multics, after Bell Labs pulled out of the Multics project.<br />
<br />
Multics was intended as an ''information utility''; i.e. a service to which those who wanted information processing would connect, much as people connect to the electric grid for power.<br />
<br />
This dictated a number of Multics' features, including the modular structure of the hardware (with multiple [[CPU]]s and [[main memory]] banks, fully interconnected, and with the ability to take individual units out of service for maintenance, or to simply add additional units as demand increased over time); extremely robust security (so that individual users in a facility open to all comers would be protected from each other), etc.<br />
<br />
==Technical aspects==<br />
<br />
In addition to the modular hardware, and robust security, Multics had a number of other major technical features, some commonplace now (and some still not too common - alas), but major advances when it was first designed (in 1967). They include:<br />
<br />
* A [[single-level store]]<br />
* [[Dynamic linking]] for libraries, etc<br />
* A [[command processor]] implemented entirely in user code<br />
* A hierachical [[file system]]<br />
* Separate [[access control list]]s for each 'file'<br />
<br />
The single-level store architecture of Multics was particularly significant: it discarded the clear distinction between [[file]]s (called ''segments'' in Multics) and [[process]] memory. The memory of a process consisted solely of segments that were mapped into its [[address space]]. To read or write to them, the process simply used normal [[instruction]]s; the operating system took care of making sure that all the modifications were saved to [[secondary storage]] ([[disk]]).<br />
<br />
In modern UNIX terminology, it was as if every file were 'mmap()'ed; however, in Multics there was no concept of process memory, separate from the memory used to hold mapped-in files: all memory in the system was part of some segment, which appeared in the file system; this included the temporary scratch memory of the process, such as its [[kernel]] [[stack]], etc.<br />
<br />
Multics also implemented [[virtual memory]], which was very new at that time (only a handful of other systems implemented it at that point); but this was not a new idea with Multics.<br />
<br />
The segmentation and paging in Multics are often discussed together, but it is important to realize that they were not fundamentally connected; one could theoretically have an SLS system which did not page. Paging was added as well for practical reasons.<br />
<br />
Multics also made popular the now-common technique of having separate per-process stacks in the kernel; this was apparently first seen in the [[Burroughs B5000]], but was not well known.<br />
<br />
This is an important kernel structuring advance since it greatly simplifies code; if a process discovers, somewhere deep inside a [[subroutine]] [[call stack]] that it needs to wait for an event, it can simply do so right there, instead of having to [[unwind]] its way out, and then return later when the waited-for event has happened.<br />
<br />
The entire system was written almost entirely in higher-level language ([[PL/I]]) - which was quite rare at the time; the Burroughs B5000 had an OS written in [[ALGOL]], but this was the only previous system to do so.<br />
<br />
===Hardware===<br />
<br />
Multics ran only on special hardware, which provided hardware support for its single-level store [[architecture]].<br />
<br />
It initially ran on the [[GE 645]], a modified version of the [[GE 635]]. After GE was bought by Honeywell, a number of models of the [[Honeywell 6000 series]] systems were produced to run Multics on.<br />
<br />
== Multics today ==<br />
<br />
Multics is dead. There are no systems running it today (the last one was [http://slashdot.org/articles/00/11/13/066228.shtml shut down in 2000]).<br />
<br />
There is however now a working [[SIMH]]-based emulator for the Multics DPS-8/M hardware, and with most of the source code still extant, it is now possible to experience the Multics computing environment.<br />
<br />
=== Reviving Multics? ===<br />
<br />
Porting Multics to alternative hardware would be a worse-than-Herculean task: the design is not well-suited for porting. It used specialized hardware built especially for it, which had many features which do not have exact analogues on any other platform today. In addition, the word length of the machine (18-bit half-words) is explicitly included in many variable declarations in every source module.<br />
<br />
Even if that could be overcome, Multics was written in PL/I. There are no PL/I compilers available other than commercial ones aimed at large enterprise systems, and which aren't getting any cheaper. The lack of a free Unixland PL/I compiler inhibits any porting task.<br />
<br />
==External links==<br />
<br />
* [http://www.multicians.org Multicians -- a great source of info]<br />
* [http://ringzero.wikidot.com/ Multics reborn wiki]<br />
* [http://swenson.org/multics_wiki/index.php?title=Main_Page Running Multics wiki]<br />
* [https://sourceforge.net/projects/dps8m/ DPS-8/M emulator]<br />
* [http://sourceforge.net/projects/h6180/ H6180 emulator (abandoned)]<br />
* [https://www.youtube.com/watch?v=jni7wk7bjxA Multics booting] - A video of a H6180 CPU front panel hooked up to a SIMH H6180 emulation booting Multics<br />
<br />
[[Category: Operating Systems]]</div>Torhttps://gunkies.org/w/index.php?title=Talk:MUD&diff=20488Talk:MUD2019-01-10T14:24:43Z<p>Tor: MUD game (disambiguity needed?)</p>
<hr />
<div>Also Multi-User Dungeon.<br />
:Yep. That's what I was thinking about when I saw MUD (even I, and I was never a gamer). I didn't know about the DEC reference. So a disambiguity page is maybe what we need. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 15:24, 10 January 2019 (CET)</div>Torhttps://gunkies.org/w/index.php?title=Help_talk:Categories&diff=20404Help talk:Categories2018-12-28T09:04:35Z<p>Tor: /* Duplicate VAX categories */</p>
<hr />
<div>==Peripherals/Devices==<br />
<br />
Hi, I'm getting set to create categories for PDP-10 and PDP-11 peripherals/devices (I've been doing a lot of organization on the CPU/system/etc end of things, and have that in pretty good shape now). Which word would be better to use, if you have an opinion - 'peripherals' or 'devices'? We current do already have a [[:Category:Peripherals]], so maybe go with that? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 16:05, 19 February 2018 (CET)<br />
<br />
: I tend to go with 'peripherals' in this case. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
OK; I'll get started on that. And also, I think we should have a category for all DEC stuff - just plain 'DEC', or 'Digital Equipment Corporation'?<br />
<br />
: DEC is consistent with the other labels. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: I'll have to ponder the DEC category name. It feels a bit 'thin', just plain 'DEC'. I don't mind the acronym 'DEC' as ''part'' of the name of sub-categories (it prevents them getting ridiculously long); but for the main category, it feels too informal. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 20:28, 19 February 2018 (CET)<br />
<br />
==Other cats==<br />
<br />
BTW, I added some thoughts about cats to [[Help:Introduction to Categories#Current organization]] - does that seem like a good system? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 19:44, 19 February 2018 (CET)<br />
<br />
: There's one problem with the taxonomy. Not all PDP-10 (or 11 or 8) operating systems are DEC operating system. At least not in the sense "operating systems made by DEC". [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: I'm happy to subdivide it (them, actually) into two other categories; any snappy ideas for the name(s)? I suppose we could have 'DEC Operating Systems' and 'Non-DEC Operating Systems'; each of which is further divided into, e.g., 'DEC PDP-11 Operating Systems' and 'Non-DEC PDP-11 Operating Systems'. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 20:28, 19 February 2018 (CET)<br />
<br />
::: That'll potentially be a lot of category pages to create! Can't a page be in both the DEC Operating Systems category, and the PDP-10 Operating Systems category? [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: Sorry, I'm not sure I'm seeing your concept; a concrete example would help. What pages (and sub-categories) would go in 'DEC Operating Systems' category, and what in the 'PDP-10 Operating Systems'? ITS would clearly be in the latter, but would it be in any others? What super-category would the 'PDP-10 Operating Systems' category be in? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]])<br />
<br />
::: TOPS-10 would be in both 'DEC OSes' and 'PDP-10 OSes'. OS/8 would be in both 'DEC OSes' and 'PDP-8 OSes'. ITS would be in just 'PDP-10 OSes'. Unix V7 would be in just 'PDP-11 OSes'. 'DEC OSes', 'PDP-8 OSes', 'PDP-10 OSes', and 'PDP-11 OSes' would all be in 'Operating Systems'.<br />
::: This way, there would be N+M categories (for N manufacturers and M architectures), rather than NxM. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: Ah, got it.<br />
:: The only potential downside to that approach is that there's no easy way to find non-DEC OS's, other than going through all the per-machine OS categories - for which having a 'OS's for DEC machines' super-cat would be mildly helpful, as opposed to just putting them in 'OS's'.<br />
:: Ah, how about a single 'non-DEC OS's for DEC machines' category? (Although it would need a snappier name than that - can't come up with one quickly.) So TOPS-10 would be in 'DEC OS's' and 'PDP-10 OS's', Unix V6 would be in 'non-DEC OS's' and 'PDP-11 OS's', etc.<br />
:: That's only one more category, and it would help find the non-DEC OS's easily; and no PDP OS article would have more than two category tags. (I'm going to put off for now the issue of OS's like MUMPS, which started out as a private venture, and which eventully wound up as a DEC product! :-)<br />
:: BTW, actually my orginal proposal was not N*M; it was Sum(2*Mi), instead of Sum(Mi), where Mi is the number of architecture for manufacturer i, out of N. But still, you're right, it would have been a lot! Twice as many as the other way... [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:04, 20 February 2018 (CET)<br />
<br />
: Now that I see the 'Non-DEC Operating Systems' Category, it does look quite strange.. on the surface of it it would cover everything that's not DEC or for DEC, i.e. most operating systems (and then a visitor would wonder why it's named that way, too.) But then it's definitely for DEC, just not made by DEC. It gets a bit confusing. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 09:20, 23 February 2018 (CET)<br />
<br />
:: I agree, actually! Despite thinking about it for several days, I just couldn't come up with a short, snappy name that, on its face, described what the category was about! 'Non-DEC Operating Systems for DEC Machines' is a bit ponderous! If anyone can come up with a better one, I'd be happy to change it (which is why I put off going around tagging articles). I asked Lars if he had a suggestion...<br />
:: In the interim, that's why I put the description in the Help: page (and the cat header), to warn people it's not what the name, ''strictly''-speaking, implies. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 14:06, 23 February 2018 (CET)<br />
<br />
:: So Lars mentioned 'external', and synonyms for it... independent, outside, foreign, non-proprietary.<br />
:: Of these, 'Independent DEC OSs' wouldn't be ''too'' bad - I'd be OK with switching to that. 'External DEC OSs' initially ''sounds'' like it might be the best, but it could be misunderstood as still being a product of DEC, for use outside the company (and the same applies to the others, too).<br />
:: Although it still doesn't describe ''exactly'' what the category is, 'Independent' does 'on its face' clearly indicate there's something unusual (i.e. it doesn't ''clearly'' give a wrong impression), and gives a strong hint of what it really is.<br />
:: The problem is that the shortest facially accurate description (i.e. without any external amplification) is 'non-DEC OSs for DEC machines', which is long and clunky. Anything shorter is going to have some lack of clarity. E.g. 'Independent DEC OSs' - what ''exactly'' is that - if you don't already know?<br />
:: Anyway, whatever solution we come up with for DEC, we can use for any companies that need it - e.g. 'Independent IBM OSs'. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:00, 23 February 2018 (CET)<br />
<br />
: And.... crickets. Oh, well! [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 13:57, 27 February 2018 (CET)<br />
<br />
:: No use overthinking this. Full steam ahead! [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
::: OK. Hey, I'm from MIT - according to some people, over-thinking things is what we do! :-) [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 21:17, 1 March 2018 (CET)<br />
<br />
== Terminal categories ==<br />
<br />
So I recently split up [[:Category:Terminals]] into [[:Category:Printing Terminals]] and [[:Category:Video Terminals]]. There's also a [[:Category:DEC Terminals]]. So, currently all the DEC terminals ([[VT52]], etc) are tagged with two categories: 'DEC Terminals' and 'Printing/Video Terminals'. Is this the way people want to go, or should we create 'Printing' and 'Video' sub-categories of 'DEC Terminals'? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 03:55, 8 June 2018 (CEST)<br />
<br />
== Unix OS cat? ==<br />
<br />
I've noticed that there are a ''lot'' of systems in the top-level category [[:Category: Operating Systems]]; the majority are Unix derivations of some type or other. I propose to move them all to a new 'Unix clones' category, so only truly one-off systems like [[CTSS]], etc are in the top-level cat. Additional query: what should the cat be called - 'Unix-based Operating Systems', or what? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 18:00, 10 June 2018 (CEST)<br />
<br />
:Sounds ok to me. Would that be a sub-category in Operating Systems then, easily found at the top of the page? As for the name - I think 'Unix-based Operating Systems' is fine. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 15:28, 17 June 2018 (CEST)<br />
<br />
: oK, good, I'll make it happen. Yes, it will be a sub-cat of [[:Category: Operating Systems]]. I think I'll use [[:Category: Unix-based OS's]], though, to keep it from being ''too'' clunky. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 17:55, 17 June 2018 (CEST)<br />
: Ah, in retrospect I should have used the full 'Unix-based Operating Systems'; now most of the sub-cats in [[:Category: Operating Systems]] use the full 'Operating Systems' in the name, so the Unix ones are now somewhat 'odd cats out'! Sigh! [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 02:26, 18 June 2018 (CEST)<br />
<br />
Another idea: I currently have two cats (the first below, plus 'everything else'),but maybe we should have three categories:<br />
* Unix versions done by Bell/ATT<br />
* Unix versions which are external descendants (Ultrix, Sun, etc)<br />
* Unix 'clones' (Linux, Coherent, etc)<br />
Comments? (And names, if the idea is desirable)? I wonder into which do the later BSD's fit - IIRC, they eventually got rid of ''all'' the Bell code? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 17:13, 18 June 2018 (CEST)<br />
<br />
== Category work ==<br />
<br />
After I created a new article on an obscure video terminal board, it was pointed out to me that since no other article linked to it, Web indexers wouldn't find it. I realized that if every article is in a category which is included in some way in one of the main categories, which are linked to on the [[Main Page]], that would do it. So I'm going to try and improve categories and cat tags, make sure all articles have the desired tags, etc. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 00:40, 11 June 2018 (CEST)<br />
<br />
=== Background category? ===<br />
<br />
In line with the concept that all articles should be in a category, to make sure Web indexers can find them, I started to think about articles on background/fundamental topics (e.g. [[virtual memory]]). They don't really fit into any existing top-level category. At first I thought about creating a new top-level category for them, but I realized I don't need to, at least to make sure there are no [http://gunkies.org/wiki/Special:LonelyPages 'orphan' articles]; in general, those pages were all created in response to red links in existing articles (which do all tend to be in categories), so if ''those'' are all in categories, Web indexers will be able to find the background articles too. Still, so people think it would be useful to have a catgory for them? If so, what shoud it be called? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 00:49, 11 June 2018 (CEST)<br />
<br />
: I don't think trying to fit everything into a category is necessary when it doesn't particularly improve anything. [[User:Tor|Tor]] ([[User talk:Tor|talk]])<br />
<br />
: There is another good reason for have a category for all the 'basics' article I've been creating, which is that they currently clog up [http://gunkies.org/w/index.php?title=Special:UncategorizedPages&limit=50&offset=50 Uncategorized Pages], which I would like to use to find pages that really ''are'' missing an appropriate category. So I think we should start one; any suggestions for a better name than 'Basics'? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 01:20, 12 December 2018 (CET)<br />
<br />
::'Basics' is fine with me. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 14:56, 12 December 2018 (CET)<br />
<br />
:: Thanks for the feedback! I'll probably have a number of sub-categories (e.g. 'Hardware basics' for things like [[pipeline]], and 'Software basics' for [[thread]], etc). I'll have to look at the [[User:Jnc#Pages I have added|whole list]], and see how many, and what, to call them. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 17:36, 12 December 2018 (CET)<br />
<br />
OK, so I've gone through and tagged all the background/basics pages I started, and also most of the 'currently-uncategorized' pages. (Not really, on the latter; explanation below.) So I had to greatly expand the number of categories.<br />
<br />
Let me say, right up front, that I'm sure I made some mistakes<br />
here - both in the extension to the category structure, and in the<br />
assignment of pages to categories. For the first: with 20/20 hindsight, and experience, one often finds there are improvements. For the latter... by the end, I was pretty worn out, and just wanted it to be ''over''! Anyway, it's a wiki, not carved in stone; I'm sure we'll catch and fix my infelicities.<br />
<br />
Anyway, I started, as discussed, with a Basics category, and a bunch of sub-categories (because I didn't want to have huge categories with a zillion pages in them):<br />
<br />
* [[:Category: Basics]]<br />
** [[:Category: Theory]] - Math, algorithms, etc<br />
** [[:Category: Electrical Basics]]<br />
** [[:Category: Computer Basics]]<br />
** [[:Category: Hardware Basics]]<br />
** [[:Category: CPU Basics]]<br />
** [[:Category: Memory Basics]]<br />
** [[:Category: Device Basics]]<br />
** [[:Category: Software Basics]]<br />
** [[:Category: OS Basics]]<br />
** [[:Category: Communication Basics]]<br />
** [[:Category: Networking Basics]]<br />
<br />
The header for each one tries to explain what goes there; e.g. [[:Category:Hardware Basics]] says " general basics of the hardware logic of a computer", and if you look at the category contents, you can see that.<br />
<br />
Some things went in the top plain 'Basics' category, if they were ''really'' basic, or extended across sub-categories, e.g. [[buffer]], [[address]], etc.<br />
<br />
I discovered, to my astonishment, that we didn't have a 'Hardware' category, so that, and some sub-cats to it, have also been added:<br />
<br />
* [[:Category: Hardware]] - A super-cat for cats about hardware<br />
** [[:Category: Components]] - Mostly physical hardware<br />
** [[:Category: Electrical]] - More advanced electrical stuff<br />
** [[:Category: Electronics]] - Basic electronics concepts<br />
** [[:Category: Technology]] - Applied electronics<br />
** [[:Category: CPU Hardware]] - Advanced CPU concepts<br />
<br />
Again, the header for each one tries to explain what goes there; e.g. [[:Category:Components]] says "Hardware components of a computer; mechanical assemblies, etc."<br />
<br />
There is a certain amount of cross-linking; e.g. many of the hardware-related 'Basics' categories show up under 'Hardware' as well as 'Basics', and vice versa etc. I also added:<br />
<br />
* [[:Category: Software Concepts]]<br />
* [[:Category: OS Concepts]]<br />
<br />
for 'advanced' topics in those areas. A lot of other categories got added as I looked at other previously un-categorized pages; e.g. categories for Apple software and hardware, and an Apple category to hold them all, etc. [http://gunkies.org/w/index.php?title=Special%3APrefixIndex&prefix=Category%3A&namespace=0&hideredirects=1 This page] shows the current list of categories, and [http://gunkies.org/wiki/Special:NewPages?namespace=14&size-mode=min here] is a list of the added categories.<br />
<br />
Finally, many un-categorized articles don't yet show up in the [http://gunkies.org/wiki/Special:UncategorizedPages automatic list] since both {stub} and {semi-stub} add pages to a category. Which, in retrospect, is dumb, because the 'what links here' of them will [http://gunkies.org/wiki/Special:WhatLinksHere/Template:Semi-stub show them too], and won't 'contaminate' the Uncategorized Pages list. So in a day or two, once I have recovered, I'll probably change those templates to not add them to categories, and then deal with the resultant 'newly'-uncategorized pages.<br />
<br />
Whew! [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 14:35, 17 December 2018 (CET)<br />
<br />
: OK, the semi-stubs and stubs are all 'done' now too. (What a slog!) A few more categories got added; see [http://gunkies.org/wiki/Special:NewPages?namespace=14&size-mode=min here] for them. Like I said (above), I'm sure there are some mistakes, but in a job that size... OK, now to fix them! [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 01:20, 20 December 2018 (CET)<br />
<br />
: Just added a few final touches; a cat ([[:Category: History]]) for a couple of the remaining un-cat'd articles, plus that gives a home for a top-level cat that didn't have a home; then added that to the list on the home page - and ditched OS's, which can be reached via [[:Category: Software]]. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 04:23, 23 December 2018 (CET)<br />
<br />
==PC categories==<br />
<br />
I guess the PC-related categories could be cleaned up a bit. We've got categories for most major manufacturers, and also a category for general PC stuff: [[:Category:Compatible PCs]], but I'm thinking we need several: one for generic PC-related topics (e.g. [[BIOS]]), one for actual machines - and that needs to be split into two, one for IBM-compatibles, and one for the earler ''sui generis'' machinesl ike Tandy's. And then for the ''software'', we need (I reckon) a category for general topics like [[TSR]], as well as applications, etc.<br />
I can sort of generally see where we need to go (above), but does anyone have any suggestions/comments? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 01:20, 20 December 2018 (CET)<br />
<br />
I'm thinking something like 'non-compatible PC's for the early machines like Tandy's, etc? Many of the more non-home machines(like Suns, etc) will go in 'Workstations', of course. So those, along with the company-specific cats, should take care of the hardware - now to ponder the software. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 19:30, 20 December 2018 (CET)<br />
<br />
OK, so I did that - [[:Category: Non-Compatible PCs]]; non-microprocessor 'personal computers' go in the top-level [[:Category: Personal Computers]] cat, and there are the two sub-cats for PC-compatible and sui generis PCs. No doubt many of the latter are not yet tagged with the correct cat - that will happen over time. (I went ahead an added the sub-cats for various manufacturer machines like [[:Category: Atari Computers]] to the new sub-cat, so that will catch many of them.) [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:49, 21 December 2018 (CET)<br />
<br />
== Duplicate VAX categories ==<br />
<br />
So [[:Template: InfoboxVAX-Data]] is assigning all the articles which use it to both [[:Category: VAXen]] (no header) ''and'' [[:Category: DEC VAX systems]] ("Members of the Digital Equipment Corporation VAX family of computers"), which seems kind of redundant to me. Should we just delete one? Or keep one for individual models, and then have a VAX super-cat, that would be for things like [[VUP]]? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 13:51, 27 December 2018 (CET)<br />
:Redundant. I can't see why both would be needed. I think I see what you mean your second suggestion - one for the actual VAX hardware, and another for other VAX-related things. Could make sense I guess, but how many are there, besides VUP? [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 10:04, 28 December 2018 (CET)</div>Torhttps://gunkies.org/w/index.php?title=DR11_parallel_interface&diff=20019DR11 parallel interface2018-12-17T10:11:18Z<p>Tor: Re-insert letter accidentally lost in prev edit</p>
<hr />
<div>The '''DR11s''' were a series of parallel interfaces for the [[UNIBUS]] and [[QBUS]]. Some used [[Direct Memory Access|DMA]], others were [[programmed I/O]].<br />
<br />
They included, for the UNIBUS:<br />
<br />
* [[DR11-A parallel interface|DR11]] (sometimes called the DR11-A): [[programmed I/O]], [[DEC card form factor|quad]] [[Small Peripheral Controller|SPC]] slot<br />
* [[DR11-B parallel interface|DR11-B]]: [[Direct Memory Access|DMA]], 4-slot [[system unit]]<br />
* [[DR11-C parallel interface|DR11-C]]: single-board replacement for the DR11-A<br />
* [[DR11-L parallel interface|DR11-L]]: double input-only<br />
* [[DR11-M parallel interface|DR11-M]]: double output-only<br />
* [[DR11-W parallel interface|DR11-W]]: [[DEC card form factor|hex]] single-board replacement for the DR11-B<br />
<br />
and for the QBUS:<br />
<br />
* DRV11: as for the DR11, on a [[DEC card form factor|dual]] card<br />
* DRV11-J: 4 DRV11's on a dual card<br />
* DRV11-B: DMA, quad card, 18-bit DMA addresses<br />
* DRV11-WA: DMA, dual card, 22-bit DMA addresses<br />
<br />
There is also a DRV11-C (M8040), but little is currently known about it.<br />
<br />
Almost all use the same interface, except the DRV11-J, which for space reasons uses a different header on the card.<br />
<br />
[[Category:UNIBUS Peripherals]]<br />
[[Category:QBUS Peripherals]]</div>Torhttps://gunkies.org/w/index.php?title=Help_talk:Categories&diff=19189Help talk:Categories2018-12-12T13:56:06Z<p>Tor: /* Background category? */</p>
<hr />
<div>==Peripherals/Devices==<br />
<br />
Hi, I'm getting set to create categories for PDP-10 and PDP-11 peripherals/devices (I've been doing a lot of organization on the CPU/system/etc end of things, and have that in pretty good shape now). Which word would be better to use, if you have an opinion - 'peripherals' or 'devices'? We current do already have a [[:Category:Peripherals]], so maybe go with that? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 16:05, 19 February 2018 (CET)<br />
<br />
: I tend to go with 'peripherals' in this case. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
OK; I'll get started on that. And also, I think we should have a category for all DEC stuff - just plain 'DEC', or 'Digital Equipment Corporation'?<br />
<br />
: DEC is consistent with the other labels. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: I'll have to ponder the DEC category name. It feels a bit 'thin', just plain 'DEC'. I don't mind the acronym 'DEC' as ''part'' of the name of sub-categories (it prevents them getting ridiculously long); but for the main category, it feels too informal. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 20:28, 19 February 2018 (CET)<br />
<br />
==Other cats==<br />
<br />
BTW, I added some thoughts about cats to [[Help:Introduction to Categories#Current organization]] - does that seem like a good system? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 19:44, 19 February 2018 (CET)<br />
<br />
: There's one problem with the taxonomy. Not all PDP-10 (or 11 or 8) operating systems are DEC operating system. At least not in the sense "operating systems made by DEC". [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: I'm happy to subdivide it (them, actually) into two other categories; any snappy ideas for the name(s)? I suppose we could have 'DEC Operating Systems' and 'Non-DEC Operating Systems'; each of which is further divided into, e.g., 'DEC PDP-11 Operating Systems' and 'Non-DEC PDP-11 Operating Systems'. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 20:28, 19 February 2018 (CET)<br />
<br />
::: That'll potentially be a lot of category pages to create! Can't a page be in both the DEC Operating Systems category, and the PDP-10 Operating Systems category? [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: Sorry, I'm not sure I'm seeing your concept; a concrete example would help. What pages (and sub-categories) would go in 'DEC Operating Systems' category, and what in the 'PDP-10 Operating Systems'? ITS would clearly be in the latter, but would it be in any others? What super-category would the 'PDP-10 Operating Systems' category be in? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]])<br />
<br />
::: TOPS-10 would be in both 'DEC OSes' and 'PDP-10 OSes'. OS/8 would be in both 'DEC OSes' and 'PDP-8 OSes'. ITS would be in just 'PDP-10 OSes'. Unix V7 would be in just 'PDP-11 OSes'. 'DEC OSes', 'PDP-8 OSes', 'PDP-10 OSes', and 'PDP-11 OSes' would all be in 'Operating Systems'.<br />
::: This way, there would be N+M categories (for N manufacturers and M architectures), rather than NxM. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: Ah, got it.<br />
:: The only potential downside to that approach is that there's no easy way to find non-DEC OS's, other than going through all the per-machine OS categories - for which having a 'OS's for DEC machines' super-cat would be mildly helpful, as opposed to just putting them in 'OS's'.<br />
:: Ah, how about a single 'non-DEC OS's for DEC machines' category? (Although it would need a snappier name than that - can't come up with one quickly.) So TOPS-10 would be in 'DEC OS's' and 'PDP-10 OS's', Unix V6 would be in 'non-DEC OS's' and 'PDP-11 OS's', etc.<br />
:: That's only one more category, and it would help find the non-DEC OS's easily; and no PDP OS article would have more than two category tags. (I'm going to put off for now the issue of OS's like MUMPS, which started out as a private venture, and which eventully wound up as a DEC product! :-)<br />
:: BTW, actually my orginal proposal was not N*M; it was Sum(2*Mi), instead of Sum(Mi), where Mi is the number of architecture for manufacturer i, out of N. But still, you're right, it would have been a lot! Twice as many as the other way... [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:04, 20 February 2018 (CET)<br />
<br />
: Now that I see the 'Non-DEC Operating Systems' Category, it does look quite strange.. on the surface of it it would cover everything that's not DEC or for DEC, i.e. most operating systems (and then a visitor would wonder why it's named that way, too.) But then it's definitely for DEC, just not made by DEC. It gets a bit confusing. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 09:20, 23 February 2018 (CET)<br />
<br />
:: I agree, actually! Despite thinking about it for several days, I just couldn't come up with a short, snappy name that, on its face, described what the category was about! 'Non-DEC Operating Systems for DEC Machines' is a bit ponderous! If anyone can come up with a better one, I'd be happy to change it (which is why I put off going around tagging articles). I asked Lars if he had a suggestion...<br />
:: In the interim, that's why I put the description in the Help: page (and the cat header), to warn people it's not what the name, ''strictly''-speaking, implies. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 14:06, 23 February 2018 (CET)<br />
<br />
:: So Lars mentioned 'external', and synonyms for it... independent, outside, foreign, non-proprietary.<br />
:: Of these, 'Independent DEC OSs' wouldn't be ''too'' bad - I'd be OK with switching to that. 'External DEC OSs' initially ''sounds'' like it might be the best, but it could be misunderstood as still being a product of DEC, for use outside the company (and the same applies to the others, too).<br />
:: Although it still doesn't describe ''exactly'' what the category is, 'Independent' does 'on its face' clearly indicate there's something unusual (i.e. it doesn't ''clearly'' give a wrong impression), and gives a strong hint of what it really is.<br />
:: The problem is that the shortest facially accurate description (i.e. without any external amplification) is 'non-DEC OSs for DEC machines', which is long and clunky. Anything shorter is going to have some lack of clarity. E.g. 'Independent DEC OSs' - what ''exactly'' is that - if you don't already know?<br />
:: Anyway, whatever solution we come up with for DEC, we can use for any companies that need it - e.g. 'Independent IBM OSs'. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:00, 23 February 2018 (CET)<br />
<br />
: And.... crickets. Oh, well! [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 13:57, 27 February 2018 (CET)<br />
<br />
:: No use overthinking this. Full steam ahead! [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
::: OK. Hey, I'm from MIT - according to some people, over-thinking things is what we do! :-) [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 21:17, 1 March 2018 (CET)<br />
<br />
== Terminal categories ==<br />
<br />
So I recently split up [[:Category:Terminals]] into [[:Category:Printing Terminals]] and [[:Category:Video Terminals]]. There's also a [[:Category:DEC Terminals]]. So, currently all the DEC terminals ([[VT52]], etc) are tagged with two categories: 'DEC Terminals' and 'Printing/Video Terminals'. Is this the way people want to go, or should we create 'Printing' and 'Video' sub-categories of 'DEC Terminals'? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 03:55, 8 June 2018 (CEST)<br />
<br />
== Unix OS cat? ==<br />
<br />
I've noticed that there are a ''lot'' of systems in the top-level category [[:Category: Operating Systems]]; the majority are Unix derivations of some type or other. I propose to move them all to a new 'Unix clones' category, so only truly one-off systems like [[CTSS]], etc are in the top-level cat. Additional query: what should the cat be called - 'Unix-based Operating Systems', or what? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 18:00, 10 June 2018 (CEST)<br />
<br />
:Sounds ok to me. Would that be a sub-category in Operating Systems then, easily found at the top of the page? As for the name - I think 'Unix-based Operating Systems' is fine. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 15:28, 17 June 2018 (CEST)<br />
<br />
: oK, good, I'll make it happen. Yes, it will be a sub-cat of [[:Category: Operating Systems]]. I think I'll use [[:Category: Unix-based OS's]], though, to keep it from being ''too'' clunky. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 17:55, 17 June 2018 (CEST)<br />
: Ah, in retrospect I should have used the full 'Unix-based Operating Systems'; now most of the sub-cats in [[:Category: Operating Systems]] use the full 'Operating Systems' in the name, so the Unix ones are now somewhat 'odd cats out'! Sigh! [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 02:26, 18 June 2018 (CEST)<br />
<br />
Another idea: I currently have two cats (the first below, plus 'everything else'),but maybe we should have three categories:<br />
* Unix versions done by Bell/ATT<br />
* Unix versions which are external descendants (Ultrix, Sun, etc)<br />
* Unix 'clones' (Linux, Coherent, etc)<br />
Comments? (And names, if the idea is desirable)? I wonder into which do the later BSD's fit - IIRC, they eventually got rid of ''all'' the Bell code? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 17:13, 18 June 2018 (CEST)<br />
<br />
== Category work ==<br />
<br />
After I created a new article on an obscure video terminal board, it was pointed out to me that since no other article linked to it, Web indexers wouldn't find it. I realized that if every article is in a category which is included in some way in one of the main categories, which are linked to on the [[Main Page]], that would do it. So I'm going to try and improve categories and cat tags, make sure all articles have the desired tags, etc. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 00:40, 11 June 2018 (CEST)<br />
<br />
=== Background category? ===<br />
<br />
In line with the concept that all articles should be in a category, to make sure Web indexers can find them, I started to think about articles on background/fundamental topics (e.g. [[virtual memory]]). They don't really fit into any existing top-level category. At first I thought about creating a new top-level category for them, but I realized I don't need to, at least to make sure there are no [http://gunkies.org/wiki/Special:LonelyPages 'orphan' articles]; in general, those pages were all created in response to red links in existing articles (which do all tend to be in categories), so if ''those'' are all in categories, Web indexers will be able to find the background articles too. Still, so people think it would be useful to have a catgory for them? If so, what shoud it be called? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 00:49, 11 June 2018 (CEST)<br />
<br />
: I don't think trying to fit everything into a category is necessary when it doesn't particularly improve anything. [[User:Tor|Tor]] ([[User talk:Tor|talk]])<br />
<br />
: There is another good reason for have a category for all the 'basics' article I've been creating, which is that they currently clog up [http://gunkies.org/w/index.php?title=Special:UncategorizedPages&limit=50&offset=50 Uncategorized Pages], which I would like to use to find pages that really ''are'' missing an appropriate category. So I think we should start one; any suggestions for a better name than 'Basics'? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 01:20, 12 December 2018 (CET)<br />
::'Basics' is fine with me. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 14:56, 12 December 2018 (CET)</div>Torhttps://gunkies.org/w/index.php?title=AIX&diff=17025AIX2018-06-22T12:26:13Z<p>Tor: Version 7.2</p>
<hr />
<div>{{Infobox OS <br />
| image = logo-aix.gif<br />
| caption = Logging into an AIX system<br />
| name = AIX<br />
| creator = [[IBM]]<br />
| current version = 7.1 for RS/6000, PPC, up to POWER8<br />
| year introduced = 1986<br />
| type = Multitasking, multiuser UNIX<br />
| architecture = [[RT/PC]], [[RS/6000]], [[IBM 386]], [[System/370]]<br />
}}<br />
<br />
'''Advanced Interactive eXecutive (AIX)''' is the version of [[UNIX]] developed by IBM, initially for the [[RT/PC]], and subsequently for [[RS/6000]], [[PS/2]] and [[System/370]].<br />
<br />
(See '[https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/ Let’s start at the very beginning… 801, ROMP, RT/PC, AIX versions]', which describes the initial 3 versions.)<br />
<br />
== Version 1.x ==<br />
AIX 1 was jointly developed by IBM Austin, IBM Yorktown and Interactive Systems Corporation, based on [[System III]] and [[SVR1]] of [[Unix SYSV]], and released for the RT/PC. It suffered from the expected limitations of a first release. See [http://technologists.com/sauer/SA23-1057_IBM_RT_Personal_Computer_Technology_1986.pdf IBM RT Personal Computer Technology].<br />
<br />
== Version 2.x ==<br />
AIX 2 supported the second version of the RT/PC hardware and capabilities planned for the first release. See '[http://technologists.com/sauer/Advanced%20Interactive%20Executive%20(AIX)%20Operating%20System%20Overview.pdf Advanced Interactive Executive (AIX) Operating System Overview]'.<br />
<br />
== Version 3.x ==<br />
AIX 3 was designed to overcome limitations of prior versions and support the RS/6000. In addition, companion versions ('[https://archive.org/stream/bitsavers_ibmpcrtaixefinitionOverviewJul88_4100993/GC23-2002-0_AIX_Family_Definition_Overview_Jul88_djvu.txt IBM AIX Family Definition Overview]') were released for PS/2 and System/370, including TCF (Transparent Computing Facility) based on [https://en.wikipedia.org/wiki/LOCUS_(operating_system) LOCUS]. See [http://ieeexplore.ieee.org/document/109275/ AIX 3 Technology]<br />
<br />
== Version 4.x ==<br />
Version 4.x introduced CPU support for the [[PowerPC]] family of processors, and included minor [[CHIRP]]/[[PReP]] compatibility, and at least one [[Apple]] server that ran AIX.<br />
<br />
== Version 5L ==<br />
As it remains now, it's a [[SYSVr3]] based OS with many enhancements from [[BSD]] and [[Linux]].<br />
<br />
== Version 6.x ==<br />
More Linux- and [[POSIX]] compatibility. Some POSIX thread library functions that are only stubs in 5.x are actually working in 6.1 (e.g. some locking functions that appear to be available in 5.1 but aren't locking anything!)<br />
<br />
== Version 7.x ==<br />
Adds virtualization support for AIX 5.3 environments. Built-in clustering support.<br />
7.2 adds live kernel updates and some other improvements, including Power9 support.<br />
{{stub}}<br />
<br />
{{Nav Unix}}<br />
<br />
[[Category: Unix-based OS's]]</div>Torhttps://gunkies.org/w/index.php?title=Help_talk:Categories&diff=16931Help talk:Categories2018-06-17T13:31:46Z<p>Tor: /* Re Background category? */</p>
<hr />
<div>==Peripherals/Devices==<br />
<br />
Hi, I'm getting set to create categories for PDP-10 and PDP-11 peripherals/devices (I've been doing a lot of organization on the CPU/system/etc end of things, and have that in pretty good shape now). Which word would be better to use, if you have an opinion - 'peripherals' or 'devices'? We current do already have a [[:Category:Peripherals]], so maybe go with that? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 16:05, 19 February 2018 (CET)<br />
<br />
: I tend to go with 'peripherals' in this case. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
OK; I'll get started on that. And also, I think we should have a category for all DEC stuff - just plain 'DEC', or 'Digital Equipment Corporation'?<br />
<br />
: DEC is consistent with the other labels. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: I'll have to ponder the DEC category name. It feels a bit 'thin', just plain 'DEC'. I don't mind the acronym 'DEC' as ''part'' of the name of sub-categories (it prevents them getting ridiculously long); but for the main category, it feels too informal. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 20:28, 19 February 2018 (CET)<br />
<br />
==Other cats==<br />
<br />
BTW, I added some thoughts about cats to [[Help:Introduction to Categories#Current organization]] - does that seem like a good system? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 19:44, 19 February 2018 (CET)<br />
<br />
: There's one problem with the taxonomy. Not all PDP-10 (or 11 or 8) operating systems are DEC operating system. At least not in the sense "operating systems made by DEC". [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: I'm happy to subdivide it (them, actually) into two other categories; any snappy ideas for the name(s)? I suppose we could have 'DEC Operating Systems' and 'Non-DEC Operating Systems'; each of which is further divided into, e.g., 'DEC PDP-11 Operating Systems' and 'Non-DEC PDP-11 Operating Systems'. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 20:28, 19 February 2018 (CET)<br />
<br />
::: That'll potentially be a lot of category pages to create! Can't a page be in both the DEC Operating Systems category, and the PDP-10 Operating Systems category? [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: Sorry, I'm not sure I'm seeing your concept; a concrete example would help. What pages (and sub-categories) would go in 'DEC Operating Systems' category, and what in the 'PDP-10 Operating Systems'? ITS would clearly be in the latter, but would it be in any others? What super-category would the 'PDP-10 Operating Systems' category be in? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]])<br />
<br />
::: TOPS-10 would be in both 'DEC OSes' and 'PDP-10 OSes'. OS/8 would be in both 'DEC OSes' and 'PDP-8 OSes'. ITS would be in just 'PDP-10 OSes'. Unix V7 would be in just 'PDP-11 OSes'. 'DEC OSes', 'PDP-8 OSes', 'PDP-10 OSes', and 'PDP-11 OSes' would all be in 'Operating Systems'.<br />
::: This way, there would be N+M categories (for N manufacturers and M architectures), rather than NxM. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: Ah, got it.<br />
:: The only potential downside to that approach is that there's no easy way to find non-DEC OS's, other than going through all the per-machine OS categories - for which having a 'OS's for DEC machines' super-cat would be mildly helpful, as opposed to just putting them in 'OS's'.<br />
:: Ah, how about a single 'non-DEC OS's for DEC machines' category? (Although it would need a snappier name than that - can't come up with one quickly.) So TOPS-10 would be in 'DEC OS's' and 'PDP-10 OS's', Unix V6 would be in 'non-DEC OS's' and 'PDP-11 OS's', etc.<br />
:: That's only one more category, and it would help find the non-DEC OS's easily; and no PDP OS article would have more than two category tags. (I'm going to put off for now the issue of OS's like MUMPS, which started out as a private venture, and which eventully wound up as a DEC product! :-)<br />
:: BTW, actually my orginal proposal was not N*M; it was Sum(2*Mi), instead of Sum(Mi), where Mi is the number of architecture for manufacturer i, out of N. But still, you're right, it would have been a lot! Twice as many as the other way... [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:04, 20 February 2018 (CET)<br />
<br />
: Now that I see the 'Non-DEC Operating Systems' Category, it does look quite strange.. on the surface of it it would cover everything that's not DEC or for DEC, i.e. most operating systems (and then a visitor would wonder why it's named that way, too.) But then it's definitely for DEC, just not made by DEC. It gets a bit confusing. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 09:20, 23 February 2018 (CET)<br />
<br />
:: I agree, actually! Despite thinking about it for several days, I just couldn't come up with a short, snappy name that, on its face, described what the category was about! 'Non-DEC Operating Systems for DEC Machines' is a bit ponderous! If anyone can come up with a better one, I'd be happy to change it (which is why I put off going around tagging articles). I asked Lars if he had a suggestion...<br />
:: In the interim, that's why I put the description in the Help: page (and the cat header), to warn people it's not what the name, ''strictly''-speaking, implies. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 14:06, 23 February 2018 (CET)<br />
<br />
:: So Lars mentioned 'external', and synonyms for it... independent, outside, foreign, non-proprietary.<br />
:: Of these, 'Independent DEC OSs' wouldn't be ''too'' bad - I'd be OK with switching to that. 'External DEC OSs' initially ''sounds'' like it might be the best, but it could be misunderstood as still being a product of DEC, for use outside the company (and the same applies to the others, too).<br />
:: Although it still doesn't describe ''exactly'' what the category is, 'Independent' does 'on its face' clearly indicate there's something unusual (i.e. it doesn't ''clearly'' give a wrong impression), and gives a strong hint of what it really is.<br />
:: The problem is that the shortest facially accurate description (i.e. without any external amplification) is 'non-DEC OSs for DEC machines', which is long and clunky. Anything shorter is going to have some lack of clarity. E.g. 'Independent DEC OSs' - what ''exactly'' is that - if you don't already know?<br />
:: Anyway, whatever solution we come up with for DEC, we can use for any companies that need it - e.g. 'Independent IBM OSs'. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:00, 23 February 2018 (CET)<br />
<br />
: And.... crickets. Oh, well! [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 13:57, 27 February 2018 (CET)<br />
<br />
:: No use overthinking this. Full steam ahead! [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
::: OK. Hey, I'm from MIT - according to some people, over-thinking things is what we do! :-) [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 21:17, 1 March 2018 (CET)<br />
<br />
== Terminal categories ==<br />
<br />
So I recently split up [[:Category:Terminals]] into [[:Category:Printing Terminals]] and [[:Category:Video Terminals]]. There's also a [[:Category:DEC Terminals]]. So, currently all the DEC terminals ([[VT52]], etc) are tagged with two categories: 'DEC Terminals' and 'Printing/Video Terminals'. Is this the way people want to go, or should we create 'Printing' and 'Video' sub-categories of 'DEC Terminals'? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 03:55, 8 June 2018 (CEST)<br />
<br />
== Unix OS cat? ==<br />
<br />
I've noticed that there are a ''lot'' of systems in the top-level category [[:Category: Operating Systems]]; the majority are Unix derivations of some type or other. I propose to move them all to a new 'Unix clones' category, so only truly one-off systems like [[CTSS]], etc are in the top-level cat. Additional query: what should the cat be called - 'Unix-based Operating Systems', or what? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 18:00, 10 June 2018 (CEST)<br />
:Sounds ok to me. Would that be a sub-category in Operating Systems then, easily found at the top of the page? As for the name - I think 'Unix-based Operating Systems' is fine. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 15:28, 17 June 2018 (CEST)<br />
<br />
== Background category? ==<br />
<br />
So,in line with the concept that all articles should be in a category, to make sure Web indexers can find them from the Main Page, I started to think about articles on background/fundamental topics (e.g. [[virtual memory]]). They don't really fit into any existing top-level category. At first I thought about creating a new top-level category for them, but I realized I don't need to, at least to make sure there are no [http://gunkies.org/wiki/Special:LonelyPages 'orphan' articles]; in general, those pages were all created in response to red links in existing articles (which do all tend to be in categories), so if ''those'' are all in categories, Web indexers will be able to find the background articles too. Still, so people think it would be useful to have a catgory for them? If so, what shoud it be called? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 00:49, 11 June 2018 (CEST)<br />
:I don't think trying to fit everything into a category is necessary when it doesn't particularly improve anything. [[User:Tor|Tor]] ([[User talk:Tor|talk]])</div>Torhttps://gunkies.org/w/index.php?title=Help_talk:Categories&diff=16930Help talk:Categories2018-06-17T13:28:47Z<p>Tor: /* Unix OS cat? */</p>
<hr />
<div>==Peripherals/Devices==<br />
<br />
Hi, I'm getting set to create categories for PDP-10 and PDP-11 peripherals/devices (I've been doing a lot of organization on the CPU/system/etc end of things, and have that in pretty good shape now). Which word would be better to use, if you have an opinion - 'peripherals' or 'devices'? We current do already have a [[:Category:Peripherals]], so maybe go with that? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 16:05, 19 February 2018 (CET)<br />
<br />
: I tend to go with 'peripherals' in this case. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
OK; I'll get started on that. And also, I think we should have a category for all DEC stuff - just plain 'DEC', or 'Digital Equipment Corporation'?<br />
<br />
: DEC is consistent with the other labels. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: I'll have to ponder the DEC category name. It feels a bit 'thin', just plain 'DEC'. I don't mind the acronym 'DEC' as ''part'' of the name of sub-categories (it prevents them getting ridiculously long); but for the main category, it feels too informal. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 20:28, 19 February 2018 (CET)<br />
<br />
==Other cats==<br />
<br />
BTW, I added some thoughts about cats to [[Help:Introduction to Categories#Current organization]] - does that seem like a good system? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 19:44, 19 February 2018 (CET)<br />
<br />
: There's one problem with the taxonomy. Not all PDP-10 (or 11 or 8) operating systems are DEC operating system. At least not in the sense "operating systems made by DEC". [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: I'm happy to subdivide it (them, actually) into two other categories; any snappy ideas for the name(s)? I suppose we could have 'DEC Operating Systems' and 'Non-DEC Operating Systems'; each of which is further divided into, e.g., 'DEC PDP-11 Operating Systems' and 'Non-DEC PDP-11 Operating Systems'. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 20:28, 19 February 2018 (CET)<br />
<br />
::: That'll potentially be a lot of category pages to create! Can't a page be in both the DEC Operating Systems category, and the PDP-10 Operating Systems category? [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: Sorry, I'm not sure I'm seeing your concept; a concrete example would help. What pages (and sub-categories) would go in 'DEC Operating Systems' category, and what in the 'PDP-10 Operating Systems'? ITS would clearly be in the latter, but would it be in any others? What super-category would the 'PDP-10 Operating Systems' category be in? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]])<br />
<br />
::: TOPS-10 would be in both 'DEC OSes' and 'PDP-10 OSes'. OS/8 would be in both 'DEC OSes' and 'PDP-8 OSes'. ITS would be in just 'PDP-10 OSes'. Unix V7 would be in just 'PDP-11 OSes'. 'DEC OSes', 'PDP-8 OSes', 'PDP-10 OSes', and 'PDP-11 OSes' would all be in 'Operating Systems'.<br />
::: This way, there would be N+M categories (for N manufacturers and M architectures), rather than NxM. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: Ah, got it.<br />
:: The only potential downside to that approach is that there's no easy way to find non-DEC OS's, other than going through all the per-machine OS categories - for which having a 'OS's for DEC machines' super-cat would be mildly helpful, as opposed to just putting them in 'OS's'.<br />
:: Ah, how about a single 'non-DEC OS's for DEC machines' category? (Although it would need a snappier name than that - can't come up with one quickly.) So TOPS-10 would be in 'DEC OS's' and 'PDP-10 OS's', Unix V6 would be in 'non-DEC OS's' and 'PDP-11 OS's', etc.<br />
:: That's only one more category, and it would help find the non-DEC OS's easily; and no PDP OS article would have more than two category tags. (I'm going to put off for now the issue of OS's like MUMPS, which started out as a private venture, and which eventully wound up as a DEC product! :-)<br />
:: BTW, actually my orginal proposal was not N*M; it was Sum(2*Mi), instead of Sum(Mi), where Mi is the number of architecture for manufacturer i, out of N. But still, you're right, it would have been a lot! Twice as many as the other way... [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:04, 20 February 2018 (CET)<br />
<br />
: Now that I see the 'Non-DEC Operating Systems' Category, it does look quite strange.. on the surface of it it would cover everything that's not DEC or for DEC, i.e. most operating systems (and then a visitor would wonder why it's named that way, too.) But then it's definitely for DEC, just not made by DEC. It gets a bit confusing. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 09:20, 23 February 2018 (CET)<br />
<br />
:: I agree, actually! Despite thinking about it for several days, I just couldn't come up with a short, snappy name that, on its face, described what the category was about! 'Non-DEC Operating Systems for DEC Machines' is a bit ponderous! If anyone can come up with a better one, I'd be happy to change it (which is why I put off going around tagging articles). I asked Lars if he had a suggestion...<br />
:: In the interim, that's why I put the description in the Help: page (and the cat header), to warn people it's not what the name, ''strictly''-speaking, implies. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 14:06, 23 February 2018 (CET)<br />
<br />
:: So Lars mentioned 'external', and synonyms for it... independent, outside, foreign, non-proprietary.<br />
:: Of these, 'Independent DEC OSs' wouldn't be ''too'' bad - I'd be OK with switching to that. 'External DEC OSs' initially ''sounds'' like it might be the best, but it could be misunderstood as still being a product of DEC, for use outside the company (and the same applies to the others, too).<br />
:: Although it still doesn't describe ''exactly'' what the category is, 'Independent' does 'on its face' clearly indicate there's something unusual (i.e. it doesn't ''clearly'' give a wrong impression), and gives a strong hint of what it really is.<br />
:: The problem is that the shortest facially accurate description (i.e. without any external amplification) is 'non-DEC OSs for DEC machines', which is long and clunky. Anything shorter is going to have some lack of clarity. E.g. 'Independent DEC OSs' - what ''exactly'' is that - if you don't already know?<br />
:: Anyway, whatever solution we come up with for DEC, we can use for any companies that need it - e.g. 'Independent IBM OSs'. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:00, 23 February 2018 (CET)<br />
<br />
: And.... crickets. Oh, well! [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 13:57, 27 February 2018 (CET)<br />
<br />
:: No use overthinking this. Full steam ahead! [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
::: OK. Hey, I'm from MIT - according to some people, over-thinking things is what we do! :-) [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 21:17, 1 March 2018 (CET)<br />
<br />
== Terminal categories ==<br />
<br />
So I recently split up [[:Category:Terminals]] into [[:Category:Printing Terminals]] and [[:Category:Video Terminals]]. There's also a [[:Category:DEC Terminals]]. So, currently all the DEC terminals ([[VT52]], etc) are tagged with two categories: 'DEC Terminals' and 'Printing/Video Terminals'. Is this the way people want to go, or should we create 'Printing' and 'Video' sub-categories of 'DEC Terminals'? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 03:55, 8 June 2018 (CEST)<br />
<br />
== Unix OS cat? ==<br />
<br />
I've noticed that there are a ''lot'' of systems in the top-level category [[:Category: Operating Systems]]; the majority are Unix derivations of some type or other. I propose to move them all to a new 'Unix clones' category, so only truly one-off systems like [[CTSS]], etc are in the top-level cat. Additional query: what should the cat be called - 'Unix-based Operating Systems', or what? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 18:00, 10 June 2018 (CEST)<br />
:Sounds ok to me. Would that be a sub-category in Operating Systems then, easily found at the top of the page? As for the name - I think 'Unix-based Operating Systems' is fine. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 15:28, 17 June 2018 (CEST)<br />
<br />
== Background category? ==<br />
<br />
So,in line with the concept that all articles should be in a category, to make sure Web indexers can find them from the Main Page, I started to think about articles on background/fundamental topics (e.g. [[virtual memory]]). They don't really fit into any existing top-level category. At first I thought about creating a new top-level category for them, but I realized I don't need to, at least to make sure there are no [http://gunkies.org/wiki/Special:LonelyPages 'orphan' articles]; in general, those pages were all created in response to red links in existing articles (which do all tend to be in categories), so if ''those'' are all in categories, Web indexers will be able to find the background articles too. Still, so people think it would be useful to have a catgory for them? If so, what shoud it be called? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 00:49, 11 June 2018 (CEST)</div>Torhttps://gunkies.org/w/index.php?title=Talk:Logo&diff=16526Talk:Logo2018-05-18T07:59:58Z<p>Tor: It was Logo in 1982 at least..</p>
<hr />
<div>I got chided by Leigh Klotz for writing LOGO rather than Logo, because it's not an acronym. I figure he has some authority in the matter, since he was part of the Logo group at MIT. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 08:56, 18 May 2018 (CEST)<br />
:Byte magazine (wait - BYTE magazine!) August 1982, the "Logo" issue, spells it "Logo" and not "LOGO" as I thought I remembered. So, yes I guess. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 09:59, 18 May 2018 (CEST)</div>Torhttps://gunkies.org/w/index.php?title=NORD-10&diff=16496NORD-102018-05-14T07:35:17Z<p>Tor: The NORD-10/S model used solid state memory</p>
<hr />
<div>{{Infobox Machine<br />
| name = NORD-10<br />
| manufacturer = [[Norsk Data]]<br />
| image = Nord-10.jpeg<br />
| caption = A pair of NORD-10/S minicomputers<br />
| word size = 16 bit<br />
| year introduced = 1973<br />
}}<br />
The '''NORD-10''' was a medium-sized general-purpose [[16-bit]] [[minicomputer]] designed for multilingual [[time-sharing]] applications and for [[real-time]] multiprogram systems, produced by [[Norsk Data]]. It was introduced in [[1973]]. The later follow up model, NORD-10/S, introduced in 1975, introduced [[cache]], [[paging]], and other miscellaneous improvements, including solid state memory (instead of core), thus the '/S'.<br />
<br />
The CPU had a microprocessor, which was defined in the manual as a portmanteau of "microcode processor" - not to be confused with the then nascent microprocessor. The CPU additionally contained instructions, operator communication, bootstrap loaders, and hardware test programs, were implemented in a 1K [[Read-only memory|ROM]].<br />
<br />
The microprocessor also allowed for customer specified instructions to be built in. NORD-10 had a memory management system with hardware paging extending the memory size from 64 to 256K 16-bit words and two independent protecting systems, one acting on each page and one on the mode of instructions. The interrupt system had 16 program levels in hardware, each with its own set of general-purpose registers. <br />
<br />
''Note:'' Much of the following information is taken from a document written by Norsk Data introducing the NORD-10. Some information, particularly about the memory system, may not be accurate for the later NORD-10/S.<br />
<br />
== The CPU ==<br />
<br />
The CPU consisted of a total 24 [[printed circuit board]]s. The last 8 positions in the rack were used for I/O devices operated by program control, such as the console [[Teletype]], punched paper [[punched tape|tape]] and [[punch card|card]] reader and punch, line printer, display, operator's panel, and the [[real time clock]].<br />
<br />
The NORD-10 had 160 [[processor registers|registers]], of which 128 were available to programs, 8 on each of the 16 program levels. 6 of those registers were general registers, one was the [[program counter]], and the other contained status information. [[Floating point]] operations were standard. The instructions could operate on 5 different formats, a [[bit]], an 8-bit [[byte]], 16-bit words, 32-bit double words, and 48-bit floating point words. It was also possible to order a 32-bit floating point option instead of the 48-bit one.<br />
<br />
==The memory==<br />
<br />
The [[Random access memory|memory]] system of the first NORD-10s were built up of 8K 16-bit modules housed in a special memory rack. One [[19-inch rack]] could take up to eight 8K modules. It was possible to extend the NORD-10's physical address space beyond 64K up to a maximum of 256K 16-bit words. The [[paging]] system translated a 16-bit [[virtual address]] into an 18-bit [[physical address]].<br />
<br />
The hardware paging system made it possible for one user to write programs up to 64K (virtual memory), and only parts of the program to be present in [[physical memory]] at any time (using dynamic memory allocation). The paging system divided memory into 1K pages. The 4 page index tables were found in a 256 word extremely fast memory block. The calculation of a physical address resulted in no appreciable delay in the effective memory cycle time.<br />
<br />
The NORD-10 had two independent protection systems. Each individual page could be protected against being read from, written into (type data or type instructions), or against reading of instructions. In addition, there was a system which divided the pages into four different categories, called rings. The [[Ring (computer security)|rings]] had a priority from 0 to 3. A program on a lower ring was never allowed to access the pages on a higher ring. Programs which ran on rings 2 and 3 could use the whole NORD-10 instruction set, while programs on rings 0 and 1 only had a limited instruction set available. The different rings were displayed on the operator's panel. For example, ring 0 (USER) may have held a user program, while compilers and assemblers ran in ring 1 (PROTECTED USER). The bulk of the operating system could run in ring 2 (SYSTEM), and the kernel in ring 3 (PROTECTED SYSTEM). If one attempted to execute privileged instructions in ring 0 or 1, or attempts were made to accessed a protected page, a hardware status [[interrupt]] would automatically be generated on program level 14 indicating the error.<br />
<br />
==I/O system and Bus Architecture==<br />
<br />
The NORD-10 was equipped with a common [[Computer bus|bus]] system for all [[Peripheral device|external devices]]. The bus system was divided into groups, and a great deal of effort had been made to ensure that no device would be able to jam the bus system in the case of malfunction. Each group had its own controller which in addition to functioning as an electronic switch for the bus system, could also change priority for the whole group. All interconnections between the cards were done with multilayer [[Printed circuit board|printed circuit]] [[Backplane|backwiring boards]], and all [[Input/output|I/O]] [[Interface (computer science)|interface]] had the same standard form. The system could therefore be extended or reconfigured by plugging in new or shifting around the existing interface cards. The position of the device interface in the card rack determined the [[Interrupt priority level|interrupt priority]] of the device. In [[Direct memory access|DMA]] transfers the device would send a "REQUEST". The CPU would answer with a "GRANT" signal, which would be passed from device to device until it came to the device which initiated the "REQUEST", and transfer to the memory could take place. When two or more devices issued a DMA request simultaneously the device nearest the CPU thus had the highest priority. One memory cycle later the next DMA along the chain would be allowed to send data, and so on, until a higher priority device again sent a REQUEST. This meant that many DMA devices could use the same bus system at the full data transfer rate. It was not necessary to establish a "master-slave" connection. The transfer was one 16-bit word/850 nanoseconds, or 2.2MB/s.<br />
<br />
The printed backplane of the I/O bus was modular in groups of 8 interface slots. Interfaces for [[mass storage]]s as [[Hard disk|disk]], [[Drum memory|drum]], [[Magnetic Tape|magtape]], etc., were built with one interface card to be plugged at the appropriate place in the bus system, the remaining control cards (6-7) were placed in one of the backplane modules.<br />
<br />
==The Interrupt System==<br />
<br />
The NORD-10 had a multiprogram system with 16 priority program levels. Each program level had its own set of registers, including a program counter and a [[PSW|status word]]. The levels running could be shown on the [[front panel]] by pressing the button ACTIVE LEVELS. Levels 0 through 9 were used for programs. Internal hardware status interrupts were assigned to level 14, whilst level 15 was reserved for extremely fast user interrupts (this was colloquially called the "Synchroton level", since the only program ever to have used it was the program controlling the synchroton at [[CERN]])<br />
<br />
Levels 10, 11, 12, and 13 were reserved for external devices. Each device had its own unique identification vector. In all 2048 such vectors were available. The "IDENT" instruction determined which device was giving an interrupt. The identification of an interrupt took 1.7 microseconds, including the time taken to enable and disable the registers.<br />
<br />
==System Software==<br />
<br />
The NORD-10 was delivered with a time-shared system, [[NORD-TSS]], and a real-time multitasking [[operating system]], [[SINTRAN III]]. The minimum configuration for SINTRAN III included a standard NORD-10 with 8K of [[Magnetic core memory|core]]. <br />
<br />
With NORD-TSS all users could simultaneously run any of the systems [[FORTRAN IV]], [[BASIC programming language|BASIC]], MAC [[Assembly language#Assembler|Assembler]], [[NODAL]], [[NORD-PL]], or [[QED (text editor)|QED]].<br />
<br />
==Known remaining systems==<br />
<br />
There are several known NORD-10 and NORD-10/S system known to remain, many of which are in near-operational condition, and several are in the care of [[NODAF]]. Restorations of systems are planned in both [[Oslo]] by [[NODAF]] [http://nodaf.no/index.php/NORD-10.5_progress_log] and [[Trondheim]] by [[Norwegian University of Science and Technology|NTNU]].<br />
<br />
Its predecessor was the [[NORD-1]] and its successor the [[ND-100]].<br />
<br />
==Sources==<br />
<br />
"Inside NORD-10", by Cand. Real. Jan Aske Børresen for A/S Norsk Data-Elektronikk, ND-nytt<br />
<br />
[[Category:Norsk Data Hardware]]</div>Torhttps://gunkies.org/w/index.php?title=MOS_operating_system&diff=15887MOS operating system2018-03-19T08:26:46Z<p>Tor: Typo</p>
<hr />
<div>The '''MOS operating system''' (formally the 'Micro Operating System', but informally 'Mathis' Operating System', after the creator, Jim Mathis) was an [[operating system]], originally for the [[PDP-11]], used for a number of [[packet switch]]es and similar network applications.<br />
<br />
It supported [[process]]es (but not [[preemption]], or creation/termination of processes), queued inter-process messages, asynchronous I/O, and allocation and freeing of [[main memory]]; it had no [[file system]] or other support for [[secondary storage]].<br />
<br />
The original version was written in [[MACRO-11]], the [[assembly language]] for the PDP-11; it was later re-written at least three times in [[C programming language|C]]: at BBN, at UCL, and at Proteon. The latter version was portable, and also ran on the [[Motorola MC68000|MC68000]] and [[AMD29000]].<br />
<br />
All were somewhat extended from the original; the first two fairly extensively, the latter only to make use of [[up-call]]s in the I/O system, and to support [[pseudo-terminal]]s.<br />
<br />
{{stub}}<br />
<br />
[[Category: PDP-11 Operating Systems]]<br />
[[Category: Operating Systems]]</div>Torhttps://gunkies.org/w/index.php?title=Talk:DR11_parallel_interface&diff=15886Talk:DR11 parallel interface2018-03-19T08:24:44Z<p>Tor: (sign)</p>
<hr />
<div>Shouldn't it be DRV11-WA instead of DRV11-W? I thought the QBUS variant of the DR-11W was DRV11-WA (an interface I used on a microVAX back in the day. But I'm no DEC expert.)[[User:Tor|Tor]] ([[User talk:Tor|talk]]) 09:24, 19 March 2018 (CET)</div>Torhttps://gunkies.org/w/index.php?title=Talk:DR11_parallel_interface&diff=15885Talk:DR11 parallel interface2018-03-19T08:24:25Z<p>Tor: Should it be DRV11-WA, not just W?</p>
<hr />
<div>Shouldn't it be DRV11-WA instead of DRV11-W? I thought the QBUS variant of the DR-11W was DRV11-WA (an interface I used on a microVAX back in the day. But I'm no DEC expert.)</div>Torhttps://gunkies.org/w/index.php?title=Talk:Latch&diff=15812Talk:Latch2018-03-15T08:25:01Z<p>Tor: Looks fine</p>
<hr />
<div>==Latches/Flops==<br />
<br />
My digital design friends tell me there's a distinction between latches and flip-flops. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:Your friends are right. Wikipedia uses the confusing 'a flip-flop or latch is..', which is easy to interpret to mean that 'latch' is just another word for 'flip-flop', which is not what is meant. There is a distinction, although there's overlap (b/c there are different types of latches). And when I design something I think of latches and flip-flops as entirely different things (e.g. flip-flops to divide or fix clock signals, latches to buffer/hold data). (Here's a web page which talks about flip-flops vs latches): http://www.electronicsteacher.com/computer-architectures/digital-circuits/flip-flops.php [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 09:35, 12 March 2018 (CET)<br />
<br />
:: Thanks. Then maybe the redirect from Latch to Flip-flop isn't entirely appropriate. Although, it might be better than nothing. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
: In current terminology, the two indeed refer to sets of things which do not overlap. However, after thinking about it (which I hadn't done before :-), I still think it might be appropriate to cover them in one article:<br />
:* They are both devices which use feedback to store information<br />
:* Separate articles would therefore have a lot of duplication<br />
:* Historically (and this is a ''history'' wiki :-), the terms were not so carefully delineated; e.g. in Pfister's book (he's the guy who came up with the whole SR/D/JK/T nomenclature), he talks about "R-S flip-flops"<br />
: I will definitely try and make clearer (than it already is) that in ''contemporary'' terminology, the two terms refer to disjoint sets. See what you think... [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 14:15, 13 March 2018 (CET)<br />
<br />
: Also, the division into flops/latches is not necessarily recent. I looked at the TI TTL data-book, from 1976, and they make the latch/flop distinction there. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 18:10, 13 March 2018 (CET)<br />
<br />
:: I talked to another friend, and he was vehement that they were the same thing. So clearly it's unclear. :-) [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
::: Yup. In fact, I just recently had confusion talking to my partner on the QSIC project about state storage devices - as part of clearing it up, he introduced me to the 'transparent' terminology.<br />
::: But I had a bit of hard time compressing it all into short text. The issue was S-R device, which doesn't have a 'data' input, ''or'' a clock, and is not (strictly speaking) 'transparent'! It's too primitive! And the J-K flop, which doesn't have a data input, didn't help! Eventually I resorted to saying 'flops are now so-and-so, everything else is latches'! [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 18:10, 13 March 2018 (CET)<br />
<br />
: Looks pretty good now! [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 09:24, 15 March 2018 (CET)</div>Torhttps://gunkies.org/w/index.php?title=Talk:Latch&diff=15793Talk:Latch2018-03-12T08:36:29Z<p>Tor: flip-flops != latches (not all the time at least)</p>
<hr />
<div>My digital design friends tell me there's a distinction between latches and flip-flops. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
:Your friends are right. Wikipedia uses the confusing 'a flip-flop or latch is..', which is easy to interpret to mean that 'latch' is just another word for 'flip-flop', which is not what is meant. There is a distinction, although there's overlap (b/c there are different types of latches). And when I design something I think of latches and flip-flops as entirely different things (e.g. flip-flops to divide or fix clock signals, latches to buffer/hold data). (Here's a web page which talks about flip-flops vs latches): http://www.electronicsteacher.com/computer-architectures/digital-circuits/flip-flops.php [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 09:35, 12 March 2018 (CET)</div>Torhttps://gunkies.org/w/index.php?title=Help_talk:Categories&diff=15754Help talk:Categories2018-02-23T08:21:54Z<p>Tor: (format)</p>
<hr />
<div>==Peripherals/Devices==<br />
<br />
Hi, I'm getting set to create categories for PDP-10 and PDP-11 peripherals/devices (I've been doing a lot of organization on the CPU/system/etc end of things, and have that in pretty good shape now). Which word would be better to use, if you have an opinion - 'peripherals' or 'devices'? We current do already have a [[:Category:Peripherals]], so maybe go with that? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 16:05, 19 February 2018 (CET)<br />
<br />
: I tend to go with 'peripherals' in this case. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
OK; I'll get started on that. And also, I think we should have a category for all DEC stuff - just plain 'DEC', or 'Digital Equipment Corporation'?<br />
<br />
: DEC is consistent with the other labels. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: I'll have to ponder the DEC category name. It feels a bit 'thin', just plain 'DEC'. I don't mind the acronym 'DEC' as ''part'' of the name of sub-categories (it prevents them getting ridiculously long); but for the main category, it feels too informal. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 20:28, 19 February 2018 (CET)<br />
<br />
==Other cats==<br />
<br />
BTW, I added some thoughts about cats to [[Help:Introduction to Categories#Current organization]] - does that seem like a good system? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 19:44, 19 February 2018 (CET)<br />
<br />
: There's one problem with the taxonomy. Not all PDP-10 (or 11 or 8) operating systems are DEC operating system. At least not in the sense "operating systems made by DEC". [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: I'm happy to subdivide it (them, actually) into two other categories; any snappy ideas for the name(s)? I suppose we could have 'DEC Operating Systems' and 'Non-DEC Operating Systems'; each of which is further divided into, e.g., 'DEC PDP-11 Operating Systems' and 'Non-DEC PDP-11 Operating Systems'. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 20:28, 19 February 2018 (CET)<br />
<br />
::: That'll potentially be a lot of category pages to create! Can't a page be in both the DEC Operating Systems category, and the PDP-10 Operating Systems category? [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: Sorry, I'm not sure I'm seeing your concept; a concrete example would help. What pages (and sub-categories) would go in 'DEC Operating Systems' category, and what in the 'PDP-10 Operating Systems'? ITS would clearly be in the latter, but would it be in any others? What super-category would the 'PDP-10 Operating Systems' category be in? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]])<br />
<br />
::: TOPS-10 would be in both 'DEC OSes' and 'PDP-10 OSes'. OS/8 would be in both 'DEC OSes' and 'PDP-8 OSes'. ITS would be in just 'PDP-10 OSes'. Unix V7 would be in just 'PDP-11 OSes'. 'DEC OSes', 'PDP-8 OSes', 'PDP-10 OSes', and 'PDP-11 OSes' would all be in 'Operating Systems'.<br />
::: This way, there would be N+M categories (for N manufacturers and M architectures), rather than NxM. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: Ah, got it.<br />
:: The only potential downside to that approach is that there's no easy way to find non-DEC OS's, other than going through all the per-machine OS categories - for which having a 'OS's for DEC machines' super-cat would be mildly helpful, as opposed to just putting them in 'OS's'.<br />
:: Ah, how about a single 'non-DEC OS's for DEC machines' category? (Although it would need a snappier name than that - can't come up with one quickly.) So TOPS-10 would be in 'DEC OS's' and 'PDP-10 OS's', Unix V6 would be in 'non-DEC OS's' and 'PDP-11 OS's', etc.<br />
:: That's only one more category, and it would help find the non-DEC OS's easily; and no PDP OS article would have more than two category tags. (I'm going to put off for now the issue of OS's like MUMPS, which started out as a private venture, and which eventully wound up as a DEC product! :-)<br />
:: BTW, actually my orginal proposal was not N*M; it was Sum(2*Mi), instead of Sum(Mi), where Mi is the number of architecture for manufacturer i, out of N. But still, you're right, it would have been a lot! Twice as many as the other way... [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:04, 20 February 2018 (CET)<br />
<br />
:: Now that I see the 'Non-DEC Operating Systems' Category, it does look quite strange.. on the surface of it it would cover everything that's not DEC or for DEC, i.e. most operating systems (and then a visitor would wonder why it's named that way, too.) But then it's definitely for DEC, just not made by DEC. It gets a bit confusing. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 09:20, 23 February 2018 (CET)</div>Torhttps://gunkies.org/w/index.php?title=Help_talk:Categories&diff=15753Help talk:Categories2018-02-23T08:21:20Z<p>Tor: 'non-dec OS'..</p>
<hr />
<div>==Peripherals/Devices==<br />
<br />
Hi, I'm getting set to create categories for PDP-10 and PDP-11 peripherals/devices (I've been doing a lot of organization on the CPU/system/etc end of things, and have that in pretty good shape now). Which word would be better to use, if you have an opinion - 'peripherals' or 'devices'? We current do already have a [[:Category:Peripherals]], so maybe go with that? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 16:05, 19 February 2018 (CET)<br />
<br />
: I tend to go with 'peripherals' in this case. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
OK; I'll get started on that. And also, I think we should have a category for all DEC stuff - just plain 'DEC', or 'Digital Equipment Corporation'?<br />
<br />
: DEC is consistent with the other labels. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: I'll have to ponder the DEC category name. It feels a bit 'thin', just plain 'DEC'. I don't mind the acronym 'DEC' as ''part'' of the name of sub-categories (it prevents them getting ridiculously long); but for the main category, it feels too informal. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 20:28, 19 February 2018 (CET)<br />
<br />
==Other cats==<br />
<br />
BTW, I added some thoughts about cats to [[Help:Introduction to Categories#Current organization]] - does that seem like a good system? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 19:44, 19 February 2018 (CET)<br />
<br />
: There's one problem with the taxonomy. Not all PDP-10 (or 11 or 8) operating systems are DEC operating system. At least not in the sense "operating systems made by DEC". [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: I'm happy to subdivide it (them, actually) into two other categories; any snappy ideas for the name(s)? I suppose we could have 'DEC Operating Systems' and 'Non-DEC Operating Systems'; each of which is further divided into, e.g., 'DEC PDP-11 Operating Systems' and 'Non-DEC PDP-11 Operating Systems'. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 20:28, 19 February 2018 (CET)<br />
<br />
::: That'll potentially be a lot of category pages to create! Can't a page be in both the DEC Operating Systems category, and the PDP-10 Operating Systems category? [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: Sorry, I'm not sure I'm seeing your concept; a concrete example would help. What pages (and sub-categories) would go in 'DEC Operating Systems' category, and what in the 'PDP-10 Operating Systems'? ITS would clearly be in the latter, but would it be in any others? What super-category would the 'PDP-10 Operating Systems' category be in? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]])<br />
<br />
::: TOPS-10 would be in both 'DEC OSes' and 'PDP-10 OSes'. OS/8 would be in both 'DEC OSes' and 'PDP-8 OSes'. ITS would be in just 'PDP-10 OSes'. Unix V7 would be in just 'PDP-11 OSes'. 'DEC OSes', 'PDP-8 OSes', 'PDP-10 OSes', and 'PDP-11 OSes' would all be in 'Operating Systems'.<br />
::: This way, there would be N+M categories (for N manufacturers and M architectures), rather than NxM. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]])<br />
<br />
:: Ah, got it.<br />
:: The only potential downside to that approach is that there's no easy way to find non-DEC OS's, other than going through all the per-machine OS categories - for which having a 'OS's for DEC machines' super-cat would be mildly helpful, as opposed to just putting them in 'OS's'.<br />
:: Ah, how about a single 'non-DEC OS's for DEC machines' category? (Although it would need a snappier name than that - can't come up with one quickly.) So TOPS-10 would be in 'DEC OS's' and 'PDP-10 OS's', Unix V6 would be in 'non-DEC OS's' and 'PDP-11 OS's', etc.<br />
:: That's only one more category, and it would help find the non-DEC OS's easily; and no PDP OS article would have more than two category tags. (I'm going to put off for now the issue of OS's like MUMPS, which started out as a private venture, and which eventully wound up as a DEC product! :-)<br />
:: BTW, actually my orginal proposal was not N*M; it was Sum(2*Mi), instead of Sum(Mi), where Mi is the number of architecture for manufacturer i, out of N. But still, you're right, it would have been a lot! Twice as many as the other way... [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:04, 20 February 2018 (CET)<br />
:: Now that I see the 'Non-DEC Operating Systems' Category, it does look quite strange.. on the surface of it it would cover everything that's not DEC or for DEC, i.e. most operating systems (and then a visitor would wonder why it's named that way, too.) But then it's definitely for DEC, just not made by DEC. It gets a bit confusing. [[User:Tor|Tor]] ([[User talk:Tor|talk]]) 09:20, 23 February 2018 (CET)</div>Torhttps://gunkies.org/w/index.php?title=PDP-10&diff=15219PDP-102018-01-16T12:52:07Z<p>Tor: Added missing space</p>
<hr />
<div>[[Image:PDP-10 1090.jpg|300px|rightt|thumb|A PDP-10 1090]]<br />
<br />
A series of large, 36-bit [[mainframe]]-like systems built by [[Digital Equipment Corporation|DEC]]; they were basically a re-implementation of the earlier [[PDP-6]] architecture, whose engineering had been a failure. (The machines were so similar at the programming level that PDP-6 code could run on a PDP-10.)<br />
<br />
DEC sold 4 different generations of PDP-10 processors: the [[KA10]], the [[KI10]], the [[KL10]], and the [[KS10]]. The first three were marketed as the [[DECsystem-10]], running the [[TOPS-10]] [[operating system]]; the third was also sold as the [[DECSYSTEM-20]], running [[TOPS-20]]. (The varying capitalization was the result of a trademark infringment suit.)<br />
<br />
Two other very important operating systems also ran on PDP-10's: MIT's [[Incompatible Timesharing System|ITS]] (a very advanced system, from whence came [[EMACS]], and much more besides), and [[TENEX]], which DEC later turned into TOPS-20.<br />
<br />
[[Image:DECsystem-10 ad.jpg|150px|left|thumb|PDP-10 ad]]<br />
<br />
PDP-10s were very important machines on the early Internet, being one of the few (relatively!) cheaply available machines which could run a full NCP and later TCP/IP stack as a multi-user environment at the time.<br />
<br />
They still have a large following today. There are several good [[simulator]]s available, notably [[SIMH]] and [[KLH10]].<br />
<br />
==Commercial clones==<br />
<br />
* Xerox PARC: [[MAXC]]<br />
* [[Foonly]]: [[Foonly F-1|F-1]], F2, F3, F4, F5 (unfinished)<br />
* Systems Concepts: SC-30M, SC-40<br />
* Tymshare: System 26, System 26KL.<br />
* CompuServe: JRG-1 (unfinished)<br />
* XKL: TOAD-1, TOAD-2<br />
<br />
==Hobbyist recreations==<br />
<br />
* David Conroy: [http://www.fpgaretrocomputing.org/pdp10x/ PDP-10/X]<br />
* Neil Franklin: [http://neil.franklin.ch/Projects/PDP-10/ (unfinished)]<br />
* Rob Doyle: [https://github.com/KS10FPGA/KS10FPGA KS10 FPGA]<br />
* David Bridgham: [http://pdp10.froghouse.org/ KV10 (in progress)]<br />
* Angelo Papenhoff: [https://github.com/aap/pdp6 FPDPGA-6]<br />
<br />
==Software simulators==<br />
<br />
* S W Galley: [http://dl.acm.org/citation.cfm?id=803947 virtual machine PDP-10]<br />
* Megan Gentry: sim10<br />
* Stu Grossman: [http://github.com/brouhaha/kx10 kx10]<br />
* Ken Harrenstien: [http://github.com/PDP-10/klh10 KLH10]<br />
* Eric Smith: (unfinished)<br />
* Daniel Seagraves: e10<br />
* Tim Stark: [http://ts10.sourceforge.net/ ts10], [http://github.com/fsword7/mse MSE]<br />
* Bob Supnik: KS10 simulator for [http://github.com/simh/simh SIMH].<br />
* Richard Cornwell: KA10 and KI10 simulators for SIMH<br />
* Angelo Papenhoff: [http://github.com/aap/pdp6 PDP-6 simulator]<br />
* Bruce Baumgart: [http://www.saildart.org/j5/index.html WAITS reenactment]<br />
* Jeff Parsons: [http://github.com/jeffpar/pcjs PCjs]<br />
* Mark Garrett: [http://github.com/gcsgithub/titan TITAN]<br />
<br />
==External links==<br />
<br />
* [http://www.avanthar.com/healyzh/decemulation/pdp10emu.html The DEC PDP-10 Emulation Webpage]<br />
* [http://pdp10.nocrew.org/gcc/ PDP-10 support for GCC]<br />
<br />
[[Category:Computers]]<br />
[[Category:DEC Computer Systems]]</div>Torhttps://gunkies.org/w/index.php?title=OS/2&diff=14862OS/22017-12-04T11:03:30Z<p>Tor: Minor spellfix</p>
<hr />
<div>[[Image:OS2 1.x neonlogo.jpg|thumb|150px|right|OS/2's early logo]]<br />
<br />
OS/2 started as a collaborative effort between [[IBM]] and [[Microsoft]] to put together the next generation [[operating system]] for the [[IBM AT]] and [[PS/2]] machines. <br />
<br />
Microsoft, famous for hedging bets, started the [[Windows]] project around the same time, as a low cost entry interface with rudimentary (cooperative) [[multitasking]].<br />
<br />
Needless to say, Microsoft wanted to target the [[i386]] processor, and work on 32-bit software, while IBM wanted to deliver to the IBM AT customers it had sold to, and demanded the [[i286]] 16-bit version. Someone at IBM even got the idea that the development tools should be a revenue stream, and needless to say, the $3,000 SDK was '''NOT''' a big seller. Instead the industry worked around OS/2, and developed [[DOS Extenders]] technology, and Microsoft practically gave away the Windows SDK, allowed for OEM customizations, and famously released the [[QuickC for Windows]] product.<br />
<br />
Microsoft leapt at the chance to formalize DOS extenders into [[DPMI]], and use it in Windows, cementing OS/2's 1.x inability to run DPMI programs. Microsoft was also upset that IBM locked them out of the graphical components of the OS, and that OS/2 worked BACKWARDS compared to Windows... the 0/0 in the screen coordinates is the bottom right, while everywhere else it's the top left..<br />
<br />
There is a great writeup on the divorce on google's [http://groups.google.com/group/comp.os.ms-windows.misc/msg/d710490b745d5e5e usenet archive], or locally here [[Gordon Letwin OS/2 usenet post]]. There is also a perspective from an Autodesk programmer available [http://www.sibbald.com/windows/windows01.html here].<br />
<br />
== Versions ==<br />
<br />
=== 16 bit versions ===<br />
All of these versions require an [[i286]] cpu, and an [[IBM AT]], or [[PS/2]] compatible computer. All of the 16bit versions were limited to a SINGLE MS-DOS compatibility box, greatly reducing the overall usefulness of OS/2 with the ever increasing prevalence of [[MS-DOS]] based applications. At the same time, the 16bit version supported swapping, DLL's, threads and preemptive multitasking. There was an excellent overview of the original OS/2's in the book [http://ebooks.znu.edu.ua/files/comp_books1/cd0/isos2.txt Inside OS/2].<br />
<br />
*1.0<br />
[[Image:Microsoft OS2 1.0 - Heathkit Zenith OEM.jpg|thumb|right|150px|OS/2 1.0]]<br />
This version was all textmode, and had an interface that was inspired from TopView. Although it could multitask, most people didn't realize it, as all programs ran full screen. It ran in 286 protected mode, except for the single "DOS" mode session. As a result all device drivers for OS/2 had to be able to run in real & protected mode. Until 1.3 all versions were released by OEM hardware vendors (Compaq, Zenith etc, along with IBM), this was normal practice for Microsoft at the time.<br />
<br />
The IBM OS/2 1.0 announcement can be read [[IBM OS2 1.0 announcement|here]].<br />
<br />
*1.1<br />
[[Image:IBM OS2 1.1 full package.jpg|thumb|right|150px|OS/2 1.1 full package]]<br />
OS/2 1.1 was released in 1988, and was the first version to include the Presentation Manager. It 'looked' identical to that of [[Windows 2.0]]. IBM OS/2 1.1 included the PM version of Borland Sidekick to fill in the gap of accessories for OS/2. While there was some initial excitement over this version of OS/2, it quickly faded as you had to either buy a new computer with it installed, or jump through OEM channels to get OS/2. Microsoft didn't sell OS'es to end users in the 1980s (This didn't change until OS/2 1.3, MS-DOS 5 & Windows NT 3.1). Version 1.1c was 386 aware, in that it could use the 80386's ability to quickly & easily transition from real & protected modes, bypassing the triple fault method of the 286. <br />
<br />
*1.2<br />
[[Image:IBM OS2 1.2 box cover.jpg|thumb|right|150px|OS/2 1.2 box]]<br />
I think this version was released in September of 1988. This release was significant with the inclusion of the HPFS filesystem. HPFS was significantly faster then the aging FAT filesystem as it placed its tables in the middle of the disk, and it allowed for larger filesystems, long filenames and extended attributes. A later service pack allowed for 386 and above CPUs to use the 386 method of switching between real & protected mode, allowing it to operate significantly faster (1.2c). From what I understand this was the last version of OS/2 that included direct involvement from Microsoft.<br />
<br />
OS/2 1.2 from IBM included the 'standard' edition, along with the EE or extended edition. The EE edition included basic communications capability (x.25, rs232 terminal), and a SQL database.<br />
<br />
[[InfoWorld]] included an excellent review of OS/2 1.2 [http://books.google.com/books?id=1DsEAAAAMBAJ&lpg=PT79&dq=%22OS%2F2%201.2%22&pg=PT66#v=onepage&q=%22OS/2%201.2%22&f=false|here].<br />
<br />
*1.21<br />
I think this version was a Microsoft exclusive, and the final version that they were directly involved in.<br />
<br />
*1.3<br />
[[Image:Microsoft OS2 front.JPG|thumb|right|150px|Microsoft OS/2 1.3]]<br />
This was the last version of the 16 bit OS/2 family. The 1.3 user interface resembled that of [[Windows 3.0]]. Microsoft did include a 32bit HPFS driver in their Lan Manager package which allowed for the fastest HPFS implementation prior to OS/2 2.0 & Windows NT 3.1 <br />
<br />
Around this time, Microsoft had released a beta of the WLO or Windows library for OS/2. The beta included a copy of all of the applettes & games from Windows 3.0 that could run in the Presentation Manager of OS/2. These libraries were also used to deliver the last versions of Microsoft Word & Excel for OS/2. Microsoft had planned on releasing these libraries to allow people to easily port their Windows applications to OS/2, but the rift had happened right before that date, so the beta (which is easy to find) was the only thing released. You can read more about it [http://pages.prodigy.net/michaln/history/pr/wlo.html here].<br />
<br />
Additionally, market penetration and OEM interest in OS/2 had dwindled so quickly by this point that Microsoft had decided to do a retail version of OS/2 (pictured to the right) to support its new [[Microsoft SQL Server]] product. Windows NT on the i386 platform included support for 16bit OS/2 applications, namely for the Microsoft Languages (Fortran/Assembler & C) and SQL Server. Since they all were text mode, they would run unmodified up through Windows 2000.<br />
<br />
=== 32bit versions ===<br />
All of these versions require an [[i386]] SX or better CPU running on either an [[IBM AT]] compatible motherboard, or the [[IBM PS/2]] 32bit machines. <br />
<br />
==== OS/2 2.x ====<br />
<br />
*2.0 LA (LA Internal revision 6.167 91-10-08)<br />
[[Image:IBM OS2 2.0 LA cover.jpg|150px|thumb|right|OS/2 2.0 LA]]<br />
This was the first 32bit version. It was released after the IBM/Microsoft divorce, and was strictly an IBM release. There was no seamless Windows in this release, and Win-OS/2 only featured Windows 3.0a in standard mode.<br />
<br />
The LA version does not include 'seamless' WIN-OS/2 sessions, and much like OS/2 2.0 GA it does not support Windows's 386 enhanced mode. While it is possible to launch Windows in a Window the display corrupts and it is exceptionally unstable.<br />
<br />
Attempting to use any production GA drivers will result in a kernel crash.<br />
<br />
*2.0 GA (GA Internal revision 6.307 92-03-01)<br />
[[Image:IBM OS2 2.0 cover.jpg|150px|thumb|right|OS/2 2.0]]<br />
This release included [[Windows 3.0]] for use in Win OS/2. At the time of the release the Presentation Managers graphic drivers were still 16 bit, although a later service pack was released which included 32bit drivers. It's interesting to note that OS/2's market share was so low at this time, that OS/2 2.0 included the ability to load older 16bit device drivers as the kernel was still a hybrid 16bit/32bit kernel.<br />
<br />
The GUI had radically changed from 1.3 to 2.0 as it now included the Workplace Shell, a full OO GUI. Many people considered WPS to be 'the' killer application at the time, as Windows still had the program manager.<br />
<br />
The new Presentation Manager replacement, Workplace Shell, included a deal with Commodore for the "look and feel" of [[AmigaDOS]], and as part of the deal, Commodore picked up a license for [[REXX]] into its products as first seen by AmigaDOS 2.0 .<br />
<br />
The default syslevel for OS/2 2.0 is XR02000. The last known service pack for OS/2 2.0 brings it up to XR06100. The XR06100 update also installs the OS/2 32-bit Graphics Engine, XR02010.<br />
<br />
*2.1 (06/1993)<br />
This release brought the Win OS/2 functionality up to [[Windows 3.1]]. From the user standpoint it still looked like 2.0 . OS/2 2.1 also included the multimedia update which would allow for sound effects for almost every conceivable motion. It was very annoying. <br />
<br />
OS/2 2.1 also supported more video cards, more printers, and included support for [[PCMCIA]] and [[APM]], making it acceptable for laptop use.<br />
<br />
The update XR06200 brings OS/2 2.1 up to 2.11 functionality.<br />
<br />
*2.11 (02/1994)<br />
*2.11 SMP (08/1994)<br />
<br />
OS/2 2.11 supported multiple processors, and from a user standpoint it was halfway between 2.11 and Warp. I remember this version being insanely expensive, as it was targeted to the 'server' crowd, IBM had shortsightedly decided end users wouldn't want SMP. While [[Windows NT]] Workstation always supported two physical processors.<br />
<br />
==== OS/2 Warp 3 ====<br />
[[Image:IBM OS2 Warp 3.0 blue spine cover.jpg|150px|thumb|right|OS/2 Warp 3.0 BlueSpine]]<br />
*3.0 (09/1994)<br />
This was the WARP release. At the time this release preempted the [[Windows 95]] release. IBM had done their best to tune OS/2 to run in 4MB of ram on a 386sx cpu. Warp also included the 'bonus pack' which included SLIP/PPP TCP/IP, a dialer application and a word processor & spreadsheet. A simple gopher client & NNTP client were also included.<br />
<br />
IMHO this is where IBM missed the boat, by making TCP/IP difficult to configure, and by not including LAN drivers (that was WARP CONNECT), while [[Windows 95]] & [[Windows_NT#Windows_NT_3.5|NT 3.5]] both included SLIP/PPP *AND* lan drivers.<br />
<br />
I *THINK* it was this release that included the ability to run [[Win32s]], which was a boon for Netscape & Mosaic.<br />
<br />
*3.01 (1995)<br />
OS/2 Warp with Win-OS/2<br />
<br />
*3.02 (1995)<br />
OS/2 Warp Connect<br />
OS/2 Warp Server <br />
OS/2 Warp Server Advanced<br />
<br />
*3.05 (01/1996)<br />
OS/2 Warp Server Advanced for SMP<br />
<br />
==== OS/2 Warp 4 ====<br />
[[Image:logo-warp.gif|thumb|150px|right|OS/2 Warp Logo]]<br />
*4.0<br />
OS/2 4.0 included both Java and Netscape in this release. Sadly IBM had still not 'gotten it' with regards to TCP/IP and insisted on a 'connect' version of 4.0 that included the LAN drivers. 4.0 also included the ability to install servicepacks online.<br />
<br />
*4.01<br />
Workspace on-Demand 1.0 (WSOD)<br />
Workspace on-Demand 2.0<br />
<br />
*4.5<br />
IBM OS/2 Warp Server for e-business<br />
Fixpak >=13 applied to OS/2 Warp 4 or WSOD<br />
<br />
*4.51<br />
Aurora Convenience Package 1 (ACP1), Merlin Convenience Package 1 (MCP1)<br />
<br />
*4.52<br />
Aurora Convenience Package 2 (ACP2), Merlin Convenience Package 2 (MCP2)<br />
<br />
This was the last IBM release of OS/2.<br />
<br />
== PowerPC port ==<br />
<br />
It's a deep secret that the PowerPC version ended up sucking up so much time, effort and money from IBM's development of OS/2, that it ended up bleeding the group dry, and without a product to ship. IMHO it's a shame, as partnered with the [[PowerPC 615]] CPU it could have revelutionalized the industry.. But then back then everyone expected Intel to hit a wall, IBM had the 615 in their pocket which was a PowerPC CPU which was pin compatible with a 486, and could run x86 code (albeit slow..) and then switch to PPC mode. The company [[NexGen]] opened up everyone's eyes that a specialized [[RISC]] cpu could in fact run x86 instructions much quicker then a real Intel cpu... This opened the way to the Pentium CPUs and effectivly killed the [[RISC]] revolution.<br />
<br />
There is a most excellent review to be found [http://www.os2museum.com/wp/?page_id=30 here] that also includes screenshots.<br />
<br />
== Running OS/2 under an Emulator ==<br />
<br />
=== 16 bit versions ===<br />
The latest version of VirtualBOX from SUN is capable of installing & Running the 1.x version of OS/2 provided that they have had a [[Patching OS/2 for fast machines|timing patch]] in place. I have found that the 'best' profile is to use the "Oracle Solaris 10 5/09 and earlier" profile. Be sure to limit the VM to 16MB of ram, add both a floppy drive, and a serial port, otherwise you'll have difficulty booting.<br />
<br />
==== OS/2 1.0 ====<br />
[[Image:OS2 1.0.png|thumb|200px|right|OS/2 1.0 under VirtualBOX]]<br />
*First version from November 1987 - no success.<br />
*There is a later 1987 version that does run, it may be an OS/2 1.1 beta?<br />
It seems the 1.0 IBM kernels rely on 286 triple faults and Virtual Box does not emulate it. However there is an early Microsoft OS/2 1.1 beta that uses the 386 method of switching to protected mode, and will run on modern machines (as long as the speed fix in place.).<br />
<br />
==== OS/2 1.1 ====<br />
[[Image:OS2 1.1.jpg|thumb|200px|right|OS/2 1.1 under Bochs]]<br />
There are some hacks available to run OS/2 1.1 under [[VMWare]], and [[Bochs]]. There are some [[Patching OS/2 for fast machines|binary patches]] you can do to allow old 1.x OS/2 on fast machines. Even without an emulator you'd need to do this on anything in pentium II speeds.. With the speed stuff in hand, you can now run 1.1 on VirtualBOX as it's floppy driver now works with OS/2 to detect speed/density correctly.<br />
<br />
OS/2 1.1c is the first version that supports the 386's method of switching from [[protected mode]] to [[real mode]]. Prior to level c of OS/2 1.1 the method was a 286 [[tripple fault]], which almost all emulators do not fully support, or it may simply be in the IBM versions. I'm still not sure as early versions of OS/2 are hard to track down.<br />
<br />
==== OS/2 1.2 ====<br />
[[Image:OS2 1.2.png|thumb|200px|right|OS/2 1.2 on VirtualBOX]]<br />
With the above hex edits in place, OS/2 1.2 installs somewhat ok. The big 'issue' I found was that the IBM version of OS/2 1.2 does not support PS/2 mice on the IBM AT computers. However you can take the PS/2 driver from OS/2 1.3 and use it.<br />
<br />
==== OS/2 1.21 ====<br />
[[Image:OS2 1.21.png|thumb|200px|right|OS/2 1.21 on VirtualBOX]]<br />
Again there is an issue of no included working mice drivers, and poaching the driver from 1.3 works fine.<br />
<br />
==== OS/2 1.3 ====<br />
[[Image:Os213.png|thumb|200px|right|OS/2 1.3 under Virtual PC.]]<br />
The only version of OS/2 1.x that can run under an emulator without any hacks applied. The three problems that you will run into is emulated floppy disks are too quick, and other various timing anomalies that will lead to a COUNTRY.SYS failure.<br />
<br />
The method for install requires you to install OS/2 1.3 on a physical machine, update it, then make a whole disk image of it. I can confirm that OS/2 1.3 runs under [[Virtual PC 2007]] just fine. While it does have some issues with the floppy (it'll throw an error reading the floppy every time you put in a new disk) it will allow you to use the floppy. This makes OS/2 1.3 the easiest to install programs into.<br />
<br />
At the moment, none of the 1.x versions will install under emulation, they all must be imaged from a physical machine.<br />
<br />
* [http://support.microsoft.com/kb/102628/en-us Microsoft OS/2 1.3 HCL]<br />
<br />
=== 32 bit versions ===<br />
<br />
==== OS/2 2.0 ====<br />
===== LA =====<br />
[[Image:OS2 2.0LA in VirtualBOX.png|thumb|200px|right|OS/2 2.0 LA running under VirtualBOX.]]<br />
<br />
At the moment the only way I've been able to install OS/2 2.0 LA on Virtual PC/VirtualBOX is to 'cheat' and use the install & disk 1 from OS/2 2.0 GA, and replace the following files on disk1, from LA's disk 1:<br />
<br />
*CMD.EXE<br />
*HARDERR.EXE<br />
*SYSINST1.EXE<br />
*SYSINST2.EXE<br />
*FDISK.COM<br />
*SYSLEVEL.OS2<br />
*DISK.NUM<br />
<br />
Then boot from GA's install, then use it's disk 1. Then use LA's disk from that point onward, and it'll install.<br />
<br />
===== GA =====<br />
[[Image:OS2 2.0 in Qemu.png|thumb|200px|right|OS/2 2.0 running under Qemu.]]<br />
[[Image:Vpc5x os2v20 wps.png|thumb|200px|right|OS/2 2.0 running under Virtual PC 5 for OS/2]]<br />
<br />
I've run OS/2 2.0 & 4.0 under Virtual PC, and Qemu... I guess it really comes down to if you move disk images around between various hardware platforms. Anything prior to version 3.0 should be run in an ISA emulation mode (-M isa) to let the peripherals work in a more compatible manner... Virtual PC 2007 works fine as well, and includes extensions that allow the guest VM to use drives that are installed on the host pc. I've heard that VMWare has given up the compatibility mode fixes.<br />
<br />
I'm now running OS/2 2.0 under VMWare Player, and it seems to be running OK. I've found one issue with networking, the Set PermaNet Server feature must be set to TRUE, under the LAPS configuration tool.<br />
<br />
*[[Qemu]]<br />
*[[Virtual PC 2007]]<br />
<br />
==== OS/2 2.1 ====<br />
<br />
Adds 32-bit Graphics Subsystem. S3 display drivers are usable under Virtual PC.<br />
<br />
* [http://drivers.s3graphics.com/en/download/drivers/legacy/Trio64V_765/eng30316.zip eng30316.zip] S3 drivers<br />
<br />
==== OS/2 Warp 3 ====<br />
*For installation with XDF diskettes, Virtual PC works, however you'll need to use the floppy drivers & xdf driver from OS/2 4.0<br />
*You should first apply the latest fixpak (XRGW040) to use Guest Additions from Virtual PC.<br />
*After this also GRADD device drivers (from Additions, IBM or Scitech SNAP) can be installed.<br />
<br />
==== OS/2 Warp 4 ====<br />
<br />
Fixpak 5 or better 9 should be applied for GRADD.<br />
<br />
==== OS/2 Warp Server for e-business (4.5) ====<br />
<br />
Works with Virtual PC.<br />
<br />
==== OS/2 Convenience Package 1 (4.51) ====<br />
<br />
Works with Virtual PC.<br />
<br />
==== OS/2 Convenience Package 2 (4.52) ====<br />
<br />
Works with Virtual PC and VirtualBox.<br />
<br />
== Popular Applications ==<br />
<br />
=== Autodesk ===<br />
* AutoCad <br />
<br />
=== IBM ===<br />
* IBM DisplayWrite5/2<br />
<br />
=== Informix ===<br />
* Wingz<br />
<br />
=== Lotus ===<br />
* Lotus 1-2-3/G<br />
* Lotus Freelance Graphics<br />
<br />
=== Micrografx ===<br />
* Micrografx Designer 3.0<br />
* Micrografx Draw for OS/2<br />
<br />
=== Microsoft ===<br />
Microsoft did port over a bunch of their languages, along with a few applications, namely:<br />
<br />
* Languages<br />
** Microsoft MASM 6.0<br />
** Microsoft C 5.1, 6.0<br />
** Microsoft COBOL PDS<br />
** Microsoft Basic PDS 7.0, 7.1<br />
** [[Microsoft Fortran]]<br />
* Productivity<br />
** Microsoft Word 5.0, 5.5<br />
** Microsoft Word (for Presentation Manager) 1.1<br />
** Microsoft Excel 2.2, 3.0<br />
<br />
All of these products are 16 bit only. While there was two pre-releases of MS OS/2 2.0 that included CL386 & MASM386 none of these are fully out in the wild so I'm not sure if they could produce programs that would run on the IBM OS/2 2.0 GA and beyond.<br />
<br />
=== StarDivision ===<br />
* StarWriter 2.0 for OS/2<br />
* StarOffice 3.0<br />
<br />
=== Watcom ===<br />
* Watcom C / C++<br />
* Watcom Fortran 77<br />
* Watcom SQL<br />
<br />
[[Category:Operating Systems]]</div>Torhttps://gunkies.org/w/index.php?title=Talk:DOS&diff=14827Talk:DOS2017-11-21T07:24:11Z<p>Tor: Definitely unintended change</p>
<hr />
<div>Sorry, no idea how that happened. I even did a preview and it was OK, but something got messed up after that, clearly.[[User:Tor|Tor]] ([[User talk:Tor|talk]]) 08:24, 21 November 2017 (CET)</div>Torhttps://gunkies.org/w/index.php?title=DOS&diff=14825DOS2017-11-20T08:10:53Z<p>Tor: Before MS, the DOS we knew was Apple's DOS..</p>
<hr />
<div>'''DOS''' is an acronym for '[[Disk]] [[Operating System]]'. There have been many system which used this name, including:<br />
<br />
* [[MS-DOS]] from [[Microsoft]]<br />
* [[Apple DOS]] from [[Apple]]<br />
* An early OS for the [[System/360]]<br />
<br />
{{disambiguation}}</div>Tor