Date: Sat, 1 Nov 1997 23:29:56 -0800 (PST) From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org> To: Mike Smith <mike@smith.net.au> Cc: hackers@FreeBSD.ORG Subject: Re: 7400 gates effected by probe routine Message-ID: <Pine.BSF.3.96.971101231708.2591B-100000@trojanhorse.ml.org> In-Reply-To: <199711020651.RAA00596@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > It's not too hard to trace the board back, but regardless this card of > yours has the change-of-state stuff; does it have a status register for > same? The only readable ports are the 8255s There is a change of state control (write only) and a clear change of state (write only) in addition to the two 8255s It is all reads 0xff like bus (16 ports), and what is really lame is that they had 6 extra ports, I wish they had stuck some magic numbers in there to read. > > Also, I don't have the right databook(s) here; what does the MODE/BITC > register on the 8255 read after reset? Nothing (0xff), the mode register is write only (at least for me) > Not really, no, unless MODE reads != 0xff. The 8255 isn't what you'd > describe as the most sophisticated bit of hardware. I'd still > recommend looking at the driver as having to address the hardware on > the other side of the card, rather than the card itself. I wish I had some hardware sophisticated enough for that! I just can't see how you'd have anything that sophisticated unless you were implementing some kind of bus with the thing, which for a card that operates in MODE0 would be kinda cludgy, since MODE1 or 2? provides some bi-directional features with port c as the status port. What I have considered however is the discrete state virtual machine someone mentioned previously. Perhaps based on the 6800 instruction set. Giving the card its own instruction set via the driver, so that the driver could be programmed from the users level to respond to events (change of states) with somekind of coherent and reliable outputs. I guess ol' tsleep() would certainly be the thing here hunh? I can immediately think of something this would be useful for as I worked on a project were I used an off the shelf rommable 68hc11 board equipped with a single 8255 as the sole interface to the outside equipment. The key here would be to guarantee some kind of responsiveness because the virtual machines would run inside the kernel. This ofcourse would be something for the future, but I'd really like to keep this open. I'm beggin yah to commit the thing!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971101231708.2591B-100000>