From: uhclemLOSE.apr06@nemesis.lonestar.org   
      
   Bill Vermillion  wrote:   
   : As I recall the system could only address 1MB of RAM, and the extra   
   : 1MB was a RAM disk, with a driver from Bob Snapp.   It made a   
   : tremendous performance increase.   
      
   The stock offset and limit registers on the 16/16B/6000 would only work up   
   to 1Meg of RAM and they only came into play in user mode.  Supervisor mode   
   saw the 16Meg address space as flat with no offsets, even though the   
   16/16B/6000 address space wrapped at 8MB.   
      
   Bob wasn't the only source of hacks to just use the extra RAM as buffers   
   (or in some mods, buffers and other kernel memory), which could always be   
   accessed in supervisor mode, which is where buffers are accessed normally   
   (but not always).  People inside Tandy came up with similar changes and   
   those managed to reach the public through non-official channels.   
   Although having more buffers almost always provided more speed (there was   
   a line, above which having more buffers slowed things down unless you   
   completely replaced the buffer management strategy), there was more speed   
   to be had by doing the right thing.   
      
   The holy grail was to actually use all the RAM as system memory, with   
   any above 1MB treated no differently than the first meg.  The MMU Extension   
   board designed by Jerry Ballard (a simplified variation of a personal   
   design MMU extender add-on he had done with the help of the software   
   guys as a "black" project sometime earlier) sold by Tandy would allow up   
   to four Meg of RAM to be installed in the system.  XENIX 3.2 (I think that   
   was first public version) had built in checks to detect its presence and   
   that of more than 1MB of RAM, and it would use up to four MB for kernel,   
   buffers, programs, whatever.  In practice, most people only put 2 or 3MB   
   in, due to limits in the number of cards they could fit in the system.   
      
   The MMU extender board simply logically adding additional bits to the   
   existing offset/limit registers by being wired into the carry-overflow   
   outputs of the original adding/compare chips, then back to where those   
   original carry-overflow signals would have been wired.  The OS wrote half   
   of the desired offset and limit values to the original registers, and   
   the rest to the additional registers, so the code change to support the   
   MMU was fairly small.  There was probably more code involved in testing   
   for the presence of the MMU extension than in actually operating it.   
   Much cleaner than trying to manage part of memory as behaving different as   
   was the case with the various buffers-above-1MB modifications.   
      
      
   The Tandy Merchandising buyer of the day didn't want to sell the MMU   
   product at all, hoping the 1MB limit would hasten the demise of the   
   16/16B/6000 system and get people to buy whole new 3000/4000 computers,   
   which he also was the buyer for.  However, the MMU product got forced   
   on him when the engineer who designed one and wanted to make some   
   for co-workers asked for a release from his VP to make and sell such   
   a device himself without getting into trouble, and the VP instead   
   scribbled a note to the buyer asking "Why aren't we selling this?".   
      
   Trapped but determined to not be defeated, the buyer agreed to sell it   
   as an official product (so that the employee could not sell such a   
   device), but the buyer also exploited a curious policy of Tandy to make   
   certain that the sale of the MMU Extender was unsuccessful.   
      
   Tandy had this rule that all the development, engineering, testing,   
   documentation-writing and what-not costs had to be recovered in the first   
   production run, REGARDLESS OF THE FIRST RUN SIZE.   So if you had a   
   gadget that cost a dollar in materials and royalties to make but had   
   $500,000 in Non-Recurring Expenses (NRE, also called NRC), you had better   
   order 500,000 of them initially so that they only cost $2.16 to ship   
   from the factory ($2 plus the 8.5% corporate profit charge),   
   which would have another 8% or so added by the Tandy   
   warehouse/transportation groups, and once it reached the stores, the   
   store would add a minumum of 45% for the individual stores profit   
   (store up-charges were sometimes as high as 400% for some items), so the   
   $1 item would likely be sold at the retail level for $5.95 or even   
   $9.95 if it was felt the public would buy at that price.   
      
   Normally, the Tandy buyer for an item would place a fairly large first   
   order for the item in question to spread out the NRE costs.  For example,   
   you would certainly make at least a couple per store (7,000 stores back   
   then), plus some for regional inventories.  15,000 units was considered   
   a tiny initial factory build order for computer systems.   
      
   So, our evil "merchie" buyer instead ordered about 250 of the MMU extender   
   boards.  Since the device had been designed in the engineers' spare   
   time, the changes were already in the OS that had been released, and   
   the documentation was merely the installation instruction sheet for the   
   repair center installer that the engineer essentially wrote, there was not   
   that much NRE.  Despite that, they went back and pretended like there   
   was a month of software development and some other invented charges   
   (covering some overruns on other projects).  This bloated each MMU extender   
   with something like $90,000 in NRE charges and turned a little circuit board   
   with perhaps $40 of cost into a $400 (plus installation) product by the   
   time it reached the service centers.   
      
   To the buyers annoyance, all the MMU extenders made sold anyway, but no   
   additional orders were placed (any additional run would have left the   
   factory for about $43.40 each which would have been far more affordable),   
   but the 255 were all that were made by Tandy.   
      
      
   This is what happens when the buyer for a given machine wants it to die   
   so he can sell its deemed replacement to his existing customer base all   
   over again, AND for some reason the traditional trick of starving the   
   old machine of advertising, supporting materials, bug fixes and available   
   software fails to kill the old product off fast enough.   
      
      
   Technically, the 16/6000 could have had almost 8MB of RAM, if you could   
   solve line ring, jitter and other bus timing/level issues.  Adding RAM   
   beyond 7-something MB was not practical because of some design choices   
   made space when the hardware was first designed in 1982 regarding where   
   I/O devices were mapped.  Likely, the concept of anyone having a machine   
   with even 1Meg of RAM in a small form factor computer and cost less than   
   $10,000 was just unthinkable.  So things ended up in the 16/16B/6000   
   68000 address map in places that made the contiguous address space for   
   RAM limited to the 7-something MB amount, and having contiguous memory   
   is a big deal on a processor that doesn't do virtual memory/paging   
   and doesn't have restartable instructions, which the 68000 didn't have.   
   (The 68010 had restartable instructions, but still lacked virtual memory   
   capability.)   
      
      
   : They really were wonderful old beasts, and the Xenix 1.3.[x] has   
   : a 76K kernel on my first machine.   
      
   The bootstrap code for a modern operating system is usually larger than   
   the complete kernel was for any of the 68000 XENIX platforms, or VAX   
   BSD 4.x for that matter.   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)