Re: Further RISC OS port work
In article Pine.WNT.4.62.1110301339020.2472@c203, Jeffrey Lee m...@phlamethrower.co.uk wrote: Hi Ralph, On Sun, 30 Oct 2011, Ralph Corderoy wrote: I'm editing the arcem-fast branch but wonder if that just means the main head will just atrophy. Should we just bung all of arcem-fast into main? You won't get any complaints from me. Yeah, I think arcem-fast brach should be merged back to trunk. It's not really obvious that the arcem-fast branch exists unless you follow development here. Also, the main homepage http://arcem.sourceforge.net/ could do with updating to mention the new version and that it's much faster, has better sound support, etc. :) -- Michael Drake http://www.smoothartist.com/ -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: Further RISC OS port work
On Sun, 30 Oct 2011, Ralph Corderoy wrote: Hi, Under 64-bit Linux I'm getting a window that doesn't handle expose events and New mode: 0x0, 400Hz (CR 0 ClockIn 24Mhz) rapidly scrolling up the screen. Anyone else see that? This is with arcem-fast straight from CVS followed by a `make'. Cheers, Ralph. I haven't got anything set up to test 64bit builds, but 32bit Linux is working fine here. I did just fix a compiler warning in arch/stddisplaydev.c that I must have missed earlier, but I'd be surprised if that was breaking it for you. Do you want me to look into it or are you happy to do it yourself? It sounds like a bug in the ARM emulation is stopping RISC OS from initialising the display. So comparing a trace of the PC in 32bit 64bit builds would be the easiest way of finding the problem. Cheers, - Jeffrey -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: Further RISC OS port work
Hi Jeffrey, Another new version: http://www.phlamethrower.co.uk/misc2/arcem-src.zip (Source) http://www.phlamethrower.co.uk/misc2/arcem.zip (RISC OS build) Given your continued work on arcem would it be worth using the central repository rather than many ZIP releases? When the repo gets updated now there will be a ton of diffs as a single big patch, possibly with a big changelog scraped from these emails. Starting to use it from now on would at least stop those bigs becoming huges. :-) Until that repo is updated you've effectively forked arcem with anyone else having to feed changes to you. Since your activity may encourage others to have a poke about again, that's a shame. If the repo was used again there's nothing to stop you popping up on the list and laying claim to it for a bit; If you've any outstanding stuff get it checked in because I want to do large re-work on the display code again over the next few days. I don't want to put an obstacle in your way that dissuades you from continuing, I just prefer lots of isolated check-ins, even if the repo's head turns out to be broken on some platforms for some of the time. Cheers, Ralph. -- 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
Re: Further RISC OS port work
On Sat, 22 Oct 2011 17:11:10 +0100 (GMT Daylight Time), Jeffrey Lee wrote: However unless Chris was talking about the 68k having 16bit ints, I don't see how ArcEm could have ever run on Amiga, as the most crucial data type (ARMword) has always been defined as being an unsigned int. Ah, maybe int is 32-bit then. I generally never use int as I'm not quite sure what size it is, but I thought it was 16-bit (maybe it is 16-bit on 68k and 32-bit on PPC) * So since the above isn't likely to have fixed the strange hostfs issues Chris is seeing, I've also added a 'OLD_FILECODE' option to hostfs.c. If this is enabled it will bypass my new file read/write functions completely, and use the original code. So with that option enabled the only difference between the current hostfs and the old hostfs will be the merge of the RISC OS version and the merge of the RPCEmu version. Amazingly, no real change :( On boot, just freezes. If I rename !Boot so it can't find it, opening HostFS within RISC OS gives the following two errors: Buffer overflow File '' not found Browsing further, I got another error about !Spritesâ Maybe it is a string termination issue? Is there any debug I can provide that would help? Chris -- 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
Re: Further RISC OS port work
On Thu, 20 Oct 2011 20:53:22 +0100 (GMT Daylight Time), Jeffrey Lee wrote: 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. That didn't work. 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. That didn't work. It wouldn't surprise me if things are horribly broken on systems where 'int' is only 16 bits. Erm, int is 16-bit here... maybe this is the issue? I'll save my !Boot for now - it is pretty much the same as before. I have no problem with stdint.h. Chris -- 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
Re: Further RISC OS port work
On Fri, 21 Oct 2011, Chris Young wrote: On Thu, 20 Oct 2011 20:53:22 +0100 (GMT Daylight Time), Jeffrey Lee wrote: It wouldn't surprise me if things are horribly broken on systems where 'int' is only 16 bits. Erm, int is 16-bit here... maybe this is the issue? I'll save my !Boot for now - it is pretty much the same as before. I have no problem with stdint.h. Ah, OK. In that case, I'll report back once I've converted everything to use stdint.h. Cheers, - Jeffrey -- 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
Re: Further RISC OS port work
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
Re: Further RISC OS port work
On Wed, 18 Oct 2011, Chris Young wrote: On Tue, 18 Oct 2011 19:53:22 +0100 (GMT Daylight Time), Jeffrey Lee wrote: Rather than keep breaking the Amiga version, I think I'll have a go at installing a version of QEMU that I can use to test the big-endian version of ArcEm. A quick google throws up a few how-to guides, so with any luck I should be able to get it sorted out sometime tonight. Good luck with that :) I'd be surprised if it is an endian issue causing this; I'd expect it to not boot or read from HostFS correctly at all if it was. Getting QEMU sorted out took a bit longer than expected (it didn't help that the Debian installer made the boot partition too small!), but I've now got a half-decent way of testing the big endian version. ArcEm runs a tad slow, but better than I was expecting. 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. Cheers, - Jeffrey arcem6.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@Ciosco 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
Re: Further RISC OS port work
On Wed, 19 Oct 2011 22:52:14 +0100 (GMT Daylight Time), Jeffrey Lee wrote:
Getting QEMU sorted out took a bit longer than expected (it didn't help
that the Debian installer made the boot partition too small!), but I've
now got a half-decent way of testing the big endian version. ArcEm runs a
tad slow, but better than I was expecting.
Whenever I install Debian, something different decides not to work on
every attempt. It seems to randomly decide not to install some
feature or some piece of hardware.
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.
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.
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!
Chris
--- RAM Disk:platform.h 2011-10-16 20:56:56
+++ Files:Projects/arcem-src/amiga/platform.h 2011-10-19 23:28:05
@@ -34,4 +34,5 @@ extern void cleanup(void);
extern void sound_exit(void);
int force8bit;
+static int PDD_FrameSkip;
#endif
--- RAM Disk:DispKbd.c 2011-10-16 20:56:56
+++ Files:Projects/arcem-src/amiga/DispKbd.c2011-10-19 23:17:44
@@ -376,9 +376,6 @@ static int BorderPalEntry;
#define MAX_DISPLAY_WIDTH 2048
static ARMword RowBuffer[MAX_DISPLAY_WIDTH/4];
-/* TODO - Allow this to be configured */
-static int PDD_FrameSkip = 0;
-
typedef struct {
int x,y; /* Current coordinates in pixels */
int width; /* Width of area being updated */
--- RAM Disk:wb.c 2011-10-16 20:56:56
+++ Files:Projects/arcem-src/amiga/wb.c 2011-10-19 23:27:20
@@ -10,6 +10,7 @@
#include ArcemConfig.h
#include platform.h
+#include displaydev.h
void wblaunch(struct WBStartup *);
void closewblibs(void);
@@ -134,6 +135,17 @@ void gettooltypes(struct WBArg *wbarg)
if(IIcon-FindToolType(toolarray,FORCE8BIT)) force8bit=1;
+ if(IIcon-FindToolType(toolarray, USEUPDATEFLAGS))
+ DisplayDev_UseUpdateFlags = 1;
+
+ if(s = (char *)IIcon-FindToolType(toolarray, FRAMESKIP))
+ PDD_FrameSkip = atoi(s);
+ else PDD_FrameSkip = 0;
+
+ if(IIcon-FindToolType(toolarray, AUTOUPDATEFLAGS))
+ DisplayDev_AutoUpdateFlags = 1;
+
+
/* This code implements ReadConfig.c via tooltypes - it
searches for
ST506DISC, but it will only support 1 line atm.
It is literally a copy'n'paste of the other code with
fscanf(fConf)
--
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@Ciosco 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
Re: Further RISC OS port work
On 17 Oct 2011 23:58:51 +, Chris Young wrote: On Sun, 16 Oct 2011 23:06:27 +0100 (GMT Daylight Time), Jeffrey Lee wrote: Right, another new version: A couple of changes to get it to compile attached (there may be a better place than hostfs.h for my #ifdef). However.. there seems to be a serious problem with this version, as I only seem to be getting as far as RPCEmu Host Filing System and than ArcEm freezes (or maybe busy-loops, either way I can't quit it) The problem is HostFS, I think it's an invalid pointer in the code somewhere. If I remove !Boot it loads up, however opening HostFS tries to open a file à followed by another called hen. Reboot and all the names of files it can't read have changed. Browsing and opening files is generally working though. I can send you my !Boot (again!) if it will help? Chris -- 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
Re: Further RISC OS port work
On Tue, 18 Oct 2011, Chris Young wrote: On 17 Oct 2011 23:58:51 +, Chris Young wrote: On Sun, 16 Oct 2011 23:06:27 +0100 (GMT Daylight Time), Jeffrey Lee wrote: Right, another new version: A couple of changes to get it to compile attached (there may be a better place than hostfs.h for my #ifdef). However.. there seems to be a serious problem with this version, as I only seem to be getting as far as RPCEmu Host Filing System and than ArcEm freezes (or maybe busy-loops, either way I can't quit it) The problem is HostFS, I think it's an invalid pointer in the code somewhere. If I remove !Boot it loads up, however opening HostFS tries to open a file à followed by another called hen. Reboot and all the names of files it can't read have changed. Browsing and opening files is generally working though. I can send you my !Boot (again!) if it will help? I'd expect it to be a bug in the endian swapping code which is causing data to be corrupted, since there's not much which could go wrong with the code that handles filenames (It's basically the same as before). Rather than keep breaking the Amiga version, I think I'll have a go at installing a version of QEMU that I can use to test the big-endian version of ArcEm. A quick google throws up a few how-to guides, so with any luck I should be able to get it sorted out sometime tonight. 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
Re: Further RISC OS port work
On Tue, 18 Oct 2011 19:53:22 +0100 (GMT Daylight Time), Jeffrey Lee wrote: On Tue, 18 Oct 2011, Chris Young wrote: The problem is HostFS, I think it's an invalid pointer in the code somewhere. If I remove !Boot it loads up, however opening HostFS tries to open a file à followed by another called hen. Reboot and all the names of files it can't read have changed. Browsing and opening files is generally working though. I can send you my !Boot (again!) if it will help? I'd expect it to be a bug in the endian swapping code which is causing data to be corrupted, since there's not much which could go wrong with the code that handles filenames (It's basically the same as before). It's odd, as if I do a *CAT all the filenames are ok, and I can see from the console output that it loads eg. VProtect without error before coming to a halt (if I leave !Boot in place), so everything is generally working. Rather than keep breaking the Amiga version, I think I'll have a go at installing a version of QEMU that I can use to test the big-endian version of ArcEm. A quick google throws up a few how-to guides, so with any luck I should be able to get it sorted out sometime tonight. Good luck with that :) I'd be surprised if it is an endian issue causing this; I'd expect it to not boot or read from HostFS correctly at all if it was. Chris -- 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
Re: Further RISC OS port work
On Sun, 16 Oct 2011 23:06:27 +0100 (GMT Daylight Time), Jeffrey Lee wrote: Right, another new version: A couple of changes to get it to compile attached (there may be a better place than hostfs.h for my #ifdef). However.. there seems to be a serious problem with this version, as I only seem to be getting as far as RPCEmu Host Filing System and than ArcEm freezes (or maybe busy-loops, either way I can't quit it) HostFS seems to be working, all the usual debug is getting chucked out up to this point, so there might be something else wrong. I'll try removing my !Boot when I have a bit more time, in case that is being troublesome. * 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!). Can we change this? Just to satisfy my OCD :) Chris --- ram:arcem-src/hostfs.h 2011-10-16 22:28:48 +++ Files:Projects/arcem-src/hostfs.h 2011-10-17 23:44:08 @@ -23,4 +23,9 @@ extern void hostfs(ARMul_State *state); extern void hostfs_init(void); extern void hostfs_reset(void); +#ifdef __amigaos4__ +#include sys/_types.h +typedef _off64_t off64_t; +#endif + #endif --- ram:arcem-src/Makefile 2011-10-16 20:56:56 +++ Files:Projects/arcem-src/Makefile 2011-10-17 23:41:06 @@ -104,7 +104,7 @@ SOUND_SUPPORT=yes SOUND_PTHREAD=no SRCS += amiga/wb.c amiga/arexx.c OBJS += amiga/wb.o amiga/arexx.o -CFLAGS += -mcrt=newlib +CFLAGS += -mcrt=newlib -D__LARGE64_FILES LDFLAGS += -mcrt=newlib # The following two lines are for Altivec support via libfreevec # Uncomment them if you are using a G4 or other PPC with Altivec --- ram:arcem-src/arch/filecommon.c 2011-10-16 21:46:46 +++ Files:Projects/arcem-src/arch/filecommon.c 2011-10-17 19:40:35 @@ -203,7 +203,7 @@ size_t File_ReadEmu(FILE *pFile,char *pB ret += read; pBuffer += read; uCount -= read; -temp = 0; + if(read count2) break; } -- 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
Re: Further RISC OS port work
Hi Chris, 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!). Can we change this? Just to satisfy my OCD :) Perhaps they'd consider changing to a more generic name? :-) Cheers, Ralph. -- 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
Re: Further RISC OS port work
On Thu, 13 Oct 2011 19:52:10 +0100 (GMT Daylight Time), Jeffrey Lee wrote: On Wed, 12 Oct 2011, Peter Howkins wrote: There have been several changes to hostfs that greatly improve its accuracy as a RISC OS filessystem. Yes, I'm looking in the right place. Although it won't help with the slow speed we seem to suffer from, I guess it would make sense to update to using the RPCEmu code. Be wary of any odd patches in the ArcEm version. I'm pretty sure I had to make a couple of changes so it would work on an AmigaOS host filesystem, and IIRC there were other similar things in there too for other hosts. Chris -- 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
Re: Further RISC OS port work
Hi Chris, That way, we're still specifying the maximum possible to SetRGB32(). Same goes for the mouse cursor palette patch. Google turned up http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node0328.html which also seems to suggest 0x_ is required. I'm pretty sure it ignores everything after the first byte, as the resolution for graphics cards is 8 bits per gun. Ah, OK, if it just truncates then fine. By taking 32-bits I was thinking 0x00ff_ would become 1 and not 0. Cheers, Ralph. -- 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
Re: Further RISC OS port work
Hi, Chris Young wrote: The only thing letting it down is disk access speed - I'm using HostFS, and loading anything substantial (eg. the Syndicate demo) can take several minutes despite the fact it now runs at near-enough full speed once loaded. From a quick look I suspect the ARMul_LoadByte()/ARMul_StoreByte() being used to move every transferred individual byte between the host buffer used by fread()/fwrite() and the ARM's memory space. As an aside, things like fwrite(), fseek(), etc., aren't having their return value checked. Cheers, Ralph. -- 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-d2dcopy1 -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: Further RISC OS port work
On Mon, 10 Oct 2011 11:57:12 +0100, Ralph Corderoy wrote: Before we were going from nibbles to bytes, 0xf - 0xff, now it's 0xf - 0xff00_. Shouldn't that be 0x_, e.g. ULONG r = ((phys 0xf) * 0x); That way, we're still specifying the maximum possible to SetRGB32(). Same goes for the mouse cursor palette patch. Google turned up http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node0328.html which also seems to suggest 0x_ is required. I'm pretty sure it ignores everything after the first byte, as the resolution for graphics cards is 8 bits per gun. However, technically you are right, it's neater and it works. I'm sure Jeffrey will update as appropriate :) Chris -- 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-d2dcopy1 -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: Further RISC OS port work
In article Pine.WNT.4.62.1110090200090.2404@c203, Jeffrey Lee m...@phlamethrower.co.uk wrote: Another new version uploaded http://www.phlamethrower.co.uk/misc2/arcem-src.zip (source) http://www.phlamethrower.co.uk/misc2/arcem.zip (RISC OS build) * The RISC OS binary is now compiled with GCC 4.6, which gave a performance boost of about 6% when compared to 4.1 Out of interest, is that 6% on an Iyonix, BeagleBoard or everywhere? Let me know what you think! I've been playing the Quark demo with it, and it's working nicely on my Iyonix. Thanks! -- Michael Drake http://www.smoothartist.com/ -- 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
Re: Further RISC OS port work
On Sun, 9 Oct 2011, Michael Drake wrote: In article Pine.WNT.4.62.1110090200090.2404@c203, Jeffrey Lee m...@phlamethrower.co.uk wrote: Another new version uploaded http://www.phlamethrower.co.uk/misc2/arcem-src.zip (source) http://www.phlamethrower.co.uk/misc2/arcem.zip (RISC OS build) * The RISC OS binary is now compiled with GCC 4.6, which gave a performance boost of about 6% when compared to 4.1 Out of interest, is that 6% on an Iyonix, BeagleBoard or everywhere? 6% on an Iyonix. I didn't check the beagleboard, but I'd expect a healthy improvement there as well. I've been doing some more tweaking today, so expect to see another release once I've sorted out the Amiga endianness issues. 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
Re: Further RISC OS port work
In article Pine.WNT.4.62.1110091621430.5184@c203, Jeffrey Lee m...@phlamethrower.co.uk wrote: On Sun, 9 Oct 2011, Michael Drake wrote: Out of interest, is that 6% on an Iyonix, BeagleBoard or everywhere? 6% on an Iyonix. I didn't check the beagleboard, but I'd expect a healthy improvement there as well. Nice. I thought most recent GCC improvement was for ARMv7 stuff. :) -- Michael Drake http://www.smoothartist.com/ -- 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
Re: Further RISC OS port work
On Sun, 9 Oct 2011 16:21:29 +0100 (GMT Daylight Time), Jeffrey Lee wrote: On Sun, 9 Oct 2011, Chris Young wrote: I've finally got round to having a proper look at the Amiga display code. The problem was that the palette wasn't being set, due to SetRGB32() taking a 32-bit left-aligned value for each colour component (I don't understand either; some sort of over-optimistic planning of how many colours would be needed in the future!) Oops! At least it was something simple. The only reason I noticed was because that has caught me out in the past. Very bizarre design decision. Ideally the display needs to be big endian (or endian-neutral) all the way through. Any ideas? Judging by the original code, it looks like all that's needed is to endian swap the source data. Some care will be needed with situations where the expand table or memcpy are used, but I think I can get the code to work. Stay tuned! Excellent, thanks! Chris -- 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
Re: Further RISC OS port work
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
Re: Further RISC OS port work
On Sun, 11 Sep 2011 18:31:54 +0100 (GMT Daylight Time), Jeffrey Lee wrote: I've made some minor changes to get it to compile (attached), however I'm not getting anything on the display at all! Ah, looks like I missed out the crucial call to IGraphics-BltBitMap(). That would do it... although I still seem to be getting nothing printed on screen. I'll have to trace through the code when I have more time and see if I can figure out what's missing. btw, there is a typo on line 599 of amiga/DispKbd.c (redarw) Regards Chris -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: Further RISC OS port work
On Sun, 11 Sep 2011, Chris Young wrote: On Sun, 4 Sep 2011 20:23:38 +0100 (GMT Daylight Time), Jeffrey Lee wrote: * Amiga GP2X display code has been modified to use the palettised driver. So with any luck both those platforms will work with only minimal fixes. However I haven't tried to add any endian swapping code, so you might need to sort that out yourself, Chris. The routines which do the data copying are in arch/displaydev.c, so that's probably the first place to start. I have a feeling it might be easiest to write seperate versions for big-endian hosts. I've made some minor changes to get it to compile (attached), however I'm not getting anything on the display at all! Ah, looks like I missed out the crucial call to IGraphics-BltBitMap(). I've attached a patch which should get things working, along with a couple of other small fixes (I've fixed the IOC timers running too fast, and fixed a couple of sound issues). I've also updated the archives on my site to contain the latest changes from both of us. Cheers, - Jeffrey arcem2.diff Description: Binary data -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/-- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: Further RISC OS port work
Right, third version uploaded, same place as before: http://www.phlamethrower.co.uk/misc2/arcem-src.zip (Source) http://www.phlamethrower.co.uk/misc2/arcem.zip (RISC OS build) Compared to the previous version, this one features: * New display driver for palettised output (arch/paldisplaydev.c). - It's somewhat similar to the stddisplaydev code, in that it needs to be #included directly with a bunch of #defines/etc. set up in order to allow it to interface with the host OS in the cleanest/most efficient manner. - The driver is able to convert the source data to any bit depth equal or higher than the source depth. (Well, not quite any depth - only depths which are powers-of-two are supported). - The driver also supports horizontal vertical upscaling, like the stddisplaydev code (Although like stddisplaydev, there are some restrictions - horizontal upscaling must be a power of 2, and each source pixel must convert to no more than 32 bits of output data). - BPP conversion upscaling is actually done through a lookup table, which made the code nice and easy to write, but won't always be the best for performance (e.g. for 4bpp or 8bpp source data, which is probably the ones people will encounter the most. Oops!). But if BPP conversion and upscaling aren't in use then it will just copy the data straight to the output, so it's not all bad. - Since it won't support mid-frame palette swaps, it just refreshes the screen once per frame instead of one scanline at a time. - This driver supports frameskip, which may be a useful performance boost on some hosts. (stddisplaydev currently doesn't support frameskip, but it shouldn't be too tricky to add it) * Amiga GP2X display code has been modified to use the palettised driver. So with any luck both those platforms will work with only minimal fixes. However I haven't tried to add any endian swapping code, so you might need to sort that out yourself, Chris. The routines which do the data copying are in arch/displaydev.c, so that's probably the first place to start. I have a feeling it might be easiest to write seperate versions for big-endian hosts. * RISC OS tweaks: - Added a tweak menu available by simultaneously pressing both Windows keys on the keyboard. This allows some of the display settings to be tweaked at runtime. - If enabled in the tweak menu, screenshots can be taken by hitting Print Screen - The tweak menu can also be used to toggle the display of some simple performance/display stats. - Supports both the palettised standard display drivers. Driver can be selected at initialisation via a new command line option, or switched at runtime via the tweak menu. Let me know what you think. Cheers, - Jeffrey -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: Further RISC OS port work
On Mon, 29 Aug 2011 00:45:59 +0100 (GMT Daylight Time), Jeffrey Lee wrote: * Amiga video code is half-updated, with the aim to use 16bpp output. However I'm having trouble finding any decent documentation, so I might leave the rest to you Chris, if that's OK? There's plenty of todo notes in there for the bits that need filling in. The old code uses a palette-mapped mode for simplicity, as ArcEm's emulated screen was only ever 8-bit maximum (is this still the case?). It then can just change the palette and plot the pens exactly as the emulated screen would be - which is quicker than converting the screen to 16bpp. Is this still possible? I'll have a look at the code and your todos when I get some time. Chris -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: Further RISC OS port work
Hi Ralph, On Wed, 24 Aug 2011, Ralph Corderoy wrote: Hi Jeffrey, Nice to see some activity on arcem. Out of interest, do you just work on the source as one long activity or use an SCM, like Subversion or Bazaar, locally to break up the edits? Cheers, Ralph. Since ArcEm is quite small I've just got a folder full of backups. If it was a bigger project I might use some kind of local SCM, or maybe just keep less backups. Anyway, new source + RISC OS build uploaded, same place as before. Changes: * X11 Windows versions now work. - The Windows version was the easiest, since it was already using a 16bpp bitmap for the screen. The X version was a lot harder, and involved me having to restructure how the new rendering code works (more on that below). - The Windows version now supports the high-res modes available in ArcEmModes (previously it had a max resolution of 800x600). The only downside is that it briefly pops up a massive 1600x1200 window on startup, which I haven't fixed yet. - Sound support in the X version is a bit iffy. To start with I tried the initial threaded code, but found that the sound thread hardly got any CPU time. Since I'm not an expert on pthreads, and using the thread to limit/control the audio rate technically isn't needed anymore, I tried disabling the thread code and sending the data directly from the main thread. This works, but the emulator seems to have a hard time keeping the correct DMA rate and constantly either underruns or overflows the buffer. So some work is definitely needed there. * As mentioned above, the new rendering code has been restructured a bit. ArcEm now has the notion of a 'display device' which handles the VIDC register writes and screen output (see arch/displaydev.c, arch/displaydev.h). - An ArcEm build can contain multiple display device implementations and the code can select the most appropriate one at runtime. - At the moment the X frontend uses this to select from two different implementations, one for pseudocolour displays and one for truecolour displays. - What's more, it's also possible for the emulator to switch between different devices while in the middle of execution (e.g. if you wanted different code for windowed or fullscreen operation), but at the moment nothing's making use of that. - This functionality comes at almost no extra cost performance-wise, since everything external to the CPU was already being done through function pointers anyway. * The display code I had in the previous version (now in arch/stddisplaydev.c) has been modified to use the new display device system. - It's also been modified to act more like a display device template; in order to use the code you need to set up a few #defines and function prototypes and then include the source file directly. This allows the code to adapt to the host environment without impacting the performance of other platforms. The two X display devices are both instances of the standard display device. - The only downside is that the source is a bit uglier, and geting access to device-specific variables from outside the device instance is a bit tricky. If only C had template support! * I've made a few general fixes/improvements to things in the previous version: - Fixed colours in 8bpp modes not being quite right - Improved IOC video timing accuracy. In particular my previous code seemed to be triggering Vsync one scanline too late. Now that I've fixed that Lotus II seems a lot better, with maybe 1 in 20 frames being off by 1 scanline on the palette swaps, or at least for the most noticeable area where the sky meets the road. YMMV. - Added support for the IOEB control register, which can control the VIDC source clock. I added this to see if it would fix Lotus II not working properly with *configure monitortype 4, but it didn't fix it, and after seeing the same thing in Red Squirrel I'm tempted to say that it's just a bug with Lotus that it doesn't work properly with all monitor types. However at the moment this is the only IOEB register that's implemented, so it's possible other registers (e.g. the ID register) are needed for some things to work properly (and the current code doesn't return sensible values when reading from the IOEB registers; it falls through to the HDC code and reads a random register from there) - Updated ArcEmModes and the ModeGen BASIC file to use sensible VIDC clock dividers for the high-res modes. However I haven't updated them to specify alternate VIDC source clock rates, so the refresh rates of the high-res modes could still be improved if needed. - There's a new common function for calculating the cursor position, since doing so correctly is a bit tricky and none of the existing frontends were doing it right. - Rewrote the vertical scaling code to be much faster * Some RISC OS version polish: - New command line option --rbswap to swap the red blue channels (since some Iyonix models have graphics cards that
Re: Further RISC OS port work
On Mon, 22 Aug 2011 02:09:45 +0100 (GMT Daylight Time), Jeffrey Lee wrote: Sounds good even though I have no way of testing it yet! The existing core sound code was rather broken (1 channel output worked, but 2+ would mostly be garbage) and didn't seem to be structured too well from the perspective of delivering data at a consistent rate. Hmm, I thought my sound was awful because it was the first time I'd tried to output sound (it improves with load IIRC), nice to know it may not be that after all... In the next couple of weeks I'll try and tidy up a few of the loose ends and get the X Windows versions working again. I can also have a stab at fixing the other versions, but I don't have any way of testing them. If you can update everything so it should work, that makes it easier for the frontend maintainers to get it working again. A lot of the frontend code is a cut'n'paste job between platforms anyway. Once that's done I'll update your arcem-fast branch in CVS. Chris -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
