Psx4gp2x Public Beta 2 Released.

[Franxis]

For Mobile Phone, get a Windows Mobile 5.0 phone, as PalmOS is on the way out, and Palm itself is now starting to use Windows Mobile for it's Palms.

The Zaurus is REALLY awesome. If you want an opensource PDA with full X11 640x480, I recommend the Zaurus Cxxx series. I love my C1000. Reminds me that I need to update psx4all on it. It runs great but could use a better control layout.

I have a better picture of what's going wrong with the dynarec. I took Tinnus' advice and limited everything down to the recompile function, recompiled jump operations, and called functions to C implementations of each PSX OP. Well it still has the same weird issue.

So the bug can be in either the recompile functions prologue or epilogue in which I basically inject a stmfd sp!, {r4-r10, lr} and epilogue of ldmia sp!, {r4-r10, pc}

Or it could be the CallFunction procedure where I basically load a function's address as a 32bit immediate (using an optimized method of the basic mov, orr, orr, orr) into R4, and also inject "mov lr, pc" "mov pc, r4". I tried many different methods of doing a long branch, and they all failed just like this simple method. I wasn't able to figure out how to calculate the offset from the PC, to construct a BL op. I figure what im doing now would be equivelant to BL though. So hmm.

Or it could be the PSX opcode's J / BNE, but I highly doubt it, as they're pretty straightforward and simple. If J / BNE didn't work, it wouldn't of made it as far into the BIOS as it does.

Any ideas?

ZodTTD

Release the source code?

 

[Wite_Noiz]

Any ideas?

ZodTTD

Pah! That's so simple I can't be bothered to give you the answer

 

[zodttd]

Franxis: Didn't Unai offer you the source already?

I'm strongly considering releasing the source actually. Unai and I have dicussed this in the past. We would like to release the source, but we want to get a release candidate worthy version out first before we go through the process.

The problem with the dynarec seems to be within the generation of bytecode to call a function from within the recompiled function. Something is getting clobbered within the branched code. I think it might have to do with exception handling. During some calls to a function it branches and links fine, returning to the link register I originally set (PC right before the branch OP), but other times it will return to the branch OP instruction (the set LR minus 4) strangely looping a dozen times or so then finally exiting.

I was thinking it might of been some sort of exception like a data abort or something that causes the LR to be changed to reflect a interrupt. I don't know.

If we can solve this strange issue, it would help a whole lot!

 

[Pickle]

I have a better picture of what's going wrong with the dynarec. I took Tinnus' advice and limited everything down to the recompile function, recompiled jump operations, and called functions to C implementations of each PSX OP. Well it still has the same weird issue.
ZodTTD

I think you should describe the bug/issue more,
if I understand dynarec correctly are you able to recompile th PCX ASM to ARM ASM and your issue comes up when you run the new assembled exec?

Note, i posted and then i saw the post above, so more info on the problem is good. It sounds the best way to solve this problem is to have a step by step listing of the registers and instructions that occur over time.

 

[Kyalami]

Does Command and Conquer: Red Alert work on the emulator? It says it does in the wiki, but I just wanted you guys' opinion on how playable it is!
What about Driver, and Gran Turismo, btw?

 

[Tinnus]

The problem appears when we write ARM code that branches to someplace else. The Link Register, which sotres the return address, is being clobbered somewhere.

AT least that's what I understood.

 

[Pickle]

The problem appears when we write ARM code that branches to someplace else. The Link Register, which sotres the return address, is being clobbered somewhere.

AT least that's what I understood.

This may a very generalized idea, but is it possible to have two subroutines and the second blows away the link to the main loop?

Another idea, why not use a general register to store the link, and use it from that location to get by this problem?

 

[Sonic-NKT]

what about a psx4gp2x DEV thread

 

[TKF15H]

"Another idea, why not use a general register to store the link, and use it from that location to get by this problem?"
Because that would be a dirty hack. It'd just be covering up the problem which, as it is unknown, could have other consequences.

Does this happen on test code or BIOS/game code? 4 being subtracted from LR sounds intentional, like if on a PSX it actually did something usefull. If it was being clobbered, it would probably have some other totally unrelated value, right?

Just my 2 shots in the dark. ^_^

 

[Vimacs]

Yeah, i would strongly sugest you to create a seperate thread for developeing problems zodttd, i would delete evrything offtopic so you could have a qualified communication.

 

