On Thu, 15 Mar 2007 00:36:59 -0400, Patrick Finnegan <pat at computer-
refuge.org> wrote:
> The VAXstation 3520 (and 3540) are dual and quad processor pedestal
> vaxes
> (BA213-sized chassis) that DEC breifly tried to sell, with a weird
> (only
> used on those models) processor/memory bus called the "M bus". I was
> hoping that I could get more than 4 CPUs to function in the
> machine, and
> after a lot of effort (module order did matter!), I got some
> encouraging
> results. I bet no one else here can claim that they've got a
> "VAXserver
> 3560"...
[...hack...]
Okay, you have my interest. I assumed you sacrificed the graphics
card slots for the additional CPU and memory. Pray tell the order.
I'm running a 3540 with the second box kept as running spares less
the processors and memory.
At one time, after one beer too many, I had thoughts of repopulating
my second box to a 3540 level and building a M-buss extender to come
up with a 3580. However, the hangover and the light of day squashed
those thoughts :-))
CRC
So, Jay and Richard, er, Bidder 6 and Bidder 1, are you guys going to put
down some real money on that ADDS terminal or just dance around all night? ;)
(noticing the back and forth on the top of the bidder list)
--
--------------------------------- personal: http://www.armory.com/~spectre/ ---
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Apparently I am not very good at being tricky. -- John Hughes --------------
Hi All,
I just got in a Data General DG/500 (this is the PC style computer
based on the microEclipse chip set).
Unforturnately, no docs or software can with the unit. Does anyone
have any info on this unit, or can
point me in the right direction. Even the connectors on the back are
non-standard.
Thanks
Rob
Robert Borsuk
rborsuk at colourfull.com
--
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
>From: der Mouse <mouse at Rodents.Montreal.QC.CA>
>
>>>>> See ftp.rodents.montreal.qc.ca:/mouse/X/mterm.src/ [...].
>> I will grab mterm and check it out.
>
>Do please let me know if you have any problems with it (this applies to
>anyone else interested in mterm, too, which is why the post to the
>list). It hasn't been built on that many systems other than my own....
>
I used mterm *ages* ago, and it worked well. I *think* I got it to compile
on SunOS 3 and a locally molested BSD 4.x on an VAX.
>
>Subject: Re: SWTPC craze
> From: Dave McGuire <mcguire at neurotica.com>
> Date: Thu, 15 Mar 2007 03:04:44 -0400
> To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
>
>On Mar 14, 2007, at 10:37 AM, Jay West wrote:
>> To which Richard replied....
>>> Dude. 10 years ago I don't know if this "hobby" was on anyone's
>>> radar.
>> I beg to differ. There's quite a few listmembers here that were
>> active in the hobby 10+ years ago. I'm also certain there were a
>> good number of people doing it well over 10 years ago that still
>> aren't on this list. A relative newcomer to the hobby wouldn't
>> usually be aware of this. Just because this list wasn't around 15
>> years ago doesn't mean there wasn't a lot of people collecting.
>
> >10 years ago, I was adopting and hacking on PDP-8 and PDP-11
>systems because it was fun, and I thought it was important to
>understand and preserve the technology. I don't think I ever really
>considered the notion of it being "a hobby" or any other structured,
>labelable/quantifiable thing. I just *did* it, because I wanted to.
>Just like today...except now it has a name.
>
> -Dave
Wow! Ten years ago I'd been at it collecting that is for more than
20 years. So yes collecting computers is far older than that.
DEC had a computer history collection in their MRO facility going
back to before 1983.
Allison
I've just posted an update to ImageDisk to my site.
1.15 includes the ability to have write/format operations
pause so that you can manually change the TG43 line state.
It also includes a couple of minor fixes to IMD, and some
less minor fixes and enhancements to IMDV the new ImageDisk
Viewer.
I've also updated the source code archive with the latest
of everything, including the viewer source code.
Enjoy,
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
>
>>>>>> 13 Divide
>>>>> HMMM, the command takes very long but the results are
>>>>> very strange. I thought it might be some type of
>>>>> random number generation by an irreducible polynomal,
>>>>> but it is definitively not Divide. Maybe here is something
>>>>> different or wrong with the microcode.
>>>> This divides a signed DOUBLE LENGTH number in the A and Q registers
>>>> by a signed memory operand. IIRC the A register gets the result and
>>>> the Q register the remainder.
>>> OK, I will verify this in the coming days. Now I
>>> know what to look form but according to my records
>>> the results of this command always have been junk.
>
> Did the experiment on the real unit:
>
> Memory operand had always value 0x003, executed
> several of the (with index register zero at
> the start) broken-divide:
>
> Akku before: 001 005 010 020 050 100 120 150 200 500 fff
> Q before: fff 500 200 150 120 100 050 020 010 005 002
>
> Akku after: 2ab d55 ff5 fe5 fb5 f05 ee5 eb5 e05 b05 d57
> Q after: 000 000 001 001 002 002 003 003 004 004 005
Hmm, difficult to spot a pattern, but then with these large 24 bit
values you will be getting overflow when dividing by such a small
number and try to fit the result into a 12 bit register. I would try
with a much larger number as the memory operand, say 0x100. Another
thing you can try is using the 12 order to do a multiply and then
using the 13 order to do a divide by the same memory operand and see
if you get anything like the numbers you started with.
>
> So honestly speaking I cannot see the system behind
> these numbers ;-) In repeating the experiment I get
> the same numbers. Changing the memory operand to
> 0x234 I get the following:
>
> Akku after: 003 013 03b 075 123 3a1 415 4c5 743 f2f ffd
> Q after: 000 000 001 001 002 002 003 003 004 004 005
>
> So... ...big questionmark ...
Ah that's better. Except I still can't see any pattern except that
the Q register is counting up every other time. I wonder if it is
doing one step in the division each time and you are supposed to loop
and stop when Q reaches a certain value. This would improve maximum
interrupt latency. But you say this order takes a long time. Maybe it
is just broken as you thought. I'll see what I can come up with.
>
>>> "MTA - Move To Accu" is one of two "two-read-cycles"
>>> instructions. Up to now I did not fugire out, what
>>> the other instruction does with the data read. Do
>>> you remember any "two-read" instructions in the Elliotts?
>> Only the instruction I invented. The first word had the address of a
> Hey, you where active in the design of these beasts!
> Really great! So I am proud, that you join this
> discussion so actively!
>
>> a call without lots of special literals. We reused /3 I think, anyway
>> the original instruction was corrupt the Q Register with B-Line
>> indexing, but B-Line indexing corrupted the Q register at the start
>> of the instruction, so a totally useless opcode.
> Interesting story! In my opinion and in modern
> times using VHDL to implement everything into hardware
> very easy, the true heroes are the people like you
> who implemented microcode with the solder iron or
> the hand wired type of core-ROM! Really great!
Actually I was employed a junior programmer and eventually became
responsible for the Coral 66 compiler and utility software for the
920. Later on I became a 'Senior Systems Engineer' and made some
suggestions to the engineers here and there. I really learned about
hardware as a hobby with my ICT1301 mainframe. After I left I
designed interface cards for micros and my most complex hardware
design was a NuBus card for the Macintosh which could transfer up to
64k of data to wide format Versatec Plotters at a million BYTES a
second without any intervention from the CPU (i.e. by Direct Memory
Access). While that was going on the CPU was imaging the next chunk
of data to be sent. It had to be real time because if the plotter ran
out of data it would stop and the liquid toner would soak into the
paper and spoil the image.
>
>>>> I suspect the big plug is for the OMP (Operator's Monitor
>>>> Panel), and
>>> Some kind of blinking-light console? Something like
>>> this exists for the Rolm 1666b, too. This would be
>>> cool to have! ;-)
>> Yes, but these were of course much rarer than the computers
>> themselves.
>
> Sniff...
>
>> For a level 1 interrupt when the processor is on level 2, it stores
>> the SCR in location 2, and the B in location 3. Then it loads the SCR
>> from location zero and the B from location 1.
> That is a clever concept and should be easy to detect.
> So I will have to do some hardware work in supplying the
> signals to the appropriate lines and than I will be
> able to test this hypothesis.
Good.
>
>>> BTW: Have there been timers on the Elliotts you
>>> know about?
>> Yes bit not within the CPU box.
> Ah OK, so there is some kind of external data bus on the
> Elliotts. In the case of PEC it consists of a multiplexed
> open collector bus with a strobe line: address is
> applied, than the strobe line is set low by the CPU.
> Shortly afterwards address is removed by the CPU again
> and the memory unit applies the data to the bus if
> read is compite and signalizes this to the CPU. This
> bus runs quite stable even with the 75cm of ribbon
> cable of my setup attached to it. The shortest instructions
> which read only onw word are executed within 1.2us
> independent of the value of the index register.
Yes the CPU and some memory was in one box and extra memory in
others, and lots of peripherals too. Not commercial things of course,
things like compasses, gyros, special digital radio receivers and
transmitters, custom keyboards and vector and raster monitors, chart
recorders and much more.
>
>> No, when I started working for Elliotts, all computers were out of my
>> reach, but then I was offered an old mainframe (which originally cost
>> 247,000 pounds, for scrap value, 150 pounds). It was built in 1962. I
>> now have two of them in a barn at home. LOTS of lights and switches,
>> each has a card reader, card punch, line printer and one has a paper
>> tape reader and punch. Oh they both have drum stores and ten track
>> magnetic tape.
> Wow - that is a really great setup!!!! Do you
> have got any photos???? How much space offered
> the drum memory?? Recently I saw a card reader
> in action at the cray-cyber.org and I know that
> this is really great stuff!!
A chap who used to be a service engineer on my computer many years
ago contacted a while back and kindly agreed to help me bring my
computer back into a useable state. He has a web site describing the
project, and there are some pictures of him and my machine at http://
ict1301.co.uk/13010510.htm . The rotary switches can be used to put
data into registers, including the three instruction registers, so
you can enter programs from the keys if all else fails. The green
squares have four indicators in each one, so can display one decimal
digit (it is primarily a decimal machine, 12 digits * 4 bits)
The machine can be run at full speed, or at three instructions per
second, or at one instruction per keypress, or at three clock cycles
per second or at one clock cycle per keypress.
There are 6 tape decks see http://web.onetel.com/~rodritab/mtani.htm
The bigger picture of a complete machine is here: http://
ict1301.co.uk/13012006.htm
though it is actually a model and has the earlier one inch tape decks.
An actual machine is the lower picture at : http://
www.milsom100.freeserve.co.uk/1301/1301f.htm
Oh for all that space! I have two machines in less space they use for
one. Mind you one of mine is not assembled. It makes taking pictures
very difficult.
Roger.
On 3/14/07, Lyle Bickley <lbickley at bickleywest.com> wrote:
> Count me in as an old fart as well...
>
> I had the following home/hobby computers:
>
> PDP-8/L in 1971
> PDP-8/I in 1972
Wow... those were relatively fresh, then. My recollection was that a
PDP-8/L was $10K USD in 1967 or 1968. Any peripherals, or just TTY?
> PDP-12 in 1975
Very nice. I've seen one up close, but never got to play.
-ethan
>
>>> not know how long development of such an aircraft takes but
>>> the first take-off was in 1974 I think, so this would match
>>> the design of this box wuite well - what do you think?
>> Aircraft development takes a long long time. To make it worthwhile
>> the aircraft has a long service life. Whilst the computers are bullet
>> proof in an office/home, the temperature extremes, vibration, high G
>> forces etc in service means that many failures occur and PCBs could
>> be replaced many times over the years, so do not pay too much notice
>> of the dates on components of the boards currently installed.
> OK, I understand this. I do not know much about these
> issues, but on the internet often the COTS strategy
> is mentioned and in using standard components, I think
> moderen aircraft swap technology more often than was done
> in the 60s and 70s, right?
I am no longer in the Avionics field so I don't know anything about
modern practice.
>
>> There were at least four 12 bit versions, and one 13 bit apparently.
>> Then 12 bit models were the 902, 102C, ARCH 105 and Minim or 12/12.
> Thank you - I will try to find information on the
> web in the next days. Compared to the Elliott machines
> the DECs are very common stuff ;-)
I doubt you will find much apart from the names in timelines.
Specialised machine will always be rarer than general purpose ones.
The design considerations for a harsh environment plus the need to
save weight means much more expense, so they are not affordable for
normal use. Every extra Kg in the Avionics adds a lot to the overall
takeoff weight. For a helicopter, I think the ratio was somewhere
around six. Then there's the power, every extra watt needs bigger
alternators/generators and a bigger engine to drive them, and more
fuel to carry, which means more engine power and so on.
>
>>> Yes, that matches - the core memory module already has the
>>> label GEC. So this is (as I suspected) older than the CPU and
>>> taken maybe from a different design?!
>> You have it the wrong way around. The GEC name replaced the Marconi
>> name, which had earlier replaced Elliott. Core memory was very
> Thank you for this hint. I checked wikipedia and obviously
> GEC got involved very early and the name was changed to GEC
> later (1984). Sorry for my misunderstanding, now I got it.
>
>> convenient for military applications and was in use long after it was
>> replaced in commercial applications. Think of a missile or torpedo
>> held in stock for many years, stick a power plug into it and program
>> the target, pull out the plug and then launch it. Only then does the
>> internal power supply come up, the processor boots up and does its
>> thing.
> The internet claimes sometimes, that core memory is less sensitive
> to radiation, too. This might have been an advantage in certain
> military applications (really bad applications, honestly speaking).
DEAD right!
> Data retenttion of the core memory should be quite good,
> but since reading is always destructive, there is the
> rist, that bad data gets written back. In the case of
> Programmer Electronic Control, they did quite a lot
> to adjust the core memory's dirver current automatically
> according to a temerature measurement of the core. As
> my experiments show, you have to reduce the current if
> temperatuere goes up. This physically understandable
> (1/T).
My old mainframes also have a temperature sensor in the core store,
and they are only allowed to be used in a narrow temperature band,
about 10 to 30 degrees C.
>
>>>> bit 920s before moving on to the Zilog Z8001.
>>> Hey, than you are a valuable expert on these - do you have
>>> got any source of intormation about the 920s?
>> Not directly but I may be able to help.
> Hey, that is even better. I highly appreciate, that
> you spend time in sharing your information! Thanks
> a lot in advance!
>
>>>
>>>> 9 Jump if negative
>>> RIGHT - all three jumps are relative ones
>> On the 18 bit machines these were relative to the start of the 8k
>> memory module the instruction was in. An interesting modification.
> In my case they are relative and you can jump
> +/-127 words (crossing any border). Here again, the
> box uses 1complement and thus jump 0x00 is the same
> as jump 0x80: An infinite loop!
If 0x00 is the same as 0x80, then it is not one's complement. Sounds
like sign/absolute. In ones complement, the two representations of
zero are all zeroes and all ones. On the 920, a jump to itself was
referred to as a 'Dynamic Stop', and was the standard was to stop the
computer as there is no stop instruction. I try to avoid doing it on
my mainframes as continually accessing the same word in core might
make it overheat.
>
>>>> 11 Store program counter (for function return)
>>> SIMILAR - This stores PC and then does a
>>> table jump
>> On the 18 bit machines, it actually stored the program counter + 1
>> and the following instruction was either an 8 or a "/8", i.e. 24.
> Hmm, I do not understand fully what you mean by "the following
> instruction was either an 8 or a "/8", i.e. 24".
In 920 assembler, instructions did not have mnemonics, you used their
decimal operation code values. To indicate 'B Line modification' in
the assembler you wrote a / before the operation code. The assembler
simply added 16 to the opcode, so /8 = 24, but you don't have the B-Line
bit on your machine - its always on.
>
> The Programmer Electronic Control (Let's call it PEC in the future)
> stores PC+1 (as your 18bit) to the specified location into
> core. The new address is taken from the position in memory
> where the index register points to. So in my case this is
> a perfect table jump.
Ah, so you do this ?
0 word with address of routine
11 link word
>
>>>> 12 Multiply
>>> RIGHT, unsigned multiplication
>> This should multiply the signed accumulator and the signed memory
>> operand giving a double length result in the A and Q registers.
> Results are as you mention, but if either operand is
> negative, the result contains wrong values. But maybe
> I check whether this depends on the content of the
> index register prior to the operation...
>
>>>> 13 Divide
>>> HMMM, the command takes very long but the results are
>>> very strange. I thought it might be some type of
>>> random number generation by an irreducible polynomal,
>>> but it is definitively not Divide. Maybe here is something
>>> different or wrong with the microcode.
>> This divides a signed DOUBLE LENGTH number in the A and Q registers
>> by a signed memory operand. IIRC the A register gets the result and
>> the Q register the remainder.
> OK, I will verify this in the coming days. Now I
> know what to look form but according to my records
> the results of this command always have been junk.
>
>>>> 14 Shift
>>> In PART: Here exist many subgroups of commands including
>>> shift left/right. Also the Q as you call it can be transferred
>>> to Accu and vice versa. There als is a MTA (MoveToAccu as I
>>> call it)
>>> which is a two-word instruction (most others are one-word) and
>>> transfers the word following this command into Accu. About
>>> 16 bit patterns have (at least to me now) the same meaning in
>>> this segment.
>> Shifting by the entire word length does transfer Q to A or A to Q
> Right. But here again, the bit 11 is the sign bit and
> thus the shift does not affect the bit 11 of the
> destination. I.e. bit 0 of A is moved to bit 10 of Q
> in shifting right for example.
I see. The Q register was always a bit weird.
>
>> (but the data disappears from the source). A load immediate
>> instruction would have been very handy.
> Yes, the load immediate is really nice. A block
> move does not exist on PEC. Essentially the immediate
> "MTA - Move To Accu" is one of two "two-read-cycles"
> instructions. Up to now I did not fugire out, what
> the other instruction does with the data read. Do
> you remember any "two-read" instructions in the Elliotts?
Only the instruction I invented. The first word had the address of a
link word (in page 0) and the whole second word was the address of
where to jump to. So this was convenient for the compile to generate
a call without lots of special literals. We reused /3 I think, anyway
the original instruction was corrupt the Q Register with B-Line
indexing, but B-Line indexing corrupted the Q register at the start
of the instruction, so a totally useless opcode.
>
>> orders were encoded in the 14 order on the 12 bit machines with only
>> 256 numbers available compared with 8k on the 18 bitters.
> Yes, this seems to be absolutely correct!
>
>>>> 15 Input/Output and special (like interrupt return)
>>>> 16 to 31, as above but indexed by B register.
>>>
>>> NOPE - The box is 12-bit and does not have got this block.
>>> EVERYTHING is done via the index register I as I called it.
>>
>> Do you mean you cannot turn the B-register modification off?
> Correct: Everything is modified by the index register.
> Exceptions are the jumps, MTA for example.
>
>> Does it get cleared automatically somehow?
> You are clever - that is exactly what appens:
> Every instruction which is affected by this
> register (ADD, SUB, LDA, STA, ...) clear
> the register. So you have to load it right before
> each instruction. A severe constraint in my
> opinion is, that the index register can only
> be loaded from words 0-127 in the lower 4k. So
> this might be a bottleneck in memory since the
> table jump (I called it IDXCALL since it used
> the index register to get ne new address from)
> requires memory for each routine called, too.
>
>>> perhaps studying the Elliot would help to solve the remaining
>>> problems??!?!?!!
>> I am willing to try.
> Great! T H A N K S a L O T!
>
>> By the way, there are two 't's in Elliott.
> Thanks - is stored into my brain now ;-)
>
>
>>>> bootstrap, in later versions, this was just copied into core
>>>> when the
>>>> machine was initialised.
>>> Interesting. The Programmer Electronic Control starts execution
>>> at 0x0a0 after reset.
>> Could it be that there is a value of 0x0A0 at location 0?
> No, if the machine is held in reset state,
> the PC is forced to 0x0a0 since the reset line
> is connected to the Set/Clear pins of the flip-flops
> making the program counter. Immediately after reset
> is set high, the first word is read and executed
> from this address.
>
>>> But of course the application was different
>>> and the operation software was completely loaded via the big plug
>>> boefore operation.
>> I suspect the big plug is for the OMP (Operator's Monitor Panel), and
> Some kind of blinking-light console? Something like
> this exists for the Rolm 1666b, too. This would be
> cool to have! ;-)
Yes, but these were of course much rarer than the computers themselves.
>
>> yes the program would be loaded via this once, probably in the
>> factory or at a maintenance depot, and the machine would probably be
>> rebooted many times afterwards.
> If data gets corrupted, than the complete aircraft has
> to return to a maintenance depot for reprogramming
> the machine? So if there are 10 or 20 of these boxes in
> one aircraft, they need service quite often I think.
> Roger, how was your experience - was this reliable with
> the Elliotts or did you have to reporgram the pater tape
> loader quite often?
>
> In my case, the transputer setup generates some spikes
> doring it bootup. If PEC is already turned on, this
> corrupts the data in core memory. So I always do a
> memory-test on PEC after turn on (to adjust the core
> driver current) and than freshly program my test
> routines.
>
>> The 920 was unusual in that it booted into the highest level
>> interrupt, level 1, so no interrupts will be serviced until you go
>> down an interrupt level or two or three.
> So 15 7168 increases the interrupt level and
> after executing this once, the interrupt 1 can be
> serviced, right?
Thats it.
>
> What happens in the Elliott, if an interrupt occurs?
> Is there a jump to a certain address in core or is the
> new program counter itself read from core?
For a level 1 interrupt when the processor is on level 2, it stores
the SCR in location 2, and the B in location 3. Then it loads the SCR
>from location zero and the B from location 1.
>
> I have to think how to figure this out for PEC.... Of
> course I have to apply signals to all possible interrupt
> sources, load a program trying the yet unknown instructions
> and watch wheter any irregularities or jumps occur. I will
> have to trap PEC if the idle-loop is left. This is a bigger
> project and I will need some weeks to check this.
>
>> The 15 order is coded thus:
>>
>> 15 0 to 2047 Input
>> 15 2048 Shift A register left 7 places and OR in a character
>> from the
>> paper tape reader (via OMP)
>> 15 2052 (IIRC) Wait until character pressed on teletype and
>> read into
>> A register (via OMP)
>> 15 4096 to 6143 Output
>> 15 6144 Output character to paper tape punch (via OMP)
>> 15 6148 Output character to teletype (via OMP) if I remember
>> correctly
>> 15 7168 Terminate current program level i.e. return from
>> interrupt
>> 15 7169 Test if standardised IIRC, skip the next instruction
>> if the
>> accumulator is zero or top two bits are different
>> 15 7170 Increment B and skip the next instruction if bottom
>> 13 bits
>> are zero
>> 15 7171 Read the value of the control keys on the OMP
>> 15 7172 Move l.s. 17 bits of A to the m.s. 17 bits of Q.
>> Bottom bit
>> of Q is zeroed
>> 15 7173 Move m.s. 17 bits of Q to l.s. 17 bits of A. Top bit
>> of A is
>> zeroed
>> 15 7174 Move A to B
>> 15 7175 Move B to A
>> 15 7176 Set relative addressing mode
>> 15 7177 Set absolute addressing mode
>
> Thank you very much for this list. This gives me
> valuable hints and ideas what to try out next.
>
> BTW: Have there been timers on the Elliotts you
> know about?
Yes bit not within the CPU box.
>
> Since you are such an expert I am sure you
> have a nice collection of vintage hardware,
> right? Perhaps you even have got an Elliott
> up and running?
No, when I started working for Elliotts, all computers were out of my
reach, but then I was offered an old mainframe (which originally cost
247,000 pounds, for scrap value, 150 pounds). It was built in 1962. I
now have two of them in a barn at home. LOTS of lights and switches,
each has a card reader, card punch, line printer and one has a paper
tape reader and punch. Oh they both have drum stores and ten track
magnetic tape.
Roger Holmes.
The VAXstation 3520 (and 3540) are dual and quad processor pedestal vaxes
(BA213-sized chassis) that DEC breifly tried to sell, with a weird (only
used on those models) processor/memory bus called the "M bus". I was
hoping that I could get more than 4 CPUs to function in the machine, and
after a lot of effort (module order did matter!), I got some encouraging
results. I bet no one else here can claim that they've got a "VAXserver
3560"...
------------------------
KA60 V1.2
F..E..D..C..B..A..9..8..7..6..5..4..3..2..1..0
7 01010004 L2003 3 ? V1.3
1 SSC 00000001
2 DZ 00031200 ?
3 NI 19210770 ?
4 SCSI 00000901
5 SYS 00000001
Tests completed.
08-E1,P1
0B-E1,P1
0C-E1,P1
0F-E1,P1
14-E1,P1
17-E1,P1
08
<snipped OpenVMS 7.2 boot>
$ show cpu
VS3200, a VAXserver 3560
Multiprocessing is ENABLED. Streamlined synchronization image loaded.
Minimum multiprocessing revision levels: CPU = 3 FBIC = 1.
PRIMARY CPU = 08
Active CPUs: 08 11 12 15 20 23
Configured CPUs: 08 11 12 15 20 23
---------------------------------------------
Note that "VS3200" is the name of the system as the disk was supposed to
go into a VAXstation 3200. Also, the system doesn't seem to be
completely reliable in bringing up all 6 processors, but that may be
related to a firmware version mis-match between processor boards (and/or
timing issues when you've got 3 CPU boards).
I set out to try to do this 3 years ago now, and finally have managed to
obtain enough spare parts (via ebay) to try it out.
Pat
--
Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
On Tuesday 13 March 2007 12:47:04 pm cctalk-request at classiccmp.org wrote:
Dwight Wrote ..
> Are you looking for single sided or double sided? If single sided,
> the SA800's that were on ebay should work fine. If double sided,
> you'll need that SA851. These have two heads.
> If your connector is a 50 pin, you need a the SA800 and SA851's.
> The SA900's have a 44 pin edge connector but are otherwise
> similar to the 800's.
Double sided would be preferred since It would be more flexible in the long
run. Although I could get by with a single sided drive if I had to. I will
read up on this. I have come across some tables of the differences of each
type of 8 inch drive but nothing all encompassing enough to give me a good
decision.
--
Kindest Regards,
Francesca Smith
"No Problems Only Solutions"
Lady Linux Internet Services
Baltimore, Maryland 21217
The ADDS auction made me try to remember the serial terminals (connected via
Xylogics Annexes) that I used at UC San Diego. There were two: big boxy green
ones sitting under H&SS lecture hall, and then the orange screen ones in AP&M
2337. The green screen ones were good solid VT-100 emulation, with double
height and width support, but not a whole lot else. They were all-in-one
white units with black keys and a very boxy form factor. The orange screen
ones could do Tektronix 4014 emulation and had a small configuration menu
you could get at with the function keys. I seem to remember the model number
having four digits in it, and they were grey with detached keyboards.
Anyone have any idea what model terminals these were?
--
--------------------------------- personal: http://www.armory.com/~spectre/ ---
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Aibohphobia, the fear of palindromes. -- Brian Braunschweiger --------------
The Internet used to have a number of useful features that it no longer
does today -- for example, the finger and talk protocols. These protocols
no longer exist on the Internet, mostly due to valid security reasons.
As an example of how 'talk' differs from today's instant messaging systems,
one time I was having trouble with some Internet site -- maybe their
FTP server was down or something, I don't remember. I fingered the host,
found an active user, and 'talk'ed him. He was happy to fill me in on what
was up.
You can't do that any more.
And if you could, it would surely be abused into oblivion by spammers
and phishers.
Usenet, which is decentralized, requires no access credentials, and has
a programmatic interface that allows for sophisticated filtering and
offline reading, has largely been displaced by the network prisons
known as web forums, which require a separate account for each forum,
have a clunky and slow user interface, and are prone to vanishing
when their operator loses interest.
In general, Internet services which were designed to be accessed
programmatically have been replaced with Web services which can only
be used manually.
On the other hand: HTTP actually isn't that bad as a replacement for FTP,
except that uploads are much harder. There's also the problem of machine
parsing the directory listings, but FTP had that problem too, to some extent.
And the network itself is much faster and more reliable than it used to be.
-- Adam
As hinted at in another post a few days ago, I'd like to add an 8" drive (or
possibly more than one if necessary) to my Imagedisk machine in order to be
able to archive 8" media.
My knowledge of 8" drives is practically non-existent, so what are the gotchas
involved? Things like:
Do 8" drives exist in both hard and soft sector variants? Is one far more
common than the other (as with 5.25")?
Do 8" drives exist with wildly different track counts (40, 77, 80 etc.) and
again is any one particular flavour far more common than the others?
Are there any problems with some particular drives that'll make interfacing
them to a '765 type FDC more difficult?
etc. etc.
I suppose the real big question is: Is there a particular flavour (i.e.
geometry and interface, not specific brand) of 8" drive I could use that will
mean that I can read and write the majority of 8" floppies found in vintage
hardware? That would at least seem like a good initial step, and I could worry
about the minority formats later on.
cheers
Jules
Necessity has been inventing again ....
FYI, I have just added a new small utility to the ImageDisk
package - this is called "ImageDisk Viewer" (IMDV). It is
essentially a simple HEX editor that lets you easily poke
through .IMD images with HEX displays accompanied by either
ASCII or EBCDIC translations.
Addtional features include the ability to search the image
for specific strings, and to extract and view all printable
strings from any arbirary location in the image (including
scanning the whole image) - this is VERY handy when you are
trying to figure what the heck a particular disk image
contains.
It's a simple viewer, but it's advantage over fancier dump
utilities is that it knows about the .IMD format and can
search/scan in the correct order for interleaved sectors (or
not if you don't want), and scans/searches transparently
across sector boundaries.
If you have a reason too (or even if you don't), you can also
use it to patch the content of individual sectors within the
image (I take no responsibility...)
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
> Depends on your point of view.
Absolutely. That's one of the great things about our hobby.
There is enough variety of backgrounds and systems that
almost every system can find a champion.
I guess the Brother-type WPs fail to catch my attention
because they're so much like other things I've designed
or worked with. Of course, that doesn't mean I don't
still have claim to the Brother we got my mother about 12
years ago. That sounded weird. Does that make it my
uncle????
> The Brother floppies are interesting--
> 240K single-sided 80 (sometimes 40) track 3.5" SS2D using GCR. The
> drives were really gutless wonders. IIRC, many were Z80/64180 based
> systems. I've not tried to get CP/M running on one but it might well
> be possible.
Hmmm. There's an idea. Maybe there's more hack value
than I had thought.
BLS
On 3/14/07, Chuck Guzis <cclist at sydex.com> wrote:
> Personally, I find little widgets with embedded processors
> fascinating.
<AOL>
Me, too.
</AOL>
> Consider a credit-card terminal--it has a modem,
> display, keyboard, can interface to a printer and most have some non-
> volatile memory. The difference between many word processors and
> general-purpose computers is one of nomenclature more than anything.
> Yet no one's really interested in them. An old Artec, CPT or AES WP
> box has the same basic components and vintage as most early
> microcomputer systems, but no one's interested in collecting them.
For me, at least, the difference is that a word processor or credit
card terminal or a gas pump, or whatever, does what it does and is
difficult to have it do something it was not designed to do. If it
were possible to get developer-level documentation on the internals of
said embedded devices, that might be something different entirely.
The one class of devices like this that _is_ thoroughly explored is
Internet/e-mail appliances like the Audrey, the WebPal, the iOpener,
etc. Many of these, of course, are just Intel PCs with a UNIXy OS in
FLASH ROM, but at least they are inexpensive enough and powerful
enough to attract attention from the contemporary hardware hacker
community. Older devices, while interesting in their own right,
aren't as easy to come by, or, prior to the advertiser/subscription
business model, were paid for by the end user, not heavily subsidized.
ISTR IOpeners were costing the company $400 each, but were marketed
at $99 (later $99 plus a mandatory 4 month sub.) For a 200MHz PC
w/USB, 16MB Flash, 800x600 LCD, single-DC-voltage power (19VDC), $99
was a *scorching* price, so lots of hackers picked them up and figured
out how to dump the OS and replace it with Linux or Windows (yes...
people _did_ put Windows98 on them). For your money, you get a nice
little toy that's easy to reverse engineer, and when you do, the
machine becomes quite useful for a variety of applications. A used
credit card terminal for $20 (or whatever the going rate is) can still
be turned into something else, but it's not going to capture the
attention of an army of curious hackers.
I guess the other thing is... for as much work as it would be to delve
the secrets of a credit card terminal, I can whip together an LCD
display and a microcontroller for a few bucks and have 100% control
over its innards. If I don't care to start from scratch, I can begin
with any number of Atmel/LCD projects already out there (and I've done
just that recently). At that point, the advantage of an existing CC
terminal diminishes rapidly. It still has the benefit of being mass
produced and potentially abundant, but anyone can order an ATtiny2313
for a couple of bucks and hang a 2x20 text LCD or a 128x64 graphic LCD
off it and make it display some sensor input or whatever. The CC
terminal has to have some pretty cool stuff in there to pull into the
lead for a hardware project - I'd most likely gut the LCD and possibly
keep the plastic case for some other project than hack the
microcontroller that's already in there, and that's presuming it's not
a mask-programmed part and that I can reflash the chip.
So while I might not turn down a box of embedded devices like a credit
card terminal, hacking a lone terminal isn't as appealing as building
a similar device from scratch and knowing exactly how that new device
works. As I said, though, having developers' docs might tip the
balance, but the chances of that are rather low.
-ethan
> Form factor? Looks just like another "box with a monitor and
> keyboard to me". The Sony SMC-70 of the same time was a lot smaller.
> Could you be thinking of the PX-8?
I may well be suffering bit rot. I thought that was the one
that had a similar form factor to those Sharps that Radio
Shack rebadged as the PC-1 and PC-2. (Of course those
designations may also be the result of neurons going the
way of dynamic RAM not refreshed fast enough.) At least
in that space the Tandy Model 100 is a fairly interesting
example. There weren't many like it and it clearly was
a step toward the laptop. And one of its biggest applications
was as a WP for reporters to prepare their stories in the
field.
The dedicated WPs that I was getting at were things like
the Brothers that you could buy at Walmart 15 or 20 years
ago. I'll agree that office systems in general from before
say 1980 are in the realm of interesting. It's the high volume
appliances that briefly supplanted typewriters that come
to mind when I think of dedicated WPs, and I don't see
much in them that's interesting.
BLS
Jay,
Out of curiosity (and to the list in case others are interested), do you have
an estimate for the yearly cost of providing classiccmp.org and all the
services it provides? I gather you've got the ISP already, so presumably the
infrastructure doesn't come into it - and likely the same with things like
backup hardware (but not media) etc. as they'll already be in place for other
non-classiccmp services.
I think what I'm asking is, how much of "your" money do you put into it per
year in order to provide the mailing list, hosting for those of us who have
data on the classiccmp server(s) etc.?
[is there just "a" classiccmp.org server, or is it all spread across several
machines?]
cheers
Jules
> That's mostly a matter of will. There were several interesting
> applications (such as VEDIT) ported to the Displaywriter.
That is a good point. The only argument that I'd have with it is
that since so much of the software we'd find interesting was
ported from general-purpose platforms, the particular machines
aren't really a part of it.
> As far as
> architecture, an old AES 800 WP is about as exciting as architecture
> of the time gets--a custom ECL CPU supported by several 8080's doing
> the peripheral I/O. I'd love to own one of those.
I would too. That's a good example of the exceptions. I guess
I was thinking more of the later generation devices. So many
of them were just Z80s or 80186s with pretty conventional
video and disk controllers. Not really any different from many
general-purpose designs of the era, but much less hackable.
But as you point out, there are certainly gems to be found in
every corner of the computing world.
> And let's not forget that "computers" like the QX-10 weren't all that
> far from being word processors, what with integrated Valdocs and
> whatnot.
But is it really the WP aspect that makes it interesting or the
form factor as an evolutionary step to PDAs? I'd even
suggest that there may have been something of an unholy
marriage between those little things and the suitcase
luggables that built the image of a laptop in some minds.
BLS
There are several element of the phenomenon that reduces
the collectability of embedded devices and things like word
processors. For context, here are the characteristics that,
for me, make a machine interesting: interesting hardware
design, interesting software design, ability to do something
cool/geeky with it, and the influence it had on other designs.
So with that in mind here's why I think we see the phenomena
that Chuck describes.
> Personally, I find little widgets with embedded processors
> fascinating.
I suspect a lot of the problem is that they often aren't really
so little. Many embedded devices are pretty much just
a board unless they're connected to some other hardware,
which is often so large that it inhibits collectability. Of
course, no one here would turn down an AGC regardless
of whether it was connected to a spacecraft. But most
embedded systems only go so far without the other
hardware.
> The difference between many word processors and
> general-purpose computers is one of nomenclature more than anything.
Personally, I think this is exactly why they aren't very interesting.
Because they are so much like a general-purpose system, they
don't have a particularly interesting hardware design, almost
by definition. Their software is usually not particularly interesting
either. But you are captive in that software. You can't really do
anything interesting with them, except type letters. And for the
most part, they didn't have much influence on the rest of computing.
So, there's not much to draw me, or I suspect a lot of others, to
them.
As in all matters of opinion, YMMV. I certainly don't condemn anyone
who does find those interesting and wants to collect them. For
that matter, I do have a few embedded devices in my collection.
But a lot of them are actually ones that I worked on in former lives.
That's really why they're interesting to me.
BLS
http://lisaem.sunder.net/downloads.html
This includes OS X PPC, win32, Linux binaries, PDF documentation, as
well as
source code.
I didn't get a chance to build the OS X Intel version, I'll do that tonight
and post it up tomorrow. (Or you can just compile it yourself.)
A ROM dumper will be available in about a week. (Thanks James!)
Enjoy.
------------------------------------------------------------------------------
LisaEm Known current Bugs for 2007.03.14 version
------------------------------------------------------------------------------
* Native printing is still broken
* Serial port option TelnetD crashes/locks up
* Skins on/off option sometimes needs to be forced.
------------------------------------------------------------------------------
Lisa Emulator Change History http://lisaem.sunder.net/
------------------------------------------------------------------------------
2007.03.13 - found a fixed config bug: serial b options copied from port a.
- added a switch to turn off power to the virtual Profile before
power on. This allows you to prevent the boot ROM's Power on
self test to automatically boot from the Profile. It's useful
when you need to repair the Profile since it allows you to
boot from "Lisa Office System 1/5" and then power on the
Profile drive to repair the file system.
2007.03.11 - Proper BMP's are now generated for printing, conversion to PNG
format works, but is a little bit off - background is gray,
should be white as in paper white.
- added command line ability to load preferences file when
launching. i.e. ./lisaem ~ray/macworks.lisaem will open the
macworks.lisaem preferences file from user ray's home.
2007.03.10 - getting closer on proper BMP generation for printing
- added throttle setting to global preferences.
- added ROM checksum failure warning on power on. If the ROM is
broken, it can crash the emulator.
2007.03.09 - skins on/off added to Display menu.
- found IW linefeed pixel bug (lack of initialization)
2007.03.08 - video modes are a bit smarter - if display size is too small,
will refuse to change video modes and will instead switch to
lower mode, or shut off skins.
- re-enaled 2Y and 2X3Y video modes (skinless of course.) with
checks for display size.
- skin/less mode switch no longer requires restart of emulator.
Extra space past display region is blackened to ameliorate
window
sizing bugs.
- Preferences "Apply" button (was save in preview versions)
closes
Preferences window.
2007.03.06 - added skinless option (bug: size of window is too
small/off). One
blit less during skinless mode so it's a bit faster on older
machines.
- NMI key can be forced now.
2007.03.02 - Video mode, sound effects, asciikeyboard as globally saved
prefs.
- added Sound Effects checkbox.
- debugging printing - somehow all pages show up black.
2007.03.01 - added NMI key to keyboard menu.
2007.02.28 - new IW code printouts sort of works.
2007.02.21 - Added Preferences panel for printer settings.
2007.02.20 - added size dialog box when creating profile (5/10MB, etc)
2007.02.18 - unified build.sh
2007.02.05 - I/O ROM version was getting clobbered by code in floppy.c to
0xA8 via a #define.
2007.02.03 - cheat_ram_test now a preference.
- if starting without ROM, dialogbox is shown, then
preferences are
shown asking for config.
- bug fix: after closing preferences, re-opening caused segfault.
- finer speed control - much closer.
2007.02.02 - fixed floppy insert on power off
- fixed floppy trapping on insert of non-DC42/bad disk image.
- fixed "Clock is not set" dialog box
- fixed ContrastTrails (linx/win32)
2007.02.01 - fixed raw kb entry - but CPU clock is still too fast.
2007.01.31 - fixed bug causing random crashes, mostly during LOS
install. Was
off-by-one array overflow related to ReDraw_* fn's.
Date: Wed, 14 Mar 2007 07:40:29 -0600
From: Richard <legalize at xmission.com>
Subject: Re: SWTPC craze
In article <45F76433.87F015DD at cs.ubc.ca>,
Brent Hilpert <hilpert at cs.ubc.ca> writes:
<snip>
...
>> I know you're interested in anything terminal, Richard, but I have to say
>>from a strictly functional perspective you're not missing anything.
>Yeah, I know, but people are clearly not bidding on this for the
>functionality. Its the brand.
>This can be a double eded sword. For instance, my Beehive terminal is
>branded Cromemco and that's the *only* thing that kept it out of the
>hands of the scrappers. Cromemco is a brand near and dear to people's
>memories and Beehive is a "WTF is that?" brand (or worse, "what a
>POS!" brand) to most people.
----------------
Good tip; I'm busy printing Cromemco stickers to put on my Falcos...
;-)
mike
OK, so this is a pretty dumb question, but what is the 'value' of a
typical PDP/8? Now I appreciate that configuration can vary wildly and
beyond that it is a matter of one what can be located for or what your
prepared to pay, luck and circumstance etc.
In terms of basic model I was thinking either a Straight-8 or PDP8/E. Now
I know only a few years ago a reseller had a number of the latter in
stock, tested, for about 400 UK pounds each. Albeit likely with no
peripherals, just the card cage and some sort of base config.
I've always wanted to own an 8 and have recently been considering the idea
of trading some less easy to run equipment.
Cheers,
Andrew
----------------
Andrew Back
a at smokebelch.org
Not sure if this is the right kind of terminal :P but I thought you guys
might find this offer interesting... :-)
---------- Forwarded message ----------
From: WebProNews <webpronews at ientrynetwork.net>
Date: Mar 9, 2007 9:15 AM
Subject: Featured Offer of the Month: Free FD100 Terminal!
To: hexstar at gmail.com
[image: counter][image: counter]
------------------------------------------------------------------------------------------------------------------
This is a WebProNews Sponsor Update
Please see the bottom of this mailing for subscription information.
-------------------------------------------------------------------------------------------------------------------
Find out how you can get the FD100 Processing Terminal for FREE* - Click
here for more information<http://aj.600z.com/aj/23363/0/cc?z=1&b=22970&c=23361>
<http://aj.600z.com/aj/23363/0/cc?z=1&b=22970&c=23361>
<http://aj.600z.com/aj/23363/0/cc?z=1&b=22970&c=23361> The First Data
FD100 terminal accepts PIN-secured and signature debit cards, credit cards
(including *American Express*(r),* Discover*(r), and *Diners Club*(r)),
contactless reader payments, gift cards, and much, much more. *Click here
for more information
<http://aj.600z.com/aj/23363/0/cc?z=1&b=22970&c=23361>or call
1.800.426.6413.*
*Benefits of the First Data FD100 Terminal Include:* ?
Accepts all major bank and credit cards; debit cards; gift and loyalty
cards; and checks using TeleCheck ECA or paperless solutions. ?
Secure Internet Protocol (IP) capability with
dial-up as connectivity backup.
?
Quiet, fast printer for speed at checkout lines ?
High speed capability for quick transactions ?
Intuitive touch screen with 128 x 64 graphic
LCD display ?
Terminal and printer combination to keep
infrastructure costs low ?
64 MB RAM standard memory allowing an average 1000 transactions before
batching out terminal ?
Access to on-line reporting 24 x 7 right from your PC
<http://aj.600z.com/aj/23363/0/cc?z=1&b=22970&c=23361>
Unsubscribe<http://attrack.ientrynetwork.net/CLK=1024083-13578967-297713191-21-22>from
iEntry Mailings on behalf of FirstData.
To unsubscribe from WebProNews regular editions or any other iEntry mailings
send an email request to: support at ientry.com
-- WebProNews <http://www.WebProNews.com> is an iEntry,
Inc.<http://www.ientry.com>publication --
iEntry, Inc. 2549 Richmond Road, Lexington, KY 40509
(c) 2007 All Rights Reserved Privacy
Policy<http://www.iEntry.com/page/corp/privacy.html>
Legal <http://www.iEntry.com/page/corp/legal.html>