General Insanity (Genesis + PVR)

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
Post Reply
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has liked: 0
Been liked: 0

Post by BlackAura » Fri Jun 25, 2004 9:42 am

You misquoted that bit about SPU DMA, it was said by Warmtoe, not me.
Oops... Let us try that again, only without the "Oops".

Warmtoe - which versions of KOS have working SPU DMA?

:wink:
Personally I have not worried too much about getting data to the SPU, because the sample generation is a much more significant bottleneck in FreeSCI.
True. I just don't want to waste too much time doing something which is otherwise useless, such as shovelling the data out to SRAM.

Hmm... I'm not really sure what the best way to do this is. Rendering the sound to a main RAM buffer is obviously the way we're going to have to go, and (hopefully) transfer the stuff using async DMA.

The catch there is that we need some kind of callback function, because no matter which way we do it, we're going to be transferring more than one sound buffer at a time, and I don't see any way around that. If we're using a software mixer, we'll need to transfer two buffers one after the other, to different positions in SRAM (left channel, right channel). If we're using hardware mixing, we'll be transferring four buffers (DAC, PSG, two FM). We can't do multiple DMA transfers at the same time, and we can't sit around and wait for them to complete...

Oh well. I'm off to grab a development version of KOS, and see if I can get it to compile.
Warmtoe
DC Developer
DC Developer
Posts: 453
Joined: Thu May 16, 2002 8:29 am
Location: ice88's house
Has liked: 0
Been liked: 0
Contact:

Post by Warmtoe » Fri Jun 25, 2004 9:56 am

I have the latest KOS-SVN version - If you like I can zip up the source and put it out for you to download (when I get home). SPU DMA is working there - I used it during some fiddling with MAME - unreleased fiddling.

Let me knoe and I'll sort some source for you - or you could go right out and get the latest KOS version from their site (can't remember the URL off the top) -

edit: errr, looks like you already did that.
Last edited by Warmtoe on Fri Jun 25, 2004 10:02 am, edited 1 time in total.
Warmtoe
DC Developer
DC Developer
Posts: 453
Joined: Thu May 16, 2002 8:29 am
Location: ice88's house
Has liked: 0
Been liked: 0
Contact:

Post by Warmtoe » Fri Jun 25, 2004 10:00 am

BlackAura wrote:The catch there is that we need some kind of callback function, because no matter which way we do it, we're going to be transferring more than one sound buffer at a time, and I don't see any way around that. If we're using a software mixer, we'll need to transfer two buffers one after the other, to different positions in SRAM (left channel, right channel). If we're using hardware mixing, we'll be transferring four buffers (DAC, PSG, two FM). We can't do multiple DMA transfers at the same time, and we can't sit around and wait for them to complete...
OK - here comes the good news... you can chain the DMA transfers - using the SPUDMA so that when one finishes, the next one starts - and you can then chain that one and so-on and so-on.

So you can do precisely what you want to do with the SPU DMA transfer code - I love it when a problem is solved by the code having already been written with the problem in mind!! Doesn't happen often enough but it has here.
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has liked: 0
Been liked: 0

Post by BlackAura » Fri Jun 25, 2004 10:07 am

Warmtoe wrote:OK - here comes the good news... you can chain the DMA transfers - using the SPUDMA so that when one finishes, the next one starts - and you can then chain that one and so-on and so-on.

So you can do precisely what you want to do with the SPU DMA transfer code - I love it when a problem is solved by the code having already been written with the problem in mind!! Doesn't happen often enough but it has here.
Cool. We don't need to do some terrible hack like I did with the video DMA code in Genesis Plus then.

I have GP/DC generating sound into three buffers (no DAC emulation as yet), so I need to try to write the sound output driver now. After I've finished downloading KOS 1.3.x 133/incr and managed to compile it, of course...
Warmtoe
DC Developer
DC Developer
Posts: 453
Joined: Thu May 16, 2002 8:29 am
Location: ice88's house
Has liked: 0
Been liked: 0
Contact:

Post by Warmtoe » Fri Jun 25, 2004 10:24 am

BlackAura wrote:I have GP/DC generating sound into three buffers (no DAC emulation as yet), so I need to try to write the sound output driver now. After I've finished downloading KOS 1.3.x 133/incr and managed to compile it, of course...
Remember - the buffers (for DMA transfer) must be on 32-byte alligned boundaries - both the input and output buffers.

OK - DUDE! I need to see that source.

I decided I'd do some donkey work, and get rid of the compiler warnings in the c68k compile - it's lots of work for no gain, but I cannot stand that enormous long list of warnings....

