nesdev.com

Edit:
I didn't send the final files (inserts for bitboxes and famicom cart labels) until mid-November. (materials for boxed copies all ready earlier though). I assumed infiniteneslives has been busy for holiday season, but sent a message. They'll likely chime in here soon.

_________________
www.mteegfx.com

I'm going to say that things were pretty busy with the CAPCOM SFII release. "We designed, assembled, programmed, and tested all 5,500 of the circuit boards used for the limited edition Street Fighter II 30th Anniversary Cartridges."

Hey guys,

Yeah sorry about the delays here. My initial goal was to get the contributor carts out by the end of November within a week or two after I got the final artwork items from M_Tee. I had some delays due to printer problems, which have since been resolved. But that pushed me to close to the holidays to get anything done by the end of the year like I was hoping for the release..

So at this point I've got all the physical items in hand for the release. NES & Famicom bitboxes were all aquired a few months back around the same time the traditional boxes & posters came in. I've had the first batch of boards assembled awaiting programming for even longer.

I've been slow to update my software tools to support flashing 1MB rom onto the boards with all the other distractions going on. But I've been making progress on that over the past week. Part of that was making my programmer capable of JTAG communications greatly simplifies the rom flashing process and speeds up board programming time with only one tool.

So anyway, I'm not fully complete with the software updates to flash the final rom onto the boards, but my goal is to finish that by the end of the week. I'd like to start flashing and testing boards over the weekend. That would allow contributor carts to get fully assembled and ready to ship as early as next week. I'll be busy before and after the weekend of PAX south the weekend of Jan 12th. So with all this, I think targeting Jan 22nd for a release date is within reach.

What's the status of the final rom? I know it's effectively been done for months, but is there a final copy ready to go assuming all goes well with final hardware testing?

The other item I could use help with is acquiring names, addresses, and email for all the contributors to get their contributor copy. I think NESHomebrew already has some of this.? Ideally this is something we should be asking for in the submission process, but need to be cognizant of people who might have a different address by the time carts ship.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

There's no rush, take your time

_________________
http://www.mojontwins.com

I agree, no rush. If anything it would make more sense to get ready for retail copies when this years compo is released. That way, when attention is pushed towards the new releases, we can send people over to buy last years cartridge. Keep things viable in the future. As for names/addresses, I vaguely remember saying I would get them, but I can honestly say that I did not. I'll get on that.

5 week bump. Anything new to report?

Not really unfortunately for the past couple weeks. But I've cleared out my schedule for this week so I can focus on getting all these put together. I'm hoping to have progress to report tomorrow that I've officially started assembly. Where's the final rom I should be using?

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

The most recent is Page 13b. But if someone wants to make new 10-color screenshots, I'm willing to spin up a new build based on the latest menu software.

Okay thanks for that. I'll report back with progress, and get final 'approval' for the rom before flashing here. I'm pushing to program and test boards this week. I can delay if that's what everyone wants to in order to update the screen shots. But I already feel severely delinquent on this and would like to avoid more delays esp on my part.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

For what it's worth, I definitely don't have time in the immediate future to generate new screenshots. Unless someone else is willing to do those, I say we just go with what we have and save the interface updates for v. 4.

_________________
www.mteegfx.com

Just wanted to check in again quick. I've been focusing on the verilog on the CPLD, and flash algorithm for the program both yesterday and today with slow and mild success. I'm able to dump, verify flash manf/prod IDs, and erase the flash just fine. But the programming algorithm is failing for some unknown reason currently. I can get data on the chip, but some bytes aren't sticking, or are ending up in the wrong place. I've been tinkering with a number of different board/flash versions new & old to try to get to the bottom of things but still not there yet.

No clue why it's being such a bugger but it is.. My typical trick to flash the chip externally and then drop it in the socket doesn't work with tsop packaging. I think my next step is to configure the CPLD for a mapper which is less complex and simpler to program so I can get the flash chip fully flashed and verified. Then reconfigure the CPLD back to mapper 28 and make sure it's playing/tests/dumps properly as I'm highly suspicious of a verilog bug at the moment, but pretty sure I've got a flashing algorithm bug at the same time. So without confidence in any one part of the chain it's a bit of a challenge..

