I finally got 3 of the the SX-Flash PCB I deisnged ! I did that mainly for fun and practice, to see how well it would turn. I started it at scool with a help of a professor.
I don't have all componant for it yet, so I don't know how well it will work, but at least it is like I expected it to be and it fits in a cartridge case, which is a great joy to me !
The board is not compatible with any Nintendo made board (else there would be no point in making it), but it allows to do test with a lot of SRAM without buying a game with rare MMC1 variants in it. That's where the name comes from, it's derived from SXROM, but uses a flash ROM instead.
Compatible with UxROM. Compatible with minor hacks with AxROM and BNROM. Compatible with hacks with SNROM, SOROM and SXROM, under the condition that only one mirroring is used per programm.
SX-FLASH mapper :
128kb, 256kb or 512kb of FlashROM at $8000-$ffff (bankswitched)
8kb of CHRRAM at PPU $0000-$1fff
32kb of battery backed WRAM (the chip is surface mounted on the bottom of the PCB to save space) at $6000-$7fff (bankswitched)
Mirroring : Horizontal, vertical, and single-screen available with solder pads
Two PRG bankswitching, 32kb and 16kb available with solder pads
No bus conflicts.
No CIC on the board.
Board is standard 1.5-mm thick instead of 1.2mm as true NES games are (the factory I used didn't allow to change the thickness)
Code:
Writes to $8000-$bfff :
xxxxPSSM
P : PRG-ROM 256kb page selection
S : WRAM 8kb page selection
M : Mirroring selection (only in Single-screen mode)
Writes to $c000-$ffff (if 16kb bankswithing) :
xxxxBBBB
B : 16kb PRGROM bank select for $8000-$bfff
Last 16kb of the current 256kb page is hardwired to $c000-$ffff
Writes to $c000-$ffff (if 32kb bankswithing) :
xxxxbbbx
b : 32kb PRGROM bank select at $8000-$ffff
Now some pics of the board (unmounted yet) :
Very cool. I wish I knew how to do this sort of thing. Question for you, this all works without any custom chips? Just usin 74 series chips?
Good work, sounds and looks nice. It's fun to play with SRAM.
Looks interesting. Can you make a famicom version of it?
Edit:
It's it possible to bank switch 8k bank only? Can you bank switch some banks in the CHR-RAM? I saw some mapper doing this, maybe konami, I forgot. Just curious.
Banshaku wrote:
It's it possible to bank switch 8k bank only? Can you bank switch some banks in the CHR-RAM? I saw some mapper doing this, maybe konami, I forgot. Just curious.
Yeah you can, if there were any bits left in the registers that'd be a good way to use them. 2 bits would do 32kB. Plus, you can't really find 8kB SRAM chips anymore.
My Squeedo cart has 32kB CHR-RAM, with the bank select being disabled when it accesses nametables, so you can use all 4 screens (leaving 28kB for tiles).
Yes, it only uses standard chips (I don't have 100k$ for making custom chips, nor the knownledge).
The mapper works as I've posted it, there is no additional features I haven't mentionned. I couldn't get anything more complicated to fit in a case with only 74 series chips easily, some programmable logic would have been needed, and this imply complicated things I'm unable to do.
There is :
- 2x 74HC161 for latching 4 bits (one for $8000-$bfff, the other for $c000-$ffff)
- 1x 74HC139 to decode adress for both register and to remove bus conflicts
- 1x 74HC08 to decode CE of the SRAM
- 1x 74S04 to turn CE to /CE, and with battery backed security.
- 1x 74HC32 to optionally fix the last bank into $c000-$ffff like UNROM does.
I guess a famicom verion would be possible but you'd have to reverse-engineer the dimention of all famicom boards. There is a square hole, which is not something easy to do, as opposed to circular holes. Anyway, I don't know if they'll work at all for now. I just figured out that thickness will be more an issue that what I was hoping. I won't be able to get all the componants to make one until during next week.
Banshaku wrote:
Can you bank switch some banks in the CHR-RAM? I saw some mapper doing this, maybe konami, I forgot. Just curious.
It might have been CPROM, used in Videomation.
tepples wrote:
Banshaku wrote:
Can you bank switch some banks in the CHR-RAM? I saw some mapper doing this, maybe konami, I forgot. Just curious.
It might have been CPROM, used in Videomation.
This comment will be off-topic so you should split that thread. What is the advantage of being able to bank switch CHR-RAM? If you only have 8k of it, I don't see any advantage. If you had more, it's a different story I guess.
I think it'd be cool if there was something like 32k of CHR RAM data, and you could write to individual 8k sections and bankswitch it to make instant graphic updates. I don't know if this is possible though. It sounds like it would be.
(offtopic)
Sure would be, you could even mod a board with 1K ROM switching to do that. Hell, it'd be possible to do 16 byte bankswitching ;)
Celius wrote:
I think it'd be cool if there was something like 32k of CHR RAM data, and you could write to individual 8k sections and bankswitch it to make instant graphic updates. I don't know if this is possible though. It sounds like it would be.
Would you mean something like being able to map CHR-RAM to both CPU space and PPU space? Like having 2 or 4 8K chips you could map to either place? Or just a plain 32K of chr ram?
Sorry if I'm not making much sense; I've never dealt with anything other than standard 8k of CHR RAM.
Anyways, basically what I'm trying to say is if you had something like one chip with 32k of CHR RAM, that would be 4 8k CHR RAM banks. You could turn the screen completely off, and draw data in each of those banks. Then you would have 4 banks that you could switch around with to make instant graphical updates like you can with CHR ROM, basically giving CHR RAM the major advantage that CHR ROM has. Does that make sense?
Yes that does, and I've thought about the same thing before myself.
(offtopic)
So basically "CNRAM"? Early Game Doctor hardware does exactly that, but at 8K banks it still not very handy. I say make the most of it with 1K/2K banks, all you need to do is rewire a MMC3 CHR ROM cart for a 62256, then you can have 6 separate 4 frame animations simultaneously.
Oh well that's what I was thinking kyuusaku, not 8k pages, but 32K of CHR-RAM that is bankable either like MMC3 or better mappers that do 1K sections.
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.
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.
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.
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.
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).
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.
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?
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 !
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.
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.
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.
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.
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.
tokumaru's explanation is exactly why Color Dreams' Boulder Dash clones (Crystal Mines, Exodus, and Joshua) use 8x16 sprites. But then those games used a board rawther similar to GNROM, having no real need for a scanline counter.
Quote:
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.
Oh this make sense. But that is probably because your game is inspired by 16-bit games. I wouldn't have such an idea of object that can be either BG or spirtes in a game I'm making honnestly, but this is a good idea.
Altough, in most cases 8x16 sprites will increase flickering more than 8x8, exept in the particular case you mentionned.
In my game I use 8x16 sprites to reduce the amount of sprites on screen. My status bar alone uses 10 8x16 sprites to display vital information (4 digits of health, 3 digits of MP, 3 digits of heart amount, letters H and M to represent "Health" and "Mana", a heart icon, and an 8x16 pixel reprentation of the current subweapon). Without 8x16 sprites this would take 15 sprites, and that's kind of a waste. 10 sprites may still sound like a lot (and I guess it is), but the player only uses 4-6 sprites, and most enemies take 6(moderate size) to 10(large) sprites, and most of the time there are only 2 to 3 of them on screen at once with about a max of 4 weapons on screen (generally 2-3 sprites). So there are usually about 40 sprites on screen maximum. If I were using 8x8 sprites, this would mean there are ~75 sprites, which is not possible without mega flickering.
I use 8x8 sprites for my polygon engine though, because it's way too much complication to deal with on the fly. But that's way off topic.
I do agree that it's kind of a waste when something is only 4x4 pixels and you have to use 2 tiles for it though. However, since you can grab from both pattern tables, I think it makes up for it. Being able to draw something as both BG and sprite without wasting tiles is really good.
But when using 8x16, I hate that I give up the scanline counter. I have lots of CHR RAM updates I need to do in Vblank, and it would be really handy with a scanline counter so I wouldn't have to do fixed timed code and waste cycles while I could be doing something else.
Bregalad wrote:
Altough, in most cases 8x16 sprites will increase flickering more than 8x8, exept in the particular case you mentionned.
Yeah, I see what you mean. My own graphics have a lot of transparent areas wasting pattern table space and interfering with the sprite limit. I try to place such areas at the bottom of the objects, so that when placed on the floor the transparent pixels stay below the ground, where there usually aren't many sprites.
I agree with Celius, only 64 8x8 sprites cover a very small area of the screen, and being able to double that is a big advantage. For most games with small characters, 8x8 is probably fine, but when they are somewhat large, the flickering can be unbearable.