Squidgesnes 0.35 Hack

[masteryoda305]

http://reesy.gp32x.de/squidgesnes_dr2.zip

Try out the above version. I've changed the way frameskip is dealt with, its now the same as Squidges original version. I've also disabled 2d acceleration to see if it is causing the rom loading problems. Let me know if you have problems loading roms with this version.

​

That was the problem for me. No version of squidge worked until I used your dr2 build. It works well now, maybe a little slow.

 

[DaveC]

There is a Snes9x for the gp2x.  It has not been updated for a while though

​

That's based on the same source as Squidges port ... it's all yoyofr-snes9x derived.

​

I wonder why it runs smoother on the GP32 at a slower clock speed then? Certainly the GP2X should be a bit faster if anything. Maybe linux is slowing it down?

 

[primeris]

This works. It's consistently a bit slow, which is more playable than zippy-then-frozen. It also consistently loads .zips =D

I wonder why it runs smoother on the GP32 at a slower clock speed then? Certainly the GP2X should be a bit faster if anything. Maybe linux is slowing it down?

Well, the processors are different, aren't they? Lots of tweaking is required to port something AND have it run just as well. Many Dreamcast games ran tons better than their PS2 ports.

 

[Hanz™]

There is a Snes9x for the gp2x. It has not been updated for a while though

​

That's based on the same source as Squidges port ... it's all yoyofr-snes9x derived.

​

I wonder why it runs smoother on the GP32 at a slower clock speed then? Certainly the GP2X should be a bit faster if anything. Maybe linux is slowing it down?

​

It works way faster than the GP32 version for me. Defective GP2X maybe?

 

[Leshrac]

Still no response from squidge? I'd like to know wht does he think about this new version ; )

 

[DaveC]

This works. It's consistently a bit slow, which is more playable than zippy-then-frozen. It also consistently loads .zips =D

I wonder why it runs smoother on the GP32 at a slower clock speed then? Certainly the GP2X should be a bit faster if anything. Maybe linux is slowing it down?

Well, the processors are different, aren't they? Lots of tweaking is required to port something AND have it run just as well. Many Dreamcast games ran tons better than their PS2 ports.

​

The GP32 and GP2X both are ARM CPUs so no, not much different.

 

[devestation]

Nice job on the update. I have all my roms working for me in .zip form. Also, the colors are better than the .34 hack and the hardware scaling problem is gone.

However, do you think you could alter the fps limiter option? In this release, with it off, my games play too fast, and when it is on, they play way to slow.

 

[Muncher666]

Davey boy, mine's smooth as silk. They are both arm processors, but not the SAME arm processors. It's the same reason you can't just shove GBA stuff through the GP2x's processors and have it work.

Allan.

 

[god_at_hell]

i don't think your on a save side with your opinion, because:

1. The GBA uses a ARM7 and not a ARM9, so it's in fact a slightly different architecture. I don't think the differences between ARM7 and 9 are only better clockrates and more cache. The ARM9 should have a bigger instruction set.

2. The GP32 and GP2X utilize in fact the same architecture. They both use CPUs from the ARM9 fork, so they have the same instructionset and varation may only accure in things like embeddet systems, mmu/pu , clockrate and cache. The GP32 cpu should have a mmu (would be hard without ) and I don't think the cachesize of the 920T is smaller than the GP32-CPUs.

So, the GP2X CPU should be better in any way.

The only differences between the GP32 and GP2X code should be the direct hardware access on the gp32 and different screen allocation ... since i'm no raider of the lost code, i can't tell, if this is right, but anything about the cpu has to be the truth

 

[DaveC]

The only differences between the GP32 and GP2X code should be the direct hardware access on the gp32 and different screen allocation ... since i'm no raider of the lost code, i can't tell, if this is right, but anything about the cpu has to be the truth

​

I think the GP2X has hardware blitting and other features in it's 2D co-processor that the GP32 didn't. The GP2X display also scans horizontally like TVs rather than the goofy vertical scanning that the GP32 had. That alone should make the GP2X faster, then with the faster clock speed it should blow away the GP32. I am thinking this has to do with linux. If HH was used (if that ever happens) we may get alot more speed out of this thing.

 

[Leshrac]

1. The GBA uses a ARM7 and not a ARM9, so it's in fact a slightly different architecture. I don't think the differences between ARM7 and 9 are only better clockrates and more cache. The ARM9 should have a bigger instruction set.

Also, I think it is very likely that the ARM7 mounted on the gba is not an off-the-shelves ARM7 processor and has some custom opcodes thrown in. Gph is not the case, but big companies who can afford it usually do.

 

[naples39]

So what are people finding to be the fastest build? I've never had a problem with ROM launching, and just want to use the fastest.

 

[Drak]

