Another new version uploaded, same place as usual. A fair number of changes went into this version so I haven't attached a patch, but let me know if you'd like one.
http://www.phlamethrower.co.uk/misc2/arcem-src.zip (source) http://www.phlamethrower.co.uk/misc2/arcem.zip (RISC OS build) General changes: * Fixed LDRB & SWPB loading a word instead of a byte when going via the memory access functions. This was confusing the Joystick module into thinking joystick hardware was present, which was causing problems with some games responding to the bad joystick input. * Tweaked the IOC memory access functions a bit to make sure reads/writes of the joystick registers (and other IOEB registers) don't get passed to the HDC driver. * Fixed the aspect ratio correction to correctly apply horizontal scaling to modes like 320x480 * Tweaked a couple of things to get a couple of percent extra speed. * Fixed & improved the DumpHandler function. It'll now dump the registers for all modes, the MEMC page tables, and MEMC.PhysRam. * Tidied some of my debugging/profiling code away * Improved the handling of ARMul_EmuRate. The value now gets recalculated on VSync instead of at (effectively) random points during each frame. This means it's updated more often than it was before, so it can better adapt to changes in emulator load (important for the audio buffering). Additionally, the IOC timer & video clock rates will be recalculated at the same time, ensuring they stay in sync over the course of the frame. This solves a problem with the previous system where the IOC timer rate would update in the middle of a frame but the video clock rate would only update at the start of the frame, causing games to perform palette swaps at the wrong time. * Rewrote the sound code (again). The previous system tried to guess how many channels the system was using, which would lead to improper mixing if it didn't guess correctly (e.g. if all channels were set to the same stereo position). It could also cause the code to instruct the host to continually switch between two different sample rates if the stereo positions were manipulated in the right way. The new mixing algorithm avoids this guessing game by trying to more accurately emulate the time division multiplexing scheme that the Arc uses for its sound output. It's also able to resample the data to the native sample rate of the host, so it's no longer reliant on the host being able to support the unusual Arc sample rates. Although I've only tested it on RISC OS and Linux, this new code should work as-is on GP2X & Amiga too. The only downside is that it is a bit more CPU intensive than the old code. * As part of the above changes, I've also tweaked the Linux sound code to try and improve the poor buffering that the previous code suffered from. RISC OS specific changes: * The RISC OS binary is now compiled with GCC 4.6, which gave a performance boost of about 6% when compared to 4.1 * RISC OS sound buffering has also been tweaked a bit to improve its reliability. * I've tidied up my profiling code to make it more useful. When profiling is neabled, sound output will be disabled, and ARMul_EmuRate will be fixed at 8MHz. Although the profiling can't be toggled on & off at runtime, the tweak menu can be used to start/stop stats collection, allowing for more targeted profiling. Let me know what you think! Cheers, - Jeffrey ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
