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