Print

[scorp316]

QUOTE(Clockface @ Mar 22 2012, 07:58 AM)

Having four seperate memory banks is much better than just one of course, but it's a real pity that it's not one memory bank that's four times the size of the N64 standard memory bank.

True.  On Surreal64, the main issue I have with memory saves is that it is difficult to determine which save is for a certain game as these saves are coded under specific numbers and letters.   Sure it is easy to delete them from the game itself, but what if I want to try out someone elses save and don't want to delete nor replace my own save.  It's gonna be a pain searching for these coded saves. :/

It would be nice if the saves could be renamed to its proper title.
For example, for WWF No Mercy (which has three different pages of saves...i believe), the first page could be named WWF No Mercy1, the second one WWF No Mercy2, and the third page WWF No Mercy3.  

But I think the game would have to be editted to read those saves.  
This would make it a lot easier to find game saves.

[Master13]

I've always had that problem with my anti virus software. It either thinks its a suspicious file or its a virus. Don't worry as long as you got it from the official site you should be okay.

[hedgecore]

QUOTE(Master13 @ Apr 21 2012, 07:26 AM)

I've always had that problem with my anti virus software. It either thinks its a suspicious file or its a virus. Don't worry as long as you got it from the official site you should be okay.

Alright cool... that's what I figured anyway.  It's just a little intimidating seeing some big ass red window popping up telling you have a virus haha

Thanks!

[siudym]

I have downloaded 5.5 and i'm looking for the best settings for games: Turok1, ShadowMan, Banjo-Tooie, Donkey Kong 64 and Doom 64. Regards

[SSTG]

Hi hopefully have the right place I've been having problems with surreal64 CE b5.5

been recently trying to transfer a save of goldeneye with cheats on to the emulator with no luck I've turned the file to eep so it left me wondering if the right directory was set so I set it to E drive since for some reason it was set to D

I reset back to basic defaults before setting the directory

though now it freezes at the rom selection if I try to go to the menu or try to launch a rom



tried completely removing the whole folder from the xbox and retransfering it with no change

is there a file outside i need to find to get surreal working again?

an older version I put on works just as well but I have the same problem with it trying to read the save file

any help would be appreciated

[weinerschnitzel]

To clean up everything, delete your application folder and the XBOX save data in TDATA (E:\TDATA\64ce64ce\)

When you are importing saves, you will need to rename the save to the rom's CRC with each segment joined with a hyphen. Each save is in a folder based on the rom's 8 character CRC1 value. Surreal.ini is a great reference for these.

Model Format: ..\Saves\CRC1\CRC1-CRC2-REGION.EXTENSION

GoldenEye 007 EEP Save Example: ..\Saves\dcbc50d1\DCBC50D1-09FD1AA3-45.eep

This isn't very user friendly, but it holds the data without fear of FATX naming limitations.

[Sketcz]

Downloaded B5.5 and it doesn't work.

My Xbox chip is old, so I need to use dexbe.exe to patch every single XBE from debug to retail (why all modern XBE files start as debug by default I don't know, because it just means I can't boot them without patching first - a long time ago they ALL started off as retail).

I previously used an earlier build of B5, patching it first, and it worked fine. Most games had major glitches though.

Now I tried to patch all the files to retail and half of them don't patch. For example 1964-611.xbe will patch to retail, but 1964-611M.xbe stoically refuses to patch, and constantly defaults back to debug.

I ignored this and tried running it anyway - no dice! Loading Surreal64 via my custom dash just crashes it back to the dash. Why is this? Previous versions of Surreal64 worked fine!

[weinerschnitzel]

Those are Release_LTCG binaries, none of them are debug... Crashing might be due to some assets being missing. Check if you have all of your skin files, and make sure E:\TDATA\64CE64CE\surreal-ce.ini isn't looking for any skin you don't have.

Otherwise a clean install along with wiping the TDATA folder "64CE64CE" will get you going again. It might be that some leftovers from a previous install are messing with it. Good Luck!

[greenmile]

Thanks again to everyone who made this release possible - it's really top notch stuff. Can't thank you all enough really. I'm pretty sure I'll be playing Mario 64 on this emu past even the next gen of console - the orig Xbox will be in my entertainment cabinet for the next 50 years probably because of all the emulators on it.

Question: I thought last year there was talk of integrating the latest 1964 source into Surreal - is that still a thing? Or is there any other development plans for Surreal?

[weinerschnitzel]

1964...
Ez0n3 was working on it again last year with the help of schibo. It builds nicely using the same codebase as 1964 1.1 for PC, but it hasn't been touched since. The page reads for the rom in virtual memory are called from inline assembly that's been modified. I've spent some time reading up on these instructions and staring at each change and from what I make of it, it looks ok. unless writing to eax,ebx,ecx and edx make a difference in what order they are written to. Aren't they supposed to be general purpose though? I'm willing to spend the time if someone can help me with this.

The big issue lies here in dma.cpp:

CODE

            pushad
            mov ecx, i //mov eax, i
            mov edx, target
            //mov ebx, source
            align 16
_Label :
            //test ecx, ecx //surreal old - 0.85
            and ecx, ecx //and eax, eax //surreal new 1.1 - etempp

            jz _Label2
            push ecx //added
            push edx //added
            mov ecx, source //mov ecx, dword ptr[ebx]
            call ReadUWORDFromROM //added
            pop edx //added
            pop ecx //added
            inc ecx // inc eax //1.1 location //etempp
            mov dword ptr[edx], eax //mov dword ptr[edx], ecx
            add source, 4 //add ebx, 4
            add edx, 4
            //inc ecx //0.85 location
            jmp _Label
_Label2 :
            popad

1964 1.1 Win32 Working:

CODE

            pushad
            mov eax, i
            mov edx, target
            mov ebx, source
            align 16
_Label :
            and eax, eax
            jz _Label2
            mov ecx, dword ptr[ebx]
            inc eax
            mov dword ptr[edx], ecx
            add ebx, 4
            add edx, 4
            jmp _Label
_Label2 :
            popad

EDIT: Madmab read it for me and more or less confirmed this routine is ok. 1964 has many more changed inline ASM routines, with only a handful being related to XBOX changes. Ez0n3 and schibo left one or two other memory issue markers, this change in dma.cpp being the most significant.

You won't have to wait for this though, PJ64 1.6 works beautifully on the XBOX. The last thing I have to resolve is some issue where I FRAG or FRAO shortly after I load a save state. I've spent a good number of hours playing DK64, already. Gains are overall compatibility, speed, and stability. Nothing GFX wise has been fixed, nor is expected to be.

The project also intends to move away from the XDK samples in the launcher to let the code out as legit GPL, as it should be. But I am a sucker for XPR fonts and XMV videos.  I'll want to eventually work those in as a patch or something.

I've been posting about my progress on EmuXtras: http://www.emuxtras....?p=22780#p22780
 

[flavor]

Sorry, can't help you there, but WOW! Awesome work on the PJ64 update so far!