The SX-Flash PCB I made
Moderator: Moderators
-
Celius
- Posts: 2158
- Joined: Sun Jun 05, 2005 2:04 pm
- Location: Minneapolis, Minnesota, United States
- Contact:
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.
-
Celius
- Posts: 2158
- Joined: Sun Jun 05, 2005 2:04 pm
- Location: Minneapolis, Minnesota, United States
- Contact:
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.
).And it's true, this is off topic. But I continued posting expecting that it'd be split.
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.
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.
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
. 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.
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
. 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.
Useless, lumbering half-wits don't scare us.
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.Bregalad wrote:If you want a A12 based counter
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).
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.
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.
Useless, lumbering half-wits don't scare us.
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 !
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 !
Useless, lumbering half-wits don't scare us.
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.
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:Bregalad wrote:Maybe because you wanted so badly to share tiles for BG and Sprites in a particular game you're making
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.
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.but personally in my project I always have separate pattern tables for BG and sprites
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.
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.
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.
Useless, lumbering half-wits don't scare us.
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.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.
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.