tuxnes-devel — Development discussion for the TuxNES project

Re: [Tuxnes-devel] [PATCH] Sound routine abstraction

[Jim U. <ji...@3e...>]

At 02:44pm on 2001 September 25, Jim Ursetto did write:
> Attached.

Whoops, forgot the diff for Makefile.am.

-- 
"... [WM97/Melissa-V] triggers immediately and attempts to delete data 
on your M:, N:, O:, P:, Q:, S:, F:, I:, X:, Z:, H:, and L: network drives."
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

[Tuxnes-devel] [PATCH] Sound routine abstraction

[Jim U. <ji...@3e...>]

Attached.  See my earlier e-mail for a summary.
Comments appreciated.

-- 
"... [WM97/Melissa-V] triggers immediately and attempts to delete data 
on your M:, N:, O:, P:, Q:, S:, F:, I:, X:, Z:, H:, and L: network drives."
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

Re: [Tuxnes-devel] Sound routines abstracted!

[Jim U. <ji...@3e...>]

At 04:15pm on 2001 September 24, Mike Melanson did write:
> 	Just curious, does the TuxNES/DC port use the existing mixing code
> and send the resulting wave to the DC's sound processor? Or does it
> attempt to make better use of the DC's custom sound hardware?

Well, it's certainly on the list of things to do, but I'm currently
concentrating on getting sound to work as-is.  Right now, sound is
very recently implemented, so it's passable but not perfect.  So it
uses the existing mixing code for now, at least until I finish up the
sound code.

-- 
"Note that Unruh [9] proposed also an 
acoustical analog of a black hole, a dumb hole."
-- http://www.st-and.ac.uk/~www_pa/group/quantumoptics/media.html
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

Re: [Tuxnes-devel] Sound routines abstracted!

[Mike M. <mel...@pc...>]

Hi Jim,
	Just curious, does the TuxNES/DC port use the existing mixing code
and send the resulting wave to the DC's sound processor? Or does it
attempt to make better use of the DC's custom sound hardware?

	Thanks...
	-Mike Melanson

[Tuxnes-devel] Sound routines abstracted!

[Jim U. <ji...@3e...>]

Hi all,

As promised long ago, I have finally gotten around to abstracting the
sound routines into platform-specific functions, modeled after the
renderer.  Here is a summary of the changes.  

- Common sound calculation setup code was moved into InitSoundParms().
- InitAudio and UpdateAudio are now InitAudio[Platform] and
  UpdateAudio[Platform], and are called indirectly through their old
  names via a pointer to function.  Each platform gets its own file.
  Common sound code remains in sound.c.
- The existing sound driver is now "oss" (InitAudioOSS), in oss-sound.c.
- Added "mute" and "none" drivers.  Mute does all the sound calculations,
  but produces no output.  None does no calculations or output at all.
  These are simple enough to stay in sound.c.
- -s/--sound option now selects the sound driver rather than the
  output file.  The default output file is determined by the
  respective InitAudio function.  However, it can be overridden with 
  the -e/--sound-device option.
- Help text reflects the changes.

Errata:

- Names are not final.  Not sure about "OSS" as driver name, though it
  seems most specific.  In places I refer to the sound routines as the
  sound engine, sound driver, or the "sounder"; needs to be standardized.
- Did not abstract sample_format, it's probably not worth the effort now.

Patch is cvs diff, ~36K, mostly because of the splitting of sound.c into two
files.  Should I send the patch to the list, or privately?

-- 
"the visual pattern seemed to be a sort of m-dimensional lissajous curve
formed by the intersection of 'i' with the shock wave of space-time
causality."                        -- zarkov, "a hit of dmt 10/9/84"
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

[Tuxnes-devel] Odd problem (gcc3-related?)

[Mike M. <mel...@pc...>]

Hi team,
	I just got a bug report. The file emu.c failed compilation with
this error:

