nesdev.org

It's been a month. Is there any news? =)

MottZilla wrote:It's been a month. Is there any news? =)

Thanks for pinging me on this. Unfortunately illness has dominated our household over the past month so it's been a challenge to make significant progress. Good news is we seem to be operating near 100% now Jim's cool did hook me up with a CIC build that is working on about 20% of the attiny13's I pop out of the tube brand spanking new. I've found the same results on 3 different lots of parts and both SOIC and DIP packages. So something funky is going on shortly after startup/reset. He's had some obstacles of his own, so I started trying to debug it myself starting fresh from the disassembler. Worst case I'll pick up where he's paused, this being my top project at the moment.

I have successfully tested TNROM. Still want to try some other more obscure MMC3's in the future but not very high priority.

Not top priority, or release limiting but I've yet to pop my version of the MMC1 on to it yet but don't expect much issues (or high demand) from MMC1.

I did dig into MMC2/4 a little while back for the first time. One of those things I always assumed was more complicated than it actually is. Really they are probably the simplest of all the MMC's IMO. It'll require a little wire jumpering to gain an input from a NAND gate to sense the CHR addr lines with few I/O. So at some point I'll ensure support for these as well. Best solution for these will be on a second PCB version that has connections for a discrete NAND gate removing the need for jumpering. I'll probably do the same to remove Sunsoft-5A jumpering on the Synth.

I've actually ignored the discretes thus far except the multi-discrete for the bundle. I do have a minor issue with PRG A13 on the PCB, but I can fix this by hand and will make sure to cover it for the next version.

Sorry more of a TODO list than an update list... But really the only thing holding back release at this point is the CIC. MMC3 is the priority here due to lack of availability anywhere else. The next step after that is setting up a wiki to help document the numerous jumpers so it's easier for people to use. But the wiki will most likely be in tandem with the release or motivated by user demand.

If anyone's aching for a board and doesn't care about the lack of a CIC I'll entertain the idea private requests. The prices throughout have been consistent, and still stand the the time being.

I have a toploader NES, so I don't need the lockout chip, so I ordered a couple boards and recently tried them out. So far, they're awesome!

I made Final Fantasy III and Mr. Gimmick, and the process was flawless. No rewiring, just soldering in the appropriate chips and being on my way. I had a couple broken games with chips I could use, so I used the parts from there, and I now have complete working brand new repros!

So far, the games seem to work great. No noticeable glitches or crashes. I'm definitely buying more boards later on

Glad they worked out for you snoopkatt, thanks for being one of the guinea pigs

Things are going pretty well with these. Thanks to Jim's cool CIC "tennis" I've decided to put these in a 'beta' release of sorts. NTSC is the only confirmed region at the moment. Working to confirm other regions right now. Still have some testing to do for mapper configs including MMC1 and a few others. But I've tested a fair number of MMC3 games with great success including clone consoles. I've also been able to make test out some simplifications to keep costs down where possible. Things like TNROM for FF3 can be minimized down to ONE larger 72Mcell CPLD. From what I can tell the game never actually uses the bankswitching available on the 8KB of CHR-RAM so that simplified things greatly to allow only one CPLD to be used.

The large part of my first order has been spoken for or is already out there in use. So I'll be ordering the second batch soon correcting things like the polarity issue on the battery. Any units shipped with the error I've just corrected by hand and included the battery clip at no charge. I'll also be changing things like moving the surface mount caps/resistors to the top of the PCB and other minor things that simplify assembly and removing some jumpers I've deemed unnecessary. My plan is to stay as the 'beta release' until I get the second shipment of boards up and running. Just email or PM any requests directly for now, and be patient while I assemble/test it specific to the order.

I still haven't quite decided the best way to make things easy for configuration and assembly while still keeping things relatively easy and simple for me to produce. While still in beta release I've decided to handle each order as a 'custom' order where you can specify exactly what you're looking for and which options you'd like. Based on what seems to work best on this beta release I'll decide what options to provide in the future. Things could be as basic as mapper/CPLD and it's power supply alone, or as complete as mapper, CIC, discretes, battery, & SRAMs (all but ROMs).

I'm also realizing how much of a pain EPROMs can really be... So I'm planning to have a second version once this first EPROM/(and other DIP memory) version is in fully released. The second version will probably ditch through hole components completely and might slim down the board as well. The goal with version 2 would be to use SOIC Flash memories which are actually cheaper than EPROMs and have a LOT less headaches. The only challenge is programming since I'd actually plan for these to come FULLY populated including ROMs. Only selling them as fully populated will allow me to load them up with a test ROM to verify everything and hopefully reduce chances of problems for the end user. So to program them I'll be using the kazzo like/compatible hardware with my own software and firmware. Some extra programming signals will be routed through the EXP connector and/or an additional 'side' connector for programming things like the CPLD and CIC most likely. Basically this would be more of a 'plug and play' version that only requires a computer and kazzo to create repro/homebrew games. No worries though, I plan to continue to offer the rev1 'EPROM' version after rev2 becomes a reality for those who still want to do everything themselves. That and the rev1 will be better for hacking/prototyping for people who like to do things like make their own multicarts and are savvy enough to overcome hardware challenges themselves making use of the perf area.

