INTL 3:770/1 3:770/3   
   REPLYADDR brain@jbrain.com   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  384b54b9   
   REPLY: <20211114-191204.737.0@George.ssl-us.astraweb.com> 10a607d8   
   PID: SoupGate-Win32 v1.05   
   On 11/14/2021 1:12 PM, George wrote:   
   > Jim Brain says...   
   >   
   >   > I forwarded it the cbm-hackers mailing list, where a   
   >   > bunch of the technical gurus hang out.   
   >   
   > Thanks very much, Jim.  It's too bad the +4 didn't get wider   
   > use.  The 6551 ACIA was a major improvement over the   
   > horrendous emulation fiasco in the C64.  I wrote replacement   
   > code for the C64, but still only got it up to 2400 baud in   
   > full duplex.  The 6551 could I'm sure do 9600 baud, and   
   > maybe 19,200.  You just have to service one interrupt per   
   > byte, and the 6551 does all the work.   
      
   Indeed you can.  You can also do 115200 on the IC by using the /16 Bps   
   clock override in the register config.  The 6551A can do 38400 normal   
   and 230400 using the same /16 trick.   
      
   CBM Hackers responses:   
      
   Hm... The way I read the datasheet of the 6551, you need to check the   
   status register whether a byte is waiting (Bit 3 set) and if yes, grab   
   the byte and store it into the buffer. That BEQ doesn't really make   
   sense in this context.   
      
     Gerrit   
      
   If I remember well I have used the serial port as tty terminal in the   
   past and it was working fine (although probably that does not use a 0x0   
   byte). Also at the university a guy has written a SLIP protocol software   
   and could get IP packets. He has created telnet, ftp and it was working.   
   It was the subject of his thesis and he has graduated.   
      
   Istvan   
      
   Maybe you could provide a bit more context on your note...   
      
   I read your note that the receive routine will read the READ register of   
   the 6551 ($fd00) and then go elsewhere of the value is 0, storing it at   
   $0fd5 (though you also say $07d5, which confused me, maybe a typo?) if   
   <>0.  The text, though, states that the routine will receive a null   
   byte, not store it, but then when a non-null byte is received, it will   
   store the null in the place the non-null byte was supposed to be stored.   
     That would seem to be a huge issue, and I'm not aware anyone sees such   
   behavior.   
      
   Am I reading your notes correctly?   
      
   Gerrit's comment above is noting that the BEQ doesn't make any sense, as   
   by the time the routine reads data from the READ register, it should   
   always have previously checked the data available flag.  If set, the   
   data in the read register should be stored regardless, and no   
   conditional should be performed.   
      
   Jim   
   --- SoupGate-Win32 v1.05   
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)   
   SEEN-BY: 1/123 14/0 18/200 90/1 103/705 105/81 120/340 123/131 129/305   
   SEEN-BY: 153/250 757 154/10 218/700 840 220/70 221/1 6 226/17 30 227/114   
   SEEN-BY: 229/424 426 428 664 700 240/1120 5832 249/1 206 317 400 261/38   
   SEEN-BY: 267/800 282/1038 301/1 113 317/3 322/757 335/364 340/1000   
   SEEN-BY: 341/66 342/200 633/280 712/848 770/1 3 100 340 772/210 220   
   SEEN-BY: 772/230 920/1 4500/1 5058/104   
   PATH: 770/3 1 218/840 221/6 301/1 229/426