gcc -DHAVE_CONFIG_H -I. -I. -I.     -O -pipe -Wall  -I/usr/X11R6/include
-D__USE_BSD -c emu.c
emu.c:724:1: directives may not be used inside a macro argument
emu.c:724:1: unterminated argument list invoking macro "printf"
emu.c: In function `help_controls':
emu.c:725: parse error before string constant
emu.c: In function `main':
emu.c:1187: warning: `size' might be used uninitialized in this function
make: *** [emu.o] Error 1

The user reported that he's compiling with gcc v3.0.1 on Slackware
7.1. The offending code looks like this:

  printf ("    S, F7, PrintScreen\n"
          "      - Capture screenshot\n"
#ifdef HAVE_X
          "            Under X11, save to ~/.tuxnes/snap\?\?\?\?.xpm\n"
#endif /* HAVE_X */
#ifdef HAVE_GGI
          "            Under GGI, save to ~/.tuxnes/snap\?\?\?\?.ppm\n"
#endif /* HAVE_GGI */
#ifdef HAVE_W
          "            Under W, save to ~/.tuxnes/snap\?\?\?\?.p8m\n"
#endif /* HAVE_W */
          );

So it seems to be complaining about those compiler directives embedded in
the printf() statement. Needless to say, this has always worked peachy
with everyone else's compilers. I even checked the preprocessor output
from gcc -E and everything looks fine.

	As a temporary hack, I advised the user if '#if 0' out the
#ifdef's. Does anyone know if gcc 3 rejects this construct, or if it's
some other problem?

	Thanks...
-- 
	-Mike Melanson

Re: [Tuxnes-devel] DGA 2.0, TuxNES, and GGI

[Stea G. <st...@cs...>]

On Thu, Sep 06, 2001 at 04:32:40PM -0400, Jon Niehof wrote:
> Anyone have any luck using the DGA target with the GGI renderer under
> DGA 2.0 (XFree 4.x)? I just get a black fullscreen, hitting ESC exits
> the emulator.
> 
	I had problems at first, but once I installed ggi from source
and recompiled/reinstalled tuxnes, it worked fine.
							--Steaphan Greene

[Tuxnes-devel] DGA 2.0, TuxNES, and GGI

[Jon N. <jn...@yi...>]

Anyone have any luck using the DGA target with the GGI renderer under
DGA 2.0 (XFree 4.x)? I just get a black fullscreen, hitting ESC exits
the emulator.

-----------------------------------------------------
http://eo.yifan.net
Free POP3/Web Email, File Manager, Calendar and Address Book

[Tuxnes-devel] Patch: Fix 2-Joystick Bug

[Stea G. <st...@cs...>]

	I found a minor problem that surfaced when using two joysticks
at the same time with tuxnes.  It had to do with js_axismeso being
shared between them.  A patch (relative to the latest CVS version of
tuxnes) that fixes this is attached.  I would suggest this should be
included on CVS and in the next release.
							--Steaphan Greene

Re: [Tuxnes-devel] Screen Saver Patch & DGA Question

[Stea G. <st...@cs...>]

On Fri, Aug 31, 2001 at 03:04:10PM -0400, Jason Dorje Short wrote:

> I often leave tuxnes running for a long time (during which time the
> screensaver *should* come on).
> 
	True.

> A patch like this should instead "re-awaken" the screen saver/screen
> blinking on each joystick input (presumably keyboard inputs already do
> this).  Then we would have the proper behavior.
> 
> However, I don't know if this is possible...
> 
	I agree, but AFAIK there is not standard way of doing this short
of faking key strokes, which is not a good thing to do for this purpose.
Also, it is my understanding that the input itself is completely
disconnected from the output renderer (true?), which would make it
difficult (and ugly) to do this kind of thing.
	The other method I thought of was adding a bit in the flags for
this, and having the renderer name change - eg: x11 for the normal one,
x11-ss for the x11 renderer disabling the Screen Saver, etc....  But
this is a pain, and is too much complexity for such a minor detail.
	Another possibility is I could disable the screen saver only
when the tuxnes window has the focus.  Not sure how complicated that
would be - it may be quite easy.
	Honestly, now that I have the DGA (which stops the screen saver)
output working through ggi, I could care less about this.  This patch
could still be useful to those who don't have DGA though.

	BTW- I am now on this mailing list, so there is no need to
separately include me in any replies that are going to the whole list.

							--Steaphan Greene

Re: [Tuxnes-devel] Screen Saver Patch & DGA Question

[Jason D. S. <js...@de...>]

Stea Greene wrote:
> 
>         First I must say thanks to all for such a great app! The only
> real problem I encountered with it is that since it does not disable the
> screen saver, and since XFree86 does not see input from my gamepad as
> activity, the screensaver would come on as I was playing games, which
> was very detrimental to my continued survival in said games.
>         Attached is a patch (most of the code simply ripped from xawtv),
> based on the current CVS tuxnes code, that fixes this by disabling the
> active screen saver, and DPMS screen blanking if present, and then
> re-enables (only if it was enabled initially) them on exit.  I tried to
> keep things to the same coding style as the rest of the code.  I have
> only tested this on my Linux machine, but it should work on any X system
> - DPMS should be automatically detected by the configure script if
> present.

I often leave tuxnes running for a long time (during which time the
screensaver *should* come on).

A patch like this should instead "re-awaken" the screen saver/screen
blinking on each joystick input (presumably keyboard inputs already do
this).  Then we would have the proper behavior.

However, I don't know if this is possible...

jason short

Re: [Tuxnes-devel] Screen Saver Patch & DGA Question

[Stea G. <st...@cs...>]

On Fri, Aug 31, 2001 at 04:26:41PM +0000, ji...@3e... wrote:
> Stea Greene writes:
> 
> > 	Also, is anyone working on, or interested in working on a DGA
> > fullscreen mode?
> 
> For now, you could use the GGI renderer's DGA mode, if you have GGI
> installed.  It works for me (much faster than X in a window, too).
> 
	Wow, that does work well - great!  I tried it with the debian
packages for ggi, and it just crashed, but it works well with the newest
ggi installed from source.  Thanks.
							--Steaphan Greene

Re: [Tuxnes-devel] Screen Saver Patch & DGA Question

[<ji...@3e...>]

Stea Greene writes:

> 	Also, is anyone working on, or interested in working on a DGA
> fullscreen mode?

For now, you could use the GGI renderer's DGA mode, if you have GGI
installed.  It works for me (much faster than X in a window, too).

Jim

[Tuxnes-devel] Screen Saver Patch & DGA Question

[Stea G. <st...@cs...>]

	First I must say thanks to all for such a great app! The only
real problem I encountered with it is that since it does not disable the
screen saver, and since XFree86 does not see input from my gamepad as
activity, the screensaver would come on as I was playing games, which
was very detrimental to my continued survival in said games.
	Attached is a patch (most of the code simply ripped from xawtv),
based on the current CVS tuxnes code, that fixes this by disabling the
active screen saver, and DPMS screen blanking if present, and then
re-enables (only if it was enabled initially) them on exit.  I tried to
keep things to the same coding style as the rest of the code.  I have
only tested this on my Linux machine, but it should work on any X system
- DPMS should be automatically detected by the configure script if
present.

	Also, is anyone working on, or interested in working on a DGA
fullscreen mode? I would really like one so I can get fullscreen play
without having to manually zoom in and align the virtual window with
tuxnes' display.  I could write such a thing, but I am unfamiliar with
the actual rendering of the NES output, which in the tuxnes code seems
to be intertwined with the graphics display itself.  It would be much
faster if I had the help of someone who is familiar with this aspect of
tuxnes.
							--Steaphan Greene

Re: [Tuxnes-devel] tuxnes working on OpenBSD

[Paul Z. <pe...@tr...>]

On Wed, Aug 29, 2001 at 11:22:49AM -0700, HUYNH,SONTRI (HP-Richardson,ex1) wrote:
>SNIP 
> i'm still trying to get sound to work, when i use the mu8 format 
> (openbsd's /dev/audio uses this format i believe) it sounds slowed
> down and choppy.  i'm not sure if there is a combination of options
> which could make this sound correctly, or if the code needs changed.
> SNIP

Eh.  I never finished support for muLaw encoding.. the option is there, but
it's trying to output non-muLaw encoded data (the audio is recognizeable, but
sounds very, very bad).
I will add it to my list of things to do..

  Paul
-- 
Paul Zaremba
Senior - CSC, North Carolina State University
Use an Envelope, Please encrypt ALL EMail.
PGP Public Key - wwwkeys.pgp.net, pe...@tr...

Re: [Tuxnes-devel] tuxnes working on OpenBSD

[J.D. <jo...@ce...>]

HUYNH,SONTRI (HP-Richardson,ex1) wrote:
>         i played megaman 2 on tuxnes on openbsd last night.  i found
> gnugetopt, and was able to get that to work, and with all the other
> changes tuxnes finally built.  it seemed a bit laggy, but i haven't
> played on any other os's to compare.

Some time ago, with another emulator, I recall slight control lag
when using an analog PC gamepad, as opposed to a digital pad (like
a retrofitted SNES or N64 pad connected to a parallel port).
Another person who tried the emulator on the Linux machine also
noticed this behavior.  I'm unsure of the latency associated 
with the joystick port, or of other issues that may have caused a
slight delay.

Kind regards,

- John

[Tuxnes-devel] tuxnes working on OpenBSD

[HUYNH,SONTRI (HP-Richardson,ex1) <son...@hp...>]

hello,
	i played megaman 2 on tuxnes on openbsd last night.  i found
gnugetopt, and was able to get that to work, and with all the other
changes tuxnes finally built.  it seemed a bit laggy, but i haven't
played on any other os's to compare.  i had hack configure (yes i
realize it's generated) in approximately this way:
2391: ac_try="$ac_cpp -I/usr/X11R6/include conftest.$ac_ext >/dev/null
2>conftest.o
ut"
in order to get xpm to be recognized as being installed and to link it.
i think that adding "-I/usr/X11R6/include" to CPPFLAGS for *-openbsd 
or something should work.

i'm still trying to get sound to work, when i use the mu8 format 
(openbsd's /dev/audio uses this format i believe) it sounds slowed
down and choppy.  i'm not sure if there is a combination of options
which could make this sound correctly, or if the code needs changed.

anyways, tuxnes works on openbsd, however, not without significant changes.
there might be some simpler/more elegant way to make x86.S build/link
correctly without having to munge all the symbol names and also keeping
mapper.h change-free, then it may be able to make the appropriate changes
to tuxnes in configure.in/Makefile.in so that it properly builds on
openbsd.  any ideas on making sound work, and is there some combination
of options which would speed up performance by maybe dropping the frame
rate or equivalent?  or even just playing at a slower uniform speed 
(it's kinda choppy depending on if i'm moving around it seems).

thanks,
tomo

RE: [Tuxnes-devel] Trying to build on OpenBSD 2.9

[HUYNH,SONTRI (HP-Richardson,ex1) <son...@hp...>]

> Since it sounds like you cannot get a recent version of GNU 
> binutils, I'd
> suggest using a different technique to generate table.o:
> 
> table.s: compdata
> 	(echo '.globl TRANS_TBL'; \
> 	 echo 'TRANS_TBL:'; \
> 	 od -vhw2 < compdata | \
> 	 sed -ne 's/.* \(.*\)/.short 0x\1/p') > table.s
> 
> table.o: table.s
> 	as -o table.o table.s
> 
> This uses the assembler to do the dirty work, rather than the 
> linker. As
> a side-effect, it will generate a huge table.s file (which 
> you may wish
> to delete after compilation is finished.)


ben,
	thanks for the insight.  i was able to hack together something
which i believe to do the same thing.. so here is some more openbsd
trivia.  in openbsd, od has been deprecated in favor of hexdump, and
hexdump takes od flags when called as od.. however, it does have the
new gnu od options in hexdump.  so i added this to Makefile instead:

table.s: compdata
        echo '.globl _TRANS_TBL' > table.s
        echo '_TRANS_TBL:' >> table.s
        hexdump -v -e '1/2 ".short 0x%04x\n"' compdata >> table.s

which creates something like:
.globl _TRANS_TBL
_TRANS_TBL:
.short 0xd801
.short 0x0048
.short 0xd8c9
.short 0x0048
.short 0x0000
...

and i was able to make table.o from this.
and i was almost able to fully build... then came link time, and everything
and its brother was undefined.  to make a long story short, i commented out
parts of mapper.h, i changed most of the symbols in x86.S from either having
an underscore or not having an underscore, then i commented out the call to
getopt_long (since i don't have gnu's getopt installed... i will work on
this
later).  after a lot of hacking, i got tuxnes to build. woohoo!

of course, since i'm at work, i haven't actually tried to get it to run
yet..
i will let you know if things work out.

thanks.
tomo

RE: [Tuxnes-devel] Trying to build on OpenBSD 2.9

[HUYNH,SONTRI (HP-Richardson,ex1) <son...@hp...>]

> -On [20010824 05:25], Ben Sittler (BSi...@Kn...) wrote:
> >As for the "ld" command you included, my suggestion is to
> >upgrade your binutils!
> 
> Agreed.
> 
> Ask Marc Espie why OpenBSD is still on old binutils while the compiler
> is up to snuff.

Sorry, it isn't quite Marc's fault.  We have binutils 2.10 in the tree,
as I said, it just isn't used for all the architectures that OpenBSD
supports.
i386 is one of them, probably because it is so important not to do anything
unnecessary that could potentially break that port for so many people (ELF
is not necessary for most OpenBSD users).

Nevertheless, Art Grabowski has been talking about moving i386 up to ELF, so
it is on the agenda.  It just isn't going to happen tomorrow, or next week..
Meanwhile, I hope to somehow get this to work with this list's help yet.

Tomo

Re: [Tuxnes-devel] Trying to build on OpenBSD 2.9

[Jeroen Ruigrok/A. <as...@wx...>]

-On [20010825 01:25], HUYNH,SONTRI (HP-Richardson,ex1) (son...@hp...) wrote:
>Still no further on the OpenBSD build, I thought I'd try it
>out on a FreeBSD machine to see how that would go.  I had
>to steal a getopt.h from binutils (although, there are tons
>of them.. so, neither of these systems really has a default
>one it seems, which should be noted).  So after throwing
>that in the include path, I get this same error on this
>4.2-RELEASE FreeBSD machine, as on my OpenBSD/i386 2.9 machine:

I didn't create a BSD README/INSTALL in the distribution for nothing. ;P

1)  it depends on long getopt stuff [ports/devel/libgnugetopt]
2)  it uses gmake

-- 
Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org]
Documentation nutter/C-rated Coder, finger as...@ni...
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/
Brother, let your Heart be wounded and give no Mercy to your fear...

Re: [Tuxnes-devel] Trying to build on OpenBSD 2.9

[Jeroen Ruigrok/A. <as...@wx...>]

-On [20010824 05:25], Ben Sittler (BSi...@Kn...) wrote:
>As for the "ld" command you included, my suggestion is to
>upgrade your binutils!

Agreed.

Ask Marc Espie why OpenBSD is still on old binutils while the compiler
is up to snuff.

-- 
Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org]
Documentation nutter/C-rated Coder, finger as...@ni...
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/
The only thing we have to fear is Fear itself...

Re: [Tuxnes-devel] Trying to build on OpenBSD 2.9

[Jeroen Ruigrok/A. <as...@wx...>]

-On [20010823 19:59], HUYNH,SONTRI (HP-Richardson,ex1) (son...@hp...) wrote:
>GNU assembler version 1.92.3, OpenBSD $Revision: 1.2 $

This is very, very, very, old.

We depend on newer options and features provided by the 2.x versions of
the GNU binutils.

-- 
Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org]
Documentation nutter/C-rated Coder, finger as...@ni...
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/
Answering the questions that no one asks...

Re: [Tuxnes-devel] Trying to build on OpenBSD 2.9

[Jeroen Ruigrok/A. <as...@wx...>]

-On [20010822 02:25], HUYNH,SONTRI (HP-Richardson,ex1) (son...@hp...) wrote:
>vivaldi:~/tuxnes-0.75$ make
>gcc -DHAVE_CONFIG_H -I. -I. -I.     -O -pipe -Wall  -I/usr/X11R6/include -c
>x86.S
>x86.S: Assembler messages:
>x86.S:1672: Error: Local symbol LASTBANK never defined.
>x86.S:1672: Fatal error:1 error, 0 warnings, no object file generated.
>
>Any ideas?  This file is only 1672 lines long, is that too short? 

Last time I tested this the as and ld in OpenBSD were old and archaic,
any version numbers you can get out of them?

-- 
Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org]
Documentation nutter/C-rated Coder, finger as...@ni...
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/
In my Dreams, I see you, I can tell you, how I feel...

RE: [Tuxnes-devel] Trying to build on OpenBSD 2.9

[Ben S. <BSi...@Kn...>]

Right, compdata is a file containing some x86 machine code used by the
dynamic recompilation code.

The -b binary option tells ld to take a raw binary file as input (instead
of an ELF or a.out object file.) When ld reads a raw binary file, there
is no symbol table, so it defines the special symbol _binary_XXX_start to
refer to the beginning of file XXX. The option -defsym
TRANS_TBL=_binary_compdata_start defines TRANS_TBL to refer to the same
place (i.e. the beginning of the binary file.)

Since it sounds like you cannot get a recent version of GNU binutils, I'd
suggest using a different technique to generate table.o:

table.s: compdata
	(echo '.globl TRANS_TBL'; \
	 echo 'TRANS_TBL:'; \
	 od -vhw2 < compdata | \
	 sed -ne 's/.* \(.*\)/.short 0x\1/p') > table.s

table.o: table.s
	as -o table.o table.s

This uses the assembler to do the dirty work, rather than the linker. As
a side-effect, it will generate a huge table.s file (which you may wish
to delete after compilation is finished.)

Does that work any better?

-ben

-----Original Message-----
From: HUYNH,SONTRI (HP-Richardson,ex1) [mailto:son...@hp...]
Sent: Monday, August 27, 2001 8:41 AM
To: 'tux...@li...'
Subject: RE: [Tuxnes-devel] Trying to build on OpenBSD 2.9



> Aha! Use GNU make, and let us know whether that works any better.
> $< is GNU Makese for "first file this rule depends on".


Aha! So it is some quirky gnumakeism.. Well now, this is what I believe
the line to be:

ld -r -b binary -r -defsym TRANS_TBL=_binary_compdata_start compdata -o
table.o

Of course, I still don't have the -b or -defsym options, but I see that it
is
trying to link compdata to create table.o.  Now, I'm not quite sure then
what
compdata is supposed to be, is it supposed to be an ELF object file?  I see
that it is spit out by comptbl.  I mean, ld gives me this:

ld: compdata: malformed input file (not rel or archive)

And doing a quick file on the file doesn't tell me anything more than that
compdata is "data" (using perhaps an older version of file).  This part of
the
build process really confuses me, perhaps someone could shed more light
please?

Thanks all,
Tomo

_______________________________________________
Tuxnes-devel mailing list
Tux...@li...
http://lists.sourceforge.net/lists/listinfo/tuxnes-devel

RE: [Tuxnes-devel] Trying to build on OpenBSD 2.9

[HUYNH,SONTRI (HP-Richardson,ex1) <son...@hp...>]

> Aha! Use GNU make, and let us know whether that works any better.
> $< is GNU Makese for "first file this rule depends on".


Aha! So it is some quirky gnumakeism.. Well now, this is what I believe
the line to be:

ld -r -b binary -r -defsym TRANS_TBL=_binary_compdata_start compdata -o
table.o

Of course, I still don't have the -b or -defsym options, but I see that it
is
trying to link compdata to create table.o.  Now, I'm not quite sure then
what
compdata is supposed to be, is it supposed to be an ELF object file?  I see
that it is spit out by comptbl.  I mean, ld gives me this:

ld: compdata: malformed input file (not rel or archive)

And doing a quick file on the file doesn't tell me anything more than that
compdata is "data" (using perhaps an older version of file).  This part of
the
build process really confuses me, perhaps someone could shed more light
please?

Thanks all,
Tomo