I was also going to do some additional tinkering - but I really want to have a tinker with the stuff you're doing now :D You know, I don't write from scratch - I tinker !!
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has liked: 0
Been liked: 0

Post by BlackAura » Fri Jun 25, 2004 10:38 am

Remember - the buffers (for DMA transfer) must be on 32-byte alligned boundaries - both the input and output buffers.
Stef already took care of that. Thanks Stef!
OK - DUDE! I need to see that source.
Wait your turn. I just had to scrap most of what I already had, so it ain't going to do a lot of good right now. Give me about twenty minutes...
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has liked: 0
Been liked: 0

Post by BlackAura » Fri Jun 25, 2004 11:10 am

It's no good - I need to go to bed. I think I might be coming down with something. It feels kinda like a flu or a cold, which is never a good thing. Damn.
Ian Micheal
Soul Sold for DCEmu
Soul Sold for DCEmu
Posts: 4864
Joined: Fri Jul 11, 2003 9:56 pm
Has liked: 0
Been liked: 3 times

Post by Ian Micheal » Fri Jun 25, 2004 11:46 am

To many late nights BA. made me ill to this week. Getings to a point were some of this stuff stresses you mind and body so much. You get sick.
Dreamcast forever!!!
User avatar
Christuserloeser
Moderator
Moderator
Posts: 5936
Joined: Thu Aug 28, 2003 12:16 am
Location: DCEvolution.net
Has liked: 0
Been liked: 0
Contact:

Post by Christuserloeser » Fri Jun 25, 2004 12:49 pm

BlackAura wrote:
Storminator16 wrote:Now that's just plain sick
Yep.

Here's one interesting point - would it be possible to distribute box or manual scans? I wouldn't have thought so, but we have distributed screenshot packs in the past. They'd obviously be much, much larger than simple screenshots.

Something like Genesis Collective might be useful either way. They even have cartridge scans, although most of them look crap. I much prefer the European boxes to the US ones though.
I for myself would love to see Japanese box art they are incredible looking!
I will give you a link (I know I have bookmarked somewhere) You'll see how great they look compared with the European :x or the US ones.
BlackAura wrote:It's no good - I need to go to bed. I think I might be coming down with something. It feels kinda like a flu or a cold, which is never a good thing. Damn.
Ian Micheal wrote:To many late nights BA. made me ill to this week. Getings to a point were some of this stuff stresses you mind and body so much. You get sick.
That's no good!

Take it easy... take a break. This emu is already so incredible:
MetaFox wrote:I'm at a loss for words - Awesome. :o

:!:


Edit: Same goes for NeoDC :)



Chris
Last edited by Christuserloeser on Sat Jun 26, 2004 5:53 am, edited 1 time in total.
Insane homebrew collector.
Heliophobe
Smeg Creator
Smeg Creator
Posts: 246
Joined: Thu Mar 14, 2002 2:40 pm
Has liked: 0
Been liked: 0
Contact:

Post by Heliophobe » Fri Jun 25, 2004 1:38 pm

Mask of Destiny wrote:
Might be worth a try though. For now, I'm just going to try to modify what we already have. It might be possible to shift the FM or PSG over to the ARM, although Heliophobe said it was too slow to emulate the PSG (as found in the SMS), so...
I find it hard to believe that the ARM in the Dreamcast is so slow that it can generate a 3 square waves and a noise channel in real time. I suppose it might be too slow to handle some of the DAC stuff some SMS games used it for, but even then...

Well, let's put it this way:

When I had Smeg running PSG on the ARM CPU, it was able to do sample accurate PSG emulation --- barely. I had originally written it in C, and that turned out to be too slow to keep up so I reimplemented it in ARM asm. while I'm not an ARM master by any means, it was decently well optimized.

I switched it over to the SH4 side after Smeg 0.80 and as it used less than 2% CPU time even when playing samples I decided not to sweat the loss.

So how fast is the ARM in practical applications? Someone should work out some benchmarks for it someday, since the 'official' docs are all over the map and all seem to be wrong, but I estimated it at about 3mhz. I do know that the Yamaha sound chip runs at about 45mhz.


This was the theory I came up with about why the ARM is so much slower than advertised - and it's all just theory from this point on, so don't take this as gospel:

The Yamaha sound chip (AICA hereafter) has 64 sound channels, which it is able to play at CD quality (44100khz) when running at 45mhz.

The sound channels in the AICA are not all calculated at once, rather each channel gets a 'turn at the mic' in order. For each sample, every channel is calculated and its final output is added to an accumulator. When all 64 channels have been calculated, the accumulator is sent to the DAC which produces the sound we hear, and the process begins again with channel zero and an empty accumulator.