[Knoxximus]

Agreed...the peanut gallery might be getting a headache with the number crunching right about now.

 

[mahavailo7]

way to go guys, on the public release. I can really tell the difference.

Of course, I bet you guys are about fed up with praise by now, I'm sure. Offering praise to you is not what I have come here for; I have a dilema that perhaps a kind soul might help me with.

I have had my gp2x for a couple of weeks now (I was doing a lot of vacationing and didn't get around to doing a ton of crap with the thing). I inicially bought the gp2x for sake of emulation because I had done some on the PSP that I thought was cool. Although, to my dismay, I had some issues. First, off the topic of the PSX, I had trouble with the whole saving on squidgesnes, but luckily I got that all figured out (squidge needs to make some better read-me's or something). My second problem is that I'm having a hard time converting all my realone and quicktime videos to avi files. With these things aside, I figured it would still be worth the money if I could play FFVII and metalslugX on the little bugger. I sifted through a ton of posts for hours and finally found this new beta release, hoping that all the fancy menus and things would make it easier.

So please help me figure this guy out. I have done PSX emulation on PC and have the sch1007 bins file dealio all set in place like I know I have to. I also have a .BIN ISO of metalslugX. When I try to run the aformentioned ISO, the screen says: Loading Game..... Load Successful... then it sits there at a black screen. So I think: perhaps metalslug is just one of those games that isn't compatable; I'll move on to FFVII.

Now my FFVII disk one has three parts: ".cue" ".ccd" and ".img"

So I tried throwing all those on my SD card. The .cue and .ccd go on fine, but when I try copying the .img, an error comes up saying that it can't find the specified sector or something and thus can't finish loading. (same thing happens when I try to put videos on there! GRRRR!!!)

any help is appreciated.

there is a small catch though, just to avoid what some might suggest. I downloaded this ISO, opposed to ripping it. I do own the game, my computer is merely too crappy to want to work with the ripping software.

thanks so very much

 

[geise69]

First off why don't you play metal slug x with the neogeo emulator? :blink: It would run a billion times better plus save you space on your SD card. Now with FFVII I would get Ultra ISO and convert the CCD image to .bin/cue. You don't need to load the .cue file in the emulator. Select the .bin file from the game list when you're in PSX4All. That always works for me. By the way does that copy of FFVII you have work on a PC emulator. I'd test that out first. The cd image could be bad. Also I don't think this psx emulator supports ccd img files, just ISO and bin/cue formats or the compressed iso formats.

 

[Draco]

Make sure the sch1007.bin is all lowercase too.

Edit: No wait, it's actually scph1001.bin, maybe thats the problem?

 

[geise69]

Make sure the sch1007.bin is all lowercase too.

Edit: No wait, it's actually scph1001.bin, maybe thats the problem?

Yes it definitly would be

 

[trixom]

So I tried throwing all those on my SD card. The .cue and .ccd go on fine, but when I try copying the .img, an error comes up saying that it can't find the specified sector or something and thus can't finish loading. (same thing happens when I try to put videos on there! GRRRR!!!)

Have the same problem using the internal SD card reader of my Dell Laptop. Craps out using large files.

I simply bought on of those external 300 in 1 readers which worked perfectly.

T.

 

[wipeout2000]

300 in 1????

 

[Nr.56]

you have to rename your rom file to "scph1001.bin"
that should work. i think it´s the only accepted filename.

 

[shinneri]

Just use the correct bios file, which is the scph1001.bin. It's easy enough to find online...

 

[mahavailo7]

lol, that's what I meant. The bins file is named correctly, cause I coppied it straight from my ePSXe, which plays my ISOs just fine.

the problem with converting and doing stuff like that on my computer is that most converters and 3rd party software I have ever downloaded get fussy and don't like to run properly on my computer. If someone could direct me to one that works for them, I would try that and see how my luck yields. If nothing else, I'll be getting a new alienware computer ordered pretty soon, and I can simply wait and test some of these ideas on that.

the whole 300-1 usb reader thing intrigues me though. I have put a couple of naruto avis I have found and some red vs. blue on the gp2x with no problem, but most other things, like the output files I get from converters will give me that error "cannot find sector" message. Perhaps if I got a different device to relay these files to the SD card, this problem would resolve; for now, I'll probably turn this into a seperate rant which will go in the "videos on gp2x" forum.

thank you guys for being so helpful and responsive.