Alternate Reality -- 33209 (pt. 2, summer 1981)

***** Alternate Reality Warning *****

So, for whatever reason, you are reading my fantasies about an alternate world where computer and information technology took a significantly different turn in the early 1980s. Maybe you started with the different Mac OS-9 that could have been. Maybe you have read the beginning of the 33209 technology timeline or the beginning of my story about the the alternate world of the 33209.

At this point, the timeline has gone well beyond what I have published of the 33209 story, but I'm going to keep plotting it out in advance because I've hit a writer's block on my stories. I'm not sure the timeline here will match the story as it plays out, though.

(You're not sure you're interested? How odd. ;-) 

* Summer 1981:  

In late June, Several engineering and CS students from University of Texas's main campus in Austin come to visit, ask to join the group for the rest of summer, and are accepted in. Some of the UT Austin group are undergraduate, some are doing graduate work.

Microware formally begins a top-secret project to re-write OS-9/6809 to use a split stack and merge in other features and concepts from Susumu. TSC begins publicly announced re-writes of both Flex and Uniflex, merging features from Susumu into their systems. Both Microware and TSC begin developing versions of their OSses for the 68000, as well, Microware secretly and TSC publicly. 

IBM and Apple collaborate with the Microware and TSC OS projects, Apple openly about the non-top-secret projects, IBM on the quiet. Various students from the group are invited to Clive and Chapel Hill for short internships, as well.

Bill Mensch and others from Western Design Center request to be permitted to come observe the research group's work, and, after a short discussion among students and sponsors, are allowed to visit.

By the end of June, the students working with TI's new version of the 9900 have gotten their prototypes running most of Susumu, better than the ports to the other processors  except for the 6809, 68000 and 682801.

More games, and more complex games are evidence of the functionality of the language and the system, and, with other applications that the students develop and share, help motivate the students to add support for modularization and versioning (tracking and control) to the language. 

Versioning drives the development of archiving tools, and those who hadn't yet built fast tape hardware for their systems do so, for the mass storage necessary for backup and archiving. Even at a mere 4 kilobaud with one bit per baud, one channel of one side of a forty-five minute cassette yields the storage capacity of several of the floppy diskettes of the time. (Cassettes longer than twenty-three minutes per side tend to stretch more quickly, so the students generally tend not to use 90-minute or two-hour cassettes, except for permanent one-time backups.)

Several of the students develop control hardware for their cassette recorders or cassette tape decks, to allow various levels of computer control.

Apple releases its first models of the Apple IX line running OS-9 on the 6809 in early July, using the 6847 for console video output and the 6845 for optional workstation video output. The BIOS ROM is essentially Susumu.

Also in early July, more magazine articles appear, including rushed articles discussing early versions of Split P and the common code base. Outside the group, Split P generates particular interest at Bell Labs and the parent telephone companies.

And also in early July, Motorola offers the group samples of the upgraded 6809s and 6845s, along with integrated support chips for the upgraded 6845, and most of the group who are not out for the summer volunteer to experiment with the parts in various configurations, including using 6845s with non-Motorola CPUs.  

Within a few days, students have Micro Chroma style computers with the upgraded 6809 running Susumu, using the 68471 for video output. Computers employing the upgraded 6845 take a bit more time to get up and running, but several are running within a week and work begins on improving the code generation for the processor's new features. 

The UT Austin students arrange to move their coursework to the local branch of UT for fall semester so they can continue to engage with the group. 

Bill Mensch arranges with a couple of the UT Austin students to help him design an upgrade to the 6502 that will be optimized for Susumu and Split P, and returns to Mesa. 

And also early in July, a couple of students get interested in text windows on the Univac terminals and starts trying to implement them in their own computers. One of the teachers mentions the Xerox Parc project and graphical user interfaces, and several students begin back-burner on-again, off-again projects trying to figure out how to make such a thing work. Various experiments in pointer devices are attempted. Joysticks are quickly produced, and functional light pens have been produced for the 6845-based displays by mid-July. Various attempts at tracking a pencil writing or sketching on a page are attempted, without much success.

And again, also starting early in July, inspired in part by the dc/bc basic calculator the students have discovered in Unix and in part by Tiny BASIC, a group of students work to re-implement dc on top of the Forth grammar of Split P, and then re-implement bc on top of the C grammar. They then extend both with formatted output and other functions usually found in BASIC. At IBM's request, they add graphics and sound functions, and certain functions useful in a business environment.

Overall, July sees more general steady progress, with Susumu becoming stable on the upgraded version of the 9900, and, towards the end of July, on the other non-Motorola CPUs. 

Discussion of a license for Susumu and the hardware the students are developing reaches a head, and a software license similar to the licenses Berkeley and MIT would later in our reality use for open source software is produced by the students and approved by the college, with help from the sponsoring companies. 

Several hardware design licenses are produced and approved by the college, and the college and the sponsoring companies help arrange for patent research and applications.

More stringent sharing agreements are established for participating in and getting support from the research group, similar to the openBSD project source code requirements and the software freedom terms of the GNU Public License that would develop later in our reality.

Unix on the 6801 remains a bit slow but usable. It is a bit snappier on the 682801, more so on the 6809, even more so on the new version of the 6809. 

Unix is even more usable on the 68000, even though virtual memory management functions on the 68000 can't be handled well without a full memory management unit. Simple bank switching in an address space as large as the 68000's is, of course, not very workable for hardware memory management. And, of course, the students haven't quite figured out virtual memory yet, anyway, even with the help of the UT students and some industry engineers. The complexities of virtual memory were not generally well understood at the time.

Experiments begin with using four of the 68000's address registers as explicit run-time segment registers for Unix, mirroring their use in Susumu, to help work around lack of memory management.

Similar experiments in segmentation on the 8086 do not fare as well, because of the design of the 8086's segmentation, but still proceed. 

In very early August, Motorola publicly announces sampling of an upgrade to the 6809:

• Instruction timings for the 681809 are brought up to par with the 6801 and 682801, and the 681809 is announced as an SOC core with most of the I/O library for the 682801 available, including on-board DMA and bank switching.
  
  
• The 6809 already has direct page mode op-codes for the unary instructions, so that doesn't change. However, the direct page mode has been added to the index post-byte, allowing memory indirection on direct page variables and use of the load effective address (LEA) instruction to calculate the address of direct page variables.
  
  
• A new I/O page register similar to the direct page register is added. Unlike the original DP register, there are no op-codes allocated for I/O page access. Addressing via the IOP register is implemented entirely as a new mode in the index mode post-byte, and access is entirely via arguments to the TFR and EXG instructions.
  
  Since no codes for the IOP are available to the PSH and PUL arguments, pushing and popping IOP require transfer through another register. Since the IO page is considered more of a hardware design constant, this is considered to probably not be a great bottleneck in the use of the IO page.
  
  
• 64 byte spill-fill stack caches are implemented for the S and U stacks, similar to those in the 682801, but with a shorter spill point for S, to cover the larger register set -- 22:34:8.
  
  
• In addition to the stack caches, the initial SOC versions of the 681809 has a half-kilobyte of internal RAM for use as fast direct-page RAM.
  
  
• User and system modes are also implemented similarly to the 682801's. Access to the I/O page register can be prohibited in user mode, generating a new memory access violation interrupt.
  
  
• Likewise, address mode function code outputs are provided, indicating addresses relative to the PC, to the S stack, to the U stack, to the direct page, to the I/O page, to extended (absolute) addresses. Two codes of eight are reserved.
  
  Because the index post-byte provides the ability to specify each of the separations, address space use for the 68109 is much more flexible than for the 682801 when the address space can be determined at compile time.
  
  As with the 682801, utilization of the extra address space is expected to require caution. However, since the index post-byte can specify the mode and therefore the space being used, the 681809 should be able to use the extra space more effectively, as long as the space is known at compile time. Better gains in address space are expected:
  
  
  • code <= 64K
  • general data <= 64K
  • direct page <= 256 of 64K (because of the direct page register)
  • I/O page <= 256 of 64K (because of the I/O page register)
  • parameter stack <= 64K
    
  • return stack <= 64K
    
  
  With the 681809, the actual aggregate active memory space per process is expected to be able to often exceed 128K, but not typically exceed 192K. Again, work with Susumu and Unix bears these expectations out.
   
• The initial SOCs provide bank switching somewhat similar to the 682801's. But the mapping registers have four more bits than those on the 682801, allowing maximum physical addresses of 16M. With the larger maximum address space, bank switching is simplified for the two stack spaces and the direct and IO pages.
  
  
• Small integer hardware division per the 682801 is also provided.
  

Motorola also announces the Micro Chroma 681809 as a prototyping kit for the new processor and the 68471, again with Susumu in ROM.

Improvements in the 68455 over the 6845 are not as easy to quantify, being mostly a redesign to better fit a video cache used for either text or graphics, along with improved support for hardware scrolling and generally improved graphics support. Modes which switch between direct pixel output and character ROM mapped output simplify the support circuitry for designs that include being able to switch between graphics mode and text mode screens. 

