It is currently Thu Dec 14, 2017 10:14 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 34 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject:
PostPosted: Sat Dec 13, 2008 1:41 am 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2143
Location: Minneapolis, Minnesota, United States
Even if it were in 8k sections, it'd still be more handy than just 8k of CHR RAM. I would like it if you could switch with 1k sections too. What would be even cooler would be to allow 256 byte bankswitching so you could switch 16 tiles at a time. Though maybe you could have different modes where you could switch 256 bytes, 1k, 2k, 4k, or 8k. Again, I don't know how possible this is, because I barely know what an ohm is (aka I know barely anything about electronics). If this is possible, why wouldn't have games done this? This seems like a total life-saver.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 13, 2008 1:47 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
This is perfectly possible by replacing a CHRROM chip by a RAM chip on a TERROM TFROM board (and do some possible minor rewiring). But you'll have to find an emulator that support that.
And this has absolutely nothing to do with my original topic.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 13, 2008 2:21 am 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2143
Location: Minneapolis, Minnesota, United States
Okay, so it is possible. Perhaps in the very very far future, I'd make a board that supports this. But yeah, knowing nothing about electronics, I'm not going to jump right in (I've jumped into stuff I didn't know anything about before, and it didn't work so well :) ).

And it's true, this is off topic. But I continued posting expecting that it'd be split.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 13, 2008 2:06 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2806
Back on topic then, would have have any idea or have any plans on adding some kind of IRQ counter to a future custom board like this? I've heard that it's not that hard to make a CPU cycle based IRQ counter. It would be nice if there were a custom board available that supported an IRQ counter. Currently you have to butcher an existing board.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 13, 2008 2:28 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1667
Location: .ma.us
IRQ counters are relatively simple, but still not very discrete chip friendly; you'd really need 6-7 chips for a decent one. If I were more confident in board making, I'd put together a CPLD based FME7 + 32K CHR RAM, seems like the ideal solution for a game I've been thinking about but it'd probably be smarter to just PowerPak prototype it.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 13, 2008 3:00 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
There is several way to do a IRQ counters I guess, and it's possible to come with something relatively simple in hardware if one accept to complicate the software in compenation for that.

Maybe with two daisy-chained 74HC161's you could load them with some 8-bit value (exaclty like you do when loading them when they act as a latch), but this time their "Count Enable" pin would be connected to the output of another latch (the "enable" bit).

If this is a M2 based counter it will work great but you'll only able to count 256 CPU cycles which is about 2 scanlines, and this is not very useful. You'd want to get a divider before the counter so that you get more usefull values, but then there is no way to guarantee you get a clock when writing to the register. However, by doing multiple writes to the register a certain number of times with timed code this should be possible :wink: . For example, if you use a divider-by-16 on the M2 clock (easily doable with yet another 161), and if you do 16 consecutive writes with 15 clocks between each, you are 100% sure the register has been loaded at least one time.

If you want a A12 based counter (advantage of being NTSC/PAL compatible), then the problem is the same : It should be clocked by M2 when loading but by A12 when counting. Then you'll likely need a clever use of a 74HC138 (or 139) adress decoder combined with some basic gates (or, simpler, a PAL chip), so that the chip is clocked either if you write to it *AND* if A12 have a rising edge.

Either way, you write some value to the register, and the counter would count it up and do an interrupt when it reches $ff, but that won't prevent the counter to overflow to $00 if an additional clock occurs. To disable interrupts, simply write $ff to the counter and '0' to the "enbable" bit. To be sure it don't moves.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 14, 2008 3:37 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Bregalad wrote:
If you want a A12 based counter

I believe this is the reason the MMC3 has those absurd limitations on it's scanline counter, am I right? If so, I'd like to ask anyone that's considering creating a board/mapper for the community to NOT USE A12 FOR IRQ PURPOSES, PLEASE! IMO, a mapper should only add features, not break things that would otherwise work perfectly fine. I think the price is too high for PAL/NTSC compatibility.

As kyuusaku suggested, an FME7-like board would be perfect. Great bankswitching scheme and solid IRQ counter. This is as good as it gets without the crazy (although nice) features of the MMC5. It would be good if we could select between CHR-ROM and CHR-RAM (I guess you could simply design the board for CHR-ROM, then you could place a RAM chip as big as you want as well, not limited to 32KB).


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 14, 2008 4:03 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
Then what about A13 divided by 42 ? This would allow for Scanline precision, NTSC/PAL conpatibility, and you would be able to use both pattern tables for both BG and Sprite, and maybe even to disable BG or Sprites (but not both) and still have the counter working. Altough I haven't tested how reliable this is, it should work in theory.
And I guess you exagerate how bad the A12 idea is. Maybe because you wanted so badly to share tiles for BG and Sprites in a particular game you're making, but personally in my project I always have separate pattern tables for BG and sprites, altough I don't use any scanline counter and I am never limited (but maybe I'll break this "rule" if I place additional graphics for the ending). And with a clever use of CHR bankswitching i guess it's not that much an issue.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 14, 2008 1:45 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2806
If A13 is so much better than using A12, why didn't Nintendo think of it? If it works as good as you say, do you think that MMC5 uses A13 opposed to A12?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 14, 2008 1:48 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
Because A13 toggles 42 frames per scanline, while A12 toggles 1 time if the conditions are correct. Doing a didiver per 42 means additional logic that it hardly doable with 74 chips, but Nintendo could definitely add this in their MMC3. I can't guess why they didn't use it.

The only way MMC5 can keep track of all PPU's reads and write is by watching /RD, /WR and A13 I guess, but I can't guess what's inside the chip. It's probably possible to test that by having a FPGA NES and modify the working of the PPU and study how all signals behave, but I don't have the knownledge to do that !

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 14, 2008 3:19 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2806
Well then it sounds like using A13 is a much better way to do it than A12. It'll be interesting if someone produces their own board with such capability. I'm sure Tokumaru would appreciate it. ;)


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 14, 2008 3:31 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19343
Location: NE Indiana, USA (NTSC)
The choice of A12 might have had something to do with the possibility that Nintendo might change details of the background fetch in future NES PPU revisions, such as changing 8 dummy sprite pattern fetches and 8 real sprite pattern fetches to 16 real sprite pattern fetches, or replacing the last (unused) tile data fetch with a sprite pattern fetch. This would invalidate the assumption of 42 nametable and 42 pattern fetches per line.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 15, 2008 5:45 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Bregalad wrote:
Maybe because you wanted so badly to share tiles for BG and Sprites in a particular game you're making

You guys sometimes seem to underestimate the power of 8x16 sprites fetched from the background side. Let me list a couple of advantages in that:

Dynamic background: you have the possibility of moving parts of the background, like when a player picks blocks up or hits them from below (and they wobble a bit) without having to waste space defining the tiles twice. If you have different types of blocks that move, replicating them is quite a waste. And if you animate them through CHR-ROM bankswitching, duplicating them is extremely prohibitive, because you'd either have to make another set of animation banks for the sprite side or use the same set and give up on the space occupied by the remaining tiles of the bank (which were meant for the BG).

Reduce flickering: I have implemented a system where objects are drawn with background tiles or with sprites, depending on what's best at the time. The same object can be drawn with background tiles when it's not in front of anything and it's coordinates are aligned to the name and attribute tables, or with sprites when these conditions are not met. This is particularly useful in Sonic games for the item boxes. It would be impossible to make long runs of them if only sprites could be used. Since they use quite a few tiles (and are animated with bankswitching), it's absolutely necessary that the same tiles are used. Of course this requires you to make 1 or more palettes the same (or pretty close) for sprites and BG, but that's not such a big issue.

Quote:
but personally in my project I always have separate pattern tables for BG and sprites

So, you say I insist on keeping this feature available along with the scanline counter because of my one project, but I might as well say you don't care about it because your projects have never needed it. It's obvious that people will want features related to the kind of program they make, and I sure plan on using my tiles like that in whatever project I work on, not just this one. If I had to pick (and I did) between the 8x16 sprite freedom and a scanline counter, I'd go with the sprites (and I did), but I'd sure like to have both.

The fact is that each individual has a different way of making games, and each one favors some features above others. But the deal with the scanline counter issue is that it seems really wrong that to implement a new feature you have to give up on an old one. That one feature might not be important for everyone, but there sure will be some that will miss it, or will simply not accept the loss and not use the new feature (this is me with the MMC3). So I'm just asking, if someone decides to come up with a cool board for the community, that this person implements a scanline counter that doesn't impose such restrictions.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 15, 2008 7:37 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
Yes you sure are right that 8x16 sprites from BG may be usefull in some case, and I probably underestimated that.

In my project, I want animation frames to take the least possible number of tiles of pattern table, and this is only possible with 8x8 sprites. Using 8x16 would imply a terrible waste of pattern table, and that way I'd be forced to overflow in the background pattern table when the same graphics could be held in the sprite pattern simply by 8x8 sprites. In fact I was planning to use 8x16 originally but I changed my mind as soon I had to draw player's sprite, that way I was able to spare more than 32 tiles in the sprite pattern table for the same animations !!

However I'm maybe planning to have projects where the sprites are a fixed size and could be both BG or sprite in a tactical RPG. In that case 8x16 sprites would be really usefull.

And I agree that A13 would be better than A12 becuase you get rid of these limitations, and that Nintendo were a little stupid to use A12 that implies that limitations, but you probably exagerate how bad the limitations are. However, in the case of a 74HC board that would feature a scanline counter, I'd be pretty forced to come with A12 if I want any hope to make it with as few chips as possible. Because if the counter is 8-bit (count scanlines), it can be done with fewer chip that if it is 12-bit or 16-bit (counts M2 or 42 times scanlines).

On a side not, while 8x16 sprites have their advantage, I really can't see how they could reduce flickering in any way. On the other side, they'd rather increase the potential flickering, as you're forced that all sprites are at least 16 pixels tall, even small bulets that are only 4 pixel tall in reality. My player's sprite is 2x3 tiles big, and if I used 8x16 sprites I would be forced to make is 2x4 (I originally planned to do that), and this implies more potential flickering.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 15, 2008 12:35 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Bregalad wrote:
On a side not, while 8x16 sprites have their advantage, I really can't see how they could reduce flickering in any way.

What I meant was that in some cases, when the conditions of an object are ideal (static object aligned to the name and attribute tables), it could be drawn in the background rather than being represented with sprites, which would prevent flickering.

As an example I mentioned the item boxes (monitors) from the Sonic games. In many places there are rows of 4 or 5 of them. Can you imagine how that would flicker on the NES? But since they just sit there, they could be drawn on the background. However, they can't be always background, because some fall from the top of trees, some are upside down, and other variations that require sprites. This is why the 8x16 sprites are useful, the same object can be drawn with sprites or background, and when the background is used you avoid sprite flickering as a consequence.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 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