tuxnes-devel — Development discussion for the TuxNES project

Re: [Tuxnes-devel] TuxNES v0.75 is available

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

On Mon, 16 Apr 2001, Jeroen Ruigrok/Asmodai wrote:

> -On [20010416 04:08], Mike Melanson (mel...@pc...) wrote:
> Is it me, or does the Makefile have a problem?

	Wow, that was sloppy of me! I never modified the Makefile.am file
to include unzip.h and ziploader.h. I fixed it now, *verified it*, and
uploaded a new archive. Only one other person reported the problem as of
this morning. Fortunately, TuxNES didn't make last night's Freshmeat
newsletter (although it has a vitality of 7.74% now, whatever that means).

	I committed the new Makefile.am. I even moved the tuxnes_0.75 tag
to the new version. 

> What do you do exactly to roll a release?  I'll build a tarball here as
> well and do a diff -ruN between the two and see what messes up.

	What I did last night was make sure everything was checked in and
tagged for tuxnes-0_75, go to a different directory, check out the
repository files as anonymous, do ./autogen, ./configure, make, and make
dist. I used that package. Silly me. For starters and completeness, I
should have checked out the files tagged with tuxnes-0_75, made the
distribution, moved the distribution to another directory and THEN tried
./configure and make. Live and learn.

> Also, could you add NetBSD to the supported OS's on SourceForge?

	I'll take care of it.

-- 
	-Mike Melanson

Re: [Tuxnes-devel] TuxNES v0.75 is available

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

-On [20010416 04:08], Mike Melanson (mel...@pc...) wrote:
>	No more running, no more hiding; TuxNES v0.75 is finally
>released.

Is it me, or does the Makefile have a problem?

[9:30] [asmodai@purgatory] (17) {0} $ gmake
gcc -DHAVE_CONFIG_H -I. -I. -I.     -O -pipe -Wall -I/usr/local/include  -I/usr/X11R6/include -c x86.S
gcc -DHAVE_CONFIG_H -I. -I. -I.     -O -pipe -Wall -I/usr/local/include  -I/usr/X11R6/include -c d6502.c
gcc -DHAVE_CONFIG_H -I. -I. -I.     -O -pipe -Wall -I/usr/local/include  -I/usr/X11R6/include -c dynrec.c
gmake: *** No rule to make target `unzip.h', needed by `emu.o'.  Stop.

A CVS compilation completes until the end.

So the rolling of the tarballs is messed I guess.  I tried the get it
working on three different boxes, all the same problem

What do you do exactly to roll a release?  I'll build a tarball here as
well and do a diff -ruN between the two and see what messes up.

Also, could you add NetBSD to the supported OS's on SourceForge?

Thanks,

-- 
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
Who got tha power?  This be my question...

[Tuxnes-devel] TuxNES v0.75 is available

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

Hi team,
	No more running, no more hiding; TuxNES v0.75 is finally
released.

	As mentioned, this is v0.75, not v1.0. I removed the HACKING file
from the distribution due to lack of completeness. I would sure like to
get a v1.0 release out soon which includes the HACKING file and fixes for 
any other minor problems we find with this release.

	I'm off to do all of the release announcements for this version.
-- 
	-Mike Melanson

Re: [Tuxnes-devel] misc info/questions

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

On Fri, 13 Apr 2001, Jeroen Ruigrok/Asmodai wrote:

> -On [20010412 01:01], Rigel (ri...@an...) wrote:
> >I have an account on a MIPS (SGI) machine!!
> 
> Heh.  I have two at home.
> 
> Currently busy porting FreeBSD to MIPS. :)

	Neat. Then we know we can count on you to help test the dyn-rec
engine for the MIPS machine...:) BTW, I might have been a little confused
when I referred to the "MIPS ISA". I'm not well-versed in all the
different types of MIPS processers.

-- 
	-Mike Melanson

Re: [Tuxnes-devel] misc info/questions

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

-On [20010412 01:01], Rigel (ri...@an...) wrote:
>I have an account on a MIPS (SGI) machine!!

Heh.  I have two at home.

Currently busy porting FreeBSD to MIPS. :)

-- 
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
All the pain I caused myself was out of love for others...

