Topic says it all. I think that I want to expand my game so I won't have to worry about space. To do this, the next size up is 512kb. I don't think this configuration was ever used in any game, so that's why I'm asking.
It'll solve a lot of problems for sure.
And... regarding flash memory, I know that it can only be written to so many times before failing, but what about reading from it?
Thanks.
Expanding UxROM to 512KB is not as trivial as going from 128KB to 256KB... To index 32 banks you need 5 bits, but the chips commonly used for bankswitching in UxROM carts can only work with 4 bits. If you (or whoever is making the carts) are willing to use 2 extra chips, or use different chips that can work with more bits, then you could go as high as 4MB of PRG-ROM.
About the Flash memory, I'm pretty sure that reading doesn't reduce their life span.
a 512kB UxROM game would no longer fit on the standard ReproPak boards, but it would not be at all difficult to make a board using a 74'377 and one or two 74'32s for the equivalent functionality.
It's conceivable one might be able to connect A14 to the '377s /OE pin and a number of resistors pulling the outputs up to fake the 74'32s but I'd want to test extensively before I deployed it.
I don't need 4MB... Thankfully. Heh.
I want to be absolutely certain that I can make the game this way before doing it. A 512kb UxROM game works fine in any emulator, but that's that platform. I have tried it in the past with the extra banks and nothing out of the ordinary happened.
By "extensive testing" do you mean playing the game through several times or something? Or just testing things that are in the extra banks? I can definitely divide up the data a lot more effectively if I have this extra space.
The other (much less favorable) solution would be to change mappers...
bunnyboy where are you?
Well considering you're at the end of working on BK2 it wouldn't be hard to only test on hardware and test code in tidbits on emulator to make sure they're 100% and not doing anything weird. Maybe re-evaluate your code and other data and try to cut out what you don't need. Switch to MMC1. There's lots of solutions and such. Heck, if you're going to need a board for this I'm sure you don't need that much space, maybe but a ROM on the board in the 6000-7FFF region with the extra data you need. Then you don't need another mapper, although it'll cost 1 extra 27C64.
It's definitely possible. putting two 161s and 32s on the board basically doubling the UxROM mapper is the easiest way without thinking about what other chips would work.
I wouldn't recommend the 377's @lidnariq is talking about. That enable is for the outputs if you used it you would want it tied to ground. The real issue is that chip doesn't have a /LOAD input like the 161. You need that so the 161 doesn't latch on every /CE toggle. You want it to only load on a write signal. which would require another chip to buffer somehow.
EDIT: I was wrong see next post
As for flash it would work fine. There isn't any read limit.
bunnyboy doesn't "officially" live here anymore. But I think he could easily solve this issue for you and would hope he does with all the money he has to make off the game's release.
It's true it wouldn't fit on his repropak that he uses for BKI but he could easily reconfigure CPLD on his MMC1 boards for this mapper.
If you'd like a full schematic and list of parts I'd be happy to make it up for you. I can even test it on the actual hardware on the NES and all if you want some actual proof it works. Just let me know, I'd love to be a part of the game!
lidnariq wrote:
a 512kB UxROM game would no longer fit on the standard ReproPak boards, but it would not be at all difficult to make a board using a 74'377 and one or two 74'32s for the equivalent functionality.
It's conceivable one might be able to connect A14 to the '377s /OE pin and a number of resistors pulling the outputs up to fake the 74'32s but I'd want to test extensively before I deployed it.
You threw me for a loop here talking about the /OE pin. There isn't one, it's actually /CLKEN (clock enable) which is exactly what you want and works the same as the /LOAD pin on the 161. So PRG R/W would be connected there, and PRG /CE to CLK. Then D0-D5 naturally.
So I agree the best way to do it would be use the 74'377 and two 74'32s. I wouldn't play around with the resistors and everything though nothing to gain even if it worked, still not sure where you wanted to connect A14.. I could imagine it working on a good day if the /OE pin you speak of actually existed.
http://www.ti.com/lit/ds/symlink/sn74hc377.pdf
Just use the two 32's their dirt cheap especially in large quantity. You could use a 6 circuit or gate like the 74AS832 but it's probably more expensive and only changes the chip count from 3 to 2...
If you need someone to design the board for it, I could do it for cheap.
If you wanted to write to FlashROM, you could use a 74hc138 or '139 to relocate the mapper register.
Quote:
I wouldn't recommend the 377's @lidnariq is talking about. That enable is for the outputs if you used it you would want it tied to ground. The real issue is that chip doesn't have a /LOAD input like the 161. You need that so the 161 doesn't latch on every /CE toggle. You want it to only load on a write signal. which would require another chip to buffer somehow.
You need a single OR gate (OR !ROMSEL and R/W) for this, and since you need 5 OR gates to fix the last bank to $c000-$ffff anyways, 2 74HC32 chips will be required so two '32s plus one '377 will do the work.
And oh no I just figured it was sivak who asked the question so he's going to make profit on my tip... well it's too late anyway.
I'd just use better compression.
From what I saw in the demo, graphics are uncompressed, and levels are compressed using literals for values 00-7F, and LZ/RLE sequences for values 80-FF.
There's lots of improvement possible for the graphics.
Levels are compressed fairly well.
SGROM has the same capabilities as UNROM and UOROM with an MMC1 instead of the discrete chips. SUROM is like SGROM and SNROM, except one of the MMC1's CHR bank bits is used to switch between the bottom and top half of the 512 KiB PRG ROM. The manual for the ReproPak MMC1 board says it can make SUROM.
tepples wrote:
SGROM has the same capabilities as UNROM and UOROM with an MMC1 instead of the discrete chips. SUROM is like SGROM and SNROM, except one of the MMC1's CHR bank bits is used to switch between the bottom and top half of the 512 KiB PRG ROM. The manual for the ReproPak MMC1 board says it can make SUROM.
On NA he said he didn't want to use MMC1, making a game with more content at a cheap cost is the only priority so while I suggsted it too I wouldn't throw out any MMC1 suggestions. Because then if he uses it but doesn't add WRAM too I'm sure you'd make people mad that it could have supported it with 2 minutes of programming and completely removing the password system. And then also do more stuff with your engine with the other 8181 bytes of RAM you'd have.
Clearly you can have a UxROM board with support for 512kb. But you'll have to talk to BunnyBoy about the pcbs for the game then. The existing Repro boards might be possible to hand-modify to support more PRG.
infiniteneslives wrote:
You threw me for a loop here talking about the /OE pin.
Ugh, I meant the '373.