tuxnes-devel — Development discussion for the TuxNES project

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

[Peter A. <pe...@da...>]

At 09:37 AM 8/16/01 -0500, you wrote:
>At 06:55pm on 2001 August 15, Jon Niehof did write:
> > >Are there no efforts (to your knowledge) to port it to (risc-processor
> > >based) os? )
> > Nope. The core does dynamic recompliation to x86, and nobody really
> > understands that part of the engine :)
>I think there are a couple people who understand it.  Heck, I
>understand it enough to be able to port it to another platform,
>if it was worth it.  I wrote a portable engine as well, but
>haven't integrated it into tuxnes yet.  Haven't had time, really.
Well this is good news! In the future i will be looking out for the 
portable engine in the new releases/cvs  of tuxnes. If you would like i 
would be more than happy to try it out.

Peter

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

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

At 06:55pm on 2001 August 15, Jon Niehof did write:
> >Are there no efforts (to your knowledge) to port it to (risc-processor 
> >based) os? )
> Nope. The core does dynamic recompliation to x86, and nobody really 
> understands that part of the engine :)
I think there are a couple people who understand it.  Heck, I
understand it enough to be able to port it to another platform,
if it was worth it.  I wrote a portable engine as well, but 
haven't integrated it into tuxnes yet.  Haven't had time, really.

-- 
The default Magic Word, "Abracadabra", actually is a corruption of the
Hebrew phrase "ha-Bracha dab'ra" which means "pronounce the blessing".
                                                    --fortune
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

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

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

>Are there no efforts (to your knowledge) to port it to (risc-processor 
>based) os? )
Nope. The core does dynamic recompliation to x86, and nobody really 
understands that part of the engine :) The end result is an emulator 
that's fast as heck, but not terribly portable.

Now, to get a renderer that can keep up...

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

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

[Peter A. <pe...@da...>]

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.
>
>--
>"My goal in life is to become yogurt." -- a cat-tree human from mars
>ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334=
 0710
>
>_______________________________________________
>Tuxnes-devel mailing list
>Tux...@li...
>http://lists.sourceforge.net/lists/listinfo/tuxnes-devel
Are there no efforts (to your knowledge) to port it to (risc-processor=20
based) os? )
I don=B4t know where to look in that case :(
(sorry about my short reply  but i have been out on the local pub with my=20
co-workers so i doubt that any longer reply would give you any more useful=
=20
information)... If i keep on going any longer you would just be reading a=20
lot of jiberish. ( I am going to work in about six hours.)

Thanks for your rapid reply! Its rare to get support/help on gnu/"freeware"=
=20
products this fast. Esprcially when the problem can`t be resolved without=20
trouble (knowledge in the os)...

Peter

And thanks for bringing this excellent game station for everyone to use (i=
=20
really miss it!)

Peter

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

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

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.

-- 
"My goal in life is to become yogurt." -- a cat-tree human from mars
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

[Tuxnes-devel] Problems compiling on SGI irix 6.2

[Peter A. <pe...@da...>]

I am trying to compile tuxnes on an sgi machine running irix 6.2 and large=
=20
parts of gnome. The configure script runs through with out any complaints.=
=20
But when i am trying to start compiling (using gnu make) i get the message=
=20
"gcc: -pipe is not supported". I tried to edit "-pipe" out of the makefile=
=20
but then i got lots of other errors (as expected).  They all look quite the=
=20
same so im just writing one:

as: Error: /x85.S line 353: Undefined symbol: CLOCK
	add CLOCK;%esi

By default configure uses gcc 2.95.2, i also tried g++ and egcs with no=20
success. As you might have expected i am not a programming guru, in fact i=
=20
don=B4t know the first thing about it. So my question to you is if there any=
=20
way to solve this?

If you have any clues please get back to me.

Thanks

Peter

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

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

Mike Melanson wrote:
>On Wed, 8 Aug 2001, Jason Dorje Short wrote:

> > I recently started using tuxnes again (good work with
> > the recent improvements, BTW), and it looks like
> > TuxNES has no "save state" feature like many other
> > emulators do.  (It's possible I missed it, in which
> > case please correct me.)

>       The save-state functionality for TuxNES is two-fold: 1) Be able to
>read NESticle Save State (.STA) files, since there are so many of them,
>and 2) implement read/write of the Standard NES Save State
>(SNSS) format. The SNSS format was a format put together by some smart
>people in the nesdev community that did its best to solve a lot of the
>problems one would encounter in developing a save state format. It's also
>supposed to be portable between different emulators. I don't think it's
>ever caught on; however, it's better than having to create our own
>format. Examining the format will probably point out all kinds of things
>you may not have thought of (that's what happened in my case).
>
>       I encourage you to check it out. The main web page that contained
>SNSS info has been redirected to, umm, adult-oriented material for some
>reason. I'll send you the latest spec when I dig it up on my hard drive.
>
>       Be aware that we will likely have to modify the mapper interface
>since, effectively, each individual mapper has to be able to save state.
>
>       I'll send you the spec files soon. BTW, I'll be on vacation
>for about a week, so don't be surprised if I don't answer email right
>away.

Sounds good.  I was unable to find the SNSS specification anywhere on
the web, and unfortunately looking at the NESticle Save State
specification (which I did find) I realized (as if I didn't know before)
that I don't know nearly enough about emulation/TuxNES to be making
these changes (although I'm certainly willing to try anyway).  I did
read some additional documents on NES emulation.

I do now know enough to be certain that my "solution" is a very poor one
(which I'm sure you knew just reading about it).  Although it saves all
32k of mapped RAM, other currently-unmapped RAM also needs to be saved. 
Also, the NESticle specification does indicate that additional registers
should be saved.  When this code worked for me it must have been because
everything else (RAM, registers) stayed the same.

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?

jason short

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

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

On Wed, 8 Aug 2001, Jason Dorje Short wrote:

> I recently started using tuxnes again (good work with
> the recent improvements, BTW), and it looks like
> TuxNES has no "save state" feature like many other
> emulators do.  (It's possible I missed it, in which
> case please correct me.)

	Nope, there's no save-state in TuxNES thus far, though it's been
on the to-do list from the get-go. Welcome to the team, and I look forward
to seeing your contributions.

	The save-state functionality for TuxNES is two-fold: 1) Be able to
read NESticle Save State (.STA) files, since there are so many of them,
and 2) implement read/write of the Standard NES Save State
(SNSS) format. The SNSS format was a format put together by some smart
people in the nesdev community that did its best to solve a lot of the
problems one would encounter in developing a save state format. It's also
supposed to be portable between different emulators. I don't think it's
ever caught on; however, it's better than having to create our own
format. Examining the format will probably point out all kinds of things
you may not have thought of (that's what happened in my case).

	I encourage you to check it out. The main web page that contained
SNSS info has been redirected to, umm, adult-oriented material for some
reason. I'll send you the latest spec when I dig it up on my hard drive.

	Be aware that we will likely have to modify the mapper interface
since, effectively, each individual mapper has to be able to save state.

	I'll send you the spec files soon. BTW, I'll be on vacation
for about a week, so don't be surprised if I don't answer email right
away.

-- 
	-Mike Melanson

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

[Jason D. S. <jas...@ya...>]

I recently started using tuxnes again (good work with
the recent improvements, BTW), and it looks like
TuxNES has no "save state" feature like many other
emulators do.  (It's possible I missed it, in which
case please correct me.)

So, I set out to implement this.  I created two
functions, savestate() and restorestate().  I
arbitrarily picked keys F11 and F12 to link to them. 
(These were obviously unused, while most other logical
keys to use for this were in use.  I only have
bindings for X11 at the moment.)

Currently, the "state" that is saved includes only the
program counter, stack pointer, and the first (only?)
32k of RAM.  Amazingly enough, this more-or-less
works!  I had thought that additional registers (which
I saw reference to in the dyn-rec file) would have to
be saved as well, but I guess they're placed somewhere
in the RAM pages when not in use (?).  All this took
very little time (~20 minutes).  I can now save and
restore the state, and everything works fine (except
as below).  (I quickly racked up tokens in the Dragon
Warrior 4 casino using it.  Ahh, cheating...)

A somewhat major problem is that graphics are not
immediately updated after the restore.  At first I
thought this could be solved by forcing a refresh, so
I set the "needsredraw", "redrawall", and
"redrawbackground" flags to force a redraw.  When this
didn't work, I immediately realized my error - of
course the graphics are drawn by the game's code, so
the graphical frontend (X11) has no way of knowing
what to draw until the game chooses to redraw.  This
suggests that the image on the screen must also be a
part of the saved state.  However, this presents a
problem because it is frontend-specific: the code for
creating a digital segment for the image will be
different between different graphical systems.  More
importantly, the data format itself will most likely
be different (unless pains are taken to convert it to
a standard format) - this is already the case with
screen shots.

I don't have a patch to give you right now, since my
computer is currently disconnected from the internet
(a DSL problem); this is the same reason why I'm
posting from this random Yahoo account (for which I
apologize, especially if it kills the formatting).  In
a few days I should have it fixed.

Another goal of this subproject would be to be
compatible with other emulator saved-state files. 
However, a cursory web search won't tell me what the
format for NESticle saved state files is.

jason short


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [Tuxnes-devel] Sound routine abstraction

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

At 09:46pm on 2001 July 21, Mike Melanson did write:
> On Fri, 20 Jul 2001, Jim Ursetto wrote:
> 
> > 
> > Any reason this would not be a good idea?
> 
> 	Sounds like a good idea. I'll be interested to see what you have
> when it's ready to submit.

OK, I will flesh out my current modifications and post a patch here.

-- 
"You can eat if you want to; that's your prerogative...  I used to play
that game... I know what it's like...  But I'm just not interested in it
any more... I'm not interested in going out, and working for the money to
buy the food, then shopping for it, then going home and preparing it, then
eating it, then washing the dishes, then just letting it all out in the
toilet... and in the end, you end up in a box, in the ground, on the
outside of town."  -- breatharian.com
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

Re: [Tuxnes-devel] Sound routine abstraction

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

On Fri, 20 Jul 2001, Jim Ursetto wrote:

> 
> Any reason this would not be a good idea?

	Sounds like a good idea. I'll be interested to see what you have
when it's ready to submit.

-- 
	-Mike Melanson

Re: [Tuxnes-devel] Sound routine abstraction

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

At 11:05pm on 2001 July 20, I wrote:
> It seems like it might be a good idea to abstract the InitAudio()
> and UpdateAudio() routines into platform-specific functions, and
> call the old InitAudio() etc. functions through an indirect call

OK, I did this, and it works well.

Also, I have a performance question.  In the new progressive architecture,
ProgressiveSoundUpdate() is always called no matter if sound is
enabled or not.  This seems kind of wasteful.  It may not have much
of an impact, but you can effectively disable the sound calculations
by setting samples_per_vsync to 0 (this skips the while loop at the
top of Progressive...() ).

-- 
"You can eat if you want to; that's your prerogative...  I used to play
that game... I know what it's like...  But I'm just not interested in it
any more... I'm not interested in going out, and working for the money to
buy the food, then shopping for it, then going home and preparing it, then
eating it, then washing the dishes, then just letting it all out in the
toilet... and in the end, you end up in a box, in the ground, on the
outside of town."  -- breatharian.com
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

[Tuxnes-devel] Sound routine abstraction

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

It seems like it might be a good idea to abstract the InitAudio()
and UpdateAudio() routines into platform-specific functions, and
call the old InitAudio() etc. functions through an indirect call,
e.g. sound->InitAudio().  This would mirror what the renderer
currently does.  

Just as the renderer has Renderer and RendererConfig structs, the
sound engine could add a Sound struct to complement its
SoundConfig struct.

This thought came about because I'm currently adding sound support to
the dreamcast port, and thought it would be clearer to have
InitAudioDC() instead of overwriting the current InitAudio().
It would help with portability.  You might have functions 
like InitAudio{Linux,OSS,ALSA,ESD} and so on.

I think I will go ahead and implement this in my copy of the
tree.  I would then be happy to submit a patch if it's worthwhile,
once we agree on naming conventions.  

Any reason this would not be a good idea?

Jim

-- 
"Sometimes I have trouble making bowel sounds." -- Fernando
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

Re: [Tuxnes-devel] Speed?

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

-On [20010627 21:20], Jim Ursetto (ji...@3e...) wrote:
>The list is alive!  Thought I got unsubscribed.

Nah...

I got tied up at work.

Now spending last two days at this job and then moving back closer to
home to work.  [effectively cutting my travel time back with 2-.25 hours
a day, wheee]

So I hope to start cleaning up the source soon again.

-- 
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/
When you are right, you cannot be too radical; When you are wrong, you
cannot be too conservative.

Re: [Tuxnes-devel] Speed?

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

-On [20010628 03:17], Jon Niehof (jn...@yi...) wrote:
>(time to grab the CVS and see if it's any better than 0.75)

I don't think much things changed since 0.75.

-- 
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] Speed?

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

-On [20010627 21:50], Jon Niehof (jn...@yi...) wrote:
>Do you have some profiling code?

I added a configure option for that long ago. :)

-- 
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/
To do injustice is more disgraceful than to suffer it...

Re: [Tuxnes-devel] Speed?

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

Thanks for your help. I got GGI up and running, and it seems
substantially faster, indicating the X renderer needs some work. Under
DGA mode it's pretty smooth

Now I need to figure out what's causing the annoying vertical scroll
flicker (top and bottom of screen transpose themselves when scrolling
vertically; playing with the mirroring didn't help)--maybe this is a
vsync problem? Then I have to port GGI to Glide 3. Gack. First I have to
port snes9x, now I have to port GGI so I can play TuxNES.

BTW, I'd like to submit that the next version *not* be 1.0. The speed
and display quality aren't quite there yet. 0.9 I can see, but not 1.0.
Of course it's still far beyond what it was last time I checked it out.

(time to grab the CVS and see if it's any better than 0.75)

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

Re: [Tuxnes-devel] Speed?

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

At 02:23pm on 2001 June 27, Jon Niehof did write:
> >  I'm at the point where the actual CPU emulation (not using the dyn-rec
> >  engine) uses >50% of the time
> Do you have some profiling code?
The DC has configurable system timers, to profile a specific section I
check the time at two points and subtract, then add that delta to a global
counter.  Also, I do this at emulation start and end time, then divide it
by total # of frames for an accurate fps count.

At one point I added FPS calculation to the x86 version in my copy of the
tree.  I doubt I have the code any more, but it's trivial to do, since you
can use gettimeofday() instead of custom timer code.
 
> That would be very cool. Heck, I'd like to run on my Dreamcast...
I will probably make an initial release once I achieve 60 fps consistently.
In the meantime, there are other released NES emus for the DC (they may run
slow too, though).

-- 
"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] Speed?

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

>The renderer is not the fastest thing ever.  Plus you have the overhead
of
>X...  I think it is possible to use DGA with X, if it is not then try
>loading the ggi libraries and playing in DGA mode.  This works well for
me.

I haven't seen an option anywhere for running via DGA. Does it do this
automagically if you're root? I was also under the impression that
MIT-SHM took out a lot of X's overhead. And I've left ggi behind awhile
ago...

>We lose the ability to support the color emphasis and monochrome
>bits, but gain a lot of speed.  These changes, along with some
modifications
>to sprite rendering, have increased my speed from 20 fps to 55.

Sounds cool

>  I'm
>at the point where the actual CPU emulation (not using the dyn-rec
engine)
>uses >50% of the time, so it's worth optimizing that now.

Do you have some profiling code?

>  I may backport
>pixels.h to the x86 version of TuxNES to check on the speedup.

That would be very cool. Heck, I'd like to run on my Dreamcast...

>BTW, TuxNES already has an automatic frame skip.  
>Look in the UpdateDisplay*() functions.

Hmmm. It doesn't seem to do it, then. It seems to render every frame and
wait if necessary.

>Have you tried disabling sound?  It plays jerky if I leave it on...

No difference here.

It's particularly odd how the old renderer is supposedly faster than the
new, but doesn't seem so for me. I guess the renderer itself is faster,
but the overhead in X is greater.

Is anyone else working on speedups in the X renderer?

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

Re: [Tuxnes-devel] Speed?

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

The list is alive!  Thought I got unsubscribed.

At 11:18am on 2001 June 27, Jon Niehof did write:
> I'm running a K6-2 500, and Final Fantasy III feels subjectively slow--
> pans are slow, etc. etc. It seems to be sustaining about 40 fps. Using
> the differential renderer, top reports 85% CPU in TuxNES and 15% in X.
> The standard X11-based renderer runs more of a 50/50 split.
On my celeron 366, with xfree86 3.3.6, it runs at about 40-50 fps, and usually
a solid 60fps using DGA.  Though I haven't tried FF3.
 
> I'm presuming, since the core engine is quite fast, that the renderer is
> the slow point here. Is this correct? And do other people sense that
> TuxNES feels slow? Would perhaps an automatic frame-skip to keep up at
> 60fps help? Or is that a hidden option somewhere?
The renderer is not the fastest thing ever.  Plus you have the overhead of
X...  I think it is possible to use DGA with X, if it is not then try
loading the ggi libraries and playing in DGA mode.  This works well for me.

I have been working on a modification to the renderer, basically to make it
playable on my dreamcast, which is also not the fastest thing ever.  The major
changes are (1) render 8 horizontal pixels per inner render loop (rather
than 1 per loop), and (2) render one line at a time, rather than partial
lines.  We lose the ability to support the color emphasis and monochrome
bits, but gain a lot of speed.  These changes, along with some modifications
to sprite rendering, have increased my speed from 20 fps to 55.  I'm
at the point where the actual CPU emulation (not using the dyn-rec engine)
uses >50% of the time, so it's worth optimizing that now.  I may backport
pixels.h to the x86 version of TuxNES to check on the speedup.

BTW, TuxNES already has an automatic frame skip.  
Look in the UpdateDisplay*() functions.

Have you tried disabling sound?  It plays jerky if I leave it on...

-- 
"There is a very hollow echo of a gaur in the birth of that animal to a cow
in Iowa.  To say that is a gaur is to disrespect all gaurs in all the places
where gaurs live.  That animal will never live its life in true gaurdom, to
wander in the forests of India and frolic with other gaurs and die and let
teak trees grow out of it.  That's the gaur I'm working to save." -K. Redford
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

[Tuxnes-devel] Speed?

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

Reading through the archives I noticed some speed comparisons and how 
the dynamic recompilation engine basically kicks ass. At the risk of 
sounding whiny, why is it then that TuxNES under Linux is tons slower 
than my DOS version of Nesticle? (quite a bit slower than snes9x as a 
matter of fact). This isn't meant to be a complaint, more a request for 
how I can make it faster user-side, and where I should start digging 
into code for improvements on that end.

I'm running a K6-2 500, and Final Fantasy III feels subjectively slow--
pans are slow, etc. etc. It seems to be sustaining about 40 fps. Using 
the differential renderer, top reports 85% CPU in TuxNES and 15% in X. 
The standard X11-based renderer runs more of a 50/50 split.

I'm presuming, since the core engine is quite fast, that the renderer 
is the slow point here. Is this correct? And do other people sense that 
TuxNES feels slow? Would perhaps an automatic frame-skip to keep up at 
60fps help? Or is that a hidden option somewhere?

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

[Tuxnes-devel] CPU info (was Parlis.com)

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

On Wed, 2 May 2001, NightFlight wrote:

> Hey guys, I've been lurking for a few months. Hmmmm... maybe closer to a 
> year? Dunno... Anyhooo... Point me to the latest release on the weeb. ;-)
> It's been a while since I've tried it out tuxnes. Last time I did, it had 
> audio problems.

	The latest TuxNES (v0.75) can be downloaded from the main site:
  http://tuxnes.sourceforge.net
If you haven't seen (and heard) it yet, you really ought to check it out,
particularly for the complete sound support.

> A couple questions too... Which processor(s) in the NES are you emulating? 
> Where did you get the instruction set details?

	The main CPU in the NES is a custom 6502. You can find a ton of
info about the NES's special 6502 at:
  http://nesdev.parodius.com
At that site, you can also find a most of the rest of the information
that's known about the little gray box.

-- 
	-Mike Melanson

[Tuxnes-devel] audio update

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

* fixed buffer-off-by-1 that crashed some games
* implemented half and double+ speed audio
* changed #ifdef NOT_DEFINED to #if 0 for proper source format
-- 
Paul Zaremba
Senior - CSC, North Carolina State University
Use an Envelope, Please encrypt ALL EMail.
PGP Public Key - www.keyserver.net, pe...@cr...
                 http://treeofice.2y.net/~pez/pez.pub

Re: [Tuxnes-devel] Parlis.com

[NightFlight <nf...@ec...>]

On Thursday 26 April 2001 22:56, you wrote:
> On Thu, 26 Apr 2001, Rigel wrote:
> > --
> >
> > On Thu, 26 Apr 2001 07:00:57
> >
> >  Parlis.com wrote:
> > >Dear friend,
> >
> > who let these guys in?
>
> 	The way the list is configured, anyone can send email to the
> list. I got an email to my personal address as well. Probably had a robot
> crawling over Sourceforge. They must not know the audience.

Hey guys, I've been lurking for a few months. Hmmmm... maybe closer to a 
year? Dunno... Anyhooo... Point me to the latest release on the weeb. ;-)
It's been a while since I've tried it out tuxnes. Last time I did, it had 
audio problems.

A couple questions too... Which processor(s) in the NES are you emulating? 
Where did you get the instruction set details?

I just got out of school for the summer, our last project for one of my 
classes was to write an emulator for a fabricated instruction set (I thought 
it was a motorola stack machine until I handed it in and my teacher told me 
otherwise). It was cool. I'm pretty much the only one that got perfect, 
although it's incomplete, but works very well and has a nice face.

So, in otherwords... I'm curious. 

-- 
Mathematicians do it in theory.

Re: [Tuxnes-devel] Parlis.com

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

On Thu, 26 Apr 2001, Rigel wrote:

>  
> --
> 
> On Thu, 26 Apr 2001 07:00:57  
>  Parlis.com wrote:
> >Dear friend,
> 
> 
> who let these guys in?

	The way the list is configured, anyone can send email to the
list. I got an email to my personal address as well. Probably had a robot
crawling over Sourceforge. They must not know the audience.

-- 
	-Mike Melanson