Jo Engine Forum

Sega Saturn Development => General Jo Engine Help => Topic started by: ponut64 on July 05, 2018, 07:38:21 am

Title: Request for real hardware tests
Post by: ponut64 on July 05, 2018, 07:38:21 am
Hey guys,

I just want to know if you run this ISO if the sound eventually annihilates your sanity (with static, of course).
It would only ever do this on real hardware. You can test emulators if you want, but about all you will get are some skips and the end of the file not terminating the sound.

http://www.mediafire.com/file/gvvevvruvr4cwnb/sl_coff.iso
----------------------------------------------------------------------------------------------------------------------------------------------
"But!" you may ask, "what is this?!"
This is streamed PCM playback of 30720 Hz (30.72KHz) audio using SGL, with the sound effect itself being copied straight to the PCM playback buffer.
Is this useful? Hell man, I don't know! But this actually plays sound, so it's what I have to work with because I cannot for the life of me get SBL to play any sound at all.

"What is the problem?"
I'm not sure. It could be a limitation of SGL. It could be a hardware limitation that SBL circumvents. It could just be my Saturn. But after so long of playing back the file, static gets thrown into the mix and I do not know how to suppress it.
Theories:
- SGL PCM playback pointer moves to a region of memory that has bad data
- SGL PCM playback pointer eventually starts playing back the incomplete data in LWRAM as its being copied
- SGL PCM playback pointer eventually leaves the Saturn's entire possible memory map range, returning NULL data
- A-bus and B-bus DMA processes eventually cross-corrupt
- SGL PCM playback library eventually attempts to mux PCM sound outputs, resulting in garbage added
Things I have tried:
- Attempt to move SGL playback start pointer (You cannot, slPCMOn will not change its parameters once started)
- Using NULL for PCM data region (I don't want it to point to any region, since I am copying the PCM data directly to the PCM buffer) (Result: Garbage)
- Using end-of-memory for PCM data region (Result: Crash)
- Different DMA modes
- Not much else (only one song and bitrate on real hardware)
MAJOR ISSUE:
No emulators replicate this problem.

Relevant code:
Code: [Select]

#ifndef __AUDIO_H__
#define __AUDIO_H__

#define SECTOR_SIZE     (2048)
#define RING_BUF_SIZE  (2048*10)
#define PCM_ADDR  ((void*)0x25a20000)
#define PCM_SIZE  (4096*2)

#define SMP_1TASK_SAMPLE (1024)
#define SMP_TR_MODE_CD (PCM_TRMODE_CPU)
#define SMP_LOAD_NUM (10)

#define PCMRAM (631734272)
#define LWRAM (2097152)
#define HIMEM (100679680)
//(31122)
#define S4410KHZ     (0)
#define S3780KHZ     (31451)
//THIS IS TESTED
#define M3072KHZ     (31118)
//
#define S2205KHZ     (30720)
#define S1920KHZ (29431)
#define S18900HZ     (29404)
#define S1600KHZ     (29134)
#define S1536KHZ     (29074)
#define S1100KHZ     (27643)
#define S0800KHZ     (27086)


extern jo_sound     main_pcmfx;
extern jo_sound music_pcmfx;

//Functions go here
void pcm_music_play(void(*sysframe)(void));
void* load_pcm(Sint8* filename, const jo_sound_mode mode, jo_sound *sound, void * workAddress);
void sound_on_channel(jo_sound * const sound, const unsigned char channel);
#endif



//Modified Jo Engine functions
jo_sound music_pcmfx;
jo_sound main_pcmfx;

static PCM _pcm[JO_SOUND_MAX_CHANNEL] =
{
    {(_Stereo | _PCM16Bit), 0, 127, 0, 0x0, 0, 0, 0, 0},
    {(_Stereo | _PCM16Bit), 2, 127, 0, 0x0, 0, 0, 0, 0},
    {(_Stereo | _PCM16Bit), 4, 127, 0, 0x0, 0, 0, 0, 0},
    {(_Stereo | _PCM16Bit), 6, 127, 0, 0x0, 0, 0, 0, 0},
    {(_Stereo | _PCM16Bit), 8, 127, 0, 0x0, 0, 0, 0, 0},
    {(_Stereo | _PCM16Bit), 10, 127, 0, 0x0, 0, 0, 0, 0},
};

static Sint16 music_frames = 0;
static Sint16 music_sectors = 0;

void pcm_music_play(void(*sysframe)(void))
{
//DEBUG INFORMATION
Sint8* filename = "B.PCM";
    music_pcmfx.mode = JoSoundMono16Bit;
//This function is supposed to play a mono PCM sound effect constantly.
//Some LWRAM is consumed in the process (10 sectors / 20KB).
    void* pcm = LWRAM;
void* write_buffer = LWRAM;
Sint32 fid = GFS_NameToId(filename);
GfsHn gfsm = GFS_Open(fid);
Sint8 fetch_timer = 0;
Sint32 fsize;
Sint32 nsct;
Sint32 stat;
Sint32 rdsize;
//Rate of data reading
Sint16 rt_step = (2 * 2048);
Sint16 rt_sector = 2;
//Get sectors
//HEY! SBL DOCUMENTATION IS WRONG! THIRD ITEM nzect IS GFS SECTOR COUNT. SECOND ITEM IS CD SECTOR SIZE.
//TIP: MEMORY MUST BE MANAGED IN SECTORS (2KB)
GFS_GetFileSize(gfsm, NULL, &nsct, NULL);
GFS_GetFileInfo(gfsm, NULL, NULL, &fsize, NULL);
//This determines playback time?
music_pcmfx.data_length = (fsize);
_pcm[(int)0].mode = (Uint8)music_pcmfx.mode;
_pcm[(int)0].pitch = M3072KHZ;
//How many frames are we reading?
if(rt_step < fsize){
music_sectors = (fsize + (rt_step - 1))/(rt_step);
}
jo_printf(0, 18, "(%i)", fsize);

GFS_SetReadPara(gfsm, rt_step);
GFS_SetTransPara(gfsm, rt_sector);
GFS_SetTmode(gfsm, GFS_TMODE_CPU);
//Loading follows
GFS_NwCdRead(gfsm, (10 * 2048));
for( ; music_frames <= music_sectors ; ){
//Copy memory from work area buffer directly into the PCM stream buffer
slDMACopy(write_buffer, PCMRAM, (8 * 2048));
slDMAWait();
//Very tightly timed! Not even timed right! Saturn appears to playback sounds faster than advertised; check pitch?
fetch_timer++;
if(music_frames < 4){
GFS_NwFread(gfsm, rt_sector, write_buffer + (music_frames * rt_step), rt_step);
}
do{
sysframe();
slSynch();
if(music_frames < 4){
GFS_NwExecOne(gfsm);
GFS_NwGetStat(gfsm, &stat, &rdsize);
}
jo_printf(0, 7, "(%i)", music_frames);
jo_printf(7, 7, "(%i)", music_sectors);
jo_printf(0, 11, "(%i)", rdsize);
jo_printf(10, 11, "(fetched filesize)");
}while(stat != GFS_SVR_COMPLETED && rdsize < rt_step);
if(music_frames < 4){
music_frames++;
}
if(music_frames == 4 && fetch_timer == 8){
music_frames = 0; fetch_timer = 0;
}
slSndFlush();
music_pcmfx.data = pcm;
jo_printf(0, 0, "(%i)", pcm);
music_pcmfx.current_playing_channel = 0;
//HEY! slPCMOn does -NOT- accept changes to the data address during playback. IT WILL DO NOTHING.
slPCMOn(&_pcm[(int)0], music_pcmfx.data, music_pcmfx.data_length);
slPCMParmChange(&_pcm[(int)0]);
}
GFS_Close(gfsm);
}


Title: Re: Request for real hardware tests
Post by: LackofTrack on July 05, 2018, 09:11:17 am
I tested the iso on my Japanese Model 2. On all the 3 test tries I did, at about 1 minute and 42 seconds in static began to appear in the song.
Also the song doesn't stop correctly and keeps repeating the last second of itself. A brief look at the code and it looks fine.
I wonder why the problem occurs only on real hardware.
Title: Re: Request for real hardware tests
Post by: ponut64 on July 05, 2018, 09:21:42 am
Stopping the song is easy that's not a problem. More to my point since I have the static issue, I don't feel like fixing the song ending.
That static though, that's a problem!
Thanks for testing. Now I know it's not just my Saturn. My real concern is testing a fix for it... I only have so many CD-Rs...

By the way, in my experience, the most accurate emulator for SGL PCM testing is Bizhawk (Saturnus based).
The other emulators do not playback the stream at the correct pitch rate.
Title: Re: Request for real hardware tests
Post by: SaturnTeam on July 05, 2018, 05:21:59 pm
Which Saturn version are you testing it on? Can you give me the model number?
Title: Re: Request for real hardware tests
Post by: ponut64 on July 05, 2018, 06:34:01 pm
Saturn MK-80 000 A
SERIAL AE66078526
Manufactured September 1996 MALAYSIA
"US Model 2"

DO NOTE: My Saturn is a strange one.
Internally, the plastic shell has the hook for the Model 1-type CD open sensor, as well as what looks to be mounting points for the Model 1 CD activity light acrylic light tube.
The CD Drive is distinctly a later model Saturn. The CD OPEN sensor is the gear-switch type (no cable). The CD door has a different plastic finish than the rest of the console (it's a darker black).
Only one or two out of the five screwholes on the bottom actually screw in to the top half of the Saturn; I'm pretty sure the top half has 6 screw holes actually in it, and I'm afraid if I pick the console up wrong that I will rip the top off. There's also some other strange cavity in the bottom of the console that shines onto the back of a PCB on the right side of the console.

I bought my first Saturn (and had my first experience with it!) early in 2018, so my guess is my Saturn is cobbled together parts from broken units.
Personally, I am suspicious of it and think that internally it's probably a Model 1 more than a Model 2, but it does have BIOS Rev 1.01 / 1995. I say that because the eBay seller I bought it from clearly had pictures showing a Model 1 Saturn (and a Model 2 controller, which I got) and my guess is he broke it and hastily slapped a shell from a broken console on it. And I can tell some work and care was given to it, since when I received it, there was a cloth shim in the backup RAM battery preventing unnecessary battery usage/leakage. But you know, he jipped me a bit, because this thing is a mismatch!
Title: Re: Request for real hardware tests
Post by: SaturnTeam on July 05, 2018, 07:13:17 pm
Well, I am disappointed. I wanted to help you, but it isn't working. I burnt it to one of my dev CDs that I use for my own game testing. I ran it on my US Model 1 MK 80000, made in Japan in 1995. I tried using both game loaders on Pseudo Saturn Kai, but it won't load. It just gets stuck at the Sega screen. If you want to, you could post the audio file and I could set up my own ISO. Did you add the "JO_PSEUDO_SATURN_KAI_SUPPORT = 1" module in the makefile?
Title: Re: Request for real hardware tests
Post by: ponut64 on July 05, 2018, 07:32:03 pm
I actually use Pseudo Saturn Kai Lite to boot CD-Rs.
That's interesting. We have one where it won't boot, two where it destroys you, and emulators that just don't do anything wrong (well most do, only works right in Bizhawk.. and mostly on real hardware if it were not for the static).

I'm uploading a zip package to where anyone can re-build the ISO. I do have a modified engine, after all. I imagine it freezes because the display mode changes (to 352x240).
http://www.mediafire.com/file/nr88ibobuw2vyy4/buildit.zip/file
By the way, you can target the code to AIFF files. It just doesn't know what to do with the header. Always encode 16-bit mono at 30.72KHz.
Title: Re: Request for real hardware tests
Post by: SaturnTeam on July 05, 2018, 07:56:19 pm
I downloaded the files. Before I burn another CD-R (I don't have many left), I wanted to mention that it won't compile. Here are the warnings and errors I'm getting:
ZT/ZT_CD.c:20: warning: implicit declaration of function 'STM_WORK_SIZE'
ZT/ZT_CD.c:20: error: variable-size type declared outside of any function
ZT/ZT_CD.c: In function 'ztCDinit':
ZT/ZT_CD.c:28: warning: implicit declaration of function 'PCM_Init'
ZT/ZT_CD.c.29: warning: implicit declaration of function 'STM_Init'
ZT/ZT_CD.c.31: warning: implicit declaration of function 'PCM_DeclareUseAdpcm'
make: *** [ZT/ZT_CD.c] Error 1
._sl_coff.iso found
Access to the path '\RTFK\._sl_coff.cue' is denied.

------
I could just make a simple application to test the PCM files if you want. I don't see why that wouldn't work. Is the music file 8-bit or 16-bit? I need to know how to mark it in my test application. Also, is it mono or stereo?
Title: Re: Request for real hardware tests
Post by: SaturnTeam on July 05, 2018, 08:47:28 pm
My test application didn't work, because I tried running the music PCM on channel 0 and it ran out of PCM memory. I figured that might happen. Can you insert the Kai module into your makefile and re-upload the sl_coff.iso? That should be enough for me to load it on my Saturn. Let me know when you've done that, and I'll try it again.
Title: Re: Request for real hardware tests
Post by: ponut64 on July 05, 2018, 09:02:44 pm
You should be able to just delete line 20 of ZT Cd (g_stm_work), "PCM_Init", "STM_Init", and "PCM_DeclareUseAdpcm" as those are SBL functions that I do not use (they are in there because I was testing it). They have no effect on the function of the program. I recommend anyone who builds the program do the same. (.. They also could have been interfering)
Thanks for trying to work with me. And before you waste more CD-Rs, I recommend doing preliminary testing using Bizhawk, and if that works, then move on to real hardware.

And, actually: It didn't run out of PCM memory. You can't actually store PCM files themselves in sound memory; think of it more as a playback buffer. It ran out of LWRAM (1MB).
19 sectors (38 KB) of sound RAM is consumed by the sound driver.
There's only about 16 sectors (32 KB) of PCM playback buffer (8 sectors for mono, 16 sectors for stereo).
And for some reason they have a whopping 436 KB dedicated to "pitch/sequence" . .
Title: Re: Request for real hardware tests
Post by: SaturnTeam on July 05, 2018, 09:13:22 pm
I commented out line 20, but I'm still getting errors from lines 28, 29, and 31. If I comment those out, I get a message saying that there were multiple ISOs found in the project and it doesn't open in Yabause. Oh, I didn't see that you had uploaded that file. Let me try it again.
Title: Re: Request for real hardware tests
Post by: ponut64 on July 05, 2018, 09:16:35 pm
Multiple ISOs? Run clean.bat, make sure nothing is mounted
On top of the updated files
Title: Re: Request for real hardware tests
Post by: SaturnTeam on July 05, 2018, 09:33:33 pm
Okay. I got it working. The first time, I pressed on the directional pad and the game froze. The second time, at 1:43, the audio went into a feedback loop. I didn't get any static before that. It just kept playing that second of the audio over and over.
(https://saturnteam.files.wordpress.com/2018/07/image1-2.jpg)
Title: Re: Request for real hardware tests
Post by: XL2 on July 05, 2018, 09:53:58 pm
You should be able to just delete line 20 of ZT Cd (g_stm_work), "PCM_Init", "STM_Init", and "PCM_DeclareUseAdpcm" as those are SBL functions that I do not use (they are in there because I was testing it). They have no effect on the function of the program. I recommend anyone who builds the program do the same. (.. They also could have been interfering)
Thanks for trying to work with me. And before you waste more CD-Rs, I recommend doing preliminary testing using Bizhawk, and if that works, then move on to real hardware.

And, actually: It didn't run out of PCM memory. You can't actually store PCM files themselves in sound memory; think of it more as a playback buffer. It ran out of LWRAM (1MB).
19 sectors (38 KB) of sound RAM is consumed by the sound driver.
There's only about 16 sectors (32 KB) of PCM playback buffer (8 sectors for mono, 16 sectors for stereo).
And for some reason they have a whopping 436 KB dedicated to "pitch/sequence" . .
Well, sequence = audio files, mainly midi, but you can actualy store pcm files too.
It's what I do to free up some 450 KB of memory.
Take a look at the tone editor with a mac emulator as it's the only way I know of to use pcm audio within sound ram.
Also you only need to transfer commands during v blank instead of dma transfering files.
Title: Re: Request for real hardware tests
Post by: ponut64 on July 05, 2018, 09:58:30 pm
Okay. I got it working. The first time, I pressed on the directional pad and the game froze. The second time, at 1:43, the audio went into a feedback loop. I didn't get any static before that. It just kept playing that second of the audio over and over.
(https://saturnteam.files.wordpress.com/2018/07/image1-2.jpg)

Interesting. Well, at about 1:43 in, it's just gonna crap itself. and yeah, don't touch the D-pad (or the Z key), it can try to manipulate model data for animation that doesn't exist.
I'm not sure how to organize the transfer at V-blank. I'll have to investigate.
I guess I will have to, since I don't want some 400 KB of LWRAM eaten up by sound.
Music, though... I'm certain I can get that figured out and it's not an issue to use LWRAM as the music buffer.

Thanks, everyone. We can move on now !
Interestingly, the fault area corresponds to memory address 6,266,880 + LWRAM = 8364032 / 0x7FA000 --> End of Saturn memory map.
So now we know what's happening. Now I need to figure out how or if I can offset the SGL PCM playback pointer.
Title: Re: Request for real hardware tests
Post by: XL2 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);

Title: Re: Request for real hardware tests
Post by: ponut64 on July 05, 2018, 10:33:07 pm
Thank you for the tutorial. In time, I'll get to that.
Title: Re: Request for real hardware tests
Post by: ponut64 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? ^^
Title: Re: Request for real hardware tests
Post by: XL2 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.
Title: Re: Request for real hardware tests
Post by: ponut64 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.
Title: Re: Request for real hardware tests
Post by: XL2 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.
Title: Re: Request for real hardware tests
Post by: ponut64 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.
Title: Re: Request for real hardware tests
Post by: XL2 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.