Test SW for YM sample playback, Hatari issues with ..

A forum about the Hatari ST/STE emulator - the current version is v2.0.0

Moderators: simonsunnyboy, thothy, Moderator Team

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2909
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Test SW for YM sample playback, Hatari issues with ..

Postby AtariZoll » Mon Nov 27, 2017 10:06 am

Something bothered me after that "communication problem" session, about sound playback errors in Hatari, mostly in TT mode. Somehow I came to conclusion that error is most likely present in earlier versions. But they were bad with PMMU emulation, so testing games in TT mode was pretty much troublesome.
I made what said: testing program, what is actually code taken from game intro, and is pretty much same as most of YM playback code, used mostly in games for ST. So, it works on TT and Falcon too (on it via APP to set STE bus mode) .
HELTER.ZIP

Ran it first in Hatari 2.0.0 - TT mode, and was bad, as it was bad with DM, Murder sample playback. CPU load in Win 7 was far below 100% .
In STE mode it was fine. CPU clock change affects nothing.
Then Hatari 1.7 0, TT mode - same as in 2.0.0 .
Then Hatari 1.4.0 , TT mode - and playback is good !

Conclusion: 1.4.0 is from 2010, 1.7.0 is from 2013 and 2.0.0 is from 2016 .
So, 4 years were passed and that playback bug is not noticed by anyone, or maybe did, but Hatari people refused to deal with it ? Whatever is behind it, things are that it was OK, and at some point it went bad, and 4, or more years passed, and it is still not on scheduling to correct. This reminds me about ACSI emulation error couple years ago: when I needed to argue with them what is faithful emulation, and why it must not work good with bad code :D

So, there is hope, I hope that Hatari team will came to mind, and finally fix this issue. That should be not so hard because it was good at some point, so they can compare sources of diff. versions. Or solve it in whatever way ...
We all want better emulation, and there is visible progress in many aspects with Hatari. What did not progress in my opinion is attitude toward users, especially Windows users. That may be reason for poor feedback, and not fixed errors in emulation over years.
Now, one thing more: if Hatari team has such errors in very low priority, then please tell it us. Communicate properly - nobody expects that you will jump on it immediately. What I experienced was very bad communication, bad attitude - ignoring whole issue, not reading carefully, if at all everything written, then talking about life etc.
And 1 thing more, just came to mind: there is still unresolved admission of bug with STE DMAA playback in DM (modded) in TT mode. But I will not make test program for it.
You do not have the required permissions to view the files attached to this post.
Negative feedback has usually positive effect.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Test SW for YM sample playback, Hatari issues with ..

Postby npomarede » Mon Nov 27, 2017 10:49 am

Hi

there's no will to hide this error or to not fix it or to set it to low priority ; believe it or not, but you're the first one to report it over the years.
It just seems that not so many people use TT emulation, or at least that they don't use it to play games, so this problem went unnoticed and was never reported anywhere in hatari mailing list or here in atari-forum.
That's why it's always interesting to get input from users having different uses of an emulator (coding, watching demo, playing games, doing MIDI, ...)
We try to keep a list in the doc/ directory of all known issues with emulation problem, if it's not there, then it's likely that we didn't see it and no one reported it to us either.

Anyway, I found the cause for it this week end, writing my own test program (so yes, you're not the only one spending time on this :) ), this is not an MFP issue or a direct YM emulation issue, it's a combination of several cases where original machines (TT or Falcon) had a cpu clock of 32 or 16 MHz. At one point, some numbers of sample are not correctly computed, but this is only noticable when playing digi sound with the YM (and even so, it will depend on the sampling rate :) ). If you just play "normal" YM music, sound emulation will be good.

As for the sound working in much older Hatari version like 1.4.0, that's a coincidence, the emulation used back then was different/not as accurate, but it had the "advantage" of hiding this problem. So, there's no code to re-use from older version, I just need to fix the current version with new code.

As for windows, we're still waiting for people who use Windows and can code for it to join us and help maintaining a Windows port. We have some OSX ports, some Android ports, some Raspberry ports and more, but it happened because people on these platforms had interested in such ports and wanted to participate in it.
Currently, there's no Windows coder in the (short) list of Hatari devs.

