maxtherabbit wrote on 2024-01-25, 01:05:
Datadrainer wrote on 2024-01-24, 20:02:I also missed the topic... And it is a really interesting one! That is wonderful to have a dump of all 4.xx firmware, to have an […]
Show full quote
I also missed the topic... And it is a really interesting one! That is wonderful to have a dump of all 4.xx firmware, to have an ASM commented source of v4.13 and jewel in the crown, to have the most annoying bugs corrected with optimizations in bonus, all of that in a very short period of time. Thank you very much to all the people involved, especially @Maelgrum who made it possible.
But it is quite sad their is no real conclusion there. I was left a little unsatisfied as nothing new was done since last October.
Is there any plan for new optimizations or additions in the firmware in the future?
Is there any clue on what can causes the last remaining issue if not a bug in the DSP?
Is there a place, apart from along the thread, where the files and the project purpose and history can be accessed?
Thanks.
I think we're at the end of the road on what can be done with software optimization, but I do wish maelgrum would upload the final version of his modified fw to vogons drivers so it doesn't remain buried in this thread
Yes that would be good.
I really appreciate projects like this with passionate people not counting their time to understand how things works and improving them. Allowing to get the better of our beloved old hardware.
But my personal opinion for open source projects is it would be preferable to use repositories with DVC like GitHub as it allow to follow the development history. Get the sources for a defined version, and it's easy to distribute binaries through a single link.
Having backup in archives sites like archive.org or the VOGONS Vintage Driver Library is the step after as the more a piece of software is spread, the more chance it have to persist.
But in the end, I'm just glad such project exists 😀
maxtherabbit wrote on 2024-01-25, 01:06:
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.
I've been running this release on three different systems since it was available, it's rock solid
Thank you for the feedback. Great to know.
For what I understood and to summarize it (please, correct me if I'm wrong. I surely am):
- The processing algorithms were not modified.
- The modified parts were the functions handling the data streams from the BIC with the code being reorganized to work correctly with a few additional lines to guaranty the states are always correct.
- The optimizations never changed the timings, just trying to get the data flow more efficient and fast to avoid to lose data on DSP reset.
And there is always the rule: Bugged firmware code + bugged software trying to correct the firmware shortcomings = kinda working. You correct the firmware, you get a mess. So it's always possible to get strange behaviors with some software. That's why feedback is important.
Marmes wrote on 2024-01-07, 23:11:
I just read this, find it interesting while I was upgrading my CT2290 which has DSP4.13 I took a picture of DSP location. Many things are not there anymore.
I will attach image :
@Marmes. I do not understand your assertion «Many things are not there anymore.», can you please explain what do you mean?
I'm interested to know where you got this partial pinout for the DSP. I found nothing about that. Maybe from the firmware ASM but I hadn't the time to look it for now. Creative Labs is often using rebadgered ICs from different manufacturer on different packages. Some are programmable meaning the pinout for the data and addresses lines is what is defined by software making it hard to know what they do. That can be guessed looking to where the lines go on other well know ICs I suppose or where the lines came from. Considering the DSP, probably not all pins are used. I hope someone can answer.
Knowing things is great. Understanding things is better. Creating things is even better.