GNU/Linux compatibility

[RyDroid]

Hi.

It would be nice if PJ64 became natively compatible with GNU/Linux.
Have you planed to do it ?

[zilmar]

I have no plans for doing it as I do not use linux at all.

most of the emu is open source now so it should not be to bad to convert it, that being said there is still a lot of windows stuff there.

I have a a library called common it would be nice if I could move all windows calls in to it and then have a linux version of the common as a separate version.

Also the core makes use of structured exception handling, not sure how well that converts to the linux world.

[twostars]

Originally Posted by zilmar

Also the core makes use of structured exception handling, not sure how well that converts to the linux world.

Hmm, the only way I can think of handling that is with signals. :/

Edit:
It seems someone's tried to address this: syprog.blogspot.com.au/2012/02/vectored-exception-handling-for-linux.html
Not quite the same, but it's a lot more manageable than using signals as-is (which won't give you any context).

IBM also has an article on it: ibm.com/developerworks/library/l-cppexcep/index.html
Interesting stuff!

[zilmar]

Originally Posted by twostars

Hmm, the only way I can think of handling that is with signals. :/

it does not check if it is rdram on not on read/writes, just executes it.

If it is not, a structured exception occurs, the structure exception handler then looks at the asm opcode causing the error, detects if it is actually in the n64 zone and maps to a n64 register address. If it does then it cause the read/write to register, setups up the x86 ops that should be filled with that value, moves EIP to the next instruction and tells the cpu to continue executing.

Not sure if that would work with signals, possible the whole memory management needs to be re-written to allow porting to linux.

[twostars]

Originally Posted by zilmar

it does not check if it is rdram on not on read/writes, just executes it.

If it is not, a structured exception occurs, the structure exception handler then looks at the asm opcode causing the error, detects if it is actually in the n64 zone and maps to a n64 register address. If it does then it cause the read/write to register, setups up the x86 ops that should be filled with that value, moves EIP to the next instruction and tells the cpu to continue executing.

Not sure if that would work with signals, possible the whole memory management needs to be re-written to allow porting to linux.

Yeah, that's half the trouble with using signals (or vectored exception handling, for that matter) as is -- context management. The flow of logic just becomes a bit cumbersome.

It could still work, it'd just be really messy keeping track of where you are/what tripped it, and resuming logic -- it might even work better coupled with typical C exception handling (setjmp(), longjmp()).

I might have a play around with it, though to figure out just how feasible that would be with the current system... perhaps rewriting it would be the better plan, here. :/

Edit: Wow, just found the code you were referring to. This might indeed be a tad infeasible to port as it is. It's a little bit more complicated than your post indicates. :P

I'm really new to emulation, so forgive me, but what's the reason behind all this to begin with? Is it typical behaviour for ROMs to access invalid memory, or is it more that it was just easier to handle certain behaviour like this? Or is it simply old legacy code that isn't strictly so necessary anymore?

Rather, what I'm saying is: what's the reason behind not differentiating in these cases?

[zilmar]

Simple idea, the actual code is a lot more complicated.

The options are that I see:

• Use SEH (which pj64 is doing)
• Check address range on each read/write
• have a function write table, where you pass the address in and execute the function in the list

the last one I had considered, since i am already looking up in essence on 4k memory address to check if an address is translated from virtual to physical.

Where at the moment I get a pointer, I write to it, if it is null then I generate an exception.

maybe if null .. then call the function.

Partly I considered this for be able to detect easier when writing to cfb.

Not sure of the performance issues. (causing an exception is very slow, with re compiler and advanced block linking, it does not happen that much).

[zilmar]

Originally Posted by twostars

I'm really new to emulation, so forgive me, but what's the reason behind all this to begin with? Is it typical behaviour for ROMs to access invalid memory, or is it more that it was just easier to handle certain behaviour like this? Or is it simply old legacy code that isn't strictly so necessary anymore?

Rather, what I'm saying is: what's the reason behind not differentiating in these cases?

the n64 memory space:

0x0000 0000 to 0x03EF FFFF RDRAM Memory
0x03F0 0000 to 0x03FF FFFF RDRAM Registers
0x0400 0000 to 0x040F FFFF SP Registers
0x0410 0000 to 0x041F FFFF DP Command Registers
0x0420 0000 to 0x042F FFFF DP Span Registers
0x0430 0000 to 0x043F FFFF MIPS Interface (MI) Registers
0x0440 0000 to 0x044F FFFF Video Interface (VI) Registers
0x0450 0000 to 0x045F FFFF Audio Interface (AI) Registers
0x0460 0000 to 0x046F FFFF Peripheral Interface (PI) Registers
0x0470 0000 to 0x047F FFFF RDRAM Interface (RI) Registers
0x0480 0000 to 0x048F FFFF Serial Interface (SI) Registers
0x0490 0000 to 0x04FF FFFF Unused
0x0500 0000 to 0x05FF FFFF Cartridge Domain 2 Address 1
0x0600 0000 to 0x07FF FFFF Cartridge Domain 1 Address 1
0x0800 0000 to 0x0FFF FFFF Cartridge Domain 2 Address 2
0x1000 0000 to 0x1FBF FFFF Cartridge Domain 1 Address 2
0x1FC0 0000 to 0x1FC0 07BF PIF Boot ROM
0x1FC0 07C0 to 0x1FC0 07FF PIF RAM
0x1FC0 0800 to 0x1FCF FFFF Reserved
0x1FD0 0000 to 0x7FFF FFFF Cartridge Domain 1 Address 3
0x8000 0000 to 0xFFFF FFFF External SysAD Device

I reserve a memory space of 0x1FF00000

so instead of detecting on each read/write to the address space to see if it is to a special area or rdram, I just assume it is rdram and detect the exception when it fails.