Subj : Re: Plus 4 rom error - is there any place to report it?
To   : George
From : Jim Brain
Date : Fri Nov 19 2021 10:30 am

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)

.