tuxnes-devel — Development discussion for the TuxNES project

Re: [Tuxnes-devel] Fullscreen Tuxnes

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

On Fri, 15 Feb 2002, W. Michael Petullo wrote:

> I would like to implement a fullscreen mode in X11 tuxnes.  Is anyone
> else working on a similar feature?  Any comments?

	Nope, not that I know of. Go for it.

--
	-Mike Melanson

[Tuxnes-devel] Fullscreen Tuxnes

[W. M. P. <mi...@fl...>]

I would like to implement a fullscreen mode in X11 tuxnes.  Is anyone
else working on a similar feature?  Any comments?

-- 
Mike

:wq

Re: [Tuxnes-devel] Save State Stuff

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

-On [20020130 16:30], Mike Melanson (mel...@pc...) wrote:
>I'll post those items somewhere publically accessible tonight.

And? :)

-- 
Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam
asmodai@[wxs.nl|xmach.org], finger as...@ni...
http://www.softweyr.com/asmodai/
The administration of justice is the firmest pillar of government...

Re: [Tuxnes-devel] patch: mmc1 one-liner

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

-On [20020206 12:15], Allen Noe (psy...@ge...) wrote:
>Here's a one-line patch to the MMC1 routine so that my
>soon-to-be-posted save-state-3.patch can make sense of the mmc1shc
>array. It should change nothing other than removing the possibility of
>having an mmc1shc[] value overflow and go negative.

Applied, thanks!

-- 
Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam
asmodai@[wxs.nl|xmach.org], finger as...@ni...
http://www.softweyr.com/asmodai/
When the solution is simple, God is answering...

[Tuxnes-devel] patch: save-state-3

[Allen N. <psy...@ge...>]

It works! Well, sorta.

I fixed a lot of crash-causing bugs, and added pseudo-support for MMC1
(incompatible with everything else). So now it will work about as well as my
original raw format.

Making MMC1 state spec-compliant will require significant changes (no more
mmc1shc[]) that I'm not willing to make right now.

Please test more, and make sure I haven't missed anything else.

This one should be applied on top of save-state-1, save-state-2, and mmc1. If
this gets much more complicated I'll start posting patches against 0.75
unmodified, but the combined patch is 75k uncompressed..

[Tuxnes-devel] patch: mmc1 one-liner

[Allen N. <psy...@ge...>]

Here's a one-line patch to the MMC1 routine so that my soon-to-be-posted
save-state-3.patch can make sense of the mmc1shc array. It should change nothing
other than removing the possibility of having an mmc1shc[] value overflow and go
negative.

It applies to unmodified 0.75 (with a significant offset) and will not conflict
with any of my other patches.

Re: [Tuxnes-devel] patch: don't create /dev/dsp

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

-On [20020201 23:45], Allen Noe (psy...@ge...) wrote:
>Here's a little patch to make tuxnes stop trying to create /dev/dsp as
>a regular file with undefined mode. Incidentally, it also allows tuxnes
>-smute to start while another process is hogging /dev/dsp.

Yes, the open with O_CREAT is not really needed no. :)

Oh btw, do not mix style and code changes. :)

-- 
Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam
asmodai@[wxs.nl|xmach.org], finger as...@ni...
http://www.softweyr.com/asmodai/
Expansion of happiness is the purpose of life...

[Tuxnes-devel] patch: save-state-2

[Allen N. <psy...@ge...>]

Okay, here's a first hack at SNSS support. It uses libsnss.[ch] from nesterdc,
and should be appled on top of save-state.patch (it will not conflict with
stat-dsp.patch).

A few problems:

It doesn't work. I can't figure out what all of the base block variables are, or
how TuxNES stores them. Read state.c:(form|extract)_BASR for details. Also it's
completely untested, apart from the fact that it compiles.

I can't figure out how the SRAM or VRAM sizes are stored, or whether they're
stored.

I'm not certain about the transformations between MAPTABLE and prgPages, or the
way chrPages gets set, both in mapper.c:(form|extract)_MPRD.

Also in mapper.c, I had to replace every memcpy into VRAM with a function call
(MapVRAM) to get chrPages set. I did it mostly mechanically, but I still may
have messed something up (particularly the bit in aorom() that switches two
pages in VRAM). The alternative is to compare the contents of VRAM with the
contents of VROM, but that struck me as a bit of a kluge.

It will only work with mappers which store no internal state: 0, 2, 3, 11, 13,
33, 66, 68, 71, 78, and 231. It also should work with 19 and 225, but libsnss
claims they store internal state, so nothing else will work with what we output.
Adding cases to (form|extract)_MPRD is just a small matter of programming.

Finally, the patch is 70.1k, so I gzipped it. Now it's "only" 11.7k.

[Tuxnes-devel] patch: don't create /dev/dsp

[Allen N. <psy...@ge...>]

Here's a little patch to make tuxnes stop trying to create /dev/dsp as a regular
file with undefined mode. Incidentally, it also allows tuxnes -smute to start
while another process is hogging /dev/dsp.

InitAudio will still try to create the audiofile later, but it gives a mode, and
I suppose it could be useful for recording sound output.

Re: [Tuxnes-devel] TuxNES 0.75 save state patch

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

At 02:04am on 2002 January 30, Jason Short did write:
> Jim Ursetto wrote:
 
> > At 01:16am on 2002 January 30, Allen Noe did write:

> >>I'm also wondering if any of you have a format description for SNSS or
> >>.STA state files
> >>
> > Why don't you just use libsnss?
> 
> Where is it?
 
> A google search for libsnss turns up nothing, and searching for just 
> SNSS turns up a lot of unrelated stuff.

True, oddly enough.  I have a copy, though.  nester-dc v3 uses it and it's
included with the source code.  Both nester and libsnss are GPLed, so one
option is to study nester's interface to libsnss, and libsnss itself,
understand them, and then rewrite the support for tuxnes.  nester's code is
pretty clean, so it shouldn't be too hard.

I think google fails to find libsnss because it was previously stored on 
nofrendo.com, which seems to have disappeared.  You guys might want to join
the nesdev mailing list and ask where the code is kept now.

If you guys can't find the nester source code, I'll send along a copy of
nester-dc v3.


-- 
"Life is based upon a perfect math or your arm would be too short 
 to wipe your butt."   -- NATURE'S HARMONIC SIMULTANEOUS 4-DAY TIME CUBE
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

[Tuxnes-devel] Save State Stuff

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

Hi team,
	First, thank you all for your continued interest and development
on the TuxNES project.

	Second, about the save state stuff, yes I do have a number of
resources that would help development, including:
1) STA format, as reverse engineered by Matt Conte (we only want TuxNES to
be able to *read* this format)
2) SNSS format (read & write)
3) libsnss, a SNSS library reference implementation

I'll post those items somewhere publically accessible tonight.

--
	-Mike Melanson

Re: [Tuxnes-devel] TuxNES 0.75 save state patch

[Jason S. <vze...@ve...>]

Jim Ursetto wrote:

> At 01:16am on 2002 January 30, Allen Noe did write:
> 
>>Attached is an alpha-quality patch which adds _very_ primitive save state
>>functionality to TuxNES 0.75.
>>
>>I'm also wondering if any of you have a format description for SNSS or
>>.STA state files
>>
> Why don't you just use libsnss?

Where is it?

A google search for libsnss turns up nothing, and searching for just 
SNSS turns up a lot of unrelated stuff.

jason short

Re: [Tuxnes-devel] TuxNES 0.75 save state patch

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

Why don't you just use libsnss?

At 01:16am on 2002 January 30, Allen Noe did write:
> Attached is an alpha-quality patch which adds _very_ primitive save state
> functionality to TuxNES 0.75.
> 
> I'm also wondering if any of you have a format description for SNSS or
> .STA state files

-- 
"When I was a child, I did things as a child.
 Now that I'm a man, I bust your ass and get wild." --Black Sheep/Freak Y'all
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

Re: [Tuxnes-devel] TuxNES 0.75 save state patch

[Jason S. <vze...@ve...>]

Allen Noe wrote:

> Attached is an alpha-quality patch which adds _very_ primitive save state
> functionality to TuxNES 0.75.
> 
> It probably has all sorts of bugs, but I'm posting it here so I can get some
> comments on it. Particularly, I'm wondering if I'm saving something that doesn't
> need to be saved, or not saving something that should. I'm also wondering if any
> of you have a format description for SNSS or .STA state files, so the format it
> uses can be compatible with one or the other.
> 
> Currently it only supports the MMC1 mapper, and uses a file named "state" in the
> current directory, supports one slot only, supports X11 renderers only, and the
> keys are hardwired to F9 to save and F10 to load.
> 
> I have tested it on Linux only, and not very extensively.

I put together a primitive save-and-restore patch a few months ago.

Yours looks to be quite a bit more advanced than what I did - I just 
saved the PC, SP, and RAM and hoped on the rest.  It worked adequately 
for a few simple purposes :-).

Eventually Mike (I think) sent me a copy of the SNSS spec.  But I never 
got around to doing the hard context switching work, much less dealing 
with any of the different mappers.

Here's what I did (I think it has some extra changes unrelated to the 
patch, but not much).  I doubt it will help you in any way, but...

jason

[Tuxnes-devel] TuxNES 0.75 save state patch

[Allen N. <psy...@ge...>]

Attached is an alpha-quality patch which adds _very_ primitive save state
functionality to TuxNES 0.75.

It probably has all sorts of bugs, but I'm posting it here so I can get some
comments on it. Particularly, I'm wondering if I'm saving something that doesn't
need to be saved, or not saving something that should. I'm also wondering if any
of you have a format description for SNSS or .STA state files, so the format it
uses can be compatible with one or the other.

Currently it only supports the MMC1 mapper, and uses a file named "state" in the
current directory, supports one slot only, supports X11 renderers only, and the
keys are hardwired to F9 to save and F10 to load.

I have tested it on Linux only, and not very extensively.

The patch is GPL, so you can include it in the next release of TuxNES if you
want.

Any comments on it?

Re: [Tuxnes-devel] Updates

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

On Fri, 25 Jan 2002, Jeroen Ruigrok/asmodai wrote:

> Some of you might noticed, others now know as well:
> 
> I am slowly starting to update TuxNES again.

	Nope, hadn't noticed. But I trust you...:) I haven't given TuxNES
much time lately as I've been hacking a bunch on the MPlayer project.
Also, I purchased a top-loading control deck which means I've been
spending a lot of time playing the real NES again.

> Are there any bugs open still?
> 
> I'll reread the archives for the list and see if patches are still
> applicable.

	Plenty of bugs remain, of course. I haven't been keeping careful
track of them, though. Let us know which major items you plan to work on.

--
	-Mike Melanson

[Tuxnes-devel] Updates

[Jeroen Ruigrok/a. <as...@ni...>]

Some of you might noticed, others now know as well:

I am slowly starting to update TuxNES again.

Are there any bugs open still?

I'll reread the archives for the list and see if patches are still
applicable.

-- 
Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam
asmodai@[wxs.nl|xmach.org], finger as...@ni...
http://www.softweyr.com/asmodai/
Knowledge is soon changed, then lost in the mist, an echo half-heard...

Re: [Tuxnes-devel] configure on the fly

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

At 01:56am on 2002 January 16, Jason Short did write:
> Naesten wrote:
> 
> > Can somebody put a configure-on-the fly system into tuxnes? (console, 
> > loopynes-style-menus, nesticle style menus/dialogs, or something like 
> > that)?
> 
> You mean like:
> 
>    ./configure --console
>    ./configure --menustyle=loopynes
>    ./configure --menustyle=nesticle

I think he means adding some sort of interactive system such as menus;
he's not talking about GNU configure.  To my knowledge gtuxnes provides 
a menu wrapper around tuxnes, using tuxnes for display.  This is as
close as you can yet on x86 right now.

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

Re: [Tuxnes-devel] configure on the fly

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

At 02:59am on 2002 January 16, Naesten did write:
> Can somebody put a configure-on-the fly system into tuxnes? (console, 
> loopynes-style-menus, nesticle style menus/dialogs, or something like that)?
> -Naesten

This may not help you, but a similar thing is going in soon to the
Dreamcast port.  A game select menu is in the already-released version, and
the code is restructured to allow playing multiple games per session.
Other configurable items are next, though it may not look like loopynes or
nesticle.

-- 
"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] configure on the fly

[Jason S. <vze...@ve...>]

Naesten wrote:

> Can somebody put a configure-on-the fly system into tuxnes? (console, 
> loopynes-style-menus, nesticle style menus/dialogs, or something like 
> that)?

You mean like:

   ./configure --console
   ./configure --menustyle=loopynes
   ./configure --menustyle=nesticle

This should not be hard.  You just put the necessary checks in 
configure.in, and send output to config.h based on what they find.

But you're going to need to be a lot more definitive on how it should 
work to get me to do it :-).

jason

[Tuxnes-devel] configure on the fly

[Naesten <na...@my...>]

Can somebody put a configure-on-the fly system into tuxnes? (console, 
loopynes-style-menus, nesticle style menus/dialogs, or something like that)?
-Naesten

[Tuxnes-devel] tuxnes-dc v0.1 released

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

Hi everyone,

I've finally released tuxnes-dc v0.1, a port of TuxNES v0.75 CVS
to the Dreamcast.  Some may yawn at the release of Yet Another Emulator, 
but I had a lot of fun with it, and it taught me a lot about the DC.
And I expect that to continue.  More code can only help us, right?

You can pick it up at http://3e8.org/hacks.html.

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

Re: [Tuxnes-devel] [PATCH] Move palettes[] into palettes.h

[Jason D. S. <vze...@ve...>]

Jim Ursetto wrote:
> 
> Attached patch removes the quite long definition of palettes[] from
> emu.c and moves it to palettes.h.  Makes things a bit less cluttered.

This sort of thing should really go into a .c file rather than a .h one
IMO.  What about palettes.c?

jason

[Tuxnes-devel] [PATCH] Move palettes[] into palettes.h

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

Attached patch removes the quite long definition of palettes[] from
emu.c and moves it to palettes.h.  Makes things a bit less cluttered.

Jim

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

[Tuxnes-devel] [PATCH] pixels.h sprite right edge

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

tuxnes currently cuts off a sprite once its rightmost edge leaves the
screen.  As an example, load up Super Mario Bros. and notice how the
right half of a Goomba disappears when partially offscreen.  Tests on
a real NES indicate it should not be cut off.  Attached patch corrects
the problem.  It's not an ideal optimized solution, because that'd
require quite a bit of work.  (I only changed 3 lines, the rest is
indentation to compensate for the new "if".)

BTW, sprites off the left edge of the screen are cut off too, but this
is proper behavior according to the real NES.  Makes sense when you
think about it.  Top edge handling appears to be incorrect as well
but I'm still working on this.  Haven't looked at bottom yet.

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