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,
[email protected]
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)
