8251 troubles

[Brent Hilpert]

Allison wrote:
> 
> >
> >Subject: Re: 8251 troubles
> >   From: Brent Hilpert <hilpert at cs.ubc.ca>
> >   Date: Mon, 28 Apr 2008 13:22:08 -0800
> >     To: General at priv-edtnaa03.telusplanet.net,
> > "Discussion at priv-edtnaa03.telusplanet.net":On-Topic and Off-Topic Posts
> > <cctalk at classiccmp.org>
> >
> >dwight elvey wrote:
> >>
> >>  Hi
> >>   The routines SETUP and COUT are ROM routines.
> >> SETUP passes the first byte to the clock generator and the
> >> remaining to the command port of the 8251. The command/status
> >> port is 1 while the data is 0.
> >>  COUT sends text to a video board.
> >> The second COUT never seems to get executed?? I give plenty
> >> of time between characters because I send then manually.
> >>  The board can do interrupt driven serial but that didn't seem to
> >> work so I went for the simpler polling method.
> >>
> >>          DI
> >>           CALL SETUP
> >> ;         .DB    $01F  ; 9600
> >> ;         .DB    $01D  ; 4800
> >>           .DB    $01B  ; 2400
> >> ;         .DB    $019  ; 1200
> >>           .DB    $0AA  ; SYNC
> >>           .DB    $0AA  ; SYNC
> >>           .DB    $040  ; RESET
> >>           .DB    $0CE  ;  2STOP, NO PARITY, 8BIT , X16
> >>           .DB    $010  ; CLEAR ERRORS
> >>           .DB    0
> >>
> >>           MVI    A,$027  ; RTD, DTR AND REC-EN TX-EN
> >>           OUT    1
> >>
> >>           CALL   TIN
> >>
> >>           CALL   COUT  ; This works
> >>
> >>           CALL   TIN
> >>
> >>           CALL   COUT ; never gets here
> >> ......................................
> >>
> >> TIN:
> >>           IN     1
> >>           ANI    2
> >>           JZ     TIN
> >>           IN     0
> >>           RET
> >
> >I have the datasheet for the 8251A but not the 8251 here, so just some guesses:
> 
> They are the same except for timing and some quirks/bugs.

Well, in general, differential quirks/bugs can go a long way to being a problem.
There's a fair set of differences listed in the A datasheet.


> >  - perhaps the 8251 (as opposed to the A) requires the receiver to be re-enabled
> >    (not a full reset) after receipt of each character (an 'explicit ack') (?).
> 
> Not required.

OK.


> >  - .. check the error flags to see if a framing error is occurring?
> 
> You don't have to but it's an idea.
> 
> >  - .. try sending a stream of (best random) characters at full rate,
> >    as opposed to just 2 manually? This might get around some framing
> >    inconsistency or such to at least see if a subsequent character can be received.
> 
> ??why.

8251A doc says device is picky about seeing the STOP bit.
Suppose for example, there is an inconsistency between the framing being sent
and the rcvr cfg, returns first character ok but sends dev into error state,
and error state does something to subsequent characters returned.
In general, it might help tease out an otherwise consistent consequence of some
unexpected behaviour.


> >  - (may be inconsequential, but in the init sequence the two sync characters
> >    are not preceded by a mode byte (perhaps SETUP does this internally?))
> 
> Thats required only for SYNC mode not async.

As Dwight has explained they are there for a reliable init, even for async
mode. I was noticing that it's different than what is suggested for init in the
A doc, which is to write 3 nuls to the command register followed by a reset command.