Subj : Re: Plus 4 rom error - is there any place to report it?
To   : All
From : George
Date : Mon Nov 15 2021 09:50 am

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.

 > If I remember well I have used the serial port as tty
 > terminal in the past and it was working fine (although
 > probably that does not use a 0x0 byte). Also at the
 > university a guy has written a SLIP protocol software
 > and could get IP packets. He has created telnet, ftp and
 > it was working. It was the subject of his thesis and he
 > has graduated.

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.

But I would just say that as far as I can tell the value
$fd00 occurs only twice in the entire rom, once to read from
that location, and once to write to it.  It also seems
pretty clear that if it takes the BEQ, it then loads in the
value from $07D5 and writes it into the input buffer.  If it
never writes a null into $07d5, there's no way a received
null will ever get into that buffer.

 > I read your note that the receive routine will read the
 > READ register of the 6551 ($fd00) and then go elsewhere
 > of the value is 0, storing it at $0fd5 (though you also
 > say $07d5, which confused me, maybe a typo?) if <>0.

Yes.  A typo.  Sorry.  It's $07d5.

 > 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.

 > Gerrit's comment above is noting that the BEQ doesn't
 > make any sense, as by the time the routine reads data
 > from the READ register, it should always have previously
 > checked the data available flag.  If set, the data in
 > the read register should be stored regardless, and no
 > conditional should be performed.

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.

George
--- SoupGate-Win32 v1.05
 * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

.