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
Storminator16
DCEmu Veteran
DCEmu Veteran
Posts: 850
Joined: Mon Sep 01, 2003 11:12 am
Location: NC/Iraq
Has liked: 0
Been liked: 0
Contact:

Post by Storminator16 » Fri Jun 25, 2004 5:32 am

speud wrote:btw will, where your save code is coming from? did you take it from another open source genesis emu or did you write it from scratch?
is someone working on implementing sram support (i dont think ive noticed anything about that in your code but please correct me if im wrong)?
It's modified code from Gens. Take a closer look at the source, it has SRAM & BRAM support.

Also, look me re-iterate the code will not work at the moment. It's missing some key functions from the VDP & Z80.

Btw, I wanted to kick off some interesting discussion. What features will the emu have? Will it have a menu with screenshots? Would Game Genie support be interesting? Will there be any analog control? I'm going to work on the latter two, but I think it would be a good open discussion to find out what the features will be because there are so many people willing o add to this emulator. Metafox is also working on something, but he hasn't said yet.
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 5:54 am

BlackAura wrote:The emulator will then generate that many frames worth of sound data for each FM channel and the PSG channel. These should be generated in 16-sample blocks (so we can use store queues to shove them out to the sound hardware), and written directly to sound memory using store queues.
Does your level of KOS have SPUDMA support in it? So long as the samples are put onto a 32byte boundary you could use DMA to transfer the data over in one lump - rather than trickle feeding it - I think that may be quicker than with store queues - anyway, if you make sure the memory area is 32 byte aligned, we could take that option later.
BlackAura wrote:We will be shoving more data out to sound memory, but we'll be able to generate that data more efficiently, because we aren't re-reading and mixing the data at all.
Is there any way to shift the sound emulation out to the ARM? That is 2 meg of memory and a whole processor that we just aren't using - if you are going to attack the generation of sound - which sounds right - then would it be possible to move this whole thing out there - and just have the main loop basically send the number of frames to generate.
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 5:58 am

By-the-way BA - is there any code for this sound emulation method of yours yet?

What can I help with?

At the moment, I'm tinkering with things on my local build - but I could get more stuck into something... it's just a question of what!
speud
DCEmu Uncool Newbie
DCEmu Uncool Newbie
Posts: 1459
Joined: Sat Dec 27, 2003 10:40 pm
Has liked: 0
Been liked: 0
Contact:

Post by speud » Fri Jun 25, 2004 5:58 am

Storminator16 wrote:It's modified code from Gens. Take a closer look at the source, it has SRAM & BRAM support.

Also, look me re-iterate the code will not work at the moment. It's missing some key functions from the VDP & Z80
oh i see, i missed that part, thanks for clarifying. so, will you try to fix it or are you done with it for now?
http://blueswirl.fr.st - DC Online Tools and Downloads

thx to Wack0 for the avatar ;)
Storminator16
DCEmu Veteran
DCEmu Veteran
Posts: 850
Joined: Mon Sep 01, 2003 11:12 am
Location: NC/Iraq
Has liked: 0
Been liked: 0
Contact:

Post by Storminator16 » Fri Jun 25, 2004 6:15 am

I'm done with it for now. I have no idea about programming emus so I'm not going to tinker with the VDP or Z80.
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 6:25 am

Phantom wrote:I'm not sure exactly what kind of FM chip is present in the Mega Drive
It's a YM2612, which is a bit different. As far as I remember, the YM3812 is the one used on old PC soundcards (like Adlib and SoundBlaster cards) isn't it?
Storminator16 wrote:Will it have a menu with screenshots?
It'll have more than screenshots, if you take the time to fill the disc out fully. At the very least, you'll be able to add additional descriptions for each game, such as the blurb from the back of the box (in multiple languages, if you like), features the game has (languages, players supported, whatever else they put on the back of the box), the release date, developer and publisher of the game, and maybe a couple of other bits of information. And that's just the text-based stuff...
Would Game Genie support be interesting? Will there be any analog control? I'm going to work on the latter two
Go for it.
The coder formerly known as Warmtoe wrote:Does your level of KOS have SPUDMA support in it? So long as the samples are put onto a 32byte boundary you could use DMA to transfer the data over in one lump - rather than trickle feeding it - I think that may be quicker than with store queues - anyway, if you make sure the memory area is 32 byte aligned, we could take that option later.
No, SPU DMA is completely broken in KOS 1.2.0.

I'm not sure if DMA will actually be faster than store queues. It'd certainly be faster than the current way, which is shoving the data out one sample at a time, because we're generating a block of data in main memory which has to be copied over to SRAM. However, if we're generating that data anyway, we may as well use store queues. With DMA, we're doing:
Generate sound -> main RAM, flush the cache, transfer DMA -> SRAM (in parallel)

With Store Queues, we're doing:
Generate sound -> store queue -> SRAM (in parallel)

At best, I think they'd be around the same speed. With store queues we don't have to worry about cache coherency, although it might make generating the sound more difficult.
Is there any way to shift the sound emulation out to the ARM? That is 2 meg of memory and a whole processor that we just aren't using - if you are going to attack the generation of sound - which sounds right - then would it be possible to move this whole thing out there - and just have the main loop basically send the number of frames to generate.
I think the ARM is too slow. We could probably use it for something, but I think the sound generation code is far too CPU-intensive to run on the ARM. We could try to use the sound hardware to generate the sound, but then we'll end up with something like the Smash Pack, and we all know how bad that sounds.

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...
By-the-way BA - is there any code for this sound emulation method of yours yet?

What can I help with?
Not much code yet. All I've really done is remove most of the sound generating code, and all of the DC sound output code. I'm working on getting DAC emulation running by itself using an SDL version of Genesis Plus (which I should probably have included in the source release actually - it's really quite good), preferably without using the FM cores at all (should be faster). Once I've done that, and it sounds reasonable, I can start working on getting sound output on the Dreamcast side.

I'm not sure if there's anything you can help with for the sound code. Each part kinda relies on the previous part, and it's not really the kind of thing you can easily split up for multiple people.
Last edited by BlackAura on Fri Jun 25, 2004 9:43 am, edited 1 time in total.
Storminator16
DCEmu Veteran
DCEmu Veteran
Posts: 850
Joined: Mon Sep 01, 2003 11:12 am
Location: NC/Iraq
Has liked: 0
Been liked: 0
Contact:

Post by Storminator16 » Fri Jun 25, 2004 6:34 am

It'll have more than screenshots, if you take the time to fill the disc out fully. At the very least, you'll be able to add additional descriptions for each game, such as the blurb from the back of the box (in multiple languages, if you like), features the game has (languages, players supported, whatever else they put on the back of the box), the release date, developer and publisher of the game, and maybe a couple of other bits of information. And that's just the text-based stuff...
Funny, I was just wondering yesterday would packing a bunch of info's or strategy hints & tips with an emu would be a great idea. Doesn't surprise me that you would be the one to add a lot of text ideas like this :D
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 6:43 am

How does scans of the box (which could be displayed in 3D) and possibly the manual sound?

Oh, and I don't think the Gens FM core is going to work in this case, just because it works a little differently to the MAME one. Basically, it's because store queues are write-only, and the Gens FM core operates directly on the sound output buffer (reading and writing to it). The MAME core does all it's calculations in variables, and I can (more) easily modify it to output directly using store queues.

I'm sure the Gens core could be modified in the same way (ask Stef - he wrote it), and it certainly does sound better than the MAME core, but it'd involve too much work at the moment. The emulator needs to output sound in a format I can directly use, and right now, the MAME one does that, and the Gens one does not.
Phantom
DC Developer
DC Developer
Posts: 1753
Joined: Thu Jan 16, 2003 4:01 am
Location: The Netherlands
Has liked: 0
Been liked: 0
Contact:

Post by Phantom » Fri Jun 25, 2004 6:55 am

BlackAura wrote:
Phantom wrote:I'm not sure exactly what kind of FM chip is present in the Mega Drive
It's a YM2612, which is a bit different. As far as I remember, the YM3812 is the one used on old PC soundcards (like Adlib and SoundBlaster cards) isn't it?
Yeah. YM2612 is implemented in fm.c in the MAME source, which is done by the same people as fmopl.c. The license issues with fm.c are probably identical. Only the versions by Tatsuyuki Satoh can be put under the GPL license. If Genesis Plus already has fm.c it's probably the older one (from 1998), so it should be alright.
"Nothing works" - Catweazle
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 7:10 am

I hope it's alright. I can't find any version information in the files or anything like that. At least we do have another one to use, although it'll involve a bit more work.
Storminator16
DCEmu Veteran
DCEmu Veteran
Posts: 850
Joined: Mon Sep 01, 2003 11:12 am
Location: NC/Iraq
Has liked: 0
Been liked: 0
Contact:

Post by Storminator16 » Fri Jun 25, 2004 8:06 am

BlackAura wrote:How does scans of the box (which could be displayed in 3D) and possibly the manual sound?
Now that's just plain sick :D Wonderful idea.

Well, I'm porting code from Gens once again but I ran into 1 function that needs a function from the ASM source. I guess I should have learned x86 assembly because I would have least had a chance to re-write this. The function of my topic is 'M68K_WW()'; I think it pumps data to the rom. I basically made another undefined function to check to see if everything else works.

Should I upload what I have or not?
Mask of Destiny
Mental DCEmu
Mental DCEmu
Posts: 330
Joined: Sun Mar 23, 2003 10:52 pm
Has liked: 0
Been liked: 0

Post by Mask of Destiny » Fri Jun 25, 2004 8:36 am

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...

Sometimes I wonder if perhaps KOS sets some register poorly, causing the ARM to run a lot slower than it should.
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 9:00 am

Don't use the SQs to transfer SPU data -- The AICA interface is incomprehensibly slow and you'll stall everything else while the SQs flush.

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 9:02 am

Mask of Destiny wrote: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...
So do I. Then again, the ARM does have to share SRAM with the sound hardware. That might cause some issues.
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.
Rand Linden wrote:Don't use the SQs to transfer SPU data -- The AICA interface is incomprehensibly slow and you'll stall everything else while the SQs flush.

Rand.
Thank you for the hint.

Phantom - which versions of KOS have working SPU DMA?
Ian Micheal
Soul Sold for DCEmu
Soul Sold for DCEmu
Posts: 4865
Joined: Fri Jul 11, 2003 9:56 pm
Has liked: 2 times
Been liked: 3 times

Post by Ian Micheal » Fri Jun 25, 2004 9:04 am

It's running at 25mhz software over clockable to 100mhz.
Dreamcast forever!!!
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 9:06 am

BlackAura wrote:Then again, the ARM does have to share SRAM with the sound hardware. That might cause some issues.
Precisely.

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 9:06 am

Err... Ian - I thought the entire sound system only ran at around 50MHz?
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 9:08 am

25Mhz... at BEST, assuming no fetch conflicts.

Rand.
Ian Micheal
Soul Sold for DCEmu
Soul Sold for DCEmu
Posts: 4865
Joined: Fri Jul 11, 2003 9:56 pm
Has liked: 2 times
Been liked: 3 times

Post by Ian Micheal » Fri Jun 25, 2004 9:12 am

Yeah 25mhz sega docs say 100mhz max software overclocking.


prolly talking 100mhz bus speed.
Dreamcast forever!!!
Phantom
DC Developer
DC Developer
Posts: 1753
Joined: Thu Jan 16, 2003 4:01 am
Location: The Netherlands
Has liked: 0
Been liked: 0
Contact:

Post by Phantom » Fri Jun 25, 2004 9:21 am

BlackAura wrote:Phantom - which versions of KOS have working SPU DMA?
I think that question should be directed at Warmtoe. You misquoted that bit about SPU DMA, it was said by Warmtoe, not me. ;)

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.
"Nothing works" - Catweazle
Post Reply