I think perhaps the difference between a TOD and an RTC is being missed..
RTC is very complex, leap years, day counters, knowing how many days are in a year, adding leap
No it's not being missed, I just didn't fully explain that it's relatively easier to get an mcu with RTC, than create your own TOD.
TOD - in the CIA case takes a 50 of 60hz signal ( aka 1 half of an AC line
) and basically does the following...
Where is your 50/60hz signal coming from?? Dividing 1.79Mhz by 15? That'll consume 15 logic cells, and result in uneven numbers which could be a pain. Or are you going to clock manually each NMI?
3bit counter + 4 bit counter + 6 bit counter + 6 bit counter + 4 bit counter + 1 bit.
so its a 24bit counter with special carry and reset logic.
That's a big counter by typical NES mapper standards. But sure its plenty possible to put in a cpld that's capable of an MMC3 scale though.
I was thinking you could probably get what ever you use to do the CIC do to it, MCU typically have a timer that pulses a port pin.
That's what I was suggesting as well, a medium sized $2-3 CPLD isn't needed if you just want a slow timer of this nature. Implement one in a cheap mcu, pick one with a RTC to make it even easier. RTC isn't necessary, but it'll certainly help if it at least has a it as a built in low speed oscillator and big counters though.
Seeing as people talk or large almost FGPA level CPLDs from Lattice and Altera I'm not seeing this as being costing the Moon gate wise, but I could be wrong. However if it was 16bit timers with the ability to bolt them together, or TOD, 16bit timers with bolt hands down. Hardware timers are handy, TOD is nice
I'm not sure who was saying a counter of this nature would cost an absorbent amount, maybe I haven't been reading closely enough.
I guess the thing I don't understand is what type of application this slow counter would serve that makes it so much nicer than implementing a simple counter in SRAM being incremented each NMI for the low cost of a few bytes and cycles.
Perhaps the point/goal of your thread was misunderstood. I think people saw it as a general, wouldn't it be nice to have a mapper with feature X. And people chimed in, "oh yeah, I'd love to have feature Y & Z too". Then day dreaming of what ideas we could entertain ensued.
What I was trying to say in my last post is that if your goal is to officially request someone make this mapper for you; it would be good to focus the discussion on how to go about successfully creating a homebrew mapper. Traditionally new mappers come about when people implement them theirselves. Or a couple people have a specific software project in mind that isn't well met by current mappers available. We'd like to help you out, but simply asking for a mapper with a specific feature isn't going to create the hardware definition, board, test rom, an emulator support that typically goes with a homebrew mapper. Especially when there's no specific software project to show that's targeting the mapper.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers