Questions about NES programming and architecture

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

strat
Posts: 370
Joined: Mon Apr 07, 2008 6:08 pm
Location: Missouri

Re: Questions about NES programming and architecture

Post by strat » Sun Sep 06, 2020 6:55 pm

Bregalad wrote:
Sat Sep 05, 2020 3:02 am
Secamline wrote:
Fri Sep 04, 2020 5:14 pm
Do first party games explicitly clear decimal mode?
Yes.

IMO there's no point in overthinking why most games uses CLD when starting up. They just do.
Interestingly enough, the (very incarucate) emulator REW actually simulates the decimal mode if enabled ! This is funny.
Maybe devs were told to do that in case the FC/NES got a hardware upgrade with decimal mode intact so it wouldn't break older games.

User avatar
Gilbert
Posts: 395
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Re: Questions about NES programming and architecture

Post by Gilbert » Sun Sep 06, 2020 9:15 pm

This was what I thought too. Also, they might have considered upgrading the CPU to be based on 65C02, so most licensed games didn't use any illegal/nonstandard/unofficial/whatever OP codes of the original 6502 (another possibility was just that these unofficial OP codes were... errr... poorly documented though).

After all, when Nintendo developed the Super Famicom, one obvious reason for choosing the 65816 as the CPU for the new system was to provide backward compatibility with Famicom games (this was also reported by magazines back then), though this idea seemed to be axed early on, probably due to the difficulties in supporting all the timings and quirks of the old system, and even when that was doable it might result in limiting the features of the new system.
(Nintendo systems were unlike Sega systems, which were just built with off-the-shelf parts (or natural evolutions of these parts, until the 32X and Saturn at least), so backward compatibility was more easily achieved.)

Oziphantom
Posts: 913
Joined: Tue Feb 07, 2017 2:03 am

Re: Questions about NES programming and architecture

Post by Oziphantom » Mon Sep 07, 2020 12:18 am

