------------------------------
On Tue, Feb 5, 2013 5:11 PM PST William Donzelli wrote:
>> In the 40s and 50s, I wonder if Hazeltine made more off their patents than
>> actually selling product.
>
>No, probably not. Hazeltine was a pretty big defense contractor during
>World War 2, the 1950s, and beyond.
Grumman was a ginormous defense contractor on Long Island. Yet at some points every jamoke with a drill press was making parts for them. The final product was *all* Grumman though. They weeded a lot of their suppliers out over time.just in time to close up shop.
>Hazeltine was a very old radio company, going back to the 1920s, although based around design/patents/licensing rather than manufacturing, originally at least.
>
>Terminals were an offshoot or sideline.
Very little of which were likely made by them anyway. But what do I know. F'rinstance the Sperry ?/Leading Edge Model M was wholly a Mitsubishi product. Even the monitors were M*, and at least 1 model externally bore a striking resemblance to the TRS-80 CM-1 used w/the model.2000. Like anyone cares.
At 04:47 PM 2/5/2013, Bob Vines wrote:
>Hopefully some of this helps. I have a couple of RL02 drives that I'd
>like to try with my PDP-8/E one of these days. (Assuming that I can
>get an "-8"-formatted pack.)
There's no format difference. There's a bit called the "mode" bit
(software selected) which selects 12-bit mode or 8 bit mode for the
RL8A. In 12-bit mode, a sector contains 128 12-bit words or 256 8-bit
bytes - 64 bytes are wasted in 12-bit mode. (Also, with 12-bit mode,
you can't DMA more than one sector at a time.) I don't know for sure,
but I'll bet that OS/8 runs in 12-bit mode.
You *do* have to run a magic formatter program on the '8 that fixes up
the bad block map into where OS/8 expects it.
As far as the jumper Charles is referring to - there's a pair of
jumpers on the RL8A that need to be configured.
W8 is installed to support the RL02 (W8), W9 installed for the RL01.
Only one of those jumpers are installed at a time.
If the zero drive is working, W8 is installed. What this does (when W9
is installed) is to limit the track delta register to the RL01 size.
-Rick
I forwarded this RL02 vs OS/8 question to Charles Lasner, his response
follows the original question.
[snip]
> Date: Sun, 3 Feb 2013 13:45:46 -0600
> From: Charles <charlesmorris800 at centurytel.net>
> To: cctalk at classiccmp.org
> Subject: Using two RL02 drives on OS/8?
> Message-ID: <7E1278E1-BA46-45AD-99F6-FB38443AC1A0 at centurytel.net>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> I'm trying to find a manual detailing the operation of an RL02 under
> OS/8. The Bitsavers archive only has manuals new enough through the
> RL01.
> Can someone point me to the proper documentation?
>
> Meanwhile, although several years ago I did manage to build an OS/8
> system with two RL02's on SIMH and transfer that disk image to an RL02
> pack, and BUILD shows the appropriate device names, when the second
> drive (1) is accessed, the data actually comes from the boot drive
> (0). Just now getting around to playing with it again.
> Version: OS/8 KBM V3T, CCL V3E.
>
> The relevant portion of the BUILD printout: (I didn't have enough
> handlers to add the "leftover" E drives anyway)
>
> R2SY: *SYS R20A
> RL20: *R2A0 *R2B0 *R2C0 *R2D0
> RL21: *R2A1 *R2B1 *R2C1 *R2D1
> DSK=RL20:R2A0
>
> I can even unload the heads on Drive 1 and ask for a DIR of its
> logical drives, and not only does OS/8 not hang or at least give a
> "NOT FOUND" error, it gives me the data from the corresponding logical
> drives on Drive 0! ASSigning DSK to the other drive doesn't make any
> difference...
>
> What am I doing wrong?
> thanks
> Charles
>
[snip]
> End of cctalk Digest, Vol 114, Issue 4
> **************************************
**********
>From CJL:
I can't guarantee this is the problem, but I do see a potential driver
head count problem here:
Let's start with the weirdness that is OS/8 RL support in the RL01:
To support the RL01, there is a controller card jumper to set. I
never found out EXACTLY what it does, but I can describe that
constrained to the only rational answers.
The RL02 has twice as many tracks to manually seek over [! Wonderful
for real-time, since it doesn't interrupt! Ask the -11 people about
creating RL seek-check tasks.]
Thus, on the RL01 [which I suspect cannot be supported on the DECmate
I's obscure RL278 spec'd for RL02 generally] you have to make sure
that the proper bits get to the controller, which apparently can
stupidly step an RL01 into never-never land if you let it.
The programming is such that you create the signed difference between
where you apparently are and where you want to be and send out a step
the head over the direction indicated and number of steps. Thus, the
arithmetic high-order bit has to become ignored.
Thus, what the jumper does is obviously one of the following:
1) Ignore it; you only see the rest of the bits in the drive. I
think this is least likely.
2) Set the bit to the same value as the one immediately to the right
regardless of what the instruction says to do. This is a signed
quantity because it could be a seek to lesser or further out as
required, etc.
In any case, this is an RL02 question, so we can table that factoid; I
just want to know because it does mean that software could be then
written to work with mixed situations of RL01 and RL02 on the same
controller the way the -11 does it. Obviously they were told to make
the bit being ignored/adjusted the correct value from the beginning; I
think many knew the RL02 was not that far in the future when the RL01
was released, so their software designs were cognizant of the then
future, etc. Unfortunately, it is a known quantity that much of the
RL software is sloppy and can be counted upon to not be counted upon
regardless of what the correct thing to do is, thus this stupid
compatibility jumper, etc. [I never wrote a P?S/8 handler for it,
thus I don't know. Moreover, OS/8's handlers are probably the most
compromised for R-L devices; any actual correct performance with the
switch off for RL01 would be a happy accident; no effort was expended
to get it right; the jumper was known the exist. In P?S/8, I don't
have the handler limitations, thus could get that right as well as a
whole lot of other things; OS/8 is an awful kludge and incompatible
with all other usages of RL01 and RL02, etc.]
All that said, here is how you get it to work:
First of all, not only do you have to perform a general formatting
diagnostic that then builds a collection of bad block tables. [I
believe there is a "factory" master table to never erase, and then
some newer table to add in found-in-the-field more bad spots, etc.]
All of that is done in an 8-bit orientation. To my knowledge, it is
difficult at best to access this data in byte mode in one pass, so
clearly 2:1 interleave is part of the design discussion regardless.
In any case, it is the case of OS/8 using 12-bit mode.
OS/8 cannot access the real bad block tables. Thus, there is an OS/8
crutch secondary program. The RL01 is divvied up into "wedges" of
unequal size. Two larger ones and another one 1/2 the size of the
other two. I have no idea how they account for this; in OS/8 PIP
there is supposed to be a table where by internal logical device
number you patch in the device size for directory zeroing purposes,
etc. Thus, I guess the small wedgie is considered a different logical
device despite it possibly being part of a same or similar non-system
handler set [system handler too tight] with the same general I/O code
just handling a different wedge of the disk, etc. They got something
that is viable, but I am not sure; it could be examined assuming you
have a system where PIP knows what to do certainly, etc.
The wedges and the little wedgie are each evaluated. As a logical set
of sectors in order to handle itself, there is a restriction that is
pretty stupid: They insist that the very highest sector of the entire
wedge/wedgie is error-free else OS/8 cannot use the pack! However,
only the inner-most tracks are guaranteed error free from the factory
because that's where the *REAL* bad block table[s] is/are. Expecting
a block to actually be good when it is potentially in the main
table[s] marked bad is preposterous, And I have heard of packs
hand-picked to allow OS/8 family versions to like it because you must
relegate it to something else that knows how to play with the bad
blocks the way the big boys do, etc.
So, assuming that risky situation is somehow OK, that becomes a
twelve-bit-oriented record of the bad blocks in the format of which
logical sectors of that wedge/wedgie are known bad. This little table
is written in the highest logical record of the wedge/wedgie. No
handler is maximum size because the table is reserving that last one
assuming all are error-free. I would also suspect that there is no
way to support it unless a few of the first of them [again, in this
logical order of where in the wedge/wedgie they are, etc.] are known
good. Certainly applies to the bootable system device one[s].
The handler proceeds to calculate the sector the caller is accessing.
For all entries in the table prior to that desired logical record, the
record that is ultimately used is bumped by one to "straddle" the bad
spot. Thus, we now have the corrected logical record in the
wedge/wedgie we want. Notice that this process has to be repeated for
any sector in the call since your neighbor could be on the other side
of the sinkhole so to speak. [I can see that physically adjacent
sectors could all be bad, even with a 2:1 interleave; physically 3 or
4 in a row for example.]
Then the handler converts that to the physicality of actual
track/head/sector and does the intended read or write operation, etc.
Go back and repeat all of the above as necessary from the original
caller's marching orders, etc.
The ordering of the sectors is through a 2:1 interleave obviously, but
remember, all the wedges/wedgie that you don't "own" are in the way in
the rotational latency sense. One revolution traverses all physical
sectors, but you only get at best 1/2 wedge's forward progress [or
worse, one half wedgie, again I mean the one that is 1/2 the size of
the two larger ones.] Thus, the overall overhead is gross as the
throughput is far less than implied by 2:1 interleave. [Historical
note: Instead of playing with this crap when it was released, I was
using the DSD-240/Western Dynex drive. 5 MB cartridges removable
looking like RL disks superficially, but not servo-driven, rather a
better mechanism than an RK05 that admittedly needed alignment but
held it quite well. More importantly, it was over another 5.0 MB
fixed disk. Thus, with some "Tower of Hanoi" juggling, you can
completely back up everything on two 5 MB packs and it is damn fast.
DMA with 1:1 interleave, all sectors addressed truly in physical
order, a smart controller, no bad blocks whatsoever, smaller logical
sectors so each transfer was one or more PDP-8-sized page blocks so
completely at home in either P?S/8 or OS/8 with elegant and easy to
write handlers for both systems. The command as well as the data are
initiated by DMA and then it just does it automatically with a done
and error status after-the-fact so low interrupt overhead, etc. In
short, absolutely no problems whatsoever. [Note: Part of the
concepts that implemented the DSD-240 were incorporated in the MDC8
>from CESI; I wrote all the handlers and support utilities.] The media
guaranteed to be error free and delivering the promise; what a
comparison between elegance and DEC's awful crap; this was well on the
way more than merely the begiinning of the end; it was already part of
the accelerating slide to eventual oblivion.]
So much for the RL01. Note that gets you three handlers for the
entirety of one disk with one handler's range 1/2 the size of the
other two.
That gets you three handler entries in BUILD if this is an RL01. But
what of the RL02?
Well, the wedgie is still smaller than the other two, but it doubles
in size to be the equivalent on the RL02 of a wedge on an RL01.
However, the RL02 wedges are twice the size that OS/8 can handle.
Thus, an analogy to the RK8E/RK05 can be drawn. Each pack cannot be
addressed with one handler; you need two of them each about 2/3-3/4 of
the maxed-out OS/8 size. In this case we are talking about a
superwedge that has to be logical cut in half as well, back to the
equivalent of one RL01 wedge each.
Thus, the RL02 gets you FIVE handlers all each addressing the same
amount of physical space.
>From the BUILD output, it suggests groupings of four, not five. It
would appear that there is potential anomaly there. The source code
for the handler will reveal what BUILD is told about the device.
Clearly that problem of logical device for PIP directory zeroing
purposes goes away as they are all know the same logical size, just
that there are more of them, thus there needs to be 5 build-oriented
entries in these handlers as opposed to three as in the RL01 case. I
suspect the confusion comes from there. Maybe you have some mixed
RL01 and RL02 handlers confusing things, etc.
P?S/8 has nearly NINE pages of code to handle system devices, as
opposed to OS/8's only two where the first if a system handler is also
not really a complete page with regard to code for the device as
opposed to reserved locations "around" the handler code, etc. That
concept applies pretty equally to both systems [but I think P?S/8 is
slightly tighter.] The second page is actually not completely
available either as the field 2 code reserves the last 4 words for
OS/8 BATCH. [Come on, folks! The DS/8 people created what they
called "HASP". Two attaboys to anyone who can explain the historical
meaning of the name from an older non-DEC world. Houston, do we have
a problem?] In any case, it got you a batch in 8K, so no reserved
words and no 12K requirement at all, etc. And for those who may not
have heard, P?S/8 BATCH is based on the original R-L Monitor System;
both run BATCH in 4K!]
But P?S/8 system handlers get EIGHT complete additional pages for
their purposes alone. Clearly there is room to read the REAL
bad-block tables and massage them as needed to allow sane bad-block
handling. No wedge crutches, no dependency on iffy sectors, etc.
As these packs age, I suspect OS/8-worthy ones will become less and
less available physically. If you can honor the real tables, you can
tolerate the true intended counts. In OS/8, I think each wedge/wedgie
is limited to something like 16 total errors there, etc. In time,
they will not be usable for the OS/8 kludge [admittedly eventually
perhaps not usable at all!]
**********
Hopefully some of this helps. I have a couple of RL02 drives that I'd
like to try with my PDP-8/E one of these days. (Assuming that I can
get an "-8"-formatted pack.)
Bob
I'm trying to find a manual detailing the operation of an RL02 under
OS/8. The Bitsavers archive only has manuals new enough through the
RL01.
Can someone point me to the proper documentation?
Meanwhile, although several years ago I did manage to build an OS/8
system with two RL02's on SIMH and transfer that disk image to an RL02
pack, and BUILD shows the appropriate device names, when the second
drive (1) is accessed, the data actually comes from the boot drive
(0). Just now getting around to playing with it again.
Version: OS/8 KBM V3T, CCL V3E.
The relevant portion of the BUILD printout: (I didn't have enough
handlers to add the "leftover" E drives anyway)
R2SY: *SYS R20A
RL20: *R2A0 *R2B0 *R2C0 *R2D0
RL21: *R2A1 *R2B1 *R2C1 *R2D1
DSK=RL20:R2A0
I can even unload the heads on Drive 1 and ask for a DIR of its
logical drives, and not only does OS/8 not hang or at least give a
"NOT FOUND" error, it gives me the data from the corresponding logical
drives on Drive 0! ASSigning DSK to the other drive doesn't make any
difference...
What am I doing wrong?
thanks
Charles
Hi there,
If I might please share with everyone on these lists about our upcoming BIG show!
- - - - - - - - - - - - - - - - - - - - -
Announcing the First Ever Vintage Computer Festival Southeast
The original Vintage Computer Festival was founded by Sellam Ismail and held in Pleasanton, California during October, 1997. Now, finally, the southeast region of the US gets its very own!
ROSWELL, Georgia ? February 4, 2013 ? Vintage Computer Festival Southeast ? a public celebration of computer history and nostalgia ? will be held on Saturday & Sunday, April 20 & 21. Our mission remains the same as that very first show:
The main mission of the Vintage Computer Festival is to promote the preservation of "obsolete" computers by offering attendees a chance to experience the technologies, people and stories that embody the remarkable tale of the computer revolution.
We will educate and entertain!
- A large premier exhibit will welcome each attendee as they enter the festival - The Apple Pop-Up Museum which tells the story of how a small start-up company, founded in a garage by two young friends, became the leading consumer electronics and personal computer company in the world. The exhibit displays an exclusive collection of game-changing Apple personal computers and consumer electronic products while presenting the history of the company since its founding in 1976 to the present. An Apple I, the first disk ][ and controller card, original apple ][, original Lisa and even a Xerox Alto are among the rare artifacts to be displayed, plus much, much more.
Within the 6,000 square feet of display space that this premier exhibit occupies will be the following rooms: Pre-Apple Room, Apple I Room, apple ][ Room, Turmoil Years Room, No Founders Left Room, Jobs? Come Back Room, Ive?s Colors Room, iPod / iPhone / iPad Room, The Timeline Lounge and Apple?s Present to the Future Room.
- Dozens of exhibitors will be present from all over the region, plus many from other parts of the country. A large variety of historic computers will be represented in the exhibit hall for live demonstrations by their owners.
- A vintage game station will be available for children and adults to play classic games on classic computer and game console systems.
- Two retrocomputing kit building classes will be held, plus continual, inexpensive introduction to soldering classes.
- Many luminous speakers and special presenters are now being scheduled.
The VCFSE is hosted and produced by the Computer Museum of America and the Atlanta Historical Computing Society.
One-day adult tickets to the VCFSE are $10, with a two-day pass for $15. Children ages 17 and younger are admitted free when accompanied by a parent or guardian. For hours, location, and other details, please visit vintage.org/2013/southeast
Contact:
David Greelish, Director, Vintage Computer Festival Southeast 1.0
david at classiccomputing.com | 770-733-6702
Best,
David Greelish
- Computer Historian, Writer, Podcaster & Speaker
- Founder of the Atlanta Historical Computing Society
http://about.me/davidgreelish
Director of the Vintage Computer Festival Southeast 1.0 - 4/20 & 4/21, 2013
http://vintage.org/2013/southeast/
Thanks for the suggestions.
I've looked for visible arcs as carefully as I can, and have been unable to see any. I've cleaned and resoldered the connections to the transformer, and removed and cleaned the anode connection to the CRT. I don't know if you can remove the anode connection at the flyback end, so I haven't fiddled with that.
Is it reasonable to assume at this point that the arc is *inside* the flyback cover? Is it possible that a component failure outside the transformer could cause arcing in the flyback, or does it mean that the flyback itself is at fault?
The flyback transformer appears to be unobtainium (although if someone knows different, I'd love to hear about it). I guess I'm in the market for a PET video board....
Thanks again,
Rob