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.