Author Topic: Request for real hardware tests  (Read 1018 times)

XL2

  • Sr. Member
  • ****
  • Posts: 350
  • Karma: +81/-1
    • View Profile
Re: Request for real hardware tests
« Reply #15 on: July 05, 2018, 10:22:32 pm »
Here is from my readme for a (someday) to be shared engine :

*********************************************
Z-TREME ENGINE AUDIO IMPLEMENTATION - README
2018-04-05
*********************************************

Using audio is a bit tricky and it might take you a while to get it right.
Most homebrew apps simply use PCM audio from the work ram and DMA it in the sound RAM buffer area.
The issue with this is that it wastes precious RAM, adds CPU overhead and hogs the B-BUS with DMA transfers (the same bus that connects the SH2 CPUs with the VDP1 and VDP2).

The best solution is to use the audio processors and the audio RAM with MIDI sequences - but instead of using sequences, we will use direct MIDI commands to the sound driver.
Sadly, I won't have time in the near future to write an app to replace the Sega Sound Tools, so right now the solution is tricky and not user-friendly.
All the Sega Sound Tools apps are for old 68K Macs and they require extra hardware (like a sound box).
By using an emulator, we can do almost everything we need for sound effects.

The solution is the following :

1) Download an old Mac emulator (68K). I use BASILISK II : https://basilisk.cebix.net/

2) Set your MAC OS 7 ROM

3) Download the Sound Tools : https://antime.kapsi.fi/sega/docs.html

4) Make sure you have .AIFF (Big endian) audio that you want to use. It will all be put in sound RAM (512 KB), so make sure you have no more than about 400 KB.

5) Use the Tone Editor to create your tone data : https://antime.kapsi.fi/sega/files/ST-068-R1-042594.pdf
   You can also look at the SGL tutorial documentation (Page 2-8) to see how to use it : https://antime.kapsi.fi/sega/files/ST-237-R1-051795.pdf
   Note that you should use only 1 bank (or switch banks ingame) and keep all the sounds in different layers.
   YOU NEED to offset the base pitch! Your first value should be C4 (60) for both beginning and end in the layer section.
   Each subsequent sound should increase that value by 1.
   Make sure you change the base pitch with the same increase. If all your audio is 22,050 khz, your base pitch should be 72 or 84 for 11,025 khz.
   Follow the SGL guide closely as it's pretty complicated the first time!

6) Create your MAP file : you can use the Sound simulator to generate one.
   Look again at the SGL tutorial documentation (Page 2-29)

7) Put your files (MAP, Sound driver and Tone data) in your CD folder, under the SOUND subfolder.

8) Tweak your Z-TREME Engine ZT_AUDIO.c file if you want to use different names, or just use the default names for your files and replace them.
   Make sure that you modify the length of the files as needed.

9) Ingame, just call the sound function when you need to play a sound.
   If you have more than 16 sounds, you will need to do a bank change depending on where your sound is.
   The sound function will stop the previous sound (say sound 60) if the same sound (again sound 60) is called twiced. By using MONO sound, you can play the same sound twice at the same moment, else it will be once only.
   If you wish to have the same sound played on several channels, just remove the MIDI stop command from the ZT_AUDIO.c file, but make sure you clear the channels manualy as needed.
   I suspect that by using the wave editor you might be able to put an end comand at the end of the sound, so that the channel clears itself, but I haven't tried it yet.
   The sound will stop on it's own, but the channel won't be cleared as it is now, which isn't a very huge deal.

Enjoy!

---------
For the audio functions :

#include        "ZTE_DEF.H"
#include        <SEGA_GFS.H>
#include        <SEGA_SND.H>
//#define         SoundSeqBuf      0x25a0b000
static   CdcPly   playdata;
static   CdcPos   posdata;

void loadSndDrv(void)
{
    Sint32 fid;
    void * ptr = (void*)LWRAM;
    fid = GFS_NameToId((Sint8*)"SDDRVS.TSK");
    GFS_Load(fid, 0, (Uint32 *)ptr, 26610);

    ptr=(void*)(LWRAM+26610+2);
    fid = GFS_NameToId((Sint8*)"MAP.BIN");
    GFS_Load(fid, 0, (Uint32 *)ptr, 10);

    SndIniDt sndInit;
    SND_INI_PRG_ADR(sndInit)=(Uint16*)LWRAM;
    SND_INI_PRG_SZ(sndInit)=(Uint16)(26610);

    SND_INI_ARA_ADR(sndInit)=(Uint16*)(LWRAM+26610+2);
    SND_INI_ARA_SZ(sndInit)=(Uint16)(10);
    SND_Init(&sndInit);
}