Nicolas

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2909
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Test SW for YM sample playback, Hatari issues with ..

Postby AtariZoll » Mon Nov 27, 2017 11:37 am

What made me think that it is MFP Timer issue is that in some cases YM sample playback was too fast + too high pitch. With this test it was not too fast, just pitch was too high. And lowering CPU clock even to 8MHz did not change significantly.
Considering need for Windows coder - that's certainly hard part. It may be partially because there are other emulators for Windows, while there is no choice for mentioned platforms. So, motivation level is different.
And there is totally only 1 man who deals with Steem improvement at moment, so it is not that good with other emulators too :-)
Personally, I would like Hatari version for Windows solved in fashion how Steem did it - they made separated GUI for Windows and for Linux, and it still works fine, even with latest versions. Actually, I did something similar - program Drive Imager (for accessing mass storage, makin images, file transfer, etc) - I made Win v. , then Linux v. But not so smart as Steem authors. In purpose to make it easier, and considering my poor coding knowledge on Linux I went on KDeveloper - because it gave big help right in GUI design . The result is that program just work not on new, popular Linux releases, actually did not work even on later Mandrivas. I should go on pure X GUI . I was aware then about diverse cross compatible solutions, like what is used in Hatari, but did not like idea. GUI is what changes more than CPU, C code . Some very old Win. SW acts weird in newer Wins, considering GUI . File selector is one of things that changes a lot. At least in Win old ones still work. In K-Desktop (what was actually imitation of Windows look, way of usage) older work not properly - that's main reason why my SW worked not in later versions. OK, enough of stories for today :-)
I'm glad that we progressed here. It would be nice to do some things more for Hatari, but my C coding is not good, I even don't like C at all. Not to mention zillion other things what I planned. Although, if things will be better than now, and will have lot of time, I could go in special Win GUI design + supporting code for Hatari. I guess that it will not need some high level C coding knowledge.
Negative feedback has usually positive effect.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1558
Joined: Sun Jul 31, 2011 1:11 pm

Re: Test SW for YM sample playback, Hatari issues with ..

Postby Eero Tamminen » Mon Nov 27, 2017 10:40 pm

Regarding Hatari v1.4. It was still using the old UAE CPU core, not the new WinUAE CPU core.

The old UAE CPU core completely lacks emulation for following 030 features:
- instruction & data cache
- 32-bit access
- MMU

And it was also otherwise much more inaccurate. Because of these omissions, it was/is significantly faster than the current, more accurate emulation.

Note that more accurate emulation can be less compatible with some software, because some things worked earlier just by lucky co-incidence. Sometimes to go forward a step, developers may need to take first a few steps backwards (change design and write a lot of new code), or at least it can appear like that to end users. :-)

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Test SW for YM sample playback, Hatari issues with ..

Postby npomarede » Fri Dec 01, 2017 2:27 pm

npomarede wrote:Anyway, I found the cause for it this week end, writing my own test program (so yes, you're not the only one spending time on this :) ), this is not an MFP issue or a direct YM emulation issue, it's a combination of several cases where original machines (TT or Falcon) had a cpu clock of 32 or 16 MHz. At one point, some numbers of sample are not correctly computed, but this is only noticable when playing digi sound with the YM (and even so, it will depend on the sampling rate :) ). If you just play "normal" YM music, sound emulation will be good.