I was hoping for an update from you soon. Good to hear things are progressing. You did say that MMC2/MMC4 would eventually be supported right? I wonder if that might only need 1 CPLD since it's relatively simple as far as mappers go. And I forget if you mentioned if down the line you planned on supporting the Konami VRC series at all. I'm glad you got the CIC worked out now.

MottZilla wrote: You did say that MMC2/MMC4 would eventually be supported right? I wonder if that might only need 1 CPLD since it's relatively simple as far as mappers go.

Yeah MMC2/4 is next up after I verify MMC1. I've already written up and tested MMC1 on the NESDEV1 so that one shouldn't be an issue. The MMC1 will fit on ONE CPLD. The FULL MMC1 will take a larger 72mcell CPLD, but something like SNROM fits pretty well inside a smaller 32mcell CPLD last time I compiled it due to only having 8KB CHR.

I haven't written up MMC2/4 yet, but you're right it is pretty simple and shouldn't require much logic. I'm expecting that it'll fit in a smaller 32mcell CPLD. But I'll also be using an external set of AND gates to reduce the number of inputs (and simplify signal routing/jumering) on the CHR address lines to sense $FD/$FE.

And I forget if you mentioned if down the line you planned on supporting the Konami VRC series at all.

I haven't mentioned the VRC series yet, but it's definitely something I'd like to do down the road. I'd also like to see some NAMCO and such. Only issue with some of those is I won't be able to get any sound extensions inside the CPLD due to the massive amount of logic that'd be required. Stepping up to the Mach-XO2 CPLDs would solve the logic demands but not sure if I'll ever put synth re-engineering high enough on my priority list to make happen There are always external synth options but the 8910 for the sunsoft-5B is the only one that appears to be an option for this route.

I've got a few other plans revolving around making my own mapper that is tailored to my boards that'd be a mmc3 improved hybrid of sorts. That's a little more fun to work on so I'll probably try to tackle that project first before working on some of the more obscure FC only mappers.

infiniteneslives wrote:The MMC1 will fit on ONE CPLD. The FULL MMC1 will take a larger 72mcell CPLD, but something like SNROM fits pretty well inside a smaller 32mcell CPLD last time I compiled it due to only having 8KB CHR.

Would something mostly compatible with SUROM fit on the smaller one?

not sure if I'll ever put synth re-engineering high enough on my priority list to make happen

Especially since it has been discovered that the logic to get the synth doing anything on a 72-pin deck would cause audible jitter at every OAM DMA.

tepples wrote:

infiniteneslives wrote:The MMC1 will fit on ONE CPLD. The FULL MMC1 will take a larger 72mcell CPLD, but something like SNROM fits pretty well inside a smaller 32mcell CPLD last time I compiled it due to only having 8KB CHR.

Would something mostly compatible with SUROM fit on the smaller one?

Yeah it'd be close, any extras may take it over the top. If one was modifing the MMC1 and wanted to minimize logic the best thing to do is cut out the serial writes (granted it's not much of a MMC1 after doing that though). The counter and extra shift register sucks up quite a bit of logic. The MMC1 minimized pinout but that's not much of a limitation with these CPLDs. You're better off to handle the register writes in more of a MMC3 fashion since pins are abundant and logic is not if you're trying to cut cost.

