mattw wrote on 2023-10-13, 20:12:anyway, I hope, at least those of us that didn't know anything about that subject - learned something new.
It is not new -- it is in the widespread vintage SB manual I posted link to in my previous message. But there is a saying in one foreign (to me) language -- Chukcha is not reader, Chukcha is writer.
mattw wrote on 2023-10-13, 20:12: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'.
If you are manually typing into debug, it is very unlikely that you need to repeat "i 331" multiple times until the ACK appears, because manual typing is so slow that when you finished typing 'i 331' the ACK has either already been sent (and you see the DSR bit setcleared on the first attempt), or there will be no ACK at all. You correctly describe how software should interface with the MPU401 interface card, though.
EDIT: DSR cleared means "data present", not DSR set. This bit is active low.
@mkarcher thank you for the excellent explanation and one more time big thank you to @Cloudschatze for all the invaluable (at least to me) information provided on the MPU-401 Intelligent mode command and all.
georgel wrote on 2023-10-13, 20:20:saying in one foreign (to me) language --
Chukcha is not reader, Chukcha is writer.
I am low IQ - just deal with it. BTW, I know the expression - I studied Russian for 4 years, but being as low IQ as I am - I didn't learn much, because Russian is extremely difficult language.
Thinking about hardware MPU...
We have HardMPU, great project, but it can't do midi output stream throttling, to solve early MT-32 buffer overflow issue (as far as I know, please correct me if I am wrong).
So some project with HardMpu code and modifications on hard and soft side to do such throttling can be the ultimate MPU solution.
Maelgrum wrote on 2023-10-13, 20:43:can be the ultimate MPU solution.
any thoughts on this, i.e. stand-alone 6801-emulator or maybe even board with 6801 controller that can execute the original Roland MPU-401 ROM:
again, I know noting on the subject and thus my ideas could be very wrong and/or very stupid.
[EDIT] also, the original ISA card was just port/address decoder based on 74-series logic and it was fully replicated:
https://www.lo-tech.co.uk/wiki/Lo-tech_MIF-IPC-B
of course, it connects via a cable to the external unit having the 6801-microcontroller inside.
@Maelgrum
check this out: Roland MT-32 Buffer overflow Hardware Fix
AFAIK only the 1st generation of MT-32s are affected by this speed issue so by patching the unit you effectively make it "speed compatible" with whatever software/hardware/dumb/smart MPU solution exists out there. At some point this will get released and one wound not have to slow-down the system to avoid such issues.
@mattw
this original Roland interface card was meant to be a way for roland to make their lives easier: the metal MPU box with the chipset would be a constant in all systems and only the interface cards would change: there was one for ISA, I think one for MCA, one for NEC systems and even one for the Commodore64.
In fact the box and the interface came in 2 different boxes - at least initially , I have a boxed complete one and it's just the metal box and the manual.
keropi wrote on 2023-10-13, 21:09:@Maelgrum
check this out: Roland MT-32 Buffer overflow Hardware Fix
AFAIK only the 1st generation of MT-32s are affected by this speed issue so by patching the unit you effectively make it "speed compatible" with whatever software/hardware/dumb/smart MPU solution exists out there. At some point this will get released and one wound not have to slow-down the system to avoid such issues.
This looks like some intermediate buffering solution, so it receives incoming midi data, stores it in large ram buffer, and transmits data to mt-32, inserting delays between sysex.
It will work, but music can be not in sync with game start (as game thinks that all sysex download process is complete, and we can start gaming process and play music. But download process is not complete 😁)
I actually have no idea of the specifics but I don't think that the atmega328 used has a large ram buffer - Perhaps it is large enough to avoid triggering the overflow , I can't see how the delay could be more than second or so?
I guess we'll find out once more details are announced. Btw I kinda think at least softmpu has an option to avoid overflows like this. I remember reading about it some time ago but I could be mistaken...
keropi wrote on 2023-10-13, 21:48:I actually have no idea of the specifics but I don't think that the atmega328 used has a large ram buffer - Perhaps it is large enough to avoid triggering the overflow , I can't see how the delay could be more than second or so?
I guess we'll find out once more details are announced. Btw I kinda think at least softmpu has an option to avoid overflows like this. I remember reading about it some time ago but I could be mistaken...
Mt-32 has 64kb of ram, so full download will be ~21 sec.
Inserted delays... yes, I agree - must be second or less.
But! If music is in sync with sound effects (via SB), or with visual effects, with this delay they will be out of sync.
Source code update.
small optimizations
with MACRO usage - much easier to read and understand, looks nicer
Just managed to finish some experiments on my CT2950. Replaced the original DSP chip with a PLCC44 socket and put my own MCU in it, using the just-released DSP code.
It did not work at first -- probably some part of the socket was not soldered properly, so I redid it and eventually got it working with the original DSP.
I used two different STC 8051 MCUs for experiment, and it seems "cheating" by using a faster 8051 MCU would not work -- the DSP won't get detected.
The non-working MCU in question is STC12C5A60S2. It's a so-called 1T (single cycle) MCU with timer retains 12T by default for compatibility (so timer initialization code does not have to be changed), but overall execution speed is about 600% of a standard 8051 from my past experience with this one.
I ended up using a STC90C58RD+ which is pretty much AT89C52 with more flash and internal memory. So far it's working correctly and I think I'll run some more software when I have time to be sure everything is okay.
For this working MCU model I disabled the "internal XRAM" just in case, which I suppose is about the extra RAM the MCU has. I'm not sure if leaving "internal XRAM" enabled would get in the way of MOVX instructions which in the DSP's context could be the X-Bus interface, but I'm not going to test it for the time being until there are some further improvements to the DSP code that might be worth trying. The non-working one (STC12C5A60S2) does not have the option to disable internal XRAM, however.
PS: I did a minor test with Wolf3D and could indeed hear a clicking noise when opening the door, which might be the "click" that was previously being discussed. It's not that noticeable though -- could be heard if I listen carefully, but normally I would not notice it.
I wonder if there are some trivially reproducible tests for hanging notes, as my time with SB16 MIDI interface (using a daughtercard) is relatively short and I personally haven't encountered any noticeable error in MIDI playback.
PPS: Maybe you can consider bumping the reported DSP version number once the changes/improvements are mature enough, to distinguish from original DSP versions, though I'm not sure if any Creative's own setup utility or any game would mind.
LSS10999 wrote on 2023-10-14, 13:38:For this working MCU model I disabled the "internal XRAM" just in case, which I suppose is about the extra RAM the MCU has. I'm not sure if leaving "internal XRAM" enabled would get in the way of MOVX instructions which in the DSP's context could be the X-Bus interface, but I'm not going to test it for the time being until there are some further improvements to the DSP code that might be worth trying. The non-working one (STC12C5A60S2) does not have the option to disable internal XRAM, however.
With enabled XRAM, new '52 MCU will NOT work with SB fw. It needs to be disabled, by some configuration bits, or in fw software.
LSS10999 wrote on 2023-10-14, 13:38:I wonder if there are some trivially reproducible tests for hanging notes, as my time with SB16 MIDI interface (using a daughtercard) is relatively short and I personally haven't encountered any noticeable error in MIDI playback.
Hanging notes bug is clear in code, fixed and tested. I am sure, no problems on this side ))
LSS10999 wrote on 2023-10-14, 13:38:The non-working MCU in question is STC12C5A60S2. It's a so-called 1T (single cycle) MCU with timer retains 12T by default for compatibility (so timer initialization code does not have to be changed), but overall execution speed is about 600% of a standard 8051 from my past experience with this one.
I can prepare test build for STC12C5A60S2, with added delays on dataport access. Maybe it helps, but maybe x-bus exchange is too fast for BIU to work properly.
LSS10999 wrote on 2023-10-14, 13:38:I ended up using a STC90C58RD+ which is pretty much AT89C52 with more flash and internal memory. So far it's working correctly and I think I'll run some more software when I have time to be sure everything is okay.
Great ! New MCU is successfully tested ))
LSS10999 wrote on 2023-10-14, 13:38:I ended up using a STC90C58RD+
what programmer do you use for those MCUs? some special one made by "STC" as well?
I found their software "STC-ISP" and I see that STC90C58RD+ has an option to enable "6T mode" via the programmer and without a need to make changes in the firmware, i.e. without a need to init some clock dividers in the firmware:
have you tried with putting that MCU in "6T mode"? if it's still working are the"clicks" still there, because it was previously said that higher speed maybe will eliminate the problem?
Test build 1 for Single cycle DMA check
Test build 2 (may not work)
mattw wrote on 2023-10-14, 17:55:have you tried with putting that MCU in "6T mode"? if it's still working are the"clicks" still there, because it was previously said that higher speed maybe will eliminate the problem?
I haven't. According to the datasheet its timer will also operate at 6T if set to that mode, so MIDI will not work properly that way without code change.
Simply testing about clicks might work, though. At default 12T everything works fine including MIDI (I'm using a daughterboard).
mattw wrote on 2023-10-14, 17:55:what programmer do you use for those MCUs? some special one made by "STC" as well?
EDIT: I'm using a U8W programmer for STC microcontrollers, though if you have any 8051 development board with ISP support using STC MCU, you could use that for flashing with STC-ISP.
You'll need a PLCC44-to-PDIP40 adapter meant for 8051 MCUs to make it work, as the U8W programmer, as well as most 8051 development boards, use PDIP40.
Maelgrum wrote on 2023-10-14, 16:10:With enabled XRAM, new '52 MCU will NOT work with SB fw. It needs to be disabled, by some configuration bits, or in fw software.
I can prepare test build for STC12C5A60S2, with added delays on dataport access. Maybe it helps, but maybe x-bus exchange is too fast for BIU to work properly.
I'm not sure how to disable XRAM in STC12C5A60S2 as from the ISP programmer that option is not offered on that family of MCUs anymore... Only STC89 and STC90 series have that option.
EDIT: Just read the datasheet of STC12 MCU regarding memory. The access to the internal XRAM (auxiliary) can be controlled via AUXR.1 bit, so it may be disabled via code.
Additionally, it appears STC12 MCU has a BUS_SPEED register that allows tweaking the execution speed of MOVX instructions, enabling some flexibility. The default values of BUS_SPEED register corresponds to ~14 clock cycles for MOVX when accessing external memory, which is only a bit faster than a standard 8051 MCU's 24 clock cycles. Depending on how you set the ALES and RWS bits, MOVX instruction speed for external access can be between 7 and 20 cycles. (MOVX execution speed = 7 + ALES*2 + RWS)
EDIT: Correction on the actual clock cycle values.
LSS10999 wrote on 2023-10-15, 01:56:According to the datasheet its timer will also operate at 6T if set to that mode, so MIDI will not work properly that way without code change.
Simply testing about clicks might work, though. At default 12T everything works fine including MIDI (I'm using a daughterboard).
No problems to change timer configuration, if it is needed.
Single cycle clicks on fast MCU, that is interesting - is there any noticeable difference?
Maelgrum wrote on 2023-10-15, 02:07:No problems to change timer configuration, if it is needed.
Single cycle clicks on fast MCU, that is interesting - is there any noticeable difference?
For STC90C58RD+ in 6T mode timer configuration will definitely need to be changed and tested.
For STC12C5A60S2, the timer does not need to be changed as it operates at 12T by default, but some additional initialization code will be needed -- to disable access of internal XRAM, and maybe tweak MOVX execution speed for external bus access.
Will take a look at the code and see what I need to do. I'm relatively new to assembly as I mostly write 8051 code in C...
EDIT: Does the DSP program begin from "reset_handler"? If so, then maybe setting the bit controlling access to internal XRAM here would probably work...
I've finished testing with STC12C5A60S2.
1. The internal XRAM indeed got in the way. After setting the EXTRAM bit in AUXR (8Eh) and now it works fine -- the DSP can be detected. For this MCU, adding this line below into "reset_handler" as part of the init sequence is enough. There's no need to change any timing. I haven't changed the BUS_SPEED register (A1h) yet, but the bus chip seems to be okay with it (14 clocks vs 24 clocks).
orl 8eh, #2
2. In DOS, both digitized audio and MIDI work as expected. However, with this faster MCU, Windows NT 3.51's SB16 driver could not detect it properly anymore. With STC90C58RD+ the card worked fine in NT 3.51. Perhaps the difference in execution speed is not an issue for DOS but a great deal for Windows and maybe other OSes.
Unless someone figures out how SB16 drivers in other OSes work (namely Windows), I'm afraid adding delays won't magically fix everything and could instead introduce other issues...
EDIT: It seems Duke Nukem 3D also doesn't like faster MCUs. It would freeze there for a while then reports the sound card not responding.
In general, I'm getting mixed results from various software regarding this... some work without issues, while others not. Need to actually look into and compare how good programs handle the DSP and how bad programs handle it to figure out what's really going on.
3. Tried several Wolf3D TCs. Could not notice any difference regarding clicking compared to my previous MCU. Maybe clicking happens with specific audio patterns, as it is only apparent on some TCs' door opening/closing sounds but not on other. The door opening sound in "Spear Resurrection" was the most apparent one to me, occurring in the middle.
Additionally, I noticed intermittent audio dropouts in Wolf3D, particularly when having a lot of digitized sounds to play (firing weapons, enemies, etc.). Ingame digitized sounds would cut off halfway, or stop altogether, and would take a while before it recovers itself and sound would play properly again for another while. So far this issue has not been observed in a few other games I've tried. Maybe it was just Wolf3D's audio logic being flawed in general and the DSP itself was not entirely to blame, as this happened to me on both STC90C58RD+ and STC12C5A60S2.
LSS10999 wrote on 2023-10-15, 07:56:However, with this faster MCU
can you say how much faster STC12C5A60S2 compared to regular 8052 MCU in "6T" is in that case? I just wonder what are the speed limits when those problems start to emerge. Also, thank you for giving so much good details about STC chips and how and with what programmers they can be used.