2nd Cpu, Utilised Much In Emulators?

[Vimacs]

the 920 CAN acces all memory, howeer only the first 32 are managed by linux and the upper mem is slower couse it isnt set up by the mmu by default

 

[torpor]

Well one thing I know is that that damn linux is keeping the raster interrupt palette switches from happening in DrMD (water in Sonic etc). That kind of sucks. If you could "bang the metal" those effects would be possible. Also without linux we could probably have a near perfect SNES emu.

so whats the problem with busting out the linux code and adding raster interrupt palette switching to the kernel/driver codebase? thats what linux is for: so you can fix the things that are needed. complaining about it instead of fixing it is not going to make it better..

 

[Mudi]

I also think that emulation of the raster interupt should be possible... isn't that what they do for emulators on PC these days? I can't see (personally) how emulating the raster interupt would take up too much extra CPU time... though I admit I really don't know for sure.

 

[coolmos]

Maybe Vobbo cam use the 940T to play the music from Dracula-X while the emu itself runs on the 920T ?

That way the music (<>sound) won't get in the way of emulation.......

 

[ste_167]

What's the second processor used for in Vektar?

 

[OMG]

Maybe Vobbo cam use the 940T to play the music from Dracula-X while the emu itself runs on the 920T ?

That way the music (<>sound) won't get in the way of emulation.......

thats wha tI thought! He is already emulating sound all on one core. just the mixer isn't enabled.

 

[PokeParadox]

What's the second processor used for in Vektar?

It's used for what people are discussing here, processing the audio.

 

[Squidge]

People have tried to shift various tasks onto the 940, but in the end they have found out that it runs no faster (sometimes slower) than having everything on the 920.

However, this is simply because of the type of tasks being shifted onto the 940. Some tasks will benefit greatly, others will show no performance increase - we just need to find out the right type of task.

There are people working on getting sound going without using Linux (so the 940 can do audio playback, and not just audio processing), vblank irq's, hblank irq's, palette tricks via hblank irq's, etc... Since we can't use interrupts on the 920, the 940 could be very useful for these roles.

Myself, I'm working on a Linux Accelerator - don't want to say much more yet until it works properly, but hopefully it'll speed up apps running under it *without* changing the clock speed of the processor.

 

[PokeParadox]

Aw... Squidgey... you have to tell us more now...
Well... I'm interested in anycase, sounds good.

 

[Shikaku]

*orgasm@more speed without overclocking*

Wait how is this going to work anyway? Are you planning to use the MMSP2 chip?

 

[Yod4z]

i think is just redirect function to bypass linux and acces direct to hardware to bypass linux limitation like Drmd diference between GP32 and GP2x

 

[Epicenter]

Well one thing I know is that that damn linux is keeping the raster interrupt palette switches from happening in DrMD (water in Sonic etc). That kind of sucks. If you could "bang the metal" those effects would be possible. Also without linux we could probably have a near perfect SNES emu.

And yes that extra core is nice for video. Video schmideo, I want SNES! and that extra core is useless for emus

'Get rid of linux' isn't an instantaneous means to get a 'perfect SNES emulator'. There are numerous other issues with current SNES emulation, as evidenced by that removing a battery meter provided an alleged 10 fps boost, telling me there is some old rudimentary, buggy or otherwise unoptimized code lurking about slowing things down-- the 65c816 CPU core is still *C* which is very, very slow compared to ARM9 ASM, and Reesy is writing an ARM9 ASM core for that. Transparencies may just never work properly unless a new means of implementing them can be devised, perhaps involving the 940T, perhaps involving the blitter or video processing hardware in the MMSP2. Not my department, I'm a Genesis guy myself .. Point is, 'remove linux from the equation and everything is gumdrops and rivers of chocolate syrup' is a shortsighted view of the situation that entirely sidesteps the real issues at hand.

 

[sephiroth111]

The GP32 was a lone ARM (correct me if I am wrong).

it was a samsung S3C2400x (rev1.1) chip. not an arm CPU.

 

[Epicenter]

That's a System-on-a-Chip (SoC) with a 133 MHz ARM9TDMI built into it. Despite the Samsung branding on the whole IC, it still has an ARM processor. The GP2X uses an SoC from a different company, with 2 ARM cores in it.

 

[DaveC]

Well one thing I know is that that damn linux is keeping the raster interrupt palette switches from happening in DrMD (water in Sonic etc). That kind of sucks. If you could "bang the metal" those effects would be possible. Also without linux we could probably have a near perfect SNES emu.

And yes that extra core is nice for video. Video schmideo, I want SNES! and that extra core is useless for emus

the 65c816 CPU core is still *C* which is very, very slow compared to ARM9 ASM, and Reesy is writing an ARM9 ASM core for that. .

I thought SquidgeDrSNES was based on Yoyo's SNES which has an ASM CPU core in it? The only thing still in "c" was supposed to be the sound mixing.

 

[Epicenter]

This is not what I've been hearing as of late-- I am referring to SquidgeSNES, by the way. 'SquidgeDrSNES'? Are you referring to Reesy's newer releases of SquidgeSNES? Last word I picked up was, an ASM core for the CPU was *in development*. If one was implemented yet, I believe it'd have been a major feature listed as an update but I see no such feature added. Mostly graphical speed hacks and removal of the battery meter.

 

[DaveC]

This is not what I've been hearing as of late-- I am referring to SquidgeSNES, by the way. 'SquidgeDrSNES'? Are you referring to Reesy's newer releases of SquidgeSNES? Last word I picked up was, an ASM core for the CPU was *in development*. If one was implemented yet, I believe it'd have been a major feature listed as an update but I see no such feature added. Mostly graphical speed hacks and removal of the battery meter.

Read the readme from SquidgeSNES. It states in there that the CPU is ASM.

 

[Epicenter]

Very well; regardless, there is work to be done. No ceiling has been hit yet.

 

[Squidge]

There's two CPU's in the snes:

65c816 - main cpu - currently in arm asm (straight port from the gp32 version)
spc700 - sound cpu - currently in c code (but someone has posted an asm cpu core for the spc700, so that will be implemented in the future)

sound mixing is in c, sound decoding is in assembler.

The main problem for speed on the snes is still the graphic emulation. If you do everything apart from rendering the graphics, the fps goes through the roof, showing that the rest of the system isn't really a bottleneck at all.

I've not looked at reesy's latest code, but I would think that the current speedup is due to the forced nature of fastsprites and possibly other optimisations, rather than the removal of the battery checking code.

 

[Reesy]

I've not looked at reesy's latest code, but I would think that the current speedup is due to the forced nature of fastsprites and possibly other optimisations, rather than the removal of the battery checking code.

I've doubled checked the code. If I put the battery check code back in right now, I lose 10fps. There's nothing wrong with the code you've written it must be something in the driver behind /dev/batt.