TRS-80 Model 16B versus Tandy 6000 Differences?
Benson Chow
differences, electronically, between these two machines.
I noticed I could not boot Xenix 3.2 on my 16B, and the T6000 I saw was
one *h*ll* of a lot faster to run the hard drive. When I first got my XT
with 3:1, I thought it was slow, then I revisited the 16B and was quite
dismayed. I wonder if the hard disk controller could do better than 8:1
interleaving on my disks now, or maybe that disk I was using had something
much less than the 90ms drives I had in my 16B. Or maybe it was just
Xenix 3.2? Anyone know of the specifics?
Just curious!
David J. Pittella
If you compared a 16B HD and 6000 HD (both with internal 15 meg drives),
you would find that the only difference would be the 68000 CPU and memory
boards were had been redesigned on the Tandy 6000.
The 16B CPU ran at 6 Mhz and the 6000 CPU ran at 8 Mhz. The Tandy 6000 CPU
board was "redesigned" - processor speed was not the only change. I don't
think I ever really saw any detailed comparison of the 16's 68000 CPU design
versus the 6000's.
I am pretty sure that the 16's were designed to run Xenix 1.X, with 1.3.X
being the last release.
Obviously the 6000 would run 1.X and 3.X.
The 16B memory boards had a 128 meg and could be chipped up to 256K (used
64K X 1 DRAM), it took (4) memory boards to get to 1 Meg on a 16B.
The 6000 memory boards had 512K and could be chipped up to 1 Meg (used 256K
X 1 DRAM).
I wonder if the 6000 you used had an external 70 meg which had a faster
average access time.
The Tandon TM503 15 Meg - lists an 85 ms average access time, as this drive
used a stepper motor to position the heads.
My 2 cents worth - I was always under the impression that Xenix 3.X on the
6000 performed better in general over 1.X on a 16?
Davep
"Benson Chow" <blc+...@q.dyndns.org> wrote in message
news:Pine.LNX.4.44.020401...@q.dyndns.org...
Frank Durda IV
: Benson:
:
: If you compared a 16B HD and 6000 HD (both with internal 15 meg drives),
: you would find that the only difference would be the 68000 CPU and memory
: boards were had been redesigned on the Tandy 6000.
Not exactly. Real 6000s had a slightly different power riser, or were
refitted with thick wires running up the back to be able to get more current
capacity to the top end of the card cage. They also had built-in cooling for
the tower, instead of having none of having it kludged into the back door,
aka "The Turbo Fan Mod". There were also some basic modification baselines
on motherboard and cards. Technically, almost all of the electrical mods
could be applied to a 16B getting them close to a 6000.
: The 16B CPU ran at 6 Mhz and the 6000 CPU ran at 8 Mhz. The Tandy 6000 CPU
: board was "redesigned" - processor speed was not the only change. I don't
: think I ever really saw any detailed comparison of the 16's 68000 CPU design
: versus the 6000's.
: I am pretty sure that the 16's were designed to run Xenix 1.X, with 1.3.X
: being the last release.
Not quite right. A minor mod to the various 68000 CPU boards would allow
XENIX 3.x to run on any board. Without the mod, XENIX 3.x would not boot.
Requiring the mod was my idea, as I wanted the function that the change
provided.
: Obviously the 6000 would run 1.X and 3.X.
The PAL mod is the only difference between running 1.x and 3.x, and I believe
it could be applied to all CPUs, including the old "dog-eared" 6MHz CPU cards,
although Tandy was trying to get those out of service and may have claimed
that they could not be upgraded (they could be).
: My 2 cents worth - I was always under the impression that Xenix 3.X on the
: 6000 performed better in general over 1.X on a 16?
I sure hope it seems that way. A very dedicated group of about five people
including myself spent a lot of time throwing away as much of the junk
provided by Microsoft and some earlier Tandy programmers and trying to get
XENIX 3 as good as possible, particularly the XENIX 3.2 release, which was
almost entirely a "black project", not presented to management until largely
done. Anything not running MS-DOS was already out of fashion, so it took
a lot of arm twisting to get it released. I personally sweated over every
line of code in every Z80 driver several times, squeezing clock cycles out
and benchmarking endlessly.
When I couldn't get any more speed out of the Z80 code, I started writing
better optimizations for the C compiler that would speed up the kernel.
(Quite a jump for someone who was learning C by working on the PCC compiler
and making the optimizer several times more clever.) Every compiler
optimization that appeared in 3.2 XENIX was one I came up with. Most are
enabled when -O is used, but a few (I think it was -a and -u) you had to
request. None of this effort was sanctioned (or really known) by Tandy
management.
All this work got the optimal hard disk interleave down to 3:1 (1:1 was
impossible on the 1010 hard disk controller, and 2:1 was just beyond what
the System III kernel could manage, at least that was the case when I
started working on the compiler - it might work now). I remember that for
one release (probably 3.0), management selected a 4:1 interleave, even
though benchmarks said 3:1 was more suitable. The decision was arbitrary.
In earlier XENIX releases, the hard disk interleave was at 8:1.
The floppy diskette format interleave was 1:1, although the filesystem
had a soft interleave of about 6:1. The floppies slower rotational
speed and slower transfer rate is what allowed the 1:1 interleave, along
with a reasonably clever bit of Z80 floppy driver work, one of the few
pieces of Z80 code to remain largely untouched until 3.2. (To be honest,
after KarlB wrote it, we were all scared of touching it.)
Internally, we were competing the 6000 against the 3000HD, and it was fun
to have the 6000 be a bit faster every week than what the 286-8MHz could do.
This behavior seemed a bit odd to some, since officially we were working on
the 3000 XENIX, and doing the 6000 XENIX improvements when management was
not looking or while we were waiting for Microsoft to deliver a System V-286
release that would actually link or to send "release" diskettes that
weren't unformatted, with MS blaming the lack of any magnetic pattern on
Fed-Ex, not on their shipping blank media just to hit a target release date...
The double-sided XENIX 3.2 release was done not to show it could be done,
it was done to save the release, because the buyer didn't want to have to
ship four diskettes (he didn't want to ship ANYTHING for the 6000), and for
some reason thought two double-sided diskettes would make the product
cheaper to build. Whatever made the release happen, we did it, because we
knew this was the last release ever for 68000 XENIX.
Even after 3.2 was approved, we had to hide stuff on the distribution
diskettes or not document functions because the project was on such thin
ice. Support for the 2000 Keyboard was something we had to hide, because
that was *NOT* an official hardware configuration, so we knew the Tandy
QA group would block the entire release if they knew this was in there.
Same thing for the four-port serial card drivers, or the 68010 support,
or the games. Games always got hung up in QA if they couldn't easily prove
that they had no bugs and could actually be won, the reason that DeskMate
only came with Hangman. When Zork originally went in there for testing, it
got stuck for over six months, because QA couldn't figure out how to not
be killed.
The 68000 MMU had similar political problems, and the buyer who was being
forced into shipping it (a Exec VP found out it existed when we asked for a
design release and the VP wanted to know why this item wasn't being
developed to be a product as we already had ten orders internally for
hand-built units), so the buyer intentionally priced it so that it would
cover all possible development and manufacturing costs (as well as the cost
overruns on two unrelated projects) in the first (and only) production run,
then made the production run very small. That's how one PAL, two 74 series
ICs and two sockets somehow ended up costing over $400 each. The MMU was
actually was developed as another "black project" (a hardware engineer was
going to make some for the software engineers' personal 6000 systems), and
so Tandy didn't exactly spend much of their own money in bringing this
product to market, copying the design and having the same hardware engineer
do the PCB.
On the software side, we had already devised the kernel changes on our own
time to drive the MMU, and had a wire-wrap prototype that worked long
before Tandy ever got involved officially.
Frank Durda IV - only this address works:| The Gartner Group recommends
<uhclem.apr02%nemesis.lonestar.org> | that any site using Microsoft IIS
| immediately seek alternatives until
This Anti-spam address expires Apr. 30th | IIS can be completely re-written."
Kelly Leavitt
Frank Durda IV wrote:
>
> David J. Pittella <davepi...@earthlink.net> wrote:
> : Benson:
> :
> : If you compared a 16B HD and 6000 HD (both with internal 15 meg drives),
> : you would find that the only difference would be the 68000 CPU and memory
> : boards were had been redesigned on the Tandy 6000.
>
> Not exactly. Real 6000s had a slightly different power riser, or were
> refitted with thick wires running up the back to be able to get more current
> capacity to the top end of the card cage. They also had built-in cooling for
> the tower, instead of having none of having it kludged into the back door,
> aka "The Turbo Fan Mod". There were also some basic modification baselines
> on motherboard and cards. Technically, almost all of the electrical mods
> could be applied to a 16B getting them close to a 6000.
>
> : The 16B CPU ran at 6 Mhz and the 6000 CPU ran at 8 Mhz. The Tandy 6000 CPU
> : board was "redesigned" - processor speed was not the only change. I don't
> : think I ever really saw any detailed comparison of the 16's 68000 CPU design
> : versus the 6000's.
> : I am pretty sure that the 16's were designed to run Xenix 1.X, with 1.3.X
> : being the last release.
>
> Not quite right. A minor mod to the various 68000 CPU boards would allow
> XENIX 3.x to run on any board. Without the mod, XENIX 3.x would not boot.
> Requiring the mod was my idea, as I wanted the function that the change
> provided.
>
Do you remember what this mod was, and can it still be done? Will you
share it? I have three different 68000 boards and I know at least one of
them is from a system that used to run Xenix 3.2x.
Thanks either way,
Kelly
Kelly Leavitt
these lying around then no go on upgrading any existing model 16 boards
that have not been updated.
Thanks,
Kelly
Frank Durda IV
:> XENIX 3.x to run on any board. Without the mod, XENIX 3.x would not boot.
:> Requiring the mod was my idea, as I wanted the function that the change
:> provided.
Kelly Leavitt <k...@lion.com> wrote:
: Do you remember what this mod was, and can it still be done? Will you
: share it? I have three different 68000 boards and I know at least one of
: them is from a system that used to run Xenix 3.2x.
The "official" repair instructions only provide the mod for the "short"
boards. It requires the replacement of two PALs, U36 and U48, along
with several cuts and jumps, adding a much larger ground wire (needed
anyway), and adding a 330pf cap.
Here are the ones I have:
(some typos exist in the original document, but I think I got most of them
and hopefully didn't add too many new ones)
----------------------------------------------------------------------------
DATE: July 11, 1985
REVISION DATE: July 11, 1985
BULLETIN NO.: 12/16B:44
PRODUCT: 26-6004/5/6 Model 16B
SUBASSEMBLY: AX-9416 6 MHz (short) 68000 CPU board (All Revisions)
----------------------------------------------------------------------------
PURPOSE: Describe modifications to allow XENIX 3.0 to run on a
6MHz CPU board.
----------------------------------------------------------------------------
DISCUSSION: The following describes the procedures for modifying 6 MHz,
or "slow" 68000 CPU boards to allow the running of XENIX
System 3. It is important to note that this modification
applies only to the "short" 68000 CPU's only.
The "long" 68000 CPU boards cannot be modified to run
XENIX System 3. [Although it was technically possible. - Ed]
The terms "long" and "short" 68000 CPU board refers to the
width of the board itself. These boards can also be identified
by the component location number silk screened on the board.
For "long" boards, the 68000 processor is located at U22.
On the "short" boards it is at U19.
----------------------------------------------------------------------------
PROCEDURE:
NOTE: The parts required for this upgrade will be supplied in the upgrade kit.
1. Install the new PAL in U36.
a.) Remove the old PAL in the U36 position on the 6MHz 68000 CPU
board.
b.) On the new PAL (U36), bend pin 5 up so as not to come in
contact with the socket when installed.
c.) Install new PAL U36 (device number 3646D4, or 46D4)
d.) Jump U36 pin 5 to U25 pin 9.
2. BERR modification.
a.) On the SOLER SIDE, cut trace at U21 pin 9.
b.) Jump U9 pin 4 to U33 pin 13.
3. Install the new U48 PAL.
a.) Remove old U48 PAL (device type 16R6)
b.) Install new U48 PAL (decice type 16R4) This new PAL
will have check sum 483999 stamped on top.
4. WAIT modification.
a.) Add 330pf cap from the ground end of C43 to the feed-thru
near the 5 volt end of C37 (this feed-thru is hooked to
TP-28).
b.) On the SOLDER SIDE of the board, add a ground strap jumper
(22-24 gauge stranded wire) from the ground end of C29 to the
ground end of C28.
5. Configure the refresh jumper to E1-E2 (E2 is the middle pin).
6. Ensure compliance with ALL other Technical Bulletins, paying
particular attention to the following:
12/16B:10
12/16B:23
12/16B:24
12/16B:39
12/16B:40
7. Reassemble unit and test with 68000 diagnostics and XENIX 3.0
[or later].
REPLACEMENT PARTS LIST
New PAL U36 MX-2125 26-6021 (REPAIR PART ONLY)
New PAL U48 MX-2124 26-6021
330pf capacitor CF-1830 26-9999C
Ground Wire Use 22-24 gauge insulated stranded wire.
----------------------------------------------------------------------------
The PALs are the tricky thing to get, although I might still have a way to
get the PAL equations. I got an offer for free samples of PALs in 1989
and had a bunch of the 6000 and Model 4/4P PALs duplicated without having the
security fuse blown (which means that they can be copied), but I haven't seen
any of those parts in years. They are buried here somewhere.
All that said, I could probably create a version of z80ctl that doesn't
require the hardware function that the modification provides, but the
resulting system may run somewhat slower than a modified system runs.
The mod allowed the Z80 to take control of the 68000 bus without allowing
one or more intervening 68000 CPU cycles and the dead cycles between when
the 68000 released the bus and the Z80 took control, and when the Z80
gave the bus back. Only 68000 refresh could cause the Z80 transfer to wait
when in that mode. The idea at the time was to increase the speed of
Z80 block transfers to and from disk, as we knew there was a bottleneck here.
However, on the 8MHz 68000 processors, it might have been slightly more
efficient to let the original dithering of cycles occur since the 68000
might be able to get a few other things done while the block was being
transferred.
For complicated reasons, all the Z80 XENIX drivers and buffers had to fit
into about 16Kbytes of Z80 RAM, and there wasn't room for both the old and
new-style drivers, not when you added in the new requirement of a SCSI
driver for the Iomega units. It was very cozy.
Frank Durda IV - only this address works:|"How do I know? I wrote the code,
<uhclem.apr02%nemesis.lonestar.org> | that's how."
This Anti-spam address expires Apr. 30th |
Copr. 2002, ask before reprinting.
Kelly Leavitt
probably not be able to get them running Xenix 3.2. I do have a short
version with all the mods in place. Happy Days!!. Now, if I can only get a
machine running with the parts I have from that machine.
I have all the individual cards from a 6000HD machine (including the BIG
mother board, HD controller and riser), but no case, no power supply, no
tube, no card cage and no known good 8" drives. Maybe I should keep an eye
out for a model II and replace everything inside it (of course it probably
won't have the card cage rails). Would the power supply on this type of unit
work if I put the hard drive in an external case?
Thanks for all of your help so far.
Kelly
"Frank Durda IV" <uhclem...@nemesis.lonestar.org> wrote in message
news:Gu4J6...@nemesis.lonestar.org...