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