>I know that Tom is a "hardware emulator" fan who likes to emulate >strange podules and all that. I don't know which direction Matthew and >Peter prefer.
I believe they also prefer the 'hardware emulator' route. I'm mainly a 'hardware emulator' person, simply because I've never been very convinced that the sort of changes you describe are worth the effort required. I've tried similar changes in the past - the 8mb VRAM hack doesn't break anything (in theory you could put 8mb in a RiscPC anyway) and is reasonably useful, though it does require patching the OS. An attempt at trapping ADFS block commands and redirecting to native code, however, didn't give much speed improvement and had the potential to cause problems. Very little of this work would give a noticeable speed increase (which I believe is the desired outcome). What is necessary for this is for major work to be done to the recompiler - preferably by someone with knowledge of compilers. I attempted this sort of work earlier in the summer, but ran up against the limits of my knowledge fairly quickly (the result is still useable though, and I'd be willing to make it available as a starting point - it translates into a platform-independent intermediate, then into native machine code, with scope for optimisation at both stages). Another approach which might work well would be to bin the current MMU/TLB emulation and use a VirtualAlloc() style scheme to directly map ARM address space onto native address space, which might give improvements, though it will hurt portability. Tom
_______________________________________________ Rpcemu mailing list [email protected] http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