Re: [Tuxnes-devel] more help w/ asm

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

-On [20010412 03:00], Mike Melanson (mel...@pc...) wrote:
>	I already tried to discourage him and he still expressed interest
>in "porting" the dyn-rec engine to the MIPS ISA.

MIPS ISA is pretty sweet if it is the one used in the v4x00 and
subsequent family members.  I think that was MIPS language III or IV.

-- 
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
Once all struggle is grasped, miracles are possible...

Re: [Tuxnes-devel] more help w/ asm

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

On Thu, 12 Apr 2001, Rigel wrote:

> Yes I am trying to port the sucker to mips.  Wouldn't it be best though, to write the linkage (x86.S) in C?  Has anyone noticed that most of the jumps are given as offsets, not labels?  Also that it's almost completely undocumented?   I'm not relishing the thought of translating that to mips.  I'm beginning to see a conspiracy.  Who does this Quor guy work for?  I may have to mail him, eh?

	Actually, Quor is on this list, or at least the address from which
he used to post is still on the list. It's been awhile since we heard from
him.

	Regarding your question about why there's all that C-ASM linkage
written in ASM...umm, well good question...:) The best answer I have right
now is, "That's the way Quor did it originally." Fortunately, I see that
Jim has posted a more technical answer.

> Whoever it was who said they could get me a cheesy rom (I forget who) that would be quite nice, though I need to get this all running on the SGI first.

	I've attached said cheesy ROM as well as the main source code for
it. The ROM simply tiles the screen with a simple pattern (like all one
letter) and allows you to scroll around. There are also some simple
sprites in the upper left corner. Use the '-m' option in TuxNES to play
with the mirroring. I wrote this ROM to help me understand mirroring. The
patterns should change depending on which mirroring you choose.

-- 
	-Mike Melanson

Re: [Tuxnes-devel] more help w/ asm

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

At 10:28am on 2001 April 12, Rigel did write:

> heads up here.  I don't understand the implementation in table.x86.  So
> on all these listed instructions I set carry flag if there was a carrry
> (and clear it otherwise)?

Yes.  What trouble are you having with the implementation?
When carry is set, ebp is -1.  When carry is clear, ebp is 0.
For instructions which may carry, the sequence is:

addl -1, %ebp                 # set i386 carry if %ebp was set
<instruction which may carry> # set i386 carry according to 6502 instruction
sbbl %ebp, %ebp               # set %ebp to -1 on carry, else clear

Like I said, check out SEC, CLC and ROR - Accumulator, these are the
simplest examples.
 
> Yes I am trying to port the sucker to mips.  Wouldn't it be best though,
> to write the linkage (x86.S) in C?

There are a few things x86.S does:

1) acts as a call gate between asm and C -- e.g. most of the memory mappers.
   This needs to stay in assembly by definition.
2) Brings the global CLOCK, CPF, CTNI, etc. variables back in sync with the
   in-register versions -- e.g. in the INPUT:, OUTPUT:, NMI: routines, and in
   a couple mappers (mmc1, mmc3, aorom to be specific).
3) Distinguishes between IRQ and NMI in routine NMI:.  Then it sets up the
   6502 for interrupt (push return address, php, setup flags).
4) Handles self-modifying code.  Also must stay in assembly.

You can rewrite 2) and 3) in high-level code.  

** SPOILERS AHEAD ;) **

For example, the OUTPUT: routine looks like this in C:

void output_shim(int addr, int val)
{
    int cesi = ESI;
    cesi = cesi - CTNI + CLOCK;
    CTNI = ESI;
    if (cesi - CPF >= 0) { cesi -= CPF; }
    CLOCK = cesi;
    output(addr,val);
    ESI = CTNI;
}

NMI: has extra logic to handle 3)--specifically, the distinguishing between
IRQ and NMI.  Interpreter cores should implement the 6502 interrupt setup
themselves, so this can be ignored.

This is required for a C-based core.  However, there's no reason to rewrite
these in C if you're using an assembly language core, since the linkage
needs to stay anyway.

-- 
"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] more help w/ asm

[Rigel <ri...@an...>]

 
--

On Wed, 11 Apr 2001 19:40:40  
 Eric Jacobs wrote:
>"Rigel" <ri...@an...> tapped some keys and produced:
>
>
>> all right, I think I've got it (all) figured out now (haha). I 
>> understood mov all along (promise), just not lea.  I do like Intel 
>> syntax much better though, as it's a little more like other *real* 
>> (RISC) assembly languages.
>> 
>> This whole gaffe of mine just illustrates another reason I don't like 
>> x86 asm, which is that the instructions are misnamed.  I would have 
>> called lea, cea, for calculate effective addr. or maybe just wpos for 
>> weird piece of sh**.
>
>The way I think about it is that lea is like taking a C "&" operator
>of the corresponding mov
>
>> >  movl 4(%ebx),%edi     is like     edi = *(ebx+4)
>
>> >  leal 4(%ebx),%edi     is like     edi = &(*(ebx+4))
>                                or     edi = ebx+4
>
>(Or, perhaps a more exact analogy is that the target register is a
>reference variable, C++ style, if you understand that sort of thing.)
>
>BTW, lea exists in Motorola 68K, and is used in much the same way.
>
>
>> 
>> I'll definitely look up that Art of Assembly stuff.  It should be a good 
>> reference.
>> 
>> Okay, with the zero and sign flag (edi) you just give it the latest 
>> result from the ALU, right?  But what about the carry flag (ebp) ?  do I 
>> just set it to 1 if there was a carry involved in the most recent 
>> instruction?
>
>You set it the way that a 6502 would set it, as you should do with Z,
>N and V as well. You don't have to set up the register mapping the
>same way as it is for the x86; you should use whatever mapping is the
>most efficient for your architecture. The 6502 instructions that modify
>the carry flag are ADC, SBC, ASL, LSR, ROL, ROR, CMP, CPX, CPY, PLP,
>SEC, CLC. (Did I miss any?)

You're right, I don't *have* to keep similar reg mapping, but it will be much easier to code, as I will have to rewrite less of dynrec.c (which, as mentioned before, is quite complex).

heads up here.  I don't understand the implementation in table.x86.  So on all these listed instructions I set carry flag if there was a carrry (and clear it otherwise)?

Yes I am trying to port the sucker to mips.  Wouldn't it be best though, to write the linkage (x86.S) in C?  Has anyone noticed that most of the jumps are given as offsets, not labels?  Also that it's almost completely undocumented?   I'm not relishing the thought of translating that to mips.  I'm beginning to see a conspiracy.  Who does this Quor guy work for?  I may have to mail him, eh?

Whoever it was who said they could get me a cheesy rom (I forget who) that would be quite nice, though I need to get this all running on the SGI first.


Who needs Cupid?  Matchmaker.com is the place to meet somebody.
FREE Two-week Trial Membership at http://www.matchmaker.com/home?rs=200015

Re: [Tuxnes-devel] more help w/ asm

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

At 08:10am on 2001 April 12, Mike Melanson did write:
> On Wed, 11 Apr 2001, Jim Ursetto wrote:

> 	Right. These are all well-known issues with the dyn-rec
> approach.
Well, don't I feel silly now.  I thought the dyn-rec
engine was poorly understood except by the original author.
Glad to hear that.

> > and it's very fast, nearly 10 times faster than the Nofrendo core,
> > using the none renderer.
> 
> 10 times faster? Really? Finally, some real speed comparisons.
> However, how much time does the program spend simulating the 6502 in
> comparison to, say, rendering the graphics 60 times per second?

I think it'd be difficult to get a pure measure of 6502 emulation
speed, unless someone has a long sequence of varied instructions that
don't depend on input or output.  Barring this, I simply used the none
renderer, decoupling it from 60fps vertical refresh by commenting out the 
sync code.  Whenever UpdateDisplayNone() is called, it increments a
global frame count.  Input and output routines are still called
normally, because otherwise the cart wouldn't progress.   The I/O
routines call drawimage, but this is a no-op.  So the approximate
overhead is:

- input and output routines
  - CLOCK, CTNI, VBL, etc. variables updated
  - fiddling based on register
  - drawimage no-op
- interrupt routine
  - CLOCK etc. variables updated
  - UpdateDisplayNone no-op

