>
>Subject: Re: DEC LA180 printer (&LA100)
> From: M H Stein <dm561 at torfree.net>
> Date: Fri, 01 Feb 2008 14:54:19 -0500
> To: "'cctech at classiccmp.org'" <cctech at classiccmp.org>
>
>Date: Fri, 1 Feb 2008 09:37:40 -0500
>From: Dave McGuire <mcguire at neurotica.com>
>Subject: Re: DEC LA180 printer
>
>On Feb 1, 2008, at 6:35 AM, Rick Murphy wrote:
>>>> My books are still in storage,( basement wall are up! ), but I
>>>> seem to
>>> recall the LA36 had adjustments on the servo. Could the LA180?
>>
>>> Yes, it's basically the same mechanism.
>>> I've sent the maintenance manual to der Mouse for scanning.
>
>> LA36 and LA180 are the same mechanism? Are you sure? I don't
>>recall much similarity there, especially in terms of speed.
LA36, 120 and 180 were mechanically similar but that about it.
the logic and a few other detils were different.
>> -Dave
>-------------
>I'll be scrapping some more LA100s (RO) shortly; any useful parts in there
>for anyone? I believe that at least some parts are compatible with the LA210
>and others, including the LA34 & 38; can someone confirm that?
The LA210 is a varient of the LA100RO for most mechanical parts.
The la210 and LA100 shared the same print head, ribbon, carriage motor
platten motor, font carts, and a few other bits. Again they were
related so many parts could be shared but the logic board for each
were differnt.
Things you want to save are power supplies, print heads, drive motors,
ribbons, and the litle one way clutch used for the ribbon advance.
Allison
>Also an LJ500 (B2), although it's probably clogged and I don't expect much
>interest...
>
>TIA,
>
>mike
>
>
>
>
>
All,
I am trying to ID a chip from a SFD-1001 motor control board. This
is printed on the chip:
JAPAN SERVO
SA1001
3A
It looks like a normal DIP, except for the middle pins which
look to be twice as wide. Is this for heat sinking? I have tried
searching for this chip but so far have found nothing. The board has
this marking;
PC-368C
JAPAN SERVO
TDK-T15V
Which also has not turned up anything useful.. The 5 1/4"
drive mech this board is connected to was made by Matsushita and its
model # is JU-570-2.
From reading the SFD-1001 technical manual, the 5 1/4"
mech is just listed as a part so it does not have any detailed
information for this board. :(
Cheers,
Bryan
>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Wed, 30 Jan 2008 10:57:15 -0800
> To: cctalk at classiccmp.org
>
>> From: "Joshua Alexander Dersch":
>
>> Were there similar problems in the CP/M world? That is, was it
>> commonplace for there to be CP/M programs that bypassed CP/M BDOS calls
>> and wrote directly to a specific machine's hardware? Seems like CP/M
>> developers were more disciplined in this fashion, but maybe it's just
>> because in the CP/M arena there were so many different pieces of hardware
>> it was the only way to do it? (Whereas with IBM, the PC was seen as more
>> of a reference standard, even if it wasn't really that way in the
>> beginning?)
>
>The great thing about CP/M (and I'm talking about the 8-bit version
>here) was that it imposed a file system and made disk I/O uniform--
>128 byte sectors, regardless of how the information was actually
>formatted onto a drive. CP/M was really primitive when it came to
>console I/O, giving only about 3 functions for output and input each.
>No cursor positioning or screen control; basic TTY style I/O. And,
>while there was an IOBYTE facility to redirect I/O, implementation
>was very nonuniform between vendors.
Things like Termcap and the lise were not needed. However the console
IO was not so good. Try printing a string containing $ using the print
string call. The other was passing 8bit data when needed.
IObyte was mostly uniform, the problem was often it wasnt even
implemented. This was a problem of allowing the BIOS spec to be
minimal and it usually was.
>As a result, for other than simple command-line utility programs and
>compilers/assemblers and the like with minimal I/O requirements, most
>productivity and comms programs had to go to the hardware directly
>for display and communications.
>
>And that, I think was the innovation of programs such as WordStar and
>SuperCalc, and, to a lesser extent MODEM7 and Kermit--that you were
>running on an operating system that was basically designed for TTY
>I/O with no connectivity and the majority of systems were using CRTs
>and had modems. The problem became then how to make a single program
>work for everyone--and that was done with custom patch overlays.
>
>DRI, for its part, seemed to remain blissfully ignorant of both of
>these aspects.
Ignorant, I think no, they gave the hooks and basic requirements. It
was up to the BIOS developer to do a good job or just enough. I've
repeatedly posted that if anything CP/M prevents little and you can
do a great deal at the bios level to really deliver a better system.
The best way to illustrate this is try a system with basic IO and one
with a full interrupt drive IO. The first thing you notice is the
ability to type ahead and the system feels more responsive.
>Likewise, it wasn't MS-DOS that was the great advance for the IBM PC
>platform, but rather the well-documented BIOS and I/O interfaces.
>Heck, PC-DOS 1.0 wasn't that different from CP/M-86--you still had to
>do your disk I/O through FCBs, just like CP/M. I believe, to this
>day, you can still issue your DOS calls by loading (CL) with the
>request number and calling TPA:0005.
Well it was patterned (so say copied) after CP/M so.. No surpize
there. ;)
Allison
>
>Cheers,
>Chuck
>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: Roger Ivie <rivie at ridgenet.net>
> Date: Fri, 01 Feb 2008 08:05:02 -0800 (PST)
> To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
>
>On Fri, 1 Feb 2008, Allison wrote:
>>
>> Done right it was portable. However I encounterd at least one system
>> where the BIOS calls were unusuable for 8bit serial because every
>> transaction in or out was masked with 07Fh..
>
>Which is consistent with the manual:
>
>"All simple character I/O operations are assumed to be performed in
>ASCII, upper- and lower-case, with high-order (parity bit) set to zero."
>
>(from the section 6 of the CP/M 2.2 manual)
It is sorta.. Parity may not be a visible bit if the terminal is
set for 8P1, the manual would imply the required serial format is
7S1 or 7S2 which may be for TTY but not always.
The manual is at best obscure on that. ;)
My implmentations had two serial drivers TTY (masked to 7bit)
and CRT not masked. Add to that printer (DEC LA100) serial 8bit
and modem 8bit I used the high and low bits of IObyte usefully.
Allison
>--
>roger ivie
>rivie at ridgenet.net
> Date: Thu, 31 Jan 2008 09:21:58 -0500
> From: Allison
> If one takes a moment some of that was INTEL MDS artifact that were
> programmed around. Also there are plenty of unused RST vectors.
> For the later systems the 8259 was available and it inserted a
> CALL XXXX where XXXX was anywere in addressable memory. The Z80
> in mode2 interrupt also could vector anywhere in ram. DMA
> is not impacted by how the low page is used.
IIRC, in ISIS-II, programs were loaded somewhere above 3000H,
depending on the buffer requirements of the program, but always above
the ISIS resident, which always occupied the same space, regardless
of memory size.
On some early 8080 implementations, an 8259 wasn't used (expensive!)
and a simpler circuit using a priority encoder and a latch to stuff
111iii11 onto the bus in response to an interrupt acknowledge. CP/M
could get in the way of this scheme, if it was desired to use the
RST0 vector for an interrupt. Otherwise, there was no problem,
except for the RST vector (usually 7) used for DDT--but that's local
to DDT and easily patchable (it's done for the Amstrad PCW, for
example).
After having used ISIS before CP/M, I was happy to see the "lean and
mean" CP/M. ISIS was verbose, clumsy and slow (e.g., :F0: instead of
A: for the first floppy drive; "DELETE" instead of "ERA").
Of course, had CP/M simply shifted the TPA up 256 bytes and used the
area between 0100h and 01FFh for command-line storage, system request
vectors and FCBs, that would have solved the problem, but for the DDT
RST vector.
Cheers,
Chuck
Have a look at:
http://www.baltissen.org/newhtm/cbmhd.htm
Ruud's the main guy behind the 1541 IDE project I mentioned to you,
(and is on the CBM hacker's list I also mentioned) but he does have
an IEEE <> PC project on his site as well.
I've been meaning to look at the IEEE version myself; if you try
it out, share your experience (as will I if I get to it first).
mike
---------------------------------------------------------------------------------------------
Message: 12
Date: Wed, 30 Jan 2008 02:19:23 +0000
From: Ethan Dicks <ethan.dicks at usap.gov>
Subject: Has anyone ever written a standalone Commodore disk drive
To: cctalk at classiccmp.org
Message-ID: <20080130021923.GA7074 at usap.gov>
Content-Type: text/plain; charset=us-ascii
Hi, Commodore folks,
I have just tracked down an ISA IEEE-488 card and was thinking that it might
be interesting to use it to build an older PC into a Commodore diskette
drive emulator - I recall there are various projects to interface modern
hardware to PETs (like the C2N232 I have with me), but the idea in this case
is to allow existing apps to work as if there were a real C= drive hanging
off the PET's IEEE port. Essentially, the PC would act as closely to, say
a 4040, as possible. My thought was that if I had a real IEEE-488 interface,
it could handle the physical-layer protocol, and the emulator would only have
to handle sending and receiving command strings and data.
The virtual diskettes would be, of course, image files. I'm not really as
worried about RELative files - more along the lines of "direct access"
files where the code running on the PET wants to read and write individual
sectors, ignoring the C= DOS filesystem. That is, in fact, the major
reason for trying to emulate drives in the first place - if it was just a
case of loading and saving streams of data as files, the C2N232 does a fine
job of that (and costs on the order of $10 to breadboard).
There seem to be a number of ways to emulate C= IEC-bus devices (such as
the 1541-III), but not for the IEEE-488. If anyone can point me at any
existing projects, even if they are incomplete, it would be a big help.
Thanks,
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 30-Jan-2008 at 02:00 Z
South Pole Station
PSC 468 Box 400 Temp -34.8 F (-37.1 C) Windchill -57.9 F (-50.0 C)
APO AP 96598 Wind 7.9 kts Grid 45 Barometer 674.7 mb (10829 ft)
Ethan.Dicks at usap.govhttp://penguincentral.com/penguincentral.html
> Date: Wed, 30 Jan 2008 13:07:48 -0600
> From: Jim Leonard
> Was there ever a *vanilla* MS-DOS?
Short answer--yes. It was called an "OEM Kit". Basically, you got
the binaries and instructions on how and what I/O drivers to write
and you linked the whole mess together to form two files, IO.SYS and
MSDOS.SYS, though you weren't confined to those names. Many
utilities, such as MODE and FORMAT were provided in skeleton form
with the vendor filling out the details. This lead to a some
interesting variations on MODE. For example, the Grid MS-DOS version
of MODE allows one to control the power status of the peripherals and
a whole bunch of other things.
I may even still have the OEM documentation wandering around
somewhere, printed up on fading tractor-feed paper.
A key difference between the two OEM arrangements was that you agreed
to serialize the copies of DRI products that were sold, while
Microsoft didn't require that. I think that MS simply charged you on
the basis of the number of systems shipped--I'd have to go back to my
files to make sure.
When you get that "Synchronization error" message from MOVCPM, it
means that MOVCPM has compared the serial number of the copy of CP/M
that it contains with the one of the system on which it's running and
the two don't match. Easy to patch out, however--but beware if you
"fill out" your CP/M disk with another's files.
Cheers,
Chuck
On Jan 30, 2008 11:53 PM, Zane H. Healy <healyzh at aracnet.com> wrote:
>
> Has anyone ever made an up-to-date install tape that doesn't require
> you to apply all the patches? I've got a chicken/egg situation going
> on, my PDP-11 uses a Viking QDT SCSI board, which requires one of the
> very last patches in order to be supported.
>
> Zane
>
I have an MTI QTS-30 (aka CMD CQD-200/Ts) and TTi QTS-1 / QTS-3 SCSI
tape controllers which I can use to boot a 2.11BSD install tape, but
the install process hangs up while trying to restore the files from
the tape to the hard drive. Anyone know for certain if the latest
patches might help that with these TMSCP controllers?
With the same SCSI tape drive and a CQD-220/TM I can complete the
2.11BSD tape install process to a hard drive attached to the
CQD-220/TM, but then it won't cold boot from the hard drive attached
to the CQD-220/TM. One of the MSCP boot loader patches is supposed to
fix that, but I haven't built and verified myself yet. It's on the to
do list.
Hi,
I see that you have the manual for science fair 200 in 1 from radio shack.
It would be great if I could get a copy of this manual.
I would like to use this system with my students. We have the machine,
however, the manual is missing.
Thank you,
sdenkin at bayridgeprep.org
Hey folks...I've got an otherwise-pristine Commodore 1702 monitor
that is missing the little front door that covers the controls. Does
anyone have one of those doors that they can spare, perhaps from a
junker 1702? I'd really like to make this one perfect.
Thanks,
-Dave
--
Dave McGuire
Port Charlotte, FL
I slipped off the belt from the motor pulley. Now the motor
can turn without moving the carriage. I tried to turn the motor
by hand (power off) and it can be turned easily.
On power up the motor starts to turn for about one second and
then stopps with the bell continously beeping (till power off).
I observed the signals -carry-, -borrow- and -inc- with an oscilloscope.
They are there when the motor turns but are the timings o.k.?
Regards
Axel Harten.
> Date: Thu, 31 Jan 2008 23:04:55 +0000 (GMT)
> From: Tony
> IIRC, while the MDA card had a light pen connector, it was never really
> documented or supported by IBM, due to the fact that light pens didn't
> work properly with the very long persisnence phosphor of the 5151
> monitor. The CGA card's light pen connector was docuemtned, though
> (although I have never seen a light pen designed to work with it
I've got a light pen that was salvaged from some 60's era graphics
equipment. This is the kind with the fiber optic tip and a
microswitch that determines when the tip is depressed. Has some
discrete circuitry in it (probably an amplifier, pulse shaper, etc.)
and works just fine with the MDA/CGA/EGA cards. About the diameter
of a felt tip marker (ca. 3/4"). I once used it with a monitor with
a short-persistance white phosphor. It wasn't bad; just couldn't
think of a good application for it. I've got a VGA card here
(Paradise I think) that also has the connector, but it's hooked to an
LCD monitor, so that's not going to work very well--but does give
another reason to hang onto CRT displays.
Cheers,
Chuck
Hi!
I'm a Computer collector from Germany and the last 3 years i spend a lot
of time in reconstructing and repairing my PDP11/05 along with its
peripheral devices (2x RK05,RX02,BA11ES).
Noe that these things are working im trying to repair my LA180-PD printer,
that was in no good condition.
With a copy of the logic-prints i was able to find some faulty IC's on
th logic board- but there must be at least one more.
On Power-Up the carriage starts to move back to left edge but stopps before
reaching the left end then the bell is turned on permanently.
There is no reaction on any button pressed or switched over.
Unfortunately i have no Maintenance Manual or Logic description, maybe there
is a person out on this list who can help me with a copy of the documents.
Regards
Axel Harten.
> Date: Wed, 30 Jan 2008 18:27:23 -0500
> From: Allison
> Things like Termcap and the lise were not needed. However the console IO
> was not so good. Try printing a string containing $ using the print
> string call. The other was passing 8bit data when needed.
Many avoided the issues with the BDOS and simply went through the
CBIOS vector. That's why it was important that your "cold boot" jump
at 0000 point to the proper entry in the BIOS jump vector list and
not to the cold boot routine directly. A lot programs used the cold
boot jump at 0000 to find the BIOS jump list--just take the address
in the jump instruction and set the low byte to 00.
Timer as well as console interrupt I/O was pretty much necessary for
MP/M functioning (interrupt-driven disk I/O was *strongly* suggested)
and recommended for CP/M 3.0, as was bank-switching.
I did a CP/M 2.2 implementation using interrupt-driven I/O for
everything but the memory-mapped display. It worked pretty well, but
the effort was wasted for the disk I/O--there was nothing to do while
you were waiting for the operation to complete. On the other hand,
it did make writing an MP/M XIOS much simpler.
> IObyte was mostly uniform, the problem was often it wasnt even
> implemented. This was a problem of allowing the BIOS spec to be
> minimal and it usually was.
The problem with IOBYTE is that it was defined in terms of console,
reader, punch and list. Well, most systems didn't have a "reader" or
"punch". This made what to do with those items a matter of
implementation. BDOS Function 3 is defined as "Reader Input" and 4
as "Punch Output".
> Ignorant, I think no, they gave the hooks and basic requirements. It was
> up to the BIOS developer to do a good job or just enough.
By the time that 2.2 was offered, most CP/M systems were CRT oriented
with a printer and perhaps a serial port used to connect to a modem.
Instead of acknowledging that as the model configuration, DRI
stubbornly stayed with TTY and paper tape as their model of character
I/O.
Cheers,
Chuck
> Date: Wed, 30 Jan 2008 15:44:40 +0100
> From: Holger Veit <holger.veit at iais.fraunhofer.de>
> MSDOS was much better in abstracting hardware, because it had a loadable
> driver concept.
Loadable drivers didn't come along until MS/PC DOS 2.0. Before that,
adding another device, say an extra disk drive, was a brutal
patchwork affair. CP/M 86 was far more advanced (for that matter,
CP/M Plus was too) than MS DOS 1.x. As a matter of fact, the DOS 1.1
reference material included information not only on commands, but
system table layout, .EXE file structure and system requests. ONE
disk buffer for blocking/deblocking. Read and write transferred one
record to and from the DTA. Flat file structure; file I/O done with
FCBs. As a matter of fact, if you didn't know any better, you'd have
sworn that someone took CP/M 2.2 and ported it to the 8086.
MS-DOS 2.0 was a huge advance over 1.1; by Microsoft's own admission,
the goal was to get closer to Xenix in operability.
> Point is there in both cases: the hardware designers did not foresee how
> their hardware could or should be used by software, so they basically
> implanted the bare chips, not even respecting IRQ and DMA requirements;
> the OS developers did not foresee usable and extensible interfaces to
> access and abstract various hardware and just hacked something that it
> would somehow work; and finally the application designers found the whole
> base OS functions where plain unusable and reinvented, each one
> differently, the wheel, leaving burnt ground for others that somehow
> required similar functions - "thou shall not use the printer port for your
> dongle, I have it already."
20-20 hindsight is great, but let's take it from the viewpoint of the
times. There were very many CP/M systems around at the time with
*no* interrupt or DMA support. Remember that the 5150 made extensive
use of peripheral chips that were from the 8-bit world (8237, 8253,
8259, 8255, not to mention the NS8250), so the fact that DMA and an
interrupt controller (with 8 interrupt levels yet) and a timer was
somewhat remarkable considering the competition.
Although the BIOS functions came a long way as the PC evolved, MS-DOS
still ran on a 5150, so the added BIOS functionality couldn't be
exploited.
The parallel port was designed as a printer port; the fact that it
was used for other things can hardly be blamed on MS-DOS. The
printer port does what it was designed to do extremely well. The
fact that a dongle designer was so short-sighted as to not provide
printer pass-through functionality can hardly be laid on the
designers of the PC.
Personally, I'm surprised the light pen interface wasn't used for
more things.
Cheers,
Chuck
I've been using a couple of Panasonic laser printers for years; a KX-
P4455 (PS/PCL) and a KX-P4451 (PCL). They're real beasts of
machines; I'd guess that they weight somewhere around 60 lbs. each--
heavy enough to cause me to grunt when lifting them.
These are the kind of units that requires one to add toner to a
compartment periodically. Drum and developer are separate cartridges.
The time came to replace the OPC drum in one of these--after pricing
the remanufactured ones and checking the deals on eBay, it turned out
not to be practical. I found that I can get a factory refurb Brother
5240 from Staples.com for $40 shipped. When it runs out of toner, I
can just buy another one at that price (1200 DPI, 23 PPM and most
important--a parallel interface).
So what to do with the old monsters? They use 68000 CPUs, with
differing SIP and DIP memories. Scrappers, I guess. It's sad
because both of these have pretty much been the only printer I've
used since a Diablo Hitype II. It wouldn't surprise me if each has
more than 250,000 copies on it.
It's just a shame that such a nicely engineered piece of gear is now
worth only its weight in scrap metal.
But nobody collects printers, not even vintage ones.
Cheers,
Chuck
> Date: Wed, 30 Jan 2008 14:16:32 -0500
> From: scheefj at netscape.net
> What is the desired end result? What is the application? A simple
> application may not need a "real" networking protocol. If "cluster"
> means distributed processing, then you have a lot more than just
> protocols to figure out.
You know, a $2 PIC (e.g. 18F2580) MCU implements CAN. It's not
really fast(CAN, not the PIC) but it keeps your car going. A minimum
of external components required. You even get a bunch of other neat
stuff thrown in (USART, timers, ADC, etc.). All in a 28 pin skinny
DIP or QFN.
(Dodging brickbats, for not keeping things contemporaneous)
Cheers,
Chuck
>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Thu, 31 Jan 2008 02:06:29 -0800
> To: cctalk at classiccmp.org
>
>> Date: Wed, 30 Jan 2008 15:44:40 +0100
>> From: Holger Veit <holger.veit at iais.fraunhofer.de>
>
>> MSDOS was much better in abstracting hardware, because it had a loadable
>> driver concept.
>
>Loadable drivers didn't come along until MS/PC DOS 2.0. Before that,
>adding another device, say an extra disk drive, was a brutal
>patchwork affair. CP/M 86 was far more advanced (for that matter,
>CP/M Plus was too) than MS DOS 1.x. As a matter of fact, the DOS 1.1
>reference material included information not only on commands, but
>system table layout, .EXE file structure and system requests. ONE
>disk buffer for blocking/deblocking. Read and write transferred one
>record to and from the DTA. Flat file structure; file I/O done with
>FCBs. As a matter of fact, if you didn't know any better, you'd have
>sworn that someone took CP/M 2.2 and ported it to the 8086.
>
>MS-DOS 2.0 was a huge advance over 1.1; by Microsoft's own admission,
>the goal was to get closer to Xenix in operability.
Roger that.
>> Point is there in both cases: the hardware designers did not foresee how
>> their hardware could or should be used by software, so they basically
>> implanted the bare chips, not even respecting IRQ and DMA requirements;
>> the OS developers did not foresee usable and extensible interfaces to
>> access and abstract various hardware and just hacked something that it
>> would somehow work; and finally the application designers found the whole
>> base OS functions where plain unusable and reinvented, each one
>> differently, the wheel, leaving burnt ground for others that somehow
>> required similar functions - "thou shall not use the printer port for your
>> dongle, I have it already."
>
>20-20 hindsight is great, but let's take it from the viewpoint of the
>times. There were very many CP/M systems around at the time with
>*no* interrupt or DMA support. Remember that the 5150 made extensive
>use of peripheral chips that were from the 8-bit world (8237, 8253,
>8259, 8255, not to mention the NS8250), so the fact that DMA and an
>interrupt controller (with 8 interrupt levels yet) and a timer was
>somewhat remarkable considering the competition.
DING! Thats is the point. the 5150 was running at 4.77mhz which by
8088 standard of the day was SLOW. but it wasnt sitting the cpu in
tight loops waiting for keypressed or FDC data ready.
Every Z80 system that did exactly that was nothing short of phenominal
to use and could easily blow the doors off a 5150. I worked with a
one off Multibus system at that time that had Z80/6mhz 64k shadow rom
DMA floppy controller and later ST506 hard disk. For text based work,
cross assemblers it was light years faster.
>Although the BIOS functions came a long way as the PC evolved, MS-DOS
>still ran on a 5150, so the added BIOS functionality couldn't be
>exploited.
Also the early bios was only 16k than even two years later it was
twice the size. Reason ram and rom became cheaper and larger.
More space more functions.
>The parallel port was designed as a printer port; the fact that it
>was used for other things can hardly be blamed on MS-DOS. The
>printer port does what it was designed to do extremely well. The
>fact that a dongle designer was so short-sighted as to not provide
>printer pass-through functionality can hardly be laid on the
>designers of the PC.
>Personally, I'm surprised the light pen interface wasn't used for
>more things.
That never caught on. I think when it could have the CPU was still
too slow to do the work.
Allison
>
>Subject: Q-BUS primer?
> From: "Dave Dunfield" <dave06a at dunfield.com>
> Date: Wed, 30 Jan 2008 22:12:16 -0500
> To: cctalk at classiccmp.org
>
>Hi Guys,
>
>Recently acquired a goodly amount of DEC gear - I had put the Q-BUS
>stuff aside while I got the "all in one" VAXstation/VAXservers up and
>running, but I'm starting to collect information - I've no experience
>whatsoever with Q-bus, but from what I've read, I understand that it
>will take a bit of research to determine how to properly configure
>and position the boards.
Here comes a huge first shot. Any questions ask. I've likely answered
them before. I have here most every Qbus configuration for PDP-11
and a few DEC would never support and a few Qbus uVAX too. All
operational.
If you liked programming the 6809 the PDP-11 will be familair
and even nicer. (CUBIX-11).
Any (and all) of the late 70s through mid 80s "MicroComputer Handbooks"
[microcomputers and memories, Microcomputer interfacing handbook]
DEC put out. They are chock full of info, explanation and are just
gotta have items. The PDP11 and MicroVAX have heavy overlap in the
Q-bus realm so any and all info for one will be helpfull for the other.
Those books will help with..
PDP11 programming (or microVAX)
PDP11 modules and their jumpers
Standard addresses for various functions
Some info on standard configurations including what board goes where.
Boot code for many devices
Mxxxx to function conversion
DEC history!
>I'm hoping that I have enough material to built up at least one
>(possibly 2) nice little PDP-11's, and/or a MicroVax II)
To make a system you need roughtly (pdp11).
A box with power, backplane and at least minimal front pannel
(three switch)
A CPU be it LSI-11 or M8186 the latter is mroe versitile.
An SL serial port configured as console (dl11 or better DLV11J OR MXV11)
My prefernce is the 11j and seperate ram as the MXV is a sea of jumpers.
However teh MXV-11 Two or up to 4 total make for a compact systems with
boot and IO galore. the MXV11s mostly seenare limited to Q18 configurations
due to limited address decoding but fully populated boards times four
Gives you 64KW (128KB) with is a moderately large memory system and
also 8 serial lines 4 PPI! Popular card for embedded systems.
Memory at least 4K more for an OS (16k minimum)
To run an OS some form of mass storage
(could be a Tu58 emulator running on a PC on A serial port)
A good OS to start with is RT-11, compact, small ram fooprint
and can run from any device 256k or larger, looks like dos. ;)
NOTE: The LSI-11 is the oldest and has some bus configuration items to
pay attnetion to. It's limited to 32KW addressing (Q16) and when you remove
the IO page (PDP-11 and VAX use memory mapped IO) typical space is 26KW
(big for basic 11). The M8186 is the F11 cipset and has MMU also
(Q18/Q22) can address larger memory. Most all 8186s I've seen despite
handbooks claims of only Q18 addressing do Q22 (22bit). It's also much
faster than the LSI-11.
>At this point, all I'm really looking for is a good "starting point".
>Can anyone recomment a good document/resources for a Q-bus newbie?
>
>Btw, this is what I've got - If there's anything I'm obviously missing,
>or will have to find extra parts for, please advise me so that I can
>start looking...
>
>Three chassis:
> BA-23: complete with outer shell and end caps. It bears a
> "MicroVAX II" label on the console switch panel, and has a
> floppy drive (dual disk) installed in it.
The dual floppy is RX50. The front pannel is processor specific as are
the real pannel (if present!) inserts. That box works for both Q-bus
11 cpus and Qbus uVAX cpus.
> I don't know the model numbers for the next two:
> - One looks like a BA32 but smaller, and has the "3-switch" PDP
> console/display panel on it. The cards are inserted from the
> front beside the panel.
BA11N BAllVA??? Should have a label somewhere identifying it.
> - The last one is the smallest, looks much like the one above,
> complete with 3-switch console/display panel, however instead
> of metal side/top/bottom plates, it has a "wire cage". It also
> has a second expansion chassis of similar construction with no
> power supply or console panel.
Generally the DEC backplanes are wirecage to cupport the guides and the
backplane at the end with power and control connectors.
>I've got the following DEC Q-BUS cards:
>(Descriptions taken from the "Field Guide to Q-BUS and Unbus modules"
>
>M3106 4-line async
>M7264 11/03 processor with 4-Kword RAM
That is the base "LSI-11" cpu card. Use in many machines and even
the H11.
>M7504 Ethernet adapter (older DEQNA)
Older and often flaky, if it works keep it, if unsure keep it.
>M7546 TMSCP controller for TK50
>M7555 Winchester and floppy disk controller
AKA the RQDX3 controller for MFM and floppy(RX50 and RX33
aka TEAC FD55GFR).
>M7606 MicroVAX II KA630
>M7608 x2 2/4 MB RAM (boards are fully populated)
uVAXII cpu has matching ram with an over the top IDE cable.
M7608 is ONLY for uVAXII.
>M7940 x2 SLU Module
DL-11 card, generic serial line interface. That an older
one but very useable. Pair that up with LSI-11 cpu.
>M7944 x3 4-Kword RAM
Goes with the LSI-11 CPU.
>M7946 x2 RX01 floppy disk controller
It's not teh FDC it's really only the bus interface to the FDC.
The drive RX01 has a simple randome logic processor to do all the
heavy lifiting. RX01 is SSSD 8" standard.
>M8043 x2 4-SLU peripheral interface
DLV11J, the standard 4 serial line interface for QBUS.
>M8044DB x2 32Kword RAM
>M8044DF x2 32Kword RAM
For qbus 11 systems.
>M8047 RAM, Async, ROMs
MXV11 compact card with a million jumpers that gives you
yp to 32kB of ram, ROm, 2 serial(DL compatable) and parallel(8255).
>M8186 11/23 CPU
First generation F11 cpu, fine board has uODT in microcode.
ODT is a very simple Octal based (all 11s are octal) monitor debugger.
>M9047 Grant continuity
Always handy for filling holes. The bus is wires such that interrupt
and DMA grant are passed through eash card so that the highest priority
requestor is nearest the CPU.
>M9400YA 120-ohm terminators with refresh & floppy boot
used with Qbus 11 cpus that are romless. can boot RX01 and I think
two otehr devicves
>M9400YE Headers and 250 Ohm resistors
bus terminator reqired in some cases optional in others not wanted in some.
>I've also got the following third party cards - I don't know
>anything about these, other than the identifying marks found
>on the boards listed below - if anyone can provide more
>information on these, that would be helpful: (Several of them
>appear to be media controllers of one sort or another).
>
>Andromedia Systems UDC-11 rev H (50 pin connector at front edge)
Memory says same as RQDXn. desireable board if you have info.
>Micro Technology Inc. MSV05B (x2) (50 pin connector at front edge)
>TD Systems TDL-11H/A (50 pin connwctor at front edge)
>Xylogics "Wizard 1" (50 pin connector at front edge)
>SDC-RXVZ1 "8202 FD Controller" (50 pin connector at front edge)
>Versatec LSI-11 P/P Interface (40 pin connector at front edge)
>Sigma Information Systems Assy 40100
> - This board has one 40 + one 50 pin connector, and a place to
> populate another 40 pin - none are at the front edge.
>W951 "Flip Chip"
> - This board has places for various sized chips (most of them populated)
> with pins to wire-wrap connections between them - looks like some sort
> of prototyping board.
>
>+ A couple of the little grant continuity boards.
>
>I don't expect this to be a short journy, but it should be interesting...
>Thanks in advance for any advice/tips.
>
>Regards,
>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
After some serious hacking, with this 3d animation program, I have it running under DOSBox!!!
Next questions:
1. Its a really cool program, expensive in its day, but abandoned by its owner AT&T who got out of the graphics business about 1993 or so. What have others done, to get the OK to post these type programs somewhere. (Im thinking about the Mame arcade emulator guys, who never were able to post the ROMs)
2. How can you free up the dosbox mouse to get back to a windows control so I can grab a screenshot?
Dosbox is cool!
Randy
_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/
Astounding - something genuinely rare on ebay.
Item number: 260206754118
I'd have it myselft but alas my loft is full.
--
Pete Edwards
"Prediction is very difficult, especially if it's about the future" - Niels Bohr
I'm assuming you've already verified that the carriage isn't binding,
by trying
to move the print head with the printer turned off, so we'll skip that
step.
If the carriage is moving, and suddenly stops, with a continuous error
bell,
it's possible that there is something wrong with the head positioning
electronics.
The motor that moves the print head has an encoder wheel on the back of
it,
which of course is monitored by the logic board.
I would GUESS that if the printer doesn't see any feedback from the
encoder,
that it would stop the print head, and turn on the warning bell.
I have one of these at home, with the classic "head slam" problem,
which is also related to the encoder and/or electronics. It will
print,
but when returning to the left-hand side, it will start with a gentle
tap while it's printing,
then a bit louder, then a bit louder, as the carriage slams harder and
harder
up against the left stop plate. Finally, it stops, and the bell sounds.
In this instance, it's losing track of where the print head is.
I haven't had time to isolate the problem myself, but it sounds like
you're having problems along the same lines.
I would check the connections to the encoder wheel. . . the encoder
wheel itself,
(sometimes they get dust / dirt inside the enclosure, which interferes
with operation),
then the infrared sensors, and related circuitry on the board.
Tim
________________________________________________________________________
More new features than ever. Check out the new AIM(R) Mail ! -
http://webmail.aim.com
I have an HP DDS cartridge labelled "HP-UX Install S800 / HP-UX 10.10
Release / For the HP9000 S800". Marked as 1 of 1, SD FMT, P/N
B3920-13427.
Available for cost of postage. Email me off-list
Jack
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.16/1250 - Release Date:
1/29/2008 10:20 PM