It is currently Thu Sep 21, 2017 12:31 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: Fri Jul 07, 2017 11:08 am 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 201
Location: Central Illinois, USA
tepples wrote:
You're trying to launch a new famiclone console, and what you've described so far is an NES with two PPUs, a Namco WSG-inspired wavetable synth, and Super NES controller ports. Thus it is to the NES as the SuperGrafx is to the PC Engine.

Anyone considering an N+ game would have to answer a question: "Why not just make a Super NES game? It'll work on all the Super NES and FC Twin consoles out there, which is far greater than the N+ install base." The traditional answer to that is that people expect a Super NES game to look no less graphically complex than the Super NES launch titles, such as Super Mario World, whereas an NES game's art style can be anywhere between Donkey Kong and Bucky O'Hare.

So N+ games would have to fit into a narrow gap: projects that are too complex for the NES, less complex than SMW, and appealing to those few people who have purchased an N+ console. Like Metanet's N+, I assume.


This was really my thought when reading this. The exercise of creating the system is a lot of fun, so for that reason, I think this cool. But as a developer, I wouldn't likely be interested in making a game for this system, for all the reasons Tepples mentioned. (plus the additional reason: with a regular NES or SNES game, I can show my less-nerdy friends, and they understand it, and think it's mildly interesting. Nobody beyond a small group of hardcore nerds would understand what I made if I made a game for this console).

FrankenGraphics wrote:
Or, you could just make a NES ROM that plays normalt on the NES but adds footsteps to the walking cycle without cutting music on the "n+" (just an example)


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+".

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Fri Jul 07, 2017 11:13 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1879
Location: WhereverIparkIt, USA
It seems to me that many of the things you're looking to do could be implemented with software tools or on a cartridge (EDIT or some sort of "nesdev deck enhancer") playing in the original NES.

-Chief goals of compatibility are complete/moot if stick with NES.

-Audio can't get any more compatible than using the original NES, and expansion sound is unlocked with a resistor.

-PPU sure, can't add an additional PPU via the cart connector. But I fail to see how an additional PPU, or more complicated graphics system benefits homebrew significantly when current works are under utilizing the standard PPU on a whole. There's lots of room for graphical ability improvements that can be unlocked from the cartridge, MMC5 features, large amounts of dual port VRAM, etc. The fact remains you can count the number of homebrews that use MMC3 scale mapper on one hand; while MMC3 scale was one of the most featured in the NES's lifetime.

-CPU, biggest thing I can see benefiting homebrew on the CPU front would be better supporting high level languages like C. higher level languanges have much more ability to speed up development time compared to writing assembly for a faster 6502 with decimal mode.

Simply writing a better C compiler than the ones currently available could go a long way.. If you're looking for some hardware assistance to better support C, something like KimKlone's radical 6502 comes to mind with 24bit address space and 16bit registers could all be done from the cartridge/compiler. Or cheat and put whatever CPU architecture you're after on the cartridge and make the NES 6502 a slave. Maybe it's "cheating", but it's significantly less work than designing and marketing a new console.

-Memory, well within cart abilities/expectations.

-Peripheral support: Original NES already supports 2/4 controllers. The entire CPU bus is available to the cart could even have the cart interface with bluetooth/wireless controllers and the NES simply reads button data from a mapper register.

-Software standards: You're on the NES already, task becomes focused on the cartridge hardware/mapper alone.

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


Top
 Profile  
 
PostPosted: Fri Jul 07, 2017 11:16 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 979
Location: Pennsylvania, USA
gauauu wrote:
tepples wrote:
You're trying to launch a new famiclone console, and what you've described so far is an NES with two PPUs, a Namco WSG-inspired wavetable synth, and Super NES controller ports. Thus it is to the NES as the SuperGrafx is to the PC Engine.

Anyone considering an N+ game would have to answer a question: "Why not just make a Super NES game? It'll work on all the Super NES and FC Twin consoles out there, which is far greater than the N+ install base." The traditional answer to that is that people expect a Super NES game to look no less graphically complex than the Super NES launch titles, such as Super Mario World, whereas an NES game's art style can be anywhere between Donkey Kong and Bucky O'Hare.

So N+ games would have to fit into a narrow gap: projects that are too complex for the NES, less complex than SMW, and appealing to those few people who have purchased an N+ console. Like Metanet's N+, I assume.