No rendering is done at all.  The remaining overhead, I suspect is
concentrated in the I/O routines (the "fiddling" part).  Speed-wise,
on a Celeron 366 I get:

dyn-rec engine: 4250 fps
nes6502 core:   600 fps
M6502 core:     440 fps

So let's say 7 times faster.  This was timed several times with Super
Mario Brothers, using the eyeball-and-watch method, over a 1 minute
period, dividing total frames by 60.  Admittedly not the most accurate
method, but gives you a general idea.  At one time I had implemented
an accurate fps counter, but not in this copy of the code.

When rendering is turned on, and synced to refresh, there is no
appreciable difference in rendering speed on my system.  I.e., it runs
at a full 59 or 60 fps at 400x300 (unscaled), when run with full-screen 
DGA or GGI.

However, I haven't done any speed comparisons with rendering on but
without vertical sync.  That might be interesting.

It's too bad I still have that slowdown problem with my Maestro2
soundcard.  It's not as fun without sound...

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

Re: [Tuxnes-devel] more help w/ asm

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

On Wed, 11 Apr 2001, Jim Ursetto wrote:

> Hmmm... if translating assembly language between architectures is 
> not porting, then I don't know what is ;)

	Okay, you've got me there...:)

> More power to Rigel and I hope he succeeds.  While he's
> in there, it'd be great if he could look at some
> issues I noticed with dynrec:
[issues]

	Right. These are all well-known issues with the dyn-rec
approach. Basically, it doesn't cover all the bases with respect to
reading from and writing to the memory space. Naturally, this isn't a big
issue for 90% of the games out there, only the coolest 10%, such as
Castlevania III which uses MMC5 which maps its registers in the lower half
of memory.

	Also, don't forget another big problem with the dyn-rec
approach: It absolutely cannot handle self-modifying code. That's why it
also contains a translator that handles the most common instructions
empirically discovered in existing self-modifying routines.

> extremely uncommon.  Maybe we should consider
> contributing any interesting tidbits about the dynrec
> code to HACKING, or comment the code in especially
> difficult places.

	Since I do understand the dyn-rec engine to a decent extent (as
opposed to, say, the sound engine), I plan to document that well in the
HACKING file.

> All in all, the dynrec is incredibly cool, and it must
> have taken a huge effort to get it working and find all
> those special translation cases...  and it's very fast,
> nearly 10 times faster than the Nofrendo core, using
> the none renderer.

	10 times faster? Really? Finally, some real speed
comparisons. However, how much time does the program spend simulating the
6502 in comparison to, say, rendering the graphics 60 times per second?

> I implemented it this way in my copy of the tree,
> except dynrec/interpreted mode was a compile-time
> option.  It should be possible to do it on the fly,
> though.

	This is good. I'm thinking that we'll have to add another field to
the mapper table in order to indicate whether that mapper has to use the
portable core in order to work because it accesses lower memory. Whatever
the program chooses to use could be overridden by a run-time switch.

-- 
	-Mike Melanson

Re: [Tuxnes-devel] more help w/ asm

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

At 07:50pm on 2001 April 11, Mike Melanson did write:
> On Wed, 11 Apr 2001, Jim Ursetto wrote:
 
> Actually, it's not really porting. The primary issue
> involved is writing a new opcode translation table as well as a new
> ASM linkage file (such as x86.S).

Hmmm... if translating assembly language between architectures is 
not porting, then I don't know what is ;)
 
> 	But people really, really like the dyn-rec approach
> 	because, as you noted, it's cool. It's difficult,
> 	sure, but if someone wants to go for it, great.

More power to Rigel and I hope he succeeds.  While he's
in there, it'd be great if he could look at some
issues I noticed with dynrec:

1) Arbitrary writes/reads to IO ports don't work, only
   special cases.  I'm sure the common cases are
   covered, but the occasional ROM may do something
   unexpected.  Probably difficult or impossible to get
   100% right without sacrificing speed.
2) In the same vein, some opcodes (ASL, ROL) don't use
   the mapper.
3) Some opcodes consider the range $2000-$5FFF as I/O
   space, others use a different range.  This may be an
   issue with the area around $3F00 as well.
   Unfortunately, I can't point to any examples of this
   offhand :(
4) Some x86 instruction use/comments inconsistent, such as
   addl/leal used interchangeably.  Probably just a
   function of being written over a long period, also a
   very minor point.

The main point is that these issues confused me when I
was trying to understand the dynrec code.  There could
be compatibility implications as well, probably
extremely uncommon.  Maybe we should consider
contributing any interesting tidbits about the dynrec
code to HACKING, or comment the code in especially
difficult places.

All in all, the dynrec is incredibly cool, and it must
have taken a huge effort to get it working and find all
those special translation cases...  and it's very fast,
nearly 10 times faster than the Nofrendo core, using
the none renderer.
 
> 	After the next release, I want to take TuxNES in a direction that
> utilizes the dyn-rec approach, if available, and can fall back on a
> portable core.

I implemented it this way in my copy of the tree,
except dynrec/interpreted mode was a compile-time
option.  It should be possible to do it on the fly,
though.


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

Re: [Tuxnes-devel] misc info/questions

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

On Wed, 11 Apr 2001, Rigel wrote:

> I have an account on a MIPS (SGI) machine!!  I've not checked the complement of devel tools yet, but I might even be able to get root access for it.  My mips port of table.x86 is about maybe a third of the way from a final beta version (now that I've mastered the dark secrets of lea).  I think I might need help rewriting compdata for portability, any offers?  Also, are there any test programs that I might be interested in?

	You do realize that you will very likely be on your own for this
whole SGI development process, right? As for the comptbl, I think that
Quor is the only person who understands that program. (Quor? Are you out
there? Can you explain it?) As for a test program, would it help to have a
simple test ROM? Somewhere, I should still have a very simple ROM that I
wrote that just scrolls some graphics. I'll try to dig that up.

	BTW, regarding an earlier email of yours, *nobody* likes the Intel
x86 instruction set...:) Just so you know you're not alone.

-- 
	-Mike Melanson

Re: [Tuxnes-devel] more help w/ asm

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

On Wed, 11 Apr 2001, Jim Ursetto wrote:

> I am curious---what exactly are you doing?  Are you
> trying to port the dynamic recompiler?  I don't mean to
> discourage you, but surely it would be easier to use
> a C or asm interpreter, because the dynamic recompiler,
> although really cool, is also really hard to
> understand.  For the SH-4 arch, I ripped out the

	I already tried to discourage him and he still expressed interest
in "porting" the dyn-rec engine to the MIPS ISA. Thus, I admire his
motivation...:) Actually, it's not really porting. The primary issue
involved is writing a new opcode translation table as well as a new
ASM linkage file (such as x86.S).

