Hi Patrick,
Sorry for the delay; had paperwork deadlines. I suspect we're getting
more into developer territory below, so I'm CC-ing
arcem-devel@lists.sourceforge.net as there's more people on the list and
they'll know the code changes that have gone on. I have set the
reply-to for there rather than arcem-users, subscribing you at the same
time.
> Yeah, sorry I was being lazy. I checked the 'arch/ReadConfig.c' where
> this file is read and it does appear to be $HOME for linux.
> Furthermore the supplied 'arcemrc' from the downloaded CVS sandbox
> needs to be ".arcemrc" in $HOME too.
>
> As a suggestion I think this should be handled by the makefile
> 'install' target. It doesn't work at all for (my) linux right now - it
> attempts to copy the wrong binary to /usr/local/bin.
Never noticed that before. I tend to not install and just do ./arcem.
> It should copy the correct binary and then copy the configuration file
> to $HOME and prefix a '.' to it.
OK, I've altered Makefile.
$ sed -n '/^install:/,/^$/p' Makefile
install: all
$(INSTALL) $(TARGET) $(INSTALL_DIR)
f=arcemrc; test -f $$HOME/.$$f || $(INSTALL) $$f $(HOME)/.$$f
$
$ make -n install
cp arcem /usr/local/bin
f=arcemrc; test -f $HOME/.$f || cp $f /home/ralph/.$f
$
> A 'man' page wouldn't go amiss either. It could be a simple subset of
> the online manual in nroff and copied into /usr/local/man as part of
> the makefile install target.
Yeah, it would be nice. I'd prefer to see the man page be the master;
a `groff -Thtml -man' version could always be put online.
> As a suggestion the location of the configuration file and (say) ROM
> should be overridden by commandline args to the 'arcem' binary and/or
> the ROM location can be entered in the configuration file (if not
> supplied via cmdline). Currently it's a PITA on my system as I must be
> in the actual directory of the arcem binary - otherwise it won't
> detect the ROM file.
Yes, this has always been a pain. I think it was discussed some years
ago, but nothing got done. If you've several ROM images, you end up
symlinking ROM to the one you want too.
Having just looked at what's involved, it seems there's code been added
by flibble since I was last involved that adds a --rom option, amongst
others. See arch/ArcemConfig.c's ArcemConfig_ParseCommandLine and
`arcem --help'. Perhaps it wasn't documented at the same time. Ah no,
I've now found http://arcem.sourceforge.net/manual.html#commandline
> If it's still an 'active' project I might update the code/makefile to
> implement the above. Let me know etc.
It's active in that once a year or so someone comes along and scratches
their itch, e.g. adds a port, etc. :-) This often results in more
cut-and-pasted lines, similar but slightly different, because none of us
have the time to do it right. :-) If you want CVS write access let me
know a SourceForge username and I'll add you.
If there's anyone out there with uncommitted stuff to CVS kicking about,
can you let the list know, else changes may give you the grief of
merging on the next update. It'll also give Patrick or me more free
reign to change stuff if we know we're not trampling others.
> Ta(2). It took me a while to work out why my 'double clicks' on my PC
> didn't execute !Configure. Thus I used F12 key to get cmdline prompt
> and did:-
>
> *configure Floppies 4
> *configure Harddiscs 2
>
> Then I worked out that the double-click delay and keyboard repeat
> rates were badly setup for my PC. Only a RAPIDO double-click launched
> the !Configure submenus. Then I managed to alter the mouse and
> keyboard delay rates for my PC ;-)
Ah, OK. *Configure Repeat and *Configure MouseStep are the RISC OS
options.
> Maybe online manual (+ man page?) should have a section on the mouse
> and keyboard delay rates and their configs.
Yes. They're under CVS too; hint, hint. It's the `webpages' module.
http://arcem.cvs.sourceforge.net/viewvc/arcem/
> OK... now I have managed to get that ELITE floppy image running - Yay!
> But now I need to work out the following:-
>
> 1. The whole emulation is running too fast. I need to slow it down.
> 2. I need to get a fullscreen of the ELITE game and/or ArcEm desktop.
I don't know if anyone's implemented having a scaled window, so you're
getting one X pixel to one RISC OS one, and at low-res RISC OS modes,
that's going to be a postage stamp.
The X code calls CopyScreenRAM() to get one row of pixels of video
memory into a temporary buffer, copies from there into an XImage, does
that for all the needed rows, and then calls XPutImage(3) to copy the
framebuffer to the X window. I guess the enlargement would happen
somewhere in that sequence, but it looks like the code has been copied
and changed several times as ports have come along.
Or perhaps the XVideo X extension is the thing to switch to as it can
put images with scaling using the graphics card IIRC. But that would be
more work and work on less platforms, and I doubt we need the speed.
It used to be that the X server's screen could zoom, something like
Ctrl-Alt-Keypad+ and Keypad- but that might not work by default in
Ubuntu set-ups. It was a solution for other emulators.
If the first method was implemented that might slow things down
sufficiently as a by-product. I'm a bit surprised that the game isn't
syncing itself with the 50Hz video vertical flyback signal. But perhaps
the emulator generates that as fast as it can! Other than that, I can
only suggest adding a delay at some core point, e.g. screen update or
every N emulated ARM instructions, just to see if it helps.
Cheers,
Ralph.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
arcem-devel mailing list
arcem-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/arcem-devel
