Nomally, MIDI UART loop reads from register #1 of bus-interface chip ( MPU-401 DATA IN), and writes this value to MIDI OUT. On erroneus event, it reads from register #5 of bus-interface chip (looks like trace port or something not clearly defined). Some bits of register #5 can be reservered and different in CT1747 and CT1746, and make some harmless MIDI command on CT1747, something like System Message Fx.
This is my assumptions, of couse.
Does the patched firmware also fix the 'type 2' hanging note bug? And can you explain how the presence of the CT1747 chip fixes the type 1 bug?
Yes it does
"And can you explain how the presence of the CT1747 chip fixes the type 1 bug?"
The guy asked about the second question that was not answered.
Cheers,
This is a MPU code, part for checking new incoming data (and sending new data byte to UART)
1X0cc9: 2 jnb ti,X0cb1 3 mov r0,#2 4 movx a,@r0 <- read status of MPU 5 setb p1.2 6 push acc 7 mov r0,#5 8 movx a,@r0 9 setb acc.6 10 movx @r0,a 11 pop acc 12 jnb acc.6, mpu_loop <- if no new data byte in MPU data register, skip sending 13 mov r0,#1 <- read new byte from MPU data register 14 movx a,@r0 15 clr ti 16 mov sbuf,a <- output byte to MIDI out 17 sjmp mpu_loop
Problem was in inerrupt handler ExtInt1, triggered at each end of block (of SB samples). This hadler was badly coded, so it returns with R0 set to 0x05, always.
So, if interrupt is triggered between this two commands:
mov r0,#2
movx a,@r0 <- read status of MPU
We got reading MPU status from x-register 0x05 (instead of legal read from x-reg 0x02).
if readed byte has bit 6 set, fw thinks that it has new data byte in MPU data register, and send it to UART. Effectively, repeating last send byte.
So, if interrupt is triggered between this two commands:
mov r0,#1 <- read new byte from MPU data register
movx a,@r0
fw reads x-reg 0x05 (instead of reading x-reg 0x01), and sends this value to UART. Effectively, sending some garbage, but if value is 0xF0-0xFF, this can be not harmful in some cases.
This is hardware dependant, and depends on value readed from x-reg 0x05.
I guess my question is (if I am not totally confused and mistaken) :
which 'x-reg' register corresponds to the content written to IO Port 0x330 and which one to 0x331? isn't for the "Fake ACK" sufficient just to always return 0xFE to IO Port 0x330, no matter what was requested to IO Port 0x331? of course, full MPU-401 intelligent mode would be significantly harder, but according to:
I guess my question is (if I am not totally confused and mistaken) :
which 'x-reg' register corresponds to the content written to IO Port 0x330 and which one to 0x331? isn't for the "Fake ACK" sufficient just to always return 0xFE to IO Port 0x330, no matter what was requested to IO Port 0x331? of course, full MPU-401 intelligent mode would be significantly harder, but according to:
Byte written to IO port 0x331 - x-reg is unknown, and maybe not exists. Testing is needed ))
thank you, if you come up with a test procedure - let us know - I am sure here are more people, than just me, always ready to help and test with whatever they can.
Byte written to IO port 0x331 - x-reg is unknown, and maybe not exists. Testing is needed ))
thank you, if you come up with a test procedure - let us know - I am sure here are more people, than just me, always ready to help and test with whatever they can.
You can try this, output is xregs.bin file
If any 0xAE byte is found in xregs.bin - its a good sign
In any way, just implementing "Fake ACK", if that is possible, will be very huge improvement.
To implement this minimally, the SB16 needs to both acknowledge all MPU commands (even if unsupported), and accept/pass MIDI data without prior reception of the 0x3F, "UART mode" MPU command. Concerning the latter point, the current behavior is that a single, untransmitted data byte can be written to the MPU data port outside of UART mode (corresponding to the 1-byte output buffer), after which the MPU becomes terminally non-ready.
Ideally, a routine for the 0xB9, "Clear Play Map" MPU command could also be added, with a behavior of sending All Notes Off messages on all 16 MIDI channels upon receipt.
Last edited by Cloudschatze on 2023-10-13, 17:20. Edited 1 time in total.
No sign of MPU command port (IO 331) register present in x-regs.
hmm, now the question is what is the best we can do with just ability to read IO port 0x330 - can we write 0x330 as well from the DSP or it's only read?
Last edited by mattw on 2023-10-13, 16:47. Edited 9 times in total.
So it looks like Bus interface chip does all job interpreting MPU commands, and DSP fw got only one line (p1.6) from BIC, which is MPU UART mode is ON or OFF.
hmm, now the question is what is the best we can do with just ability to read IO port 0x330 - can we write 0x330 as well from the DSP or it's only read?
IO 330 is bidirectional, of course.
My notes:
1x-registers: 20 - read: command/data port (2xC on PC side) 31 - read: MPU-401 data register 42 - read: MPU-401 state register 5 - write: MPU-401 data register
on my AWE32 and see how it looks like - maybe that will help us imagine the things better... be back in 10-15 minutes with the results.
You won't get any response to, or acknowledgement of, the version/revision request. The SB16 MPU only implements two MPU-401 commands - Reset (0xFF) and UART Mode (0x3F).
You won't get any response to, or acknowledgement of, the version/revision request.
the things are now getting real unexpected turn, because the above is true, but for my CT4170 DSP V4.16 card (which as Build-in MCU in the main chip cannot be modified anyway) and here is how the test looks:
1C:\>debug.exe 2-o 331 ac 3-i 330 4FF--> BAD 5-i 330 6FF--> BAD 7-o 331 ad 8-i 330 9FF--> BAD 10-i 330 11FF--> BAD 12-q
but the surprise is my AWE32 DSP V4.13 card, because what I get is:
So, now the big question is which one of the following options we have:
A. We have huge news and at least AWE32 DSP V4.13 card (CT3990) is Unknown until now "Fake ACK" card - that I see as very unlikely, because those are popular cards and I am almost sure DosDaysUK which documented the list of their "Fake ACK" cards:
but still maybe missed to test it, I don't know - the fact is that at least 2 MPU-401 command 0xAC and 0xAD my CT3990 does "Fake ACK" for them
B. even we found 2 MPU-401 command (0xAC and 0xAD) that my CT3990 does "Fake ACK" for them, maybe there are many other MPU-401 command, for which CT3990 does NOT do "Fake ACK" - we just haven't tested them yet - I believe that is most likely the case.
C. if it's not option A) and it's not option B), then the known "Fake ACK" cards have to do something more than just "Fake ACK" and we don't know what that more is - that's the worst case - as I don't know how to proceed if that is the case.
mattwwrote on 2023-10-13, 17:19:the things are now getting real unexpected turn, because the above is true, but for my CT4170 DSP V4.16 card (which as Build-in […] Show full quote
the things are now getting real unexpected turn, because the above is true, but for my CT4170 DSP V4.16 card (which as Build-in MCU in the main chip cannot be modified anyway) and here is how the test looks:
1C:\>debug.exe 2-o 331 ac 3-i 330 4FF--> BAD 5-i 330 6FF--> BAD 7-o 331 ad 8-i 330 9FF--> BAD 10-i 330 11FF--> BAD 12-q
Looks like the MPU is either uninitialized, or just needs to be reset first (0xFF), after which the output should match what you saw for the AWE32.
but the surprise is my AWE32 DSP V4.13 card, because what I get is: […] Show full quote
but the surprise is my AWE32 DSP V4.13 card, because what I get is:
The "FE" byte that you're reading back in this case isn't an acknowledgement of the prior commands. It's residual. The state of the DSR bit (0x80) of the Command port status byte indicates acknowledgement when low, in conjunction with an "0xFE" acknowledgement byte at the Data port.
But yes, even when software is just checking for command acknowledgement via the Data port 0xFE byte, and ignores the status of the DSR bit entirely, the SB16's MPU still won't accept/transmit MIDI data outside of UART mode, which is the other piece necessary to match the behavior of the Ensoniq and Audiotrix Pro cards.
SB16's MPU still won't accept/transmit MIDI data outside of UART mode, which is the other piece necessary to match the behavior of the Ensoniq and Audiotrix Pro cards.
I see, that is good explanation. So, nothing comes out of the DB15 connector as electrical signals on SB16, but it goes out on the known "Fake ACK" cards.
Looks like the MPU is either uninitialized, or just needs to be reset first (0xFF), after which the output should match what you saw for the AWE32.
both cards were tested the same way, power-on, 'ctcm' to init them then 'debug' to read/write the IO ports, but i will re-test as yourt suggestion with sending first "FF" to reset. if that changes anything - I will report back.
based on the above findings do you think you can as 1st step mod V4.13 to not leave any "residual" ACK, i.e. after 0xFE is in the IOPort 0x330 Xreg and the register is read, set its value back to 0xFF (or to 0x00 - I am not sure which one is the correct to remove the ACK) or something like that - that way prevent we have case of "residual" ACK. as you can see at least V4.16 initializes that reg to 0xFF and sets it for the first time to 0xFE after the first ACK. [EDIT] not sure if that makes any sense, but the point is how to make it return True and False ACK and not "residual" ACK left from the previous successful request.
Also, as far as Electrical Activity on the DB15 connector - really happens or not - I found way how to test that - I have MIDI-Switch or MIDI-Splitter (or something like that, not sure how really the device is called) and it has LEDs for Activity on its MIDI-IN ports, i.e. connecting SB16 DB15 to that device shows if the card electrically outputs the SysEX or not. I am mentioning this - just in case after "residual" ACK is eliminated, you have idea how to make the DSP output the SysEX electrically to the DB15 connector. I guess you know, because that is Essentially - what we did with the Loopback connection during the ROM dump attack.