[hatari-devel] New STE DMA audio emulation
Nicolas Pomarède
npomarede at corp.free.fr
Mon Jul 4 00:33:10 CEST 2011
Le 03/07/2011 23:34, Eero Tamminen a écrit :
> Hi,
>
> On perjantai 01 heinäkuu 2011, Nicolas Pomarède wrote:
>> Please test this new version with all your favorite STE programs. For
>> great results, don't forget to run Hextracker which gives really clear
>> output even with 7 voices or more.
>
> Sounds is much better now.
>
> Btw. Have you noticed that Hextracker mouse doesn't track host mouse
> properly in windowed mode? After using Hextracker for a while, I cannot
> anymore move mouse cursor to a place where I could click on "Play"...
hello,
No, I didn't really use the tracker, except for starting a mod.
But I noticed that if I lock the mouse in windowed mode 'alt+m', after a
while the mouse was unlocked again and could exit Hatari's window (this
seems to be triggered when loading a module and having the tos'
fileselector displayed, but I'm not sure if there's a relation ?)
>
> Some other notes about sound:
> * R0x doesn't anymore give messages mentioned in compat list:
> "DMA snd: Illegal buffer size (from 0x0 to 0x0)"
The error (which is in ROx) is still there, it's just that I don't print
an error anymore as this case is handled by the dma's emulation.
> * Paradox Xmas-2004 scroller music has strange skips
I don't hear them ; do you mean the dma sound or the ym sound, what part
of the demo is that in ?
> * In many demos and some games STE sound has much less volume
> than ST sound (e.g. PowerUp game supports both "ST" and "STE"
> sounds and STE one has maybe half the volume of ST one)
DMA's volume should not have changed in the modifications I made, I
think it was already like that before.
But it's true the lowpass filter is lowering the volume a little ; David
Savinkoff certainly knows this better than me (I don't have an STE to
compare the volume difference).
>
>> In order to fix this, I added a new file clocks_timings.c ; the purpose
>> of this file is to put all the hardware's clocks informations for all
>> emulated Atari machines in a single file. This file then provides some
>> functions to compute the exact values of VBL per sec, length of a VBL in
>> micro sec, ...
>
> Some comments on the changes (from newer to older):
>
>
> * Is the ifdeffed "old_code"& "olddma"& "nofifo" stuff still needed?
>
> There were also couple of compiler warnings:
> ---
> [ 56%] Building C object src/CMakeFiles/hatari.dir/dmaSnd.c.o
> src/dmaSnd.c:354: warning: ‘DmaSnd_FIFO_ReadByte’ defined but not used
> src/dmaSnd.c:372: warning: ‘DmaSnd_FIFO_ReadWord’ defined but not used
> ---
Those are parts of the "I will clean the code once no one reports
regression in new dma code" :)
>
> * http://hg.berlios.de/repos/hatari/rev/df8c0a09d846
>
> -> It's a bit ugly to do init on uninit phase, but I think it's also best
> to do the re-init if machine needs reset (not just when machine type
> changes), because that takes into account also changing e.g. TV to mono
> monitor (HZ change).
What phase is "uninit" ? ClocksTimings_InitMachine is called when
machine changes, which seems enough to me, I don't see what you call
"uninit".
Calling ClocksTimings_InitMachine when video freq change is not
necessary, the machine's clocks don't depend on the chosen video freq
(that's why video freq is a parameter of some other functions in
clocks_timings.c)
>
> -> ClocksTimings_InitMachine() call doesn't belong to dlgSystem.c,
> it should be done where the changes are applied (why calling
> it in change.c wouldn't be enough?)
It's possible I left some redundant calls, I will check that.
>
>
> * http://hg.berlios.de/repos/hatari/rev/065cb494bb3f
>
> -> "the number of cpu cycles per second is not a multiple of the number
> of cpu cycles per second."
> - did you mean instructions?
I meant "VBL" :)
> -> There are several functions like this:
> ----
> Uint32 ClocksTimings_GetVBLPerSec ( MACHINETYPE MachineType , int
> ScreenRefreshRate )
> {
> Uint32 VBLPerSec;
> /* Upper 8 bits are for int part, 24 lower bits for float part */
>
>
> VBLPerSec = ScreenRefreshRate<< 24;
> /* default rounded value */
>
> if ( RoundVBLPerSec == false )
> {
> /* STF and STE have the same numbers of cycles per VBL */
> if ( ( MachineType == MACHINE_ST ) || ( MachineType ==
> MACHINE_STE ) )
> VBLPerSec = ( (Sint64)MachineClocks.CPU_Freq<< 24 )
> / ClocksTimings_GetCyclesPerVBL ( MachineType , ScreenRefreshRate );
>
> /* For machines where cpu freq can be changed, we don't know
> the number of cycles per VBL */
> /* -> comment code to keep the default value from above */
> //else if ( ( MachineType == MACHINE_MEGA_STE ) || (
> MachineType == MACHINE_TT ) || ( MachineType == MACHINE_FALCON ) )
> // VBLPerSec = ScreenRefreshRate<< 24;
> }
>
>
> return VBLPerSec;
> }
> ----
>
> Why not just do something like this:
> ----
> Uint32 ClocksTimings_GetVBLPerSec ( MACHINETYPE MachineType , int
> ScreenRefreshRate )
> {
> if ( RoundVBLPerSec == false )
> {
> /* STF and STE have the same numbers of cycles per VBL */
> if ( ( MachineType == MACHINE_ST ) || ( MachineType ==
> MACHINE_STE ) )
> return ( (Sint64)MachineClocks.CPU_Freq<< 24 ) /
> ClocksTimings_GetCyclesPerVBL ( MachineType , ScreenRefreshRate );
> }
>
> /* Upper 8 bits are for int part, 24 lower bits for float part */
> return ScreenRefreshRate<< 24;
>
> }
> ----
> ?
I did this on purpose to emphasize the fact that MEGA_STE, TT and FALCON
should eventually be handled with their own special case ; so I prefer
leaving a commented code that does nothing to make it clear that those
machines need a customised value too.
Nicolas
More information about the hatari-devel
mailing list