On Wed, 31 Aug 2005 09:53:55 -0400, Paul Koning
<pkoning at equallogic.com> wrote:
> I don't know about Modcomp, but that's not the IBM way. IBM had
> amazingly primitive file systems (at least through OS/360), but not
> quite *that* primitive. You could create files at anytime, but only
> through JCL. (Actually, I think it was possible to create files under
> program control, but not via the standard APIs.)
>
> [...]
> paul
>
You are talking about big iron here. The IBM 1800, SEL, and Modcomp
were essentially toys which used a preallocated file system to ensure
speed in file access. All files were guaranteed contiguous and of
know size. The editor, compiler, and linker each had their own
segments which they individually managed. The editor would create
"files" within its segment. The JCL on these machines was quite
rudimentary and did not include any capability to re-hack the file
system. You could always design an application to partition and
manage one of the preallocated segments.
I remember having to re-sysgen the system numerous time while we were
designing the application in order to optimize the file sizes.
CRC
>
>Subject: Re: 6800 opcode $02
> From: "Dwight K. Elvey" <dwight.elvey at amd.com>
> Date: Wed, 31 Aug 2005 09:44:34 -0700 (PDT)
> To: cctalk at classiccmp.org
>
>
>Hi
> On the 8080, one just has pullups on the bus and
>it will do continuous restart interrupts. This
>will cycle through the addresses for the push part of
>the instruction. This is handy for testing address
>decoders, especially when working with boards of
>unknown design.
> I wasn't aware that the 6800 had a similar method.
>Dwight
>
Not quite the same. The 8080 RST (also works for z80 and 8085)
will revert to normal operation if rom(or any instruction source)
is encountered. The HCF required hard reset to escape as it
was not a useful instruction. Hence the name Halt and Catch Fire.
Allison
Turns out to be the wrong chip :-(
The person who mailed me the specs sent the wrong chip info.
Yes, it is a crystal oscillator. The actual part info I was
looking for was a82786 18062010 85 87 which I think is a graphics chip
>from Intel...
Sorry about that,
Ram
> -----Original Message-----
> From: Dwight K. Elvey [mailto:dwight.elvey at amd.com]
> Sent: Wednesday, August 31, 2005 12:56 PM
> To: cctalk at classiccmp.org
> Subject: Re: Does anybody know what this chip is?
>
>
> >From: "Ram Meenakshisundaram" <RMeenaks at olf.com>
> >>
> >It is labeled as:
> >
> >iqx0-500c 50,000000mhz dbg
> >
> >Thanks,
> >
> >Ram
> >
>
> Hi
> Sure sounds like a crystal oscillator to me as well.
> They are mostly in metal cans but also often in plastic
> cases. They usually only had 4 pins but I've seen some
> with 14 or 16 pins. Usually only 3 pins are used unless
> there is an adjust or enable input as well.
> Dwight
>
>
>From: "Ram Meenakshisundaram" <RMeenaks at olf.com>
>>
>It is labeled as:
>
>iqx0-500c 50,000000mhz dbg
>
>Thanks,
>
>Ram
>
Hi
Sure sounds like a crystal oscillator to me as well.
They are mostly in metal cans but also often in plastic
cases. They usually only had 4 pins but I've seen some
with 14 or 16 pins. Usually only 3 pins are used unless
there is an adjust or enable input as well.
Dwight
Hi
On the 8080, one just has pullups on the bus and
it will do continuous restart interrupts. This
will cycle through the addresses for the push part of
the instruction. This is handy for testing address
decoders, especially when working with boards of
unknown design.
I wasn't aware that the 6800 had a similar method.
Dwight
>From: "Allison" <ajp166 at bellatlantic.net>
>
>The 6800 indeed had HCF and while I forget the opcode
>(not a regular 6800 user) it was real. Basically if
>the opcode was encountered the chip executed bus cycles
>and did nothing else till reset. Story then was it
>enabled some level of factory testing of the die for
>the is it even alive test.
>
>
>Allison
>
>>
>>Subject: Re: 6800 opcode $02
>> From: "J.C. Wren" <jcwren at jcwren.com>
>> Date: Tue, 30 Aug 2005 21:45:00 -0400
>> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>>
>> I'd suggest finding a VHDL or Verilog implementation, and see if
>>that provides any insight. Also, Google for '6800 undocumented opcodes'
>>(no quotes). There are a number of hits. Most seem to indicate that
>>the undocumented opcode (no value given) causes the processor to go into
>>a mode where there are no instruction fetchs, but the address bus runs
>>incrementing bus cycles.
>>
>> --jc
>>
>>Scott Stevens wrote:
>>
>>>On Mon, 29 Aug 2005 17:53:59 +0100 (BST)
>>>ard at p850ug1.demon.co.uk (Tony Duell) wrote:
>>>
>>>
>>>
>>>>Does anyone know what Opcode $02 is on a Motorola 6800 processor. It's
>>>>
>>>>not defined in the data sheet, but I have a device which forces that
>>>>instruction onto the data bus in one of the test modes.
>>>>
>>>>Is it, by any chance, the infamous HCF instruction?
>>>>
>>>>-tony
>>>>
>>>>
>>>>
>>>Hmm, all the other $0x opcodes on the table are inherent instructions
>>>that mess with the condition code register. Looking at the order of the
>>>bits in the instructions, I don't see an order that corresponds with
>>>good old HINZVC (we were required to memorize this, the order of the
>>>bits in the condition code register, in tech school)
>>>
>>>0a clears overflow (V)
>>>0b sets overflow (V)
>>>0c clears carry (C)
>>>0d sets carry (C)
>>>0e clears interrupt mask (I)
>>>0f sets interrupt mask (I)
>>>
>>>The lower instructions defined are
>>>06 Accumulator A to CCR
>>>07 CCR to Accumulator A
>>>
>>>
>>>Is there a bit-level 'Opcode Breakdown' reference for the 6800
>>>processor, that defines bit field and gives clues to how the opcodes are
>>>translated in hardware, like there is (it's an elaborate table and I
>>>even have a machine language Textbook that drags you through it all on
>>>an early chapter) for the 8086 processor?
>>>
>>>The good old 6800. 'Freescale' : bah!
>>>
>>>
>>>
>
On Tue, 30 Aug 2005 16:07:04 -0700 (PDT), Jeff Davis"
<jdaviscl2 at soupwizard.com> wrote:
[...]
> The color scheme was brown and white, titled "Modular Computer
> Systems", with a ModComp logo.
What you found was a Modcomp II, a 16-bitter with 64 kwords of
memory. The machine was modeled (ala SEL) on the IBM 1800 series
controllers and were used primarily in communications and process
control. There were produced in the 1974-78 period, or thereabouts.
The design was interesting in that it used microcode which could be
extended through a microword bus. Consequently, unused instructions
were used for floating point, communications controllers, etc. OS was
multi-tasked, priortized, and fully pre-emptive. The file system was
ala IBM: you allocated your files at sysgen time. They were quick
machines for the time.
> The insides were odd - instead of the usual card cages, a lever let
> you pull
> out a sliding tray with (very rough est.) 15 x 15 inch cards that
> were mounted
> on an accordian style fold-out bracket, which I couldn't figure out
> how to
> fold out.
There is a knob on top of each plane which when pulled up allows the
plane to swing open. By far the easiest computer to work on I've run
across...
> They were interconnected with various flat cables. The outside
> most card was wire-wrapped, I couldn't see much of the other cards
> but I got
> the card names and part#s of all of them:
>
> 1 of Loop Controller, 551-100169-001
> 1 of MC II Plane I, 551-100140-001
> 1 of MC II Plane I, 551-100140-001
> 4 of 16K memory, 551-100069-001
IIRC all the planes, with the exception of the memory were wire-
wrapped and all ICs are socketed. What makes these planes unique is
that the power regulation is at the top on each plane. Raw DC is
provided from some honkin' supplies located at the back of the
drawer. The original IIs were implemented in 74Hxx (read very hot,
but not too fast) and consequently there are IIRC 9 fans on the
bottom of the drawer.
Generally, I/O was housed in plain boxes beneith/along side the
computer, but constructed with the same planes as the main computer.
However, these planes were oriented horizontally.
I ran one in an experiment during the period 1975-78. It was mounted
in a trailer which traveled over 10k miles over the period of the
experiment - damn reliable beast.
> Anyone know what this is? If anyone wants it, it's located in
> Santa Barbara,
> California - email me and I can give you the contact info for the
> surplus
> department there (or google "surplus ucsb"). I'll try to get out
> there on
> thursday and take some pictures if anyone is interested.
>
> Jeff
I would love to see some pictures :-))
CRC
If anyone wants to run a beowulfe cluster using a bunch of SBUS-based
UNIX-boxes, this is a great way to start. It comes with 5 adapters...
http://cgi.ebay.com/Lot-of-5-Dolphin-SBus-SCI-SPARC-Cluster-Adapter-Cards_W0
QQitemZ5803708439QQcategoryZ3668QQrdZ1QQcmdZViewItem
You can download MPI for Solaris which supports this (get ClusterTools for
Solaris from SUN)....
Ram
OK, now that I have your attention, an odd question...
How often do we reckon that a freebie big machine (PDP-11, VAX, Eclipse,
and so on - NOT micros) gets posted (or crossposted) to this list? Once a
week on average? I suppose I could scan the archives and do all sorts of
studies, but that sounds like WAY TOO MUCH WORK to settle my curiosity.
William Donzelli
aw288 at osfn.org
