INTL 3:770/1 3:770/3
REPLYADDR gh424NO584SPAM@cox.net
REPLYTO 3:770/3.0 UUCP
MSGID: <20211115-155041.792.0@George.ssl-us.astraweb.com> 12a1d73e
REPLY: 384b54b9
PID: SoupGate-Win32 v1.05
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)
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
|