void loadSndData(void)
{
    SND_ChgMap(0);
    Sint32 fid;
    void * ptr = (void*)LWRAM;
    fid = GFS_NameToId((Sint8*)"TONE.BIN");
    GFS_Load(fid, 0, (Uint32 *)ptr, 352514);
    SND_MoveData((Uint16*)ptr, (Uint32)352514, SND_KD_TONE, 0);
}

/** TODO : Change this implementation for something better and implement MIDI audio **/
void ztPlayCDDA(Sint32 startTrack, Sint32 endTrack)
{
    CDC_PLY_STYPE(&playdata) = CDC_PTYPE_TNO;
    CDC_PLY_STNO(&playdata) = startTrack+1;
    CDC_PLY_SIDX(&playdata) = 1;  //First track ID
    CDC_PLY_ETYPE(&playdata) = CDC_PTYPE_TNO;
    CDC_PLY_ETNO(&playdata) = endTrack+1;
    CDC_PLY_EIDX(&playdata) = 1;
    CDC_PLY_PMODE(&playdata) = CDC_PM_DFL + 15;
    CDC_CdPlay(&playdata);
}

void ztStopCDDA( void )
{
    CDC_POS_PTYPE( &posdata ) = CDC_PTYPE_DFL;   /* Stop Music. */
}

/** NOTE : The current function doesn't clear the channels after the playback, only after you play the sound again. There must be a setting in the tone editor I missed, but for now we just clear it first... **/
void ztPlaySound(Uint8 SFX) //The direct Midi control is as follow : SndRet SND_CtrlDirMidi(SndSeqNum, SndSeqPri, Uint8 MidiCommand, Uint8 MidiChannel, Uint8 pitch, Uint8 velocity);
{
    SND_CtrlDirMidi(0x02, 0x00, MidiNoteOff, Channel1, SFX, 127); //Stop the note (clears the channel)
    SND_CtrlDirMidi(0x02, 0x00, MidiNoteOn, Channel1, SFX, 127); //Plays the note (it will stop playing once it's done, but won't clear the channel)
}

void ztInitSound()
{
    /*
    Sound map structure :
    Byte 0 : 0, using 3 bits for a sequence : 0x0K where K = bank ID, with 4 bits (so max 16 banks per map)
    Bytes 1, 2 and 3 : first 4 bits are unused, the remaining bits are the start of the bank's adress
    Byte 4 : first bit is 0, the rest is unused AFAIK
    Byte 5, 6 and 7 : area size
    */

    ztCDsetDir("SOUND");
    {

        loadSndDrv();
        loadSndData();

        CDC_CdInit(0x00,0x00,0x05,0x0f);

        SND_ChgMix(0, 0);
        SND_SetTlVl(15);

        SND_CtrlDirMidi(0x02, 0x00, MidiCtrlChg, 0x01, 0x20, 0x00);
        SND_CtrlDirMidi(0x02, 0x00, MidiPrgChg, 0x01, 0x00, 0x00);  //If you have more than 1 voice, you will need to do a program change at some point
        SND_SetCdDaLev(6,6);
        SND_SetCdDaPan(0,0);
    }
    ztCDsetRoot();
}

---
Of course, you will need to adapt this code for your needs.
Say you want to play the sound no 0 in your map, just call :
   ztPlaySound(60);


ponut64

  • Full Member
  • ***
  • Posts: 181
  • Karma: +13/-0
    • View Profile
Re: Request for real hardware tests
« Reply #16 on: July 05, 2018, 10:33:07 pm »
Thank you for the tutorial. In time, I'll get to that.
« Last Edit: July 05, 2018, 10:35:20 pm by ponut64 »

ponut64

  • Full Member
  • ***
  • Posts: 181
  • Karma: +13/-0
    • View Profile
Re: Request for real hardware tests
« Reply #17 on: July 07, 2018, 11:08:01 am »
Hey guys,

I've got one last tentative request for some tests. I've used up my last pocket CD-R (dont worry I can get more).
This isn't urgent by any means, but I do have another case of hardware-emulator divergence, but this is in a way I think I already understand.

