From turner7@pacsibm.org Sat Mar 25 00:49:58 CST 1995
Article: 96209 of alt.folklore.computers
Xref: uchinews alt.folklore.computers:96209
Path: uchinews!vixen.cso.uiuc.edu!uwm.edu!psuvax1!news.cc.swarthmore.edu!netnews.upenn.edu!netaxs.com!pacsibm.org!root
From: turner7@pacsibm.org (Lee Winson)
Newsgroups: alt.folklore.computers
Subject: IBM Logo
Date: 25 Mar 1995 04:39:33 GMT
Organization: PACS IBM SIG BBS
Lines: 10
Message-ID: <3l06q5$80k@netaxs.com>
NNTP-Posting-Host: pacsibm.org
Originator: root@pacsibm.org
Status: RO

I've found some old (1936) IBM manuals and their logo was different--the
words International Business Machines arranged in a circle, like a
globe.  Further, their literature referred to the "International" method
as opposed to the "IBM" method.

[Actually, that old logo would fit in perfectly with their OS/2 Warp
psychedelic ads.]

Anyway, anyone know when IBM switched to the current block letters?
 Thanks.


From turtle@charm.net Sat Mar 25 16:33:01 CST 1995
Article: 96278 of alt.folklore.computers
Xref: uchinews alt.folklore.computers:96278
Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!news.sprintlink.net!news.charm.net!turtle.charm.net!turtle
From: turtle@charm.net (The Turtle)
Newsgroups: alt.folklore.computers
Subject: Re: IBM Logo
Date: Sat, 25 Mar 1995 09:37:38 LOCAL
Organization: Charm.Net Baltimore Internet Access, Hon  (410) 558-3900
Lines: 31
Message-ID: <turtle.88.025849B6@charm.net>
References: <3l06q5$80k@netaxs.com>
NNTP-Posting-Host: turtle.charm.net
X-Newsreader: Trumpet for Windows [Version 1.0 Rev B final beta #4]
Status: RO

In article <3l06q5$80k@netaxs.com> turner7@pacsibm.org (Lee Winson) writes:
>From: turner7@pacsibm.org (Lee Winson)
>Subject: IBM Logo
>Date: 25 Mar 1995 04:39:33 GMT

>I've found some old (1936) IBM manuals and their logo was different--the
>words International Business Machines arranged in a circle, like a
>globe.  Further, their literature referred to the "International" method
>as opposed to the "IBM" method.

>[Actually, that old logo would fit in perfectly with their OS/2 Warp
>psychedelic ads.]

>Anyway, anyone know when IBM switched to the current block letters?
> Thanks.

I found similar materials in a search of trademark materials in a law library 
about six years ago.  The logo dates back a little earlier than 1936 but I 
cannot remember exactly when.

Remember also, that in the 1940s, IBM began using the block-letter logo, but 
it was not the present "blue chips stacked" logo, it was solid letters.  Not 
sure that I remember when they went to the present rendering...

Turtle
______________________________________
|                                    |
| The Turtle         turtle@charm.net|
| Visit the Weightless Dog Home Page!|
| <URL:http://www.charm.net/~turtle/>|
L____________________________________J


From uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!EU.net!sunic!news.lth.se!news.lu.se!magnus Thu Mar 10 17:27:24 CST 1994
Article: 62444 of alt.folklore.computers
Xref: uchinews comp.fonts:11907 alt.folklore.computers:62444 alt.folklore.science:10483
Newsgroups: comp.fonts,alt.folklore.computers,alt.folklore.science
Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!EU.net!sunic!news.lth.se!news.lu.se!magnus
From: magnus@thep.lu.se (Magnus Olsson)
Subject: Re: IBM with _tiny_ letters (was Re: Hermann Zapf)
Message-ID: <1994Mar10.093024.20088@nomina.lu.se>
Keywords: Carillo
Sender: news@nomina.lu.se (USENET News System)
Nntp-Posting-Host: lena.thep.lu.se
Organization: Dept. of Theoretical Physics, Lund University, Lund, Sweden
References: <2lioss$eqj@Times.Stanford.EDU> <OLLI-PEKKA.RINTA-KOSKI.94Mar9130443@anjovis.hut.fi> <1994Mar9.160816.24482@midway.uchicago.edu>
Date: Thu, 10 Mar 1994 09:30:24 GMT
Lines: 68
Status: RO

In article <1994Mar9.160816.24482@midway.uchicago.edu>,
Eric Fischer <enf1@midway.uchicago.edu> wrote:
>In article <OLLI-PEKKA.RINTA-KOSKI.94Mar9130443@anjovis.hut.fi>
>Olli-Pekka.Rinta-Koski@hut.fi (Ola Rinta-Koski) writes in comp.fonts:
>
>>  A while ago, IBM announced that they had, using some novel technique
>>(and utilizing an electron microscope to see what they were doing),
>>used individual atoms to write the word "IBM".

[...]

>I was talking with someone about this last weekend (and got laughed at
>for suggesting that they could have done much better letterforms with
>a seven-pixel vertical to work with) and encountered the question:
>what were the atoms sitting on?  As I recall, the photos showed a dull
>gray background with roundish atoms sitting on top of it, but clearly
>the background had to be atoms too.  Was it a really big atom?
>Several atoms but out of focus?  Very strange...

OK, I suppose it's time to inject some facts among the folklore...

The images as well as the minuscule IBM logo were made with a scanning
tunneling microscope (*not* an electron microscope). It works on a
fascinating but simple principle:

Make a very fine metal needle (only one atom thick at the tip) and put
it at a distance of less than an atomic radius from a surface. If you
put a potential difference between the surface and the needle,
electrons will start to "tunnel" across the gap (this is a purely
quantum mechanical phenomenon, related to the electron's wavelike
properties) and you'll get a tunnel current. This current decreases
exponentially with the width of the gap. Moving the needle by only a
fraction of an atomic radius will create a large change in the current.

Now, put some feedback into the system by adding a servo mechanism
that tries to keep the current constant by moving the needle towards or
away from the surface. Then move the needle across the surface and
register the servo current. The needle will trace out the individual
atoms on the surface to an accuracy of a few picometers (an atomic
radius is about one Angstrom, or 100 picometers). This way, you can
construct images that show individual atoms.

The IBM logo was by some researchers who discovered that they could
make atoms stick to the tip of the needle, and then drop them again by
reversing the voltage. That way, they could pick up atoms (of a kind
different from both the surface and the needle) and move them about to
form letters.

And why was the background blurred? Well, either it was "out of focus"
- if the needle was kept above the "IBM atoms" all the time, the
substrate would be too far away to be detected and would indeed be out
of focus, or they simply told their computers to blur everything more
than one atomic radius below the IBM logo - after all, the output of
the microscope is height information.  Also, I believe they used
rather large atoms (Xenon?) for the logo, while the background
substrate was composed of much smaller atoms. 

A final note: the principle behind the STM is simple (once you've
discovered it). The tricky part is of course building a servo
mechanism capable of positioning the needle with an accuracy of a
fraction of an atomic radius.


              Magnus Olsson                | \e+      /_
    Department of Theoretical Physics      |  \  Z   / q
        University of Lund, Sweden         |   >----<           
 magnus@thep.lu.se,  thepmo@selund.bitnet  |  /      \===== g
PGP key available via finger or on request | /e-      \q


From ljw@formula1.demon.co.uk Thu Jun 29 14:18:40 CDT 1995
Article: 106319 of alt.folklore.computers
Xref: uchinews alt.folklore.computers:106319
Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!news.sprintlink.net!demon!formula1.demon.co.uk!ljw
From: Lawrence Wilkinson <ljw@formula1.demon.co.uk>
Newsgroups: alt.folklore.computers
Subject: IBM 360/30 saga (long)
Date: Thu, 29 Jun 95 18:50:26 GMT
Lines: 417
Message-ID: <804451826snz@formula1.demon.co.uk>
Reply-To: ljw@formula1.demon.co.uk
X-NNTP-Posting-Host: formula1.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.29
Status: RO

For those looking forward to it, here it is.  To the others, sorry
for clogging up a.f.c. Having just re-read it, I can't believe I
ever managed to do all this. LJW 29-Jun-95.

What follows is quite true, to the best of my recollections. I am
a bit sketchy on many of the specifics, as most of this  happened
over ten years ago.  I apologise in advance to anyone who  helped
out and has been denied a mention. LJW 16-May-93.

This  story  starts some time mid 1982, when I was in  my  second
year of an electrical engineering degree and involved with the NZ
Microcomputer Club.  At that time I still had an 8080-based  S100
system,  complete with 8k RAM and KC standard cassette,  but  had
done quite a bit of work on TRS80 clones, Sorcerers and the like.

Someone in the NZMC had been told of the existence of a  computer
in  a cartage company's warehouse, which they wanted to  get  rid
of.   With  no idea of what to expect, myself and  several  other
club  members (Selwyn Arrow and Trevor Sheffield, I  think)  went
along  one evening to the building in central Auckland to have  a
look.  With virtually no light, all we could see almost buried in
between sacks of spices and goodness knows what else were several
large  cabinets.  After a bit of clambering and moving of  stuff,
we ascertained that it was an IBM, and the cabinets had the model
numbers  2030  and  2841 on the side.  There  were  also  several
smaller units, which were pretty obviously disk drives.

Never having had anything to do with IBM products before, none of
us knew what it was, but I was sure of one thing:  If they didn't
want  it, I did!  The club had hopes of starting a BBS,  but  the
size  of  the  unit was a bit excessive, even if  the  price  was
right.   Anyway, it was there for the asking, all we  needed  was
somewhere to put it, and the company would move it for free.   An
agreement  was  drawn up between me and the club (the  OSI  club,
represented by Brian Wilson, was also involved.)

At  the time I was doing some programming work (1802, 6800  etc.)
for  a friend (Steven Murray) who had a small office (like  about
3m  square)  in downtown Auckland, and next to him  there  was  a
larger vacant room.  The rent was about $120 per month.  I  don't
know how I afforded it back then, but I took it.  The catch  was,
it was on the third floor, and there was only a winding staircase
and  a tiny lift for access, so it obviously wasn't going to  fit
up there in one piece.

I  opted to have the main units brought home, where they took  up
most  of one side of our carport, while the smaller  pieces  like
the  drives  went straight to the office.  There were  plenty  of
huge blue manuals, about 50 disk packs and various other odds and
ends.   At  some stage the identity of the machine  was  revealed
when  the  nameplate  turned up: "IBM  System/360".   After  much
reading at the library I worked out that what we had was a  Model
30,  hence the 2030 number, which was a bit of  a  disappointment
when I would have liked a 91 or something.

All my spare time was taken up with studying the machine and  the
manuals.  It was obvious that the two main units would have to be
disassembled  to get them into the office.  The frames would  fit
up  the stairs, but if we were going to lift them then all  their
contents  would  have to go separately.   Unfortunately  the  IBM
engineers had not taken such disassembly into account, so it  was
not just a matter of unplugging everything and unbolting it  from
the frame.

A few words about the construction of the unit are in order.   As
I  became 'au fait' with the manuals I was able to  identify  the
basic units.  The whole CPU was about 1.5m high by 1m wide by  2m
long.  Looking from the front panel, the main power supply was at
the  left about 3/4 the way back.  It consisted of a huge  three-
phase transformer/filter assembly and a high-frequency  switching
power supply.  Behind it was an air compressor (yes - more  about
this later) and a relay panel.

At  the front left, near ground level, were the two  core  memory
units.   Each  was 32k bytes, and 64k was this  system's  maximum
capability.   Above the core was the microcode storage, known  as
CCROS (card-capacitor read only storage), in which microcode  was
stored  on punched cards, sandwiched statically  between  circuit
boards.   Each card held twelve words of 60 bits,  running  long-
ways along the card, and the card was pressed against the circuit
board  by  an  air bladder, kept  filled  by  the  aforementioned
compressor.  There were about 4k words of microcode, or about 340
cards.

Virtually  the whole right hand side of the machine was  occupied
by  the logic, on a 'gate' which swung out to provide  access  to
the  connections on the rear.  There was provision for  a  second
gate of similar size, though I learnt that this was only used  if
the  floating  point option (which also  required  an  additional
CCROS unit) or a second selector channel were fitted.

By  the  time I had sorted everything out I was  pretty  familiar
with  what was inside.  While the IBM 360 is of course a  32  bit
machine,  the Model 30 was internally an 8 bit system, so it  had
to do any computations four times.  Its addressing capability was
restricted to 16 bits, hence the 64k core limit.

It  had  a  single  multiplexer channel  and  a  single  selector
channel.   The  selector  channel was all in  hardware,  but  the
multiplexer  channel was implemented in microcode, with  a  small
amount   of  dedicated  hardware.   There  was  some   additional
'auxiliary  storage' (outside the main 64k address  space)  which
was  used  to store the 360's register  contents  (excluding  the
instruction  pointer  which  was  stored  in  hardware)  and  the
multiplexer  sub-channel status, where it kept track of up to  32
concurrent transfers.