> recompiler and replaced it with a GPL'ed C core taken
> from nosefart, which was substantially easier, although
> with some speed cost.  This could be reimplemented in
> assembly for some speedup (though it'd still be interpreted).
> You could always port the recompiler later.

	But people really, really like the dyn-rec approach because, as
you noted, it's cool. It's difficult, sure, but if someone wants to go for
it, great.

	After the next release, I want to take TuxNES in a direction that
utilizes the dyn-rec approach, if available, and can fall back on a
portable core. Also, having a portable core will be the default option for
games that use certain mappers (such as MMC5) that currently can't be
emulated in TuxNES due to limitations in the dyn-rec approach.

-- 
	-Mike Melanson

Re: [Tuxnes-devel] more help w/ asm

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

At 05:17pm on 2001 April 11, Rigel did write:

> >Exactly.  With lea you can do a mul, add, AND a shl (by
> >2,4,or 8) 
 
> correction here.  I think you mean a mult by 2, 4, or
> 8 (which is really shl by 1, 2, 3).  I only mention
> this because I confuse the two all the time...

What the...?  That's what I get for re-editing my
paragraph too many times.  I meant, you can do a MOV,
add, and a MUL (by 2, 4, or 8).
 
> This whole gaffe of mine just illustrates another
> reason I don't like x86 asm, which is that the
> instructions are misnamed.
LEA confused me for a long time, probably up until I
looked it up in the Art of Assembly.

> Okay, with the zero and sign flag (edi) you just give
> it the latest result from the ALU, right?  But what
> about the carry flag (ebp) ?  do I just set it to 1
> if there was a carry involved in the most recent
> instruction?
No, ebp is -1 on carry set, and 0 on carry clear.
See SEC, CLC, and ROR - Immediate in table.x86 for examples.

I am curious---what exactly are you doing?  Are you
trying to port the dynamic recompiler?  I don't mean to
discourage you, but surely it would be easier to use
a C or asm interpreter, because the dynamic recompiler,
although really cool, is also really hard to
understand.  For the SH-4 arch, I ripped out the
recompiler and replaced it with a GPL'ed C core taken
from nosefart, which was substantially easier, although
with some speed cost.  This could be reimplemented in
assembly for some speedup (though it'd still be interpreted).
You could always port the recompiler later.

Jim

-- 
"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

Re: [Tuxnes-devel] more help w/ asm

[Eric J. <ea...@ri...>]

"Rigel" <ri...@an...> tapped some keys and produced:


> all right, I think I've got it (all) figured out now (haha). I 
> understood mov all along (promise), just not lea.  I do like Intel 
> syntax much better though, as it's a little more like other *real* 
> (RISC) assembly languages.
> 
> This whole gaffe of mine just illustrates another reason I don't like 
> x86 asm, which is that the instructions are misnamed.  I would have 
> called lea, cea, for calculate effective addr. or maybe just wpos for 
> weird piece of sh**.

The way I think about it is that lea is like taking a C "&" operator
of the corresponding mov

> >  movl 4(%ebx),%edi     is like     edi = *(ebx+4)

> >  leal 4(%ebx),%edi     is like     edi = &(*(ebx+4))
                                or     edi = ebx+4

(Or, perhaps a more exact analogy is that the target register is a
reference variable, C++ style, if you understand that sort of thing.)

BTW, lea exists in Motorola 68K, and is used in much the same way.


> 
> I'll definitely look up that Art of Assembly stuff.  It should be a good 
> reference.
> 
> Okay, with the zero and sign flag (edi) you just give it the latest 
> result from the ALU, right?  But what about the carry flag (ebp) ?  do I 
> just set it to 1 if there was a carry involved in the most recent 
> instruction?

You set it the way that a 6502 would set it, as you should do with Z,
N and V as well. You don't have to set up the register mapping the
same way as it is for the x86; you should use whatever mapping is the
most efficient for your architecture. The 6502 instructions that modify
the carry flag are ADC, SBC, ASL, LSR, ROL, ROR, CMP, CPX, CPY, PLP,
SEC, CLC. (Did I miss any?)

Eric

-- 

Re: [Tuxnes-devel] misc info/questions

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

On Wed, 11 Apr 2001, Rigel wrote:

> I wanna use a NES controller for tuxnes.  I've heard this is possible,
> what do all ya (pronounce "all ya" as one word, as on oddworld2) have to
> say about it.  Specifically, how do I build a little adapter from NES
> proprietary plug to standard joystick?

I use a snes pad.  The directions on how to hack these things up for an
x86 box can be found with the newer linux kernels in
linux/Documentation/joystick-parport.txt, joystick.txt, and
joystick-api.txt

its a really simple process of hacking the things up, it took me roughly a
half hour to solder a new plug in place of a snes plug, and I was being
picky/anal about it.  I went with the recommendations of doing a direct 5v
connection instead of doing multiple pins to get power from the parallel
port.

If you want to make an adapted and keep your prized nes controller plug in
one piece, you can find extension cables on the web that will have the
correct female port for you to hack.

Im planning on building myself a switch box to allow snes, nes and db9
plug controllers to plug in, and be js0-3.  Its not so handy for tuxnes as
it is for mame, but your tuxnes playing may benefit from such a beast as
well.

GOOD LUCK!

---
--- krt
---

[Tuxnes-devel] misc info/questions

[Rigel <ri...@an...>]

I wanna use a NES controller for tuxnes.  I've heard this is possible, what do all ya (pronounce "all ya" as one word, as on oddworld2) have to say about it.  Specifically, how do I build a little adapter from NES proprietary plug to standard joystick?

I have an account on a MIPS (SGI) machine!!  I've not checked the complement of devel tools yet, but I might even be able to get root access for it.  My mips port of table.x86 is about maybe a third of the way from a final beta version (now that I've mastered the dark secrets of lea).  I think I might need help rewriting compdata for portability, any offers?  Also, are there any test programs that I might be interested in?

	Rigel Freden


Who needs Cupid?  Matchmaker.com is the place to meet somebody.
FREE Two-week Trial Membership at http://www.matchmaker.com/home?rs=200015

Re: [Tuxnes-devel] more help w/ asm

[Rigel <ri...@an...>]

 
--

On Wed, 11 Apr 2001 16:51:44  
 Jim Ursetto wrote:
>At 03:40pm on 2001 April 11, Rigel did write:
>> I was wrong, then, because I meant load into ebx the value at the mem location held in edi.
> 
>> So if I say, 
>> leal	4(%ebx),%edi
>> then I mean (in C),
>> edi = ebx + 4
>
>Exactly.  With lea you can do a mul, add, AND a shl (by
>2,4,or 8) 

correction here.  I think you mean a mult by 2, 4, or 8 (which is really shl by 1, 2, 3).  I only mention this because I confuse the two all the time...

>in only one instruction, but it can also be
>used to just do a single mov, add, or shl.  lea is a
>special instruction that performs all address
>computations, then moves this address result into a
>register.  
>
>For example, 
>  leal 4(%ebp,%ebx,2),%edi
>does (in C)
>  edi = ebp + ebx*2 + 4;
>
>What you want is movl (%edi), %ebx.   This is like saying ebx = *edi.
>This is also equivalent to movl 0(%edi), %ebx -- the 0 is superfluous.
>
>In intel syntax, 
>  lea eax, [ebx]  ==  mov eax, ebx.
>
>You may just be confused by the AT&T syntax, but here are some resources:
>

all right, I think I've got it (all) figured out now (haha).
I understood mov all along (promise), just not lea.  I do like Intel syntax much better though, as it's a little more like other *real* (RISC) assembly languages.

This whole gaffe of mine just illustrates another reason I don't like x86 asm, which is that the instructions are misnamed.  I would have called lea, cea, for calculate effective addr. or maybe just wpos for weird piece of sh**.

I'll definitely look up that Art of Assembly stuff.  It should be a good reference.

Okay, with the zero and sign flag (edi) you just give it the latest result from the ALU, right?  But what about the carry flag (ebp) ?  do I just set it to 1 if there was a carry involved in the most recent instruction?

Thanks much,
	Rigel


Who needs Cupid?  Matchmaker.com is the place to meet somebody.
FREE Two-week Trial Membership at http://www.matchmaker.com/home?rs=200015

[Tuxnes-devel] Snowday updates

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

Hi team,
	Today turned into a snowday for me. Even though the sun is shining
bright now and much of the snow is melting. Happens all the time where I
live. Anyway, since work and school were already cancelled, I'm spending
the day on TuxNES.

	I just added a new uniform header to all of the TuxNES source
files like I've been meaning to do. It looks 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:$
 *
 * Description:
 */

Some source code files used to have a list of authors who have hacked on
them, others didn't. The lists were rarely kept up to date. It's better to
have all the credits in a few central files like AUTHORS and THANKS.

	I also eliminated a dead data structure in sound.h and io.c. Right
now, I'm trying to figure out what to do with the ulaw.c file. It just
contains a giant array of numbers which isn't referenced in the program
anymore.

	I'm off to work on the HACKING file some more. The release creeps
close.
-- 
	-Mike Melanson

Re: [Tuxnes-devel] more help w/ asm

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

At 03:40pm on 2001 April 11, Rigel did write:
> I was wrong, then, because I meant load into ebx the value at the mem location held in edi.
 
> So if I say, 
> leal	4(%ebx),%edi
> then I mean (in C),
> edi = ebx + 4

Exactly.  With lea you can do a mul, add, AND a shl (by
2,4,or 8) in only one instruction, but it can also be
used to just do a single mov, add, or shl.  lea is a
special instruction that performs all address
computations, then moves this address result into a
register.  

For example, 
  leal 4(%ebp,%ebx,2),%edi
does (in C)
  edi = ebp + ebx*2 + 4;

What you want is movl (%edi), %ebx.   This is like saying ebx = *edi.
This is also equivalent to movl 0(%edi), %ebx -- the 0 is superfluous.

In intel syntax, 
  lea eax, [ebx]  ==  mov eax, ebx.

You may just be confused by the AT&T syntax, but here are some resources:

LEA documentation in intel syntax at:
http://webster.cs.ucr.edu/Page_asm/ArtofAssembly/CH06/CH06-1.html#HEADING1-136

Scaled indexed addressing modes at:
http://webster.cs.ucr.edu/Page_asm/ArtofAssembly/CH04/CH04-3.html#HEADING3-49

Register indirect and indexed addressing modes at:
http://webster.cs.ucr.edu/Page_asm/ArtofAssembly/CH04/CH04-2.html#HEADING2-35

-- 
'I came to the 3-day "breatharian" seminar in Hawaii, but
without the $300 fee to attend. Wiley asked me: "If you
can't find $300, then how do you expect to find God?"' -- breatharian.com
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

Re: [Tuxnes-devel] more help w/ asm

[Rigel <ri...@an...>]

 
--

On Wed, 11 Apr 2001 12:20:56  
 Jim Ursetto wrote:
>At 10:45am on 2001 April 11, Rigel did write:
>> Hi again,
>> All right, I have another one.  What's the difference between, say:
>> leal	0(%edi),%ebx
>> and,
>> movl	0(%edi),%ebx.
>> 
>> This is my guess.  leal loads value held in mem loc edi into ebx, and movl loads value of mem loc held in edi to ebx.  If you understand that, am I right?
>Yes, although for "leal" I think you mean "register edi".  The leal is
>equivalent to movl %edi,%ebx.  [At least, I'm 99.9% sure
>there isn't any difference.]
>
>Note also that leal 3(%esi),%esi and addl 3,%esi are
>used interchangably in table.x86, which can be a little
>confusing.
>
>-- 

I was wrong, then, because I meant load into ebx the value at the mem location held in edi.

So if I say, 
leal	4(%ebx),%edi
then I mean (in C),
edi = ebx + 4
?




Who needs Cupid?  Matchmaker.com is the place to meet somebody.
FREE Two-week Trial Membership at http://www.matchmaker.com/home?rs=200015

Re: [Tuxnes-devel] more help w/ asm

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

At 10:45am on 2001 April 11, Rigel did write:
> Hi again,
> All right, I have another one.  What's the difference between, say:
> leal	0(%edi),%ebx
> and,
> movl	0(%edi),%ebx.
> 
> This is my guess.  leal loads value held in mem loc edi into ebx, and movl loads value of mem loc held in edi to ebx.  If you understand that, am I right?
Yes, although for "leal" I think you mean "register edi".  The leal is
equivalent to movl %edi,%ebx.  [At least, I'm 99.9% sure
there isn't any difference.]

Note also that leal 3(%esi),%esi and addl 3,%esi are
used interchangably in table.x86, which can be a little
confusing.

-- 
'I came to the 3-day "breatharian" seminar in Hawaii, but
without the $300 fee to attend. Wiley asked me: "If you
can't find $300, then how do you expect to find God?"' -- breatharian.com
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

[Tuxnes-devel] more help w/ asm

[Rigel <ri...@an...>]

Hi again,
All right, I have another one.  What's the difference between, say:
leal	0(%edi),%ebx
and,
movl	0(%edi),%ebx.

This is my guess.  leal loads value held in mem loc edi into ebx, and movl loads value of mem loc held in edi to ebx.  If you understand that, am I right?
	Thanks again,	
		Rigel Freden


Who needs Cupid?  Matchmaker.com is the place to meet somebody.
FREE Two-week Trial Membership at http://www.matchmaker.com/home?rs=200015

Re: [Tuxnes-devel] OpenBSD

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

-On [20010411 15:31], Mike Melanson (mel...@pc...) wrote:
>On Wed, 11 Apr 2001, Jeroen Ruigrok/Asmodai wrote:
>
>> the as -v output shows as GNU assembler version 1.92.3. =\
>
>	Does this indicate that this OpenBSD installation doesn't have the
>latest development software, thus causing incorrect building?

Lets just state that the version is old. =\
I think that's the issue.

Might want to mention in our docs somewhere.

-- 
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
Without a soul there can be no understanding between the heart and the mind.