New support circuits for the 68455, to simplify the digital-to-analog output conversion for color and gray-scale are announced, along with a companion DRAM refresh/bus arbitration part, the 68831 68835, capable of directly supporting up to 512 kilobytes of video RAM, and a nearly identical 68832 68837 that includes bank switching for the the CPU side, for processors that can't address large address spaces on their own. 

TI announces the 99S200, a version of the 9900 with the local stack frame implemented as entries in a spill-fill cache instead of in general memory. In addition, the 99S200 adds a separate return address stack with spill-fill caching and improved call overhead, and removes the PC entry in the local stack frame. The 99S200 does retain a 512-byte internal bank of fast RAM. SOC parts and libraries are also announced, initial SOCs including both bank switching and DMA. 

TI also announces the 99V180 video display, compatible with the 9918A, but supporting up to double the 9918A's horizontal and vertical resolution, if the external digital-to-analog circuitry and display device are fast enough.

And TI announces the TI-99/16 home computer, utilizing the new processor and video generator in a memory configuration less constricted than the 99/4, with both Susumu and an improved 99/4 BASIC compatible BASIC in ROM. A simplified version of the main circuit board for the new home computer is also made available as a prototyping kit, with only Susumu in the ROM.

Shipments of the 99/16 are expected to begin in plenty of time for Christmas.

A few days later, Motorola pre-announces the 68010 about a half a year ahead of the announcement in our reality, with the improvements seen in our reality:

• The Popek and Goldberg virtualization features, 
• Exception stack frames corrected to allow recovery from bus faults, 
• Three instruction loop mode, 
• Vector base register,
• And improved instruction cycle counts for certain instructions.
  

-- and a little bit more:

• New addressing modes -- 32-bit constant offsets for indexed modes and branches. 
• New 32-bit integer multiplies, with 32-bit and 64-bit results, and new 32-bit by 32-bit divide and 64-bit by 32-bit divide instructions.
• A new system-mode A6 is provided in addition to the system-mode A7, to better support split-stack run-times.
  
• Four spill-fill stack caches are provided, one each for system and user mode A7, and one each for system and user mode A6 as a parameter stack.
  

At the same time as the pre-announcement, samples are made available to the research group, and students dig into it, helping Motorola debug the design in much the way the students helped debug the 99S200. 

A few days later, moving plans up under pressure because of TI's announcement of the 99/16, IBM announces the IBM PC in two models, the Business PC/09 based on the 681809 with bank switching, and the Family PC/88 based on the 8088, both with video based on the original 6845. Both models start at 16K of RAM expandable on the mainboard to 64K. The 640K address space limit we are familiar with is present on both the PC/88 and the PC/09, but the PC/09 adds a second connector for each card slot, similar to the AT bus that would later be used in our world, that allows full 16M addressing, making the boundary mostly irrelevant. Pricing for the both models is comparable, $1500 for the PC/88l, 1525 for the PC/09 model.

Neither comes with disk drives, but disk drives are an option. Both have built-in cassette I/O interface and simple sound generating devices.

Both models offer integration with existing third party OS products -- CP/M or MP/M for the 8088 and Uniflex-S/6809 or OS-9S/6809 for the 681809, and both already have software and hardware products that allow integrating these PCs as workstations into IBM's mainframe and mid-range systems. 

OS-9S is a split-stack version of OS-9 based on OS-9 level 2 and Susumu, now no longer top-secret. Uniflex-S is based on Uniflex and Susumu.

Both have Susumu as their BIOS in ROM, and both include (as something of a last minute addition) the students' extended dc/bc languages in the ROMs.   

A third model is also announced, based on the (alternate world) 68010 which Motorola has just announced. It starts at 32K RAM installed on the mainboard, but otherwise has a similar design to the 6809 version, including the expanded bus connector, but with a full 16-bit data bus. Uniflex-S/68000 and OS-9S/68000 are available OSses. Pricing starts a little higher, at $1750.

Neither Microsoft BASIC nor PC-DOS are mentioned.

In answer to questions about models based on other processors, IBM specifies a product concept that focuses on the software rather than the hardware. They do not commit to using other CPUs, but they do mention development research on the 99S200 and the newly announced Z8001S. They do not mention their own ROMP.

A week after IBM's announcement, Radio Shack rushes to announce their own OS-9/6809 compatible model, the TRS-09 Color Business Computer based on, and compatible with, their original Color Computer. It includes a built-in DMA controller, with the Color Computer's Multi-Pak interface, a floppy disk controller, and two hardware serial ports in addition to the single CPU-intensive bit-banging port of the Color Computer also built-in. It boots to Microsoft Disk Color BASIC, but the DOS command can load an operating system from a floppy disk or ROM pack. Two cartridge slots for ROM packs are brought out to the side, the other two slot circuits being used internally for the built-in I/O. It comes with 16K of RAM, upgradable to 64K. Price and branding adjustments are also announced, with sales personnel pointing out that the entry level price is only half the price of an IBM PC/09. 

The limit to RAM expansion is swept under the rug, but the magazines dedicated to Radio Shack's computers all point it out.

The two students who are under NDAs with IBM Instruments go to Danbury again for short internship sessions, and return before school starts.

Efforts to find a source for CRTs are still not very fruitful, but the students have developed some approaches that allow a couple of them to write magazine articles describing circuits using the 68471 for TVs and steps to tune the output to individual TV models, to get legible text at 64 columns, or even 85 columns using 512 pixel wide lines and 6 pixel-wide characters.

Parents of several of the students meet with the colleges and the other companies that have been supporting the research group, and set up a company to handle commercializing their work. Arguments arise, but a small core group of seven of the students (who have just returned from a little vacation to Japan) work hard to bring everyone to agreement. 

A non-profit research group is set up, and the students take membership in it.

Additionally, a for-profit development company is set up which can act as agent for the students in accepting contract work.

Microsoft attempts to sue IBM for getting shut out of the PC product, but IBM legal has their response already prepared. A legal skirmish commences, with public news coverage generally portraying Bill Gates as a modern David against IBM's Goliath.

Tandy/Radio Shack wakes up and sends lawyers, and then wakes up again and sends engineers, too. After some discussion and belated agreement to follow the licenses and consortium rules, they are allowed to join the sponsors' consortium.

Western Electric also approaches the group, but do not seek membership in the consortium because of their monopoly status in the communication industry. Top-level negotiations on the licensing of Unix ensue between the Susumu Sponsors Consortium and Western Electric and several other communications industry companies and educational institutions. The core student group participates, along with counselors and legal help from the college and university, representing the students' interests. 

IBM Instruments again sends engineers to observe the students' work, and spend considerable time discussing both Susumu and Microware's OS-9 with the two NDA students and members of the core student group.

The core student group members all complain quietly about having to take time away from their own projects to deal with all the side issues.

As summer break ends, a group of foreign exchange students arrive from Japan, mostly on education/research leave from Japanese companies. This creates a bit of confusion and friction, but the core group members manage to iron things out and they join the research group.

~~~~~

How's that for more alternate reality? Doesn't it sound like it might have been even more fun than the reality we know?

Alternate Reality -- 33209 (pt. 1, winter 1981)

***** Alternate Reality Warning *****

So, having treated myself to a trip down memory lane, with some daydreaming about Apple and a different OS-9 and how things could have been, I decided maybe I should map out some of the directions the computer/information industry would take in the alternate world of the 33209.

As opposed to the previously mentioned daydream, this alternate reality begins branching from mainline reality in a general sense in early 1981. 

(In a more specific, personal sense, it branches much earlier. But that branch runs pretty much parallel with our reality until late in 1980. I won't deal with that here, read the novel linked above (what there is of it at this time) if you're interested.)

(You're not sure you're interested? Odd. It's not like this is just working out a time line for the evolution in technology at the core of the plot of that novel or anything like that. ;-) 

* First half of 1981:

A group of electronics and computer information science students at a community college in a football/oil field town in west Texas coalesces around the Micro Chroma 68, Motorola's prototyping board for the 6802/6808, a 6800-compatible early system-on-a-chip (SOC) MPU, the 6846 ROM-I/O-Timer chip, and the 6847 TV grade video controller. and around building microprocessor trainers using the 6805 (not 6800 compatible, but close, microcontroller with a little bit of built-in I/O, timer, ROM, and RAM) and turning the trainers into keyboard controllers. 

Initially, all of the additional circuits they design are hand-wired.

From the beginning, several of the students help the others keep records of their work and of how they share what they produce.

Not only their teachers and other faculty members, but representatives of Motorola, IBM, and TI observe and encourage the students' work. (Why they do, I won't get into here. See the novel. Admittedly, this is the biggest jump in logic in the daydream, and big enough to keep it squarely in the realm of daydreams.)

Faculty from the nearby branch of the University of Texas drop in to observe, as well.