Nobody made a "6502 for NES programming" book, everybody will have learnt either on another system or those people that did just learn 6502 for NES will have read books from other machines first. There is no way to debug on a NES, they would have used either actual 6502 systems such as the Apple ][ and Commodore 128. Used 6502 cross dev solutions such as PDS, or the HP 64000 which simulate/run real 6502s which will have needed the decimal mode disabled.

User avatar
Secamline
Posts: 39
Joined: Sat Aug 15, 2020 4:25 pm

Re: Questions about NES programming and architecture

Post by Secamline » Mon Sep 07, 2020 3:00 am

It's weird that Nintendo never made any official devkit or even a documentation for the Famicom/NES. I've read that third party developpers back then had to retro engineer the system in order to make their own developpement tools.

creaothceann
Posts: 256
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Questions about NES programming and architecture

Post by creaothceann » Mon Sep 07, 2020 3:59 am

Secamline wrote:
Mon Sep 07, 2020 3:00 am
It's weird that Nintendo never made any official devkit or even a documentation for the Famicom/NES
They didn't want another videogame market crash...
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

Pokun
Posts: 1512
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Questions about NES programming and architecture

Post by Pokun » Mon Sep 07, 2020 6:00 am

Makes sense, I guess if the crash could happen in North America the same thing could happen in Japan as well. Besides Nintendo knew they had people that could make quality games, what with the success of arcade games such as Donkey Kong, the Game & Watch line and even their earlier Pong clones.
Nowadays everyone knows that a game console can't survive without third-party support however, no matter how good first-party games are, so in the hindsight it sounds like a bad decision. The Famicom, unlike the NES, didn't have a lockout chip though, so it was much more vulnerable to unlicensed games.


Both Super FC/NES and PC-Engine has a working decimal mode, I don't know any other 65x-based system besides the FC/NES that doesn't have it. So yeah, if the SFC would have the planned backwards-compatibility, games that skipped the CLD would be problematic.


The BRK instruction is very useful I think (although the exact assembly behaviour seems to be loosely defined). I often use it as a quick break point without requiring a debugger. Rainwarrior uses it to access a kind of blue screen in his game Lizard. If the ROM is padded with $00 (which is the opcode for BRK) you can easily tell that something is wrong (the PC went outside of the code area) when a BRK-interrupt happens.
Only thing is that you have to get the B flag from the stack after an IRQ happened to check that it was a BRK-type of IRQ. Supposedly the B flag doesn't even physically exist in P (no need to since there is no way to read P or check the B flag directly), but it exists in the copy of P that can be found on the stack after an IRQ happened.


Regarding debugging, I read that there were something called In-Circuit Emulator (ICE) that could debug a microprocessor. DICE-6502 and NICE-Z80 are such things and some developers used things like that for debugging. Nintendo also sold a line of development systems called PROS80 using obscure 3" floppy disks. It was apparently not that popular.
There are some Famicom development documentation, and some of that has been leaked, but it's mostly of the MMC mappers and license administration stuff. I also remember reading interviews with western developers (I think it was those that made Solstice) that they got some kind of documentation from Nintendo, but it was mostly in Japanese so they had a hard time figuring it out.

Edit: changed $FF to $00. Thanks Tokumaru and Secamline for the correction!
Last edited by Pokun on Mon Sep 07, 2020 6:07 am, edited 3 times in total.

User avatar
tokumaru
Posts: 11859
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Questions about NES programming and architecture

Post by tokumaru » Mon Sep 07, 2020 6:03 am

The opcode for BRK is $00, not $FF.

User avatar
Secamline
Posts: 39
Joined: Sat Aug 15, 2020 4:25 pm

Re: Questions about NES programming and architecture

Post by Secamline » Mon Sep 07, 2020 6:06 am

So they couldn't legally prevent 3rd party developpers from making NES games?
I know they tried to keep control of the console's games library with their seal of quality, but as we all know, loads of terrible games bear the Nintendo seal of quality. I guess any game could get Nintendo's approval as long as the developpers paid for the licence. So in the end the NES was on par with the 2600 (except for the porn games).
If the ROM is padded with $FF (which is the opcode for BRK) you can easily tell that something is wrong (the PC went outside of the code area) when a BRK-interrupt happens.
Isn't $00 the opcode for BRK?
Edit: Oops, missed tokumaru's reply

Pokun
Posts: 1512
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Questions about NES programming and architecture

Post by Pokun » Mon Sep 07, 2020 6:29 am

Thanks I fixed the mistake.

In Japan I think they could legally prevent unlicensed games for the Famicom, but not anywhere else. The NES got the lockout chips though which somewhat prevented both unlicensed games and cross-region "grey" importing. There were Japanese-made unlicensed games as well though, so I'm not entirely sure. Hacker International (later Games Express), Super Pig etc made both unlicensed cartridge and disk games, and often adult ones.

The Seal of Quality was a NES-only thing (we had it in Scandinavia as well), but I think it's clear that Nintendo had much stricter quality control than many other companies (like earlier Sega). The quality control probably doesn't enforces that games has to be fun, only that they have some degree of a quality product. You couldn't release half-complete games, super repetitive games or very simple homebrew-like games and such that you often see on other systems (especially on computers which usually has no licensing system at all, and can be programmed by anyone) simply by paying the license fee.

Atari had serious problems with their employees taking drugs and not taking their work seriously before the crash.

User avatar
Bregalad
Posts: 7951
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Questions about NES programming and architecture

Post by Bregalad » Mon Sep 07, 2020 7:12 am

If the ROM is padded with $00 (which is the opcode for BRK) you can easily tell that something is wrong (the PC went outside of the code area) when a BRK-interrupt happens.
This is some very loose reasoning and wishful thinking.

If your stack gets corrupted/desynchronized somehow and your program return to a garbage adress, there's very little chance it will "return" to an unused section of ROM.
There is a lot of chances it will "return" outside of ROM area ($0000-$7FFF) where the reads will not return $00, and as thus will not execute a BRK instruction but instead some other garbage that will likely crash the program.

There is a lot of chances it will "reutrn" to an used area of the ROM, and as such various bugs can happen, as some other part of the code will execute.
Useless, lumbering half-wits don't scare us.

Fiskbit
Posts: 162
Joined: Sat Nov 18, 2017 9:15 pm

Re: Questions about NES programming and architecture

Post by Fiskbit » Mon Sep 07, 2020 7:27 am

In my experience, BRK is very frequently hit when a game goes off the rails. I've had very good luck catching and fixing bugs using a crash handler on the IRQ vector. You can hit 00's in unused ROM space, data, instruction operands, PRG-RAM, or system RAM. I also use NMI-based crash detection that calls the crash handler if the gameplay frame hasn't retired after a few seconds, and have a manual trigger where you hold a button combination while resetting the console for any hardlocks the automatic detection doesn't catch.

None of this is perfect, of course, but it works far better than you give it credit for.

Oziphantom
Posts: 913
Joined: Tue Feb 07, 2017 2:03 am

Re: Questions about NES programming and architecture

Post by Oziphantom » Mon Sep 07, 2020 10:20 am

Pokun wrote:
Mon Sep 07, 2020 6:00 am
Supposedly the B flag doesn't even physically exist in P (no need to since there is no way to read P or check the B flag directly), but it exists in the copy of P that can be found on the stack after an IRQ happened.
php
pla
and

User avatar
Quietust
Posts: 1603
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Questions about NES programming and architecture

Post by Quietust » Mon Sep 07, 2020 10:48 am

Bregalad wrote:
Sat Sep 05, 2020 3:02 am
Interestingly enough, the (very incarucate) emulator REW actually simulates the decimal mode if enabled ! This is funny.
At one point, Marat Fayzullin posted on the old NESdev mailing list about an unlicensed Famicom game that relied on decimal mode, using it as justification for emulating it in iNES. Interestingly, when I examined my own copy of the same game, I found that it had been patched to instead perform all of its decimal mode arithmetic in software (so that it would work on authentic hardware), so it would seem that some Famiclones actually supported decimal mode, likely by accident.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

lidnariq
Posts: 9676
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Questions about NES programming and architecture

Post by lidnariq » Mon Sep 07, 2020 10:50 am

NewRisingSun wrote more about that here: viewtopic.php?p=243832#p243832

User avatar
Quietust
Posts: 1603
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Questions about NES programming and architecture

Post by Quietust » Mon Sep 07, 2020 11:02 am

lidnariq wrote:
Mon Sep 07, 2020 10:50 am
NewRisingSun wrote more about that here: viewtopic.php?p=243832#p243832
Indeed, the game in question was Othello by Bit Corp, though it seems the above-mentioned conversation might've happened somewhere else - the old mailing list archive only goes from January 1998 to March 1999, but I can't find that conversation anywhere in it.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

Post Reply