Strange 68020 audio glitching on a handful of games

[movisman]

Hi there,

I was hoping someone with some technical knowledge of the Minimig core might be able to help with this. There may be a simple explanation for it or maybe it's just the way the core works in 68020 mode.

Anyhow, the issue - so, for example, when using the MegaAGS image, this uses WHDload games and the HDF has to be run on a 68020 processor in AGA, KS3.1 in order to boot.

I've noticed that some games (for example, Shufflepuck Cafe and Hostages), the title screen music 'glitches' randomly on certain channels, or doesn't play certain notes at all. It isn't terribly noticeable if you are unfamiliar with the music, but it is easy to replicate. I don't think it glitches in the same place every time, but it glitches with regularity.

If I fall back to a standard .ADF floppy of these games, and run them in 68000, OCS, KS1.3 for example, the glitches are gone.

Unfortunately, the MegaAGS image can't run in 68000 OCS/ECS mode.

No amount of RAM combination or anything will resolve the issue, so I figured this was a 68020 / AGA implementation related thing.

If I try to run the .ADF floppies with a 68020 / AGA setup, the music is totally screwed, unlistenable and all over the place, random samples and glitchy noise. As detailed above, the WHDload variants fare far better in 68020 / AGA, but there is still the aforementioned glitching.

Obviously, the workaround is, any games which have glitchy sound on the MegaAGS image in 68020/AGA - sure I can just use an ADF floppy and load a 68000 configuration instead.

But I was curious as to why this happens.

It doesn't sound too bad to be honest, definitely playable, and it doesn't glitch at all on most games, but some (like the ones mentioned above) do suffer.

Of course, the ideal would be if there was a MegaAGS image out there which ran in 68000/ECS mode (basically an A600HD), but I cannot find one. I could try to build my own, so perhaps this is something to learn at some point.

I thought maybe it was related to cycle exact accuracy (or lack of) in 68020 mode, and that some games need this. I might be way off as I don't have the adequate technical knowledge on the core, but it was just a thought.

Does anyone have any ideas? I may report it as an issue on Github but wanted to get thoughts on here first before doing so.

Thanks!

[limi]

What would be interesting to test would be if someone with a real Amiga could try running the WHDLoad version of the abovementioned games. (I have one, but it will be a few days until I have access to it again)

It may be that the game has bugs that were not fixed in the WHDLoad conversion, or it might be a MiSTer core problem. But that would help narrow it down. Any Amiga users out there that could help out with testing it before I get access to mine again?

[rcade]

Did you test on a real Amiga also?

It could just be some games don't like/expect anything except 68000 and original 7MHz timings. It's very common. I know some WHDLoad games are "fixed" for this, but not all.

[movisman]

Hi there,

Thanks for the quick replies, appreciate it.
Unfortunately, I don't have a real Amiga A1200 to test. My brother has my old A600 but it isn't readily available.

I was wondering if it was a timing related thing - running most WHDload games on the MegaAGS image is generally fine, but the two I mentioned have this strange glitching, which is very easy to replicate. I'm sure there are others too. Those two were games I grew up with and so I instantly noticed the audio being off.

Weirdly, as I mentioned in the first post, running them from ADF floppies in 68020/AGA the sound is totally illegible. It's all over the place.

I can run the floppies fine in A500 mode. The sound doesn't glitch then.

I don't have an environment configured to be able to run WHDload games in 68000 mode (eg as an A600HD) - that would be an interesting test?

Any help appreciated, I have tried various RAM configurations and DCACHE on/off but it makes no odds.

@Limi - if you don't mind testing when you have access to your Amiga again that would be great. The Hostages WHDload I was using was quite recent, a 2020 release I think. Shufflepuck Cafe was much older. I wondered if it was something to do with the implementation of 68020/core bug, but like yourself and rcade says, at this stage it could be also related to the WHDload conversion.

Happy to help with any testing.

Thanks!

[Higgy]

Hi.
I will see about giving this a test on real hardware. I even have a MegaAGS image that I run on my real Amigas.
By one of those strange coincidences i only recently played Shufflepuck Cafe and Hostages for the first time.
Update: I went to test and just found my left speaker on my Amiga monitor is not working, so need to investigate that. Old hardware is like a classic car!

[ReadyPlayerTwo]

How do you output your audio from your Mister???

I use an external DAC and have no audio issues in the games you mention, either running from disc or from WHDLoad.

I find the Mister internal DAC isnt as good as it could be and the external makes a world of difference

[movisman]

Hi,

Thanks Higgy, sorry about your left speaker though! Hope you can get it sorted. That is a strange coincidence you played those two games recently! I did enjoy them both a lot when growing up. I can always try to capture what I experience if needed. It may not be super obvious to some maybe, but it's subjective of course. It's easy to replicate on the Minimig core using the MegaAGS image with the recommended 68020 configuration. If in doubt, then load in 68000 mode with floppies and you'll see what I mean.