One of the students designs a floppy disk controller based on the 6801, and Motorola negotiates with him for options on the design. As a result, the group gets access to Motorola engineering support, in the form of both documentation and parts sampling.

The group has the right combination of talents, interests, resources, time, and connections, and by spring break, they all have working trainer/keyboards based on the 6805. 

During spring break, several of the students participate in internship programs with the three companies.

By the end of spring break, most of the students have their own working Micro Chroma 68s, using daughterboards to substitute the 6801, an integrated microcontroller with a more powerful 6800 compatible CPU, for the 6808 or 6802 originally specified for the board. 

Since most of the students do not yet have floppy disks, and since ROM is faster for reading than floppy disks and displaces less of the usable RAM space, as well, all students include hardware to program EPROMs in their computers. This allows them to program their own ROMs and construct their own monitor/debug systems and their own boot-level input-output software -- what we began to call BIOS (Basic Input/Output System) about this time under influence of CP/M.

Several simple graphical games get written in the process, for fun, relaxation, and testing the computers.

Several of the students get together to rewrite parts of the  Micro Chroma monitor/debug program ROM to use the features of the 6801, and they call the combination Micro Chroma 6801. The monitor/debugger is shared with everyone, and all the students also put ROMs containing the freely available Tiny BASIC in their computers and are able to type in programs and save their programs to cassette tape and load them back in.

Many of the students add bank switching, lots of RAM, and floppy disk drives to their computers. Fast cassette interfaces are also experiment with, especially for backing up their work. Some of the students adding floppy disks use the 6801-based floppy disk controller developed by their fellow student, others use various commercially available floppy disk controllers, allowing the group to learn how to separate I/O functions out into device driver modules and make their software somewhat hardware independent.  

Some of the students add the 6844 DMAC (direct memory access controller) to their Micro Chroma 6801s, to ease timing for the floppy disk high-speed cassette interfaces and device drivers.

Several students start experimenting with chemical etching to produce their circuit boards.

With floppy disk drives, they are able to bring up the Flex operating system from Technical Systems Consultants, which some of them have bought copies of.

Certain members of the group port the Forth Interest Group's freely available fig-Forth language/operating environment to their computers, allowing even those who don't buy an OS to (among other things) use their floppy disks without always having to type obscure machine code in at the keyboard.

Motorola and IBM both negotiate with the students for limited rights to use their design work, IBM asking for confidentiality concerning their being interested.

A small group begins an attempt on a port of Edition 7 Unix (now known as Research Unix) to their computers. The college makes their Univac 1100 available to them during off-hours, to run Unix on, to help with their work.

At this point, TI also negotiates with the students for limited rights to use their design work.

Engineers at Apple hear about the students' work and start visiting with IBM, TI, and Motorola when they visit. Members of the petroleum industry operating near and in the town also start visiting. 

Some of the students have misgivings about the visits until visiting engineers share some of their experience and help with the Unix port and other problems students have trouble solving by themselves. Nevertheless, the port gets a bit stuck in trying to produce a cross-compiler for the C programming language.

Many of the students begin building computers with other CPUs, sharing ideas and keeping their designs similar  enough to the Motorola CPU-based designs to make porting the Forth reasonably straightforward. 

TI provides 9900s and 9900 series peripheral parts, including their video controller, the 9918A, to several students who want to use them. Motorola provides 6809s and 68000s and peripheral parts to those who want to use them. IBM steps up to buy CPUs for students who want to use 8086s or 8088s. Apple steps up to help those who want to use 6502s. Some of the students want to use Z-80s or 8085s, and petroleum industry companies step in to help them. At the suggestion and assistance of certain engineers from the petroleum industry, a couple of students decide to try the Z8000, as well.

Students working with the more advanced CPUs initially try to implement too many of the advanced features, but after a short time consign themselves to just getting them working first. 

Students working on the 68000, in particular, spend a week trying to design asynchronous bus interfaces, along with 16-bit peripheral circuits to take the place of 16-bit parts that aren't available from Motorola. Not making much progress with that, they settle on using the 6800-compatible bus signals, and rely the special MOVEP instruction which was designed to make it easy to use the existing 8-bit peripheral parts from the 6800 family. This allows them to get basic functions running enough to start figuring out the advanced functions.

For most things that don't require large address spaces, the 6809 proves the easiest to work with, and students working with it are successful at getting more advanced operating system and hardware features running, including DMA access using the 6844 for high-speed I/O concurrent with other operations, and basic memory management functions using bank switching or the 6829 series memory management unit (MMU), which Motorola also provides samples of. Simple bank switching proves to allow the computers to operate at higher CPU and memory cycle speeds than the 6829, but with less flexibility in function. 

Many of the students elect to use the 6845 or 9918A to control video in the computers of their own designs instead of the more limited 6847. Some initially elect not to include video, using the Micro Chromas as terminals for their computers, instead. Other options for video output are also explored.

Motorola samples an upgrade to the 6805 to the group, along with a cross assembler that the students can run on their Micro Chroma 6801s, either under Flex or by loading and calling directly from the monitor/debugger firmware. A couple of students build small computers with the upgraded 6805 for practice, pairing it with the 6847 video controller. The limits of the byte-wide index register X make it difficult to port a full Forth, but a small subset of library-type functionality is put together. 

One of the students quickly redesigns the floppy controller using the libraries and the new microcontroller's internal direct memory access controller, and Motorola buys this design outright, giving the group a bit of money.

About the time that the new floppy controllers come up, the students working with the 68000 get their asynchronous bus interfaces running, speeding up memory access. But they decide to continue to use 8-bit peripheral parts and the MOVEP glue instruction rather than design their own peripherals, as much as possible.

In response to students' requests, Motorola offers to make MMU parts for the 68000 available, with the warning that most customers have not found them useful and have been implementing their own MMUs. They do make documentation available, and after a few days of studying the documentation and errata, the students decide to postpone memory management on the 68000 for the time being.

One of the students notices that a 512 byte table in ROM can be used to synthesize a fast byte multiplicative inverse on CPUs that lack hardware divide, and that is added as an optional part of their libraries, the source code for the table being generated mechanically on one of the students' Micro Chroma 6801s. The table can be used even on the 6805 by storing the more and less significant parts of the result in separate tables. 

One of the students writes a simple inclusion pre-processor inspired by the C pre-processor to handle assembly language file inclusion, making it easier to handle library code.

A group of the students writes a set of library routines for the Micro Chroma 6801 inspired by the libraries of the programming language C, but using a split stack architecture inspired by Forth, with one stack to keep return addresses and the other (a software stack on the 6801) to keep parameters on. The group then produces a mashup programming language based on fig Forth and the programming language C, which language gets nicknamed first "Split C", then, amid jokes about split pea soup, renamed "Split P" -- P as in program. 

The language has two grammars, a Forth grammar, which is modified from the fig Forth, and a C grammar, which is kept compatible with K&R C. Implementing the C macro-preprocessor takes some effort, and eventualy they implement it in the Forth grammar.

Almost as fast as it is implemented on the 6801s, split P is implemented on the 6809 and 68000, and the three code bases become the core code bases for the language.

One of the programming teachers tells the class about Ken Thompson's "Reflections on Trusting Trust", and the students design a process for using cross-compiling to bootstrap the compiler for Split C cleanly of potential library-hidden back doors..

Using Split P and borrowing more ideas from both Unix and Forth, members of the group begin designing a new OS they call Susumu (Japanese for "Proceed"). The BIOS for Susumu is designed to include a ROMmable monitor/debugger which is a subset of the Forth-like grammar of Split P and includes a minimal interactive assembler and disassembler. 

Full assemblers are also written, to make the operating system and programming language self-hosting. Early versions of the 68000 assembler do not handle the full instruction set, only enough to compile and run the high-level code.

The disassembler/debuggers, both minimal BIOS and full versions, and the relocating linking loader are ongoing projects that have to be rewritten as Split P evolves. In particular, the ability to relocate variables and labels within the 6801's direct page requires several tries to get right. These are not complete during April (or even May), but they are working well enough to fork (spin off) versions to use in the project to port Unix.

Some of the students write about their work and submit to certain electronics and computing magazines, and some of the articles are accepted, to be published beginning in June.

In late April, Motorola acts on the option to buy the right to use the 6801 floppy controller design, giving the group more money. 

Motorola then publicly announces the upgraded 6805 system-on-a-chip (SOC) microcontroller, with immediate sampling:

• The 682805, using a pre-byte to expand the op-code map as necessary, gets a second parameter stack pointer (named U after the 6809 second stack pointer) and push/pop and transfer pointer instructions (PSH/PUL/TFR) to support it. It also gets push/pop/transfer instructions for the return stack, to reduce the bottleneck that a single stack tends to create. Careful design allows using the pre-fix instruction byte to add u-stack indexed mode instructions to access local variables on the parameter stack without significant increase in transistor count, as well. 
   
