On Thu, 19 Oct 2011, Chris Young wrote:
On Wed, 19 Oct 2011 22:52:14 +0100 (GMT Daylight Time), Jeffrey Lee wrote:The problem was a bug in the endian swapping code, but it would only affect the last few bytes of the transfer. Any transfer which ended on a word boundary would have been OK. The attached patch should fix the issue, and I've updated the source archive with both mine and Chris's fixes.Sadly the problem persists even with that patch. To my untrained eye it looks like the directory catalog is being passed to HostFS on the RISC OS side and then being freed. RISC OS is later looking up filenames and getting a partially overwritten cached copy back.
Everything is working fine for me when using the !Boot you sent me last time. The directory scanning code is the same as before, and looks fairly robust to me, so I'd be surprised if that was causing the problem.
I've just had a thought that this sounds suspiciously related to this:* Added some new functions to arch/filecalls.h and a new file arch/filecommon.c. [...] 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.
You can disable the file buffering code by undefining USE_FILEBUFFER in arch/filecommon.c. If that doesn't work, then feel free to send me a copy of your current boot sequence.
There is one thing that comes to mind - the code in arch/filecommon.c assumes that temp_buf is 4 byte aligned. If that's not the case then it could cause all kinds of trouble with the endian swapping code. I've attached a patch that should hopefully force it to have the correct alignment, see if that's any help.
I've added the UpdateFlags/FrameSkip stuff to the configuration (see attached patch). With AutoUpdateFlags it is flying - I'm tempted to try compiling for 68k as it might even manage a usable speed there now!
Cool.What are peoples thoughts on adopting the use of the number types in stdint.h? So far I've been keeping away from them because I'm not sure whether all the platforms have compilers that support C99. But if we were to adopt them, it would make things a lot easier when I'm trying to work out what number types I should use for certain calculations. It wouldn't surprise me if things are horribly broken on systems where 'int' is only 16 bits.
Cheers, - Jeffrey
arcem7.diff
Description: Binary data
------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev
-- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
