Jump to content

Photo

R: Hardware Flow Control

technical questions atari 850 blackbox mio acia serial port r: handler

29 replies to this topic

#1 tschak909 OFFLINE  

tschak909

    River Patroller

  • 2,766 posts
  • Location:USA

Posted Thu Aug 16, 2018 10:06 AM

Question cavalcade below, as I try to gather my thoughts and plan: (I know I have asked a remix of some of these before, please bear with me, I am dealing with multiple ports at the same time)

 

I am trying to figure out how best to implement hardware flow control for PLATOTerm. Due to the processing complexity of PLATOTerm (and the fact that text output isn't optimized for this first version) hardware flow control is a must for anything above 2400 baud, and 2400 baud is marginal.

 

ACCORDING to the technical manual for the 850, I can IN THEORY VIA CIO disengage Concurrent mode, change RTS, and subsequently engage concurrent mode to resume.

 

Will this mean that I lose characters? I'm guessing from the way the 850 works, this is a big fat YES.

 

I'm not even thinking on the RVerter, as people seem to have been frittering around with this thing, for years, and still haven't implemented anything resembling an RTS/CTS handshake.

 

I do know that the Blackbox and MIO have their ACIAs exposed on the bus, and I can flip the registers pretty much immediately. I can also do this via CIO without needing to explicitly toggle concurrent mode. (I THINK, the manual seems to say this is possible).

 

If I do this via registers, I need to see if the registers are in the same place for the MIO and BB. Are they?

 

If not, how can I best detect a BB or MIO? (I don't really HAVE to because I have an installer which allows the user to select what they are running, but, still nice to have that option)...

 

Thanks in advance,

-Thom



#2 Nezgar OFFLINE  

Nezgar

    Stargunner

  • 1,168 posts
  • Location:Regina SK Canada

Posted Thu Aug 16, 2018 12:03 PM

I used Len Spencer's HyperSpeed R: handler with the MIO for my BBS. It automatically took care of the RTS/CTS and the BBS didn't need to do anything on it's own. This may mean that in your case, the handler may automatically take care of halting the incoming data if the application isn't taking it up fast enough. I clearly remember the handler obeying the hardware handshaking pauses when sending to the modem at 19,200, and the line rate was lower.

 

I would hazard a guess that the handler is directly twiddling the registers you mention on it's own.

 

http://www.lenardspe...r/hyperspd.html



#3 tschak909 OFFLINE  

tschak909

    River Patroller

  • Topic Starter
  • 2,766 posts
  • Location:USA

Posted Thu Aug 16, 2018 12:16 PM

I have his handlers on the PLATOTerm disk for MIO and BB, but both seem to exhibit a strange bug where data transmission just returns strings of 'U''s once connected, so I can't continue testing here.

 

-Thom



#4 Nezgar OFFLINE  

Nezgar

    Stargunner

  • 1,168 posts
  • Location:Regina SK Canada

Posted Thu Aug 16, 2018 12:52 PM

I have his handlers on the PLATOTerm disk for MIO and BB, but both seem to exhibit a strange bug where data transmission just returns strings of 'U''s once connected, so I can't continue testing here.

 

For the MIO at least (I have no experience with BB) the default baud rate is configurable in the MIO settings. Maybe there's some sort of speed mismatch / compared to the hardware default? Or something's up with speeds set by software... In theory with full hardware flow control, there's no reason to use anything other than 19200...

 

I have a real MIO, so if I can be of any assistance to test it would be good reason for me to try it out :-)



#5 tschak909 OFFLINE  

tschak909

    River Patroller

  • Topic Starter
  • 2,766 posts
  • Location:USA

Posted Thu Aug 16, 2018 12:56 PM

@Nezgear, yes please, here's a current build. It even has a SpartaDOS installer for hard disks. The program sets a baud rate of 1200bps for now, preferences is currently broken, please do not use. :)

 

(it is a bootable disk with MyDOS on it, with the setup and platoterm programs, as well as the currently selected handler set to autorun)

 

Attached File  plato-20160816.zip   45.78KB   10 downloads

 

-Thom


Edited by tschak909, Thu Aug 16, 2018 12:57 PM.


#6 bf2k+ OFFLINE  

bf2k+

    Stargunner

  • 1,769 posts
  • Location:Boot Factory BBS 2k+

Posted Thu Aug 16, 2018 2:59 PM

String of 'UUUUU' sounds like a baud rate mismatch.  I've seen this before.



#7 tschak909 OFFLINE  

tschak909

    River Patroller

  • Topic Starter
  • 2,766 posts
  • Location:USA

Posted Thu Aug 16, 2018 3:04 PM

It seems... setting the baud rate drop down in altirra to report 1200 baud seems to have fixed the issue...weird. It's working with Blackbox now.. trying with MIO.



#8 _The Doctor__ OFFLINE  

_The Doctor__

    Quadrunner

  • 5,112 posts
  • Location:10-0-11-00:02

Posted Thu Aug 16, 2018 10:06 PM

? I stand confused, I had yesterdays posted image running on real hardware using the MIO, I posted the steps I had to take to make it work... If you check your sys op caller logs you will see guest guest calls of very short duration until I managed to make it connect from there on out you can see I popped in and out of some of the online menus, and played checkers albeit a somewhat graphically glitchy game.   Never got any uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu's, thought baud rate mismatches should resemble never ending line noise...anything is possible...

 

I connected using 2400 baud and it worked, using 9600 and 19200 would download the char set with corrupted data and produce bit mapped looking mayhem...


Edited by _The Doctor__, Thu Aug 16, 2018 10:07 PM.


#9 tschak909 OFFLINE  

tschak909

    River Patroller

  • Topic Starter
  • 2,766 posts
  • Location:USA

Posted Thu Aug 16, 2018 10:55 PM

__the Doctor__ I do not have any real hardware, save for a stock 800, so I am having to do all my development and testing in emulation. I was able to get the MIO and BB to work, so long as I explicitly set the baud rates reported by Altirra against the baud rates that I initialized the program with. This is okay enough for me to move forward.

 

Right now, there is no hardware flow control, and I am needing to get input from those who actually know the innards of the serial handlers to be able to move forward, which, honestly, is only a few people on this community, but I do need their help.

 

-Thom



#10 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,573 posts
  • Location:USA

Posted Fri Aug 17, 2018 12:40 AM

Altirra forces U characters and framing errors into the serial stream when it detects a mismatch between the serial transmitter and receiver. In real circumstances, the characters you get depend on what was sent, the ratio between the mismatched baud rates, and whether the receiving software discards characters received with framing errors. Characters like U ($55) are more common when there is a large mismatch in baud rates as the stop bit happens to be correct with certain repeating patterns.

 

When a modem is involved, the speed at which the modem connects can dictate the speed between the modem and the computer. Low speed modems just replicate bytes across the wire and so the speeds have to match, as there is no flow control between the modems. IIRC you have to go to pretty high speed connections before LAPM is available for full holdoff/retransmission capability (9600 baud?). Altirra lets you cheat a bit and will let you hold off a low speed connection by local handshaking, which I don't believe is possible on a real modem. OTOH, it might be a bit too strict with the serial port speed on high speed connections where the modem does have the capability to buffer and hold off on both sides of it. For best results, match the connection rate in the modem settings to the rate used by the communications program.

 

(Forgot to mention about the MIO and BlackBox. The ACIAs are not in the same place, the MIO's is at $D1C0-D1DF and the BlackBox's is at $D120-D13F. In addition, the control signals are hooked up differently -- it's been a while, but reviewing my emulation source code, the MIO has handshaking signals hooked up to the ACIA while the BlackBox needs the CPU to handle them.)



#11 _The Doctor__ OFFLINE  

_The Doctor__

    Quadrunner

  • 5,112 posts
  • Location:10-0-11-00:02

Posted Fri Aug 17, 2018 12:55 AM

Always mixed up about that one.... I know the Black Box hardware handshaking always worked for me, but the MIO never seemed to work correctly until a special handler was written for use with the BBS, later on Spencer wrote the R: accelerator and it was the only other time I saw the MIO actively flipping the flow control lines



#12 tschak909 OFFLINE  

tschak909

    River Patroller

  • Topic Starter
  • 2,766 posts
  • Location:USA

Posted Fri Aug 17, 2018 1:33 AM

I have BOTH of those hyperspeed handlers, but they aren't helping, for one reason or another, and I do not know why.

 

-Thom



#13 _The Doctor__ OFFLINE  

_The Doctor__

    Quadrunner

  • 5,112 posts
  • Location:10-0-11-00:02

Posted Fri Aug 17, 2018 2:36 AM

if you can monitor memory while it executes, can you see if the drivers are getting clobbered or cc65 serial library doesn't bother hooking up to the drivers at all... bypassing their function

cc65 Atari library needs to be built up more, and some of this stuff needs the extras added in to them or be improved... looks like it ran back to Atari 800 pre infancy... did to great a job implementing stuff from possibly material before any of it was well documented or even understood and what printed had a great number of mistakes or errors in it.

 

In any event I suspect cc65 is using it's own serial method and bypassing

 

I am not sure what all was hardware flow control aware... I would suspect Puff's BBS would have controlled the lines and would look to his work because his board was high speed and multi user.. and I believe MUX'd as well.... certainly used hardware flow control in that scenario, I don't remember ever losing characters or having problems with it, and it ran on MyDOS afaik......     I highly suspect tearing into his BBS will yield results.... vaguely rmember some one saying they had it and would upload it...  hopefully it was done...


Edited by _The Doctor__, Fri Aug 17, 2018 2:49 AM.


#14 tschak909 OFFLINE  

tschak909

    River Patroller

  • Topic Starter
  • 2,766 posts
  • Location:USA

Posted Fri Aug 17, 2018 9:52 AM

This is CC65's serial driver. It indicates to the API that it supports hardware handshaking, but i don't see any evidence of it:

$ cat ser/atrrdev.s
;
; Christian Groessler, Dec-2001
; converted to driver interface Dec-2013
;
; RS232 routines using the R: device (currently tested with an 850 only)
;

        .include        "zeropage.inc"
        .include        "ser-kernel.inc"
        .include        "ser-error.inc"
        .include        "atari.inc"

        .macpack        module


; ------------------------------------------------------------------------
; Header. Includes jump table

.ifdef __ATARIXL__
        module_header   _atrxrdev_ser
.else
        module_header   _atrrdev_ser
.endif

; Driver signature

        .byte   $73, $65, $72           ; "ser"
        .byte   SER_API_VERSION         ; Serial API version number

; Library reference

libref: .addr   $0000

; Jump table

        .word   SER_INSTALL
        .word   SER_UNINSTALL
        .word   SER_OPEN
        .word   SER_CLOSE
        .word   SER_GET
        .word   SER_PUT
        .word   SER_STATUS
        .word   SER_IOCTL
        .word   SER_IRQ


        .rodata

rdev:   .byte   "R:", ATEOL, 0
bauds:  .byte   1               ; SER_BAUD_45_5
        .byte   2               ; SER_BAUD_50
        .byte   4               ; SER_BAUD_75
        .byte   5               ; SER_BAUD_110
        .byte   6               ; SER_BAUD_134_5
        .byte   7               ; SER_BAUD_150
        .byte   8               ; SER_BAUD_300
        .byte   9               ; SER_BAUD_600
        .byte   10              ; SER_BAUD_1200
        .byte   11              ; SER_BAUD_1800
        .byte   12              ; SER_BAUD_2400
        .byte   0               ; SER_BAUD_3600
        .byte   13              ; SER_BAUD_4800
        .byte   0               ; SER_BAUD_7200
        .byte   14              ; SER_BAUD_9600
        .byte   0               ; SER_BAUD_19200
        .byte   0               ; SER_BAUD_38400
        .byte   0               ; SER_BAUD_57600
        .byte   0               ; SER_BAUD_115200
        .byte   0               ; SER_BAUD_230400
        .byte   0               ; SER_BAUD_31250
        .byte   0               ; SER_BAUD_62500
        .byte   3               ; SER_BAUD_56_875
num_bauds       =       * - bauds
databits:
        .byte   48              ; SER_BITS_5
        .byte   32              ; SER_BITS_6
        .byte   16              ; SER_BITS_7
        .byte   0               ; SER_BITS_8
num_databits    =       * - databits
parities:
        .byte   0               ; SER_PAR_NONE
        .byte   4+1             ; SER_PAR_ODD
        .byte   2+8             ; SER_PAR_EVEN
        ;.byte  0               ; SER_PAR_MARK
        ;.byte  0               ; SER_PAR_SPACE
num_parities    =       * - parities

        .bss

; receive buffer
RECVBUF_SZ = 256
recv_buf: .res  RECVBUF_SZ

cm_run: .res    1       ; concurrent mode running?

        .data

rshand: .word   $ffff

; jump table into main program, initialized from libref
my_newfd:
        .byte   $4C
        .word   0
my__close:
        .byte   $4C
        .word   0
my_pushax:
        .byte   $4C
        .word   0
my_popax:
        .byte   $4C
        .word   0
my_findfreeiocb:
        .byte   $4C
        .word   0
my___do_oserror:
        .byte   $4C
        .word   0
my_fddecusage:
        .byte   $4C
        .word   0
my_fdtoiocb:
        .byte   $4C
        .word   0
my___inviocb:
        .byte   $4C
        .word   0
my_clriocb:
        .byte   $4C
        .word   0
my_CIOV:
        .byte   $4C
        .word   0

        .code

invbaud:
        lda     #<SER_ERR_BAUD_UNAVAIL
        ldx     #>SER_ERR_BAUD_UNAVAIL
openerr:
        rts


;----------------------------------------------------------------------------
; SER_OPEN: A pointer to a ser_params structure is passed in ptr1.
; Must return an SER_ERR_xx code in a/x.

SER_OPEN:
        jsr     do_open
        bne     openerr

; set line parameters
        lda     rshand
        ldx     #0
        jsr     my_fdtoiocb     ; get iocb index into X
        bmi     openerr         ; shouldn't happen
        tax

        ; set baud rate, word size, stop bits and ready monitoring

        ; build ICAX1 value
        ldy     #SER_PARAMS::BAUDRATE
        lda     (ptr1),y
        cmp     #num_bauds
        bcs     invbaud

        tay
        lda     bauds,y
        beq     invbaud
        sta     ICAX1,x

        ldy     #SER_PARAMS::DATABITS
        lda     (ptr1),y
        cmp     #num_databits
        bcs     init_err

        tay
        lda     databits,y
        ora     ICAX1,x
        sta     ICAX1,x

        ldy     #SER_PARAMS::STOPBITS
        lda     (ptr1),y
        clc
        ror     a
        ror     a
        ora     ICAX1,x
        sta     ICAX1,x

        lda     #36             ; xio 36, baud rate
        sta     ICCOM,x
        lda     #0
        ;ICAX2 = 0, monitor nothing
        sta     ICAX2,x
        sta     ICBLL,x
        sta     ICBLH,x
        sta     ICBAL,x
        sta     ICBAH,x
        jsr     my_CIOV
        bmi     cioerr

        ; check if the handshake setting is valid
        ldy     #SER_PARAMS::HANDSHAKE
        lda     (ptr1),y
        cmp     #SER_HS_HW      ; this is all we support
        bne     init_err

        ; set handshake lines
        lda     #34             ; xio 34, set cts, dtr etc
        sta     ICCOM,x
        lda     #192+48+3       ; DTR on, RTS on, XMT on
        sta     ICAX1,x
        jsr     my_CIOV
        bmi     cioerr

        ; set translation and parity
        ldy     #SER_PARAMS::PARITY
        lda     (ptr1),y
        cmp     #num_parities
        bcs     init_err

        tay
        lda     parities,y
        ora     #32             ; no translation
        sta     ICAX1,x

        lda     #38             ; xio 38, translation and parity
        sta     ICCOM,x
        jsr     my_CIOV
        bmi     cioerr

        lda     #<SER_ERR_OK
        tax                             ; A is zero
        rts

inverr: jmp     my___inviocb

cioerr:
        ; @@@ need to close IOCB here
        jsr     my_fddecusage   ; decrement usage counter of fd as open failed

init_err:
        ldx     #0
        lda     #SER_ERR_INIT_FAILED
        rts

;---- open the device

do_open:
        jsr     my_findfreeiocb
        bne     init_err
        txa
        tay                     ; move iocb # into Y
        lda     #3
        sta     tmp3            ; name length + 1
        lda     #<rdev
        ldx     #>rdev
        jsr     my_newfd
        tya
        bcs     @doopen         ; C set: open needed / device not already open

        pha
        jsr     SER_CLOSE       ;** shut down if started  @@@TODO check this out!!
        pla

@doopen:tax
        pha
        jsr     my_clriocb
        pla
        tax
        lda     #<rdev
        sta     ICBAL,x
        lda     #>rdev
        sta     ICBAH,x
        lda     #OPEN
        sta     ICCOM,x

        lda     #$0D            ; mode in+out+concurrent
        sta     ICAX1,x
        lda     #0
        sta     ICAX2,x
        sta     ICBLL,x         ; zap buf len
        sta     ICBLH,x
        jsr     my_CIOV
        bmi     cioerr

        lda     tmp2            ; get fd (from newfd)
        sta     rshand
        ldx     #0
        stx     rshand+1
        txa
        rts

;----------------------------------------------------------------------------
; CLOSE: Close the port, disable interrupts and flush the buffer. Called
; without parameters. Must return an error code in a/x.
;
;----------------------------------------------------------------------------
; SER_UNINSTALL routine. Is called before the driver is removed from memory.
; Must return an SER_ERR_xx code in a/x.
;

SER_UNINSTALL:
SER_CLOSE:
        lda     rshand
        cmp     #$ff
        beq     @done

        ldx     rshand+1
        jsr     my__close
        ldx     #$ff
        stx     rshand
        stx     rshand+1
        inx
        stx     cm_run
@done:  lda     #<SER_ERR_OK
        ldx     #>SER_ERR_OK
        rts

;----------------------------------------------------------------------------
; SER_GET: Will fetch a character from the receive buffer and store it into the
; variable pointer to by ptr1. If no data is available, SER_ERR_NO_DATA is
; return.
;

SER_GET:
        ldy     rshand
        cpy     #$ff
        beq     ni_err           ; work only if initialized

        lda     rshand
        ldx     #0
        jsr     my_fdtoiocb
        tax
        lda     cm_run          ; concurrent mode already running?
        bne     @go
        jsr     ena_cm          ; turn on concurrent mode

@go:    ; check whether there is any input available

        lda     #STATIS         ; status request, returns bytes pending
        sta     ICCOM,x
        jsr     my_CIOV
        bmi     ser_error

        lda     DVSTAT+1        ; get byte count pending
        ora     DVSTAT+2
        beq     @nix_da         ; no input waiting...

        ; input is available: get it!

        lda     #GETCHR         ; get raw bytes
        sta     ICCOM,x         ; in command code
        lda     #0
        sta     ICBLL,x
        sta     ICBLH,x
        sta     ICBAL,x
        sta     ICBAH,x
        jsr     my_CIOV         ; go get it
        bmi     ser_error

        ldx     #0
        sta     (ptr1,x)        ; return received byte
        txa
        rts

@nix_da:lda     #SER_ERR_NO_DATA
        ldx     #0
        rts

ser_error:
        lda     #SER_ERR_OVERFLOW       ; there is no large selection of serial error codes... :-/
        ldx     #0
        rts

ni_err: lda     #SER_ERR_NOT_OPEN
        ldx     #0
        rts

;----------------------------------------------------------------------------
; SER_PUT: Output character in A.
; Must return an error code in a/x.
;

SER_PUT:
        ldy     rshand
        cpy     #$ff
        beq     ni_err          ; work only if initialized

        pha                     ; remember char to write
        lda     rshand
        ldx     #0
        jsr     my_fdtoiocb
        tax

        lda     cm_run          ; concurrent mode already running?
        bne     @go
        jsr     ena_cm          ; turn on concurrent mode

        ; @@@TODO:       check output buffer overflow
@go:    lda     #PUTCHR         ; put raw bytes
        sta     ICCOM,x         ; in command code
        lda     #0
        sta     ICBLL,x
        sta     ICBLH,x
        sta     ICBAL,x
        sta     ICBAH,x
        pla                     ; get the char back
        jsr     my_CIOV         ; go do it
        bmi     ser_error
        lda     #0
        tax
        rts

;----------------------------------------------------------------------------
; SER_STATUS: Return the status in the variable pointed to by ptr1.
; Must return an error code in a/x.
;

SER_STATUS:
        ; fall through to SER_IOCTL

;----------------------------------------------------------------------------
; SER_IOCTL: Driver defined entry point. The wrapper will pass a pointer to ioctl
; specific data in ptr1, and the ioctl code in A.
; Must return an error code in a/x.
;

SER_IOCTL:
        lda     #<SER_ERR_INV_IOCTL     ; We don't support ioclts for now
        ldx     #>SER_ERR_INV_IOCTL
        rts

;----------------------------------------------------------------------------
; SER_IRQ: Not used on the Atari
;

SER_IRQ     = $0000

;----------------------------------------------------------------------------
; SER_INSTALL routine. Is called after the driver is loaded into memory. If
; possible, check if the hardware is present.
; Must return an SER_ERR_xx code in a/x.

SER_INSTALL:
        ; check if R: device is installed
        ldy     #0
search: lda     HATABS,y                ; get device name
        cmp     #'R'
        beq     found
        iny
        iny
        iny
        cpy     #MAXDEV
        bcc     search

; R: device not found, return error

        lda     #<SER_ERR_NO_DEVICE
        ldx     #0
        rts

; R: device found, initialize jump table into main program

found:  lda     ptr3
        pha
        lda     ptr3+1
        pha
        lda     libref
        sta     ptr3
        lda     libref+1
        sta     ptr3+1

        ldy     #0
        lda     (ptr3),y
        sta     my_newfd+1
        iny
        lda     (ptr3),y
        sta     my_newfd+2
        iny

        lda     (ptr3),y
        sta     my__close+1
        iny
        lda     (ptr3),y
        sta     my__close+2
        iny

        lda     (ptr3),y
        sta     my_pushax+1
        iny
        lda     (ptr3),y
        sta     my_pushax+2
        iny

        lda     (ptr3),y
        sta     my_popax+1
        iny
        lda     (ptr3),y
        sta     my_popax+2
        iny

        lda     (ptr3),y
        sta     my_findfreeiocb+1
        iny
        lda     (ptr3),y
        sta     my_findfreeiocb+2
        iny

        lda     (ptr3),y
        sta     my___do_oserror+1
        iny
        lda     (ptr3),y
        sta     my___do_oserror+2
        iny

        lda     (ptr3),y
        sta     my_fddecusage+1
        iny
        lda     (ptr3),y
        sta     my_fddecusage+2
        iny

        lda     (ptr3),y
        sta     my_fdtoiocb+1
        iny
        lda     (ptr3),y
        sta     my_fdtoiocb+2
        iny

        lda     (ptr3),y
        sta     my___inviocb+1
        iny
        lda     (ptr3),y
        sta     my___inviocb+2
        iny

        lda     (ptr3),y
        sta     my_clriocb+1
        iny
        lda     (ptr3),y
        sta     my_clriocb+2
        iny

        lda     (ptr3),y
        sta     my_CIOV+1
        iny
        lda     (ptr3),y
        sta     my_CIOV+2
        ;iny

        pla
        sta     ptr3+1
        pla
        sta     ptr3

        lda     #<SER_ERR_OK
        tax                     ; A is zero
        rts


; enable concurrent rs232 mode
; gets iocb index in X
; all registers destroyed

.proc   ena_cm

        lda     #40             ; XIO 40, start concurrent IO
        sta     ICCOM,x
        sta     cm_run          ; indicate concurrent mode is running
        lda     #$0D            ; value from 850 manual, p62.  must be $0D?,
        sta     ICAX1,x         ;  or any non-zero?
        lda     #0
        sta     ICAX2,x
        lda     #<recv_buf
        sta     ICBAL,x
        lda     #>recv_buf
        sta     ICBAH,x
        lda     #<RECVBUF_SZ
        sta     ICBLL,x
        lda     #>RECVBUF_SZ
        sta     ICBLH,x
        jmp     my_CIOV

.endproc        ;ena_cm

-Thom



#15 thorfdbg OFFLINE  

thorfdbg

    Dragonstomper

  • 782 posts

Posted Fri Aug 17, 2018 11:11 AM


ACCORDING to the technical manual for the 850, I can IN THEORY VIA CIO disengage Concurrent mode, change RTS, and subsequently engage concurrent mode to resume.

 

Will this mean that I lose characters? I'm guessing from the way the 850 works, this is a big fat YES.

 

Yes, it means yes, you can loose characters. There is no hardware flow control between the 850 and the modem, simply because there is no logic within the 850 which could handle it. In concurrent mode, the only thing the CPU in the 850 does is to mirror the signal from the modem line on the SIO line. There is not even any decoding taking place - it is a "bit copy". Whatever junk comes in at the modem side will appear at the SIO end, as if there is a cable between them (almost).

 

Which means that there is no buffer in the 850 into which incoming characters could overflow.

 

To keep the long story short: Hardware handshake on the 850 is borken by design. You need to use some software protocol on top for handhaking.



#16 tschak909 OFFLINE  

tschak909

    River Patroller

  • Topic Starter
  • 2,766 posts
  • Location:USA

Posted Fri Aug 17, 2018 11:15 AM

Yes, it means yes, you can loose characters. There is no hardware flow control between the 850 and the modem, simply because there is no logic within the 850 which could handle it. In concurrent mode, the only thing the CPU in the 850 does is to mirror the signal from the modem line on the SIO line. There is not even any decoding taking place - it is a "bit copy". Whatever junk comes in at the modem side will appear at the SIO end, as if there is a cable between them (almost).

 

Which means that there is no buffer in the 850 into which incoming characters could overflow.

 

To keep the long story short: Hardware handshake on the 850 is borken by design. You need to use some software protocol on top for handhaking.

 

*deeeep-breath*

 

PLATO supports XON and XOFF, however, due to the massive asymmetry of the connection (seriously, think about it, you're connecting a teeny tiny RS232 modem to a TCP connection that can spit out many megabytes a second of data.), so by the time XON/XOFF came through in-band, your buffer would have overflowed, many times over.

 

The only workable solution is to literally signal the modem to stop.

 

-Thom



#17 Nezgar OFFLINE  

Nezgar

    Stargunner

  • 1,168 posts
  • Location:Regina SK Canada

Posted Fri Aug 17, 2018 11:25 AM

The only workable solution is to literally signal the modem to stop.

I remember S register commands on my USRobotics modems to have the local modem handle the XON/XOFF software flow control itself, and stop the flow for a LAPM/MNP buffered type connection for exaclty the type of lag problem you describe. I guess those characters would get filtered from the outgoing stream though, so would possibly break some file transfer protocols. I'll check my manuals.

This again would require a hardware serial gateway device to do extra work processing xon/xoff, outside of the program.

I'll check my usr modem documentation later.

#18 thorfdbg OFFLINE  

thorfdbg

    Dragonstomper

  • 782 posts

Posted Fri Aug 17, 2018 11:41 AM

 

*deeeep-breath*

 

PLATO supports XON and XOFF, however, due to the massive asymmetry of the connection (seriously, think about it, you're connecting a teeny tiny RS232 modem to a TCP connection that can spit out many megabytes a second of data.), so by the time XON/XOFF came through in-band, your buffer would have overflowed, many times over.

Yes, that's all understood. I'm not suggesting XON/XOFF in particular. I'm just wondering which amounts of data you want to pump through the line in first place considering the itsy-bitsy tiny system (as in: An Atari 8-bit) sitting at one end of the line. As long as it is just text, you're probably fine with no handshake.

 

As soon as it is data, I would check whether the xmodem-family of protocols is probably something worth looking into. Some of the advanced members (such as zmodem) do have error recovery and error resiliance built-in, and you're much better off just re-transmitting a block if it got lost instead of switching to xon/xoff, which also only works for ASCII.

 

Yes, sorry for the bad news, but the 850 is not really very well designed for serious work.



#19 tschak909 OFFLINE  

tschak909

    River Patroller

  • Topic Starter
  • 2,766 posts
  • Location:USA

Posted Fri Aug 17, 2018 12:04 PM

I can't do that. PLATO protocol is set in stone. There are many other terminals which rely on it. 

 

I did make a slowdown proxy, but this is no different than setting the baud to 1200bps.

 

So ok, will just write off the 850. urgh.

 

-Thom


Edited by tschak909, Fri Aug 17, 2018 12:05 PM.


#20 _The Doctor__ OFFLINE  

_The Doctor__

    Quadrunner

  • 5,112 posts
  • Location:10-0-11-00:02

Posted Fri Aug 17, 2018 6:19 PM

you could still hard code it to use the 850 flow line to regulate thru-put, let's say you can process incoming stream full blast for 1 sec.. then it starts dropping stuff, just drop rts before the second is up and toggle it at the maximum the atari can process the stream at until the block is done. the flow rate may be 2000 but the baud rate will still be 2400.... this is how we set up some peculiar situations with faster baud rates on controlling production lines... remember we are using it to control the flow not the baud rate.... after a period of inactivity set up the interval before flow regulation again... might I also add this help in the sio drive situation as well, though switch modes concurrent/block is the thing done...


Edited by _The Doctor__, Fri Aug 17, 2018 6:19 PM.


#21 _The Doctor__ OFFLINE  

_The Doctor__

    Quadrunner

  • 5,112 posts
  • Location:10-0-11-00:02

Posted Fri Aug 17, 2018 7:47 PM

CIO disengage Concurrent mode change RTS and subsequently engage concurrent mode to resume. the 850 might hold 1 character, and might still receive it at the Atari, not lost.... the lantronix or a well made modem should have a good buffer, so it normally can hold a chunk of data without worry. we aren't serving live movies and sound so it's not like you are going to push mega bytes at a time.... just regulate rts to control the flow enough to allow processing when the terminal get saturated, then either wait till the Atari has fished all it's data off and raise it, cyling the rts mid flow might eat up more processing time and there is that lose a character worry (the less cycling the better)... the modems should communicate the buffer condition to the remote modem... both buffers can fill... the remote modem will then tell the server I'm not ready and the server should start holding off sending any more data until one or both modems say okay to send....  getting a little tired of hearing it's not possible when this sort of this was done already... mind you better devices did come along like the Black Box and MIO and lets not forget the microphaser serial buffers and the like used to deal with some of the situations.

I still have both the parallel buffer and the serial buffer... and yes it was used to buffer a printer (parallel) and a modem (serial)

many solutions exist but if you don't like them, how about someone makes a new serial interface to your liking.... With as big a head start the Atari had on this with TLP and all you would think it could be coded to run faster with all the improvements and knowledge as well as tricks discovered on the Atari and the different tools available... just may be using all those discoveries and coding up in machine language might be the only way to make improvements to function and speed


Edited by _The Doctor__, Fri Aug 17, 2018 7:51 PM.


#22 tschak909 OFFLINE  

tschak909

    River Patroller

  • Topic Starter
  • 2,766 posts
  • Location:USA

Posted Fri Aug 17, 2018 9:52 PM

My goal right now is to get something usable for a first version, then it can be optimized, one such improvement that I can see immediately, is to optimize text output by not needing to plot every single dot indivdually, but rather pre-shift and try to output the font data directly after shifting onto the bitmap.

 

As for serial, I will try to add hardware flow control as best I can. I am actually trying to ping Steve Tucker to get some help with APE's R: handler, because it is sending data to the system too fast for the terminal to process.

 

-Thom



#23 _The Doctor__ OFFLINE  

_The Doctor__

    Quadrunner

  • 5,112 posts
  • Location:10-0-11-00:02

Posted Fri Aug 17, 2018 10:31 PM

APE's R: device still gets baud rate set using the same as the 850 etc.... however, if your still getting data at too fast a rate...

 

go to modems tab , r:internet modem, look for default metering level.... bump it up a notch.... to 2,3 or 4.... if it's not what you expect bump it the other way

 

not sure if changing the master rs232 timing in the SIO speed section will help but you can give that a try if meter doesn't work out for you....though I always believed it was drive specific...

 

this is what I remember for some isolated cases would be needed


Edited by _The Doctor__, Fri Aug 17, 2018 10:34 PM.


#24 tschak909 OFFLINE  

tschak909

    River Patroller

  • Topic Starter
  • 2,766 posts
  • Location:USA

Posted Fri Aug 17, 2018 10:39 PM

The APE users manual points to an Under Construction page.

 

-Thom



#25 _The Doctor__ OFFLINE  

_The Doctor__

    Quadrunner

  • 5,112 posts
  • Location:10-0-11-00:02

Posted Fri Aug 17, 2018 10:42 PM

which sio2pc (usb or r232) are you using with APE?

 

please click modem tab R: Internet Modem and adjust default metering level on right hand side near the green checkmark okay button







Also tagged with one or more of these keywords: technical questions, atari 850, blackbox, mio, acia, serial port, r: handler

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users