From: brain@jbrain.com   
      
   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: you cannot sedate... all the things you hate (1:229/2)