It is currently Wed Dec 13, 2017 7:40 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 68 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Sat Jul 08, 2017 9:32 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19342
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 9:43 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2425
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.


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 9:56 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1940
Location: WhereverIparkIt, USA
Quote:
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


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 11:08 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1124
Location: Gothenburg, Sweden
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).

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 11:35 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1940
Location: WhereverIparkIt, USA
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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Last edited by infiniteneslives on Sat Jul 08, 2017 11:52 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 11:40 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6519
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 11:41 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
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 ?


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 1:04 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 1:46 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6519
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 7:32 pm 
Offline

Joined: Thu Jul 23, 2015 7:54 pm
Posts: 152
Location: USA
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.


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 7:37 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19342
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sun Jul 09, 2017 4:03 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1124
Location: Gothenburg, Sweden
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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun Jul 09, 2017 6:13 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1124
Location: Gothenburg, Sweden
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

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun Jul 09, 2017 6:45 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2982
Location: Tampere, Finland
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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Tue Jul 11, 2017 1:07 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1124
Location: Gothenburg, Sweden
Quote:
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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 68 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: toggle switch and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group