The  CPU clock was about 1.3MHz.  In one cycle (750ns)  the  core
could do a single read, and on the following cycle the data would
have  to be rewritten, as core reads were destructive, unless  of
course  the data was to be modified before being  re-stored.   As
registers were in core the same procedures applied there.

After  much deliberation, the unit was dismembered  into  several
large  chunks:  the power supplies (after removing  a  very  dead
rat),  the CCROS unit, the core modules, the logic gate  and  the
front  panel.   I didn't have to cut many wires,  but  kept  good
records to assist with reassembly.  With the panels removed  this
left a bare frame, though still none too light.

The  2841 unit turned out to be the DASD (disk)  controller.   It
was almost as complicated as the computer itself, having its  own
microcode,  and  an interface for each of the four  drives.   The
drives  were  type  2311, with about 7MB each (that  was  a  huge
amount  in those days) and I had plenty of disk packs.  The  2841
was similarly dismantled, though it wasn't so much of a problem.

I  made up small paper templates of each unit, and shuffled  them
around  on a plan of the office so as to make sure I  could  open
all the doors and still have the cables reach between units.   An
electrician  friend, Doug Hook, wired three-phase power from  the
switchboard into the office.

All the moving was done at weekends, any other time it would have
been too difficult with traffic and other tenants.  The CPU frame
and the logic gate were man-handled up the stairs without causing
too  much damage to the banisters, while everything  else  fitted
into the lift, though at times it strained a bit.