Anyway, I'm confident I'll figure things out soon enough. Just wanted to give update of where I'm at and this is no longer sitting on the back burner. Once I get things working I'll report back and plan on play testing until the following day. At which point I'll start programming boards with whatever is the most final rom version at that point. Expecting it'll be the same build Tepples pointed me to, but until I report back there's at least 24hrs to make any last min tweaks for any reason.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

Another progress report for ya'll. As is typical I can't find problems without taking a break and getting a fresh look at things. I resolved all the problems I was having and am able to fully program the cartridges with my new inlretro programmer build (512KB PLCC & 1MB TSSOP-48). However a new problem has reared it's ugly head..

When running on the 1MB 3v TSSOP-48 flash, I can get things to boot and most games start. But they don't go for long until they crash. I have this problem with both vol2 & vol3 so it's not rom related. I also have effectively identical crash points for games on original NES & a cheap clone. I've also verified this on two different cartridge boards. So everything is highly repeatable and invariable for the most part.

HH85 always crashes after the serum/life count screen while trying to load the actual level I assume. Twin dragons boots & plays, but after 10-30sec of gameplay it locks up typically with garbled sprites. Nebs 'n Debs won't boot, and filthy kitchen runs okay, but there appears to be mirroring issues after walking into the house which is a bit strange..

When playing part1 & 2 separately on the 5v PLCC flash none of these issues exist and everything plays & boots just fine. I also doubled up action53v2 to 1MB and ran it from 3v TSSOP flash and experienced similar problems.

So it's pretty apparent I've got a bug when running from 3v TSSOP flash, as 5v PLCC flash runs perfectly. The biggest difference is that the 3v flash is behind a level shifter. I've got a single Lattice Diamond build for the CPLD where I'm only swapping out the few lines of code that toggle between 5v 'external' flash, and 3v 'internal' flash including level shifter control code. So I can mostly eliminate any of the other code from being a bug source. I'm a bit miffed as to what's going on, but I'm only just now running into the new problem. While it sounds like a timing issue, I'm not fully convinced. Both 5v and 3v flash chips are 70nsec, and with the crashes being so consistently repeatable between boards/consoles it smells of a logic problem. So I'll take a break for a bit and come back later today with fresh eyes and hope for the best..

[about to click submit on this post, and the therapy of writting out the problem gives me a handful of ideas for things to check...]

I solved it! Turned out that the flash chip was getting locked up with mapper writes to $8000-FFFF which were also getting 'written' to the flash chip. This was happening to the 5v PLCC flash as well, but the 3v TSSOP flash is a completely different part with different behavior. I've seen issues like this in the past with SNES designs of mine using this same flash chip. And this is effectively the first time I'm using 3v flash on my NES design. The 5v flash has proven more 'bullet proof' being unaffected by mapper writes that also get applied to flash causing any problems, so that explains why the issue never appeared previously.

So for now my temporary fix simply ties flash /WE pin high and it plays great. But this means I can't program the flash with this CPLD configuration. I can flash the CPLD twice, but I'd rather have a permanent fix for this issue. Really what we need is an addition to mapper 28 which enables/disables writes to flash. With other bits of the mapper being required to startup high, it's best to have this bit high upon startup as well. Default setting on startup should be flash writes disabled. So "F = 1" disables flash writes, and "F=0" enables flash writes.

Tepples, do you have input on where we should put such a 'flash write' disable bit? There is benefit in not requiring further address decoding other than what the mapper already requires, so it may be best to put this in "$5000: Register select" bit 1 perhaps? This has the disbenefit of all writes to $5000 requiring the Fbit to be set effectively which I assume requires modification of the current build(s)..? It also effectively makes older versions of action53 incompatible with this board. If all previous builds default to writting '0' to the unused $5000 bits, then I guess it's not a big deal for the CPLD to invert the write so F=0 disables flash writes.