So, we have 64 channels running at 44100khz. That means that 64 channel * 44100 samples = 2822400 channel calculations/second being calculated. But how many cycles does it take the AICA to calculate a channel? Well, we've got to figure they decided to use a 45mhz crystal for the sound system for a reason. Let's say it's 45,000,000 cycles a second (though it's probably not that exactly) so

45,000,000 / 2822400 = 15.94 =~ 16 (say, that's a nice round number.. in binary at least)

So let's say the AICA runs at 16 * 2822400 = 45158400 cycles/second, .

Okay, so now let's assume it's correct that the AICA takes 16 cycles to calculate a channel. For at least some of these cycles, the AICA will need to access memory. At the very least, it will need one of those 16 cycles to fetch the sample data.

However, it seems to take a lot more than that. For each channel there are 32 4 byte registers - but a number of them are unknown or unused (or it's unknown whether they're unused). I'll assume these are held in RAM and fetched by the AICA rather than being directly mapped to AICA registers, since they seem to be read/write (the ARM can write them at work or byte boundaries, implying a read/modify/write sequence) and there are so many of them.

AICA docs I'm looking at (probably out of date) suggest 11 of these have known functions, so the AICA is likely to fetch at least these 11 every cycle while doing it's calculations, possibly more. That means 12 or more of the 16 cycles may be taken up by AICA memory reads. Since the ARM7 doesn't have an instruction cache(or, at least the one in the GBA doesn't) it is effectively frozen while waiting for the sound chip to release the memory bus (as it must always have higher priority).

So, worse case scenario is that the ARM7 only gets 1 out of 16 cycles (in case the AICA ties up the bus for other things), so it functions at 2.8mhz, which is awfully close to my estimate. Maybe it gets two or three or more out of sixteen, increasing the available time in 2.8mhz increments.

An interesting note is that I had observed such slow speeds while only using a single channel, so the AICA seems to do memory fetch (or at least tie up the bus) and caclulations even when a channel is not active. There might be a way to completely disable the channels, memory fetch and all, and get more ARM time when the unused channels are up - but I have no clue if/how that could work.




Like I said, it's all speculation but it would explain why the ARM seems so go so slow even though it's supposed to be a 25 or 28 or 45mhz CPU.
Ian Micheal
Soul Sold for DCEmu
Soul Sold for DCEmu
Posts: 4864
Joined: Fri Jul 11, 2003 9:56 pm
Has liked: 0
Been liked: 3 times

Post by Ian Micheal » Fri Jun 25, 2004 2:27 pm

Very hard to get the maxuim out put from it the docs explain how to do this. with examples i have them but there offical not released there printed. So i cant really type it all out here. Prolly scann it but it says it's illegal to dislose.


it is 25mhz but thats very hard to do.

As Rand said.
Dreamcast forever!!!
Heliophobe
Smeg Creator
Smeg Creator
Posts: 246
Joined: Thu Mar 14, 2002 2:40 pm
Has liked: 0
Been liked: 0
Contact:

Post by Heliophobe » Fri Jun 25, 2004 2:50 pm

Yeah, most of my conceptions of the Dreamcast hardware are based on what was publically available about two years ago.

I had some luck working on a new FM renderer for EMU2413. The 2413, as many of you know, is a 2-op synth chip similar to the original AdLib sound, except with preset instruments. I decided to keep the original EMU2413 for chip I/O, calculating operator and envelope phases, etc, but replace the actual sample generating code with a faster renderer. I don't really know if I'll ever get it in a releasable state, but sometime I'll share my notes on what I've done in case it can be of use for making a new YM2612 renderer (or even 2151, which I think is similar except for the PCM stuff). The YM2612 is more sophisticated, with 4 operators per channel and with multiple connection algorithms, but I think some of the principals would still apply.
User avatar
Quzar
Dream Coder
Dream Coder
Posts: 7486
Joined: Wed Jul 31, 2002 12:14 am
Location: Miami, FL
Has liked: 0
Been liked: 3 times
Contact:

Post by Quzar » Fri Jun 25, 2004 6:46 pm

according to "Yamaha AICA Sound System Hardware Reference v0.8" You can change the clock rate of the arm chip through the interrupt/timer register 0x28a8 which is set to the desired clock speed - 1. The examples this document give are 00 = 1Mhz and 24 = 25Mhz. Using this you could theoretically clock this higher, to 16 Mhz, 32 or probably even 64 without causing any permanent damage. I assume that what is happening is that it defaults to 3Mhz (~2.8) because that is the minimum required by the AICA but it is probably possible to go much higher than that (probably up to 25Mhz as sega notes) safely.
"When you post fewer lines of text than your signature, consider not posting at all." - A Wise Man
doragasu
DCEmu Cool Poster
DCEmu Cool Poster
Posts: 1048
Joined: Thu May 16, 2002 5:01 pm
Location: Madrid, Spain
Has liked: 0
Been liked: 0

