Using DECmate III from terminal

From: allisonp_at_world.std.com <(allisonp_at_world.std.com)>
Date: Mon Jun 12 09:26:25 2000

> The DECmate II and (I presume, although I've not played with one) the III
> use Harris I/O support chips. The first thing you need to do to these
> chips after power-on is to configure their address. Consequently, there's
> a table of IOTs executed by the processor straight out of reset to get
> the job done. It should be possible to switch the addresses configured

True.

> for the console port and the printer port in that table. The effect would
> be that the printer port would now be the console port and the terminal
> emulation in the slushware would now run the printer port.

Will not work.

> No, I've not tried this. Furthermore, every time I mention the possibility
> some pretty knowledgeable folks usually tell me it won't work. I don't
> see why it won't work.

Simple, the slushware does the port to 5027based video and keycodes to
ascii translations and terminal emulation. You would not want that
inbetween a nominal serial port and the system while using a terminal.

To do thiswould require modding the slushware so that a normal console
requests are mapped to another port. the problem is that the 03/04 ports
do not support the full set of standard IOTs for TTY and interrupts.
the rest of the ports are even less like standard PDP-8 IO so you would
at a minimum be designing a full set of slushware and IOTs.

That is the crux of the Lasner ravings as to why a DECmate is not a PDP-8.
It is a system that is largely pdp-8 in character because of a micro that
executes most PDP-8 opcodes. However there is a holw class of PDP-8
things a decmate can't due to lack of buss access and the ability to
interface to real PDP-8 peripherals (not easy to do threy cycle databreak
using the CMOS CPU as a coopertive element).

check UU.SE and also www.dbit.com the nickles directory.

Allison
Received on Mon Jun 12 2000 - 09:26:25 BST