4 MEG memory board for model 6000
Kelly Leavitt
is labeled PC60004MR2. HWP (c) 1987. Anyone know anything about these?
Do I need a special kernel build to access it?
There was no hard drive directly associated with this computer (there
were 2 external drive units, but I have not tested any yet).
Kelly
PS Everyone bored of my postings yet?
Bill Vermillion
Kelly Leavitt <kb2...@gmail.com> wrote:
>Wow. Finally found one of these lurking inside a recent model 16B. It
>is labeled PC60004MR2. HWP (c) 1987. Anyone know anything about these?
I had a 2MB in my 16[a]
>Do I need a special kernel build to access it?
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.
A bit of trivia. When Bob was selling these he talked about one
system that was slow and had 4 users. He analyzed it and found
they company could get more work done with 3 users, as the swapping
to the HD slowed things down to the point that 3 could get more
work done than 4.
With the swap on RAM you could put on many users.
I don't know if there were other modifications later to make
the RAM accessible to the machine, but I think it would have to be
a hardware mod.
>There was no hard drive directly associated with this computer (there
>were 2 external drive units, but I have not tested any yet).
My first 16 was when it was discontinued for the 16B. I finally
swapped out the 8MB 8-inch external HD for two 33MB Rodimes from
Bob Snapp.
Actually almost any HD can work. I recovered a system that had
Iomega backups when it's Tandon HD failed - as they were prone to
do. I attached a 5.25" Seagate 20MB externally - case open on the
table for the recovery - and reinstall the backups to that, and
them made serial xfers to a new IBM Model 80, running filePro, just
like the 16.
They really were wonderful old beasts, and the Xenix 1.3.[x] has
a 76K kernel on my first machine.
Bill
--
Bill Vermillion - bv @ wjv . com
Kelly Leavitt
> In article <1145409381.3...@u72g2000cwu.googlegroups.com>,
> Kelly Leavitt <kb2...@gmail.com> wrote:
> >Wow. Finally found one of these lurking inside a recent model 16B. It
> >is labeled PC60004MR2. HWP (c) 1987. Anyone know anything about these?
>
> I had a 2MB in my 16[a]
>
> >Do I need a special kernel build to access it?
>
> 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.
<SNIP>
> Actually almost any HD can work. I recovered a system that had
> Iomega backups when it's Tandon HD failed - as they were prone to
> do. I attached a 5.25" Seagate 20MB externally - case open on the
> table for the recovery - and reinstall the backups to that, and
> them made serial xfers to a new IBM Model 80, running filePro, just
> like the 16.
>
I mentioned the HD only because if I needed the kernel support, I
probably don't have what I need then. I have replaced dead drives in
16s, 6000s, IIs,and 4s. I have a shelf full of st-506 drives for
spares.
Now, if only I could find an archive of all of Bob's goodies. Anyone
know where he went off to?
Kelly
Joel W. Howell III
Bill Vermillion
You might try to find Tom Pancero.
He used to work as a tech for Bob building the boards,
etc., and AISTR he also has been repairing such items. He's at
a printing company in Cincinatti - that for some reason I want to
associate with the old King Records.
The last email address I see for him is from an old 2003 mailing
list. postm...@cobbinc.com
Frank Durda IV
: 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.
The /boot/loader program for FreeBSD 4.10 is 155K, almost double the size
of the entire XENIX 1.x OS.
Frank Durda IV - only this address works:| A sign mounted high on a telephone
<uhclemLOSE.apr06%nemesis.lonestar.org> | pole in the country says: "Please
You must remove the "LOSE" to mail me. | do not shoot at the telephone
http://nemesis.lonestar.org | wires. We appreciate your
Copr. 2006, ask before reprinting. | cooperation, Mr. Cheney."
Kelly Leavitt
> Bill Vermillion <b...@wjv.com> 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.
>
<Big Snip>
> 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.)
So, if I have Xenix 3.2 on the machine with the 4 meg board (which also
had the bernoulli box interface card by the way), then will it take
advantage of any of this 4meg board on its own? Or do I need some kind
of patch? There is definitelty no MMU board on this box. Anyone have
any schematics of the mmu board? It would be an interesting project.
The merchie sounds like a real jerk by the way. Gotta love some people
>
>
> : 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.
>
> The /boot/loader program for FreeBSD 4.10 is 155K, almost double the size
> of the entire XENIX 1.x OS.
I have a fob on my keyring that has more storage than we had back in
1988 while supporting 25 people and a 100k name database.
Kelly