INTL 3:770/1 3:770/3   
   REPLYADDR brain@jbrain.com   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  12bdf201   
   REPLY: <20211115-155041.792.0@George.ssl-us.astraweb.com> 12a1d73e   
   PID: SoupGate-Win32 v1.05   
   On 11/15/2021 9:50 AM, George wrote:   
   > Jim Brain says...   
   >   
   >   > 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.   
   >   
   > It's been a while since I looked at this, but I believe the   
   > BEQ is there to bypass the code that checks if the byte is   
   > Xon or Xoff.   
      
   It might make sense to write up a bit more of the disassembly with your   
   notes to create clarity.   
   >   
   > I don't know if normal traffic would encounter null bytes,   
   > but I would think file transfers might.  In any case, it's   
   > possible to avoid any problem if your software takes over   
   > the beginning of the IRQ routine, duplicates it up to this   
   > point, makes the fix, then jumps back into ROM.  So the fact   
   > that all his stuff worked doesn't mean the error isn't   
   > there.  He may have used his own code.The original post may have confused   
   some folks, but I do think he was   
   aware we were discussing the stock routines, so I don't think he was   
   referring to home-spun code.   
   >   
   >   
   >   
   >   > 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.   
   >   
   > No.  $07d5 is the temp storage location for the incoming   
   > byte.  A non-null byte is first stored there, then later   
   > retrieved and stored into the buffer.  A null byte is NOT   
   > stored in $07d5, but the value in $07d5 is retrieved anyway.   
   > The result would be that a null byte produces a duplicate of   
   > whatever the last non-null byte was.   
   Ah, that clears things up for me.  So, if $34 $00 were the data items,   
   the data delivered to the +4 app would be $34 $34   
   >   
   >   
   > I agree, except for the Xon/Xoff check. I'll have to double   
   > check that, but my memory is that it compares the received   
   > byte to zero-page locations that contain the values, if any,   
   > being used for Xon and Xoff. If Xon/Xoff is NOT being used,   
   > then those zero-page values are probably zeros, and in that   
   > case for a null byte you need to skip over the test because   
   > otherwise you would get a false match. I think that's why the   
   > BEQ is there.   
   Ah, understood.   
   >   
   > George   
   >   
      
      
   --   
   Jim Brain, brain@jbrain.com   
   RETRO Innovations: Contemporary Gear for Classic Systems   
   www.go4retro.com   
   --- 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