home *** CD-ROM | disk | FTP | other *** search
- Path: iesd.auc.dk!news
- From: jds@kom.auc.dk (Jes Degn Soerensen)
- Newsgroups: comp.unix.amiga
- Subject: Re: Driver for GVP I/O Extender
- Date: 23 Feb 1996 10:45:13 +0100
- Organization: Aalborg University, Dept. of Communication Technology
- Sender: jds@ultra.kom.auc.dk
- Message-ID: <52vpwb6s7di.fsf@ultra.kom.auc.dk>
- References: <4fflpg$pdn@fbi-news.Informatik.Uni-Dortmund.DE>
- <31265527.3E9F@hollyfeld.org>
- NNTP-Posting-Host: ultra.kom.auc.dk
- NNTP-Posting-User: jds
- In-reply-to: Russ Miranda's message of Sat, 17 Feb 1996 14:22:31 -0800
- X-Newsreader: Gnus v5.1
-
- >>>>> "Russ" == Russ Miranda <amigaman@hollyfeld.org> writes:
-
- Russ> It shouldn't be that difficult. Once you know the board's
- Russ> address, I have the base offset of the UART, and it's just a
- Russ> standard 1655x type UART. The registers are well documented in a
- Russ> booklet from National Semiconductor, as well as in a billion
- Russ> other device drivers for 1655x UARTs for x86 based UN*Xen. I
- Russ> wrote a little AmigaDOS driver for the board, but I ran into
- Russ> problems initializing it. If I let the gvpio.device initialize
- Russ> it, then start my driver, it works great. If I just power on and
- Russ> set the regs up like I think I should, it doesn't do anything. A
- Russ> brief email w/ Ralph Babel (ex-GVP driver writer) indicated some
- Russ> weirdness exists with the board, and you have to do something
- Russ> odd like enabling all the interrupts before you can do
- Russ> anything. I'm not sure, I never tried to disassemble the
- Russ> gvpio.device, and Ralph never explained fully. I never had
- Russ> enough time to continue.
-
- Stay away from National Semiconductor's documentation - their version
- of the chip does not contain the parallel port so you might end up
- with a minor headache when you start looking for the missing
- information. I used the documentation from Texas Instruments when I
- wrote the driver for Linux, those docs are quite alright.
-
- Your problem with the initialization of the board is not that weird -
- the main problem is that when you start messing with the chip
- (ie. enable interrupts) you _must_ have a handler capable of servicing
- _all_ possible interrupts generated by the chip, otherwise you'll
- see an interrupt storm that makes you computer freeze (only a reset
- can get you out of that state).
-
- Jes
- --
- Jes Sorensen: jds@kom.auc.dk | If programming was ment to be fun,
- jes@leech.adsp.sub.org | why did they come up with Intel?
-