Hi Peter,
> > > The ArcEm CVS has been static for quite some time.
> >
> > Last change 2009-09-25?
>
> Sorry yes. "cvs log" does things in a unhelpful order. I've been
> using SVN too long.
Yes, I found it annoying when I went to look.
$ cvs log |
> sed '/^date: /!d; s#/.. .*##; s/.* //; y#/#-#' |
> sort -r | uniq -c |
> pr -t3
2 2009-09 72 2006-02 2 2003-08
21 2008-11 35 2006-01 123 2003-05
2 2008-10 7 2005-12 35 2003-04
5 2008-05 1 2005-11 29 2002-08
15 2008-04 7 2005-10 50 2002-06
1 2007-04 2 2005-08 105 2002-05
7 2007-01 7 2005-07 21 2002-03
1 2006-10 15 2005-02 6 2002-02
16 2006-09 25 2005-01 1 2002-01
1 2006-05 26 2004-12 8 2001-11
38 2006-04 15 2004-11 133 2001-10
45 2006-03 9 2003-10
$
> Do you have any specific plans for ArcEm here?
No. Just fixing whatever thing's got in the way the next time I dust it
off and go to use it. But I've not done much on it in some time, others
come along and run with it for a while, and I expect this'll keep
happening.
> My biggest frustration with RPCEmu is still the issue of RONs.
The Spoon site links to where 3.60 and 3.71 can be downloaded. I find a
bigger problem with later ROM images is that some are taken after
they've been patched by the boot process. As I now understand it, the
list of SHA1 digests at http://inputplus.co.uk/ralph/#acornem has an
error. The correct digest for '4.02 (10 Aug 1999)' is
37acd8573da51493beb0fa6eef29623ce382822f; thanks to Eric Rucker for
sacrificing his RiscPC's CMOS to determine that. Any other corrections
welcome.
Debugging error reports from people who say they're running, e.g. 4.02,
may be hampered if they're starting with a patched ROM image or patch it
on booting.
I suspect the biggest future problem for RPCEmu is the one that bit
arcem; copy-and-paste expansion of code. For arcem it was to port to
more platforms. There's lots of identical, or worse almost identical,
code that should be platform independent, or worked on to be made
platform independent, that isn't. Now if I want to change a P.I. line
or two I have multiple copies to change having gone to the effort of
making sure the change is correct in all cases and bearing in mind some
of the changes I then can't compile and test. In the end, I don't
bother.
With RPCEmu.c this has happened with the interpreted versus dynarec ARM.
I'm spotting little improvements here and there and instead of making
them twice am trying to factor out common code where possible. Really,
the build process needs changing a bit so both variants are compiled but
only one linked in. At the moment I have to run './configure && make
all check' in all four variants of --enable-{debug,dynarec} before
submitting a patch to Peter Howkins.
> There are other Archimedes emulators that seem to have vanished for
> example.
Yes, but they were never on SourceForge.
> > The mailing lists work fine and have a decent archive interface on
> > mail-archive.com. (sf.net's is awful.) Why break all those ties?
> > I don't see any benefits.
>
> In fairness, the ArcEm mailing list isn't really used any more. The
> argument could be make for combining its traffic with that of RPCEmu.
It is used. Someone new subscribes and asks for help and gets
responses. 2008-10 is the last example on the user list.
http://www.mail-archive.com/arcem-u...@lists.sourceforge.net/
http://www.mail-archive.com/arcem-de...@lists.sourceforge.net/
I think there's probably folks interested in arcem, perhaps because they
did work on it, that are still subscribed and want to be yet have no
interest in lots of current chat about the more actively developed
RPCEmu.
> > riscos.info's wiki already links to arcem.sf.net, perhaps a page for
> > it is all that's needed if you're concerned about it being
> > forgotten?
>
> Perhaps.
I agree the arcem.sf.net web site needs to indicate "there's no current
development but feel free to come along and play around". However,
Acorn users will be used to coming across web sites where the last news
entry is last century and yet still realise there may be useful stuff
there.
Cheers,
Ralph.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