Once  everything  was there, it  was  reassembly  (reassembler?!)
time.   This  went  pretty well, my notes were  good  enough  and
nothing  had  been damaged.  As this progressed, I  was  able  to
understand  the FEMM manuals more and more.  They  contained  all
the circuit diagrams, including connector layouts, and while  the
components  were  unfamiliar  I could still  use  them  to  trace
connections.   One unit that was a bit tricky was  the  1051/1052
console  typewriter.  This was a Selectric-style unit  which  was
wired  directly  into  the circuitry of the  CPU,  and  had  been
disconnected before being put into storage.

The  logic  was IBM's "SLT" (solid logic  technology)  which  was
similar  to DTL, and based on 0.5" square modules, each of  which
contained about one gate.  Four to eight modules would be mounted
on a board about 2" by 3", and these boards were in turn  plugged
into boards about 8" x 12", of which there were about 30 in total
on the main gate.

Once it was all back together to the best of my ability, the  day
came for the big start-up.  I really can't remember it too  well,
as  it  wasn't really that eventful - in retrospect I  was  lucky
that  nothing  blew up or caught fire.

We switched on the main power feed to the CPU.  There was a small
clunk from a relay somewhere, and the high-pitched squeal of  the
switching supply - this evidently ran all the time even when  the
computer was "off".  I reached out and nervously pushed the  "ON"
button.   There was a loud series of relay clacks, the  sound  of
lots of fans and the air compressor starting, then another  click
and everything shut off.

