maxtherabbit wrote on 2023-10-13, 13:55:

Oetker wrote on 2023-10-13, 08:04:

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,

Oetker wrote on 2023-10-13, 08:04:

And can you explain how the presence of the CT1747 chip fixes the type 1 bug?

pentiumspeed wrote on 2023-10-13, 14:54:

The guy asked about the second question that was not answered.

Maelgrum made assumptions about it some posts ago.

Maelgrum wrote on 2023-09-22, 13:59:

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.

pentiumspeed wrote on 2023-10-13, 14:54:

"And can you explain how the presence of the CT1747 chip fixes the type 1 bug?" […]
Show full quote

maxtherabbit wrote on 2023-10-13, 13:55:

Oetker wrote on 2023-10-13, 08:04:

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.

Maelgrum wrote on 2023-10-13, 15:39:

read from x-reg 0x02

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:

http://www.dosdays.co.uk/topics/mt32_game_compat.php

about 98% of all MT-32 titles

work with just the "Fake ACK".

mattw wrote on 2023-10-13, 15:49:

I guess my question is (if I am not totally confused and mistaken) : […]
Show full quote

Maelgrum wrote on 2023-10-13, 15:39:

read from x-reg 0x02

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:

http://www.dosdays.co.uk/topics/mt32_game_compat.php

about 98% of all MT-32 titles

work with just the "Fake ACK".

Byte written to IO port 0x330 - is in x-reg 0x01
Byte written to IO port 0x331 - x-reg is unknown, and maybe not exists. Testing is needed ))

Maelgrum wrote on 2023-10-13, 15:54:

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.

mattw wrote on 2023-10-13, 16:01:

Maelgrum wrote on 2023-10-13, 15:54:

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

Maelgrum wrote on 2023-10-13, 16:08:

If any 0xAE byte is found in xregs.bin - its a good sign

see the attached dump - 0xAE is there - I hope it's also on the right place and not some other 0xAE....

mattw wrote on 2023-10-13, 09:29:

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.

mattw wrote on 2023-10-13, 16:26:

Maelgrum wrote on 2023-10-13, 16:08:

If any 0xAE byte is found in xregs.bin - its a good sign

see the attached dump - 0xAE is there - I hope it's also on the right place and not some other 0xAE....

No luck - looks like x-regs are in range 0x00-0x1F, and 0x80-0x83 (ASP/CSP).
No sign of MPU command port (IO 331) register present in x-regs.

Maelgrum wrote on 2023-10-13, 16:32:

No luck - looks like x-regs are in range 0x00-0x1F , and 0x80-0x83 (ASP/CSP).

I made X-Regs dump on CT4170 with DSP V4.16 and then your statement becomes real obvious, because:

1         00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
2--------------------------------------------------------
300000000 00 00 BF FF 68 FB F0 F0 02 F8 00 00 00 00 FC 3E 
400000010 02 80 00 00 00 00 FC FC FE FF FF 0F FF FF FF 00 
500000020 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
6................
7000000F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

obviously after address 0x1F it's all 'FF's and of course no ASP/CSP on CT4170.

Maelgrum wrote on 2023-10-13, 16:32:

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?

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.

mattw wrote on 2023-10-13, 16:42:

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

Maelgrum wrote on 2023-10-13, 16:45:

IO 330 is bidirectional, of course.

OK, let me test this same thing:

Re: Roland LAPC-N / I question

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.

mattw wrote on 2023-10-13, 16:52:

OK, let me test this same thing: […]
Show full quote

Maelgrum wrote on 2023-10-13, 16:45:

IO 330 is bidirectional, of course.

OK, let me test this same thing:

Re: Roland LAPC-N / I question

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

Cloudschatze wrote on 2023-10-13, 17:03:

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:

1C:\>debug.exe
2-o 331 ac
3-i 330
4FE--> GOOD, ACK
5-i 330
6FE--> GOOD, ACK
7-o 331 ad
8-i 330
9FE--> GOOD, ACK
10-i 330
11FE--> GOOD, ACK
12-q

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:

http://www.dosdays.co.uk/topics/mt32_game_compat.php

most likely own such "CT3990" card:

https://www.dosdays.co.uk/topics/sb_awe32_64.php

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.

So, what is it - A, B or C?

mattw wrote 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:

Copy code to clipboard

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:

Copy code to clipboard

1C:\>debug.exe
2-o 331 ac
3-i 330
4FE--> GOOD, ACK
5-i 330
6FE--> GOOD, ACK
7-o 331 ad
8-i 330
9FE--> GOOD, ACK
10-i 330
11FE--> GOOD, ACK
12-q

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.

Cloudschatze wrote on 2023-10-13, 17:36:

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.

Cloudschatze wrote on 2023-10-13, 17:36:

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.

Cloudschatze wrote on 2023-10-13, 17:36:

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.

The "FE" byte that you're reading back in this case isn't an acknowledgement of the prior commands. It's residual.

you're correct on CT4170 DSP V4.16, it's 100% residual ACK, because only after doing reset, i.e. sending FF, it starts to return 0xFE for AC and AD:

1C:\>debug.exe
2-o 331 ff
3-i 330
4FE
5-o 331 ac
6-i 330
7FE
8-i 330
9FE
10-o 331 ad
11-i 330
12FE
13-i 330
14FE
15-q

So, that shows one obvious difference between DSP V4.13 and DSP V4.16 .

@Maelgrum :

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.