tschak909 Posted August 16, 2018 Share Posted August 16, 2018 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 Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted August 16, 2018 Share Posted August 16, 2018 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.lenardspencer.com/Lenspencer/hyperspd.html 2 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 16, 2018 Author Share Posted August 16, 2018 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 Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted August 16, 2018 Share Posted August 16, 2018 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 :-) 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 16, 2018 Author Share Posted August 16, 2018 (edited) @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) plato-20160816.zip -Thom Edited August 16, 2018 by tschak909 1 Quote Link to comment Share on other sites More sharing options...
+bf2k+ Posted August 16, 2018 Share Posted August 16, 2018 String of 'UUUUU' sounds like a baud rate mismatch. I've seen this before. 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 16, 2018 Author Share Posted August 16, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 17, 2018 Share Posted August 17, 2018 (edited) ? 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 August 17, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 17, 2018 Author Share Posted August 17, 2018 __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 Quote Link to comment Share on other sites More sharing options...
phaeron Posted August 17, 2018 Share Posted August 17, 2018 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.) 4 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 17, 2018 Share Posted August 17, 2018 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 17, 2018 Author Share Posted August 17, 2018 I have BOTH of those hyperspeed handlers, but they aren't helping, for one reason or another, and I do not know why. -Thom Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 17, 2018 Share Posted August 17, 2018 (edited) 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 August 17, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 17, 2018 Author Share Posted August 17, 2018 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 Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted August 17, 2018 Share Posted August 17, 2018 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. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 17, 2018 Author Share Posted August 17, 2018 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 Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted August 17, 2018 Share Posted August 17, 2018 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. Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted August 17, 2018 Share Posted August 17, 2018 *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. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 17, 2018 Author Share Posted August 17, 2018 (edited) 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 August 17, 2018 by tschak909 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 18, 2018 Share Posted August 18, 2018 (edited) 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 August 18, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 18, 2018 Share Posted August 18, 2018 (edited) 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 August 18, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 18, 2018 Author Share Posted August 18, 2018 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 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 18, 2018 Share Posted August 18, 2018 (edited) 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 August 18, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 18, 2018 Author Share Posted August 18, 2018 The APE users manual points to an Under Construction page. -Thom Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 18, 2018 Share Posted August 18, 2018 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.