or maybe even simpler - "residual" ACK doesn't matter and just patch the DSP code, no matter if there is Real ACK or not - always output electrically to the DB15 connector the SysEX.

mattw wrote on 2023-10-13, 18:02:

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

What problem do you want to solve with this ?
I cannot 'SET' it to 0xFF, i can _output_ 0xFF to MPU data port, but it can spoil MPU exchange with applications. 0xFF is unexpected byte ))

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

What problem do you want to solve with this ?

it seems we both were writing at the same time.

essentially, what is needed is Commands written to IOPort 0x331 that are not really acknowledged (they look like acknowledged based on the value in IOPort 0x330, but that is just left-over from the previously properly ACK command, i.e. "residual ACK") be forced to be electrically send out via the DB15 connector. currently, it seems those commands are not sent out electrically via the DB15 connector. That's the main problem.

Is it solvable via DSP patch or no?

the less important, actually unimportant is - if DSP can be made to properly shows the command if they are not ACK and not like at the moment keep the status of the previous successful command when return IOPort 0x330.

That all of the above to be considered only in case I did not misunderstand the tests above I ran on DSP V4.16 and DSP V4.13 cards. Especially, DSP V4.16 without doing FF reset 1st and with doing it - showing major difference.

While 3x1h port address seems not operational for writes there are other port addresses that are available and moreover during UART mode are almost useless. So if you can figure a simple way to divert 3x1h MIDI commands to one of them either in software on PC side or in hardware on SB (like some PNP redirection) or simple address lines mod, then you are good to go. If you find a pair of consecutive addresses even better. But there is already SoftMPU for real mode games and none of the protected mode games uses intelligent MIDI, so there is not much point in your effort to provide that in the DSP.

I am away over my level of knowledge and understanding, but thinking more about it - maybe the "Fake ACK" cards, actually not just ACK all commands (written to IOPort 0x331) and send them all out electrically on the connector, but only send out the commands that are SysEX requests, aren't those have some format like:

1FO ... F7

because Google tells me:

SysEx messages start with (hexadecimal) F0 and end with F7

So, I guess, if that is the case, then we need DSP patch that sends out the Unacknowledged SysEX requests. However, if that is the case, then DSP code should contains some code where it validates the SysEx messages - otherwise there is no way to determine which are ACK and should be as well electrically transmitted on DB15 connected. I really don't know - all those are just my thought said out loud - hence maybe they are all wrong.

mattw wrote on 2023-10-13, 18:25:

essentially, what is needed is Commands written to IOPort 0x331 that are not really acknowledged (they look like acknowledged based on the value in IOPort 0x330, but that is just left-over from the previously properly ACK command, i.e. "residual ACK") be forced to be electrically send out via the DB15 connector. currently, it seems those commands are not sent out electrically via the DB15 connector. That's the main problem.

Is it solvable via DSP patch or no?

No way. DSP has no means to READ command (port 0x331), and cannot send it to MIDI OUT.
DSP can only be bridge for midi data.

Maelgrum wrote on 2023-10-13, 18:48:

DSP can only be brige for midi data.

it seems we were writing again at the same time - please, see my post above yours. Exactly, but SysEX messages are considered MIDI-Data and not commands, correct or not?

Maelgrum wrote on 2023-10-13, 18:48:

and cannot send it to MIDI OUT.

what you were sending out and how you were sending it out via the Loopback during the ROM dump hack?

mattw wrote on 2023-10-13, 18:51:

what you were sending out and how you were sending it out via the Loopback during the ROM dump hack?

Midi data, of course, port 0x330

mattw wrote on 2023-10-13, 18:51:

Exactly, but SysEX messages are considered MIDI-Data and not commands, correct or not?

Not sure about this. Need to check it with HardMPU source code.
[EDIT] looks like it is in midi-data stream

Maelgrum wrote on 2023-10-13, 19:00:

Not sure about this. Need to check it with HardMPU source code ))

at least I got totally lost now - I mean what those known "Fake ACK" cards do more then? I mean as far as I understand from what @Cloudschatze wrote and based on my test results, the "Fake ACK" cards transmits electrically out what is send , while SB16 blocks it when it's not acknowledged. Obviously, I am misunderstanding and/or missing something. I don't know about HardMPU, but SoftMPU has several function that seems to me depending on the hardware are sending out the data:

https://github.com/bjt42/softmpu/blob/master/SRC/MIDI.C

even via SerialPort called "PlayMsg_Serial()". However, the point is the known "Fake ACK" cards, they don't send the real message (they don't have real MPU-401 intelligent processing), then what they send? I guess my main confusion now is what the known "Fake ACK" cards really do, which is the minimum necessary.

mattw wrote on 2023-10-13, 19:07:

at least I got totally lost now - I mean what those known "Fake ACK" cards do more then? I mean as far as I understand from what @Cloudschatze wrote and based on my test results, the "Fake ACK" cards transmits electrically out what is send , while SB16 blocks it when it's not acknowledged. Obviously, I am misunderstanding and/or missing something.

This may help clarify:
Re: If you are forced to stick with just one sound card

I'm with georgel though - enhancing the MPU functionality of the SB16 would be excellent, but where it's sounding like that's not readily possible, alternatives yet abound. Even in the case of driver modification for non-386-systems incapable of leveraging SoftMPU, it's a two-byte change to modify Sierra's "intelligent mode" MPU driver to initialize and function with the UART-only SB16 MPU.

mattw wrote on 2023-10-13, 19:07:

at least I got totally lost now - I mean what those known "Fake ACK" cards do more then? I mean as far as I understand from what […]
Show full quote

Maelgrum wrote on 2023-10-13, 19:00:

Not sure about this. Need to check it with HardMPU source code ))

at least I got totally lost now - I mean what those known "Fake ACK" cards do more then? I mean as far as I understand from what @Cloudschatze wrote and based on my test results, the "Fake ACK" cards transmits electrically out what is send , while SB16 blocks it when it's not acknowledged. Obviously, I am misunderstanding and/or missing something. I don't know about HardMPU, but SoftMPU has several function that seems to me depending on the hardware are sending out the data:

https://github.com/bjt42/softmpu/blob/master/SRC/MIDI.C

even via SerialPort called "PlayMsg_Serial()". However, the point is the known "Fake ACK" cards, they don't send the real message (they don't have real MPU-401 intelligent processing), then what they send? I guess my main confusion now is what the known "Fake ACK" cards really do, which is the minimum necessary.

Fake ACK - is then card answers ACK (0xFE) to all MPU commands (if i understand it right)
This cannot be done in SB, as all commands are processed by BIC (Bus interface chip), and it recognizes only RESET and UART MODE commands (?).
DSP _can_ send ACK, but it does not know what this sending needs to be done ))

Cloudschatze wrote on 2023-10-13, 19:20:

This may help clarify:
Re: If you are forced to stick with just one sound card

thank you very much, it helps, but it brings me back to the very beginning of the discussion: I see "0xFE" Acknowledge on the tests I did on my AWE32 DSP V4.13 card, even further tests with DSP v4.16, clearly revealed that "0xFE" is residual, left-over, from the previous successful 0xFF Reset command and not from the current MPU-401 0xAC command I sent. That you predicted and I fully agree with it as I confirmed it with that aforementioned DSP v4.16 test.

However, then how the software distinguish in such case from "residual" Acknowledge and real Acknowledge on SB16 - I mean even if SB16 doesn't send out electrically anything on its DB15 connector and thus there is no sound, then the software shouldn't be still see those "residual" Acknowledge as real and continue to work?

Also, even SB16 keeps the "residual" Acknowledge, after I send MPU-401 0xAC command, which is supposedly in reality Un-Acknowledged then what happens - I mean what causes SB16 to stop sending electrically anything (further) on its DB15 connector.

I am not sure how clear I am explaining what I don't get...

Cloudschatze wrote on 2023-10-13, 19:20:

it's a two-byte change to modify Sierra's "intelligent mode" MPU driver to initialize and function with the UART-only SB16 MPU.

please, refer us to this 2 byte patch, maybe reading the x86 assembler can make it more clear to me (us).

Maelgrum wrote on 2023-10-13, 19:29:

Fake ACK - is then card answers ACK (0xFE) to all MPU commands (if i understand it right)

that was my initial understanding, but as I asked above - it SB16 keeps residual ACK from previously successful command, then how the software fails - I mean it read 0xFE all the time as my tests showed.

mattw wrote on 2023-10-13, 19:41:

thank you very much, it helps, but it brings me back to the very beginning of the discussion: I see "0xFE" Acknowledge on the te […]
Show full quote

Cloudschatze wrote on 2023-10-13, 19:20:

This may help clarify:
Re: If you are forced to stick with just one sound card

thank you very much, it helps, but it brings me back to the very beginning of the discussion: I see "0xFE" Acknowledge on the tests I did on my AWE32 DSP V4.13 card, even further tests with DSP v4.16, clearly revealed that "0xFE" is residual, left-over, from the previous successful 0xFF Reset command and not from the current MPU-401 0xAC command I sent. That you predicted and I fully agree with it as I confirmed it with that aforementioned DSP v4.16 test.

