The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: fair-tuhs@netbsd.org (Erik E. Fair)
Subject: [TUHS] v6 RK05 bootloader question
Date: Wed, 30 Dec 2015 10:06:57 -0800	[thread overview]
Message-ID: <22302.1451498817@cesium.clock.org> (raw)
In-Reply-To: <568387EF.6010407@gmail.com>

Related minicomputer booting story:

I cut my computing teeth on the PDP-11's competitor, the Data General NOVA minicomputer. Edson de Castro supposedly proposed the architecture to Ken Olson, and when Ken said "no", Edson left DEC and founded DG - much as we've seen companies in Silicon Valley beget each other when some smart engineers get annoyed with their bosses. Fairchild begat Intel and AMD, Cisco begat Juniper, et alia.

Rather than memory-mapped I/O, the NOVA had I/O instructions, and six bits of device codes. Every interrupt handler I saw for the NOVA ended in the same self-modifying code sequence: if your OS doesn't handle the device that has interrupted, put the device code into an interrupt dismiss instruction in the next location, fall into it to shut the device up, and return from interrupt.

Booting the NOVA (provided you knew the device code of the device you wanted to boot from) was simplicity itself:

Power everything up.

Mount the media (disk, tape) including any positioning as required

Put I/O device online (frequently an explicit act involving a switch)

Set the CPU front panel switches to the 6-bit device code

Hit in order the momentary contact switches: STOP, RESET, START

The CPU would read the device code from the front panel switches, read the first record (of arbitrary size) from the device into RAM starting at location 0, and set the program counter (PC) to zero and begin execution of whatever was read in from the I/O device.

Disks had a primary booter in the first 512 bytes (so, 256 16-bit instructions & data) which would read in the rest of whatever OS you were booting. Necessarily, that booter needed to know where to load the OS from on disk.

Since "page zero" of the NOVA (the first 256 words of RAM) was a critical resource (direct reference from anywhere else in RAM rather than using space-expensive indirect addressing, plus, there were some autoincrement and autodecrement locations - reading them caused the stored value to change - handy for counters and pointers), the booter usually got overwritten.

Booting an OS from tape was easier because of the arbitrary record size: you could fit a whole tape OS into a single record and start running immediately - no intermediate boot code required. OTOH, tape OSes were really slow when all their files were on very slow tape drives (if you were lucky, you had vacuum column tape drives - faster for positioning).

Life got lots easier when PROMs got big & cheap enough for on-board firmware like IEEE 1275 (OpenBoot/Open Firmware, a formalization of Sun's forth-based firmware).

So far as I know, Unix (DG/UX) didn't come to DG until the Eclipse MV ("Eagle") 32-bit computer of literary fame.

	ancient history,

	Erik <fair at netbsd.org>



  reply	other threads:[~2015-12-30 18:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-27 20:32 Norman Wilson
2015-12-29 20:55 ` Will Senn
2015-12-29 21:37   ` Ronald Natalie
2015-12-30  7:14   ` Wolfgang Helbig
2015-12-30  7:29     ` Will Senn
2015-12-30 18:06       ` Erik E. Fair [this message]
2015-12-30 18:33         ` John Cowan
2015-12-31  8:06       ` Wolfgang Helbig
  -- strict thread matches above, loose matches on Subject: below --
2015-12-31 13:45 Noel Chiappa
2015-12-26 18:34 Will Senn
2015-12-26 19:15 ` Ronald Natalie
2015-12-26 19:26 ` Ronald Natalie
2015-12-26 20:34   ` Will Senn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=22302.1451498817@cesium.clock.org \
    --to=fair-tuhs@netbsd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).