infiniteneslives wrote:If one was modifing the MMC1 and wanted to minimize logic the best thing to do is cut out the serial writes (granted it's not much of a MMC1 after doing that though). The counter and extra shift register sucks up quite a bit of logic. The MMC1 minimized pinout but that's not much of a limitation with these CPLDs. You're better off to handle the register writes in more of a MMC3 fashion since pins are abundant and logic is not if you're trying to cut cost.

In other words, it'd be a good idea to mapper hack games developed for MMC1+CHR RAM to use the multi-discrete mapper that we worked on. The layout of port $80 is even (intentionally) similar to MMC1's register 0.

infiniteneslives wrote:The counter and extra shift register sucks up quite a bit of logic.

You can cut the counter by increasing the length of the shift register by one. Rather than having a counter that counts from 0 to 4, instead have a six-bit shift register that's preloaded with 1, and when the MSB is set, load.

I don't know if that's enough, though.

(Also, sorry if I'm telling you something you already know)

Technically, you need only a 5 bit shift register.

Reset: 10000
Shift bit A: A1000
Shift bit B: BA100
Shift bit C: CBA10
Shift bit D: DCBA1
Load bit E: Don't shift. Take bit 4 from D0 and bits 3-0 from shift register bits 4-1, then reset the shift register.

But perhaps even this logic requires too many macrocells for intermediate results. Is there a "disassembler" of sorts in the Verilog compiler that tells exactly what each macrocell is doing? Perhaps this might help fill us in on the difference between the 25 flip-flops required for the MMC1's architectural state and the size on the CPLD.

That's not a bad idea, I'll have to give it a try and see how much logic it actually saves. I haven't really revisited my MMC1 design since I made it almost a year ago. It was my first ASIC to re-create so it's fun to look back at my old 'noob' code.

I used a 4bit shift register and 3 bit counter. So should be around 7 macrocells based on number of states.

Ditching the counter for an extra bit in the Shift reg would presumably cut it down to around 5 macrocells. More logic can also be saved if you allow consecutive writes from RMW opcodes.

As for a disassembler type thing I'd have to check my text file outputs from synthesis (aka logic compilation). That's where you'd find that kind of data if it is available. Honestly though the best way I've found is to actually compile the thing for the target device. I've ran into some weird issues and found that most of my designs save a few macrocells if I optimize for speed instead of density. Kinda messed up, but based on the other xilinx webpack issues I've seen I wasn't that surprised...

My point was really to cut the ~5-7 macrocells for the input shift register completely buy utilizing easier and faster parallel direct register MMC3 style writes if you're already making a custom mapper. The I/Os are there, may as well use them if they're saving you logic for a 'non-standard' mapper. You could also stay serial and shift writes directly into the final register based on A13/14 instead of only watching the last write. You m ight even be able to do this with many licensed games assuming they don't put the bankswitching code in the bank that's disappearing post bankswitch. This would also rely on start up proceedure, resets aren't really needed when you've got known start up register values. I think some games like to 'prime' the MMC1 which wouldn't work out so well.

For my custom mmc3 hybrid mapper I went as far as restricting ranges of the banks. This makes a lot of sense for CHR especially if you keep sprites and bg tiles in segregated pattern tables which makes sense anyways based on NES limitations. Those assumptions allow you to cut a few bits from each register, and when you've got several registers the savings adds up.

infiniteneslives wrote:This would also rely on start up proceedure, resets aren't really needed when you've got known start up register values.

After the player presses the Reset button on the Control Deck, there's not as much faith in the register values, unless perhaps you're using loss of oscillation on M2 to reset the mapper.

For my custom mmc3 hybrid mapper I went as far as restricting ranges of the banks. This makes a lot of sense for CHR especially if you keep sprites and bg tiles in segregated pattern tables which makes sense anyways based on NES limitations. Those assumptions allow you to cut a few bits from each register, and when you've got several registers the savings adds up.

You might not necessarily have segregated sprites and background tiles if you map the same bank into banks 0 ($0000) and 5 ($1C00-$1FFF) so that objects can transition from being in the background to being sprites and back without tripping up the scanline counter. I remember recommending this to tokumaru. But another thing that saves flip-flops in an MMC3-alike is to design it for CHR RAM. Just restricting the range to the 32K in a 62256 CHR RAM saves 18, and hardwiring all CHR banks but banks 1 ($0800-$0FFF) and 2 ($1000-$13FF) saves even more.

tepples wrote:You might not necessarily have segregated sprites and background tiles if you map the same bank into banks 0 ($0000) and 5 ($1C00-$1FFF) so that objects can transition from being in the background to being sprites and back without tripping up the scanline counter. I remember recommending this to tokumaru.

And it was a very good recommendation. I'll definitely do this when I make an MMC3 game.

tepples wrote:

infiniteneslives wrote:This would also rely on start up proceedure, resets aren't really needed when you've got known start up register values.

After the player presses the Reset button on the Control Deck, there's not as much faith in the register values, unless perhaps you're using loss of oscillation on M2 to reset the mapper.

yeah it's not really a great idea, more of a frugal one.

tepples wrote:

For my custom mmc3 hybrid mapper I went as far as restricting ranges of the banks. This makes a lot of sense for CHR especially if you keep sprites and bg tiles in segregated pattern tables which makes sense anyways based on NES limitations. Those assumptions allow you to cut a few bits from each register, and when you've got several registers the savings adds up.

You might not necessarily have segregated sprites and background tiles if you map the same bank into banks 0 ($0000) and 5 ($1C00-$1FFF) so that objects can transition from being in the background to being sprites and back without tripping up the scanline counter. I remember recommending this to tokumaru. But another thing that saves flip-flops in an MMC3-alike is to design it for CHR RAM. Just restricting the range to the 32K in a 62256 CHR RAM saves 18, and hardwiring all CHR banks but banks 1 ($0800-$0FFF) and 2 ($1000-$13FF) saves even more.

Yeah your solutions were mine as well. That and your idea of a bullet proof scanline counter that senses CHR A13 should resolve that issue as well, while saving even more logic. CHR ROM really doesn't make much sense for homebrew use when large parallel SRAM and large serial flash is dirt cheap.

On a related note, another interesting thing I realized a while back is 128KB SRAM is actually cheaper than 32KB SRAM when buying sizable quantities. So I'll actually be moving to 128KB SRAM even if it's not all useable under typical configurations...