Request for new mappers

Adding in a VIA/CIA style timers on the IRQ would be really nice. Even if its just 1 16bit timer and a TOD.

The 6525 is hard to find, let alone in large quantities. What is the benefit of this timer (not counting the additional circuitry for i/o operations)?

I was thinking the timers would be emulated in the CPLD/FPGA, rather than drop a 6526A ( you would need the 2Mhz version + extra circuit to drop the CPU clock down to a 50/60hz signal ) on the board.

TOD is useful for doing things like Make X happen in 5 seconds, or 10 minutes. at 50fps 5 seconds is 250 frames, 60fps 5 seconds is 300.. 5 minutes at 50fps is 15,000 and 60fps is 18,000. So having a TOD to do the counting keep the times locked when porting regions. Could be shown in game to aid Speed Runners, or you can use it time various aspects, destruction countdowns, round times, quest timers etc and change things like difficulty, or make items drop to change the game play on extended play sessions.
Show a on-screen msg for a second, like when you enter a town in a RPG or damage.

Timers have a lot of uses, for extra note timings in music engines, for generating random vales based upon button presses, you can use 2 timers where 1 is an inverted cycle counter to get stable rasters. You can even execute code in the Timers to jump to timer routines to get 100% super stable , you can use them to profile your code more accurately, you can use them to see how much frame time is left and to make calls on if you update things or not for frame time management.

You can use the Timers to act as a separate thread, in that you normally have a NMI and Main, you can get a NMI, IRQ and Main threads.

I'd like 4kb bankswitching granularity, for 4+4+4+4 and 16kb fixed. Also, a hardware zlib decompressor chip.

Hmm.. would something like this suffice? 0,6-0,5 eur / piece depending on quantity. Might be cheaper (or more suitable*) things out there. http://www.mouser.com/ds/2/302/PCF85063TP-842236.pdf

*Several channels of timers ticking in seconds (or fractions) would be more pragmatic than a ss:mm:hh:dd:mm:yy format. Depending on the application, of course. In any case, i'd look for timer chips with low power consumption, usually meant for mobile devices like cameras and what not.

Keeping intervals consistent across TV systems can also be done entirely in software. A couple of my games divide NMI by five or six depending on TV system, producing an internal timer that ticks every tenth of a second. (In Thwaite, see uses of gameTenthSecond and gameSubTenth; in RHDE, see uses of time_tenths and time_subtenths.) The resulting values of current decisecond and current frame within decisecond let me schedule updates that happen 5 or 10 times per second, spreading out the work load across multiple frames. Both games assign periodic 10 Hz tasks for frames 0, 1, 2, 3, and 4 of each tenth, with nothing scheduled for 5 because PAL.

As for making the name of a town appear and disappear, Thwaite does something similar, making "tips" disappear after fifty tenths. (See uses of tipTimeLeft.) RHDE does something similar for alert boxes between rounds. (See uses of delay_y_tenths.)

As for music timing, these games use the Pently music engine, which adds rows-per-minute to a 16-bit counter and compares it to 3606 on NTSC or 3000 on PAL. (See uses of pently_rows_per_beat and tempoCounterLo.)

And just as The Simpsons already did it in western animated sitcoms, Super Mario Bros. already did it on NES. Speedrunners of that game and Super Mario Bros. 2 (J) are familiar with a 21-frame counter that schedules parts of the engine to run, which is why a new run for most levels must be 21 frames shorter than the previous run to make any improvement. It gets shortened to 18 frames on PAL.

Well the RTC could probably stand in for a TOD, although that one doesn't have the full Alarm set ( its has minute and 30seconds ) and pulses the IRQ pins, rather than waiting for latch means you would need extra management to avoid a double trigger.

That being said WDC do still make PIA and VIA, sadly they no longer make CIA but ACIA which are not as useful for this case(no timers no TOD ). Pricey though, but come in DIP http://www.westerndesigncenter.com/wdc/w65c22-chip.cfm you could re-purpose the 2 8bit Data Ports one for PPU banking, and one for CHR banking. This would give you read/write registers you could use to control what the current banks are.