This was really my thought when reading this. The exercise of creating the system is a lot of fun, so for that reason, I think this cool. But as a developer, I wouldn't likely be interested in making a game for this system, for all the reasons Tepples mentioned. (plus the additional reason: with a regular NES or SNES game, I can show my less-nerdy friends, and they understand it, and think it's mildly interesting. Nobody beyond a small group of hardcore nerds would understand what I made if I made a game for this console).


It seems it is possible to build a large community around a "new retro" game console, at least in terms of a "fantasy console" such as the Pico-8. I am wondering if someone could create a competing piece of software, where "Phase 1" is just creating an emulator/fantasy console of the hardware and building a community with game jams, a forum, etc. Make it really easy to program for and use a modern language, but keep it constrained and retro, but not as constrained as Pico-8. Once the community is built, move on to Phase-2 and create an open-source design for the hardware. Then find interested individuals to build their own or market a pre-built version of it.

In a sense this would marry the idea behind the Pico-8 and the Uzebox. It would be modern, easy to program, constrained but not too constrained, use a modern language, and it wouldn't *just* be some software slapped on a cheap linux board. (So you'd get fast boot times, and maybe physical cartridge production on SD cards or something of that nature)

That's kinda what I was hoping the Retro VGS was gonna be... :(

Downside to the above idea is you'd lose the NES compatibility the OP was going for, which to me is in itself a downside. I mean, I code around NES constraints because I love the NES and I want to make games for it, but I don't WANT to work within quite so many constraints. I.e. I love the graphical and audio constraints, but the coding constraints are a real pain a lot of times. I know not everyone feels this way, but if you want a community around a new console, you'll have to make it possible for peasants like me to code for it, LOL (and not take 4 years to make a game, which is about par for me)


Top
 Profile  
 
PostPosted: Fri Jul 07, 2017 11:31 am 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
[PPE: INL kinda covered this, but missed a few points.]

Nothing really stopping you from 32X-ing off the NES expansion port and having the new device provide your composite out. You can even provide a new NES-cartslot

You'd probably either
1. gen your own NTSC signal that's in-time with that and mux it with your own, which isn't as easy as if they'd mapped the PPU-slave lines to the expansion port,
2. have an FDS-style cable from cart to expansion device [or vice-versa] carrying the PPUA/D lines and completely take over picture generation

tokumaru wrote:
DMA, increased CPU speed, extra VRAM... This sounds kinda like how the GBC improved the original GB. Can we draw some inspiration from how Nintendo upgraded that system while maintaining compatibility with older games?
Well, DMA repurposing is doable cartside on vanilla. You can't DMA to palette, but NTSC has 4.5 DMAs of cycles in vblank anyway, and the 40ish 8-cycle read/writes that half gives you means you can pretty much set up the PPU as-desired in that half a DMA. (Mind, you kinda want 5.5 DMA, as one should be for sprites, and 4 covers a whole NT[+vanilla AT]; this would require an extra 4-5 scanlines off) but if you're doing fancy cartside addressing shenanigans, you could just as well have dual-port-style (like ExGrafx), which would be more efficient, as your program doesn't need to do a write twice.

If you do have a cable connecting your expansion and cart, you can just have another processor (faster-clocked) on the new thing, and use the NES's 2A03 as a dummy with a tiny program that passes through APU register writes and strobes controllers (PPU reg-write passthrough optional; you could just generate your own vanilla signal entirely…). You can also just give it your own replacement cartslot, going full wideboy/32X/FDS, and this then can help satisfy the retrocompatibility if it's a 72-pin fat. (If paralleling the GBC upgrade is wanted, this featureset has as minor extra fruit altering palettes for vanilla games (though this again may take you out of target territory); and you could have the NES-slave-mode + faster processor switch enabled by a register write.)

(sarcasm) Another optional feature is allowing access to that juicy 4K of onboard CPU RAM and VRAM, something this Peripherally-Enhanced NES surely can't have already had lots added to.(/sarcasm)


Top
 Profile  
 
PostPosted: Fri Jul 07, 2017 12:58 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2265
I made a 12-bit RGB version of the NES palette, that we can use if we are going to use an RGB palette, and simply use a LUT ROM for NES compatibility mode.

Attachment:
nes color palette.png
nes color palette.png [ 359 Bytes | Viewed 510 times ]


Top
 Profile  
 
PostPosted: Fri Jul 07, 2017 1:21 pm 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 201
Location: Central Illinois, USA
infiniteneslives wrote:
It seems to me that many of the things you're looking to do could be implemented with software tools or on a cartridge (EDIT or some sort of "nesdev deck enhancer") playing in the original NES.
....
-Software standards: You're on the NES already, task becomes focused on the cartridge hardware/mapper alone.


It did surprise me, when starting nes dev, how some of the more interesting mappers and features were rarely used. I guess it's an issue of cost -- if I want people to be able to buy my game for a reasonable price, I need a cheaper board. A project like GT-ROM, keeping the cost low, but with additional cool features that some of the more advanced mappers support, would be incredible. (of course, I realize the absurdity in asking for "cheap but powerful please!")

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Fri Jul 07, 2017 1:42 pm 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 210
Location: Fort Wayne, Indiana
Rotated/scaled sprites would be easy to do even as a cartridge-side extension, with a coprocessor or FPGA rendering graphics during vblank. I guess you'd want a fast multiplier too for generating the parameters to give it.


Top
 Profile  
 
PostPosted: Fri Jul 07, 2017 1:57 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1879
Location: WhereverIparkIt, USA
gauauu wrote:
(of course, I realize the absurdity in asking for "cheap but powerful please!")

It's a pie in the sky idea, but significantly more achievable/adoptable than a new console is some sort of 'nesdev deck enhancer' similar to Camerica's. Homebrew games could target utilize the more expensive hardware which would be a one time buy for the consumer.

It would also allow homebrew games to be published for a lowered cost, once the deck enhancer was owned. The published cartridge could be as simple as an SD card. Or something less copy-able like a high density, low cost SPI flash chip on a small cartridge along the lines of a GBA cart that plugged into the deck enhancer. Giving the device some sort of online connectivity would even permit digital purchase of homebrew games.

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


Top
 Profile  
 
PostPosted: Fri Jul 07, 2017 2:47 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
NovaSquirrel wrote:
Rotated/scaled sprites would be easy to do even as a cartridge-side extension, with a coprocessor or FPGA rendering graphics during vblank. I guess you'd want a fast multiplier too for generating the parameters to give it.

How do you get around sprite limits?
If you're just rendering to BG, then that's cutting your colors in half.

And if we're really sky-pieing…why have the CPU do those calculations at all rather than just feeding in the angles and scales to the new coworker?


Top
 Profile  
 
PostPosted: Fri Jul 07, 2017 4:13 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2265
NovaSquirrel wrote:
Rotated/scaled sprites would be easy to do even as a cartridge-side extension, with a coprocessor or FPGA rendering graphics during vblank. I guess you'd want a fast multiplier too for generating the parameters to give it.


If the affine sprites are stored in packed pixel format and the FPGA renders them at 5.37 Mhz, it would be able to render 160 8x8 sprites per frame, which is more than the NES could handle anyway.


Top
 Profile  
 
PostPosted: Fri Jul 07, 2017 5:23 pm 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 210
Location: Fort Wayne, Indiana
Myask wrote:
How do you get around sprite limits?
If you're just rendering to BG, then that's cutting your colors in half.

And if we're really sky-pieing…why have the CPU do those calculations at all rather than just feeding in the angles and scales to the new coworker?
Image Have you played Yoshi's Island? It's pretty much packed with rotation effects on 16x16 and 32x32 objects and they wouldn't eat into the sprite limits any more than non-rotated sprites would. I guess scaling is less useful, only really there for shrinking something to show distance.

If a coprocessor did the rotation/scaling, it could fit a sine/cosine table in with the code pretty easily, but if an FPGA did it, then room for big lookup tables is a bit more scarce.


Top
 Profile  
 
PostPosted: Fri Jul 07, 2017 5:50 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18993
Location: NE Indiana, USA (NTSC)
Rotate a 16x16 sprite, and unless it fits in a radius-8 circle, it becomes a 24x24. An example from the sprite shearing topic:

Attachment:
16x16_plus_rot_equals_24x24.png
16x16_plus_rot_equals_24x24.png [ 1008 Bytes | Viewed 440 times ]


Yes, scaling is useful to show distance, especially in car racing games or Space Harrier-family games (or in Super NES platform fighting games where the background uses mode 7).

But if we're expanding sprites, we need to expand each PPU's sprite capacity from 8 per line to 15, as I've described elsewhere. This may trip up MMC5 but won't trip up MMC3.


Top
 Profile  
 
PostPosted: Fri Jul 07, 2017 9:40 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2265
Maybe the rotation chip can trim around sprites. Heck, it can even merge same colored rotating sprites together. It might as be capable of merging all same colored sprites together anyway.


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

Joined: Thu Apr 14, 2016 2:55 am
Posts: 855
Location: Gothenburg, Sweden
First, i'd like to clarify that anything written in the OP was just to get the thread started, not a locked design proposal. :wink:

Regrettably, i won't have access to my laptop for a few days. A few mockup animations of whole screens would greatly help visualize what you could do with two or three PPU:s layered on top of each other. I'll return to that if there's at least some interest.

It also makes quoting specific subtopics a pain from the phone, so bear with me. Anyway:

InfiniteNESlives, you may very well be right that a standalone console might not be the right end form. But regarding the use of two/three layered PPU:s (which is really the core feature in my otherwise conservative proposition in the OP), i have to disagree strongly. For example, assume a scrolling walking left and right type of game. On a per level section basis, what's significantly more complicated, project time enlarging, or unwieldy uploading a fixed scenery to the "background layer" PPU and let the rest behave as usual? The amount of extra work is minimal code-side, while massively altering the visual experience. While a graphics hobbyist like me would love to see what i can do with that feature alone, the task of generating graphics can also be as simple as layering a set of graphics you would've drawn anyway, like for example an arcade port of Moon Patrol. In this instance, parallax scrolling would actually become less time consuming to program, assuming NES won't have the parallax effect and "+" addition would.

Ultimately, the choice is up to the designer/dev: Use the 2/3 PPU:s (and CPU power) to make the project more manageable/less time consuming, or make the same effort to achieve more things, or in the rare occasion, ramp up projects to make something really shimmering. We're also seeing more and more colaborations/division of labour along with tools/engines, which enables more people to participate in the homebrew scene.

Furthermore, if the layer combiner unit would support programmable PPU ordering, or even a byte's worth of steps of opacity and blend modes on top of the already present emphasis bits that would now be on a per PPU level; a deep well of creative experimentation would be just one register write away.

With one of the two WDS CPU:s as a base, it could also become easier to make music work. You could simply write music however you want in FamiTracker, focusing on the expression rather than the art of compromise (and spend time on team discussions on the same topic - which may be part of the fun but adds to the project scope all the same). Now there's the option to skip the art of compromise - if you want to focus on other things. Both options are there.

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. By comparison; GTROM offers more interesting and accesible features for a lower price - for example the way 4-screens and their bankswitching enables me to write less complicated code to achieve nice looking scrolling and status bar/map features makes it much more attractive to sink my teeth into. It lets me do things i want to do without the relatively messy interface of MMC3. When planning out a project or just doodling code for the purpose of learning, i do it with either NROM, UNROM or GTROM as a template. Will it have scrolling? Then i go to GTROM directly.

I think it is important that a hypothetical console (or expansion) leaves room to grow organically into over time. But it isn't really comparable to most of the commercial-era mappers, because most of their feature sets aren't that attractive to grow into. Music chips aside.

I think Gradual Games is right that the first step should be something akin to a "fantasy console". But as for the choice of programming language, to each their own. Before reading every article and pdf i could find on 6502 assembly, all i could program was qbasic (and similar languages), terribly aged webdev, and game maker scripts. This makes me a programming novice at best, but i found the 65xx assembly terribly fun. Every little personal success is felt, somehow, directly*. Now, with a 65816 or the like, you can write the same sort of assembly, but more comfortably so - and you can also afford yourself to make efficiency mistakes more liberally while learning/exploring the platform. Or, if you prefer C or a C-like language because that's the direction you came from, that would mean your compiler doesn't have to be as efficient as for the 6502 and close derivates. You could write a FORTH or BASIC-like compiler or interpreter just aswell; as has been done for vanilla NES.

Basically, you would have more options viable to suit your programming preferences.

*Granted, i can whip up a simple NES-like single screen platformer or shoot em up in under an hour in something modern like game maker, which provides a plate to build the burger on (as does pico8 to some extent if i've understood it right). But there's little lure doing so on in game maker. It'd just be shovelware, most likely/something PC/mobile has more than enough of.

But back to the fantasy console thing. That's what this basically would be, for a long time. Meaning it would only exist as a console emulation in its first phase. As soon as you have emulation, nothing's to stop an individual from disabling desktop on an RPi and autostart emulation on power on, to approximate a console experience. More conveniently still if distributed as an image. That'd potentially gather interest from the RPi tinkerer and leisure user crowd if well presented. An actual, functioning console/full expansion release would likely be the final step and a luxury item with a small run, that's almost garantueed, but the install base is wider than that.

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


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

Joined: Wed May 19, 2010 6:12 pm
Posts: 2265
I think we should have a bus multiplexor chip for the 3 PPUs, so we don't need 3 different VRAMs or cart slot buses.


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: nesrocks 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