In article ,
Jeffrey Lee 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.
Yea
Hi Jeffrey,
> On Sun, 30 Oct 2011, Ralph Corderoy wrote:
> > I'll try and get the emails to arcem-cvs working again soon. I
> > noticed on commits last night that they've broken.
>
> It looks like they're working again now - but it looks like everyone
> needs to be subscribed to the list (with t
On Sun, 30 Oct 2011, Ralph Corderoy wrote:
> I'll try and get the emails to arcem-cvs working again soon. I noticed
> on commits last night that they've broken.
It looks like they're working again now - but it looks like everyone needs
to be subscribed to the list (with their @users.sourceforge
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.
> Anyone recall the CVS invocation to do so? It's
Hi Jeffrey,
> > 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'.
>
> I haven't got anyt
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
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.
--
Hi Ian,
> Well, I don't plan to "go crazy" but if things have stabilised a
> little again, I'll try and get the OSX build (re)done
I've a vague recollection that CVS stores some intermediate build files
for the Mac OS X port? Quite a few of them perhaps, e.g.
arcem/macosx/build/ArcEm.build/ArcEm
On Tue, 25 Oct 2011, Jeffrey Lee wrote:
> I think the next thing on my list will be to have a go at optimising the
> 16bpp display driver. I suspect just adding support for the "auto
> updateflags" option will result in the performance gains I'm after.
This is now done. I've added support for the
On 27/10/2011 22:17, Jeffrey Lee wrote:
> On Tue, 25 Oct 2011, Jeffrey Lee wrote:
>
>> My CVS access seems to be working, so when I get a chance I'll check in my
>> changes. Since I've got lots of backups I could even have a go at breaking
>> it up into several changes if you want. That should make
On Tue, 25 Oct 2011, Jeffrey Lee wrote:
> My CVS access seems to be working, so when I get a chance I'll check in my
> changes. Since I've got lots of backups I could even have a go at breaking
> it up into several changes if you want. That should make it easier to
> track down the cause of any ne
On Tue, 25 Oct 2011 01:48:03 +0100 (GMT Daylight Time), Jeffrey Lee wrote:
> With these tweaks applied, this new
> version runs about 25% faster than the previous one.
Blazing along at about 13MHz now!
Chris
--
The d
On Tue, 25 Oct 2011, Ralph Corderoy wrote:
> 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
> reposi
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
Another new version:
http://www.phlamethrower.co.uk/misc2/arcem-src.zip (Source)
http://www.phlamethrower.co.uk/misc2/arcem.zip (RISC OS build)
* Added Chris's Amiga 64bit files fix
* I'm not sure how much it will effect other platforms, but after a quick
bit of profiling on RISC OS I found that
On 22 Oct 2011 20:16:33 +, Chris Young wrote:
> On Sat, 22 Oct 2011 18:21:40 +0100 (GMT Daylight Time), Jeffrey Lee wrote:
>
> > A copy of the stderr log would be useful. It might also be worth switching
> > the code back to using fseek/ftell instead of the 64bit versions - perhaps
> > the
On Sat, 22 Oct 2011 18:21:40 +0100 (GMT Daylight Time), Jeffrey Lee wrote:
> A copy of the stderr log would be useful. It might also be worth switching
> the code back to using fseek/ftell instead of the 64bit versions - perhaps
> the 64bit versions are somehow broken on Amiga.
Woo-hoo! That d
On Sat, 22 Oct 2011, Chris Young wrote:
On Sat, 22 Oct 2011 17:11:10 +0100 (GMT Daylight Time), Jeffrey Lee wrote:
* 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 m
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, m
On Fri, 21 Oct 2011, Jeffrey Lee wrote:
> 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 he
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 !Bo
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 thi
Hi Jeffrey,
> 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.
Probably worth using it if it's available. Platforms that don't have it
could a
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
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
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 u
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
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
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 see
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? :-)
C
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
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 f
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 w
On Wed, 12 Oct 2011, Peter Howkins wrote:
> On Wed, Oct 12, 2011 at 10:10:24PM +0100, Jeffrey Lee wrote:
>>
>>> Is anything of RPCEmu's HostFS usable in ArcEm?
>>
>> The two implementations are pretty much identical, since they're both
>> based on code written by Matthew Howkins. The code in RPCEm
On Wed, 12 Oct 2011, Michael Drake wrote:
> In article ,
> Jeffrey Lee wrote:
>
>> Once I've tweaked the hostfs code I'll upload a new version for people
>> to try out.
>
> Is anything of RPCEmu's HostFS usable in ArcEm?
The two implementations are pretty much identical, since they're both
ba
In article ,
Jeffrey Lee wrote:
> Once I've tweaked the hostfs code I'll upload a new version for people
> to try out.
Is anything of RPCEmu's HostFS usable in ArcEm?
--
Michael Drake http://www.smoothartist.com/
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.
On Mon, 10 Oct 2011, Chris Young wrote:
> (I'm not sure if the fact I emulate an ARM3 makes any difference
> to the clock frequency report - if I try to emulate an ARM2 my
> !Boot hangs or errors)
I've just checked and it doesn't look like the choice of CPU has any
effect on the speed reported b
On Mon, 10 Oct 2011 00:25:59 +0100 (GMT Daylight Time), Jeffrey Lee wrote:
> Thanks. Have you tried running !SICK at all?
Ah, I normally do that with each build and completely forgot. I've
just run it now for you.
> On an Iyonix (600MHz ARM)
> it reckons it's running at just over 6MHz; it woul
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 Set
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_Load
Hi Chris,
> static void PDD_Name(Host_SetPaletteEntry)(ARMul_State *state,int i,unsigned
> int phys)
> {
> - int r = (phys & 0xf)*0x11;
> - int g = ((phys>>4) & 0xf)*0x11;
> - int b = ((phys>>8) & 0xf)*0x11;
> + ULONG r = ((phys & 0xf)*0x11) << 24;
> + ULONG g = (((phys>>4)
On Mon, 9 Oct 2011, Chris Young wrote:
> That fixes it, thanks. I'm amazed with what you've managed to do, I
> can use RISC OS now and wouldn't suspect it was running under
> emulation if I didn't know! What I'm running on isn't particulary
> fast either, being only a 600MHz PowerPC.
Thanks. Ha
On Sun, 9 Oct 2011 20:37:54 +0100 (GMT Daylight Time), Jeffrey Lee wrote:
> On Sun, 9 Oct 2011, Chris Young wrote:
>
> > Only problem I can see now is that the mouse pointer is the wrong
> > colour (red instead of blue), it looks like it might not have been
> > updated for palette mapped display.
On Sun, 9 Oct 2011, Chris Young wrote:
Only problem I can see now is that the mouse pointer is the wrong
colour (red instead of blue), it looks like it might not have been
updated for palette mapped display.
I tried changing (line 330-ish):
line[x] = cursorPal[idx];
to:
line[x] = VIDC.CursorPal
On Sun, 9 Oct 2011 18:45:19 +0100 (GMT Daylight Time), Jeffrey Lee wrote:
> General changes:
> * Chris's Amiga palette fix
> * Sound & video code should (hopefully) work properly on big-endian
> systems now. Might also be slightly faster than the old code.
Wow, sound working better than it ever
On Sun, 9 Oct 2011, Chris Young wrote:
> On Sun, 9 Oct 2011 16:21:29 +0100 (GMT Daylight Time), Jeffrey Lee wrote:
>
>> On Sun, 9 Oct 2011, Chris Young wrote:
>>
>>> Ideally the display needs to be big endian (or endian-neutral) all the
>>> way through. Any ideas?
>>
>> Judging by the original co
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-ali
In article ,
Jeffrey Lee 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 improv
On Sun, 9 Oct 2011, Michael Drake wrote:
> In article ,
> Jeffrey Lee 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
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-
In article ,
Jeffrey Lee 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% w
On 9 Oct 2011 15:08:45 +, Chris Young wrote:
> Patch attached.
Is now anyway!
--- ram:arcem-src/amiga/DispKbd.c 2011-10-07 23:35:32
+++ Files:Projects/arcem-src/amiga/DispKbd.c2011-10-09 15:01:25
@@ -388,9 +388,10 @@ static void PDD_Name(Host_ChangeMode)(AR
static void PDD_Name
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
>
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
On Sun, 25 Sep 2011, Jeffrey Lee wrote:
On Sun, 25 Sep 2011, Chris Gransden wrote:
Hi,
Since the recent changes arcem no longer picks up the hard disc I created.
Doesn't recognise the disc as being formatted.
Yes, it does look like I've broken something. I've got an image that
mounts, but t
On Sun, 25 Sep 2011, Chris Gransden wrote:
> Hi,
>
> Since the recent changes arcem no longer picks up the hard disc I created.
> Doesn't recognise the disc as being formatted.
Yes, it does look like I've broken something. I've got an image that
mounts, but triggers an abort on data transfer ins
In article ,
Jeffrey Lee wrote:
> 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)
Hi,
Since the recent changes arcem no longer picks up the hard disc I created.
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...
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
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
>
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).
On Mon, 29 Aug 2011, Chris Young wrote:
> On Mon, 29 Aug 2011 11:22:00 +0100 (GMT Daylight Time), Jeffrey Lee wrote:
>
>> If you're worried about performance (even with palette-mapped output the
>> code would still be doing a per-pixel lookup to map from the current Arc
>> palette to the host pale
On Mon, 29 Aug 2011 11:22:00 +0100 (GMT Daylight Time), Jeffrey Lee wrote:
> On Mon, 29 Aug 2011, Chris Young wrote:
>
> > 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 hav
On Mon, 29 Aug 2011, Chris Young wrote:
> 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,
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
>
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 sm
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.
--
EMC VNX: th
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 per
69 matches
Mail list logo