• The return address stack and its RAM are moved out of the direct page, with access optimized so that simple calls cost no more than jumps or branches. The parameter stack and its RAM replace the return stack in the direct page.
  
  
• A two-channel chainable direct memory access controller (DMAC) with 8-bit counters is added to the list of optional integrated I/O devices. (Chainability is what makes the microcontroller especially suited to the floppy controller.) (It's worth noting here that, in our real world, Motorola didn't introduce DMA channels in their published SOC microcontrollers until much later.)
   
• Also optional instructions are added, including the 8 by 8 to 16-bit multiply from the 6801 and 6809. Both of these use the X index register to store the high byte of the multiply, similar to later versions of the 6805.
  
  
• The MEK 682805 and Micro Chroma 682805 are announced as prototyping kits, crediting the students' work.
  

What is not announced is that monitoring the students' experiences is a large part of what has actually motivated the changes. 

• Motorola engineers have also polished the floppy controller designs and implemented them as integrated, almost single-chip controllers, and Motorola publishes the designs, both as products and as reference design application notes on constructing custom SOC designs using Motorola's processors, again acknowledging the group's contributions.
  

At about this time, Motorola also samples upgrades to the 6801 and 6847 to the group, and several of the students elect to build prototyping kits similar to the un-expanded Micro Chroma kits using these parts, for fun and practice. They work quickly, producing operational prototypes in just a few days. 

Comparing the 6845 and the upgraded 6847, a few of the other students decide 64 characters wide is good enough, and rework their video designs to use the upgraded 6847 instead of the 6845.

Most of the students are now building both chemically etched and hand-wired circuit boards. 

As students bring up computers of their own design on CPUs other than the core three, they begin to port both Split P and the nascent Susumu to their computers, keeping a high degree of compatibility between their systems in spite of the different CPUs. In order to make the ports work, techniques for specifying byte-order independence in source code are explored and implemented.

Several of the students work together to write cross-assemblers for the non-core CPUs in Split P, which allows much of the development to proceed on working hardware instead of the hardware prototypes. Coding significant parts of the OS and interpreter/compiler in Split P instead of assembler also helps speed development. 

Modifications are made to the Forth grammar of Split P, to include explicit named statically allocated local variables and global variables controlled by semaphores or counting monitors. 

Modifications are made to the C grammar to include structured return types for functions (using the split stack), global variables controlled by semaphores or counting monitors, and task-local static allocation.

Several students working on computers based on the 6809 purchase TSC's Uniflex or Microware's OS-9, as well. TSC and Microware both provide help to the students to bring their OSses up, both companies becoming interested in Split P and Susumu in the process. 

Two of the students, frustrated with the restrictions against mixing code and string data in Microware's  native assembler write their own assembler to allow mixing string and other constants in with code without needing fix-up tables and code. This allows them to bring up Forth for OS-9 as a relocatable module.

Apple inquires about obtaining formal rights to produce products based on the work the group is doing. Motorola, IBM, TI, Microware, TSC, and the petroleum industry companies also express a need for more formal arrangements, and, with help from the college, the group formally organizes as a research group under the college umbrella, in order to simplify legal issues. Legally organized, the group itself becomes able to receive small grants from each of the interested companies, and individual students are more easily able to contract to do projects for various companies.

The organizational structure within the group is kept flat, and participation voluntary. With legal help from the colleges, they agree on a liberal license for collaboration in their work, allowing them to continue collaborating with each other and also with interested people not formally in their group. 

More students express interest in joining the group, both from within the college and from the nearby branch of the University of Texas. After some discussion, and after the new students agree to accept the license and respect requests for confidentiality from the corporate sponsors, they are cautiously welcomed in. 

As spring semester ends, some students head out for summer jobs and summer vacation, others stay for the summer terms and to keep the group moving forward. Certain of the students begin internships with one or more of the companies that are taking something of a sponsorship role by this point, working some days with engineers at the corporate campuses and some days back at the college lab. A newsletter is begun, to keep everyone up to date.

More articles are accepted by electronics and computer magazines, including a few articles that are contracted by Motorola and TI to publicize application notes, including the floppy controller and the 682805 in particular.

At Apple, during May, Jef Raskin prevails on management to produce an OS-9/6809-based business computer line, including workstations and network computers. 

Nothing really exciting happens within the student group during early June, only steady progress on various projects. Well nothing exciting except that TI also brings samples of an upgraded variant of the 9900 CPU and of the 9918A video generator for the students, and several agree to try them out. These take a bit more work, with students helping to debug TI's new design work. 

The appearance of the magazine articles on the students' work creates some excitement outside the group, but the group is so far ahead of what is published that other than the excitement of seeing their work in print, the articles are a bit anti-climatic for the students.

Engineers at Radio Shack are among those outside the group that take note of the articles, in particular showing their management an article detailing the Micro Chroma revisions for the 6801 and 6809 and another article showing the 6809 interfaced to the 6844 DMAC.

The students working on Susumu get Split P code generation on the 6801 working well enough to start using the C grammar directly as the system native compiler for the Unix port project, and parts of Unix are brought up on the Micro Chroma 6801s with bank switching. There isn't enough room in 64K for Unix without bank switching, but it does run with bank switching. It's also relatively slow on the 6801, but it works well enough to compile and run some system tools.

The ports of Susumu to the 6809 and 68000 are likewise brought up to a usable level by mid-June, and ports to the 8086, Z8000, 9900, Z-80, and 6502 are partially running, but buggy.

With work on 68000-based computers proceeding well, students working on those are invited to a meeting with engineers at IBM Instruments under non-disclosure. After some discussion, the student group agrees to let the invited students make up their own minds. 

Two of the invited students go, and return in a week with a couple of IBM engineers who observe the student group's activities without comment for several days and then return to Danbury. Everyone in the group studiously avoids tempting the two students to break their NDAs, which engenders some small tension. But the tension gradually evaporates naturally.

In mid-June, just before the start of summer, Motorola publicly announces sampling of the upgrade to the 6801 SOC microcontroller:

• The 682801 gets direct-page versions of the 6801's unary instructions, allowing more effective use of the direct page. (The 6800 and 6801 did not have them, I assume because the design engineers were concerned that there would not be enough opcodes for required inherent address op-codes. They were present in the 6809, however.) The op-codes for the new direct-page unary modes are carefully allocated so that they fit in the primary op-code map and don't cost a pre-byte fetch to use, but are scattered across the available un-implemented op-codes instead of lined up with the rest of the unary instructions. This costs more in circuitry, but maintains object-code compatibility with the 6801 and 6800.
   
• The 682801 also uses a pre-byte to expand the op-code map so that it can have a second U stack pointer for parameters and for index mode op-codes that allow access to the parameter stack without going through the X index register.
  
  In addition to the 6801's ABX (add B to X) instruction, new instructions SBX (subtract B from X) and the corollary ABU and SBU are provided for improved handling of address math and stack allocation/deallocation. And the compare D (CPD) instruction which is missing on the 6801 is added to the 682801.
  
  
• The 682801 gets a 64 byte spill-fill cache for the return stack, with 18:38:8 hysteresis to provide worst-case overhead space for interrupt frames, which is large enough for nineteen levels of frameless calls and nine levels of framed calls without going to the external bus to save the PC or the frame pointer. This allows simple calls to statistically cost no more memory cycles than jumps and branches. A similar 64 byte spill-fill cache for the parameter stack is provided, as well, but with 8:48:8 hysteresis, improving access cycle times to local parameters. These caches can be locked in place, for applications that don't need deep stacks.
  
  
• Separate system and user mode are implemented, with a new status bit in a new status register in direct page I/O space. In order to make context switches faster for interrupts, there is a return stack cache and parameter stack cache for both system mode and user mode.
  
  In order to avoid complex delay circuitry for the caches under interrupt and return, the S and U registers also have system and user mode versions.  Control registers for the caches are in the direct page I/O space.
  
  
• Functional equivalent modules for many of the 6800-series peripheral parts are announced as optional integrated I/O and timer functions, including the 6844 DMAC. Integrated devices will be shared with the 6805 series MCUs, too.
  
  
• Address function signals are provided, to allow a system to distinguish between program/interrupt response, return address stack, direct page, and extended address/general data access for both user and system modes. This allows separate buses for each function, reducing memory conflicts.
  
  This also allows expanding the address space to an effective total active address space larger than 64K.
  
  (Theoretically:
  
  
  • code (f3) <= 64K 
  • + general data (f2) <= 64K 
  • + direct page (f0) <= 256 of 64K
  • + return address stack (f1) <= 64K;
  
  Because of the 16-bit width of the index register X, expected actual aggregate active process space will generally be less than 128K. Even so, the extra address space clears a number of design bottlenecks.)
  
  Because the index register X can only point into the general data area, using separation requires care in software when using addresses and pointers, and when assigning address range deselection in the hardware.

But with the return address stack in a separate address space based on the function codes, rogue code can't overwrite the return address, period. Also, the spills and fills associated with calls and returns can occur concurrently with other instructions.


• Hardware 8 bit by 8 bit unsigned divide -- A is dividend, B is divisor, result B is quotient, and A is remainder, to make it easier to repeat the division and get the binary fraction.
  
  
• Bank switching memory management is also added to the list of optional integrated devices, to expand the physical address space and allow write and address mode protection and address function separation.
  
  In the bank-switch module provided by one initial part, 16 8-bit-wide bank switches provide linear mapping of 4-kilobyte banks of a single linear 64K address space into a single 1 megabyte maximum physical address space. The top 4 bits (LA12-LA15) of the logical (CPU) address select the bank switch, and the bank switch provides the top 8 bits of physical address (PA12-PA19), instead. This part provides only 128 bytes of internal direct-page RAM.
  
  In the bank-switch module provided by another initial part, address function codes are appended to the top of the CPU address, giving 18 total logical address lines (LA0-LA15,FA16,-FA17) for a 256K logical address space.
  
  
  • Data and code (f2 and f3, FA17:FA16=10 and 11) are each given their own sets of 16 8-bit-wide bank switches (providing PA12-PA19) to map 4K banks from the 64K space addressed in data mode (extended or indexed) or code mode (program counter or interrupt) into the full 1M max physical address space.
     
  • Data (f2, LA17:LA16=10) is given its own set of 16 10-bit-wide bank switches (providing PA12-PA21) to map 4K banks from the 64K address space pointed to by the index register or extended mode absolute addresses into the full 4M max physical address space.
    
    
  • Code (f3, LA17:LA16=11) is given its own set of 16 9-bit-wide bank switches (providing PA12-PA20, with PA21=1) to map 4K banks of the address space pointed to by the program counter or selected by an interrupt response into the top 2M of physical address space.
     
  • Stack references (f1, FA17:FA16=01) are hard-mapped to the second 64K range ($010000 - $01FFFF), and four sets of 16-bit bounds register latches and a stack bounds violation interrupt are provided for stack security. The first version of this part provides 256 bytes of internal stack use RAM at $10000-$100FF.
     
    
  • Stack (f1, LA17:LA16=01) is given its own set of 16 12-bit wide bank switches (providing PA8-PA19, with PA21:20=00). Shifting the switch addresses down allows stack to be allocated in 256 byte chunks, making more efficient use of stack RAM. The extra width allows allocating illegal address ranges around the stack, to improve system security in case of stack overflow, underflow, or corruption. (Too late at night.)
    
    
  • Direct page references (f0, FA17:FA16=00,LA15:LA8=00000000) are split into upper and lower halves, and mapped into the lowest 32K range ($000000 - $007FFF), using the high bit of the direct page address (LA7/DP7) and a system/user state bit to select one of four 8-bit switches to provide physical address PA7 - PA14. In this part, 256 bytes of internal direct page RAM are provided at $000400 - $0004FF. internal I/O addresses, including the bank switch registers, are provided from $000000 - $0000FF.
    
    
  • The upper half of the direct page is mapped through a simple 8-bit latch with constant higher bits that are appended above the lower 7 bits of the direct-page logical address produced by the CPU, to yield a physical address in the range $8000 - $FFFF. In this part, only 512 bytes of internal RAM are provided.
    
    
  • The lower half of the direct page is similarly mapped, to yield a physical address in the range $0000 - $7FFF. The bank switching registers are mapped into this range, in particular, the direct page latches and related control bits start at address zero, and interrupts
    
    
  Initial SOC parts provide either simple general switching out of a single larger address space or function-based switching out of function-separated address spaces. of 16 by 4K banks out of a single 1 Megabyte max address space, or function-based switching of 16 by 4K banks each of code and data out of 1M max plus 16 1/4K banks of return stack out of 64K max with a constant offset into the CPU address space
  
  Special bank switching for the direct page is another optional integrated peripheral, to allow switching half-pages from up to 32K of physical address space into the lower half of the direct page and 32K into the upper half (theoretical max, depending on the width of the implemented bank switch register), in 128 byte chunks.
  
  Motorola suggests the convention that I/O should be switched in the lower range from $00 to $7F, and (preferably internal) RAM in the range from $80 to $FF, and the initial SOC parts follow this convention., providing 512 bytes of actual internal direct page RAM. Initial parts only implement 4 bits of direct-page bank switch, physically limiting total addressing for each half to 2K.
  
  With this kind of mapping, keeping task global variables in the direct page can speed task switches.
  
  By keeping task global variables in the $80 to $FF range, fast task switching can be supported.
  
  Full 6829-style MMU functionality is mentioned as under consideration, but not yet committed to.
   
• In addition to the 40 pin DIP package, 48 pin and 64 pin DIP packages will provide access to extra address and port signals.
  

They also announce the 68471, with the following extensions to the 6847:

• In character mode, 32 or 64 characters per row, 16 or 32 rows, interlaced or non-interlaced. Internal character ROM now includes 128 characters. The default character set includes lower case, full ASCII punctuation, and common useful symbols in the control code range. External character ROM is supported,
   
• In graphics mode, 512 pixels per row and 384 rows per field modes are added to the 6847's lower resolution modes, interlaced or non-interlaced. One, two, or four bits per pixel are supported, allowing 2, 4, or 16 colors per pixel, if the output digital-to-analog converters and amplifiers are fast enough. 24 kilobyte maximum video buffer give 2 colors at highest density, 4 at 256 by 192, and 16 at 128 by 64.
  
  8-bit programmable palette registers are provided, intended as 2 bits each of red, green, blue, and intensity.
  
  
• 6883/74LS783 DRAM sequential address multiplexer (SAM) and refresh functions are built-in. Bank switching into an up-to 16-kilobyte CPU-side window is also built in, to support the large video buffers for the higher density graphics modes on 16-bit addressing CPUs.
  

And Motorola announces the Micro Chroma 682801 as a prototyping kit for the new CPU and video generator, with Susumu the 2 kilobyte monitor in internal ROM implemented as Susumu library functions.

Specifications for upgrades to the 6809 and 68000 CPUs and 6845 video controller are also shown to the students, and more than a few express interest in seeing what they can do with them.

The students start searching in earnest for a source for CRTs that can function at sufficient resolution to handle 80-columns or more of text output that the 6845 and the improved 6845 can produce, but don't have real success. A few students are able to get a CRT here or there, but the interfaces are varied, and the video generator circuits the students produce are also varied.

As a result, most of the students remain dependent on TVs for video, and Motorola supplies them with enough 68471s that they can all get 64 column text output circuits for their more advanced computers. Unfortunately, results are rather uneven and require careful tuning to individual TVs, such that, even with the 68471s, the circuits they produce do not approach mass-marketable products.

Susumu and Split P code generation for the 682801, 6809, and 68000 are also functioning well enough as summer begins that the ports of Unix are re-booted using Split P as the system language and Susumu as the system programming language.

And this is getting long.

~~~~~

How's that for alternate reality?

And the outline for summer is ready now, here.

Connection between Motorola's 6800 and the DDP-116?

I think I may have found the computer that was the primary influence in the design of the 6800. This is going to require more research, but the Wikipedia page on Honeywell's H-316 describes the processor, but doesn't give any more information on how much of the design was inherited from the original DDP-116 that Honeywell got from Computer Control Company:

Accumulators A and B? 16-bit, but check.

Index? Check.

I'm thinking it looks closer than either the PDP-8 or PDP-11, both of which are usually cited as influences, but have much larger register sets of general purpose registers rather than the 6800's limited pair of small accumulators, single index register, stack pointer, and program counter (instruction pointer).

The 68000 (one more zero!) clearly shows influences from the PDP-11, and the 6809 borrows indexing modes from the PDP-11, but the 6800 does not look like a PDP in any way that is not attributable to both implementing Turing machines in register-memory architecture.

[JMR20220703:

I've been looking around again, and I think the Data General Nova is another CPU that the 6800 might have been fairly directly influenced by -- 

• two accumulators (again, 16-bit), 
  
• and, okay, two, not one, index registers. 
• The 6800's constant byte offset could be inspired by the Nova's constant offset indexed addressing mode, 
• and the 6800's direct page is similar to the Nova's page zero.

Two index registers -- the 68HC11 descendant of the 6800 finally got a second index register, well more than a decade after the introduction of the 6800.

It is fairly clear that the Nova was part of the inspiration for the original ARM architecture, I think, and I know several people who agree with me about that.

]

This needs more research, however. I'll try to update this stub when I have better information.

Alternate Reality -- Early Microcomputer Operating Systems, OS-9, and Apple

This comes from a response I posted to a thread in the Vintage Apple Macintosh Enthusiasts group on Basshook about Michael Dell's bragging, where the thread took a what-if turn about Rhapsody, Yellow Box, and such.  The OP hypothesized how the computer industry could have changed if Dell had accepted the opportunity to preinstall Yellow Box (essentially, Steve Jobs's NeXT, but on top of MSWindows, if I understand/remember correctly) on the computers he sold.

I suggested, for a what-if hypothesis-contrary-to-fact session of daydreaming, going back more than a decade from there to Microware's OS-9, a modular real-time operating system available for Motorola's 6809 CPU from 1979/80, and for Motorola's 68000 from 1983, which included graphics and GUI component libraries. 

He said that was before his time.

So I offered him a gratis (heh), technologically dense daydream of my own:

----- My Response -----

Worth checking out. OS-9 was a Unix-like, modular multitasking real-time OS available in 1979. (Wikipedia: https://en.wikipedia.org/wiki/OS-9.)

The open source project has a FB group, Tandy Color Computer OS-9 / NITROS-9, and you can download NITROS-9 and check it out using MAME or the XRoar emulator.

Kind of surprising what could be done on what was essentially a Radio Shack toy computer in 1987.

In the late 1970s and early '80s, the 6809 was viewed by many in the Apple community as the natural evolution from the 6502. 

There were a few hanging points -- mainly the need to develop an interpreter front-end to Microware's compiled Basic09, byte order opposite the 6502, incomplete support of pointer variables in the byte-addressed direct page, the need for a simpler, faster MMU than Motorola's over-designed separate 6829 MMU, the penalty that OS-9 placed on non-position-independent programming techniques, and Motorola's lack of plans for evolving the 6809 to a fully 16-bit CPU.

Also, Apple would have had to plan on developing it as a product line to be aggressively evolved.

But they could have delivered a multi-tasking network-server capable business machine with high-level language support in 1980 instead of the Apple III, with minimal engineering effort. This could have been Raskin's text-based appliance computer. They probably would have wanted to introduce 80-column Apple IIs with bundled terminal emulators to go with it.

A model with built-in hard disk support, bank-switching for a 2 MB memory map, and a display buffer could have been produced in 1981. They could have released their own GUI or an improved Multivue in 1983, and it wouldn't have required 80+ hour workweeks for the engineers.

Experience with OS-9/6809 would have allowed them to put OS-9/68000 underneath the Lisa, and bring that to market at least a half-year earlier, without MMU, but cheaper.

With OS-9/68000 underneath the Lisa, the Macintosh would not have required a separate technological base. Or it could have had different hardware with little engineering penalty, and still been part of the same line as Lisa. The toolbox would simply have been a collection of OS-managed library modules in ROM.

Lack of a true OS underneath the Macintosh would never have been a problem, and neither would *nix compatible networking. The Lisa/Macintosh would have been Internet ready pretty much as it was.

How's that for alternate reality?

----- End Response -----

 

Well, some of what I put in that included false memories about who did what when, but it wasn't that far off.

But it was dense. So I'll use unpacking it as an excuse to walk through the real-world background of that dense daydream:

===== Real Reality =====

Two decades before Mac OS9 -- a decade and a half before the failure of Copland and the transition to Rhapsody, and a decade before Pink -- a small company called Microware was contracted by Motorola to develop a structured, i-code compiled version of BASIC for the 8-bit M6809 CPU (not the 6800, 6801, or 68HC11). For an operating system to put underneath Basic09, Microware developed the operating system OS-9 (OS-9/6809). 

(Microware's lawyers and Apple's lawyers met around the introduction of Mac OS 9, mid-1980s, and were able to come to an agreement about the name fairly quickly. At the time I write this, Wikipedia's page on OS-9 has minimal mention, but more information is available elsewhere.)

OS-9 was (and still is) a modular, multitasking, real-time Unix-like OS, and it was first available for computers based on the 6809 in 1979. (OS-9/68000 and OS-9000 and later versions were POSIX compliant.)

It was also a showcase for certain aspects of the 6809 that regularly still get overlooked by the noisier elements of the industry. 

A lot of people seemed to notice only one or two features of the 6809, such as the hardware multiply instruction or the second index register. 

But the 6809 is much more than that. The architecture of the CPU supports a programming style that is modular, understandable, and, well, engineerable. OS-9 demonstrated that the architecture of the 6809 allowed using concise code to solve truly difficult problems like guaranteed response times and functional verification with generalized hardware and programming tools for a wide range of 8-bit applications. 

(The 68000 also supports such a programming style for 16 and 32 bit applications, but uses roughly twice the number of registers in doing so -- in a much more flexible way.)

Engineers who understood the architecture made very good use of it in telephony, sound synthesis, various kinds of real-time controllers, and even business systems. 

But there were a lot of famous pundits who could not see the forest for the trees and spread a lot of useless information about the limitations of isolated features of the 6809.

As just one rather visible example of what the architecture enabled, with Basic09 and OS-9 you had an integrated development environment pretty much as powerful as, say, the combination of Turbo Pascal under CP/M and MS-DOS would be two years later. Admitted, the programming editor provided with the OS was originally a line editor instead of a full screen editor, but third party screen editors came pretty quickly.

One big difference from Turbo Pascal under CP/M or MS-DOS was that OS-9 was multi-tasking from the outset -- Send a long document to the printer and it would print in the background while you worked on accounts receivable, your neighbor in the next cubicle worked on a program she was developing using a terminal on her desk, and a secretary proofread and prepared a letter on a terminal on his desk, all at the same time on the same machine running OS-9/6809. 

(For the record, DR produced the multi-tasking MP/M about the same time as OS-9 came out. MP/M was more-or-less about desktop-level multitasking, where OS-9 was more general, being able to multi-task on desktop applications as well as controller applications. Also, for the record, MS-DOS was not multi-tasking, and had to rely on the individual applications themselves, or on terminate-and-stay-resident (TSR) utilities, to manage print spooling and calendars and such.)

The 64K RAM limit in OS-9 level 1 in 1979 did put some limits on things, just like with any of the 8-bit ALU/16-bit addressing microcomputers of the time. These limits could be largely overcome with bank switching in OS-9 Level 2, when it became available in 1980.

Microware also made a Pascal compiler available soon after the release of OS-9 and Basic09. The 6809 instruction set and register set is well adapted to high-level languages. A C compiler was not immediately available, but came out about the time OS-9 Level 2 was released, if I recall correctly.

OS-9 Level 2 supported bank switching, to open up the address space to 2 MB in 1980. You could have six users or more simultaneously doing pretty memory intensive stuff on a single machine running Level 2. (And everybody spooling print jobs, of course.) That meant that single users were also able to make much more efficient use of the processor's extra cycles, such as compiling and running utilities and test programs in the background while editing in the foreground.

OS-9 used device drivers to get around dependence on specific hardware, so that you could build a computer with a cheap floppy disk controller or with a good hard disk controller, and the only thing that would change in the OS would be adding or swapping out the driver code. Application code would not change at all (if the application code followed the rules). So you could hang a hard disk on an OS-9 computer basically as soon as the actual hardware was available, in 1980 or '81.

One thing that OS-9 lacked was system support for virtual memory and demand paging. But it wasn't that necessary, since even native machine code for OS-9 could be (and was supposed to be) written position-independently. You didn't need a virtual machine for position independence. You hardly needed a virtual machine at all. 

A position-independent (PIC) code module, whether program or library, could be loaded to any available address without a link loader patching it up first for the address it was loaded to. And multiple processes could call the loaded module from wherever they themselves were located. Even without virtual memory, you essentially had shared dynamically loaded libraries from the first version of the OS.

Data modules could also be created and/or loaded pretty much arbitrarily, and OS-9 could use an MMU for memory protection, so most of what virtual memory gets used for was taken care of without virtual memory.

(Looking at, among other things, those pointer-pointers that enabled mobile allocation in the Classic Macintosh toolbox.)

There is a fundamental conflict between generalized virtual memory and the requirements of a real-time OS. Swapping system stuff in and out from disk makes it hard to respond to real-world events in real time. For a true real-time OS to support virtual memory would require separating the virtual memory interface from the real memory interface, and the system itself would not use the virtual memory system for anything that had to happen in real time. 

In other words, virtual memory in a real-time system must be a secondary service, provided strictly for the run-time environment of non-critical applications that need to access more memory than is physically available, need to access large amounts of high-speed memory backed by persistent store, or need  to make sparse use of large address ranges. According to certain approaches to computing systems, this is the proper approach to virtual memory in any system, but it is not an approach that has seen much use in the industry.

The perception that a real-time OS is not for ordinary users may have contributed to lack of interest in OS-9 in the general-purpose personal computer market. 

But the reality is that we as users want the computer to respond in real time, even if we can choose to be patient. That's a huge part of the magic of the Macintosh interface.

Microware made graphics libraries available for OS-9/6809, and had a fairly complete graphical user interface package no later than 1984. I don't remember if it was originally called Multivue or not, but Radio Shack would sell it as Multivue for the Color Computer 3 in 1986 or '87 (about three years after most of us thought they should have).

Network interfaces comparable to those available for Unix at the time were also available from the first versions of OS-9.

(If you want to take OS-9/6809 for a test drive, I recommend joining the Facebook group for NitrOS9: https://www.facebook.com/groups/1929079184021683/. They can point you to the web sites for the open source project, NitrOS9, and they can help with emulation environments to run NitrOS9 in, such as MAME, VCC, OVCC, and XRoar. ) 

It's rather surprising what OS-9 could do on what was essentially a toy computer from Radio Shack, the Color Computer, even in 1981. Radio Shack delivered the Color Computer 3, under-engineered and rather late to the game in 1986, but it was still impressive, much more usable than the early versions of Microsoft Windows. Even though it was still only 8-bit, it had features that would not be replicated on PCs in general until the mid-to-late 1990s. 

(And the Tandy/Radio Shack Color Computer gets its own share of what-iffing, of course.)

An important note, Microware ported OS-9 to the 68000, releasing it as OS-9/68000 in 1983. Graphics libraries and GUI for OS-9/68000 came a bit after that, some of them from 3rd parties. 

In the late 1970s and early '80s, the 6809 was viewed by at least some of the talking heads in the Apple community as the next logical step up from the 6502 in the Apple II. Both the 6502 and the 6809 were derived from the 6800. The indexing techniques commonly used in the 6502 were all more directly and more efficiently supported by the 6809's design, which produced much faster code in both benchmarks and real applications. The 6809's partially 16-bit design helped speed development, as well.

The hanging points relative to migrating from the 6502 to the 6809 that I mentioned above did exist, but a look at them shows they were not serious problems: 

• The 6809 followed the 6800 in putting the more significant bytes of numbers lower in memory, where the 6502's byte order was reversed, following Intel's habit of putting the less significant numbers first. This was considered a low-level optimization by some engineers.
  
  I disagree about it being an optimization. The technological arguments in favor of less-significant digits appearing lower in memory ignore the global effects, especially on testing and debugging. Also, arguments that byte order doesn't really affect algorithms are only excuses for whichever order is chosen, not reasons to make a choice. If less-significant first should be no detriment, neither should more-significant first, and changing the mental habits is not fatal.
  
  As an aside, the Z-80 had the same byte order as the 6502, but the run-time architecture was not comfortable to programmers used to working in assembly language on the 6502..
  
  
• The 6502 inherited its short address zero page (or page zero) from the 6800. On the 6800 it's called direct page, but it's pretty much the same idea, although the 6502 allows somewhat more efficient use. In particular, the 6502 allows indirection on memory in the zero page. This allows a great deal of flexibility and a fair degree of efficiency when working with pointer variables and address math, once you learn how it's done on the 6502.
  
  The 6809 also inherited the direct page address mode from the 6800. But it has both (almost) general memory indirection and the LEA address math instruction, which mean that you don't need the zero page for address math. Simpler, faster, improved, but different, meaning you have to take a few hours puzzling out the differences.
  
  One of the frequent uses of address math was incrementing and decrementing pointers, and the 6809 supports that as an address mode, often not even needing an extra instruction. Or you can use the LEA instruction, if the addressing mode is not flexible enough. A common issue for engineers used to other CPUs was not realizing the addressing modes and LEA instructions could be used to replace whole sequences of 6502 instructions -- or of 8080, Z-80, etc., instructions. Unfortunately, programmers who didn't know what they were doing shared a lot of code, so example code was often less than useful.
  
  If you want to write good code on a particular processor, you have to spend a few hours looking at the instruction set and addressing modes and thinking out how to use them.
  
  It's a bit odd, but indirection through variables in the direct page somehow got left out of the 6809's indexed address modes. For actual indirection, it's not a big deal -- one extra load with maybe a save and restore of an index register when necessary. But it makes the 6809's relocatable direct-page not quite the advance over the 6502's page zero that it could have been -- especially when trying to calculate the effective address of a variable in the direct page, since it can't be done with just an LEA. This is not a fatal problem, by any means. It just takes 3 to 5 instructions to replicate what should have been doable with just a single LEA.
  
  Specifically (I prefer to use the U stack, so the following uses the U stack. Those who prefer to use the S stack, use PSHS and PULS instead for push and pop.) If the value in X or D does not need to be saved, the push and pop instructions can be left out, and it's just one extra instruction:
  
  
  1. to achieve indirection on a pointer in the direct page, instead of
         LDD [<dp_pointer]  ; load value at dp_pointer
     free an index register if necessary and use it to load the pointer first:
         PSHU X  ; (if necessary)
         LDX <dp_pointer  ; get the pointer
         LDD ,X   ; load through it
         PULU X  ; (pop it back if it was pushed)
     
     
  2. To get the address of a pointer in the direct page at run-time, instead of
         LEAX <dp_pointer
     free the double accumulator if necessary, and use it to calculate the address:
         PSHU A,B   ; (if necessary)
         TFR DP,A    ; high byte of base of direct page
         LDB #(dp_pointer-dp_base)    ; offset in B
         TFR D,X   ; put whole address in X
         PULU A,B   ; (if it was pushed)
     
     
  It does feel a little more awkward than it really is. D usually will not need to be saved, so it will usually just be 3 instructions. And it's usually not an operation that occurs often enough to have a significant impact on execution time, overall.
  
  Note that the 6809 does allow memory indirection on the extended address mode. But that's only useful relative to the direct page if the direct page address is known and fixed at assemble time, which interferes with position independent practices and significantly reduces the usefulness of the direct page.
  
  
• Motorola's plans for the future of the 6809 became somewhat unclear once microcontrollers based on the 6801 and 6805 were shipping in volume and the 68000 CPU saw better than 99.999% reliability in production.
  
  The earliest materials for the 6809 indicated that the 6809 was being considered for system-on-a-chip integration, but that never happened -- at least where it could be seen by general members of the public. Such references tended to disappear from later materials.
  
  I understood from reliable sources that the 6809 was viewed by some members of management as cannibalizing the 68000's market share, and that those members of management pushed for deprecation of the 6809 for marketing purposes. This resulted in an apparent lack of a "road map", which did become a problem in the marketplace. On the other hand, eating into the 68000's market never really was a problem.
  
  
• OS-9 did not directly support non-position-independent code. You could, with effort, run such code on the system, but you lost most of the advantages of the OS.
  
  Writing code in a position-independent manner was not a common practice at the time, and many programmers thought it looked more difficult than it really was.
  
  Similar issues existed with the move to the Macintosh, but going to a 16/32-bit run time from an 8-bit run-time could be seen to have more apparent benefits than going from the Apple II/6502 to just the 8/16-bit run-time of the 6809.
  
  Because of the above, code transitioning from the Apple II to OS-9 faced not just translation from 6502 to 6809, but conversion to position independent architecture, as well.
  
  
• Since most of Apple's customers would be wanting to run code written in BASIC for the Apple II on Apple computers based on the 6809, Apple would need to provide some means of transitioning the code. Apple's engineers would face the same apparent obstacles and compatibility issues porting Apple's Integer BASIC to the 6809 under OS-9 that 3rd-party software companies and end-users would face.
   
• Another alternative, producing software to analyze BASIC programs and convert them (somewhat) automatically to Basic09, was considered the stuff of pipe dreams, although it was considered. We just generally didn't know how to do things like that back then. Still don't know how to do it well.
  
  
• Which would basically leave the alternative of a hardware Apple II emulator card for the OS-9/6809 computer, for backwards compatibility, and an OS-9/6809 emulator card to allow Apple II owners to run the OS-9 programs.
  
  We should note that OS-9/6809 cards for the Apple II were, in fact, produced and sold in early 1981.
  
  
• Motorola had a memory management unit (MMU) for the 6809, called the 6829, but it slowed the 6809 down by basically one memory cycle per memory access. One memory cycle felt like a lot, and the 6829 was a little expensive, so simple bank switching was more commonly used.
  
  But OS-9/6809 worked well with moderately-well designed bank switching hardware, so bank-switching was not such a big problem. And one memory cycle per access was actually not  all that bad, either.
  

Comparing the above to the 68000 as a path of evolution from the 6502 --

• The 68000 was also most-significant byte first, so it would be something to get used to in migrating to the 68000, just as with the 6809.
  
  
• The 68000's equivalent of a direct page is, instead of 256 bytes from address zero, the 64 kilobytes centered around address zero -- the highest and lowest 32 kilobytes in address space.
  
  While it has no specific direct page register comparable to the 6809's DP, to move that 64K of address space around with, it has 8 address registers, one of which might be used as an equivalent of the direct page register, and it has byte (8-bit) indexed address modes to improve code density and reduce clock cycle counts near a base address in any of those 8 registers.
  
  The 68000 did not have memory indirection until the 68020, but, with all the address registers, that was usually not a problem. Similar to memory indirection on a direct page variable on the 6809, just load the pointer into a free address register, and then use that address to load the value pointed to and you're done. One extra instruction that usually didn't cost much in time or code space.
  
  To illustrate, borrowing the examples above, of pointer math in the direct page on the 6809, and assuming A4 points to the local static allocation area and the variable pointed to is a long (32-bit) variable,
  
  
  1. to achieve indirection on a statically allocated local pointer variable, instead of
         MOVE.L [pointer(A4)],D0  ; load value at pointer
     free an address register if necessary and use it to load the pointer first:
         MOVE.L A0,-(A6)  ; (not usually necessary)
         MOVE.L pointer(A4),A0  ; get the pointer
         MOVE.L (A0),D0   ; load through it
         MOVE.L (A6)+,A0  ; (pop it back if it was pushed)
     
     
  2. To get the address of a local static pointer at run-time
         LEA pointer(A4),A0
     
     
  Usually, A0 would be free anyway, and there would be no need to save and restore it with the push and pop auto-mode MOVEs. So the actual cost for indirection would usually be one extra instruction, not three. Also, I should note that, while I prefer to save things on the parameter stack in a case like this, others prefer not to have a separate parameter stack and the push and pop MOVEs, if used, would be
  
      MOVE.L A0,-(A7)
  
  and
  
      MOVE.L (A7)+,A0
  
  The 68000 had a large set of data registers (accumulators), so math in general did not need a zero page. But it also had the full set of load effective address instructions and auto-increment auto-decrement addressing modes, like the 6809, so you didn't even need to use the data registers to do the address math. Still, you needed to take time to study the register set and instruction set, if you wanted to write good code.
  
  
• Motorola's plans for the future of the 68000 were made fairly clear by the marketing team. They (or the vocal members of the sales team) considered the 68000 the future of the company. (Fortunately, that faction did not attempt to push customers to use the 68000 where the 6805 or 6801 could obviously be used -- most of the time.)
  
  Anyway, it was always clear during the 1980s that Motorola intended to support and improve the 68000 long term. (That clarity disappeared, into the 1990s, but that is after the decisive events.)
  
  
• OS-9/68000 was a bit more forgiving of non-relocatable code, with the 68000's larger address space, but the full features of the OS were still limited to position independent code. So, writing for OS-9/68000 also meant learning to write PIC.
  
  
• One convenience of the larger address space of the 68000 was that there would be more room to build a more complete emulation of the functionality of Apple II software such as Integer BASIC. Other than that, accomplishing this on OS-9/68000 would have issues similar to the issues on OS-9/6809.
   
• Likewise, automatic translation,
  
  
• and hardware emulation. If you had mission-critical software to carry over from the Apple II, you wanted to keep your Apple IIs, or you wanted an emulation card.
  
  
• Motorola had a memory management unit (MMU) for the 68000, called the 68451, and it slowed the 68000 down a bit the same as the 6829 did the 6809. One difference was that the 68000's addressing timing was a little more flexible, so that a full memory cycle delay was not induced by the 68451.
  
  Nonetheless, the 68451 was not a perfect MMU by any means. Semiconductor technology and the industry's understanding of the problems were not sufficient at the time.
  
  This lack of technology is also seen in the 68000's design for interfacing with a memory management unit. Things did not quite fit, and the 68000 could not recover correctly under certain conditions when a new page of memory had to be called in from hard disk. These problems were fixed in the 68010 CPU, released publicly in 1982.
  
  But, like OS-9/6809 , OS-9/68000 worked well without memory management or virtual memory, and it really wasn't a big problem.
  
  The 68000 provided support for separating system mode from user mode, which was also improved in the 68010.
  
  One improvement I think they missed on was failing to add 32-bit constant offsets to the the indexed addressing modes of the 68000, penalizing large module designs. This was addressed in the 68020, which, in my opinion, added way too much complexity.
  
  Among other things, too many of the new instructions and addressing modes of the 68020 cost more in time and bytes of code than simply doing the same in existing 68000 code. (The execution time did improve significantly in the 68030.) Also, testing become significantly more difficult on the 68020 because of the complexity.
  
  For some reason, Motorola refrained from pushing customers to move their designs to the 68010. I assume that was because they preferred the customers moving to the 68020, instead, when moving up.
  

All of that said, Jeff Raskin was known to be working on a text-based appliance computer around 1979. The 6809 was one of the options he was known to have considered. I would be surprised if he hadn't considered OS-9/6809 for the project, but I do not at present have proof.

That's the factual background.

With the factual background laid out, here's the short version of the daydream again

***** Alternate Reality, Short Version *****

If Raskin had induced Apple to produce an Apple-branded text-based appliance computer running OS-9/6809, they could have introduced the machine in late 1980 with minimal design effort and expense. 

With that timing, the buggy Apple III of our reality could have been postponed and redesigned as a bridge machine. Instead of a pair of 6502s, it could have had a 6502 for Apple II emulation and a 6809 for business applications. Paired with OS-9/6809, this would have provided a stable mini-computer class offering.

The 6502 emulator might have done double duty as the system console for the 6809, especially if the video buffer in the emulator provided 80-column wide text.

If the initial model did not have bank switching, an advanced model with bank switching could have been produced quickly, in 1981. This model would have supported a 2 MB memory map, giving more room for a larger video buffer.

They could have produced their own graphics environment/GUI, or, by 1983, they could have delivered it with Microware's Multivue. None of this would have required engineers to work 80+ hour weeks.

When OS-9/68000 pre-release became available to Apple, Apple might have re-engineered the Lisa with OS-9/68000 underneath. Perhaps the re-engineering would have been part of the Macintosh project, or, if Microware were working with Apple early enough, the Lisa might have had OS-9/68000 as its original foundation OS. The Toolbox would have been a collection of OS-9 modules.

With a shared technological base, the Lisa and the Macintosh would have shared most of their software architecture and the success of either would have supported the success of the other, the Lisa positioned as an office machine class computer and the Macintosh as a true personal computer at a price within reach of individuals.

A/UX would never have been necessary. Copland could have been NeXT, instead of a failed mess of marketing dreams.

IBM PC? 

IBM would have had to re-think that launch. Even if they had ended up using the 8088, they wouldn't have dared launch it with PC-DOS. They'd have been motivated enough to overlook the miscommunications with Kildall, so maybe MP/M. Or maybe they could have gone to TSC and got a Uniflex/8086 -- that might have been achievable before year-end 1981. Or maybe they'd have been sensible enough to scrub the 8088 prototype and redo it with a 68000. 

Or simply copy the OS-9/6809 gambit, get it out in August, and put their stamp of approval on Apple and Tandy. Or, more likely, set up two lines of PCs, one based on the 6809 and one on the 8088. And when OS-9/68000 came out, simply add another line based on the 68000.

At any rate, we'd have had a much more pluralistic market, relative to CPUs. Whether that would have improved the substance of the CPU wars or pushed the wars more toward pathological can't be seen from here, but we could hope:

Among other actual fixes to the 80x86 architecture, Intel might have been motivated to stretch the segment register widths in the first iteration of the 8086 line, instead of just adding a DMA controller to the register-poor model continued in the 80186. This might have allowed them to avoid most of the detours of the 80286. (I think it's doubtful. They had the heritage of the iAPX 432 to get over.)

Motorola, on the other hand, might have made a fully 16-bit 6809 capable of 24 or 32 bits of address. True segment registers? Or maybe just extending the width of the index registers and the direct page register? (I'd lean toward the latter, actually.) Hopefully, they'd have fixed the infelicities I've mentioned above, and a few others related to system/user space separation, that I haven't.

And maybe, just maybe, instead of over-designing the 68020, Motorola might have taken the lessons of the 6809 and the nascent RISC designs to heart and refrained from adding instructions and addressing modes that took more time and more bits of code than simply doing the same thing with existing instructions, and generally added to complexity more than utility. With a simplified target run-time architecture, they could have brought a fully tested, true 32-bit internal 680X0 to market much more quickly.

Commodore, of course, would have jumped on OS-9/6809, if they wouldn't have been doing it alone.

And Tandy would have quit puttering around and focused on the Color Computer line, and had a Color Computer 3 equivalent ready, probably with DMA and other business-class features, when Microware released Multi-vue in 1983 or '84.

Who knows what would have become of Microsoft? We can suppose they would have built their company on Xenix. Microsoft BASIC running on Xenix? Heh. But, yes. We can guess that "Windows" would have remained a GUI paradigm, instead of becoming a captured trademark of Microsoft. Or maybe Bill Gates would have doubled down on "Windows", but at least it would have had Xenix underneath.

BSD/Research Unix would probably have remained the dominant OS in colleges.

Minix, Xinu, and such would still have been developed. But Minix probably would not have been written first for the 8088, since the 8088 would have been left behind much earlier.

Likewise, the GNU re-implementation of the Unix Workbench. With more solid microprocessor technology to choose from and earlier implementation of the core tools, the migration from LISP would not have been necessary on the one hand, and, on the other hand, the vaporware kernel for Hurd might have seen real implementation by the early 1990s.

Linus might still have made his own kernel, but probably not on the 80386. But he might not have felt the need to, if the Gnu/Hurd OS were already there.

How's that for alternate reality?

(Yeah, I've been thinking about this for a while. Maybe too long. In fact, I'm working on a novel based in something like this alternate reality, but a little different.)