tuxnes-devel — Development discussion for the TuxNES project

Re: [Tuxnes-devel] Uninitialized(??) statics in mapper.c:mmc1()

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

-On [20010310 06:08], Jim Ursetto (ji...@3e...) wrote:
>At 11:53pm on 2001 March 09, Jim Ursetto did write:
>
>> Can anyone explain or venture a guess as to why
>> (compiler, etc.) none of my globals/statics are
>> being initialized?
>
>To answer my own question: the bss segment wasn't being
>zeroed out, because the crt0.o I'm using doesn't do
>this.  (grr...)  Time to rewrite it.

Jim,

so this isn't a problem anymore I assume?

-- 
Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
	  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
Better to light a candle than to curse the darkness...

Re: [Tuxnes-devel] [ alexandria-Support Requests-404494 ] CVS repository clean-up: tuxnes (fwd)

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

-On [20010317 14:04], Mike Melanson (mel...@pc...) wrote:
>	We got our wish to have the TuxNES repository moved. The root for
>the TuxNES source code is the tuxnes/ directory on the server. You'll need
>to checkout fresh oopies of the CVS tree.

Works for me.

-- 
Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
	  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
Where do I take this pain of mine?

[Tuxnes-devel] [ alexandria-Support Requests-404494 ] CVS repository clean-up: tuxnes (fwd)

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

Hi team,
	We got our wish to have the TuxNES repository moved. The root for
the TuxNES source code is the tuxnes/ directory on the server. You'll need
to checkout fresh oopies of the CVS tree.

-- 
	-Mike Melanson



---------- Forwarded message ----------
Date: Thu, 15 Mar 2001 16:01:31 -0800
From: no...@so...
To: no...@so...
Subject: [ alexandria-Support Requests-404494 ] CVS repository clean-up:
    tuxnes

Support Requests item #404494, was updated on 2001-02-26 19:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=200001&aid=404494&group_id=1

Category: CVS
>Group: Second Level Support
>Status: Closed
Priority: 5
Submitted By: The Mighty Mike Master (tmmm)
Assigned to: Jacob Moorman (moorman)
>Summary: CVS repository clean-up: tuxnes

Initial Comment:
Hi there,
	Thank you for importing the existing CVS tree for the
TuxNES project. However, the project got imported into
the root of the CVS tree. Checking out the project
entails a 'cvs checkout .' command which is
unintuitive, and the source files get downloaded into
the current directory. If it's not too much trouble, I
was wondering if you could make a tuxnes/ directory in
the tree root and move all of the CVS files in there.

	If this is too much trouble (I don't know if it has
any ripple effects), then I understand.

	Thanks...
	-Mike

P.S. The TuxNES project is at:
  http://sourceforge.net/projects/tuxnes/
And the CVS browser is at:
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/?cvsroot=tuxnes

----------------------------------------------------------------------

>Comment By: Jacob Moorman (moorman)
Date: 2001-03-15 16:01

Message:
Logged In: YES 
user_id=152443

Greetings,

Per your request, the contents of the tuxnes project CVS
repository have been moved one level lower.  All files and
directories now reside within the 'tuxnes' module in the
tuxnes project CVS repository.  All members of your project
team should check out fresh copies of this repository. 
Please let me know if I may be of further assistance in this
matter.

Thank you,

Jacob Moorman
Quality of Service Manager, SourceForge

If you are interested in responding on the quality of
support provided by this individual, please log in to your
SourceForge account, then go to:
https://sourceforge.net/users/moorman or
http://sourceforge.net/users/moorman (non-SSL) and rate this
user using the SourceForge peer rating system.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=200001&aid=404494&group_id=1

Re: [Tuxnes-devel] ipc shm cruft + linux

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

-On [20010312 03:38], tux...@fa... (tux...@fa...) wrote:
>when I ctrl-c to kill tuxnes (for whatever reason.. im lazy, the window
>with it running was in front of me on the desktop in front of me on the
>head in front of me, etc.)

[snip shm info]

>I can use ipcrm shm <ID> to rm this, but a friend pointed out that the
>ctrl-c handling code should be able to clean up this before it exits the
>program.

Aha, a SIGINT handler.  Shouldn't take long to hack up.

Noted.

-- 
Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
	  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
He laughs best that laughs last...

[Tuxnes-devel] ipc shm cruft + linux

[<tux...@fa...>]

this is on a linux system running 2.2.19pre6.  tuxnes revision is the
cvs'd version as of about a week ago.

when I ctrl-c to kill tuxnes (for whatever reason.. im lazy, the window
with it running was in front of me on the desktop in front of me on the
head in front of me, etc.)

anyways, it leaves behind some cruft:

$ ipcs -m

------ Shared Memory Segments --------
key       shmid     owner     perms     bytes     nattch    status
0x00000000 2176      krt       777       983040    0

the normal running process has a nattch value of 2:
$ ipcs -m

------ Shared Memory Segments --------
key       shmid     owner     perms     bytes     nattch    status
0x00000000 2176      krt       777       983040    0
0x00000000 2177      krt       777       983040    2

if I use escape on the active tuxnes window (the proper kill method?) the
shm block goes away:
$ ipcs -m

------ Shared Memory Segments --------
key       shmid     owner     perms     bytes     nattch    status
0x00000000 2176      krt       777       983040    0

I can use ipcrm shm <ID> to rm this, but a friend pointed out that the
ctrl-c handling code should be able to clean up this before it exits the
program.

I'd go in and hack it myself, but im potentially dangerous in the .c arena
at this time.

Is this a known problem?  It doesnt seem to be in any files that I could
see.

And, just in case anyone else hasnt said it.. keep up the great work! I
love this program!

(and am now trying to help by submitting my bug report)

Re: [Tuxnes-devel] Uninitialized(??) statics in mapper.c:mmc1()

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

At 11:53pm on 2001 March 09, Jim Ursetto did write:

> Can anyone explain or venture a guess as to why
> (compiler, etc.) none of my globals/statics are
> being initialized?

To answer my own question: the bss segment wasn't being
zeroed out, because the crt0.o I'm using doesn't do
this.  (grr...)  Time to rewrite it.

-- 
"But if food is so good for you, how come the body
keeps trying to get rid of it?" -- breatharian.com
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

[Tuxnes-devel] Uninitialized(??) statics in mapper.c:mmc1()

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

In my port to the dreamcast, I had trouble with MMC1
games until I changed

static int mmc1reg[4];
static int mmc1shc[4];

in mapper.c's mmc1() to 

static int mmc1reg[4] = { 0 };
static int mmc1shc[4] = { 0 };

Debugging output confirms these were not originally
initialized to zero at the beginning of the program.

However, my understanding is that C -guarantees- that
static (and global) variables will be initialized to
zero, without explicitly doing this.

Can anyone explain or venture a guess as to why
(compiler, etc.) none of my globals/statics are
being initialized?  Virtually every problem I've had so
far is due to variables not being initialized; this
would save me a lot of pain...

-- 
"But if food is so good for you, how come the body
keeps trying to get rid of it?" -- breatharian.com
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

[Tuxnes-devel] RAM not explicitly initialized

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

Hi,

After RAM is malloc'ed (actually, mmap'ed), it is not
explicitly initialized.  Like the spriteram[] problem
mentioned in my earlier e-mail, this one is not noticed
on linux because RAM is magically zeroed out by the OS.
But this bug bit me hard when I was porting (took me
days to find).

For clarity RAM should probably be explicitly zeroed
out with memset(RAM, 0, 0x8000) or the like.

There are a few times when global variables are not
initialized either.  So far, I found at least CLOCK and
CTNI belong in this category.  There may be others.

-- 
"closing my eyes, i got a glimpse of several entities moving in front of
a giant complex control panel.  the creatures were bipedal and of about
human size. it was impossible to say more other than they did not move
like the giant insect creatures i have seen clearly under the influence of
stropharia mushrooms."             -- zarkov, "a hit of dmt 10/9/84"
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

Re: [Tuxnes-devel] Bug in pixels.h sprite rendering -- full patch

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

At 10:28pm on 2001 March 02, Jim Ursetto did write:
> I've found what seems to me a definite bug in sprite
> rendering in pixels.h, which works only by coincidence
> on linux x86 platforms. ...  Patch attached.  This fixes 
> 8, 16, and 32 bpp.

The original patch fixed the bug in non-scanline,
non-doubled modes.  Here's a new patch which fixes
scanline/doubled modes as well, and which also 
attempts to fix 1, 4, and 24 bpp.  Only 8, 16, 32 
bpp are tested, but 1, 4, and 24 should work.

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

[Tuxnes-devel] GTuxNES 0.3.0

[Scott D. W. <sd...@le...>]

Alright-

The all-night freezing rain and threat of a foot of snow forced ye olde
Administrators to shut down the University today, giving me plenty of
time to bang out a new release of GTuxNES.  The new version has support
for the latest set of command-line options and will save your selected
options and ROM filename at the click of a button to make the program
that much easier to use.

As always, the release is here:
http://www.scottweber.com/projects/gtk/gtuxnes/

Grab it, let me know what you think.  Find bugs, think of new features,
etc.

-Scott

[Tuxnes-devel] sound

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

Sound Updates:

emu.c: Fixed device busy error
sound.c: Fixed triangle channel linear counter (Fixes Zelda II opening title)

Thanks,
   Paul
-- 
Paul Zaremba
Senior - CSC, North Carolina State University
PGP Public Key - http://treeofice.2y.net/~pez/pez.pub

[Tuxnes-devel] Bug in pixels.h sprite rendering

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

I've found what seems to me a definite bug in sprite
rendering in pixels.h, which works only by coincidence
on linux x86 platforms.  Here's a (shortened) version
of the current code:

for (s = 63; s >= 0; s--) {
	render sprites into 256-char linebuffer
}
for (x = 0; x < 256; x++) {
	if (linebuffer[x]) {
		ptr0[spriteram[s*4+3] + x] = endian_fix(palette[linebuffer[x]]);
	}
}

The line containing "ptr0[]" is wrong.  It's obvious
that if spriteram[s*4+3] > 0, then spriteram[s*4+3] + x
can exceed 256, the boundary of the line.  It turns out
that the "render sprites" code in the previous loop
itself takes care of putting all sprites on the current
line in the correct position in the linebuffer, so we
should be able to remove the reference to spriteram[].
In fact, if you replace the line with 

ptr0[x] = endian_fix(palette[linebuffer[x]]);

you get exactly the same behavior.  Why?  Because "s" is
always -1 during the second loop---due to the first loop!
We're referencing spriteram[-1*4+3] = spriteram[-1]
which is (probably) uninitialized, and is therefore
zero under an operating system such as linux.  If
you're not running under an OS, well, let's just say
that if you avoid a crash your sprites aren't in the
right place anyway.  Probably the error above is 
just a vestige of old code and it wasn't caught 'cause it
doesn't do much harm normally...

Patch attached.  This fixes 8, 16, and 32 bpp.  I can't
test 1, 4, or 24 bpp so I didn't make a patch, though I
can have a go at it if you like.  I will note that all
those #defines get really confusing and require careful
negotiation ;)

Hope this is really a bug and I'm not missing something,
Jim

[Tuxnes-devel] MMC4 support

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

Hi team,
	I don't know if I could actually release a version of TuxNES
without at least 1 new mapper supported...:)

	With a little guessing, extrapolation, and luck, I figured out
that MMC4 is functionally equivalent to MMC2, except for one tiny
difference (the first 16K of PRG is switchable instead of just the first
8K). So I was able to leverage the MMC2 support and implement MMC4. So, if
you actually happen to have one of those exceptionally rare ROMs that uses
this mapper (Fire Emblem [Gaiden], (Family | Famicom) Wars, Japanese
version of Punch-Out!!, allegedly), it should work fine.

-- 
	-Mike Melanson

Re: [Tuxnes-devel] What a great program (status)

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

>> SNIP
> - there doesn't seem to be any actual code left for the old sine wave
> generation, so I removed the last traces of the sine/square toggling 
> options
I didn't leave any of the rendering code and didn't get around to removing the
support code.  Thanks!

> - updated the status of the sound functionality in README
> - updated the copyright date in emu.c to 1999-2001
> 
> 	A few questions/notes:
> - Paul, I noticed that there's no bass sound (i.e., triangle wave) in the
> opening title of Zelda II
I am looking at it.

> - Are we still supporting the echo/reverb option? It's commented out right
> now from the CLI option list and the sound_config.reverb variable isn't
> actually hooked up to any other code. Should we get rid of the remaining
> code for the sake of good housekeeping or will the echo option be back?
Echo/reverb is not yet supported, but if the demand is there I will add it..
or someone else is welcome to add echo.

>> SNIP
> - One last thing: Has anyone gotten a joystick to work under Linux
> 2.4? I'm having the worst time making a go of it...
> 
I have a USB joystick that works with the test program.. haven't used
my old Gravis 2 Axis 4 Button.

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

Working hard,
   Paul
-- 
Paul Zaremba
Senior - CSC, North Carolina State University

[Tuxnes-devel] What a great program (status)

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

Hi team,
	So I was messing around with TuxNES this evening and I remembered,
once again, what a truly awesome program TuxNES is! Good work to everyone
involved.

	Now then, here are the most recent changes:
- sound is enabled by default: Since the sound support is basically
complete, I don't see any reason to force the user to turn it on. After
all, a real NES enables sound by default...:)
- since sound is on by default, I added a way to turn it off: Specify the
audio file as 'mute' or 'none', e.g., 'tuxnes --sound=mute ...' Some may
wonder why the -s option is still there-- just in case the user needs to
specify a different audio device than /dev/dsp
- there doesn't seem to be any actual code left for the old sine wave
generation, so I removed the last traces of the sine/square toggling 
options
- updated the status of the sound functionality in README
- updated the copyright date in emu.c to 1999-2001

	A few questions/notes:
- Paul, I noticed that there's no bass sound (i.e., triangle wave) in the
opening title of Zelda II
- Are we still supporting the echo/reverb option? It's commented out right
now from the CLI option list and the sound_config.reverb variable isn't
actually hooked up to any other code. Should we get rid of the remaining
code for the sake of good housekeeping or will the echo option be back?
- I think we should have a common header on top of all of the source
files. I propose something minimal like this:

/*
 * This file is part of the TuxNES project codebase.
 *
 * Please see the README and COPYING files for more information regarding
 * this project.
 *
 * $ID:$
 */

A more detailed description of a specific file's functionality can follow
in a separate comment after the primary header. If there are no
objections to this, I'm going to get started on this tomorrow. I'll make
an exception for unzip.* because the copyright notice kindly requests that
the header not be modfied.
- One last thing: Has anyone gotten a joystick to work under Linux
2.4? I'm having the worst time making a go of it...

	BTW, if anyone is trying the daily CVS snapshots, they haven't
actually been updated since I moved the site to Sourceforge. I thought I
should mention that before people try it and get confused.

-- 
	-Mike Melanson

[Tuxnes-devel] HACKING file

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

Hi team,
	I just committed a [currently barebones] developers' guide called
HACKING to the CVS repository. This is inspired by the Gnuboy emulator
which I tried out recently. I was highly impressed with their HACKING file
and I would like to document our system as thoroughly. Suggestions on how
to proceed are welcome.

-- 
	-Mike Melanson

[Tuxnes-devel] zip support is in CVS

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

Hi team,
	Latest ChangeLog revision:

2001-02-28  Mike Melanson <mel...@pc...>
 
        * Added zip support, courtesy of Kevin Lindsay
        <kli...@mk...>
 
        * Updated README to explain compressed file support

-- 
	-Mike Melanson

Re: [Tuxnes-devel] CPU core graft

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

At 08:36am on 2001 February 27, Mike Melanson did write:
> On Tue, 27 Feb 2001, Jim Ursetto wrote:
 
> 	So is the plan to be able to include a portable 6502 core in the
> TuxNES program? That would be my plan anyway, and nes6502 sounds like a
> good candidate core.

Well, my plan was to port the thing to the dreamcast; the portable
core was a nice side-effect.  But it would definitely be useful to
have one in the mainline distribution, as long as it can be done
cleanly.

I do not think the dynamic recompiler can be made to conform to a
generic interface---the program flow is completely different, E.g.,
the recompiler effectively reimplements inline a Write6502() function
for -each- store instruction, while a portable core just calls a
generic Write6502() function for stores.  Also, the assembly code
always keeps some values in registers (cycle count in particular, in
%esi), so you'd have to futz around with pushing these registers on
the stack before you call C functions that need them.  I've done
this, but it isn't pretty, and it'd be easier to just add some
glue functions so that other cores can be hooked in, and leave
the recompiler be.

By the way, there's no visible speed difference between running the
assembly and C cores on my Celeron/366, at least when rendering is
turned on.  With the None renderer and speed NOT capped at 60fps,
an fps display should show the actual difference.  I'll probably try
that out soon.

> > I'll make the new code available on my web page in the
> > not-too-distant future
 
> 	Take your time; as I mentioned in my last message, I was hoping to
> 	do the portable CPU thing in the next version. How is it coming?
> 	Have you actually gotten it up and running on the Dreamcast yet?
Yesterday was the first time I tried to compile it for the dreamcast
(I wrote pretty much all the necessary code first).  I got it to the
point where emulation starts and runs correctly for a couple frames
before locking up.  The lockup point, and certain values such as
sprite0hit (!!), change when I insert innocuous code like "fprintf"
or "for(x=0;x<5;x++);".   So I suspect a very nasty uninitialized
memory pointer somewhere.  But it's on the verge of working...

-- 
"But if food is so good for you, how come the body
keeps trying to get rid of it?" -- breatharian.com
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

Re: [Tuxnes-devel] Re: [tuxnes-dev] Steve's memory patch

[<spi...@my...>]

What's broken in BSD?
I realize that using more virtual ram then you need to isn't a big problem, but it's still better to allocate it only if you need to..
For some reason we are allocating about 20 megs worth, and only really using 3... It just seems to be quite sloppy to me :-)
What I did for my patches was just grep through the source for FIXME's, then fix them(I think ;-).. Let me know is you found anything nasty from those patches..
The memory handling should be fine, don't see any problems there... I wonder if the defines react wierd on BSD?

				Steve

On Tue, Feb 27, 2001 at 06:48:00AM +0100, Jeroen Ruigrok/Asmodai wrote:
> Don't be fooled by things though.
> 
> FreeBSD also assigns a VSIZE value but only allocates this when the
> application really needs it.  In other words, should you add up the
> VSIZEs and other SIZEs the result could be very skewed in that it won't
> measure up to your memory and swap partition sizes.
> 
> I need to fix the sourcecode first before I can even compile it on BSD
> again. =P
> 
> -- 
> Jeroen Ruigrok vd Werven/Asmodai    asmodai@[wxs.nl|bart.nl|freebsd.org]
> Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
> 	  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
> I'm a child of the air, I'm a witch of the wind...
> 
> _______________________________________________
> Tuxnes-devel mailing list
> Tux...@li...
> http://lists.sourceforge.net/lists/listinfo/tuxnes-devel

-- 

Re: [Tuxnes-devel] CPU core graft

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

On Tue, 27 Feb 2001, Jim Ursetto wrote:

> Yeah, I remembered Matt Conte's cpu core after I sent that
> message.  Since Marat's works for me right now on my own project,
> it's not a high priority to change, though it will help in making
> the interface more generic (and possibly including a portable
> core in tuxnes later).

	So is the plan to be able to include a portable 6502 core in the
TuxNES program? That would be my plan anyway, and nes6502 sounds like a
good candidate core.

> At the very least it makes tuxnes easier to understand and port ;)
> I'll make the new code available on my web page in the
> not-too-distant future, once it's fit for presentation (unless
> somebody REALLY wants to see it RIGHT NOW).

	Take your time; as I mentioned in my last message, I was hoping to
do the portable CPU thing in the next version. How is it coming? Have you
actually gotten it up and running on the Dreamcast yet?

-- 
	-Mike Melanson

[Tuxnes-devel] Releasing v0.75 (not yet)

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

Hi team,
	Don't worry; I'm not releasing v0.75 just yet. I'll wait for
Asmodai's fixes so that we officially support FreeBSD again. Hopefully, it
will be enough time for Scott to update GTuxNES for a simultaneous
release. The things I want to do still:
- apply Steve's memory patch
- apply the zip patch
- go through all of the options and see which ones still exist and
work; clean out the others
Then I feel we can get this release out the door. That will be v0.75. I
predict that v0.76 will have us working hard on save state support and the
portable CPU core. The latter feature should also lead us to be able to
support some more mappers.

-- 
	-Mike Melanson

Re: [Tuxnes-devel] CPU core graft

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

At 09:41pm on 2001 February 26, Mike Melanson did write:
> On Fri, 23 Feb 2001, Jim Ursetto wrote:
 
> > I'm pretty sure Marat's license is incompatible with
> > the GPL, but the glue between tuxnes and the new cpu
> > core, being written by me, is. ;)
> 
> 	I don't mean to discourage you from writing a new 6502 core, if
> that's what you really want to do. But I think there are several open
> source cores out there which have much looser licenses that Marat's 
My last sentence was kind of confusing.  What I meant was, the
glue (interface) is written by me and so is useable, even if the
particular core I chose was not.  That said, I wrote about 90% of
a 6502 core as an experiment several months ago, though I don't
currently plan to finish it ;)

> 	Come to think of it, though, Nosefart is GPL'd and it relies
> 	on a 6502 emulator core. Have you checked that out?
Yeah, I remembered Matt Conte's cpu core after I sent that
message.  Since Marat's works for me right now on my own project,
it's not a high priority to change, though it will help in making
the interface more generic (and possibly including a portable
core in tuxnes later).
 
> 	I would be very interested to see it and eventually incorporate it
> into the codebase. We may even be able to use it to emulate games with 
> certain mappers that can't be emulated under the current NEStra/TuxNES
> model.
At the very least it makes tuxnes easier to understand and port ;)
I'll make the new code available on my web page in the
not-too-distant future, once it's fit for presentation (unless
somebody REALLY wants to see it RIGHT NOW).


-- 
"... [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] Re: [tuxnes-dev] Steve's memory patch

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

-On [20010208 10:44], Steve Pinkham (spi...@ki...) wrote:
>And yes, it does use about 2-3 megs or real ram, over 20 megs virtual
>ram..  Don't remember the executables being any bigger, but darn, we're
>still allocating way to much memory somewhere....
>To see this, run "ps aux | grep tuxnes", and check the 5th
>column(vsize, which as best I can tell is all virtual memory assigned
>to tuxnes).  Resident size never goes over about 3 and a half megs on
>my machine, so all that virtual space is wasted...  Luckily, Linux is
>smart enough to not really give it that memory untill it needs it (or
>at least that's how I think it works, don't quite remember ;-) Could
>our resident BSD man give this a wirl on his box and see if he gets any
>interesting results?

Don't be fooled by things though.

FreeBSD also assigns a VSIZE value but only allocates this when the
application really needs it.  In other words, should you add up the
VSIZEs and other SIZEs the result could be very skewed in that it won't
measure up to your memory and swap partition sizes.

I need to fix the sourcecode first before I can even compile it on BSD
again. =P

-- 
Jeroen Ruigrok vd Werven/Asmodai    asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
	  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
I'm a child of the air, I'm a witch of the wind...

Re: [Tuxnes-devel] Sound and GTuxNES

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

-On [20010227 06:15], Mike Melanson (mel...@pc...) wrote:
>	Sorry to be sending so many messages tonight, but I really, truly
>want to get to a release soon.

As you noticed I am cleaning up the ``problems'' with the code from a
stylistic and pedantic point of view as well as solving the compilation
problems on FreeBSD.

So if you could wait a few days I'd appreciate it.

-- 
Jeroen Ruigrok vd Werven/Asmodai    asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
	  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
I'm a child of the air, I'm a witch of the wind...

Re: [Tuxnes-devel] Sound and GTuxNES

[Scott D. W. <sd...@le...>]

Mike Melanson wrote:
[snip]
>         Next, GTuxNES doesn't really reflect the current state of the
> sound, does it? Does TuxNES still feature an echo option? And since we
> have proper sound support, we no longer have (or need) the "simulate
> square wave" option, right? I've been using GTuxNES to help me learn GTK
> programming so I night be able to modify it myself.
> 
[snip]

Sorry about that, I didn't realize that the square wave and echo
features had disappeared -- I don't use them myself, so I didn't
notice.  I will get rid of those.  I have been slowly working on a new
release of GTuxNES that removes some of the weirdness from pipe
redirections and adds the use of an rc file to save the last used set of
options, simplifying its use even more.  I probably only need a couple
hours more work on it, but the question is when I will get that time. 
If / when we get a new release of TuxNES scheduled, I will make time to
get GTuxNES ready for a simultaneous release.

-Scott