29 Apr
2008
29 Apr
'08
1:50 a.m.
Allison wrote:
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.
OK.
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.
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.
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:
They are the same except for timing and some quirks/bugs.
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: - 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. - .. 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. - (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.