I'm not sure DIP is an advantage here though. It's great for one-off projects and mods or socketed swapables, but SMD:s are generally faster even at home (unless they're too small), and you'd want to reduce the time manual labour takes. 8 dollars is pricey (as you said) if you just want the timers, but if you can use the rest, it might be worth it?

How about a second 6502 type CPU at 20mhz with shared RAM to communicate with the NES CPU giving you all the computing power you could want. The NES CPU would just be the middle man between the NES I/O and the much faster on cartridge CPU. Or use whatever kind of CPU you want and do the same thing. Use the audio input and connect whatever audio hardware you want too.

There are lots of low cost (<$1) microcontrollers with a built in RTC. A little glue logic may be needed, but one could set up any number of simple/complex timing IRQs if an mcu is handling the task.

You could, but what about cost per board? You'd essentially build a single board computer with fixed software. That doesn't sound consumer friendly.
EDIT: i see W65C02S goes for 5,89 EUR per unit for a batch of 100.

Super Game Boy, Super FX GSU, and SA-1 say hi.

Stuffing a 6502 core into a cheap FPGA is probably cheaper than getting a new 6502 in silicon :/

If you just want a Programmable Interval Timer with a very long count, you might just use the design of the broken one inside the original 2A03.

—
A hardware decompressor doesn't really make sense to me. You'd have to implement it in an FPGA, so you'd have to add 3V translation. Once you've added 3V translation you can get large parallel NOR flash for cheap, and huge Guaranteed Good Die parallel NAND flash for roughly the same. And at that point the challenge becomes "making enough content" rather than "how do I compress this data to fit in a small ROM"

That said, the idea of grafting an SA-1 into an NES still amuses. The S-DD1 is architecturally incompatible, though.

Or skip majority of parallel level translation and put it data in dirt cheap serial flash which gets copied into PRG-RAM for execution.

Booting how? What's your current plan toward this?

There are any number of ways boot could be handled. Simple solutions could include a small parallel 5v rom, or battery backing the SRAM. Exotic choices might include a boot rom in a CPLD, or since it's not random access a fast mcu could act as a boot rom by itself or via glue logic. I was just offering up an alternative to avoiding a several finely pitched level shifters if one were to consider a design with lots of data.

Not sure how my plans are pertinent to the convo, I'd have to say it depends on a number other design goals.

Very true. But all these benefited from SNES being mass culture for families. What can be considered a viable production cost per unit today?

But a computer on a cart might still be more viable than something plugged into the expansion port, even if it's a bit wasteful on resources?

Two SQI EEPROMs. Because initial fetch order is completely deterministic, all we "have" to do is inject a few command writes to the EEPROMs to start fetching bytes at a specific address; after that the deterministic sequence of bytes on the bus could copy a small bootloader into RAM.

You guys...

I ask for a couple of itty bitty timers tucked away in the corner of your fancy FPGA/CPLD based designs you seem to muse about on here, and suddenly its all ZLib decompression chips and a SUPER CPU XD

I don't even now how a Zlib decompression chip would work, I mean you probably could blow a FPGA on making one, but why? Also use exmoizer, its smaller and faster but doesn't give as good compression but runs alright on a 6502

With out the DMA/BA pin on your 6502, doing a Super CPU in the cart is going to be tricky, you can keep a CPU in it, but how are you going to get data where the NES CPU can see it? I guess you could send an IRQ to the NES CPU, it then writes to say it got the IRQ, then you bank a chunk of RAM into its address space with code for it to run.... VS system style.

tepples : what are your thought on polling vs Events. Seems for your post you are in the Polling camp, I prefer events as they cut back on spaghetti. Typically I make what I call 4 Byte Event Timers(4BET) which are value latch ptrLo ptrHi then you have 3 Byte One Shot (3BOS) value ptrLo ptrHi this allows me to make a single loop that updates them all, and let the assembler work out the size for me and auto update the "update" function. Overall I feel it saves me RAM, but in the NES case, it probably cost more RAM, but would free up ROM.

While one can store NTSC timings and PAL timings, I imagine few would, and my recollections are very few did even back in the commercial days, I would think that the "for fun", "works on my machine" hobby programmer would be even less inclined, while having it hang off hardware timers that can have a simple "check machine version, adjust bit" that people can copy paste into their boot code, would make it more common

Why would a FPGA be needed? Zlib is a standard feature of many processors and MCUs.

A TOD/RTC counter isn't a small counter in relation to the size of typical NES mapper counters. And from a practical standpoint, that style of timer isn't well suited for a small CPLD, it does help a little if you add a 32Khz clock to the board though. It's more practical/cost effective to off load a timer like this into a mcu that has a RTC built in.

If you're genuinely interested in having a timer of this nature available on a board it's certainly possible on a budget. But it becomes a bit of a chicken-egg problem. Detailing how the timer works exactly should be dependent on the hardware resources being made available. On top of that you also have the task at hand of creating emulator support, and there's currently no software written for this idea of a timer. These are all the hurdles that have to be overcome if you want to realize your idea.

Perhaps it's best to focus the discussion on how a mapper request becomes reality before getting too deep in what specific hardware could be used to meet the goals. Discussions focusing on specific hardware has a tendency to go off the rails pretty quick in these parts as you've found..

{{citation needed}}

Unless you mean "just add a fast 5V capable CPU and do it in software" in which case:
1- Why only do decompression in the coprocessor
2- Why write a game for the NES if it's not running on the 2A03

Various ARM cores from AMD, NXP, and Cavium have that in a quick google. Some Xeons do. I couldn't find the MCUs right now.

Nothing for the MCUs, I do remember reading it as a bullet point, but perhaps it referred to an optimized library by the manufacturer.

Since none of this is likely to ever exist, how about some dual ported RAM? So both your super CPU and NES slave CPU could see the same RAM. And then go another step by having more dual ported RAM for the NameTables so that the super CPU's program has direct access to the NameTable memory allowing for potentially complete NameTable updates each frame if the CPU is fast enough. That leaves the NES CPU with the tasks of NES Audio, Controller Reading, Sprite DMA, and letting the super CPU know when NMI/VBlank happens.

Through dual ported RAM you could communicate whatever you needed between the two. You could basically use the NES for its Audio and Video capabilities and have insane computing power and memory to do whatever you could want.

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 seconds yadda yadda
TOD - in the CIA case takes a 50 of 60hz signal ( aka 1 half of an AC line ) and basically does the following
5/6 counter which then feeds a 10 counter which then feeds a 60 counter which feeds a 60 counter which feeds a 12 counter which feeds a 1bit flag.
While the 6526 stores them in BCD, as the NES doesn't have BCD this would be stupid Also I guess it uses Chuck's and Menches's fancy BCD tricks, and hence nobody could clone it and hence only Commodores have the 26, while the rest of the world used knock-off Rockwell 22's
This make its a
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.
Again for the NES 12hrs and AM/PM nobody is going to be playing that long, dropping it to a 2 bit counter for 4hrs would be overkill. When people do DC only mods of C64s they use a tiny MCU to make the 50/60hz clocks, 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. To which you could get it to even do the 1/10th a second counter and ditch the 50/60 difference as the NES will never need to see it.
This drops you to an 18bit counter with custom carry logic. 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

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.




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?



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.


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.


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.

RTC:s are cheap, so that's at least good. They can be used as a method for seeding a randomizer algorithm or provide seasonal changes to a program based on realworld time or trig unlocking hidden bonus content, or provide the player with time since last save/play, etc.

A Pokemon/Harvest Moon/Animal Crossing-style clock wouldn't even need to be a RTC, just a monotonic clock.

I guess the issue is its neither a call to get a mapper 260 with X made for game Y, or a call to lets talk about what would be nice to have in a mapper.

It a call to have mappers add timers as standard, to put it on the radar so to speak, if one looks in the NES's toolbox, timers are the glaring omission compared to other contemporary machines. To which I'm not calling for a strict concrete example, I've just said 6526/22 style to give a concept of what a kind of timer I mean as they are found on pretty much every 6502 based and some non 6502 based machines. I.e 16 bit timers with one shot or continuous mode, a force latch, maskable interrupt generation,and the ability to count underflows of a paired timer to get 32bit timers. It is just in your new larger fancier mappers, tuck some timers away in the corner they are great "get out of gaol free cards", that allow you to add things quickly with minimal code complexity. The cycle counters basically can't be done at the moment to my knowledge, some have H PPU based counters, but I don't think any have cycle counters. TOD is a nice to have, but not really worth that much effort, although having one that just ticks, so whether you are in pause, or have the screen turned off because you a building data and need more transfer, and then adding extra flags to make sure it does get called each frame, or you switch out your NMI so that it does get updated etc. adds code complexity, adds overhead, or you just set the timer to X, and wait for the interrupt.

But as you say I should provide more resources
6522/26 based timers are documented http://archive.6502.org/datasheets/mos_6526_cia.pdf
Source code for Emulator writers to crib can be found here (GPL) https://sourceforge.net/p/vice-emu/code ... /ciacore.c
https://sourceforge.net/p/vice-emu/code ... ciatimer.c
https://sourceforge.net/p/vice-emu/code ... ciatimer.h
And both emulator and hardware test code can be found here https://sourceforge.net/p/vice-emu/code ... progs/CIA/

Although I more imagine that they would be fitted around your current registers set rather than having a strict binary comparability with a 22/26

How about coming up with a standard for an expansion port device?

criteria:
-needs to fit inside the expansion shell or elsewise not add to the dimensions of the unit.
-include a utility timer
-include the audio bridge
-other things while at it? i/o handling? port forward?
-maybe: open standard; anyone may reproduce it?

this way, you only need one device for several "augmented" programs, more applications are likely to use it vs. this mapper has this benefit but that mapper has that benefit.

In other words, exactly what incGameClock and update_game_time do. I'm just trying to find the most resource-efficient way to handle TOD, particularly balancing CPLD resources against CPU RAM and PRG ROM.


The alternative adds code complexity to the CPLD. There's no free lunch, but if you can delay it to 2 PM, there are sliders at Arby's.

And a clock for something like Animal Crossing would need to be an RTC, or at least have the accuracy of one, in order to keep the game's day/night cycle in sync with the player's. Harvest Moon with its two orders of magnitude speedup would need TOD that pauses in buildings.

Noted. The hurdles of creating the mapper definition, test rom, emulation, and software targeting said mapper are still what's keeping it from going anywhere besides on the radar. FWIW, I already have hardware/board designs that can support what you're asking for, but having the hardware on the board is the easy part. Takes effort to get over all those hurdles. I've started to make it a goal of mine to allow the hardware on my designs to be configurable by the end user. I've got a lot of work ahead before I can meet that, but the first steps have been taken. End goal is some tutorials that help devs get started with mapper development if they'd like, allowing them to bypass the board design steps.



A standard is fairly worthless till someone scrounges up somewhere on the order of $10-40k for a run of connectors that fit in the exp port (assuming you're talking frontloader NES.)

Just to make sure we're starting from the right page... when you say "cycle counters", do you mean the same thing that we do in this page ?

FWIW Sunsoft's FME-7 with 16bit CPU cycle counter is the most popular/available of all those choices.

When I saw them originally I saw the MMC3 references, which made me think they had some PPU based link, but ignoring it,looking at the more obscure ones they are strict CPU cycle timers/counters the FDS has a timer, but others have counters, but are actually timers and some are counters just rather limited ones.

Is the Namco 129 available?

Sidenote is there a reason why most put the registers under the ROM? And not below the ROM area?

I think Animal Crossing would need a RTC so it Knows it is Christmas, on Christmas to do the special event. Harvest Moon is in "fairy" time and I don't think even a pause-able TOD would be helpful

Two things come to mind...
1) it's ROM, so there's no reason to not have a read-only and write-only function overlap
2) the NES doesn't provide access to CPU A15, just CPUA15 NAND Φ2, so it's electrically simpler to not have to compensate for the timing difference between Φ2 and CPUA15 NAND Φ2

Explicitly looking for a readable one timer? I think that's the only one.

I don't know of a reproduction for it, because the wavetable synth portion uses a enormous number of bits of state.

well in case of 2, fair enough.....


Looking at the wiki the Namco 163 = 129 + sound port, so the 129 is the same as the 163 only it doesn't have the sound chip? The 163 audio is also on the 129, just the 163 has an extra 128bytes of RAM for audio
R/W + Latch is the holy trinity, but the NES seems to be a "pick 2" system

The 129 is "just" a buggy version of the 163. It doesn't have a functioning wavetable synth, but is otherwise identical.