Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 02 Nov 1997 14:01:45 +0000
From:      =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson <totii@est.is>
To:        "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
Cc:        Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG
Subject:   Re: 7400 gates effected by probe routine
Message-ID:  <345C87C9.15FB7483@est.is>
References:  <Pine.BSF.3.96.971101231708.2591B-100000@trojanhorse.ml.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Jamil J. Weatherbee wrote:
> 
> >
> > 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!

I am not sure at the moment but I have been working with Rocwell 6522
PIA and 
I think it should be possible to probe 8255 in same manner as 6522, send
byte to
output ports and read back, if they are defined as output you should get
the 
same back out from them. I think you can also with the control register.

Do you have the 8255 datasheet ? it is available from Intel website

-- 
Þórður Ívarsson		Thordur Ivarsson
Rafeindavirki		Electronic technician
Norðurgötu 30		Nordurgotu 30
Box 309			Box 309
602 Akureyri		602 Akureyri
Ísland			Iceland

---------------------------------------------
FreeBSD has good features,
Some others are full of unwanted features!
---------------------------------------------



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?345C87C9.15FB7483>