The alternative would be to add another register address specifically for this bit. But as the mapper is currently defined, new CPU address pins would be required. Adding extra pins for decoding is a big of a pain for my smaller board which we use to publish volumes which are 512KB or less. However when 1MB or more is required, the mapper has the entire CPU bus visible as they all had to be levelshifted for the 3v flash anyway.

If we don't really want (or have time) to think too hard about redefining mapper 28, I can always put in a 'back door' register which may only ever exist in this build/publishing. Maybe a register at $5555 which has to be set to 0xAA in order to enable flash writes, and any other value disables them. This would also require the register select to only decode to all values of $5000-5FFF except $5555 which might be weird but likely works. This board doesn't have PRG-RAM, so $6000-7FFF is actually open and available, maybe putting the flash write enable somewhere in there makes more sense, but the definition isn't forward compatible with PRG-RAM being added in a future volume/build. And there's the whole aspect of temporary fixes typically becoming permanent solutions..

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

I'd be willing to explore extending the A53 mapper with new register $2A exposing a flash memory control port. Then enabling or disabling /WE would look like this:


These registers would still respond to $5000-$5FFF and $8000-$FFFF like any other A53 mapper feature, but use of $5555 or $AAAA thematically matches the rest of the flash unlock sequence and would be easy to catch with the debugger.

Not sure if I want to mark it as user ($2A) or supervisor ($AA) though. It depends on whether we want to built in a self-flash mechanism analogous to that of so-called UNROM 512.

Ahh yeah adding another 'internal' register "2A" should work which makes more sense for the design of the mapper. I'll test that out to confirm I don't have a conflict somehow during there for my flash routines.

For a quick fix, earlier I required $5000 bits 6-1 to be set to "101010" in order for writes to $8000-FFFF to get applied to the flash and everything including erasing, flashing, and playing was working great.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

So thinking about this more closely as I'm trying to implement it, there's a number of ambiguities with things getting complex quickly.

So for the $5555 register, is that the only specific address where bits 6-1 of the select register stick? Or can you write 0x2A to any address $5000-5FFF and it has same effect as writes to $5555?

Similarly, does the write to the 'flash enable register' have to occur at $AAAA, or can it be anywhere in $8000-FFFF? I'm assuming it must be $AAAA specifically.

If I understand your code correctly, some modifications would be needed:


I do think there's value in simplification where possible so long as protection is adequate as there's been several mentions of interest from compo entries to utilize flash saves. But to be honest the complications here are quite significant and even I have a hard time wrapping my head around all this. It gets even further complicated by not really knowing what part number will be used for the game. 128-512KB, 1-2MB, and 4MB+ all have different address/command pairs, different expedited flash algorithms, and the board design may change in the future. 128-512KB flash doesn't even require flash write protection. The creator of a compo entry can't know any of those details in development. And even if they do, we may use a 512KB flash for that individual compo release, and a 8MB flash on a future multi-volume mass compilation. It's unlikely devs will be interested in updating their entry to support the new board config year(s) after the fact.

So I guess what I'm trying to say is for right now, the specifics of what we implement for this flash shouldn't really matter for the future. I'm suggesting we don't even publish the solution we use here in the wiki. It's only real purpose is to allow me to manufacture this volume's cartridge.

In the end if we want to provide flash save option to future compo entries, I think it's best to abstract away the actual flash save algorithm completely. There are a few ways we could do this, which is probably a discussion for a different thread. But one idea would be to define mapper 28 CHR-RAM as battery backable. In practice though, the action53 menu rom could have helper functions present at $6000-7FFF which transfer CHR-RAM data to/from flash instead of actually placing a battery on board. Or maybe we just avoid all the hassle and drop a 32KByte battery backed SRAM on the board and give each entry 128-1024Bytes of save RAM. IDK what's best, but the complexities of entries writing directly to flash may never be reasonably within reach..

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers