Gp2psx V0.36
- Thread starter zodttd
- Start date
zodttd
Solving your premature emulation since the Tapwave
From what I'm aware of the DC's GPU won't be of much help for PSX emulation. I'd have to get this confirmed with Chui, as this is just my speculation. The PSX uses it's own chipset for 3D calculations called the GTE. All PSX emulators I've seen do the GTE emulation in software without any hardware acceleration. My hope is that I figure out the DynaRec and get it working on ARM, as the GTE can be recompiled as well, at least for sure on the X86 platform.
I guess that's what I should focus on today, the DynaRec, as it will benefit us the most at this point. ARM's website has a good amount of documentation on the ARM920T. What I'm looking for in particular is the bytecodes for each ARM instruction. I don't know the term used for this, so the best I can describe it is during recompilation the equivelant ARM OPCODE gets pushed into a buffer and the buffer is executed. When putting the OPCODE into the buffer, it's in a numerical form, of course. I need those numbers for GP2X's ARM OPCODES. If it sounds like I have no clue what I'm doing, you're pretty close to right. But I'm very good at getting something working when I know little about it, so flames aside, just knowing the correct term to search for what I'm looking for would help.
I will read up more on dynarec's, but I really think I could get this working with a bit of help. I'll begin work on it now, and start looking for the opcode information as well. An idea just popped into my head would be to look at ARM emulators out there and see if they provide any tidbits of info. Just go in reverse.
I already have the framework for the dynarec, I just need to fill in the blanks so to speak.
Recompiler time it is!
Tinnus just gave me a great piece of code for help with the DynaRec. Basically a JIT compiler for ARM for use with GP2X / PalmOS. This may help quite a lot. I'll give an update in a bit about the status of things.
I guess that's what I should focus on today, the DynaRec, as it will benefit us the most at this point. ARM's website has a good amount of documentation on the ARM920T. What I'm looking for in particular is the bytecodes for each ARM instruction. I don't know the term used for this, so the best I can describe it is during recompilation the equivelant ARM OPCODE gets pushed into a buffer and the buffer is executed. When putting the OPCODE into the buffer, it's in a numerical form, of course. I need those numbers for GP2X's ARM OPCODES. If it sounds like I have no clue what I'm doing, you're pretty close to right. But I'm very good at getting something working when I know little about it, so flames aside, just knowing the correct term to search for what I'm looking for would help.
I will read up more on dynarec's, but I really think I could get this working with a bit of help. I'll begin work on it now, and start looking for the opcode information as well. An idea just popped into my head would be to look at ARM emulators out there and see if they provide any tidbits of info. Just go in reverse.
I already have the framework for the dynarec, I just need to fill in the blanks so to speak.
Recompiler time it is!
Tinnus just gave me a great piece of code for help with the DynaRec. Basically a JIT compiler for ARM for use with GP2X / PalmOS. This may help quite a lot. I'll give an update in a bit about the status of things.
hannanshah
Still Fresh
- Joined
- Feb 9, 2006
- Messages
- 54
Keep up the excellent work. The scene is due a big release!
daclassicgamingmaster
It Is Your Birthday.
hey zodttd, good to see you're still around
zodttd
Solving your premature emulation since the Tapwave
http://forums.ngemu.com/web-development-pr...troduction.html
That is a great site for DynaRec authors! Notice he gave up on a DynaRec for the 200MHz StrongARM. He wasn't able to get peephole optimizations working well and said screw it so it seems.
He refered to what I needed as "hexcodes" for the ARM instructions. I guess that's appropriate.
The hexcodes seem to be dependant on what the operation being translated is, so there hasn't been a list of these hexcodes made often. They are out there for Intel based stuff, but trying to find them for ARM is being tough. I'm still digging.
If anyone finds a list of appropriate hexcodes for ARM operations (I really don't like the term hexcodes heh) then by all means reply with a link or PM me. Thanks!
That is a great site for DynaRec authors! Notice he gave up on a DynaRec for the 200MHz StrongARM. He wasn't able to get peephole optimizations working well and said screw it so it seems.
He refered to what I needed as "hexcodes" for the ARM instructions. I guess that's appropriate.
The hexcodes seem to be dependant on what the operation being translated is, so there hasn't been a list of these hexcodes made often. They are out there for Intel based stuff, but trying to find them for ARM is being tough. I'm still digging.
If anyone finds a list of appropriate hexcodes for ARM operations (I really don't like the term hexcodes heh) then by all means reply with a link or PM me. Thanks!
foft
Certified Guru
Is this what you're after? Its got all the bits to set etc for the arm instruction sets (including arm9tdmi).
http://www.altera.com/literature/third-par...00e_arm_arm.pdf
Thanks,
Mark
http://www.altera.com/literature/third-par...00e_arm_arm.pdf
Thanks,
Mark
arm emulators on x86 and dynarec links for interested
http://armphetamine.sourceforge.net/#links
http://arcem.sourceforge.net/
http://armphetamine.sourceforge.net/#links
http://arcem.sourceforge.net/
zodttd
Solving your premature emulation since the Tapwave
Thanks foft and evol!
foft: That PDF is awesome! It gave me exactly what was needed to start coding the dynarec.
I began work on the DynaRec. Taking my first baby step, I implemented the ADD instruction so that it get's written to a 32bit buffer. I basically have to tell the recompiler what to do for each R3000A (PSX) instruction, by giving it equivelant ARM instructions. So in turn I have to tell the recompiler how to put each ARM instruction into a buffer to be executed. So I'm going to go through all the ARM instructions I think will be used and get the 32 bit's set correctly and pushed into a buffer. So far ADD and SUB are done. 14 more math instructions to go. Then the rest.
The tricky part will be to get the logic part done right. Such as, when doing a jump on R3000A, how is it handled on the ARM? Then how do you simplify it to get better speed. As the articles from evol say, you can't always do a OPCode to OPCode translation. You sometimes need other instructions to handle certain conditions. I'll ask for some help with this from Unai and Chui, but if someone will offer help with this, please let me know either by replying or PM! Thanks.
More status updates soon to come.
foft: That PDF is awesome! It gave me exactly what was needed to start coding the dynarec.
I began work on the DynaRec. Taking my first baby step, I implemented the ADD instruction so that it get's written to a 32bit buffer. I basically have to tell the recompiler what to do for each R3000A (PSX) instruction, by giving it equivelant ARM instructions. So in turn I have to tell the recompiler how to put each ARM instruction into a buffer to be executed. So I'm going to go through all the ARM instructions I think will be used and get the 32 bit's set correctly and pushed into a buffer. So far ADD and SUB are done. 14 more math instructions to go. Then the rest.
The tricky part will be to get the logic part done right. Such as, when doing a jump on R3000A, how is it handled on the ARM? Then how do you simplify it to get better speed. As the articles from evol say, you can't always do a OPCode to OPCode translation. You sometimes need other instructions to handle certain conditions. I'll ask for some help with this from Unai and Chui, but if someone will offer help with this, please let me know either by replying or PM! Thanks.
More status updates soon to come.
moz
load *,8,1
the in progress updates are fasinating and apriciated
Phil
FAPPO!
I'm as excited about the theory as I am about the actual releases! Really interesting (and excellent) work.
Crazy Goat
Member
- Joined
- Feb 10, 2006
- Messages
- 199
Will you have my babies?!
Sounds most excellent - it seems as if everything is going well. You are doing great - and thank you for your work!
Sounds most excellent - it seems as if everything is going well. You are doing great - and thank you for your work!
zodttd
Solving your premature emulation since the Tapwave
Most of the work lately has been from Unai and Chui. But I'm going to get back into things by pulling off this dynarec as I said I would do when I first got Unai aboard.
I currently have all the ARM instructions bitfields correctly done. This was made extremely easy due to Tinnus being kind enough to point me in the direction of Vincent, which uses a JIT (Just In Time) compiler for ARM. I was able to use the macro's to create the bitfields for each ARM instruction from Vincent for use with the dynarec.
So now I'm up to the hard part, emulating the R3000A instruction set. Luckily I have two examples to work off of and am working on getting the ARM dynarec into "full gear" now.
I'm also wondering if Vincent's OpenGL for the GP2X could be used for the GPU in GP2PSX, as it seems very well written and fast.
Ok, time for another hour of working on the dynarec...
I currently have all the ARM instructions bitfields correctly done. This was made extremely easy due to Tinnus being kind enough to point me in the direction of Vincent, which uses a JIT (Just In Time) compiler for ARM. I was able to use the macro's to create the bitfields for each ARM instruction from Vincent for use with the dynarec.
So now I'm up to the hard part, emulating the R3000A instruction set. Luckily I have two examples to work off of and am working on getting the ARM dynarec into "full gear" now.
I'm also wondering if Vincent's OpenGL for the GP2X could be used for the GPU in GP2PSX, as it seems very well written and fast.
Ok, time for another hour of working on the dynarec...
Vimacs
Don't be evil!
I hope you know how much appreciated your work is
zodttd: you usually just stop recompiling when you meet a JUMP
Start from point zero, translating everything until you find a JUMP. Then you store this "block of code" in the translation cache. Then you execute that block, then after that you start translating R3000A code, starting from the address the JUMP told you to go, until you encounter another JUMP... and so on.
That's what I understand from what I've read.
edit: ah, about Vincent rendering: that'd be fun. You should take note that VIncent has linear texture filtering, VERY fast. That'd be useful when/if PSX gets playable, it shoudln't suck more than 1 FPS from my tests anyway
Start from point zero, translating everything until you find a JUMP. Then you store this "block of code" in the translation cache. Then you execute that block, then after that you start translating R3000A code, starting from the address the JUMP told you to go, until you encounter another JUMP... and so on.
That's what I understand from what I've read.
edit: ah, about Vincent rendering: that'd be fun. You should take note that VIncent has linear texture filtering, VERY fast. That'd be useful when/if PSX gets playable, it shoudln't suck more than 1 FPS from my tests anyway
zodttd
Solving your premature emulation since the Tapwave
Tinnus: That part of the code is pretty well laid out. The part I'm having trouble with is taking a R3000A instruction and converting it into ARM instructions. Each R3000A instruction used by the emulator must be translated. Since I don't know much ARM assembly beyond blitting operations this is becoming hard for me to do.
So an update on things...I really suck with ARM assembly. I *really* need someone with a bit or more of ARM assembly expierence to help me with this dynamic recompiler. I can supply all the code needed to get started and some working code for a X86 dynarec to help show how the framework goes.
This is what needs to be done:
- Implement each R3000A processor instruction used by the emulator into equivelant ARM instructions.
- There's only a handful of instructions needed to be converted from the R3000A.
- The recompiler work that needs to be done doesn't need to be complete, , I just need to get the hang of things. So if you only have time to do a function or two, that's alright!
- I have all of the ARM instructions in the form of macros to use for use with converting R3000A instructions. The ARM instruction macro's build the buffer of instructions to be executed.
- If none of this makes sense, but you still understand ARM assembly, I can explain what needs to be done in further detail.
Basically, I need a little help to get the ball rolling forward with the dynamic recompiler. It's my lack of ARM assembly knowledge that's stopping me. So any help with this is appreciated. Feel free to PM me or reply here if you want to help.
I believe this technique for speeding up this emulator is very feasible and can be done soon with some help.
Thanks!
So an update on things...I really suck with ARM assembly. I *really* need someone with a bit or more of ARM assembly expierence to help me with this dynamic recompiler. I can supply all the code needed to get started and some working code for a X86 dynarec to help show how the framework goes.
This is what needs to be done:
- Implement each R3000A processor instruction used by the emulator into equivelant ARM instructions.
- There's only a handful of instructions needed to be converted from the R3000A.
- The recompiler work that needs to be done doesn't need to be complete, , I just need to get the hang of things. So if you only have time to do a function or two, that's alright!
- I have all of the ARM instructions in the form of macros to use for use with converting R3000A instructions. The ARM instruction macro's build the buffer of instructions to be executed.
- If none of this makes sense, but you still understand ARM assembly, I can explain what needs to be done in further detail.
Basically, I need a little help to get the ball rolling forward with the dynamic recompiler. It's my lack of ARM assembly knowledge that's stopping me. So any help with this is appreciated. Feel free to PM me or reply here if you want to help.
I believe this technique for speeding up this emulator is very feasible and can be done soon with some help.
Thanks!
reallynotnick
The smartest newb
Wow, when people start speaking gibberish to me I know something good is going to happen!
It seems like a lot has been going on, how much do you think this is going to improve the emulator compared to .36?
Also do you plan on releasing a new version anytime soon, or are you waiting to have all your aces and then lay them down?
Keep up the great work Zottd.
It seems like a lot has been going on, how much do you think this is going to improve the emulator compared to .36?
Also do you plan on releasing a new version anytime soon, or are you waiting to have all your aces and then lay them down?
Keep up the great work Zottd.
Shikaku
ROFL THE WORD PENIS IS HILARIOUS!
reallynotnick posted on Apr 23 2006 at 12:38 PM said:
Most of it is not jibberish to me...
But let me assure you it is good news =p
Last edited by a moderator:
