Designing a NES compatible console - nesdev designs, part 2.

You can talk about almost anything that you want to on this board.

Moderator: Moderators

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

Re: Designing a NES compatible console - nesdev designs, par

Post by tepples »

That depends on how fast the CHR RAM/ROM in the cartridge (and the mapper, if it has a PA12- or PA13-triggered interval timer) can react to three different PPUs all trying to read it. In addition, if you think 64K isn't enough for all the graphics you want to show on Super NES, imagine how small 8K will feel because there's no way to assign different CHR banks to different PPUs.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Designing a NES compatible console - nesdev designs, par

Post by psycopathicteen »

In NES games the multiplexor will be turned off. As for clock speed, the multiplexor will be clocked at 64Mhz and accesses memory every 8 cycles. The multiplexor would also divide it's clock speed by 3 to get the 21Mhz clock to power the 3 PPUs. For ROM size, we can hook up a couple of the EXT pins to the address bus.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by infiniteneslives »

MMC3, by comparison, was popular due to commercial interest. It's only natural that it wouldn't have the same post-market value outside reproduction and hacks. It just doesn't offer features that are interesting or convenient enough.
I said MMC3 scale, meaning finely banked CHR, scanline counter, etc. There are only a couple homebrews which utilize these types of features regardless if the mapper is interfaced in MMC3 fashion or not. Those features do have post-market value, even if you don't understand/see it. You talk about wanting parallax scrolling, but these "uninteresting features of the MMC3" are the features that permit parallax scrolling on the NES.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by FrankenGraphics »

One thing that would alter the performance of layered PPU:s considerably is the presence of a BG colour mask per layer. If there's no such thing, the bg colour would always be transparent, which could work, but is kind of a waste. With a transparency mask working like a" one-bit-per-cell" attribute table, we'd get much more mileage out of the two top BG layers. The bad news is that it's a new block tied to the layer merger block. The good news is it's optional for the dev to use it or just fill it with 0:s for the same effect as if it is not implemented, enabling different strategies and styles of graphics.

re: MMC, scanline counting:

Sorry, i must've missed that. Yes, that's how its done, or by cycle counting (like jupiter scope 2).
My thinking here is... If you have access to a straighforward interface counting scanlines for your project, you wouldn't normally count cycles (except for the challenge/sport). Now, if you had three background layers, you wouldn't count scanlines for this purpose (except for the same reason - or if you've managed to tie up all layers to something else and still want parallax). I mean, this is a bit outside NES territory, which is why i posted it in "general".

I should've probably added that my digression on mappers was based on personal judgement (what i personally choose to prioritize - the feature set of GTROM over banking granularity and counters).
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by infiniteneslives »

FYI, GTROM doesn't really have any features that are special/specific to GTROM. Practically all mappers can have 4screen mirroring tacked onto them (the few licensed games with 4screen mirroring added it to MMC3). 16KB PRG-ROM banking, multiple 8KB banks of CHR-RAM, and flash saves, are all basic features which can be integrated into any mapper.

EDIT: corrected by lidnariq below as to my knowledge hole. While GTROM is only design to bank nametables, it's still a relatively simple expansion that could be applied to most mappers.
Last edited by infiniteneslives on Sat Jul 08, 2017 11:52 am, edited 1 time in total.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Designing a NES compatible console - nesdev designs, par

Post by lidnariq »

The particularly unique thing to GTROM is 8 nametables, bankswitchable in groups of 4. Gives you both glitch-free all-way scrolling on both PAL and NTSC as well as spare space for a bunch of status screens/bars.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Designing a NES compatible console - nesdev designs, par

Post by Bregalad »

gauauu wrote: This aspect is the one part that would make sense to me as a developer. I could still make a regular NES game, but enable optional features when running on the "n+".
Why not implement those "n+" features on the cartridge and make it NES/FC compatible, then ?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Designing a NES compatible console - nesdev designs, par

Post by tokumaru »

Bregalad wrote:Why not implement those "n+" features on the cartridge and make it NES/FC compatible, then ?
I guess not all of the features can be implemented as part of a mapper, but even if they could, I imagine that a significantly expensive FPGA would be needed to replicate multiple PPUs, so the cost for a single cartridge would be too much.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Designing a NES compatible console - nesdev designs, par

Post by lidnariq »

Run-time compositing of multiple tiles into a single one shouldn't be that complex ... at least as long as we can ignore palettes. We do need 3 fetches per single PPU fetch to handle different X scrolls per layer, though.
User avatar
Sogona
Posts: 186
Joined: Thu Jul 23, 2015 7:54 pm
Location: USA
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by Sogona »

I'm not a hardware guy at all, so I don't know if any of this is with the realm of feasibility, but I think it'd be cool if some of the unused opcodes were replaced with useful features like
phx/phy/plx/ply
to make stack operations faster in time-critical code like NMI handler; but still retain backwards compatibility with the regular 6502 instruction set. I guess this might not work very well, since some games use undocumented opcodes. Just an idea.

Also something like a RNG built into the hardware, maybe using an algorithm similar to 10NES.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by tepples »

If something is essential to the game model, such as randomness, it needs to work on an unenhanced NES as well, which means it needs to be done in software. It's not that hard to just import the cc65 LCG to your project.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by FrankenGraphics »

You'd have those instructions on w65c02s and w65c816s aswell as some new addressing modes and other instructions.

Personally, i think it's okay to break compability with illegal opcodes:
-Commercial era games using them are few and rather unpopular.
-Some of those are relatively easy to patch, if you're playing a personal image rather than the physical copy.
-An emulator capable of emulating both NES and "n+" machines as separate entities can simply select in which mode to run. That means that even if the "n+" machine, virtual or real, can't interpret illegal opcodes correctly, an emulator potentially can if it also has vanilla NES emulation.
-Only a hypothetical physical unit or a strict "n+" emulator will have a slight compability gap this way.
-Old homebrew can be modified, if the author really wants to.
-New Homebrew using illegal opcodes can potentially switch blocks out between NES and "n+" mode.
-The advantages of illegal opcodes are leveled out by cheer performance and the wider instruction set/addressing modes, so you won't be likely to miss them when writing an "n+" feature for your project.


That said, yeah, even though you as a software dev could write something that'll only run on an "n+" emulation/machine, some have pointed out it sounds more attractive to just write NES compatible games (because of the install base/ease of explaining what it is), with added features that'll show only on an "n+" machine. I think this would especially be a true forecast for at least the first phases.

I can also envision some areas that might see more "n+ only" than you'd see otherwise, depending on popularity:
-Perhaps a small demo scene revival - concepts demonstrating neat tricks that can be made
-Small games but with "n+" graphics/sound/other features (cpu); like pong and "side view player vs player volleyball", for example.
-Hack patches to existing games (like remapping Castlevania controls, or even adding background elements)
-Maybe Revisits/"Remakes" on already released NES homebrew.

Beside "works on both, but differently" type of games, any relatively "short spanned" commitment of a type listed above could likely be further fueled by events, compos, co-releases and the like.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by FrankenGraphics »

Re: programming language, WDC offers a C compiler/optimizer for free in return for registrering as a user, alongside their assembler. I don't know C and haven't tested it, but i assume that WDC would be experts on how to optimize C for their own 65xx processors?

http://www.westerndesigncenter.com/wdc/tools.cfm
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by thefox »

FrankenGraphics wrote:Re: programming language, WDC offers a C compiler/optimizer for free in return for registrering as a user, alongside their assembler.
Cool. However note that it's not free for commercial use on non-WDC processors. (Also note that it's for 65c02/65816, not 6502).

Funny to see some SNES references in the linker (wdcln): "-MN use Nintendo memory map", "-MN80 use Nintendo fast memory", "-MN21 use Nintendo mode 21 map". It also has an output format "Nintendo Binary" (-HN).

EDIT: Tried it out, the "Nintendo Binary" format outputs .ISX, which seems to be Intelligent Systems' file format, also referenced in another thread about the Super NES Emulator SE hardware.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by FrankenGraphics »

Also note that it's for 65c02/65816, not 6502
Yeah, i was assuming a new nes-compatible console or expansion would facilitate one of those at this point. To summarize:

-As tokumaru pointed out, more processing power is required to do the housework of the new capabilites.
-A physical processor (or one that comes in a ready fpga package) is much simpler to implement than coming up with an all-new 65 compatible processor in fpga form. Then the two options would be 65c02/65c816, which tepples linked to.
-The choice between them would largely be the choice between 64kB and 16MB address range, 8 or 16bit stack, and pin compability with the 6502 standard vs more signals. You also need to 'boot' the 65c816 with a couple of instructions at reset to get out of 65c02 emulation mode, which is default.
Post Reply