• Plus 4 rom error - is there any place to report it?

    From George@3:770/3 to All on Sat Nov 13 22:03:02 2021
    I was going over some of my old CBM files from back in the day, and ran
    across an error I had found in the Plus 4 kernel rom. I don't think I ever found a way to report it to anyone, so I thought I would see if anything
    has changed.

    The error is in the 6551 ACIA servicing routine where a byte is read in
    from the ACIA:

    LDA $FD00
    BEQ EAC2
    STA $07D5

    Incoming bytes are first stored at $0FD5, and later moved from there into
    the input buffer. But as the rom is written, any null byte (00) received
    would be later stored as whatever the most recent non-null byte was. And
    it's impossible to receive a null byte. The solution is to reverse the
    second and third instructions:

    LDA $FD00
    STA $07D5
    BEQ EAC2

    Or you could duplicate the beginning of the IRQ servicing up to this point
    in your code, with the correction, then jump back into the rom.

    Of course, this being the Plus 4, it may be that nobody would ever care
    about this, but it would be nice to make a record in case anyone ever
    wanted to make other revisions to the ROM, or actually make use of the UART capability of the Plus 4.

    George Hug
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Bernd Bachmann@2:240/8001.16 to George on Sun Nov 14 16:00:00 2021
    Hello George,

    that bug you discovered on the Plus 4 kernel rom sounds quite interesting.
    I still use the Plus 4 since many many years (actually it was my very
    first 8bit computer I owned).

    Maybe you are interested in posting this bug on the Plus4 website we have
    at: https://plus4world.powweb.com/

    There is a forum on this site were we could discuss this bug.
    Feel free to join us there! :-)

    Best regards,
    Bernd (aka Fonsis on the Plus4world Site)



    I was going over some of my old CBM files from back in the day, and ran across an error I had found in the Plus 4 kernel rom. I don't think I ever .....
    about this, but it would be nice to make a record in case anyone ever
    wanted to make other revisions to the ROM, or actually make use of the UART capability of the Plus 4.

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


    Viele Gruesse
    Bernd
    --- OpenXP 5.0.33
    * Origin: Antix Linux (2:240/8001.16)
  • From Jim Brain@3:770/3 to George on Sun Nov 14 09:52:21 2021
    On 11/13/2021 10:03 PM, George wrote:
    I was going over some of my old CBM files from back in the day, and ran across an error I had found in the Plus 4 kernel rom. I don't think I ever found a way to report it to anyone, so I thought I would see if anything
    has changed.

    The error is in the 6551 ACIA servicing routine where a byte is read in
    from the ACIA:

    LDA $FD00
    BEQ EAC2
    STA $07D5

    Incoming bytes are first stored at $0FD5, and later moved from there into
    the input buffer. But as the rom is written, any null byte (00) received would be later stored as whatever the most recent non-null byte was. And it's impossible to receive a null byte. The solution is to reverse the second and third instructions:

    LDA $FD00
    STA $07D5
    BEQ EAC2

    Or you could duplicate the beginning of the IRQ servicing up to this point
    in your code, with the correction, then jump back into the rom.

    Of course, this being the Plus 4, it may be that nobody would ever care
    about this, but it would be nice to make a record in case anyone ever
    wanted to make other revisions to the ROM, or actually make use of the UART capability of the Plus 4.

    George Hug


    I forwarded it the cbm-hackers mailing list, where a bunch of the
    technical gurus hang out.

    Jim

    --
    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)
  • From George@3:770/3 to All on Sun Nov 14 13:12:04 2021
    Jim Brain says...

    I forwarded it the cbm-hackers mailing list, where a
    bunch of the technical gurus hang out.

    Thanks very much, Jim. It's too bad the +4 didn't get wider
    use. The 6551 ACIA was a major improvement over the
    horrendous emulation fiasco in the C64. I wrote replacement
    code for the C64, but still only got it up to 2400 baud in
    full duplex. The 6551 could I'm sure do 9600 baud, and
    maybe 19,200. You just have to service one interrupt per
    byte, and the 6551 does all the work.

    While I'm here, is there any need for an ML Monitor program
    for the C64, or has that already been done many times? Mine
    is similar to the Monitor rom section found in the +4, but
    is loaded into the C64 by a Basic loader, and you say where
    you want it placed. My memory is it's exactly 2K (8 pages).
    Comes with a manual. I think one difference between mine
    and the +4 logic is that mine correctly moves overlapping
    blocks in both directions, and the +4 didn't.

    I also have an assembler that runs on the C64, but I assume
    people just cross-assemble on their PCs these days.

    And finally, I have an article I wrote for Transactor, but
    they shut down before publishing it, which I think is the
    final word on the REL file bug in the 1541. Includes the
    1541 rom fix to eliminate it.

    If there's any use for any of this, I could post it in a
    Github repo.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From George@3:770/3 to All on Sun Nov 14 12:40:44 2021
    Bernd Bachmann says...

    that bug you discovered on the Plus 4 kernel rom sounds
    quite interesting. I still use the Plus 4 since many
    many years (actually it was my very first 8bit computer
    I owned).

    Maybe you are interested in posting this bug on the
    Plus4 website we have at: https://plus4world.powweb.com
    /

    There is a forum on this site were we could discuss this
    bug. Feel free to join us there! :-)

    Thanks Bernd, I just posted there. Hope it will be useful
    to someone.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Brain@3:770/3 to George on Mon Nov 15 00:44:15 2021
    On 11/14/2021 1:12 PM, George wrote:
    Jim Brain says...

    > I forwarded it the cbm-hackers mailing list, where a
    > bunch of the technical gurus hang out.

    Thanks very much, Jim. It's too bad the +4 didn't get wider
    use. The 6551 ACIA was a major improvement over the
    horrendous emulation fiasco in the C64. I wrote replacement
    code for the C64, but still only got it up to 2400 baud in
    full duplex. The 6551 could I'm sure do 9600 baud, and
    maybe 19,200. You just have to service one interrupt per
    byte, and the 6551 does all the work.

    Indeed you can. You can also do 115200 on the IC by using the /16 Bps
    clock override in the register config. The 6551A can do 38400 normal
    and 230400 using the same /16 trick.

    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.

    Gerrit

    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.

    Istvan

    Maybe you could provide a bit more context on your note...

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

    Am I reading your notes correctly?

    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.

    Jim
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From George@3:770/3 to All on Mon Nov 15 09:50:41 2021
    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)
  • From George@3:770/3 to All on Mon Nov 15 22:22:19 2021
    Steven Combs sent me a copy of the Term-80 terminal program, the Plus/4 version, which works well on the Plus/4. I have nothing to test it on, but
    was able to examine the .PRG file, and found that the author uses his own
    IRQ code for handling the 6551. So that's a case where the rom error would never come into play because the author uses his own replacement code
    instead of the rom code. He does that by hijacking the IRQ ram vector at $0314.

    I've asked Steven to send me Plus/4 terminal software that doesn't work so well. Maybe we can find one that doesn't bring in new ACIA handler code,
    and we can see if any errors match the expected doubling of non-null
    characters that the rom error should produce. Then if he can arrange to
    flash a new eprom containg the fix, we can see if performance is improved.

    Here's Steven's video on the Plus/4 6551:

    https://www.youtube.com/watch?v=daoAllAv9qo
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From George@3:770/3 to All on Sun Nov 28 15:45:15 2021
    Jim Brain says...

    Do you have the VICE emulator? It supports the +4 and
    the built in 6551, and can tie that 6551 ACIA to a real
    or virtual serial port. You could test it there if
    desired.

    I haven't been able to get the Plus/4 ACIA emulation to work
    in VICE. The rom emulation knows about the ACIA, and will
    let me open a channel to it, and sets the command and
    control registers, but it doesn't actually do anything, such
    as generating interrupts. I tried the +acia command line
    switch, but then it doesn't even let me open the channel.
    It errors out with Device Not Present.

    If you know of a way to get 6551 emulation to function,
    please give me the exact sequence of what I need to do.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From George@3:770/3 to All on Sun Nov 28 17:51:27 2021
    If anyone has a Plus/4 and has nothing better to do, it would be helpful if
    you could run the programs listed below and report the results. The
    programs report the total number of ACIA interrupts which occur while transmitting 256 bytes of data continuously at 2400 baud. They should be
    run with nothing plugged into the User Port - no modem or anything.

    My suspicion is that the single-byte transmit buffer of the Plus/4 results
    in back-to-back double interrupts being generated for each byte
    transmitted, which can cause problems at high speed. If that's the case,
    the first program will report about 512 interrupts, and the second about
    256. But there may be no difference. Anyway, I just need to know.

    irqtest1
    --------

    10 rem irq test1 to count interrupts
    20 cb = 819
    30 for i = 0 to 161
    40 read a
    50 poke cb+i,a
    60 next
    70 sys cb
    75 open 2,2,0,chr$(26)+chr$(7)
    80 sys 940
    85 close 2
    90 sys 845
    95 print peek(1009)*256 + peek(1008)
    100 data 120,32,85,252,186,202,189,0
    110 data 1,24,105,36,141,20,3,232
    120 data 189,0,1,105,0,141,21,3
    130 data 88,96,120,169,14,141,20,3
    140 data 169,206,141,21,3,88,96,173
    150 data 9,255,41,2,240,3,32,96
    160 data 206,44,216,7,16,64,173,1
    170 data 253,141,212,7,16,56,238,240
    180 data 3,208,3,238,241,3,173,212
    190 data 7,41,8,240,24,173,212,7
    200 data 41,247,141,212,7,173,0,253
    210 data 141,213,7,173,211,7,201,63
    220 data 240,3,32,220,234,173,212,7
    230 data 41,16,240,10,44,206,7,16
    240 data 5,162,0,32,131,234,76,43
    250 data 206,120,169,0,141,240,3,141
    260 data 241,3,141,242,3,88,44,206
    270 data 7,48,251,169,85,141,205,7
    280 data 56,110,206,7,206,242,3,208
    290 data 237,173,2,253,73,12,141,2
    300 data 253,96

    irqtest2
    --------

    10 rem irq test2 to count interrupts
    20 cb = 819
    30 for i = 0 to 173
    40 read a
    50 poke cb+i,a
    60 next
    70 sys cb
    75 open 2,2,0,chr$(26)+chr$(7)
    80 sys 952
    85 close 2
    90 sys 845
    95 print peek(1009)*256 + peek(1008)
    100 data 120,32,85,252,186,202,189,0
    110 data 1,24,105,36,141,20,3,232
    120 data 189,0,1,105,0,141,21,3
    130 data 88,96,120,169,14,141,20,3
    140 data 169,206,141,21,3,88,96,173
    150 data 9,255,41,2,240,3,32,96
    160 data 206,44,216,7,16,76,173,1
    170 data 253,141,212,7,16,68,238,240
    180 data 3,208,3,238,241,3,173,212
    190 data 7,41,8,240,24,173,212,7
    200 data 41,247,141,212,7,173,0,253
    210 data 141,213,7,173,211,7,201,63
    220 data 240,3,32,220,234,173,212,7
    230 data 41,16,240,22,44,206,7,16
    240 data 17,172,2,253,152,73,12,141
    250 data 2,253,162,0,32,131,234,140
    260 data 2,253,76,43,206,120,169,0
    270 data 141,240,3,141,241,3,141,242
    280 data 3,88,44,206,7,48,251,169
    290 data 85,141,205,7,56,110,206,7
    300 data 206,242,3,208,237,173,2,253
    310 data 73,12,141,2,253,96
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From George@3:770/3 to All on Thu Nov 25 17:57:04 2021
    Just to bring this to a conclusion, I've written alternative IRQ servicing
    code that bypasses the "BEQ" error in rom, and a BASIC program that
    installs the new code into the tape buffer. It's 120 bytes of ML that does
    the ACIA processing and then jumps back into ROM for the rest of the IRQ routine. The BASIC program and the source code for the ML portion are
    shown below. The actual .PRG file can be downloaded from my Github CBM
    repo:

    https://github.com/gbhug5a/My_CBM_stuff

    Since I no longer have a +4, I have no way to test the new code.

    10 rem this code bypasses the "beq" bug
    12 rem in the +4's irq acia received-
    14 rem byte routine, and eliminates the
    16 rem xon/xoff software flow control
    18 rem code in both xmit and receive.
    20 rem the irq service routine vector
    22 rem ($0314) normally points to $ce0e.
    24 rem this code duplicates that code up
    26 rem to the acia, fixes that, then
    28 rem jumps back into rom. the code is
    30 rem poked into the cassette buffer at
    32 rem $0333, but can be placed anywhere
    34 rem visible in ram when kernel and
    36 rem basic roms are banked in. sys
    38 rem to the first byte to take over
    40 rem $0314. no need to re-assemble for
    42 rem a different location. the code
    44 rem detects where it has been placed.
    46 rem sys (first byte + 26) to restore
    48 rem the the $0314 vector to $ce0e.
    100 cb = 819
    110 for i = 0 to 119
    120 read a
    130 poke cb+i,a
    140 next
    150 sys cb
    160 v= (peek(789)*256) + peek(788)
    170 print "irq ram vector now";v
    180 data 120,32,85,252,186,202,189,0
    190 data 1,24,105,36,141,20,3,232
    200 data 189,0,1,105,0,141,21,3
    210 data 88,96,120,169,14,141,20,3
    220 data 169,206,141,21,3,88,96,173
    230 data 9,255,41,2,240,3,32,96
    240 data 206,44,216,7,16,63,173,1
    250 data 253,141,212,7,16,55,173,212
    260 data 7,41,8,240,24,173,212,7
    270 data 41,247,141,212,7,173,0,253
    280 data 141,213,7,173,211,7,201,63
    290 data 240,3,32,220,234,173,212,7
    300 data 41,16,240,17,173,16,253,41
    310 data 2,240,10,162,0,44,206,7
    320 data 16,3,32,131,234,76,43,206

    .6502

    ;code to bypass error in +4 acia irq receive-byte routine,
    ;and eliminate xon/xoff software flow control for
    ;transmit and receive.

    .org $0333 ;object code can be moved anywhere
    ; without reassembly
    ;sys entry to set irq vector to newirq
    ;sys restore (entry + 26) to restore
    ; default vector

    entry:

    sei
    jsr $fc55 ;just rts there
    tsx ;pc now in stack
    dex
    lda $0100,x
    clc
    adc #(newirq - entry - 3) ;point to newirq
    sta $0314
    inx
    lda $0100,x
    adc #0
    sta $0315 ;irq vector now newirq
    cli
    rts ;return from sys

    restore: ;restore = entry + 26

    sei ;restore vector to $ce0e
    lda #$0e
    sta $0314
    lda #$ce
    sta $0315
    cli
    rts

    newirq: ;$035a (858) if entry = $0333

    lda $ff09 ;not related to acia
    and #$02
    beq checkacia
    jsr $ce60

    checkacia:

    bit $07d8 ;acia present?
    bpl backtorom
    lda $fd01 ;read status reg
    sta $07d4 ;save status reg
    bpl backtorom ;bit 7 set if acia triggered irq

    receive:

    lda $07d4 ;new byte received?
    and #$08
    beq transmit
    lda $07d4
    and #$f7
    sta $07d4
    lda $fd00 ;new byte
    sta $07d5

    lda $07d3 ;number of bytes in queue
    cmp #$3f
    beq transmit ;discard byte if full

    jsr $eadc ;add new byte to input queue

    transmit:

    lda $07d4
    and #$10 ;transmit buffer empty?
    beq backtorom
    lda $fd10 ;pin k of user port = cts
    and #$02
    beq backtorom ;modem says don't send
    ldx #$00
    bit $07ce ;anything to send?
    bpl backtorom
    jsr $ea83 ;send it

    backtorom:

    jmp $ce2b ;acia done, continue rest of irq
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Brain@3:770/3 to George on Fri Nov 19 10:30:50 2021
    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)
  • From George@3:770/3 to All on Fri Nov 19 17:29:16 2021
    Jim Brain says...

    It might make sense to write up a bit more of the
    disassembly with your notes to create clarity.

    See below.

    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

    Yes, that's right. I think regular BBS traffic probably
    wouldn't have any nulls, so for that, this problem wouldn't
    make any difference. But I think file transfers might have
    lots of nulls, including any two-byte block numbers, or
    two-byte checksums. And of course any program with an ML
    section would have nulls all over the place (LDA #$00, STA
    $FD00, and such).

    Below is the relevant section of somebody's kernel source
    code, and on the right side the more raw version of the same
    thing showing the actual hex values.

    The error results from an attempt to work software flow
    control (Xon/Xoff) into the ACIA IRQ servicing routines. If
    flow control is enabled, the values normally used for Xon
    and Xoff ($11 and $13 respectively) will be stored at
    locations $FC and $FD. If flow control is disabled, those
    locations will contain nulls.

    If flow control is disabled, a received null byte must not
    be compared to $FC or $FD because a false match would be
    detected, and we would be halting and resuming transmission
    for no reason. So the code branches around all the Xon/Xoff
    stuff if a null is received. But it fails to save the null
    in aintmp ($07D5) before branching. So later, when the
    value in aintmp is retrieved and added to the input queue,
    another copy of the last non-null byte received is what will
    go into the queue.

    The solution is to reverse the two instructions, so the null
    is saved into aintmp, then the BEQ is performed. The Zero
    flag will not be modified by the STA instruction, so the
    branch will work correctly.

    ain
    lda astat ; acia status reg prev. saved LEA95 LDA $07D4
    and #$8 ; bit 3 set if char recd. AND #$08
    beq rxfull ; no char has been received BEQ LEAF0
    lda astat ; got one...reset stat bit LDA $07D4
    and #$f7 AND #$F7
    sta astat STA $07D4
    lda acia ; read byte LDA $FD00
    beq notacc ; if null, skip xon/xoff BEQ LEAC2

    ; it's a null, don't let thru for x-disable

    sta aintmp ; save char [unless it was a null] STA $07D5
    cmp xon ; is it a ~q CMP $FC
    bne trycs ; nope BNE LEAB7

    ; got a ~q

    lda #0 LDA #$00
    sta alstop ; tell local xmit to go STA $07D6
    beq rxfull ; !bra, what character? BEQ LEAF0

    trycs
    cmp xoff ; is it a ~s LEAB7 CMP $FD
    bne notacc ; nope BNE LEAC2

    ; got a ~s

    lda #$ff LDA #$FF
    sta alstop ; tell local xmit to stop STA $07D6
    bne rxfull ; !bra, i didn't see that... BNE LEAF0

    notacc
    lda inqcnt LEAC2 LDA $07D3
    cmp #inpqln-1 ; is queue full CMP #$3F
    beq rxfull ; yep BEQ LEAF0
    cmp #hiwatr ; high water mark CMP #$38
    bne nohw ; nope BNE LEADC

    ; hit high water mark, tell sender to stop

    lda xoff ; x-sw is off LDA $FD
    beq nohw BEQ LEADC
    sta soutq ; ~s STA $07CF
    lda #$ff LDA #$FF
    sta soutfg ; flag it present STA $07D0
    sta arstop ; flag remote stopped STA $07D7

    nohw
    ; not full, insert char
    ldx inqfpt ; do: inqfpt <- inqfpt+1 mod 64 LEADC LDX $07D1
    inx INX
    txa TXA
    and #$3f AND #$3F
    sta inqfpt STA $07D1
    tax TAX
    lda aintmp ; get char to insert LDA $07D5
    sta inpque,x ; insert it STA $03F7,x
    inc inqcnt ; another drop in the bucket INC $07D3 rxfull ; error exit
    rts ; all ok LEAF0 RTS
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Brain@3:770/3 to George on Sat Nov 27 00:34:10 2021
    On 11/25/2021 5:57 PM, George wrote:
    Just to bring this to a conclusion, I've written alternative IRQ servicing code that bypasses the "BEQ" error in rom, and a BASIC program that
    installs the new code into the tape buffer. It's 120 bytes of ML that does the ACIA processing and then jumps back into ROM for the rest of the IRQ routine. The BASIC program and the source code for the ML portion are
    shown below. The actual .PRG file can be downloaded from my Github CBM
    repo:

    https://github.com/gbhug5a/My_CBM_stuff

    Since I no longer have a +4, I have no way to test the new code.

    Do you have the VICE emulator? It supports the +4 and the built in
    6551, and can tie that 6551 ACIA to a real or virtual serial port. You
    could test it there if desired.

    Jim
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Johann Klasek - swap last two domai@3:770/3 to George on Sat Jun 22 20:47:33 2024
    George <gh424NO584SPAM@cox.net> wrote:
    If anyone has a Plus/4 and has nothing better to do, it would be helpful if you could run the programs listed below and report the results. The
    programs report the total number of ACIA interrupts which occur while transmitting 256 bytes of data continuously at 2400 baud. They should be
    run with nothing plugged into the User Port - no modem or anything.

    My suspicion is that the single-byte transmit buffer of the Plus/4 results
    in back-to-back double interrupts being generated for each byte
    transmitted, which can cause problems at high speed. If that's the case,
    the first program will report about 512 interrupts, and the second about
    256. But there may be no difference. Anyway, I just need to know.
    [..]

    Did anyone catched up to this? Has it been solved.

    Maybe I could give a try, if still needed.

    Best,
    JEEK

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