DSNES Source Code
- GyroVorbis
- Elysian Shadows Developer
- Posts: 1874
- https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
- Joined: Mon Mar 22, 2004 4:55 pm
- Location: #%^&*!!!11one Super Sonic
- Has thanked: 81 times
- Been thanked: 64 times
- Contact:
DSNES Source Code
I was told that it was released. If anybody knows where I can find it, please let me know.
- GyroVorbis
- Elysian Shadows Developer
- Posts: 1874
- Joined: Mon Mar 22, 2004 4:55 pm
- Location: #%^&*!!!11one Super Sonic
- Has thanked: 81 times
- Been thanked: 64 times
- Contact:
-
- DC Developer
- Posts: 2285
- Joined: Fri Feb 21, 2003 7:37 am
- Location: Chicago, IL
- Has thanked: 0
- Been thanked: 1 time
- Contact:
- Christuserloeser
- Moderator
- Posts: 5948
- Joined: Thu Aug 28, 2003 12:16 am
- Location: DCEvolution.net
- Has thanked: 10 times
- Been thanked: 0
- Contact:
- chronofurb
- DCEmu Freak
- Posts: 79
- Joined: Wed Jan 07, 2004 11:33 pm
- Location: Earth
- Has thanked: 0
- Been thanked: 0
what part of the emulator is slowing things down, the cpu portion or the graphics? if it is the cpu, I might consider writing a new core from scratch. Me and my partners in my software engineering class just wrote our own 6502 core (NES cpu) and its pretty fast. its not written in asm but it is all inline pretty much. but the interesting this is we managed to write it so that everything is done through jump tables, so we are only having to read from memory and not having to write every time. I am sure the snes cpu core was written already with this in mind. but it might be a fun little project
What the hell is dreamcast?
-
- Modder Of Rage
- Posts: 805
- Joined: Mon Mar 18, 2002 12:41 pm
- Location: Midwest
- Has thanked: 0
- Been thanked: 0
- Contact:
- Christuserloeser
- Moderator
- Posts: 5948
- Joined: Thu Aug 28, 2003 12:16 am
- Location: DCEvolution.net
- Has thanked: 10 times
- Been thanked: 0
- Contact:
Fox68k told me that the DSNES SH4 ASM core basicly is nothing but a babelfish translation from C to SH4 so he's pretty sure that there's room for improvements.chronofurb wrote:what part of the emulator is slowing things down, the cpu portion or the graphics? if it is the cpu, I might consider writing a new core from scratch. Me and my partners in my software engineering class just wrote our own 6502 core (NES cpu) and its pretty fast. its not written in asm but it is all inline pretty much. but the interesting this is we managed to write it so that everything is done through jump tables, so we are only having to read from memory and not having to write every time. I am sure the snes cpu core was written already with this in mind. but it might be a fun little project
However, what would you expect to gain from speeding up a laughable 3 (!) MHz CPU ? The SuperNES isn't a NES (with its 3 6502 variants) nor it is a Genesis/Mega Drive (with its extremely powerful M68K/z80 combo).
The most powerful things within the SuperNES are the incredible sound and video hardware. That's why implementing the DreamSNES SH4 CPU to SuperFamicast v2 didn't have any noticable effect.
Having to use the Dreamcast's SH4 for generating the video & sound rendering without even using the AICA or the PVR2DC is the cause for SNES emulation beeing that "slow" on DC.
Insane homebrew collector.
- chronofurb
- DCEmu Freak
- Posts: 79
- Joined: Wed Jan 07, 2004 11:33 pm
- Location: Earth
- Has thanked: 0
- Been thanked: 0
-
- DC Developer
- Posts: 9951
- Joined: Sun Dec 30, 2001 9:02 am
- Has thanked: 0
- Been thanked: 1 time
There isn't really any documentation on the PVR. About the extent of it is:
http://www.ludd.luth.se/~jlo/dc/
http://mc.pp.se/dc/
Everything else is basically example programs, having a look through bits of KOS to see how it works, and trying things out.
The main problem is trying to replicate the behaviour of the SNES PPU. It's actually impossible to do it accurately with the PVR, without being slower than the software renderer you're trying to replace. The best you're going to be able to do is something that's good enough to play games, but you'll have to drop most of the special effects.
You really do need to find some documentation on the SNES first.
http://www.ludd.luth.se/~jlo/dc/
http://mc.pp.se/dc/
Everything else is basically example programs, having a look through bits of KOS to see how it works, and trying things out.
The main problem is trying to replicate the behaviour of the SNES PPU. It's actually impossible to do it accurately with the PVR, without being slower than the software renderer you're trying to replace. The best you're going to be able to do is something that's good enough to play games, but you'll have to drop most of the special effects.
You really do need to find some documentation on the SNES first.
-
- DC Developer
- Posts: 9951
- Joined: Sun Dec 30, 2001 9:02 am
- Has thanked: 0
- Been thanked: 1 time
The ARM? Not fast enough. Not even close, in fact - it can't even manage emulating the Master System's sound hardware by itself.
That said, it should be possible to use the Dreamcast's sample playback hardware to mimic the SNES sample playback hardware, then use the ARM to control the playback as the SNES' DSP would have (ADSR envelopes and so on). I can't immediately see a way to mimic the DSP's echo, filter or feedback effects, but there's a fair bit we don't know about the Dreamcast's sound hardware, so it's probably possible. Ditto with the noise generator. The SH-4 would still have to take care of emulating the SPC700 (the sound CPU) in this scenario, and emulating the SPC700 isn't exactly fast. The SH-4 would also have to take care of working out which bits of memory represent samples, converting them from 4-bit ADPCM to 16-bit PCM, optionally applying gaussian interpolation to them as the SNES DSP does, and uploading them to SRAM. That's probably the single most difficult part. Once you've got that worked out, you just need to work out what frequency to play the samples back at, what volume levels to use, decode the volume envelope, and get the Dreamcast to play the samples back. That's ignoring all the post-processing effects and noise generation, but it'd be enough to get most games running, at least.
That said, it should be possible to use the Dreamcast's sample playback hardware to mimic the SNES sample playback hardware, then use the ARM to control the playback as the SNES' DSP would have (ADSR envelopes and so on). I can't immediately see a way to mimic the DSP's echo, filter or feedback effects, but there's a fair bit we don't know about the Dreamcast's sound hardware, so it's probably possible. Ditto with the noise generator. The SH-4 would still have to take care of emulating the SPC700 (the sound CPU) in this scenario, and emulating the SPC700 isn't exactly fast. The SH-4 would also have to take care of working out which bits of memory represent samples, converting them from 4-bit ADPCM to 16-bit PCM, optionally applying gaussian interpolation to them as the SNES DSP does, and uploading them to SRAM. That's probably the single most difficult part. Once you've got that worked out, you just need to work out what frequency to play the samples back at, what volume levels to use, decode the volume envelope, and get the Dreamcast to play the samples back. That's ignoring all the post-processing effects and noise generation, but it'd be enough to get most games running, at least.
- Christuserloeser
- Moderator
- Posts: 5948
- Joined: Thu Aug 28, 2003 12:16 am
- Location: DCEvolution.net
- Has thanked: 10 times
- Been thanked: 0
- Contact:
Hm, I never understood that.... Dunno, it's just something that doesn't get into my head, even if it does it doesn't make any sense... Why shouldn't it be fast enuff for emulating the SMS' sound hardware ?BlackAura wrote:The ARM? Not fast enough. Not even close, in fact - it can't even manage emulating the Master System's sound hardware by itself.
I know Rand Linden said sth like this a year ago (in fact he insulted Heliophobe just because he started thinking about it ). I really admire Rand and I am pretty sure that he got more expierence with the DC's hardware than 99,9% of the people that created commercial games for it, still he's human like all of us and thus he may be wrong... - however, at least I've yet to understand that and why the ARM isn't fast enuff to do anything...
Insane homebrew collector.
-
- Modder Of Rage
- Posts: 805
- Joined: Mon Mar 18, 2002 12:41 pm
- Location: Midwest
- Has thanked: 0
- Been thanked: 0
- Contact:
The arm's purpose is to direct sound in memory. The arm itself only has enough power to process very small sound samples and to dictate sound in memory. The arm is the slowest part of the dc hardware.
Check out the beats of rage community at http://borrevolution.vg-network.com/
- Quzar
- Dream Coder
- Posts: 7499
- Joined: Wed Jul 31, 2002 12:14 am
- Location: Miami, FL
- Has thanked: 4 times
- Been thanked: 10 times
- Contact:
Actually, that's wrong. The arm within the sound processor is quite powerful, the problem is that the memory interface is so slow that it becomes useless. I've spent large amount of time pondering how this could possibly be used, and have come up with a few ideas, but they are probably somewhere between ridiculous, nonsensical, and the fevered dreams of a madman.DcSteve wrote:The arm's purpose is to direct sound in memory. The arm itself only has enough power to process very small sound samples and to dictate sound in memory. The arm is the slowest part of the dc hardware.
"When you post fewer lines of text than your signature, consider not posting at all." - A Wise Man