@ReadyPlayerTwo - just using HDMI audio, all other cores are fine it's just this one with 68020 configuration and a select number of games using WHDload or floppies. And it doesn't do it when reverting to 68000 and floppies. I don't think it's related to the DAC or anything like that.

Thanks!

[Higgy]

@movisman speaker was simple connection issue, sorted.
Let us stick with Hostages. I am using WHDload version 1.1

I think this might be due to our good friends PAL and NTSC.
MegaAGS is set for NTSC, but a lot of games are PAL.

Load MegaAGS, press ESC to get to Workbench. Navigate:
Games - WHD - H - Hostages.
Right mouse click over the circle Hostages ICON.
Add a new Tooltype - PAL
Make sure this is around the first 2 lines, Slave and Preload.
Save and try the game again.

[movisman]

Hi there,

Glad you got the speaker sorted and it was just a simple connection issue!

I forgot to say, I have already tried to force PAL mode for the MegaAGS session, by going to options within the MegaAGS GUI and selecting 'Force PAL'. This should force all games to run in PAL mode until the next reset. I guess this essentially does the same thing as you mention above?

Running 'Force PAL' though makes no difference. The dropouts are very noticeable if you know the music, but if you don't it might be slightly more difficult to pick up. It's like one of the sound channels will momentarily drop out and miss a note or two.

A good one to try is Shufflepuck Cafe (WHDload 1.1 16-01-2005). When the music first kicks in on the initial screen (with the picture of the cafe from the outside) listen to the horn/siren effect that comes in after about 5 seconds. For me, running the WHDload in either PAL or NTSC via MegaAGS (Minimig configured as 68020 AGA), the siren will drop out on occasion, eg. one of the notes isn't played, same with other channels but is less noticeable.

But if I boot the game from a floppy in 68000 OCS, no such issues. Same with Hostages.

With Hostages (WHDload 1.2 28-04-2020) via MegaAGS (Minimig configured as 68020 AGA) maybe is a bit more subtle. The bass line channel often drops, sometimes the lead. It is always just momentary, eg a couple of notes on what I think is random channels. But always with a fair amount regularity.

If needed I can try to capture the effect if you are unable to replicate?

Ideally, what I need to do is get an image set up that works with a 68000 OCS/ECS configuration that can run WHDload games. I need to learn how to do this though. But if it doesn't exhibit the problem then, it's possibly a 68020 implementation issue and a bug with Minimig, but if it does, it is likely to be something related to the WHDload game.

Thanks!

[robinsonb5]

I think this is due to the CPU running too fast for those particular games.
The way a lot of games (and music routines) work with sound is that they set the audio pointer and sample length for a channel, then busy wait for a short time before setting the repeat position and length (for looped samples), or setting the pointer and length to a "null" 2-byte silent sample if not.
If the busy-wait finishes too soon, the second half of that process happens before the audio hardware has noticed the the first half, and the sample doesn't play (or for looped samples, skips straight to the repeated section.)

[movisman]

Hi there,

Thanks for the reply, I appreciate it.
I have just done some tests with WinUAE (unfortunately no access to a real Amiga), and I think you might be onto something there.

So, in WinUAE, if I select a preset expanded (4mb fast RAM) A1200 configuration and mount the same MegaAGS image i'm using on MiSTer, the problem still occurs with those games.

However, if I go to the 'chipset' options and enable 'cycle exact (full)' the issue goes away.

This seems to fall in line with what you are suggesting, because I understand when Minimig is set to 68020 mode, it is not 'cycle exact' and as a result maybe the CPU is running a bit too fast at times - would that be correct or something along those lines?

When I run Minimig in A500 configuration and boot the games from floppy - no issues. I guess because the 68000 implementation in Minimig is cycle exact already?

FYI, in WinUAE - even if I fall back to A500 configuration and load the game from a floppy, you get the same dropout effects with the music on those games - unless checking the 'cycle exact (full)' option there too. Again, it goes away after enabling.

So I guess if that's correct, the only permanent 'fix' would be if one day the 68020 implementation can be cycle exact on the Minimig core. Of course, the workaround is to use an A500 configuration for these games which prefer cycle exact timing.

One other thing, which I cannot replicate on WinUAE - if you boot one of these games from a floppy while Minimig is set to a 68020/AGA configuration, the sound is totally trashed in every way - random noises, samples, silence, all sorts of strangeness. But if I boot the same floppy on WinUAE in a similar A1200 configuration, no issues. I have literally no idea why this is. I only discovered it because I forgot to load my A500 configuration in Minimig when launching one of these games from floppy. Not sure if this could possibly be a bug or related to the implementation of 68020.

Thanks!