Right, another new version: http://www.phlamethrower.co.uk/misc2/arcem-src.zip (Source) http://www.phlamethrower.co.uk/misc2/arcem.zip (RISC OS build)
General changes: * Fixed support for 512K & 1MB memory (and perhaps 256K, although I've left that disabled for now since I haven't been able to find anything it works with). Also, 2MB configurations will now use a 16K page size instead of 32K. Getting this working involved replicating the different ways that MEMC generates the row & column addresses, according to the current page size selection. However since ArcEm doesn't deal with row & column addresses, what actually happens is that the addresses get translated twice - from physical address to a row,column address, via the current MEMC page size, and then from row,column to physical, via the "correct" page size for the amount of RAM that's being emulated. If the OS correctly detects how much RAM is fitted then it should choose a page size that's identical to our "correct" one, resulting in a 1:1 mapping. ArcEm currently relies on the two values matching for audio & video DMA to work properly. * Integrated the latest HostFS code from RPCEmu (including Sprow's fix for files >2GB). The emulaor code needed tweaking a bit, but the support modules loaded by RISC OS are identical to the RPCEmu versions (including retaining the RPCEmu name!). * Merged riscos-single/hostfs.c into the main hostsfs code (this was the modified hostfs code I made for use on RISC OS hosts, but to reduce the risk of bugs creeping in it's probably best if the two files were merged). * Added some new functions to arch/filecalls.h and a new file arch/filecommon.c. These functions allow data to be read/written from files to either buffers in emulator memory format, or to buffers in emulator memory. They know how to use the fastmap to access memory directly, and there's some buffering code to avoid lots of calls to fread/fwrite, so with any luck they'll provide good performance on all hosts. * Made the hostfs code & initial ROM loading use the new functions. * Fixed the Amiga IGraphics->SetRGB32 calls to multiply by 0x11111111 instead of 0x11000000 * Fixed a couple of bugs in the new endian-swapping memcpy functions * Added a couple of new performance-boosting options to the palettised display driver. "DisplayDev_UseUpdateFlags" controls whether MEMC.UpdateFlags is used to track writes to DMA-capable RAM (i.e. screen memory). Previously ArcEm was always tracking writes, but the write tracking is wholly unnecessary in most games, since they use multiple screen banks (and ArcEm is forced to redraw the entire screen when the DMA addresses get updated). So setting this option to 0 will disable all the memory write tracking, which seems to give a 10%-20% speed boost when I was testing it on my Iyonix. However when disabling the option you do need to set the correct PDD_FrameSkip value (the frameskip counter will be used as a failsafe to force a screen redraw, for situations where the game has stopped flipping screen buffers). Also when toggling the option on & off you need to call ARMul_RebuildFastMap() to ensure the fastmap entries reflect the current setting. * The second new option is DisplayDev_AutoUpdateFlags. If set to 1, this will cause the display device to automatically select whether the UpdateFlags option should be on or off, and to pick the correct failsafe frameskip value. This removes the hassle of requiring users to set the correct settings manually. RISC OS specific changes: * Added --nolowcolour option to prevent ArcEm from using 1/2/4bpp modes. E.g. on an Iyonix with Aemulor loaded, it's better for ArcEm to use an 8bpp mode than to rely on Aemulor's emulation of 1/2/4bpp modes. * Previously the border colour would only be displayed correctly if (a) you used the 16bpp display driver or (b) ArcEm was running in a colour depth greater than the depth of the emulated mode. However the code has now been improved to display the correct colour in (almost) all situations, so games which make heavy use of the border colour (e.g. Wolf 3D) should be much more playable. * Added the new palettised display performance options to the tweak menu. As mentioned above, this seems to give a 10%-20% performance boost on an Iyonix, which makes quite a few games a lot more playable. * Fixed the mouse cursor image being displayed one scanline above where it should have been Apart from requiring the new file access functions, I think the updated hostfs code should work unmodified under RPCEmu. So far I've only worked on making performance improvements; I haven't added any extra error checking, nor do I have any immediate plans to. Also I had a quick look at the syndicate issue that Chris mentioned; as far as I can tell this is just a case of syndicate being slow, and nothing to do with hostfs. On my Iyonix it did take one minute to load the game, but some timing code placed in hostfs suggested that the total amount of time spent performing file access was just two seconds. Cheers, - Jeffrey ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel