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

Reply via email to