Donkey Kong: Walking Sound Hack?

[80sArcadeKid]

I think thorr is on the right path here, each analog generated sound needs to be filtered?/simulated? rather than a holistic filter over the top of it all.

I did a recording with the LPF 2khz 1st filter and it made very little difference to the underlying tone issue, sounds similar to the internal default setting but does take a slight overall edge of it but nothing really changes.

[80sArcadeKid]

I downloaded the Arcade-DonkeyKong_20220429.rbf that jopdorp created, the walk is different, definetly not as pitchy but still not really equivilant.
Looped twice. Both with the 2khz LPF on.

I notice that the jopdorp rbf mutes the over games sound as well (kinda like MAME) but not sure why? I had to reset and record twice as thought something was wrong with my recording but happened both times. I've adjust volumes so they are all similar, so the difference is the tone.

I actaully think the current implemented walk is closer to the original, just that super high pitch.

[schendel]

dkong.drawio.png (986.18 KiB) Viewed 9823 times

I listend and looked at the audio you sent, and there is obviously some things that could be improved:
1. The purple "envelope generator" path for the DAC is missing in the FPGA, which is present in Mame
2. The yellow path with second order low-pass is missing in the DAC output
3. Most of the analog effects are still stored as WAV files, it is unclear what kind of filtering they have. Either the red or the green path have been
impemented by Jopdorp.
If we apply an output filter, this should only be appied to emulate the brown path, that is common for all sound sources.

Some questions on your recordings
Also, I noticed that the music seems to play slightly faster in the FPGA. Did you record all sounds with the same capture card?
The side-edge connector on of the TKG4 board has two audio outputs: Monitor out and

[schendel]

sorry submitted previous early by accident

The side-edge connector on of the TKG4 board has two audio outputs: Monitor out (brown path) and Speaker out (not colored, right next to the brown path), I think the monitor out path is normally connected (for upright cabinets ?, controlled by switch SW2). This signal is again connected to another amplifier board (next to the monitor?).
Did you record the speaker signal (component side of board) or tv audio signal (solder side of board) ? (second is most likely, if you keep SW2 on default)

MAME Donkey Kong can be compiled with or without both the 1916 Hz 2nd order lowpass and the additional components on the amplifier board next ot the monitor, but by default, all filters are there. This could be one reason for MAME sounding so dull. I assume that you have the default version with filters, let me know if I am wrong.

When processing comparison waveforms with audacity, ot looks like adding the 1.9 kHz lowpass will make the FPGA digtal sound quite close to the PCB.

This is a bit strange, because the brown output path until the Monitor sound (that, I think, MAME always simulates) is strange:
The 47kOhm output resistors of all audio paths, combined with C159 of 100 nF of the monitor path give 1st order cut-off of 1/(2 pi 47 * 0.0001) = 30 Hz !? It seems that MAME implements something like this (not 30Hz though), this seems to cause the underwater sound on the MAME recording.
Strange enough I think MAME is simulating this filter even when (other) filters are not compiled, but it seems that the simulation does not correspond to your recording. I guess Jopdorp already found out that getting a simulation that is equal to reality is actually quite hard.

Does you know if a real setup including the original speaker also sound like the MAME version?

One thing that the real recording spectrum shows, but neither MAME nor FPGA is some extra (2nd) harmonics. This probalby means that the real system has some non-linearities in the digital waveform generator path.

Finally, it seems that the small duration and pitch difference (2.4%) is due to the Digital Waveform Generator running at 6.144 MHz instead of 6.000 MHz the schematics shows.
This 2.4% difference seems small, but the human ear can distinguish a diffence of 3.6 Hz at about 1kHz, which is about ten times less (https://en.wikipedia.org/wiki/Psychoacoustics).
Also, I think it amazing that your board audio oscillator apparently still runs at 6 MHz after all these years! (or is this a case of the "Ship of Theseus"?)
If no one else is already working on this, this seems to be something I can fix, although it may be a bit tricky, because running this part at the non-system clock will require securing some asynchronous transitions (although it seems the original board has no problems with it).

It seems to me, that, with correct clock speed, 1.9 kHz filter and envelope generator (the last is probalby the trickiest), the digital waveform generator spectrum of the FPGA implementation would be more accurate than the MAME implementation (of course that is still hot air until its there).

Then we would still have to take a look at the pseudo-analog effects.

[thorr]

If no one else is already working on this, this seems to be something I can fix

I don't think anyone is currently working on this. It would be greatly appreciated if you could make improvements! Thanks! You could try reaching out to jopdorp via github. He hasn't logged into this forum since August.

[Robgus]

If no one else is already working on this, this seems to be something I can fix

I don't think anyone is currently working on this. It would be greatly appreciated if you could make improvements! Thanks! You could try reaching out to jopdorp via github. He hasn't logged into this forum since August.

I agree. I would consider sponsoring it on patreon.

[80sArcadeKid]

sorry submitted previous early by accident

The side-edge connector on of the TKG4 board has two audio outputs: Monitor out (brown path) and Speaker out (not colored, right next to the brown path), I think the monitor out path is normally connected (for upright cabinets ?, controlled by switch SW2). This signal is again connected to another amplifier board (next to the monitor?).
Did you record the speaker signal (component side of board) or tv audio signal (solder side of board) ? (second is most likely, if you keep SW2 on default)

I really don't know the answer to this, I use the "Mr Video" on default settings I believe goign directly the the GV-USB2 capture dongle. Not sure which pin it uses. All I know is the speaker sounds and captured sound is similar and the FPGA is way off. You said it uses samples, for analog which is probably the issue I assume?

Does you know if a real setup including the original speaker also sound like the MAME version?

MAME sounds thew same but 'duller'. Speaker from arcade and Mr Video capture sound similar. Very diffferent to FPGA. The videos really are te best example I can give and sound like I hear them.

Also, I think it amazing that your board audio oscillator apparently still runs at 6 MHz after all these years! (or is this a case of the "Ship of Theseus"?

The board has definetly had repairs, but it sounds similar to 11 other boards that played next to it at the recent Austrlaian Kong Off. Whereas FPGA sound way different,

If no one else is already working on this, this seems to be something I can fix, although it may be a bit tricky, because running this part at the non-system clock will require securing some asynchronous transitions (although it seems the original board has no problems with it).

This would be amazing, if you have a patreon I'd definetley sub for the duration and maybe always if you continue to fix classic arcade core issues!

[PistolsAtDawn]

This would be amazing, if you have a patreon I'd definetley sub for the duration and maybe always if you continue to fix classic arcade core issues!

As would I!

[schendel]

First of all, thanks for pointing out that the FPGA sound is wrong, you convinced me.
I an quite a Noob to Arcade hardware (professional EE though), and (FPGA) emulation is already quite old.
So I was excited that I could contribute to this very Video game history relevant core.
The challenge is my main motivation, the pressure of having to satisfy Patreons would just turn me off, my day-job already supplies enough pressure.
So your best way to help this along is to do what you already did: record what is wrong and point it out.

The side-edge connector on of the TKG4 board has two audio outputs: Monitor out (brown path) and Speaker out (not colored, right next to the brown path), I think the monitor out path is normally connected (for upright cabinets ?, controlled by switch SW2). This signal is again connected to another amplifier board (next to the monitor?).
Did you record the speaker signal (component side of board) or tv audio signal (solder side of board) ? (second is most likely, if you keep SW2 on default)

I really don't know the answer to this, I use the "Mr Video" on default settings I believe goign directly the the GV-USB2 capture dongle. Not sure which pin it uses. All I know is the speaker sounds and captured sound is similar and the FPGA is way off. You said it uses samples, for analog which is probably the issue I assume?

Ok, so as I said I am an Arcade Noob: I have no idea how one would go about connecting the "Mr Video" to the Arcarde hardware. I looked at the operation manual of the TKG4-UP board model, and there are at least four connector pins (A, A*, B, C) where you might record a sound signal. A and A* should be the same signal, but the others could all sound different. There are also two places where you could capture Video (1 and 1*).

dkong_av_locations.drawio.png (275.56 KiB) Viewed 9447 times

This manual is in principle copyrighted content, the manufacturer being who they are, can this wiki get into trouble for this post? Of course, they have nothing on me: this is a citation of their work in my very new and original work of art. Anyhow, they did assert their copyright in the manual, so maybe this is (a pdf of) one of those rare copies without the copyright sign? (Yes while figuring out the code of the core and the schematics, I learned a bit about especially collectible cabinets, very interesting. Hot damn, I couldnt find the TKG2 schematics, so I finally thought to google for the Radarscope schematics and Voila! The Internet archive is just amazing, sponsor them if you must spend money! Must -- continue -- writing -- post -- cannot -- study -- schematics).
I hope you do not mind me going off on tangents like this, if you dont, you just blame #80sArcadeKid for putting me up to this!

The reason why I insist is that I looked at the MAME code, and from the comments, it seems they did do not just "copy" the schematic, but also did measurements to verify their code, so I wonder how it could be so much off. They would have compared audio of the emulator to the real thing (wouldn't they?), so maybe they are just simulating a different signal than you measure?

Another explanation could be that people may be (commiting heresy by) removing capacitor from the board to get a more clear sound, although that would have to be very common for all systems on the Kong-up to do so.

[schendel]

So anyways, it took some time to get back, because I rather wanted to reply with some good news (in the form of an .rbf).
This is not yet so far, but the good news is that I still believe this can be fixed.

• Changed the Digital Signal Generator clock speed, and now the duration of these sounds is then exactly the same as in your recording. However, this change is not the major improvement that you would notice.
• Added an 2kHz IIR filter to the Digital Signal Generator signal path (but not the analog effects). Unfortunately, for the last day, bugs have been doing what bugs do. For the time being, you could try enabling the Arcade 2nd order 2kHz low-pass filter in the MiSTer sound options. You should get get better digitally generated sound (at the expense of perhaps worse
• The analog emulation framework that JOpdorp started can (probably) be used to implement the envelope generator on the Digital Signal Generator/Synthesiser path, so that the legatos in the FPGA version of the tunes will be no-more.
• Figuring out what to do with the remaining waveform samples for Jump and Bump. They apparently have a weird sample rate of 555 times less than 6 MHz clock frequency. Did the FPGA core creator put this in an easter-egg as a homage to the iconic 555 timer, which is being used in a dual-package on this board? Due to hard tracabilty of the Git repository, we may never know...
  Regardless I will use the same trick and ensure that, for example, the Jump sound has the same duration on the FPGA and the PCB recording.
• It is not really true that this core is abandoned, it regularly receives improvements. However, it is hard to track because Git history is hard to track,
  with changes being copied between MiSTer, gehstock MiST and some other repos that I have not yet located. At some point, it would be nice to collect all contributors, because Git history is getting lost with all the back-and-forth copying.
• As far as I can tell, the walk sound made by JOpdorp (and probably MAME as well) is pretty accurate. If it is not right, the way forward is to improve it, not to go back to sampled sounds. By "coincidence" I was rewatching the Hiscore documentary on Netflix, and Hirokazu Tanaka, the programmer of the sounds, specifically mentioned that it was actually a coincidence that the walk sound was irregular, because it depends on the walk-sound history. The walk sound is a response to the player command, so it would be pretty hard to reproduce this irregularity with sampled sound. And Tanaka-sensei mentioned this specifically, so we can not really leave this out can we now?

[thorr]

That is awesome that you saw the walking sound being mentioned specifically in Hiscore. Have you seen King of Kong a Fistful of Quarters?

Thanks a ton for all of your efforts!

[dshadoff]

The reason why I insist is that I looked at the MAME code, and from the comments, it seems they did do not just "copy" the schematic, but also did measurements to verify their code, so I wonder how it could be so much off. They would have compared audio of the emulator to the real thing (wouldn't they?), so maybe they are just simulating a different signal than you measure?

I think the best response to this is, "make no assumptions".

On the MAME side, do not assume that anybody has done a comparison with real hardware; MAME's historical priorities have been to get machines "playable", and bugfixes/refinements come if/when developers are motivated... this is not a foregone conclusion. Also, focus has tended to be on gameplay, with sound and other "analog" attributes being re-examined later (and sometimes never). So it should only ever be considered a point-of-reference, not a reference implementation.

Having said that, MAME does get improvements. But with Youtube videos having various ages, and with emulators (such as RetroArch) not using the most up-to-date versions of MAME, it gets confusing really quickly what you are actually listening to - so MAME should also not be considered to be a fixed implementation.

On the arcade side, there are also variables such as:
- authentic board or copycat ?
- what version of the board is it (manufacturers kept very poor records back then) ?
- were authorized or unauthorized modifications added ?
- Is the "reference" sound captured at the output of the board, or at the output of an amplifier section (or even speakers) ? (and is the intent to emulate the original board, or also the analog output section and acoustics ?)
- how has 40 years of time affected original parts - or has the machine been kept well-maintained ?

... So overall it's a very difficult problem to manage... but in any case, some reference is better than no reference.
I can agree that the sound recorded at the beginning of this thread showed that MiSTer had needed some work though.

[dmckean]

- how has 40 years of time affected original parts - or has the machine been kept well-maintained ?

To me, this can be the biggest one. Do we want to recreate what a Donkey Kong board sounds like today with 40+ year old components or do we want it to sound like factory new. Is there even a difference?

[dshadoff]

If it’s been well-maintained, there shouldn’t be a difference - or rather, it should be within the expected machine-to-machine difference from the manufacture period (which, for analog circuitry, is much larger than for digital).

[thorr]

This is all good discussion but in reality it should be a non-issue. The components and their values are known. Therefore, the intended sound can easily be reproduced mathematically. Getting this in real time in FPGA is the bigger challenge. Yes as parts age, they will affect the sound. The great thing about FPGA is the analog signal quality will never degrade with time so we will always have brand new sound. There are other factors that affect the sound as well such as the enclosure the speakers are in and the room the cabinet is placed in. More or less bass can happen as a result for example. I think the goal here should be to reproduce the electronics as new and leave the rest to be controlled by external addons such as additional filters and arcade cabinets.

[mhartman]

- how has 40 years of time affected original parts - or has the machine been kept well-maintained ?

To me, this can be the biggest one. Do we want to recreate what a Donkey Kong board sounds like today with 40+ year old components or do we want it to sound like factory new. Is there even a difference?

This is a very small issue. I have 4 DK PCBs. They’re all slightly different, but I’ve replaced just about every component in the analog section of one (chasing a bug) and, while the sounds changed, it was more component to component variation than age related variations. 20% spec variation over several components will add up. That being said, I believe that the variations are a red herring - get it right and it will sound right. Our understanding of the sound is the average of what we’ve all heard over the years.

In my mind, the big issue is trying to recreate analog in a digital environment. Very, very tough (but not impossible).

[80sArcadeKid]

This is a very small issue. I have 4 DK PCBs. They’re all slightly different, but I’ve replaced just about every component in the analog section of one (chasing a bug) and, while the sounds changed, it was more component to component variation than age related variations. 20% spec variation over several components will add up. That being said, I believe that the variations are a red herring - get it right and it will sound right. Our understanding of the sound is the average of what we’ve all heard over the years.

In my mind, the big issue is trying to recreate analog in a digital environment. Very, very tough (but not impossible).

Wow! Mr Hartman. I've watched a few of your repair videos. This is a privilege sir. Any chance your knowledge can help any dev that attempts to simulate the analog circuits? Or was that Mike Haaland? LOL ethier way.

[mhartman]

This is a very small issue. I have 4 DK PCBs. They’re all slightly different, but I’ve replaced just about every component in the analog section of one (chasing a bug) and, while the sounds changed, it was more component to component variation than age related variations. 20% spec variation over several components will add up. That being said, I believe that the variations are a red herring - get it right and it will sound right. Our understanding of the sound is the average of what we’ve all heard over the years.

In my mind, the big issue is trying to recreate analog in a digital environment. Very, very tough (but not impossible).

Wow! Mr Hartman. I've watched a few of your repair videos. This is a privilege sir. Any chance your knowledge can help any dev that attempts to simulate the analog circuits? Or was that Mike Haaland? LOL ethier way.

Haha - you’re thinking of the Mike from Mike’s Arcade (different Mike). I’m just a hack who enjoys Donkey Kong. I know the hardware side, but unfortunately I’m no good with programming, so I’m probably of little help. That being said, I’m very interested in seeing a solid FPGA DK core!

[schendel]

Just to let you know I am still working on this.

The main thing I had to find out how hard it is to correctly add signed and unsigned numbers of different width in Verilog (<troll>VHDL is much better: if it compiles, it works correctly</troll>).

You may give this a try:
https://github.com/pvanschendel/Arcade- ... 221120.rbf

Improvements are only in the digital synthesizer (which produces all music and jingles)
1. The synthesizer now runs at the correct frequency
2. The synthesizer now has an envelope generator
3. The synthesizer now has a 1.9 kHz anti-aliasing filter
Embarassingly, it turned out that these last two changes had already been implemented on the DonkeyKongJr. core that was split from the main core years ago. For now, I just ripped these back to the original core.

I think the envelope and filter that get is not yet as accurate as they can be made, without increasing resource usage, but I thought I had to give you something.

I converted the wav sounds from the mra-file back to wav, to find out if their format (11.025 kHz, 8bit unsigned).
If anyone is interested, I can share the sound "recordings" I have in audacity file format.

The walk sounds in the mra are closer to the recording by 80sArcadeKid than the currently emulated walk sound.
So I hope that also there, some increased analog simulation accuracy may be achieved.
I had a short discussion with JOpdorp, and you can rest assured: He is not dead, but working on a new project, so I understood that there is no conflict if I am messing around.

To add (a barrel of, haha) oil to the fire of the sound output variations discussion:
The sounds in the mra are more noisy (that may just be early 2000s hobby sound recording tech for you), but also crisper than the recording by 80sArcadeKid.
So I think you may still want to turn on a 2kHz Arcarde low-pass filter in the core menu to re-create the sound of your particular setup. Maybe a new, even lower-pass filter is needed, although I do not think we should go so far down as to re-create the MAME experience.

I would be really interested: When the video was made of all Donkey Kong cabs running in unison, were individual recordings made as well? If so, could I get my hands on them?

Finally, I would like to find out how the original sound recordings in the current core were made. I just found the [url=https://web.archive.org/web/20080518005 ... ng_prj.htm
]original repository by Katsumi Degawa on internet archive[\url], but I think the .zip file downloads of the source code are lost.
Also, I am not sure what happened between 2004 and the time it arrived in the MiST repository, and where the mra files come from. I have not tried very hard to ask around, but if anyone who knows reads this...

Up next:

wickerwaka — 11/23/2022 10:51 PM
Pretty cool that they provide this: https://www.mamedev.org/tools/

I think I will give this a go, I am such a newbee, I have actually never used MAME

[thorr]

Thanks so much for the update and continuing to work on this. If Mame sounds better than the current samples, maybe you can hack it somehow to just isolate the sounds individually to make better all digital recordings of the analog sounds, or better yet, see the code used in Mame and replicate it in FPGA. If they do math functions, create (or borrow) FPGA code to do the math functions.

Edit: I just tried the new version and it is sounding a lot better! Jumping over the barrels and dying has crackles in the sound. I assume these are samples. Maybe the samples can be cleaned up in Audacity.

Check this out: https://www.researchgate.net/publicatio ... sing_FPGAs

Edit 2: I have to say, this new version is so much better than the released version. Great job! Thinking about what I mentioned above, I think jopdorp's method is probably the right approach. Hopefully he (or you) can improve it further someday. Meanwhile, maybe we can get better samples. Getting a cleaner one of the death sound should not be difficult because all other sound stops. We have lots of videos in this thread to reference to get the samples from. This is assuming the death sound is a sample.

Edit 3: I just listened to the video again and the death sound is crackly in the original arcade too, so never mind, lol

So what exactly is left as samples at this point? This version is so much better. Are you going to update Donkey Kong Jr. with any improvements too eventually?

[Robgus]

Wow! Thank you so much for this, absolutely brilliant, what an improvement!

I realised now, that the overall volume is lower in DK compared to a lot of the other arcade cores, is it like that for everyone or is it just on my end?

Thank you so much again.

[schendel]

Thanks a lot for the positive feedback, it really helps me to stick with this.

Edit: I just tried the new version and it is sounding a lot better! Jumping over the barrels and dying has crackles in the sound. I assume these are samples. Maybe the samples can be cleaned up in Audacity.

Au contraire, you are probalby right:
In my previous post, I was complaining about getting the summing of the various signals right, so I did not yet take care of clipping. This is what may be happening when simultaneously having the walk sound, sampled sound effects and the digital synthesizer sound, for example when walking into a barrel and dying (see below).

So what exactly is left as samples at this point?

The jump sound and the boom sound.
The boom sound is also used in the intro sequence, when barrels are dropped, and when jumpman gets hit by a barrel (don't nail me down on this).

It seems to me that the sampled sound more closely match the sound from the recording than either the JOpdorp version or the simulation on Mame, so after properly cleaning the digital synthesizer sound, I would like to get a closer match there. Then I would try to replace the sampled sounds.

Are you going to update Donkey Kong Jr. with any improvements too eventually?

I think you misunderstood: I copied code from Donkey Kong Jr. because the issues I am taking care of here are already fixed there.

That said, I looked at th Donkey Kong Jr. schematics, and it seems that the Nintendo designers were sick of the finicky 555-timer effects, and implemented something less hacky there. But it may be that these weird analog effects do add character to a sound, so that may explain why DKJr effects are just not as nice as the ones in Donkey Kong. Still if you can get an accurate recording of a DKJr. cab, we can compare it to the current core and have a look.

If any next core, it would be nice if we coud get a working Radarscope MRA (hint).

Check this out: https://www.researchgate.net/publicatio ... sing_FPGAs

Do you have any experience with that?

I think JOpdorp tried it and gave up, I have not tried this, but I do not think this is the way to go:

• The main reason for this is that it solves the wrong problem: Just copying the schematics does not produce an accurate simulation. We need to know thinks like input and output resistance and capacitance of the transistors and integrated circuits that are simple devices in the schematic. I believe this is the main reason why both the Mame and the JOpdorp solution create a different sound than the actual boards.
• The second reason I wouls not do it is I think it is not an efficient solution: The spice-like matrix inversion approach only works for linear time-invariant systems. To a certain extent, I hope you will believe me when I tell you that in this case we might just as well model the systen with an IIR filter. An IIR filter can be made relatively cheap. An IIR filter is what I copied over from the DKJr core, and what is also used in the sound filter settings that the current MiSTer framework has. In addition to being more complex without benefit, I think it may even produce unstable solutions. To my mind, spice simulations are the right tool for proving that a certain design works, but not for implementing it.
• A thrid reason, if we would like to go for ultimate accuracy:
  As soon as you want to model non-linear behavior (transistors as we have here) or behavior that varies with time (switches that may be opened or closed) the approach falls flat. To be fair, I do not propose to model transistor non-linearity, or changes in resistance due to switches opening or closing, but that is what people who model analog synthesizers do, as far as I understood.

I think we can learn a lot from what is going on / has been solved with analog synths. People there also seem to think that spice simulation is great, but the more sensible people (in my opinion) don't. Then again, spice probly does a lot more then simply compiling a netlist into a big sparse matrix and inverting it (maybe I will look at that sometime).

If you ever want to get into analog sound simulation, Julius O Smith of the CCRMA created a great resource :
https://ccrma.stanford.edu/~jos/
Be warned though, it seems that, unlike us, people trying to accurately recreate analog synths are kind-of crazy .

[pgimeno]

Also, I am not sure what happened between 2004 and the time it arrived in the MiST repository, and where the mra files come from. I have not tried very hard to ask around, but if anyone who knows reads this...

I took these samples from an old MAME sample set, from the time when MAME used samples instead of simulating the analogue sounds. I think I faded out the end and maybe faded in the start so that both ends didn't click. Can't remember if I did anything else besides cropping.

[dmckean]

Can we just record new samples using current mame and apply the correct filters to get us something better than what we have now?

[thorr]

Thanks a lot for the positive feedback, it really helps me to stick with this.

It is very much deserved! The new version is incredible in comparison to the old.

Au contraire, you are probalby right:
In my previous post, I was complaining about getting the summing of the various signals right, so I did not yet take care of clipping. This is what may be happening when simultaneously having the walk sound, sampled sound effects and the digital synthesizer sound, for example when walking into a barrel and dying (see below).

While that makes sense and is totally worth checking, I still think I hear the clipping in the real hardware in the comparison videos too. Don't stress if this ends up not being fixable because it isn't actually clipping. If you discover that it is clipping and you can fix it, that would be awesome.

It seems to me that the sampled sound more closely match the sound from the recording than either the JOpdorp version or the simulation on Mame, so after properly cleaning the digital synthesizer sound, I would like to get a closer match there. Then I would try to replace the sampled sounds.

Sounds great!

I think you misunderstood: I copied code from Donkey Kong Jr. because the issues I am taking care of here are already fixed there.

I understood, but I was suggesting that maybe you are further improving other aspects of Donkey Kong that might be an improvement in Donkey Kong Jr. also.

Check this out: ...
Do you have any experience with that?

Yes, but very little. I have run spice simulations before of analog circuits and they take forever to just start drawing the waveform. This was in the mid-90's on computers of the day. I was proposing that maybe in FPGA with dedicated logic, it might be able to be done in realtime with the hopefully somewhat simple circuits involved.

I think JOpdorp tried it and gave up, I have not tried this, but I do not think this is the way to go:

[*]The main reason for this is that it solves the wrong problem: Just copying the schematics does not produce an accurate simulation. We need to know thinks like input and output resistance and capacitance of the transistors and integrated circuits that are simple devices in the schematic. I believe this is the main reason why both the Mame and the JOpdorp solution create a different sound than the actual boards.

Just an idea, is it possible to temporarily have adjustable core menu values that can be adjusted for these resistances and capacitances and these could be used to try different values until the existing jopdorp code sounds correct? I am not saying you should do this, but I thought of it so I am sharing my thought.

[*]The second reason I wouls not do it is I think it is not an efficient solution: The spice-like matrix inversion approach only works for linear time-invariant systems. To a certain extent, I hope you will believe me when I tell you that in this case we might just as well model the systen with an IIR filter. An IIR filter can be made relatively cheap. An IIR filter is what I copied over from the DKJr core, and what is also used in the sound filter settings that the current MiSTer framework has. In addition to being more complex without benefit, I think it may even produce unstable solutions. To my mind, spice simulations are the right tool for proving that a certain design works, but not for implementing it.

To me, this is the most exciting part of your latest post. You clearly know what you are talking about, and I am excited to see if you can get this working with an IIR filter.

[*]A thrid reason, if we would like to go for ultimate accuracy:
As soon as you want to model non-linear behavior (transistors as we have here) or behavior that varies with time (switches that may be opened or closed) the approach falls flat. To be fair, I do not propose to model transistor non-linearity, or changes in resistance due to switches opening or closing, but that is what people who model analog synthesizers do, as far as I understood.

This makes sense too and may nullify my suggestion above about adjusting the temporary core menu values to try to find the right sound. I am not sure.

I think we can learn a lot from what is going on / has been solved with analog synths. People there also seem to think that spice simulation is great, but the more sensible people (in my opinion) don't. Then again, spice probly does a lot more then simply compiling a netlist into a big sparse matrix and inverting it (maybe I will look at that sometime).

If you ever want to get into analog sound simulation, Julius O Smith of the CCRMA created a great resource :
https://ccrma.stanford.edu/~jos/
Be warned though, it seems that, unlike us, people trying to accurately recreate analog synths are kind-of crazy .

Yeah, I have a Roland Fantom that does an excellent job modeling a Jupiter 8 and other analog synths. Maybe we need to get a Zen chip addon for our MiSTers so we can play Donkey Kong properly.

Thanks so much for all the details, and all your efforts, and I am super excited to see what you find out next. Even if it never gets perfect, it is already miles better than it was, and there is always the chance to get better samples if nothing else even if they aren't random like analog is (although there could be variations in the samples like sampled pianos). We will need a 1GB sample set for Donkey Kong for complete accuracy. (just kidding)

[schendel]

I took these samples from an old MAME sample set, from the time when MAME used samples instead of simulating the analogue sounds. I think I faded out the end and maybe faded in the start so that both ends didn't click. Can't remember if I did anything else besides cropping.

Wow, I did not expect an answer so soon!
Do you know how long ago that was?

Please bear with me, I know I am not moving very fast.
I would not like to replace the samples by other samples, but by analog emulation.
The reason for this is mainly just because I like the challenge.

[thorr]

Please bear with me, I know I am not moving very fast.
I would not like to replace the samples by other samples, but by analog emulation.
The reason for this is mainly just because I like the challenge.

This is music to my ears, no pun intended. Take your time. There is no need to feel rushed.

[pgimeno]

Wow, I did not expect an answer so soon!
Do you know how long ago that was?

Not much. https://github.com/MiSTer-devel/Arcade- ... er/pull/39

I took the existing core, which had a single sample for the walk, and added two more and made them play cyclically, per requests in this thread. I'm not very interested in the original DK sound because we only had clones around here, so it's not something I have nostalgia about, but people seemed so hopeful that someone made it, that since it was something that my poor skills could reach, I tried (and succeeded).

[80sArcadeKid]

Super glad you find it a challenge to help with the sound fixes! So are you intending to try fix all the sounds? Not just the walk?
I wish you a good challenge and hope you can do it!

While you are there maybe you can fix the default draw mode in the core, for some reason it is flipped like pleyr one is sitting on a cocktail cab in player two spot. (flip option in the menu makes it the right way!)

uSjMd45.jpeg (111.58 KiB) Viewed 8104 times

FPGA first frame

fYPrzRz.jpeg (111.69 KiB) Viewed 8104 times

PCB First Frame

[80sArcadeKid]

Checking in 2 months later
Anybody got updates on the Donkey Kong soudn issues? I know there was a few parties in this thread interested in doing the analouge sound simulaiton.