Re: Further RISC OS port work

2012-01-03 Thread Michael Drake
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

Re: Further RISC OS port work

2011-10-30 Thread Jeffrey Lee
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'.

Re: Further RISC OS port work

2011-10-25 Thread Ralph Corderoy
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

Re: Further RISC OS port work

2011-10-22 Thread Chris Young
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,

Re: Further RISC OS port work

2011-10-21 Thread Chris Young
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

Re: Further RISC OS port work

2011-10-21 Thread Jeffrey Lee
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

Re: Further RISC OS port work

2011-10-20 Thread Jeffrey Lee
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.

Re: Further RISC OS port work

2011-10-19 Thread Jeffrey Lee
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

Re: Further RISC OS port work

2011-10-19 Thread Chris Young
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

Re: Further RISC OS port work

2011-10-18 Thread Chris Young
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

Re: Further RISC OS port work

2011-10-18 Thread Jeffrey Lee
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

Re: Further RISC OS port work

2011-10-18 Thread Chris Young
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

Re: Further RISC OS port work

2011-10-17 Thread Chris Young
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

Re: Further RISC OS port work

2011-10-17 Thread Ralph Corderoy
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,

Re: Further RISC OS port work

2011-10-14 Thread Chris Young
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

Re: Further RISC OS port work

2011-10-11 Thread Ralph Corderoy
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

Re: Further RISC OS port work

2011-10-10 Thread Ralph Corderoy
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

Re: Further RISC OS port work

2011-10-10 Thread Chris Young
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().

Re: Further RISC OS port work

2011-10-09 Thread Michael Drake
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

Re: Further RISC OS port work

2011-10-09 Thread Jeffrey Lee
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)

Re: Further RISC OS port work

2011-10-09 Thread Michael Drake
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

Re: Further RISC OS port work

2011-10-09 Thread Chris Young
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

Re: Further RISC OS port work

2011-10-08 Thread Jeffrey Lee
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)

Re: Further RISC OS port work

2011-09-17 Thread Chris Young
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...

Re: Further RISC OS port work

2011-09-11 Thread Jeffrey Lee
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

Re: Further RISC OS port work

2011-09-04 Thread Jeffrey Lee
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).

Re: Further RISC OS port work

2011-08-29 Thread Chris Young
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

Re: Further RISC OS port work

2011-08-28 Thread Jeffrey Lee
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

Re: Further RISC OS port work

2011-08-23 Thread Chris Young
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