I've got a Technico 9900-based process control system arround here
somewhere. The 9900 CRU was handy for that sort of thing - clumsy for
more normal purposes.
I also have a a few front panel here, and believe it or not was thinking
about using the 9900 CRU chips (which have both a 74xxx and a 99xx
number) to drive the pannel off the parallel port. They are 8 bit, bit
addressable latches. I would have used a parallel port. 7 of the port
data bits would select the bit, the remaining port data bit would be the
value. Speed would probably be good enough - parallel ports can be fast.
You don't want an emulator that drives a front pannel to be too fast or
the blinking ligts won't look right.
That is one project that dropped plumb off the bottom of my "someday" list.
Armistead, Jason wrote:
Göran
Given that TI obsolete the TMS9900 range of CPUs probably 20 years ago, using
their 1-bit serial I/O scheme, know as Communications Register Unit (CRU), is
probably not a great idea. It never really caught on outside of TI's own
product lines, and it still required (up to) 12 bits for the address bus used
to select CRU bits (up to 4096 input and 4096 output bits), plus the 3 CRU
signals CRUIN, CRUOUT and CRUCLK.
Using a modern PC as a starting point, maybe you'd be better off with a
USB-based device which writes out to a SPI-like serial bus. Parallel ports are
disappearing (and now almost totally non-existent on notebook PCs and even
their docking stations), and CANbus is too specialized to each vendor (and thus
difficult to find drivers for every OS, especially Unix/Linux-based ones).
Companies like FTDI have some neat USB I/O controller devices (some that are
nicely programmable) and could be adapted to your needs using simple control
instructions across the USB channel.
Jason
-----Original Message-----
From: Göran Åhling
Sent: Friday, 10 December 2010 3:47 PM
To: simh@trailing-edge.com
Subject: Re: [Simh] Hardware Requirements
Hi!
One solution to consider, besides a bunch of small CPU's of personal
choice each having USB-interface and N signals I/O (thus requiring some
USB-hub's), or alternatively using the same way of thinking, but a
CAN-bus starting with a RS-232 to CAN converter from the PC would be:
Use the PC parallel port (bidirectional). For output, have a decoding
circuit (in plain logic or in an embedded CPU of favourite...) and the
required number of 8-bit latches. Use a RESET control signal to reset
the counter, thereafter sending out 8-bit words on D0-D7, having the
strobe select the proper latch to take next strobe to store the data.
This will not look like a shift-register, but more like a parallel
printer... 64 bit to write out would require 8 writes. One could also
imagine a "general" card with "LPT-in" and "LPT-out" that after reset
swallows the first 4 characters to come (and make 32 bits available for
outputs) and sends the rest of a stream "down the line". Next card in
line would take the first 4 characters that arrive into it ...
The cards would be identical to each other to design!
For input, a similar method might be usable, but here, I'm not sure
which signal to use for strobing "next register".
This should all be quire reasonable to implement though!
In the good old days. Texas instruments made the 9995 CPU, which I
think had some kind of serial 1-bit I/O-interface bus, and they sold
quite some different I/O-chips to attach. I never really learnt how this
was designed and set-up, but friends of mine who played with these
things were impressed (by then). I don't know how much of this that is
still available to the open market of electonics... If anyone else in
the list can give a 30 s class, I'd really appreceate it!
All my best,
Göran
On 2010-12-07 16:05, Pontus Pihlgren wrote:
On Tue, Dec 07, 2010 at 09:21:43AM -0500, Ken Cornetet wrote:
Keep in mind that the printer port on regular old PCs can be used for a few
lines of general input and output. I used to do this on a regular basis back in
the DOS days. Looks easy under linux too:
http://www.faqs.org/docs/Linux-mini/IO-Port-Programming.html
It's a solution I'm considering, but I have a concern. Besides the
PDP-15 panel I also have a PDP-12 panel. The PDP-12 panel has arround
120 lights. So while I think it will be possible to control them by
cascading shift registers, I'm worried it will be to slow.
Having more I/O pins and narrower shift registers would speed things up.
I would love to be proven wrong here, in which case I can dig out a
Pentium III with parallel port and start experimenting.
- Pontus.
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh