8251 troubles

Allison ajp166 at bellatlantic.net
Mon Apr 28 17:37:03 CDT 2008


>
>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.

>  - 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.  

Allison



More information about the cctech mailing list