In the meantime, I have "fixed" (forged a workaround for) the static problem by injecting my own static (using slSoundRequest) and setting its volume to zero.
I've also set this little test up so it will load the model file, too.

The issue is, when it's playing the music, my matrix transforms are all screwed up! My guess is it won't do this because when the game code is stuck in the music playback loop, it doesn't have access to the slave CPU to perform the transformations. That, or DMA for the music is just blocking all access to VDP1. Which would suck. XL2 would know more about that.
Confusingly, this is another thing that only happens on real hardware. No emulators replicate it.

But, you don't have to test this one for me. You guys helped a lot the first time. Mostly I want to know if the static is gone. Then I shouldn't need more tests like this.
http://www.mediafire.com/file/2rlrb8zbll9gead/smelly.zip
I wonder how many times XL2 has had to deal with emulator-hardware divergence? ^^
« Last Edit: July 07, 2018, 11:13:57 am by ponut64 »

XL2

  • Sr. Member
  • ****
  • Posts: 350
  • Karma: +81/-1
    • View Profile
Re: Request for real hardware tests
« Reply #18 on: July 07, 2018, 03:29:50 pm »
Can you show me the problem?
I won't have access to my Saturn for a while.
About the matrix issue, how big is it?
A couple of vertices?
If so, move your vertices to high ram (just set your model's pdata pntbl pointer to a global array of say 200 vertices, the model functions will just overwrite the data anyway).
Your pcm functions are also on low ram?
Make sure the alignment is right.
There is a SGL document somewhere that explains issues with audio stored in low ram, again because - if I'm not mistaken - you can't do scu dma from low ram.
Make sure your audio buffer is in high ram.
Low ram is slower and has many restrictions as it's not directly linked with the scu.

ponut64

  • Full Member
  • ***
  • Posts: 181
  • Karma: +13/-0
    • View Profile
Re: Request for real hardware tests
« Reply #19 on: July 07, 2018, 07:55:09 pm »
Okay, I'll get a cam out and record it real soon. It's entirely reasonable to use HIMEM instead of LWRAM as the buffer so next time I have some CD-R I will try that.
It's real simple. The model/polygons matrix just isn't getting transformed at all. No rotation. In time I'll see what using HIMEM does.

Here is (bad) video:
https://youtu.be/giMNu6vDnlc

Here's an updated code set that uses HIMEM (actually an offset at the end of HIMEM as HIEND - (8 * 2048) ) as the sound buffer instead of LWRAM:
http://www.mediafire.com/file/4351n36yygvgcm3/stelco.zip
[Use this if you would like to see if the static suppression works on your console)

Mostly bugging you about the matrix issue since I don't have any suitable CD-Rs left and I have to wait a week for new ones to get here :)
Thank you for the help.
In the meantime I can move on to fixing up to get variable animation interpolation.
« Last Edit: July 07, 2018, 08:48:05 pm by ponut64 »

XL2

  • Sr. Member
  • ****
  • Posts: 350
  • Karma: +81/-1
    • View Profile
Re: Request for real hardware tests
« Reply #20 on: July 07, 2018, 09:41:36 pm »
What do you mean about variable interpolation?
About the real hardware, I don't even have access to real hardware for now so I can't help you for now.

ponut64

  • Full Member
  • ***
  • Posts: 181
  • Karma: +13/-0
    • View Profile
Re: Request for real hardware tests
« Reply #21 on: July 07, 2018, 09:54:42 pm »
Well, you did help me, knowing that I should be putting sound stuff in high memory (if not sound memory).

Variable interpolation would be changing an animation so that each keyframe can have a different amount of frames interpolated between them.
It should just require some manipulation of the current interpolation code to skip forward a certain number of interpolated frames, or something like that, that's tomorrows job.
I should get my next stack of CD-Rs next week so there's no rush, I will have more things to test by then anyway.
« Last Edit: July 07, 2018, 10:26:41 pm by ponut64 »

XL2

  • Sr. Member
  • ****
  • Posts: 350
  • Karma: +81/-1
    • View Profile
Re: Request for real hardware tests
« Reply #22 on: July 08, 2018, 12:53:05 am »
Well, I'm already doing that in Z-treme, I could try to share it soon enough.

 

Sitemap 1 2 3 4 5 6 7 8 9 10 
SMF spam blocked by CleanTalk