nestest.nes problem

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
User avatar
oRBIT2002
Posts: 634
Joined: Sun Mar 19, 2006 3:06 am
Location: Gothenburg/Sweden

nestest.nes problem

Post by oRBIT2002 » Tue Mar 21, 2006 12:24 pm

Just found the very nice nestest.nes ROM, great stuff indeed. But I keep getting error 59 (STA (ind,x)) test.
I am not sure how the test is performed as I haven't been able to locate the asm-source that nestest.txt refers to.
I've browsed a few 6502 docs and some other NES sources but haven't found anything that I didn't knew.
And yes, I'm using wrap around so the address is always 8-bit.

Hints anyone? :)

mattmatteh
Posts: 345
Joined: Fri Jul 29, 2005 3:40 pm
Location: near chicago
Contact:

Post by mattmatteh » Tue Mar 21, 2006 4:28 pm

is there only 1 nestest.nes ?

maybe this will help ?
http://nesdev.com/bbs/viewtopic.php?p=6 ... ight=#6651

queitust link is not there but blarggs is.

you have to set the PC differently, bot the poweron/reset vector

matt

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Tue Mar 21, 2006 4:33 pm

Test your knowledge on this example:

Code: Select all

memory at $000 = $11
memory at $001 = $22
...
memory at $0FF = $33
memory at $100 = $44
memory at $101 = $55

ldx #1
lda ($FF,x) ; what address does A get read from?
lda ($FE,x) ; what address does A get read from?
This will help determine whether the error is in your mind or your code. :)

User avatar
oRBIT2002
Posts: 634
Joined: Sun Mar 19, 2006 3:06 am
Location: Gothenburg/Sweden

Post by oRBIT2002 » Wed Mar 22, 2006 12:38 am

I think the first example would result in fetching data from $2211 and the second one $1133.
Do I need to do my homework? :)

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Wed Mar 22, 2006 8:25 am

Match. Next question: is your code doing what your brain just did on that example?

User avatar
oRBIT2002
Posts: 634
Joined: Sun Mar 19, 2006 3:06 am
Location: Gothenburg/Sweden

Post by oRBIT2002 » Thu Mar 23, 2006 2:10 am

Hm.. Probably not in the $FE-case when I think about it. Have to check that out, thanks. :)
Seems to be quite a rare situation however to find that kind of code in a ROM, unless it's a test-ROM. :)

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Thu Mar 23, 2006 9:25 am

A valuable technique if you're not looking to emulate every esoteric aspect of the NES, regardless of the cost: emulate generally-used behaviors and put debug checks for aspects you don't handle. In many cases these debug checks will never trigger, allowing you to keep the simplicity and know it hasn't affected accuracy in any way. It's part of a general principle of implementing systems with infinite and near-infinite possibilities: in theory, anything can happen, but in a finite span of time, only a finite number of things do happen.

WedNESday
Posts: 1236
Joined: Thu Sep 15, 2005 9:23 am
Location: Berlin, Germany
Contact:

Post by WedNESday » Thu Mar 23, 2006 2:19 pm

blargg wrote:A valuable technique if you're not looking to emulate every esoteric aspect of the NES, regardless of the cost: emulate generally-used behaviors and put debug checks for aspects you don't handle. In many cases these debug checks will never trigger, allowing you to keep the simplicity and know it hasn't affected accuracy in any way. It's part of a general principle of implementing systems with infinite and near-infinite possibilities: in theory, anything can happen, but in a finite span of time, only a finite number of things do happen.
...er, yeah...That's what I was going to say...
blargg wrote:...implementing systems with infinite and near-infinite possibilities...
Such as?

User avatar
oRBIT2002
Posts: 634
Joined: Sun Mar 19, 2006 3:06 am
Location: Gothenburg/Sweden

Post by oRBIT2002 » Fri Mar 24, 2006 3:14 am

I got my stuff working now. Thanks for all help. A special "hello and thanks" to everyone that write these test-ROMs, they were not present when I did some NES coding a few years ago. Anyway, they've helped alot, keep 'em coming. :)
Anyone feels like doing a test-ROM(FDS) for the FDS? ;)

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Tue Apr 04, 2006 12:59 pm

WedNESday wrote:
blargg wrote:It's part of a general principle of implementing systems with infinite and near-infinite possibilities: in theory, anything can happen, but in a finite span of time, only a finite number of things do happen.
Such as?
Here's an example posted today in another thread:
tokumaru wrote:
cdoty wrote:Why not just use existing cartridges? [for making homebrew releases]
Well, there are only so many cartridges produced by Nintendo, and they will eventually run out. We can't rely on them forever.
One wants to have an unlimited ability to make homebrew cartridges (theory), but in reality one can only make so many homebrew cartridges, there is only a market for so many, etc., so modifying Nintendo cartridges might be acceptable and serve as a practically-inifinite supply.

tepples
Posts: 22281
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Tue Apr 04, 2006 2:53 pm

Practically infinite? If you want a scanline IRQ and CHR RAM in a cart for use on North American NES consoles, you have exactly five choices for donor carts (three TGROM and two TQROM), and none of them are exactly dirt-cheap. Only with a circuit similar to that of Color Dreams or a successful reverse engineering of 10NES can we have the complete freedom of cart design that Michel "Bananmos" Iwaniec and others have been claiming is the core of NES development.

User avatar
kevtris
Posts: 504
Joined: Sat Oct 29, 2005 2:09 am
Location: Indianapolis
Contact:

Post by kevtris » Tue Apr 04, 2006 5:59 pm

tepples wrote:Practically infinite? If you want a scanline IRQ and CHR RAM in a cart for use on North American NES consoles, you have exactly five choices for donor carts (three TGROM and two TQROM), and none of them are exactly dirt-cheap. Only with a circuit similar to that of Color Dreams or a successful reverse engineering of 10NES can we have the complete freedom of cart design that Michel "Bananmos" Iwaniec and others have been claiming is the core of NES development.
This is why you design your own PCB... then you can use ANY i.e. MMC3 cart to make your games. Just buy the absolutely cheapest MMC3 containing carts you can get your mitts on. Remove the MMC3 and lockout chip, and solder them to your new board. As a bonus, you do not have to dick with rewiring the boards to accept EPROMs or flash ROMs- you can design your board to suit exactly what you need, including things like WRAM or CHR RAM. As a bonus, you can even do cute things like bank 32K of CHR RAM, which is not possible on any MMC3 cart.

Removing the chips isn't too difficult if you have a dedicated desoldering tool. The MMC3 is surface mount, so removing it is very simple- I use a heat shrink gun for this. I heat the chip up, and use a knife to just "pop" it off the board. The lockout chip is then desoldered using the desoldering
iron.

Since you won't be caring too much about the PCBs though, you can go to a much cheaper and faster destructive desoldering practice... the blowtorch. This will heat the pins up at once making removal a cinch. If the boards have WRAMs or whatever you can save these too and put them on your own carts. To remove the MMC3, you'd heat the board from the *bottom* then slide the chip off with the knife blade once the solder was molten. Shouldn't take more than 1-2 minutes a board to strip them.

You could save the ROMs too, but they are pretty worthless and I'd just leave them on and throw them away with the boards most likely once the lockout chip, RAM(s) and MMC3 were removed (and any 74HC32 or other useful chips).
/* this is a comment */

Post Reply