http://reesy.gp32x.de/squidgesnes_dr2.zip

Try out the above version.  I've changed the way frameskip is dealt with, its now the same as Squidges original version.  I've also disabled 2d acceleration to see if it is causing the rom loading problems.  Let me know if you have problems loading roms with this version.

​

Does volume control work with this? Whenever I use madplay and snes starts up the volume goes way up to like 5 and hurts my ears ^^

btw whats with your genesis emu reesy? It doesnt seem to like madplay and I only get like 5fps. While with the snes emu I get 30 at like 266mhz with sound off hehe. I dont understand the stuff behind all this as all I can code is a simple pong game hah.

 

[primeris]

So what are people finding to be the fastest build? I've never had a problem with ROM launching, and just want to use the fastest.

Well, that's hard to answer, but the ones on the archives are too buggy to really be called "fast".

 

[kgcs10]

How to fix the game Kirby Superstar? All that happens is blank screen. All other games work a full speed.

 

[iignotus]

How to fix the game Kirby Superstar? All that happens is blank screen. All other games work a full speed.

​

I believe that uses a SuperFX chip or so, so emulation of the ROM won't come for a long time if at all. Much like Yoshi's Island.

 

[Reesy]

btw whats with your genesis emu reesy? It doesnt seem to like madplay and I only get like 5fps. While with the snes emu I get 30 at like 266mhz with sound off hehe. I dont understand the stuff behind all this as all I can code is a simple pong game hah.

Its probably because I still have a sound thread updating the /dev/psg device even when the emulator is not rendering sound. My sound thread current doubles as my frame timer, so it madplay is using dev/psg as well it will bugger up the timing in the emulator. I'll change this at some point but its not high on my list of priorities.

DaveC: The reason why the GP2X version is slower than the GP32 version ( relatively speaking anyway ) is because the GP2X version is missing the ARM ASM tile rendering written by Yoyo. We can't use the code he produced because it is optimised for the back to front frame buffer on the GP32.

The rendering code makes a lot of use of stm and ldm opcodes, these can load data into multiple registers all from 1 opcode or can save data from mulitple registers to memory all from 1 opcode. This dramatically reduces the amount of memory bandwidth used by the rendering routines, which makes them much faster.

The rendering routines need to be re-written for the GP2X frame buffer, this is something I'm going to do, as assember is what I enjoy most . In fact I'll probably get started now and leave 8bit mode for later.

 

[Drak]

btw whats with your genesis emu reesy? It doesnt seem to like madplay and I only get like 5fps. While with the snes emu I get 30 at like 266mhz with sound off hehe. I dont understand the stuff behind all this as all I can code is a simple pong game hah.

Its probably because I still have a sound thread updating the /dev/psg device even when the emulator is not rendering sound. My sound thread current doubles as my frame timer, so it madplay is using dev/psg as well it will bugger up the timing in the emulator. I'll change this at some point but its not high on my list of priorities.

DaveC: The reason why the GP2X version is slower than the GP32 version ( relatively speaking anyway ) is because the GP2X version is missing the ARM ASM tile rendering written by Yoyo. We can't use the code he produced because it is optimised for the back to front frame buffer on the GP32.

The rendering code makes a lot of use of stm and ldm opcodes, these can load data into multiple registers all from 1 opcode or can save data from mulitple registers to memory all from 1 opcode. This dramatically reduces the amount of memory bandwidth used by the rendering routines, which makes them much faster.

The rendering routines need to be re-written for the GP2X frame buffer, this is something I'm going to do, as assember is what I enjoy most . In fact I'll probably get started now and leave 8bit mode for later.

​

Ah well, thankyou for clearing that up for me. I didnt understand it and I love multi-tasking ^^

 

[DaveC]

The rendering routines need to be re-written for the GP2X frame buffer, this is something I'm going to do, as assember is what I enjoy most .  In fact I'll probably get started now and leave 8bit mode for later.

​

Wouldn't writing the ASM frame buffer AND using 8-bit mode be the fastest? What use is the 16 bit mode? I think the GP32 uses 8-bit rendering doesn't it? Isn't 16-bit only useful for transparencies, or are there other benefits? If 16 bit is only needed for transparencies, wouldn't 8-bit be the way to go since transparency rendering is to slow to be playable anyway? Just wondering what the thoughts were.

 

[Reesy]

Damm Dave you're never happy are you, fine 8bit it is!

Your probably right, the only reason 16bit would be usefull is that it could be extended to support transparency. Of course that's going to take time so its probably best I add a fast 8bit mode so every can enjoy fast Snes gaming until/if 16bit is done.

Actually the GP32 uses 16bit, 8bit mode runs at the same speed as 16bit mode due to the way its written. If you look at Yoyo's source code the 8bit ASM code is actually disabled because it crashes.