[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