Request for new mappers

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

User avatar
infiniteneslives
Posts: 2102
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Request for new mappers

Post by infiniteneslives » Wed May 31, 2017 12:37 pm

tepples wrote:
infiniteneslives wrote: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.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2033
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Request for new mappers

Post by FrankenGraphics » Wed May 31, 2017 12:54 pm

Super Game Boy, Super FX GSU, and SA-1 say hi.
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?
http://www.frankengraphics.com - personal NES blog

lidnariq
Posts: 10264
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Request for new mappers

Post by lidnariq » Wed May 31, 2017 1:25 pm

infiniteneslives wrote:since it's not random access
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.

Oziphantom
Posts: 1080
Joined: Tue Feb 07, 2017 2:03 am

Re: Request for new mappers

Post by Oziphantom » Wed May 31, 2017 11:36 pm

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 ;)

calima
Posts: 1304
Joined: Tue Oct 06, 2015 10:16 am

Re: Request for new mappers

Post by calima » Thu Jun 01, 2017 1:38 am

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

User avatar
infiniteneslives
Posts: 2102
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Request for new mappers

Post by infiniteneslives » Thu Jun 01, 2017 9:34 am

Oziphantom wrote: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
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..
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

lidnariq
Posts: 10264
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Request for new mappers

Post by lidnariq » Thu Jun 01, 2017 10:49 am

calima wrote:Zlib is a standard feature of many processors and MCUs.
{{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

calima
Posts: 1304
Joined: Tue Oct 06, 2015 10:16 am

Re: Request for new mappers

Post by calima » Thu Jun 01, 2017 11:46 am

lidnariq wrote:
calima wrote:Zlib is a standard feature of many processors and MCUs.
{{citation needed}}
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.

calima
Posts: 1304
Joined: Tue Oct 06, 2015 10:16 am

Re: Request for new mappers

Post by calima » Thu Jun 01, 2017 11:58 am

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

User avatar
MottZilla
Posts: 2835
Joined: Wed Dec 06, 2006 8:18 pm

Re: Request for new mappers

Post by MottZilla » Thu Jun 01, 2017 3:26 pm

Oziphantom wrote: 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.
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.

Oziphantom
Posts: 1080
Joined: Tue Feb 07, 2017 2:03 am

Re: Request for new mappers

Post by Oziphantom » Thu Jun 01, 2017 11:56 pm

infiniteneslives wrote:
Oziphantom wrote: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
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..
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 ;)

User avatar
infiniteneslives
Posts: 2102
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Request for new mappers

Post by infiniteneslives » Fri Jun 02, 2017 12:48 am

Oziphantom wrote: 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

User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2033
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Request for new mappers

Post by FrankenGraphics » Fri Jun 02, 2017 1:19 am

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.
http://www.frankengraphics.com - personal NES blog

calima
Posts: 1304
Joined: Tue Oct 06, 2015 10:16 am

Re: Request for new mappers

Post by calima » Fri Jun 02, 2017 1:48 am

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

Oziphantom
Posts: 1080
Joined: Tue Feb 07, 2017 2:03 am

Re: Request for new mappers

Post by Oziphantom » Fri Jun 02, 2017 3:41 am

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

Post Reply