nestest.nes problem

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
nestest.nes problem
by on (#11052)
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? :)

by on (#11065)
is there only 1 nestest.nes ?

maybe this will help ?
http://nesdev.com/bbs/viewtopi ... ight=#6651

queitust link is not there but blarggs is.

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

matt

by on (#11066)
Test your knowledge on this example:

Code:
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. :)

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

by on (#11073)
Match. Next question: is your code doing what your brain just did on that example?

by on (#11090)
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. :)

by on (#11099)
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.

by on (#11112)
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?

by on (#11137)
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? ;)

by on (#11546)
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.

by on (#11551)
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.

by on (#11558)
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).