Project L Unmasked
- Thread starter link343
- Start date
Sorry man i fixed the post now was wanting to get the opinions of the people over at SegaXtreme quickly.
Wouldn't it also prove more effecient to create a saturn emulator based on the DC and its particular hardware rather than port an emulator designed to run on something else?
I know I dont know much about this, but that seems like the best angle of attack if people are seriously going to attempt this and put alot of time and energy into it.
I know I dont know much about this, but that seems like the best angle of attack if people are seriously going to attempt this and put alot of time and energy into it.
Of course the best route would be to write an emulator from scratch specifically tailored to the DC hardware, but there is currently no one in the DC community with the skill, time, and desire to take on such a task. At least this port will provide a base allowing someone to rewrite a specific portion for the DC hardware and see immediate results.
I had an idea for dealing with endianness that I may as well mention here since there's a very good chance that I won't find time to properly test/code it anytime soon:
First of all, the main problem with just swapping the memory around and letting the code run is that we don't know ahead of time how a particular piece of data will be accessed, and the address changes depending on how the memory is swapped, so unless you want to take a trap exception on every MOV instruction, it's necessary to do some analysis of the code. If we simply byteswap a binary, we get valid little-endian instruction words, but only word (16-bit, Hitachi/Renesas terminology) accesses will retrieve correct data. The idea is to code a vaguely dynarec-like engine that instead of producing "native" code blocks makes selective changes to the existing binary, like so:
First of all, the main problem with just swapping the memory around and letting the code run is that we don't know ahead of time how a particular piece of data will be accessed, and the address changes depending on how the memory is swapped, so unless you want to take a trap exception on every MOV instruction, it's necessary to do some analysis of the code. If we simply byteswap a binary, we get valid little-endian instruction words, but only word (16-bit, Hitachi/Renesas terminology) accesses will retrieve correct data. The idea is to code a vaguely dynarec-like engine that instead of producing "native" code blocks makes selective changes to the existing binary, like so:
- Swap the target memory of PC-relative longword (32-bit) accesses
- Adjust the displacement of PC-relative word and byte accesses (word accesses only need to be adjusted when the same data is accessed by a longword access)
- Replace any access whose target address is not fixed with a trap instruction corresponding to the access width. The trap exception handlers would be comparable to the traditional methods of handling memory accesses in emulators.
Is it the procssor that makes the dreamcast operate in little indian format memory addressing or the memory controller?
antime
Extra Hard Mid Boss
The point is that you have no way of knowing if the program is loading a 32-bit constant or four independent bytes. In the latter case there's a good chance their order matters and swapping the bytes around won't work. Limiting the swapping to PC-relative accesses helps somewhat but can't be made foolproof.
Of course it can't be foolproof. In general you're not going to afford to be able to be foolproof (which would require, for instance, emulating pipeline hazards and memory contention) on any Saturn emulator with current PC performance levels, let alone on a Dreamcast. The question is which "cheats" are affordable in the face of actual usage.
Sure it will, you just need to modify the byte writes to account for the byteswapping. For PC relative mov instructions you just edit the individual offsets and for the ones based on an address in a register you xor the value before and after the read.
Maybe I glossed over this a bit too much, but the scanner would keep a master list of stuff it's touched, and if there's ever an access to the same address at both longword and another width it adjusts the offsets. Yes, this would add overhead, but it would only be checked on a new block, not every time a MOV instruction pops up.
Like I said, I'm not vouching for the feasibility of this idea, just putting it out there in case someone wants to try it, since my time will likely be heavily occupied by Real Life soon.
Like I said, I'm not vouching for the feasibility of this idea, just putting it out there in case someone wants to try it, since my time will likely be heavily occupied by Real Life soon.
I was assuming that swapping would be done on the writes as well. On a processor with a load-store instruction set that wouldn't be incredibly expensive, though it might be wise to use something closer to an actuall dynarec rather than using trap instructions. I'm not sure about the SH-4, but on the SH-2 exceptions were rather expensive.
antime
Extra Hard Mid Boss
Those are the main ones. Mixing prebuilt and runtime-generated VDP1 lists sounds like an interesting excercise.
<!--QuoteBegin-ExCyber@Jun 21, 2004 @ 07:54 PM
On a processor with a load-store instruction set that wouldn't be incredibly expensive, though it might be wise to use something closer to an actuall dynarec rather than using trap instructions. I'm not sure about the SH-4, but on the SH-2 exceptions were rather expensive.[/quote]
The book See MIPS Run suggests that about every tenth instruction is a store instruction. H&P probably has more data on the subject.
How expensive are MMU exceptions on the Dreamcast? Setting up a segment with only supervisor-level access would offer one way of trapping both reads and writes without modifying the code. On the other hand, the MMU doesn't seem to offer separate execute protection, so something would have to be figured out. Perhaps a separate segment mapped to the same physical memory (but different virtual addresses) from which the code is run? Pointer-based jumps would also be caught by the MMU and could be fixed up. (This will not help with PC-relative loads and stores though.)
By the way, it has occurred to me that it should be possible to point the same page of virtual memory at two different physical pages - one for instruction accesses and one for data accesses. The catch is that while doing this you must make absolutely sure that there is never an ITLB miss, because if there is it will go to the UTLB to find the page and grab the data page. I'm not sure whether or not this would be particularly useful.
Similar threads
