View Single Post
  #5  
Old 6th May 2013, 03:35 AM
twostars twostars is offline
Junior Member
 
Join Date: Nov 2008
Posts: 8
Default

Quote:
Originally Posted by zilmar View Post
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?

Last edited by twostars; 6th May 2013 at 04:02 AM.
Reply With Quote