However, then how the software distinguish in such case from "residual" Acknowledge and real Acknowledge on SB16 - I mean even if SB16 doesn't send out electrically anything on its DB15 connector and thus there is no sound, then the software shouldn't be still see those "residual" Acknowledge as real and continue to work?

Also, even SB16 keeps the "residual" Acknowledge, after I send MPU-401 0xAC command, which is supposedly in reality Un-Acknowledged then what happens - I mean what causes SB16 to stop sending electrically anything (further) on its DB15 connector.

I am not sure how clear I am explaining what I don't get...

Maelgrum wrote on 2023-10-13, 19:29:

Fake ACK - is then card answers ACK (0xFE) to all MPU commands (if i understand it right)

that was my initial understanding, but as I asked above - it SB16 keeps residual ACK from previously successful command, then how the software fails - I mean it read 0xFE all the time as my tests showed.

RTFM! MIDI section of https://pdos.csail.mit.edu/6.828/2018/reading … oundBlaster.pdf

mattw wrote on 2023-10-13, 19:41:

However, then how the software distinguish in such case from "residual" Acknowledge and real Acknowledge on SB16...

By checking the DSR status bit from the Command port, which is the predecessor behavior to checking for the acknowledgement byte at the Data port. I didn't make this very clear in the example sequence that I'd linked to.

I mean what causes SB16 to stop sending electrically anything (further) on its DB15 connector.

Beats me. 😀 That is, it's a defined behavior on Creative's part, but it sounds like it has something to do with programming/behavior found in the bus-interface chip, rather than anything in the DSP code, based on what Maelgrum has stated.

Cloudschatze wrote on 2023-10-13, 19:52:

By checking the DSR status bit from the Command port

thanks, I believe I maybe finally got it (as low IQ as I am): I am judging for ACK by the value of IOPort 0x330 (which is let's call it the 'new way'), but there is 'legacy way' with checking the DSR status bit (bit 7) in the value of IOPort 0x331 (what you calling are "Command port"). So, since IOPort 0x331 cannot be manipulated from the DSP code - it cannot be fixed from the side of the DSP.

To @mattw, you miss one thing - MPU dataflow is controlled by 2 bits in MPU status register (0x331)
So you cannot read MPU data port, until Status port shows that data is present in data register.

Port 0x331 is command/status.
Then you write to it - MPU commands written.
Then you read from it - it is status of dataports.

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

To @mattw, you miss one thing - MPU dataflow is controlled by 2 bits in MPU status register (0x331)
So you cannot read MPU data port, until Status port shows that data is present in data register.

yep, it seems that way, using 'Debug.exe' for the test - i shouldn't do '-o 331 ac' and then immediately '-i 330', but after '-o 331 ac' do several times '-i 331' until those bits are in correct value and then do '-i 330'. anyway, I hope, at least those of us that didn't know anything about that subject - learned something new.

mattw wrote on 2023-10-13, 20:12:

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

To @mattw, you miss one thing - MPU dataflow is controlled by 2 bits in MPU status register (0x331)
So you cannot read MPU data port, until Status port shows that data is present in data register.

yep, it seems that way, using 'Debug.exe' for the test - i shouldn't do '-o 331 ac' and then immediately '-i 330', but after '-o 331 ac' do several times '-i 331' until those bits are in correct value and then do '-i 330'.

Exactly))

Well, obviously you technically can read the MPU data port (0x330) even if the DSR bit in 0x331 is not set cleared. That's what mattw did all the time. But it makes no sense to read the data port when the DSR bit not set. The key point is that the DSR bit tells you whether the data you obtain at port 330 is "fresh" or "residual". There is no "old" and "new" way to check for an ACK, but only one correct way, and this way involves looking at both ports: First you have to wait for something to "appear" in port 0x330. You don't check for that by looking at port 0x330, but instead by looking at the DSR bit in port 0x331. Then you can check what appeared at port 0x330 by reading this port. As soon as you do that, the data is considered "consumed", and the DSR bit switches back to 0.

The DSR protocol is very likely fully implemented inside the BIU: So whenever you write a byte to X-Bus address 2, the DSR bit in 331 is set cleared. Whenever the host reads port 330, the DSR bit is clear set again. This means writing 0xFE to X-Bus address 2 does everything that is required to send an ACK to the host.

(this post has been posted anyway, after the concurrent posts appeared, due to the last paragraph which seems still relevant)

EDIT: DSR cleared means "data present", not DSR set. This bit is active low.