I am just wondering what everyone's stances are on this topic. I looked up the price of a 6116 SRAM at Unicorn Electronics, and it seems a 6164 and 6116 for 8KB WRAM and 2KB VRAM cost about $3.00 for both. Cheaper is you go by 10's or 100's. I think that is really, really cheap for what it gives you. With the price of the RAM being so cheap for both RAM's, do you think a 4-way scrolling game should have any reason not to include it and get rid of glitches on the side and also throw in the WRAM if needed? I see all this stuff done, but I don't think anyone who scrolls, let alone 4 ways, uses it. I think it seems justified for the price and how much more it gives you to work with.
Just wondering what everyone else thinks on this matter. I believe if I made a 4-way scrolling game, I'd use both just for the heck of it.
Something to think about is if you want to manufacture a cart run (which apparently you are thinking about, otherwise you wouldn't be looking at prices
). You won't be able to use the boards from RetroZone, you'll have to make your own. This ups the technical complexity and startup investment.
Also on-cartridge VRAM does not work on most FamiClones. For me at least that's a show-stopper.
I don't use the extra VRAM it because as far as I know, there's no way I can put my game on a cart without destroying existing carts if I use it. Cheap RAM existing doesn't mean custom boards are commercially available that can use it. If there is such a solution, I'd like to know about it.
As for WRAM, I don't use it yet, but may use it for saving. My game just leaves 4 screens of 32x32 tiles in a page of the regular RAM for now. This way the time spent decompressing my level data is only done when going to a new screen. Getting an 8x8 tile from a 32x32 tile is not as big a deal for the CPU as having to find a screen, then get a tile from that.
8KB WRAM is a lot of space and if I don't use it for work RAM, I could even allow the user to store one level replay in it if it's <2 minutes.That would even leave 992 bytes for the rest of the data which is still a lot, and I could have a level editor AND an actual save. I do recall bunnyboy's MMC1 clone not supporting a battery save either, but I think that'd be easier for him to support if a good enough game comes across his table.
Actually, unless you want to use the Gauntlet boards, or that weird ass famicom game, you'll have to make your own boards. Like QBrad said. I believe if I (or anybody) made a game that used it and would sell and then be able to get boards made, I believe we could get some help and get 20 or so made at cost and then sat on for anyone who'd like to develop on it, then just sell it at cost to encourage development with it. I think if I were to make a game and see if my father would be up for making a couple, they'd probably be 8 or 32KB SRAM/WRAM, 32KB CHR-RAM, and then probably 512K-1MB ROM, and then of course 2KB VRAM added. Something like that. I just don't know though, it's just me brainstorming. Seems like all ideas I come up with, that board would be perfect for it, even if it won't come out to be 1MB, the options are great for it.
And I won't even let a famiclone stop what I think of getting put onto a board. Then the PowerPak wouldn't even exist if you limited like that.
The MMC1 repro board at RetorZone says it supports battery-backed SRAM. There's even spots on the board for the diodes and resistor, and instructions for how to solder everything in.
That said I have yet to put a battery on mine.
3gengames wrote:
Actually, unless you want to use the Gauntlet boards, or that weird ass famicom game, you'll have to make your own boards.
As stated in my previous post, that's issue for me. I won't destroy old boards, and am incapable of making my own. Should you manufacture one, I would perhaps use it if it's cheap enough. It is probably definitely not a big enough deal to me to spend any more than I would already spend on bunnyboy's MMC1 board though, just to hide scrolling attributes however.
qbradq wrote:
The MMC1 repro board at RetorZone says it supports battery-backed SRAM. There's even spots on the board for the diodes and resistor, and instructions for how to solder everything in.
Are there still instructions on how to add a battery?
http://www.retrousb.com/downloads/repro ... manual.pdf
I do seem to remember there USED to be some, but there doesn't seem to be now. Could you post the instructions you have, or show me that I'm not looking hard enough? I did check.
You solder it to pads on the back of the board.
Fair enough. Just to prove my suspicions were correct:
http://bertozi.com/adb/telecomunicacao/ ... manual.pdf
That is the old pdf. The one on the website (linked in my last post) no longer explains how to do it. Why he removed step 5 with how to add battery backup, I have no idea. So I would assume someone has bought this board recently, and successfully added a battery to it? Otherwise, my worry would be he removed step 5 because something wasn't working properly or the board changed in some other way. Getting off topic so feel free to just PM me.
I bought the board when the manual still had the battery instructions, and my board does have the solder pads for the battery on the back. Thanks for that link!
As for WRAM it really depends on your requirements. For my
Adventure Game Demo I used WRAM to decompress an entire level to RAM so I could easily support scrolling in two directions. For my latest NROM game I am only scrolling forward, so I use a wrapping buffer 32 columns wide.
I could have used a wrapping buffer for the adventure game as well but it would have been somewhat more complicated. Add to that the fact that I want battery-backed saves and there's not much of a reason to.
The question is not how much it costs today, but how much it costed in the late 80s - early 90s.
I think the OP is wondering why modern homebrewers don't use 4-screen VRAM.
Personally I would be a big supporter of this if the clones supported it.
Bregalad wrote:
The question is not how much it costs today, but how much it costed in the late 80s - early 90s.
Well, yeah, but today, don't you think there should be more people using it? Although I guess most people like everyone here can't exactly make a board on the spot with it, so that could play in with it....
Wouldn't it be dead simple to make a board using an always-enabled 62256? It'd provide CHR RAM in $0000-$1FFF and nametables in $2000-$2FFF.
tepples wrote:
Wouldn't it be dead simple to make a board using an always-enabled 62256? It'd provide CHR RAM in $0000-$1FFF and nametables in $2000-$2FFF.
I've been wondering about that myself. Again my only problem with this is the issue of clones apparently not supporting it.
qbradq wrote:
tepples wrote:
Wouldn't it be dead simple to make a board using an always-enabled 62256? It'd provide CHR RAM in $0000-$1FFF and nametables in $2000-$2FFF.
I've been wondering about that myself. Again my only problem with this is the issue of clones apparently not supporting it.
I don't think many, if anybody, doesn't do something because clones don't support it.
I wonder if the decapping and simulation efforts (e.g. Q's "Visual 2A03") will lead to more accurate clones.
3gengames wrote:
qbradq wrote:
tepples wrote:
Wouldn't it be dead simple to make a board using an always-enabled 62256? It'd provide CHR RAM in $0000-$1FFF and nametables in $2000-$2FFF.
I've been wondering about that myself. Again my only problem with this is the issue of clones apparently not supporting it.
I don't think many, if anybody, doesn't do something because clones don't support it.
Well... now you found somebody
I can see the attraction of wanting to making something that's highly compatible across the board. There are quite a bit of fami-clones out there (not to mention emulation itself).
Where is your proof that this doesn't work on famiclones? There seems to be absolutely no reason for this to not work on clones, so I'm having a hard time believing that this would be incompatible.
Many clones are wired wrong. They connect CHR /A13 and CIRAM /CE internally instead of sending them to the cart connector. When you see games like Gauntlet or Rad Racer II on the incompatibility list, that is why. At least the Yobo, NEX, FC Twin, GN Twin, and Gen-X are all wired that way.
Maybe that's a good way to stop games from playing on famiclones. Read the memory, if it's not all there, just tell them to get the real thing. Oh well, not my problem.
A side question: Has anyone considered just shoving 4 screens to the nametable and then just using those to as the "screen" and scroll around on that, and when exiting, scroll onto 4 new nametables? I think that'd be great for an adventure game/RPG. Scrolls and has difference screens, I think both would be awesome.
3gengames wrote:
Has anyone considered just shoving 4 screens to the nametable and then just using those to as the "screen" and scroll around on that, and when exiting, scroll onto 4 new nametables?
Isn't that what Zelda 3 does?
On the NES? I'm not familiar with many SNES games, especially not the hardware.
3gengames wrote:
Has anyone considered just shoving 4 screens to the nametable and then just using those to as the "screen" and scroll around on that, and when exiting, scroll onto 4 new nametables?
Sounds to me like a very cheap and limited way to do scrolling. Four-screen just makes programming easier, it doesn't make games any better. Pretty much everything that can be done with it can be done without it, even if a bit of extra work is required.
tokumaru wrote:
3gengames wrote:
Has anyone considered just shoving 4 screens to the nametable and then just using those to as the "screen" and scroll around on that, and when exiting, scroll onto 4 new nametables?
Sounds to me like a very cheap and limited way to do scrolling. Four-screen just makes programming easier, it doesn't make games any better. Pretty much everything that can be done with it can be done without it, even if a bit of extra work is required.
Well, you could make it scroll from there too if you wanted, but I though just the mechanic of scrolling, but not having it go many screens, and keep them smaller like 2x2, and then do a zelda 1 type of scrolling when you hit the edge of the screen. Just wondering if that'd be cool or annoying. I'm trying to think of games for SNES that do something like that, but I can't think of any. Gauntlet does that, shove all 4 screens up and forgets it, but it was to keep track of the game that way and enemies.
Quote:
Well, yeah, but today, don't you think there should be more people using it? Although I guess most people like everyone here can't exactly make a board on the spot with it, so that could play in with it....
Probably. I don't see much reasons for NOT using it (assuming you don't care about it) but I don't see much reasons for using it either... It's really down to if you want to pay the extra $3 per cart or have a harder time programming the scrolling engine.
You could even start with 4-screen programming and go back to a standard configuration right before releasing the game if you want to save the $3 per cart. If your scroll engine was well written the effort for doing this would be minimal.
Quote:
Sounds to me like a very cheap and limited way to do scrolling. Four-screen just makes programming easier, it doesn't make games any better.
I have to pretty much agree with this.
Quote:
Pretty much everything that can be done with it can be done without it, even if a bit of extra work is required.
Well, pretty much everything is not everything. I guess it could be good for fake 3D or really crazy raster demo-scene things.
Bregalad wrote:
Well, pretty much everything is not everything. I guess it could be good for fake 3D or really crazy raster demo-scene things.
Yeah, that's exactly the kind of thing that came to my mind when I said "pretty much". =)
3gengames wrote:
Gauntlet does that, shove all 4 screens up and forgets it, but it was to keep track of the game that way and enemies.
I don't really see how having 4-screen VRAM helps keeping track of game/enemies that way, they were just lazy and/or didn't care about the extra cost.
thefox wrote:
3gengames wrote:
Gauntlet does that, shove all 4 screens up and forgets it, but it was to keep track of the game that way and enemies.
I don't really see how having 4-screen VRAM helps keeping track of game/enemies that way, they were just lazy and/or didn't care about the extra cost.
Well when you need to put about 8+ 2x2 tile enemies on the screen, the flicker without using it would be insane, and they couldn't remember them all on the screen I guess, so it seems they just suck it to the screen since everything else would just not be plausible and they did away with sprites flickering. The no scrolling sucks, but I think that's the right choice to get the game done.