Maelgrum wrote on 2023-10-12, 02:20:

But it can be not locked)) S95Sedan dumped 4.04, Malice dumped 3.02 and 4.05. So it is possible, but requires some luck. […]
Show full quote

But it can be not locked))
S95Sedan dumped 4.04,
Malice dumped 3.02 and 4.05.
So it is possible, but requires some luck.

And 2.02 (?) dump by Eric (@TubeTimeUS).
Decapping chip, direct probing of chip signals, reading bit by bit from sense amplifier.
This is astonishing, hats off.

PS. With all my respect for work of @S95Sedan and @Malice

Hey i just popped the chip in a reader. All the ground work was already done really.
Though i did have a rompar project i was working on at some point but never completed. (which takes die-pictures as input)

I think whoever found out about the xor decryption key deserves most credit, without that non of this would have been possible.

--------

Did you still need additional testing for the sbplay/dma clicking with some of the cards i have?

appiah4 wrote on 2023-10-12, 14:18:

@TubeTimeUS actually reverse engineered it using die x-rays or some such imaging rather than dump it AFAIR?

Partially decap the chip and direct probing.
https://twitter.com/TubeTimeUS/status/1137554976257929217

appiah4 wrote on 2023-10-12, 14:18:

@TubeTimeUS actually reverse engineered it using die x-rays or some such imaging rather than dump it AFAIR?

https://hackaday.com/2019/06/19/reverse-engin … -sound-blaster/

S95Sedan wrote on 2023-10-12, 16:18:

I think whoever found out about the xor decryption key deserves most credit, without that non of this would have been possible.

This information is from from MAME team.

S95Sedan wrote on 2023-10-12, 16:18:

Did you still need additional testing for the sbplay/dma clicking with some of the cards i have?

sbplay - i think not needed to be tested any more, thanks.

I hope at this weekend some completely new code will be done, with cmd 0x14 via int0.

This is source code of unmodified V4.13 (with all bugs present).
Sole purpose of this - to be a base for diff's (for anyone who interested in source code changes)

This is release of 'dsp_v413_maelgrum' version 5
Changes from classic V4.13:
1. Hanging note bug fixed
2. ADPCM decoding bug fixed
3. ALL interrupt handlers are fixed (PSW bug and R0 used before pushed to stack bugs)
4. Numerous small scale optimizations (LJMP to RET is changed to RET, e.t.c.)

Must be as stable as classic V4.13 - nothing is changed in logic of code.
And have some improvements, comparing to old patch 4.

Maelgrum wrote on 2023-10-12, 17:06:

This information is from from MAME team.

MAME includes 8052-emulator for the DSP, as far as I can tell from their code:

https://github.com/mamedev/mame/blob/master/s … us/isa/sb16.cpp

[EDIT] BTW, I will go entirely off-topic, but just because @Maelgrum, with that comment ,took my attention to MAME - I did not know, they Dumped the Roland MPU-401 ROM and even dumped it on the latest version, i.e. the one that is integrated in the 6801-microcontroller:

https://github.com/mamedev/mame/blob/master/s … hine/mpu401.cpp

that's actually amazing - maybe topic of entirely another thread and indeed "roland__6801v0b55p__15179222.bin" is included in the MAME ROM collections - I found it and download it without any issues. Now, the question is why no real perfect MPU-401 clone wasn't made based on that ROM - it's even more amazing the dump was made 2013, i.e. 10 years ago.

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

[...]Now, the question is why no real perfect MPU-401 clone wasn't made based on that ROM [...]

I would not assume that it was not made 😁 but ultimately is not needed - just like there is no need to invite Roland to take actions against someone that would use this in some hardware...
I do not know if you are aware but they did came after MUNT some years ago - but that was an emulator and just like nintendo they cannot shutdown emulators... copyrighted code on the other hand is a whole different deal , noone needs that pain in their lives IMHO

keropi wrote on 2023-10-12, 21:46:

I would not assume that it was not made 😁

yeah, I believe you cloned the Music-Quest card, but it's clone of a clone - re-implementation, not running the exact Roland code. anyway, not to spam the thread here with more off-topic, but I was real amazed so many years ago MAME dumped the Roland ROM.

keropi wrote on 2023-10-12, 21:46:

copyrighted code on the other hand is a whole different deal , noone needs that pain in their lives IMHO

10 years later, MAME is up and running - no one came after them...

[EDIT] no more off-topic here, opened new thread about it:

MAME Roland MPU-401 Emulator

mattw wrote on 2023-10-12, 21:50:

[...]10 years later, MAME is up and running - no one came after them...

maybe it was not clear enough but I was referring to a clone of the original mpu , not PCMIDI
what I am saying is this: MAME (and MUNT) are still around *but* both do not distribute any copyrighted code - this is what saves them
the fact that you can go to the internet and download all the roms you heart desires is irrelevant
on a sidenote , the shadow mame dumping team has down wonders dumping protected devices and cracking encryptions, it's a digital art IMHO

anyways, I think it's enough offtopic from me , I just threw my 2 cents and that's about it 😀

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

This is release of 'dsp_v413_maelgrum' version 5 Changes from classic V4.13: 1. Hanging note bug fixed 2. ADPCM decoding bug f […]
Show full quote

This is release of 'dsp_v413_maelgrum' version 5
Changes from classic V4.13:
1. Hanging note bug fixed
2. ADPCM decoding bug fixed
3. ALL interrupt handlers are fixed (PSW bug and R0 used before pushed to stack bugs)
4. Numerous small scale optimizations (LJMP to RET is changed to RET, e.t.c.)

Must be as stable as classic V4.13 - nothing is changed in logic of code.
And have some improvements, comparing to old patch 4.

Thanks!

How hard would it be to implement fake ACK for the MPU? The same way as Ensoniq Soundscape "supports" intelligent mode MPU enough to get most games working. That would be a nice improvement.

I hope the AT89S52 chips would arrive soon so I can test the fixed firmware. I also have one CT2290 that have very quiet DMA clicking (hard to notice, you really have to try to hear it) and I'm waiting another CT2290 to arrive (I hope it is a "bad" one with typical DMA clicking) so maybe something can be tested.

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?

aitotat wrote on 2023-10-13, 04:25:

I hope the AT89S52 chips would arrive soon

same from my side. BTW, @Maelgrum if you need a tester for "6 clocks cycles"-mode, i.e. if you believe anything can be fixed/improved that way, just keep in mind I ordered "AT89C51RC2".

aitotat wrote on 2023-10-13, 04:25:

I hope the AT89S52 chips would arrive soon

same from my side. BTW, @Maelgrum if you need a tester for "6 clocks cycles"-mode, i.e. if you believe anything can be fixed/improved that way, just keep in mind I ordered "AT89C51RC2".

aitotat wrote on 2023-10-13, 04:25:

How hard would it be to implement fake ACK for the MPU? The same way as Ensoniq Soundscape "supports" intelligent mode MPU enough to get most games working. That would be a nice improvement.

Excellent, idea! I think if the DSP code is what handles the MPU UART responses that should be easy. maybe, @Maelgrum is not familiar what we mean and so just to give some further details:

dosdays.co.uk wrote:

The ACK Message Another option (mattw note: for games that need MPU-401 Intelligent mode to connect to Rolland MT-32 device) if […]
Show full quote

The ACK Message
Another option (mattw note: for games that need MPU-401 Intelligent mode to connect to Rolland MT-32 device) if you don't have a proper MPU-401 interface is if you have a sound card that sends an ACK *acknowledge" response to all MIDI messages that get passed to them which in many cases fools the game into believing you have a real MPU-401 interface. So in our case, it works like this:
1) the game's code sends a MIDI message to say 'play some music'.
2) the clever sound card receives this message (since it is acting as the conduit from the PC to the external sound device) and automatically sends back an 'ACK'. If you had a real MPU-401 interface, it too would send back an 'ACK' message to the running program, but it would probably also send further information with it.

and by pure accident I wrote earlier today about MPU-401 ACK response and how such communication looks like:

Re: Roland LAPC-N / I question

So, if the DSP can be patched to sends out "Fake ACK" (let's call them that way for short) to any MIDI Request that would be huge improvement, indeed! Last, but not least - if there is space in the 8052-MCU ROM (or if needed we upgrade the MCU to one with 16KB, 32KB and even 64KB of ROM space), I think even full MPU-401 code can be integrated, which makes the comment I made in post here:

Re: The Soundblaster DSP project

not even off-the-topic, but an idea for possible way for improvement of the current SB16 DSP-code, but maybe for the full MPU-401 support - not just the ROM space, but the 8052 speed would be a limitation. In any way, just implementing "Fake ACK", if that is possible, will be very huge improvement.

Can someone write in a nutshell what this does, where it applies, what you need... ? If possible in the 1st post.

Thanks

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

same from my side. BTW, @Maelgrum if you need a tester for "6 clocks cycles"-mode, i.e. if you believe anything can be fixed/imp […]
Show full quote

aitotat wrote on 2023-10-13, 04:25:

I hope the AT89S52 chips would arrive soon

same from my side. BTW, @Maelgrum if you need a tester for "6 clocks cycles"-mode, i.e. if you believe anything can be fixed/improved that way, just keep in mind I ordered "AT89C51RC2".

aitotat wrote on 2023-10-13, 04:25:

How hard would it be to implement fake ACK for the MPU? The same way as Ensoniq Soundscape "supports" intelligent mode MPU enough to get most games working. That would be a nice improvement.

Excellent, idea! I think if the DSP code is what handles the MPU UART responses that should be easy. maybe, @Maelgrum is not familiar what we mean and so just to give some further details:

dosdays.co.uk wrote:

The ACK Message Another option (mattw note: for games that need MPU-401 Intelligent mode to connect to Rolland MT-32 device) if […]
Show full quote

The ACK Message
Another option (mattw note: for games that need MPU-401 Intelligent mode to connect to Rolland MT-32 device) if you don't have a proper MPU-401 interface is if you have a sound card that sends an ACK *acknowledge" response to all MIDI messages that get passed to them which in many cases fools the game into believing you have a real MPU-401 interface. So in our case, it works like this:
1) the game's code sends a MIDI message to say 'play some music'.
2) the clever sound card receives this message (since it is acting as the conduit from the PC to the external sound device) and automatically sends back an 'ACK'. If you had a real MPU-401 interface, it too would send back an 'ACK' message to the running program, but it would probably also send further information with it.

and by pure accident I wrote earlier today about MPU-401 ACK response and how such communication looks like:

Re: Roland LAPC-N / I question

So, if the DSP can be patched to sends out "Fake ACK" (let's call them that way for short) to any MIDI Request that would be huge improvement, indeed! Last, but not least - if there is space in the 8052-MCU ROM (or if needed we upgrade the MCU to one with 16KB, 32KB and even 64KB of ROM space), I think even full MPU-401 code can be integrated, which makes the comment I made in post here:

Re: The Soundblaster DSP project

not even off-the-topic, but an idea for possible way for improvement of the current SB16 DSP-code, but maybe for the full MPU-401 support - not just the ROM space, but the 8052 speed would be a limitation. In any way, just implementing "Fake ACK", if that is possible, will be very huge improvement.

Thinking about intelligent MPU mode, there is a problem - current fw not uses MPU command register at all.
All it uses, is one signal line from Bus interface chip, telling what MPU Uart mode is running, or not.
So questions - is MPU command register present on x-bus (but not used)
Is any bit flag in some x-register exists, telling that command register was written, but not readed yet.
If both things present, then it is possible to plan intelligent mode MPU.

kixs wrote on 2023-10-13, 12:48:

Can someone write in a nutshell what this does, where it applies, what you need... ? If possible in the 1st post.

Thanks

1. New DSP firmware for SB16/AWEs fixes some bugs (including infamous hanging note bug)
2. Applies to all Sb16/aWEs with discrete DSP.
3. You need to desolder old DSP, install plcc socket, buy modern programmable '52 MCU, buy MCU programmer, install new fw in old SB))

Currently, research are in progress, about ways to solve single cycle DMA clicking bug.
Also, in this project, all versions of DSP fw was dumped, including 4.16.

Thanks 😀

Nice project.

Maelgrum wrote on 2023-10-13, 13:01:

Thinking about intelligent MPU mode, there is a problem - current fw not uses MPU command register at all. All it uses, is one […]
Show full quote

Thinking about intelligent MPU mode, there is a problem - current fw not uses MPU command register at all.
All it uses, is one signal line from Bus interface chip, telling what MPU Uart mode is running, or not.
So questions - is MPU command register present on x-bus (but not used)
Is any bit flag in some x-register exists, telling that command register was written, but not readed yet.
If both things present, then it is possible to plan intelligent mode MPU.

I doubt this exists but you can modify for example function E3 to dump so called x-bus registers and see if it dumps the last byte written to port 3x1h.

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