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

Reply via email to