I never really resolved what was happening, but I think I  worked
out  that  there  was  a  problem  with  the  emergency  shut-off
circuitry (there was a line running down the channel cable  which
linked  the shut-off switches on each unit together - I  think  I
may  have had to move the terminator from the 2841 into the  2030
to temporarily override this) and this was fixed by cleaning  the
contacts on all of the relays.

Now  starting  the system would produce a  continuous  cacophony.
The air compressor would stop after about 20 seconds, starting up
every  few  minutes as the air bags leaked down, but  there  must
have  been  40 fans in there all whirring and  pushing  out  vast
quantities of hot air.  I had to remove the false ceiling  panels
and open the window if I wanted to have it running for more  than
ten minutes.

I  soon noticed that all was not well, and that the  machine  was
stopping soon after startup with a microcode check.  This led  me
down  a  convoluted path.  The microcode is stored on  a  special
punch card, which has silver conductive traces screened onto  it. 
When  fed  through  a card punch, some of  the  silver  pads  are
removed,  and  the  remaining pads become one  half  of  a  small
capacitor,  the other half being on the circuit board (hence  the
CCROS designation.)  Over time, some of the silver had  corroded,
resulting  in  dropped  bits.  Luckily each  microcode  word  had
several parity bits, so these errors were picked up.  I went  out
and  bought a small bottle of silver conductive ink from  Philips
and proceeded to do my own repair jobs.  It worked a treat.

Diagnosis  was  aided by the fact that each microcode bit  had  a
lamp  on the front panel, and there was  a  single-microcode-step
mode  of  operation.  There was also a complete  set  of  manuals
containing    the   microcode   (CLDs),   using    a    graphical
representation,  which I soon got to understand.  Before  then  I
had never encountered microcode.  The microcode system was  quite
nifty and most instructions seemed to execute in the minimum time
feasible,  though  even a simple register to register  add  would
take some 33 cycles (25 microseconds).

As  an aside, the mechanism used to implement microcode  branches
was  quite cute.  The 4k of microcode was divided  into  256-word
pages,  and 4-way interleaved.  A given microcode word  specified
only the top 6 bits of the next instruction's address within  the
current  page, the bottom 2 bits were determined by two  separate
function  codes,  giving  each  instruction  up  to  4   possible
successors (the function codes included force 0 and force 1 where
no branch was needed).  Since the four possible destinations were
already  read  by  the end of the cycle there  was  no  branching
delay.

There  really  were lots of 'blinkenlights' - a section  for  the
microcode,  a  section for the selector channel, as well  as  the
conventional  IP, data and status displays.  Quite a few  of  the
lamps had blown, so they got moved around depending on what I was
working on - I never got round to buying any new ones.

I now had a system that would start and stay running, even if  it
wouldn't  do anything.  I hadn't worried about the disk  side  of
things yet.  At this stage I had to start learning about what the
360 could do.  I hadn't had to worry at all about the intricacies
of  360  machine code or CCW programming, so now I  had  to  find
everything I could.  All those books in the library on  'Learning
IBM   360   Assembler  Language'  suddenly  had   a   great   new
significance, though most of my initial work was derived from the
listings  in the diagnostic manuals, plus the fact that the  1802
mnemonics seemed to mirror those of the 360.

I  wrote a few simple programs, and dialled them in on the  front
panel.   There  were  four  sixteen-position  switches  for   the
address,  two for data, and 'Store' and 'Read'  buttons.   Things
seemed  to work much as expected, but there were a few  anomalies
which I eventually traced to a few faulty SLT components.

In  one  case I managed to trace the fault to  a  particular  SLT
gate,  and  verified  the fault by swapping  its  board  with  an
identical  one elsewhere in the CPU (there was a  cross-reference
in  the  manual  of  where  each type  of  board  was  used.)   I
eventually isolated it to a single input to a three or four input
gate, and worked out that a single diode strategically placed  on
the back of the board would resurrect it.  It worked!

In another case I managed to swap a faulty board into a  position
which  didn't use the failed portion.  Other than these, and  the
CCROS  problems,  the  machine had survived  about  10  years  in
storage remarkably well.

With the CPU sorted out, my attention turned to the disk storage. 
I  had  got sick of manually entering programs, though  at  least
they  stayed  there  forever (I had  several  programs  scattered
through the 64k space.)

As far as I can recall, the 2841 worked straight away.  It didn't
have CCROS microcode, but rather TROS, transformer ROS, which was
a  sort of second cousin which used small transformers  to  sense
copper tracks on plastic strips.  Depending on where a small hole
was  punched,  the track would either go through,  or  bypass,  a
ferrite  loop.   I  think that TROS was faster  than  CCROS,  but
wasn't so readily modified.

Each  drive  was connected to the 2841 by two  cables,  one  data
cable  directly  between the two, and one  control  cable  daisy-
chained  from  one to the next, somewhat like the  ST506  cabling
arrangement.   Each drive could seek independently, but only  one
could be transferring data at a time.  The 2841 had no  buffering
capability - data had to go down the channel and into the CPU  as
soon as it left the drive, at the rate of 145kB/second.

The heads on the 2311 drives are hydraulically actuated, and  for
their  size move at astonishing speeds.  With the weight  of  the
head  assembly, it's no wonder that whole drives can move  during
vigorous disk accessing.  A lot of the hydraulic fluid had leaked
out,  but I drained one drive which gave me enough to top up  the
other three.

I  picked a disk pack that didn't look important, fitted it,  and
hit the 'Power' button.  It spun up as I watched nervously.  Once
it  was up to speed, the heads slowly moved out onto the edge  of
the  disk,  loaded, and then there was a bang-bang  as  the  head
assembly seeked into the centre and back again.  This turned  out
to  be quite normal, but at the time it gave me a  great  fright,
and  I still don't know the real reason for it.  Maybe it's  just
to get any head crashes over and done with right away.

By  this  time I knew that I should be able to  set  the  address
'190'  on the front panel switches, and hit the 'IPL'  button  to
boot the system up.  I found the pack marked 'SYSVOL' and mounted
it on drive 190.  Once it had spun up I pressed IPL.  The console
typewriter sprung into life, banging out a prompt for the current
date.   I think it took me a while to get past this as  I  didn't
have  any  manuals and didn't know exactly what  it  wanted,  but
eventually I had my own running DOS/360 system.

This  was quite amazing, as the only DOS systems I had ever  used
were  CP/M  and TRSDOS, and here was something with a  whole  new
terminology.   At the same time, with only a console  typewriter,
there  wasn't  much I could do with it.  There must have  been  a
line printer and card reader with it at some stage, and the whole
operation of the system was centred around being able to feed JCL
in through the reader.

Luckily, a friend of a friend lent me a small DOS handbook  which
listed all the commands and proved invaluable.  John Machin,  I'm
sorry I never gave it back!  I went through the disk packs I had,
looking  for interesting programs.  As far as I could  tell,  the
machine   had   been  used  in  a  typical   commercial   billing
environment.   I  never found any interesting data,  not  that  I
looked  very  hard.  I was more interested in the  programs,  and
trying  each one out, as well as trying to extract  COBOL  source
using the library utilities.

I  managed  to order some manuals from IBM, on the 360,  DOS  and
COBOL.  They must have wondered why anyone was ordering them, but
to  their  credit they didn't take long to arrive and  they  were
very  cheap.  I was a little coy because I wasn't too sure  about
the provenance of the machine.

Sometime  around December 1982 I had a stroke of luck when I  saw
advertised an IBM 2203 RJE (remote job entry) station.  This  was
being disposed of by a government department, and they put it  up
for  tender.  I tendered $151 for it, and got it.  I think I  was
the  only tenderer - I could probably have saved $150.  The  boss
of  the  office  that had used it was quite  amused,  maybe  they
expected to get $10000 for it or something.