Post by doragasu » Fri Jun 25, 2004 8:08 pm

Just one thing, I have discovered this emu (preview 3) has the same "timer bug" as Neo CD SDL DC, so I suppose the bug is in Stef's 68K core. I found it playing Gunstar Heroes. While in stage 4 (in Black's Palace), in the minigames that have a timer discounting to 0, the time goes to 0 instantly. Also, while fighting against Timeron in stage 6 (the horizontal shooter stage) there's a timer that counts up, well in that timer, minutes and seconds are always 0, and cents are always 1X (only the last digit moves).

Also, I don't know if it's related to the "timer bug", but in Gunstar Heroes, score tends to go to 99999999.
User avatar
MetaFox
Adventure Gamer
Adventure Gamer
Posts: 2801
Joined: Wed Oct 17, 2001 7:44 pm
Has liked: 0
Been liked: 5 times
Contact:

Post by MetaFox » Fri Jun 25, 2004 8:29 pm

Last edited by MetaFox on Fri Jun 25, 2004 9:24 pm, edited 1 time in total.
Rand Linden
bleemcast! Creator
bleemcast! Creator
Posts: 882
Joined: Wed Oct 17, 2001 7:44 pm
Location: Los Angeles, CA
Has liked: 0
Been liked: 0
Contact:

Post by Rand Linden » Fri Jun 25, 2004 8:30 pm

Heliophobe wrote: <insert huge tech. crap here>
Mostly correct, but it runs at 25Mhz... BELIEVE ME.

Rand.
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has liked: 0
Been liked: 0

Post by BlackAura » Fri Jun 25, 2004 8:46 pm

Ian Micheal wrote:To many late nights BA. made me ill to this week. Getings to a point were some of this stuff stresses you mind and body so much. You get sick.
Actually, I think it's an ear infection.

doragasu - I noticed a few of the same bugs is other games. The score in TMNT doesn't work properly (it seems to stay around 815-ish), and a couple of other programs seem to have issues with the score counts.

Update: Got it working with KOS 1.3.x incr. 113, and made a couple of minor alterations. There's no sound output yet (it's emulated, but not output) and it's almost (but not quite) fast enough to do full speed with sound on most games. The sound output code, when I get it written, should solve the problems with sound skipping.
Ian Micheal
Soul Sold for DCEmu
Soul Sold for DCEmu
Posts: 4864
Joined: Fri Jul 11, 2003 9:56 pm
Has liked: 0
Been liked: 3 times

Post by Ian Micheal » Sat Jun 26, 2004 2:42 am

Timer problem is in neogeocd yeah and this emulator to and it's more of a problem for me since some games have to have the timer. But also on genesis. SF2 for example if you dont turn the timer off you instantly lose it goes to zero soon as you touch some one. Lots of others like this.


Same for me.
Dreamcast forever!!!
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has liked: 0
Been liked: 0

Post by BlackAura » Sat Jun 26, 2004 4:02 am

For the sound output, the theory's good, but I'm having trouble getting it to actually work... At the moment, I've only got PSG output, and it sounds a little funky...

Update: One of the FM channels was playing too, but it was on the right channel only (and I only have a mono TV). That means that channels 1 and 2 are playing, but channel 0 isn't. I'm also having some problems with keeping the sound output and the sound playback in sync.
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has liked: 0
Been liked: 0

Post by BlackAura » Sat Jun 26, 2004 5:50 am

I give up. I just can't get the sound code right...

http://files.frashii.com/~sp00nz/Doom/f ... -5.tar.bz2

Here's what's wrong with it:
- Everything's output to the center sound channel
- The sound mixing is completely wrong
- Only one of the two FM channels is playing. For some reason, channel 0 is either not playing, or the sound data isn't being copied.
- The sound keeps screwing up. Either the sound output keeps catching up with the playback, or the playback is catching up with the sound output. I have no way to tell which is happening

Basically, I can't debug it. If I can't debug it, I can't fix it. I always have this problem with sound streaming stuff. I don't know why, but I can never get sound streaming to work properly, mostly because I can't see what's wrong with it.

When it does work (when the playback position and the writing position aren't overlapping) it sounds pretty good, if you can ignore the fact that half the FM sound is missing...

If someone else wants to have a go at it, feel free. It requires a version of KOS with SPU DMA. I'm using 1.3.x incr 133.
Post Reply