Hi
the changes for this YM sample playing problem on TT/Falcon were pushed to the Hatari devel tree.
I tested with several programs, using STF/STE/TT/Falcon mode in 8/16/32 CPU and YM samples play correctly in TT/Falcon.
I tested the programs you posted. They now sound good, but I noticed a few things :
- In Helter, there's a problem when playing on Falcon, because the YM sample routine uses the YM shadow registers that don't exist on Falcon. So only VolA and VolC are modulated, never volB, which gives a very noisy result (but maybe it's not your latest replay version ?)
- In Star Trek intro, the sound is very low in STE/TT mode, this is because you set left volume to 4 using the microwire interface. Only right output plays at normal volume, so in the end the total volume is half what you hear in STF or Falcon mode. I don't know if it's on purpose ?

Nicolas

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2909
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Test SW for YM sample playback, Hatari issues with ..

Postby AtariZoll » Fri Dec 01, 2017 2:59 pm

npomarede wrote:
npomarede wrote:Hi
the changes for this YM sample playing problem on TT/Falcon were pushed to the Hatari devel tree.
I tested with several programs, using STF/STE/TT/Falcon mode in 8/16/32 CPU and YM samples play correctly in TT/Falcon.
I tested the programs you posted. They now sound good, but I noticed a few things :
- In Helter, there's a problem when playing on Falcon, because the YM sample routine uses the YM shadow registers that don't exist on Falcon. So only VolA and VolC are modulated, never volB, which gives a very noisy result (but maybe it's not your latest replay version ?)
- In Star Trek intro, the sound is very low in STE/TT mode, this is because you set left volume to 4 using the microwire interface. Only right output plays at normal volume, so in the end the total volume is half what you hear in STF or Falcon mode. I don't know if it's on purpose ?
Nicolas

Thanx. I need to check all it when will have time. Yes, I noticed that it is more noisy on Falcon, but that's usually so. Some things left not fixed in many cases - main goal is to make game playable. I don't remember seeing code what uses shadows over address $FF8804 with shorter writes . There are some with movem, and such are patched for Falcon. Indeed, need to check some again.

Star Trek: It must be my bug in code, will look after ... Thanx again.
Negative feedback has usually positive effect.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Test SW for YM sample playback, Hatari issues with ..

Postby npomarede » Fri Dec 01, 2017 3:54 pm

I didn't save the traces for Helter/Falcon, but IIRC it was using 1 movep.l for volA/volB followed by 1 movep.w for volC, so that's why volB is never written and sound is noisy.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2909
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Test SW for YM sample playback, Hatari issues with ..

Postby AtariZoll » Fri Dec 01, 2017 7:59 pm

OK, I fixed Star Trek microwire code, and it is now uploaded. From some reason I used there my old, first microwire code, what is replaced with better, and I guess correct long time ago.
Considering that Falcon sample playback via YM, I can say that this is something extremely weird. I tested on real HW and it is very noisy with STE bus emulation on, and long movep . Patched code with 3x movep.w and some swaps sounds fine, still much more noise than on ST, but that's what Falcon can with it, I guess. So, what is purpose of that, so called STE bus emulation ? Only to prevent bus error when accessing $FF8804-$FF8807 ? But writes to $FF8804-$FF8807 do nothing ??? What a nonsense ! Especially as is called emulation - ah, proper one would be called simulation :lol:
Negative feedback has usually positive effect.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1558
Joined: Sun Jul 31, 2011 1:11 pm

Re: Test SW for YM sample playback, Hatari issues with ..

Postby Eero Tamminen » Fri Dec 01, 2017 9:17 pm

Looking at Hatari sources, the STE bus emulation indeed just removes bus errors for several HW register address ranges, nothing else. But it's a lot more than just that address range you indicated.

If you think about how this would be implemented in HW, it's fairly cheap way to get a bit more compatibility (= avoid crashes). What else *bus* emulation would be than whether certain bus values generate error?

If it would actually implement the HW registers, wouldn't it be called *register* emulation? And if they were actually implemented, what would be the point of not having them working all the time? :-)

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2909
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Test SW for YM sample playback, Hatari issues with ..

Postby AtariZoll » Fri Dec 01, 2017 10:07 pm

Hatari emulates it correct. I meant - and that was clear, because I said that tested on real HW - that it is Falcon design nonsense.
Term 'bus emulation' was stupid always for me. We need emulation of STE glue chip, not bus emulation only . Then sound would be good.
The whole case seems for me as some late stage forced fix, done in rush. + what is bus emulation really ? - bus in Falcon is basically same as in STE. Address range of peripheral is what is here emulated, but only that, not necessary actions.
I don't care what range it covers - fact is that no sound in lot of games which use movem for faster sound code. I expected that at least it activates one shadow, and there writes to YM - just because lot of SW using that movep.l . They should simply make it that it activates CE line for YM. Just preventing bus error is pathetic. 2 gates more, and would be perfect. For me another sad design flaw.
Negative feedback has usually positive effect.


Social Media

     

Return to “Hatari”

Who is online

Users browsing this forum: No registered users and 2 guests