The  RJE station consisted of a card reader and a  line  printer.
As  I didn't have a card punch, automatic or manual,  the  reader
wasn't  much use, but the printer was.  Unfortunately  the  whole
system was designed to run to a mainframe via a modem, so  access
to the whole thing was via a serial link, and these were somewhat
lacking on the /360.  Still, once it was moved into the office  I
was able to play with printing out the test card deck, and  again
it came with a good set of manuals.

The printer was a reciprocating band type, in which the  typeface
moved  back and forth, and a hammer in each print position  fired
as  the appropriate character went past.  With a full  upper-case
alphabet,  and numbers, I think about 44 characters, it would  do
300lpm, which would still be quite respectable.  It made an awful
racket,  as the hammers were all cocked back for each line,  then
fired with a screech.

Anyway, back to connecting this station to the system.  I decided
that if I was going to do anything much I would need to have some
way of getting data in and out other than the console typewriter.
There was nothing for it but to design my own multiplexer channel
peripheral.   I  can't believe it now, but with  the  benefit  of
the  operation  manuals,  circuit  diagrams  and  the   microcode
listings, I was able to deduce the operation of the channel.

I  decided  to make a unit based on the 6802, as I  was  familiar
with 6800 programming, and worked out the minimum amount of  add-
on circuitry necessary to talk to the /360.  Not having any spare
channel  cables (and because a channel connector would be  larger
than  the  whole microprocessor assembly), I wire-wrapped  a  new
connector  onto the appropriate points within the CPU and  ran  a
piece of flat cable out to my little unit, including power feeds.

The  channel  interface circuitry was quite tricky, as  the  6802
couldn't  respond as fast as the 360 required, necessitating  the
use  of  latches  and  comparators  to  respond  to  the   device
addresses.   Luckily,  once a transfer cycle was  underway  speed
wasn't  a  problem.  All transfers were done a byte  at  a  time,
there was no buffering and no use of 'burst' mode.

The  6802,  together  with 4 6850 serial  chips,  looked  like  8
independent subchannels, numbered 8 through F to tie in with  the
default  device  assignments.   The 6802 could cope  with  all  8
running simultaneously.  I can't remember how I set the baud rate
for each channel, I think there were rotary switches.  The RS-232
handshaking  lines  were  used as the status  indicators  when  a
program  queried the device's readiness.  One full-duplex  RS-232
link  was  run to the RJE station, and another to a  "System  80"
(TRS-80 clone) which served as my data entry station.

I  did have a few mysterious problems with my device causing  the
CPU  to  stop with a channel check for no  apparent  reason.   It
happened  so rarely that I couldn't track it down, but it  was  a
bit annoying (pun not intended).

That  aside, I was now able to invoke the COBOL compiler, feed  a
program  in from the System 80 and produce a listing on the  line
printer.  I wrote a few simple programs in COBOL, number guessing
games  and the like, but my heart wasn't really in it.   The  fun
had been in getting the whole system going - once it was going  I
had no use for it.

After that the system languished.  I occasionally fired it up  to
demonstrate  it, but eventually I gave up paying the rent on  the
office  and  had the power disconnected.  The building  has  gone
through  several owners since then.  At some stage someone  broke
the  office  door  down  and stole the  bookshelf  that  held  my
manuals.  I haven't been back there since.

My  experiences  with the system have proved useful.   I  have  a
great respect for IBM hardware, and for the effort that goes into
the  design  of any system that complex.  I am glad it  wasn't  a
360/91, that little /30 was a lot cosier.

Lawrence Wilkinson
Auckland, New Zealand
May 18, 1993

--
Lawrence Wilkinson --- ljw@formula1.demon.co.uk --- 72070.3440@compuserve.com
         "It is said you learn from your mistakes.
          If so I must be an absolute genius!" - Tony Rudd



