tuxnes-devel — Development discussion for the TuxNES project

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

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

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

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


Hello, once again..

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:

ld -r -b binary -r -defsym TRANS_TBL=_binary_compdata_start  -o table.o
/usr/libexec/elf/ld: no input files

So, I still have that same question.. what am I supposed to be linking
here, or is this whole line wrong somehow?  (although this ld 
recognizes -b and -defsym at least).
[snip]

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

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

Hello, once again..

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:

ld -r -b binary -r -defsym TRANS_TBL=_binary_compdata_start  -o table.o
/usr/libexec/elf/ld: no input files

So, I still have that same question.. what am I supposed to be linking
here, or is this whole line wrong somehow?  (although this ld 
recognizes -b and -defsym at least).


> As for the "ld" command you included, my suggestion is to
> upgrade your binutils!


hehehe.. well, i've done stuff like that before, but really, it's
easier said than done.  FSF binutils doesn't really support OpenBSD,
so it's not like I can just go grab a new tarball and install that.
OpenBSD users are basically dependant on the binutils that is in
the OpenBSD tree, and while on many architectures they use binutils
2.10 and newer, i386 isn't yet (currently there are 2 versions of
gas and ld in the tree)...

so, anybody have any other ideas?  maybe as simple as telling
me what that link line should be?  the "$<" in the Makefile line
ld -r -b binary -r -defsym TRANS_TBL=_binary_compdata_start $< -o table.o
is confusing me here..

thanks,
Tomo

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

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

Okay, I misunderstood what context the #define was used in
(unfortunately I haven't got the TuxNES code here to look
at.) Eliminate the #define entirely, and find the C file
which is using the LASTBLANK variable. Change the C file's
LASTBLANK declaration to include the "asm" qualifier, and
all should be well.

As for the "ld" command you included, my suggestion is to
upgrade your binutils!

-ben

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



> Anyhow, my guess is that OpenBSD is using a non-ELF object 
> file format (the 'file'
> command will tell you for sure) and so the C identifier 
> LASTBLANK *is* the asm
> label _LASTBLANK. When you #define LASTBLANK to _LASTBLANK, 
> the C identifier becomes
> _LASTBLANK, which is the asm label __LASTBLANK.

OpenBSD/i386 uses a.out (other architectures use ELF and others)
although it is capable of running ELF binaries (the kernel itself
is a.out).  I've heard about the whole pre-fixing symbol names with
_ .. it seems something is broken.


> There is a way to do this portably, I believe: declare 
> _LASTBLANK with the "asm"
> type qualifier in C, like so:
> extern asm int _LASTBLANK; /* or whatever the C declaration 
> looks like, + asm */

good to know :)  unfortunately, this is a .S file which is being
processed with gcc but doesn't accept C statements.  So I'm still
not sure what the real solution to this is (but I agree, a quick grep
seems to me that LASTBANK isn't even -really- used and could probably
be removed, but what do I know, not having even ran the program once :).
  

I had to add a getopt.h, but then I was able to get all the way down to
table.o, where my linker says:

ld -r -b binary -r -defsym TRANS_TBL=_binary_compdata_start  -o table.o
ld: invalid command option `-b'

this ld is from a pretty old version of binutils.. it doesn't have the -b
or -defsym options.  I am guessing that the -b won't be necessary.. but
maybe there is some way to hack in the TRANS_TBL symbol in manually.
Also, what is this line actually supposed to link?  I see that the output
is table.o... but what are the src objects?

Sorry if I made it seem like it was working, but what fun would it be if
it were that easy? :)

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...>]

> Anyhow, my guess is that OpenBSD is using a non-ELF object 
> file format (the 'file'
> command will tell you for sure) and so the C identifier 
> LASTBLANK *is* the asm
> label _LASTBLANK. When you #define LASTBLANK to _LASTBLANK, 
> the C identifier becomes
> _LASTBLANK, which is the asm label __LASTBLANK.

OpenBSD/i386 uses a.out (other architectures use ELF and others)
although it is capable of running ELF binaries (the kernel itself
is a.out).  I've heard about the whole pre-fixing symbol names with
_ .. it seems something is broken.


> There is a way to do this portably, I believe: declare 
> _LASTBLANK with the "asm"
> type qualifier in C, like so:
> extern asm int _LASTBLANK; /* or whatever the C declaration 
> looks like, + asm */

good to know :)  unfortunately, this is a .S file which is being
processed with gcc but doesn't accept C statements.  So I'm still
not sure what the real solution to this is (but I agree, a quick grep
seems to me that LASTBANK isn't even -really- used and could probably
be removed, but what do I know, not having even ran the program once :).
  

I had to add a getopt.h, but then I was able to get all the way down to
table.o, where my linker says:

ld -r -b binary -r -defsym TRANS_TBL=_binary_compdata_start  -o table.o
ld: invalid command option `-b'

this ld is from a pretty old version of binutils.. it doesn't have the -b
or -defsym options.  I am guessing that the -b won't be necessary.. but
maybe there is some way to hack in the TRANS_TBL symbol in manually.
Also, what is this line actually supposed to link?  I see that the output
is table.o... but what are the src objects?

Sorry if I made it seem like it was working, but what fun would it be if
it were that easy? :)

Tomo

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

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

Here's the (long-winded) story:

Most non-ELF C compilers prefix external identifier names with an underscore
("_")
when generating assembly or machine code. This tradition dates back at least
to the
PDP-11 tools, and quite possibly earlier (I'm no historian, but the original
"a.out"
object file format did this.) As a result, many object file tools (gdb, nm,
objtool,
etc.) have ugly heuristics to convert the _-prefixed identifiers into
human-readable
identifiers (as seen in the C source.) This is a completely useless bit of
overhead,
now that nobody uses FORTRAN, COBOL or Pascal compilers very much. [In the
old days
FORTRAN was the default language, and C was the latecomer which bit off a
small un-
used part fo the FORTRAN identifier namespace.]

Most ELF C compilers, on the other hand, leave identifiers unchanged, and so
the rest
of the toolchain can Keep It Simple, and display identifiers exactly as they
appear in
object files. These days FORTRAN is the second-class citizen which must use
special
namespace protection :)

Keep in mind that Linux used to use an a.out object file format, and most
Linux
development migrated from a.out to ELF a few years ago. TuxNES is written in
the
ELF style, but with carefully-chosen names to make a.out support easy (I'm
not
sure, but I think NEStra may have been developed originally on an a.out
Linux
system.)

Anyhow, my guess is that OpenBSD is using a non-ELF object file format (the
'file'
command will tell you for sure) and so the C identifier LASTBLANK *is* the
asm
label _LASTBLANK. When you #define LASTBLANK to _LASTBLANK, the C identifier
becomes
_LASTBLANK, which is the asm label __LASTBLANK.

There is a way to do this portably, I believe: declare _LASTBLANK with the
"asm"
type qualifier in C, like so:

extern asm int _LASTBLANK; /* or whatever the C declaration looks like, +
asm */

Also retain the #define LASTBLANK _LASTBLANK, or fix the C files to use
_LASTBLANK.

The asm type qualifier should prevent an a.out C compiler from prefixing the
'_',
and ELF C compilers should ignore it.

Let me know whether that works :)

-ben

P.S. sorry to be so completely unresponsive for the last year (!), I've been
busy with
     a new job.

-----Original Message-----
From: Mike Melanson [mailto:mel...@pc...]
Sent: Thursday, August 23, 2001 11:17 AM
To: 'tux...@li...'
Subject: RE: [Tuxnes-devel] Trying to build on OpenBSD 2.9


On Thu, 23 Aug 2001, HUYNH,SONTRI (HP-Richardson,ex1) wrote:

