Fix hang-up when executing RQ1 SysEx on SC-55mk1

[shingo45endo]

This pull request fixes a hang-up issue when executing RQ1 SysEx on the SC-55mk1.

When running Nuked-SC55 in mk1 mode, it hangs when sending such kind of RQ1 SysEx as shown below.

f0 41 10 42 11 40 01 00 00 00 10 2f f7

The hang-up occurs at the following code in the SC-55 firmware (v1.21):

L041877:
        MOV:G.B @H'FFDA:16,R0                   ; 041877  15FFDA80     ; 00ffda = SCI SCR
        OR.B    #H'AC:8,R0                      ; 04187B  04AC40       ;
        MOV:G.B R0,@H'FFDA:16                   ; 04187E  15FFDA90     ; 00ffda = SCI SCR
L041882:
        MOV:G.W @H'ABFA:16,R0                   ; 041882  1DABFA80     ; 00abfa = Index of "head" of the ring buffer for RQ1 SysEx
        CMP:G.W @H'ABFC:16,R0                   ; 041886  1DABFC70     ; 00abfc = Index of "tail" of the ring buffer for RQ1 SysEx
        BNE     H'41882                         ; 04188A  26F6         ;
L04188C:
        LDC.B   @R7+,EP                         ; 04188C  C78C         ;
        BRA     H'40EA3                         ; 04188E  30F612       ;

The buffer for RQ1 is managed as a ring buffer, with “head” stored in H'ABFA and “tail” in H'ABFC. It loops infinitely until the head and the tail are equal (= until the ring buffer is empty), which causes a hang-up. The head does not change in this loop, but the SC-55 firmware expects the head to change in the transmit-end interrupt (TXI) handler. However, Nuked-SC55 does not issue a TXI interrupt. As a result, a hang-up happens.

This pull request modifies the MCU emulator to issue a TXI interrupt if the SSR.TDRE bit is 1 when a 1 is written to the SCR.TIE bit. Such behavior is not described anywhere in the H8/532 hardware manual, but the SC-55 firmware seems to be implemented on the assumption of such behavior. According to the hardware manual, it is understood that clearing SSR.TDRE triggers a transmission of the TDR data, and then a TXI interrupt is issued when the transmission is completed. However, it seems that the only two processes in the SC-55 firmware that explicitly clear SSR.TDRE are the process of sending the next data in the TXI interrupt handler and the transmission of active sensing. And the only SCI-related processing that the SC-55 firmware does in the RQ1 process seems to be to enable SCR.TIE before the infinite loop.

After applying this, it will no longer hang up when sending RQ1 SysEx. (Confirmed on v1.00, v1.10, v1.20, v1.21, and v2.00) Also, by enabling printf in MCU_UpdateUART_TX, we can confirm that the RQ1 results are correctly sent as shown below.

Base path is: nuked-sc55
Audio device: Default device
Audio Requested: F=S16LSB, C=2, R=64000, B=128
Audio Actual: F=S16LSB, C=2, R=64000, B=128
Opened midi port: loopMIDI Port
Unknown write f103 1
Unknown write f108 0
Unknown write f109 0
Unknown write f10a 0
Unknown write f10b 0
Unknown write f10c 0
Unknown write f10d 1
Unknown write f10e 0
Unknown write f10f 0
Unknown write f110 0
Unknown write f111 0
Unknown write f112 0
Unknown write f113 0
Unknown write f103 1
tx:fe
tx:fe
...
tx:fe
tx:fe
tx:f0
tx:41
tx:10
tx:42
tx:12
tx:40
tx:1
tx:0
tx:2d
tx:20
tx:53
tx:4f
tx:55
tx:4e
tx:44
tx:20
tx:43
tx:61
tx:6e
tx:76
tx:61
tx:73
tx:20
tx:2d
tx:20
tx:f7
tx:fe
tx:fe
...

In addition to this, there are a few other SCI implementation issues that I was concerned about, and fixed them.

• Only the clear operation is valid for the SSR register, but the register is entirely overwritten at the end of the function because it does not return at the end of the DEV_SSR case.
• According to the hardware manual, the initial value of the SSR register is H'87.