> Actually.. (sorry, this email is following my train of actions) I just
> commented out
> the #include lines of x86.S and it builds fine.  In fact, I only have to
> comment out
> "#define _LASTBANK LASTBANK      /* Last memory page code executed in */"
> from 
> mapper.h.  
> 
> Does this make sense to anyone?

	Nope, but if it works, great. It also doesn't make sense that
LASTBANK doesn't actually seem to be used (assigned) anywhere in the code
(try 'grep LASTBANK *' in the source dir). I'm still puzzling over that 
one. Can you certify TuxNES as working on OpenBSD/i386 if that line in
mapper.h is gone? If so, I'll note that fact on the features page.

	-Mike Melanson




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

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

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

On Thu, 23 Aug 2001, HUYNH,SONTRI (HP-Richardson,ex1) wrote:

> Actually.. (sorry, this email is following my train of actions) I just
> commented out
> the #include lines of x86.S and it builds fine.  In fact, I only have to
> comment out
> "#define _LASTBANK LASTBANK      /* Last memory page code executed in */"
> from 
> mapper.h.  
> 
> Does this make sense to anyone?

	Nope, but if it works, great. It also doesn't make sense that
LASTBANK doesn't actually seem to be used (assigned) anywhere in the code
(try 'grep LASTBANK *' in the source dir). I'm still puzzling over that 
one. Can you certify TuxNES as working on OpenBSD/i386 if that line in
mapper.h is gone? If so, I'll note that fact on the features page.

	-Mike Melanson

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

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

> 	I admit, I don't know much about the build system on BSD
> systems. Is it all the same as GNU systems? Anyway, try placing:
> .extern LASTBANK
> near the top of x86.S.

Here is some preliminary info:
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd2.9/2.95.3/specs
gcc version 2.95.3 20010125 (prerelease)

GNU assembler version 1.92.3, OpenBSD $Revision: 1.2 $

OpenBSD uses a gnu toolchain, and for those that don't know, OpenBSD/i386
uses the a.out format rather than ELF which most use now.  Sometimes there
are directives that are different for different object formats.

I added ".extern LASTBANK" after #include "mapper.h" (doesn't seem to matter
where I placed it) and still got the same output as before:
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.

From what documentation I could find for gas:
.extern is accepted in the source program---for compatibility with other
assemblers---but it is ignored. as treats all undefined symbols as external.


I think that's why it's not already .extern'd in any way in the src
currently, but
for some reason, my gas doesn't like LASTBANK for some reason, and if I
comment
out the LASTBANK lines, then x86.o builds.. but correct me if I'm wrong,
LASTBANK
isn't the only undefined external symbol in x86.S, but for some reason it is
having a problem with LASTBANK in particular.

Actually.. (sorry, this email is following my train of actions) I just
commented out
the #include lines of x86.S and it builds fine.  In fact, I only have to
comment out
"#define _LASTBANK LASTBANK      /* Last memory page code executed in */"
from 
mapper.h.  

Does this make sense to anyone?

Tomo
 

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

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

On Wed, 22 Aug 2001, HUYNH,SONTRI (HP-Richardson,ex1) wrote:

> Nope, this won't work with the assembler.. I get:
> gcc -DHAVE_CONFIG_H -I. -I. -I.     -O -pipe -Wall  -I/usr/X11R6/include -c
> x86.S
> mapper.h: Assembler messages:
> mapper.h:35: Error: no such 386 instruction: `extern'
> 
> Sorry, I am not all that familiar with gas/x86, is there another syntax for
> declaring LASTBANK as defined elsewhere?  

	I admit, I don't know much about the build system on BSD
systems. Is it all the same as GNU systems? Anyway, try placing:
.extern LASTBANK
near the top of x86.S.

> Btw, this is all with tuxnes-0.75.  I'm not sure how different it is from
> the cvs

	Nope, no different.

> version.  I am unable to get very far in building that either, especially
> since I
> don't seem to have aclocal (is this supposed to be part of autoconf?).  

	Technically, aclocal is part of the automake package, which you
probably also have. You may wish to upgrade to the latest versions of
each.

-- 
	-Mike Melanson

Re: [Tuxnes-devel] Re: ESD Support

[Captain R. <ro...@dw...>]

> Remember a few messages ago when Paul mentioned there was a user
> who reported sound problems about a year ago?  That was me, and I am
> also using a Dell Inspiron 7000 with a Maestro 2.  I never figured out
> why the emu slows down so bad.  The driver author acknowledges a
> separate problem wherein the sound begins to crackle nonstop due to
> buffer underflow; I suspect this problem is related.  My solution was
> to give up on the Maestro and play the damn thing on the Dreamcast.
> 
> -- 
> ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710
> 
> 

Well I guess thats an option :).  sounds like the Maestro 2 has some
problems in general, I don't think I am up for that.

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

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

> 	1672 lines is correct. Let's see. x86.S uses a symbol named
> _LASTBANK which is defined in the included file "mapper.h" as
> LASTBANK. LASTBANK is declared in dynrec.c. I guess the 
> assembler on Linux
> is a little more forgiving than on OpenBSD when it comes to defining
> globals. Look in mapper.h and after the following line:
> 
> #define _LASTBANK LASTBANK      /* Last memory page code 
> executed in */
> 
> Add the line:
> 
> extern unsigned int LASTBANK;

Nope, this won't work with the assembler.. I get:
gcc -DHAVE_CONFIG_H -I. -I. -I.     -O -pipe -Wall  -I/usr/X11R6/include -c
x86.S
mapper.h: Assembler messages:
mapper.h:35: Error: no such 386 instruction: `extern'

Sorry, I am not all that familiar with gas/x86, is there another syntax for
declaring LASTBANK as defined elsewhere?  

Btw, this is all with tuxnes-0.75.  I'm not sure how different it is from
the cvs
version.  I am unable to get very far in building that either, especially
since I
don't seem to have aclocal (is this supposed to be part of autoconf?).  

Thanks for your help.

Tomo

[Tuxnes-devel] Re: Sound and ESD

[Captain R. <ro...@dw...>]

Ok upon actually reading the documentation I managed to stop the
resyncing. this is what I got:



$ esddsp tuxnes -v -R 22050 -E -l doubdra1.nes
Rom size: 262160
BufSize: 1024 bytes
Appending 22050 Hz 8-bit unsigned samples to /dev/dsp
NES/Famicom ROM
Mapper 1 (MMC1)  Program ROM 128k  Video ROM 128k
Using built-in palette "loopy"
[x11] TrueColor visual, depth 24, 32bpp, static colors, shared-memory
XImage
Warning: 6398.578 sec sound delay, resynchronizing
Skipping 171 frames.
Warning: 6398.578 sec sound delay, resynchronizing
Skipping 171 frames.
Warning: 6398.578 sec sound delay, resynchronizing
Skipping 171 frames.

so I set the minimum fora resync and it played great, with the delay of
course.  Now this still leaves the delema as to why tuxnes is very slow
for me sans esound.  without esound running I don't get any resync
messages or frameskip messages, just sluggish performance.

Re: [Tuxnes-devel] Re: Tuxnes-devel digest, Vol 1 #43 - 2 msgs

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

On Tue, 21 Aug 2001, Jon Niehof wrote:

> The renderer seems slow to me; I've been meaning to take a look at 
> that "sometime." I belive someone's already working on at least a 
> partial speedup. Do any of the X renderers even support SHM?

	Yep. TuxNES should compile with the MIT shared memory extensions
if they're available. Look for the following lines when you run
./configure:

checking for sys/ipc.h... yes
checking for sys/shm.h... yes
checking for X11/extensions/XShm.h... yes
checking for X11/extensions/Xext.h... yes

Are the right extensions being found?

-- 
	-Mike Melanson

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

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

On Tue, 21 Aug 2001, HUYNH,SONTRI (HP-Richardson,ex1) wrote:

> Hello,
> 	I see nobody knows if tuxnes should work on OpenBSD.  Well,
> I just tried on an OpenBSD 2.9 system, ./configure'd, tried to make,
> and got stopped pretty early.
> 
> 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? 

	1672 lines is correct. Let's see. x86.S uses a symbol named
_LASTBANK which is defined in the included file "mapper.h" as
LASTBANK. LASTBANK is declared in dynrec.c. I guess the assembler on Linux
is a little more forgiving than on OpenBSD when it comes to defining
globals. Look in mapper.h and after the following line:

#define _LASTBANK LASTBANK      /* Last memory page code executed in */

Add the line:

extern unsigned int LASTBANK;

And see it that fixes the problem. If it does, I'd wager that another
global will experience the same difficulty. Let us know how it turns out.

-- 
	-Mike Melanson

[Tuxnes-devel] Trying to build on OpenBSD 2.9

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

Hello,
	I see nobody knows if tuxnes should work on OpenBSD.  Well,
I just tried on an OpenBSD 2.9 system, ./configure'd, tried to make,
and got stopped pretty early.

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? 


tomo

Re: [Tuxnes-devel] Re: ESD Support

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

At 02:24pm on 2001 August 21, Captain Rotundo did write:
> Well I have never written any ESD apps, but since it is plaqueing me, I
> will look into it. I have an ESS Maestro on a Dell Inspiron 7000. the
> crackling and cut outs seem to make sence beign associated with the
> added layer, but that doesnt explain why the emu slows considerably when
> esd is turned off... Are their any known sound issues that may slow it?

Remember a few messages ago when Paul mentioned there was a user
who reported sound problems about a year ago?  That was me, and I am
also using a Dell Inspiron 7000 with a Maestro 2.  I never figured out
why the emu slows down so bad.  The driver author acknowledges a
separate problem wherein the sound begins to crackle nonstop due to
buffer underflow; I suspect this problem is related.  My solution was
to give up on the Maestro and play the damn thing on the Dreamcast.

-- 
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

[Tuxnes-devel] Re: ESD Support

[Captain R. <ro...@dw...>]

Well I have never written any ESD apps, but since it is plaqueing me, I
will look into it. I have an ESS Maestro on a Dell Inspiron 7000. the
crackling and cut outs seem to make sence beign associated with the
added layer, but that doesnt explain why the emu slows considerably when
esd is turned off... Are their any known sound issues that may slow it?
is it because it is processing all the sounds rather than letting them
get chopped up by esound ? I have never played doom for linux, I will
also look into the ioctl issues with the Maestro driver. 

Re: [Tuxnes-devel] Re: Tuxnes-devel digest, Vol 1 #43 - 2 msgs

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

>What areas of developement need help?

The renderer seems slow to me; I've been meaning to take a look at 
that "sometime." I belive someone's already working on at least a 
partial speedup. Do any of the X renderers even support SHM?

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

[Tuxnes-devel] Re: Tuxnes-devel digest, Vol 1 #43 - 2 msgs

[Captain R. <ro...@dw...>]

Hello,
	I've asked a sound question on this list, and it just occurred to me to
ask this.  What areas of developement need help?  Is there anything that
need atention that no one is working on, I would like to lend a hand.
thanks.

Re: [Tuxnes-devel] Re: Tuxnes-devel digest, Vol 1 #43 - 2 msgs

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

Hmm.. Zelda is my primary test game.

What kind of sound card do you have?  Does it gripe about resyncing?
The exact message would be:
Warning: (number) sec sound delay, resynchronizing

I am unable to reproduce the problem on my laptop.

I remember an issue last year with someone having a similar problem, and
it was that the driver for their sound card didn't support the necessary
ioctl to get near-realtime sound output.

Can you play Doom without any changes? I understand that Doom was the reason
the ioctl was added to begin with.

I would expect esddsp to add crackle and delay anyway, it is adding a layer
of processing to all audio output and tuxnes outputs sound at 60 segments
of sound a second (50 segments for PAL), the programs are racing along
trying to output sound, and esd probably outputs one segment, tuxnes sends it
the next, but esd delays processing the sound, then finally gets
it to the soundcard, then tuxnes sends it the next segment.. etc
It crackles because of timing issues.

I suppose the next thing to do is try to add ESD support directly into tuxnes.
Though if the sound gets delayed I believe there is nothing I can do.
Last time I worked with esd it didn't support querys of the timing delay
from sending it data to the sound actually reaching the user.. of course
that was 3 years ago.

On Mon, Aug 20, 2001 at 04:31:48PM -0400, Captain Rotundo wrote:
> > 
> > Hey,
> > Are you using the snapshot or the release version?
> > What game were you playing (so I can fix it if it still happens with
> > the snapshot)?
> 
> I downloaded and compiled from CVS, with ESD it is now much worse. the
> sound plays for about a second or two and cuts out, comes back
> infrequently.  without ESd it sounds great but it still very slow.
> 
> This is all with Zelda.
> 
> 
> > 
> > I updated the sound queue function so it would be more accurate with
> > regards to internal values and reading from the sound registers.
> > Unfortunately I didn't notice a performance hit until after the release
> > when I was playing MegaMan 2 (Quick Man Stage).
> > There is a change in CVS that should remove the problem with the
> > most-used audio channels - the DMC still needs the progressive
> > update because it's possible it can trigger an interrupt when it finishes
> > playing the audio.
> > 
> > I play on a F00F hampered P150 laptop (Debian Woody)
> > and it's usable at high audio rates (44Khz/8bit 22Khz/16 bit, my laptop
> > has problems at 44Khz/16bit that my desktop doesn't..)
> > 
> > I haven't used esd with it (don't like the additional overhead and it
> > tends to make audio sound tinny to me).
> > 
> > Thanks,
> >   Paul
> 
> 
> 
> _______________________________________________
> Tuxnes-devel mailing list
> Tux...@li...
> http://lists.sourceforge.net/lists/listinfo/tuxnes-devel

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

[Tuxnes-devel] Re: Tuxnes-devel digest, Vol 1 #43 - 2 msgs

[Captain R. <ro...@dw...>]

> 
> Hey,
> Are you using the snapshot or the release version?
> What game were you playing (so I can fix it if it still happens with
> the snapshot)?

I downloaded and compiled from CVS, with ESD it is now much worse. the
sound plays for about a second or two and cuts out, comes back
infrequently.  without ESd it sounds great but it still very slow.

This is all with Zelda.


> 
> I updated the sound queue function so it would be more accurate with
> regards to internal values and reading from the sound registers.
> Unfortunately I didn't notice a performance hit until after the release
> when I was playing MegaMan 2 (Quick Man Stage).
> There is a change in CVS that should remove the problem with the
> most-used audio channels - the DMC still needs the progressive
> update because it's possible it can trigger an interrupt when it finishes
> playing the audio.
> 
> I play on a F00F hampered P150 laptop (Debian Woody)
> and it's usable at high audio rates (44Khz/8bit 22Khz/16 bit, my laptop
> has problems at 44Khz/16bit that my desktop doesn't..)
> 
> I haven't used esd with it (don't like the additional overhead and it
> tends to make audio sound tinny to me).
> 
> Thanks,
>   Paul

Re: [Tuxnes-devel] Sound and esd

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

Hey,
Are you using the snapshot or the release version?
What game were you playing (so I can fix it if it still happens with
the snapshot)?

I updated the sound queue function so it would be more accurate with
regards to internal values and reading from the sound registers.
Unfortunately I didn't notice a performance hit until after the release
when I was playing MegaMan 2 (Quick Man Stage).
There is a change in CVS that should remove the problem with the
most-used audio channels - the DMC still needs the progressive
update because it's possible it can trigger an interrupt when it finishes
playing the audio.

I play on a F00F hampered P150 laptop (Debian Woody)
and it's usable at high audio rates (44Khz/8bit 22Khz/16 bit, my laptop
has problems at 44Khz/16bit that my desktop doesn't..)

I haven't used esd with it (don't like the additional overhead and it
tends to make audio sound tinny to me).

Thanks,
  Paul

On Mon, Aug 20, 2001 at 12:00:30AM -0400, Captain Rotundo wrote:
> Hi, I just joined this list and I have a few questions regarding sound.
> I run GNOME and esd on Debian Woody, whenever I run tuxnes with esd
> (using esddsp) the sound gets crackly and cuts out intermittantly. When
> I run tuxnes sans esd the sound is perfect but the emulator is
> substantially slower, too slow to play in fact (Pentium II 266Mhz w/ 196
> MB RAM) is this a known problem ? if so is it with esd or with tuxnes?
> and if no one knows any pointers on how to figure out who the problem is
> with, so that I can try to be helpful in fixing it?
> 
> thank you+
> 
> 
> _______________________________________________
> Tuxnes-devel mailing list
> Tux...@li...
> http://lists.sourceforge.net/lists/listinfo/tuxnes-devel

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

[Tuxnes-devel] Sound and esd

[Captain R. <ro...@dw...>]

Hi, I just joined this list and I have a few questions regarding sound.
I run GNOME and esd on Debian Woody, whenever I run tuxnes with esd
(using esddsp) the sound gets crackly and cuts out intermittantly. When
I run tuxnes sans esd the sound is perfect but the emulator is
substantially slower, too slow to play in fact (Pentium II 266Mhz w/ 196
MB RAM) is this a known problem ? if so is it with esd or with tuxnes?
and if no one knows any pointers on how to figure out who the problem is
with, so that I can try to be helpful in fixing it?

thank you+

Re: [Tuxnes-devel] saving the "state" of the game

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

On Tue, 14 Aug 2001, Jason Dorje Short wrote:

> May I suggest that TuxNES's "HACKING" document be expanded, or even that
> a separate directory for documentation is created?  It would be a pain
> to rewrite emulation documentation from scratch, but perhaps some of the
> authors of documents available on the web wouldn't be opposed to having
> their documents merged?

	Actually, if I know some of these NES document authors, they would
be quite opposed to having their docs redistributed in such a
manner. But I do like your idea of creating separate a doc/
directory. That's long overdue.

-- 
	-Mike Melanson

Re: [Tuxnes-devel] Problems compiling on SGI irix 6.2

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

On Thu, 16 Aug 2001, Peter Andersson wrote:

> Are there no efforts (to your knowledge) to port it to (risc-processor 
> based) os? )

	Actually, I've been brainstorming better solutions to the dyn-rec
problem. Ideally, it's going to be much more complete than the current 
x86 engine and much easier to port to other processors. The 2
non-x86-based computers I own and will test it on first are the PowerPC
and Hitachi SH-4 (Dreamcast) architectures. With any luck, I can create a
MIPS port as well, as long as I have testers (and I seem to have 2 people
for the task on this list).

	I love this low-level processor stuff.
-- 
	-Mike Melanson

Re: [Tuxnes-devel] Problems compiling on SGI irix 6.2

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

At 07:05pm on 2001 August 15, Peter Andersson did write:
> At 11:06 AM 8/15/01 -0500, you wrote:
> >At 11:41am on 2001 August 15, Peter Andersson did write:
> > > I am trying to compile tuxnes on an sgi machine running irix 6.2 and large
> > > parts of gnome.
> >TuxNES only works on x86 machines.  Sorry.
> Are there no efforts (to your knowledge) to port it to (risc-processor 
> based) os? )

BTW, "Rigel" <ri...@an...> said he was porting the dyn-rec engine
to an SGI machine.  This was back in April.  I don't know what came of
this.

-- 
"You cannot simultaneously have mass adoption and rigor" -- Clay Shirky
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710