All,
This is the result of our
previous discussion about building an easy-to-use dev board, together with the further discussion in this thread. The end result of this discussion was to create a replica of the Sunsoft FME-7 mapper using programmable logic that would be backward-compatible with existing emulators and development tools.
All related specifications, code (including Verilog files), schematics, PCB layouts and Gerber Files will be provided under open source and open hardware licenses. This will ensure that all who contribute (and have contributed) have a stake in the design, and that our community can freely use the design for the betterment of the platform.
Google Code Project
NESDEV1 on Google Code
Please email
qbradq@gmail.com to request commit access.
Artifact Download Links
FME-7 Test ROM for Memory Mapping and Name Table Mirroring
Related Wiki Pages
NESDEV1 Development Cart
Sunsoft FME-7 ASIC Mapper
Implementation Task and Status
1. Specify the functional requirements of the mapper
Complete
2. Specify the behavioral model of the mapper
Complete
3. Create a test ROM for existing emulators to validate the behavioral model is compatible, and test in a variatey of emulators
Working
4. Implement the mapper in MyHDL and Verilog in a synthesize-able form
Working
5. Fit the mapper to a programmable logic device
pending
6. Implement on-board programming code for micro-controller and workstation
pending
7. Create a schematic for the development board
pending
8. Create PCB designs and Gerber files for the development board
pending
9. Construct prototype development board for testing and approval
pending
10. Create schematic for the production board
pending
11. Construct prototype production board for testing and approval
pending
qbradq, based on my reading of your excellent MMC5_NESDEV1 wiki page, it seems that one would be able to reprogram the IRQ counter multiple times per frame, thereby being able to implement a top + bottom status bar, for example.
Can you confirm that your mapper will permit this?
Does the original MMC5 do this, and if so, do any existing games make use of reprogramming the IRQ timer within a frame after it has already fired?
I do with that you could support banking CHAR-RAM though. Games that have background tile animation generally make use of banking the char address space (char-rom usually) (like Crystalis). This is an effect that I really want to put into a game. I know that one can re-write char-ram during vblank, but that consumes lots of precious CPU cycles that are better used for updating name tables.
I understand that there is a limit to what a given CPLD can do, and a cost / feature trade-off. But maybe you can keep this in the back of your mind and tinker with it later?
clueless wrote:
qbradq, based on my reading of your excellent MMC5_NESDEV1 wiki page, it seems that one would be able to reprogram the IRQ counter multiple times per frame, thereby being able to implement a top + bottom status bar, for example.
Can you confirm that your mapper will permit this?
Yes, it will.
clueless wrote:
Does the original MMC5 do this, and if so, do any existing games make use of reprogramming the IRQ timer within a frame after it has already fired?
According to documentation it does. I do not know of any commercial games that used this however. It seems like the commercial games that did use the MMC5 generally did not utilize it to its full extent.
clueless wrote:
I do with that you could support banking CHAR-RAM though. Games that have background tile animation generally make use of banking the char address space (char-rom usually) (like Crystalis). This is an effect that I really want to put into a game. I know that one can re-write char-ram during vblank, but that consumes lots of precious CPU cycles that are better used for updating name tables.
I understand that there is a limit to what a given CPLD can do, and a cost / feature trade-off. But maybe you can keep this in the back of your mind and tinker with it later?
I know, this is a major limitation of this proposed mapper. What I plan on doing is implementing what I have documented, then fitting it for a CPLD. Once I know how many macro cells and I/O pins the base design requires we can see how much more it would cost to add CHR-ROM or CHR-RAM banking.
The ultimate plan is to develop an NESDEV2 that supports more features, and an NESDEV3 that supports much larger memory spaces (on the order of 4 MB ROMs and 1MB PRG-RAM). These two designs will be even more expensive to create both in terms of logic requirements and board space. For those reasons I want to limit the initial design to basically a (very) enhanced UNROM board.
Thank you for your input! If I have learned anything throughout the past several weeks it is that what I create hardware-wise is very much a product of the community. I could not even begin to do any of this without the contributions you all have made long before I got here, and those you continue to make.
Sounds like an interesting project. However the flamed debate will come when it will discussed which features will be cut off and which ones won't....
Isn't there a way to "synthesize cheaply" the whole MMC5 chip ?
I mean this chip is over 20 years old and technology has advanced....
Bregalad wrote:
Isn't there a way to "synthesize cheaply" the whole MMC5 chip ?
I mean this chip is over 20 years old and technology has advanced....
CPLDs are cheap, but the ones designed to work in a 5.0 V environment are either much smaller (e.g. 36 to 72 macrocells) or far more expensive. FPGAs generally need a CPLD to load them at power-on. This takes time, and the CPU needs to have the reset vector yesterday. ASICs are dirt cheap in quantity, but the first unit is cost prohibitive for a hobbyist to make.
clueless wrote:
Does the original MMC5 do this, and if so, do any existing games make use of reprogramming the IRQ timer within a frame after it has already fired?
There are so few MMC5 games that it might be hard to find good examples of its features, but using several scanline interrupts per frame is nothing new, several MMC3 games did this. IIRC, MMC3 interrupts can be as close as 2 scanlines apart. So you can have up to 120 or so in the same frame. What happens in those interrupts is up to the programmer, but I don't why you couldn't have status bars at the top and at the bottom.
Quote:
I do with that you could support banking CHAR-RAM though.
I second this request. Even though you can do a lot with 8KB of CHR-RAM, you really need CHR bankswitching to achieve that "16-bit" look, with large characters and lots of background animations.
Quote:
I know that one can re-write char-ram during vblank, but that consumes lots of precious CPU cycles that are better used for updating name tables.
Even if you use all of VBlank for updating tiles, you can only update about 17 of them every frame with the fastest code possible. The "definitive homebrew mapper" should really allow more than 8KB of CHR memory.
qbradq's approach is very reasonable. Just get the MMC5_NESDEV1 working and see where the project is at. Personally, I won't be ready to start on a new game for a few more months anyway, and I will make do with MMC1 + 8K SRAM until I need more memory and more granular banking.
I am already needing more granular banking
The cheapest 5V FPGA with enough I/O pins I can find is $30 in single quantities. I am not too familiar with how FPGA's work, so I do not know what resources would be required to implement the 1KB ExRAM.
Let's just get this first draft of the HDL done and then see what we can do about CHR banking. One step at a time
Bummer, Nintendulator's MMC5 implementation does not seem to support CHR-RAM. FCEUX does.
Programs must not turn off PPU rendering? Ouch. This will cause heavy loading times, as it'll take 51 frames to fill CHR RAM 10 tiles at a time. And how do you plan on handling presses of the reset button, which can occur on any scanline? Better would be to reset the scanline counter on $FFFA (NMI vector) reads.
qbradq wrote:
Bummer, Nintendulator's MMC5 implementation does not seem to support CHR-RAM.
What the hell? Why would it do that?! Even if there aren't any MMC5 games with CHR-RAM, that's no reason for rejecting this combination...
This is similar to blocking NROM games from using CHR-RAM, or forcing CNROM games to have a 32k CHR cap.
tepples wrote:
Programs must not turn off PPU rendering? Ouch. This will cause heavy loading times, as it'll take 51 frames to fill CHR RAM 10 tiles at a time. And how do you plan on handling presses of the reset button, which can occur on any scanline? Better would be to reset the scanline counter on $FFFA (NMI vector) reads.
Yea, when I wrote the bit about never turning off PPU rendering I knew we had to find another way. That's why I posed the question in the MMC5 thread about detecting the end of the frame.
Is the NMI vector read if NMI is disabled? I'd rather have something that does not restrict the user's program architecture, flawed though it may be
As for resets I am not too worried about that. If we figure out a good way of detecting the idle PPU then the IRQ counter will hiccup on the first frame after you turn rendering back on, assuming you turn it back on mid-frame. If you wait until the end of the frame (like a good lil' coder) there will be no hiccup.
You could fool the IRQ counter by
reading name table data via $2006 / $2007. Once we get this nailed down I think that and not enabling rendering mid-frame will be the only restrictions on using the IRQ.
More and more I am thinking that a CPU cycle counting IRQ would be a heck of a lot easier to use and less prone to total and complete breakage at the hands of the program. Unfortunately VRC7 does not implement the super-the-cool SRAM features everyone's so hot about.
Wow, this really is a balancing act if I've ever seen one!
tokumaru wrote:
qbradq wrote:
Bummer, Nintendulator's MMC5 implementation does not seem to support CHR-RAM.
What the hell? Why would it do that?! Even if there aren't any MMC5 games with CHR-RAM, that's no reason for rejecting this combination...
I know, but this is definitely a challenge we'll have to face for this setup. That's why I've started on the test ROM so early
The good news is Nintendulator is not used for playing ROMs (for fun anyway
), and it has a modular mapper interface. I am looking into providing both a revised MMC5 mapper that would support CHR-RAM and an NESDEV1-specific mapper that would emulate the actual hardware mapper (for compliance testing of software).
Quote:
More and more I am thinking that a CPU cycle counting IRQ would be a heck of a lot easier to use and less prone to total and complete breakage at the hands of the program.
Exept that a program won't be NTSC/PAL compatible if you use such a counter. Not that it is a major problem though, it's true, since you usually need to do NTSC and PAL variations because of the sound.
Quote:
CPLDs are cheap, but the ones designed to work in a 5.0 V environment are either much smaller (e.g. 36 to 72 macrocells) or far more expensive.
What about doing it like the power pak : Put a 3V (or whatever it is) regulator on the cart and use pull-up resistors on all outputs ? I'm not sure how they did it for inputs but there is certainly a way.
Quote:
What the hell? Why would it do that?! Even if there aren't any MMC5 games with CHR-RAM, that's no reason for rejecting this combination...
Quote:
This is similar to blocking NROM games from using CHR-RAM, or forcing CNROM games to have a 32k CHR cap.
Well I don't know. I agree blocking CHR-RAM mapper 0 roms and caping mapper 3 roms at 32k is stupid (please don't confuse the board names and mapper numbers.... arghh I think everyone habe been doing this for years anyways).
If you look carefully at MMC5's feature, you'll see that the chip was fundamentally designed to work with CHR-ROM. Half of it's features (sparate banking for sprites and BG, ex-graphics, split screen) has been made to work with CHR-ROM, so that games could easily display much more than 512 tiles. So a MMC5+8kb of CHR-RAM combination would make very little sense since this will kill most functionalities of the MMC5.
I guess you guys assumed a larger CHR-RAM, then yeah I agree it would be cool, but you'd have problems writing to it on a real MMC5 cart modified to have CHR-RAM. All the CHR chip enable lines are driven by the MMC5, so if you'd just write the write pin to CHR WR, you might not get what you're expecting, because the MMC5 drives all the enable lines and all the higher adress lines.
In short I'll be very hard to control how to write to the CHR-RAM. You'd definitely want to totally disable ExRam and split screen when doing that, but even then there is still 2 sets of swapped banks. If you make it so that both matches, then *maybe* it would be possible to normally write to the CHR-RAM chip.
That being said, I agree CHR-ROM alone is not very exciting and quite limited. On another hand the MMC5 would make the best of it, so yeah...
I guess the only mapper who can handle more than 8k of CHR-RAM is the Namco one (no I'm not counting videmation's mapper because it can't do ANYTHING else), so maybe you guys would rather duplicate this one instead ? The main problem is that it's even harder to do testing on real Namco chips are they are only released in japan and usually are epoxy blobs.
Several comments:
1. Most 3.3v CPLD's have I/O pins that are compatible with 5V CMOS logic. Only a 3.3v power supply is required.
2. I don't care if this will not work on an MMC5 donor board. The whole point is to not have to do that
I only care that it will work properly in existing emulators as that is the primary development and demo platform.
3. The Namco mapper makes no advanced provisions for WRAM that I can see. At the very least a write protect feature is needed, although that would not be important on an emulator. It is an option though.
Thank you for your input Bregalad! I've been waiting for you to chime in on this thread
Making a new mapper based on an ASIC mapper is a bad idea, IMHO (especially for sharing an iNES mapper #). It puts a lot of limits on what we can do. If anyone whines that they can't test their ROM in an emulator, they aren't really the target audience of a devcart. The whole point of getting the devcart is so you can test on the real system. I know for me personally, when I bought my EPROM emulator, my percentage of testing under software emulators decreased to virtually never.
I'm sure people who are used to using the PowerPak haven't had the chance to experience the convenience, because it would be utterly stupid to swap a memory chip 100 times in one sitting and have to navigate the menu every time.
What if it turns out the MMC5 works different than we think.. so emulators get updated later, suddenly all these programs will be behaving differently depending on what chip they used.. Then we're up shit creek. Same thing with MMC3.
I think a full-assed new mapper would be extremely less troublesome than making a half-assed clone mapper.
BTW, the FPGA used in the PowerPak I believe costs $10 or so. For my (later planned) FPGA board I was going to use a bigger model in the same family (I think was $17 or so?). Looking at 5V FPGAs and/or CPLDs is the wrong way to go, what you want is a 3V part that can work safely with 5V stuff.
I have a whole lot more to say on this stuff, gotta get ready to make dinner though, I'll share more of my thoughts/opinions later.
qbradq wrote:
Is the NMI vector read if NMI is disabled? I'd rather have something that does not restrict the user's program architecture, flawed though it may be
Do you mean spin on $2002? That's for nesticle programs. Apart from about two Japan-only games, if I remember correctly, all games use NMI to detect vertical blanking, even if it's a Squaresoft-style "just notify the main loop that NMI has occurred" routine.
Quote:
If we figure out a good way of detecting the idle PPU
NMI is a rawther reliable way.
Quote:
that and not enabling rendering mid-frame will be the only restrictions on using the IRQ.
Even Battletoads, which runs on a cheap old discrete mapper, turns on rendering mid-frame so that it has more bandwidth to push sprite cels into CHR RAM. This is especially important if the CHR RAM isn't banked.
Bregalad wrote:
Not that it is a major problem though, it's true, since you usually need to do NTSC and PAL variations because of the sound.
Not necessarily. My current project detects NTSC NES (29780), PAL NES (33247), or Dendy (35464) at program startup. Its sound engine speeds up the music (assuming 3000 frames per minute rather than 3606) on PAL NES and Dendy, and transposes all pitches up by a semitone on PAL NES only. This has been a priority ever since I realized how CIClone works.
qbradq wrote:
Most 3.3v CPLD's have I/O pins that are compatible with 5V CMOS logic. Only a 3.3v power supply is required.
That includes outputting PRG bank numbers to the PRG ROM and PRG RAM and nametable bank numbers to the CIRAM, and eventually the occasional status flags to the CPU data bus if we have enough space left, correct?
Memblers wrote:
If anyone whines that they can't test their ROM in an emulator, they aren't really the target audience of a devcart. The whole point of getting the devcart is so you can test on the real system.
But not everybody is next to a real system all the time. I do a lot of coding on the bus, for example, and carrying an NES, TV, and EPROM emulator around with me wouldn't do. Nor can an EPROM emulator single-step, can it?
Memblers wrote:
Making a new mapper based on an ASIC mapper is a bad idea, IMHO (especially for sharing an iNES mapper #). It puts a lot of limits on what we can do. [...] I think a full-assed new mapper would be extremely less troublesome than making a half-assed clone mapper.
I agree 100% with those statements, however...
Memblers wrote:
If anyone whines that they can't test their ROM in an emulator, they aren't really the target audience of a devcart. The whole point of getting the devcart is so you can test on the real system.
This is not my target audience. I believe it is important for the continued growth of our platform to give new developers a low-impedance path through the product life cycle. Step 1 is developing test code in an emulator. Step 5 or 6 is actually testing on hardware
I can see that seasoned veterans of NES development will jump to where they are comfortable, however this will not be true for new developers.
I think there is also a deeper distinction we can make here. The target developer is one who wishes to publish their software on a physical cart. Does that developer care if his product works on every emulator? Probably not. They probably only care that it works in the debugging emulator of their preference.
This is very good discussion! I look forward to your further thoughts.
tepples wrote:
qbradq wrote:
Most 3.3v CPLD's have I/O pins that are compatible with 5V CMOS logic. Only a 3.3v power supply is required.
That includes outputting PRG bank numbers to the PRG ROM and PRG RAM and nametable bank numbers to the CIRAM, and eventually the occasional status flags to the CPU data bus if we have enough space left, correct?
According to the data sheets, yes. Note that I have zero real-world experience with this
No offence, but for being the mapper for all homebrews and the biggest and baddest, I think we'd need more than 512K CHR-ROM and 8KB CHR-RAM. I mean, this is an MMC1 retropak board with a scanline counter right now. That's not worth pursuing. Maybe this mapper won't be doable in a affordable price range. That's always possible.
The FME-7 is a very capable mapper with MMC3 level capability which could be cloned and is already supported in tons of emulators. It features a CPU cycle IRQ counter so the pattern table and MMC3 scanline counter are not an issue. It supports PRG-RAM as well.
If you want something powerful that is already supported I think you can't do any better than FME-7. I would imagine many emulators don't complain if you want to use CHR-RAM with it though I'm not sure. The only thing FME7 doesn't have that I can think of is all the crazy MMC5 features like its extended 12K CHR thing that lets you have 8K for sprites.
So my vote and suggestion would be to clone the FME-7 (iNES mapper 69) and just have your board support battery backing of the PRG-RAM as well as support for CHR-RAM. The board I've read should even in theory support PRG-RAM banking if you had more than 8K of it.
The only drawbacks to FME-7 in my opinion are it uses a Register Select system like MMC3 rather than just an address on the bus like MMC5 and some japanese mappers. And also the CPU IRQ counter is not quite as straight forward as a PPU based scanline counter. But those drawbacks are perfectly acceptable given all the capability gained by it.
I'd be OK with an FME-7 clone. CPU cycle counters have the disadvantage that you need to translate scanlines into CPU cycles if the Y coordinate of the raster effects are dynamic, and that values are different for PAL and NTSC, but both issues can be solved with look-up tables (about 960 bytes).
The advantage is that you can use them for purposes other than counting scanlines, since they still work when the PPU is off, and there's nothing the PPU can do that will screw up the counting.
FME-7 does not support more than 8k WRAM, which is a shame.
@Memblers: How do you intend to overcome the FPGA configuration time problem? How does the PowerPak manage this? With a $6.00 FPGA we could implement all of MMC5 (minus sound) and have room to spare.
FME7 could support more than 8K of PRG-RAM though. The registers are already there for such. No board produced allowed for more than 8K but that's just a board difference and not a mapper difference.
Regardless of which is picked I'm sure people would like to see any sort of more capable mapper made available for new projects. MMC1 has its issues and limits that certainly would impact some projects.
Man I feel like it's arround the 26th time since I'm in Nesdev I see this thread.
Yeah, the MMC5 is awesome, FME-7 is good too blah blah.... But as long as nobody here release great games with simple mapper, I'm pretty confident nobody will release great games with complex mappers. Yeah they can allow bigger games, better graphics, etc... But if people here can't even release simpler games, this is NOT going to happen.
So everyone move your asses and release great games using simple/ discrete mappers (0,2,3,7,66) and when I'll see quite a few of them I'm confident it'll be time to do a clone of whatever existing powerful mapper (MMC5, FME-7, N106 or wathever) or even a new one that allows 1GB of ROM, CD quality sound and 3D-graphics. (being hironical here)
Quote:
The advantage is that you can use them for purposes other than counting scanlines
Wow did you know I didn't even think about that ? Stable $4011 streaming comes to mind immediately.
PS : If anyone answers me they want a "complex" mapper saves is your problem, most emulators allows 8k SRAM and saves with every mapper (including 0,2,3,7,66) and it IS possible to do that in hardware by adding a few chips (well a SRAM, 3 AND gates and one battery backup controller), so do not refrain from doing it. Nintendo didn't do that but they had the MMC1/3 for that. That or use ReproPak's MMC1.
And I'll remember that saves for not only NES, but also SNES and playstation games are 8kb. Proof that 8kb should be enough for almost anyone
(subtle reference here)
Bregalad,
Thank you for your input! Really the ultimate goal of this project is to provide an easy-to-use development board with a clear path to production carts, but that is backward-compatible with existing emulators. The topic of discussion at the moment is the mapper, as this is the first step in describing the behavior of the board.
The first board design I worked on was UNROM + SRAM, however I noted that this would be more limited than existing MMC1 (no mirror control). I also noted that in my own game design I need some sort of reliable scanline counter IRQ as it makes implementing status bars and four-way scrolling a whole lot easier.
Next I began working on an MMC3 design as it fits the requirements, however it was noted that MMC3's scanline counter limits sprite pattern allocation. That is when we started looking at MMC5 as its scanline counter is much more stable and does not limit sprite allocation. Plus MMC5 has all kinds of features that MMC3 does not.
However it is now becoming apparent that an MMC5 board also has its limitations with respect to the requirements. MMC5 is poorly supported in many emulators, and the exact behavior of the mapper differs from emulator to emulator. The advanced pattern mapping is not only difficult to implement but it is also difficult to work with in software. No provisions for CHR-RAM are made (and this is a staple of homebrew development), and my survey of existing emulators shows that many do not allow CHR-RAM of any sort on MMC5, and those that do implement it inconsistently due to the separation between sprite and background patterns.
So, after investigating MMC5 as a possible mapper for the development cart I can say that it does not meet the requirements. FME-7 is a good suggestion, however I feel that the CPU Cycle-based IRQ counter is problematic (though more flexible).
I have also researched many esoteric mappers, none of which seem to offer enough advantage over the MMC3 to warrant trying to support an obscure mapper.
So with all of this taken into account, I am going to redraft the functional requirements and behavioral description to be a 100% replica of MMC3. An emulator survey will be required to determine if we can increase PRG and CHR ROM capacity to their maximum values given the register space available without breaking emulator compatibility.
None of the MMC3 variants appear to give significant advantage.
qbradq wrote:
So with all of this taken into account, I am going to redraft the functional requirements and behavioral description to be a 100% replica of MMC3.
...and I completely lost interest in this again.
Quote:
I feel that the CPU Cycle-based IRQ counter is problematic (though more flexible).
Come on man, If you're gonna make an exact replica of a mapper, do the FME-7, you said it yourself that its scanline counter is more flexible. For status bars, where the vertical position of the split doesn't vary, all you have to do is dynamically decide between 2 constants so that it works well in both PAL and NTSC. You already have to detect the console type if you want to fix the frequency of music notes, it's not like there's any real complication here. As for dynamic splits, a not-so-large look-up table can be used, no big deal. FME-7 also has better CHR bankswitching, without any of that 1KB vs 2KB banks bullshit the MMC3 has. The ROM/RAM mapping in FME-7 is also versatile as fuck.
Bregalad wrote:
it IS possible to do that in hardware by adding a few chips (well a SRAM, 3 AND gates and one battery backup controller)
Yes, I'm aware of the 74HC139 and 74HC20 based decoders, but how much does this "battery backup controller" cost?
Quote:
And I'll remember that saves for not only NES, but also SNES and playstation games are 8kb. Proof that 8kb should be enough for almost anyone
(subtle reference here)
Mario Paint's save is 32 KiB. As I understand it, so is SimCity's, and SimCity was a launch title. There are games for the Super Famicom with save bigger than even that; to see a list, register at assemblergames.com and download the
list.
I too vote for cloning FME-7.
Possible idea: Separate CHR banks for even/odd rows in the background. Effectively doubles the number of possible tiles from 256 to 512. Then combine that with separate CHR banks for sprites, and you have far less limits than a stock NES.
Wow I have to say those are very good idea DWedit. Most games uses mostly 16x16 metatiles anyways, and a 8x16 font could easily make a good use of this idea.
I think there we need a split between the "compatible with emulators" and "new awesome ideas for a new mapper". What about making two carts, one of each (or one which can go into two modes) ? That way everyone will be happy.
Personally I think the unability to test on an emulator would be handicapping, not only for developing, but would be much more a major problem if you distribute the ROM freely and that people can't play it ! (for developers who wants their work to be freely distributed in a form of an iNES ROM).
Of course you could distribute a modified emulator instead so that people could play it as a PC game but well this is not really cool.
It's true it's too bad emulators doesn't emulate the MMC5 "accurately", but I think there is a chance you could make a game that takes advantage of many of it's awesome graphics possibilities, yet still works under 90% of emulators which supports the MMC5. (I say that because Nesticle supports the MMC5, and only CV3 isn't too far from working on it....).
@dbraq : I'm not sure what your game is going to be, but there is probably a way to make it without the MMC5 or maybe even the MMC3. If the only problem is the status bar at the bottom, I think there is quite a few games who managed to have one without any timer in their mapper (Double Dragon, Gradius, Life Force, Guardian Legend, Wizard & Warriors series comes to mind).
Of course it's easier to have it at top because you can simply wait for the hit after dealing with VBLank updates without wasting too much CPU time. However all the games I mentioned managed to get it at the bottom so it certainly is possible.
Check
tepple's stable DPCM interrupt demo for a reliable proof of it.
What I mean is that it's probably not worth using a very complex mapper just because you're not willing to sacrifice anything. This you are a game developer back then and that you should get your game working with the smaller costs possible (so with a little ROM, and a simple mapper whenever possible).
A complex mapper will be cool if you really uses all it's feature, for example if you write a game using MMC5 mapper then you'd have to use it's multiplier all the time, use the EX-Graphics mode at least during half of the game, and have a lot of scanline effects, and graphics that require more than 256 tiles. Then yes, it's worth using the MMC5.
Dwedit wrote:
Possible idea: Separate CHR banks for even/odd rows in the background. Effectively doubles the number of possible tiles from 256 to 512.
This is genius. Since most games use 16x16 pixel blocks as their basic construction unit, you could go as far as using different banks for each of the 4 quadrants, for a total of 1024 tiles (still far from the 2048 or so that the Genesis/MD can use, specially considering they can be flipped, but it's still good). Tiles that might be used anywhere would have to be repeated in all banks, but that could easily be dealt with by mapping the same bank to all slots when text is necessary.
This is a great idea for a way to have more tiles without all the complexity and extra memory required by the MMC5. Of course this would have to be a completely new mapper, not what exactly qbradq wants. But the idea is great, and should definitely be considered by the next person who designs a mapper.
Quote:
Then combine that with separate CHR banks for sprites
Just like the MMC5, right? Since sprites are fetched at a very specific time in the scanline, I imagine this isn't very difficult to implement.
Dwedit,
I like the idea of a 100% custom mapper. Memblers is working on this for his cart. I have offered to help him with his cart as well if he wants to use the USB reprogramming stuff I am working on.
tokumaru wrote:
If you're gonna make an exact replica of a mapper, do the FME-7...
Ok. I respect your and Tepples's opinions. It's a good compromise. I loose the convenience of the scanline counter, but gain more memory functionality.
Tokumaru, can you write up a demo on using FME-7's CPU interrupts for screen splits? That would be a great start for the documentation. Could you also write a test ROM so we can see which emulators support this properly?
I will create a memory mapping test ROM including testing 512 KB WRAM (which I doubt any emulator will support). I will make a second to test CHR-RAM support.
Total memory space available should be 2048 KB PRG-ROM, 256 KB CHR-ROM, 512 KB PRG-RAM. Some compromises might have to be made on these sizes if you wish the software to be emulator-compatible.
Getting down to implementation thoughts, we will need 64 state bits for CHR banking, 32 state bits for PRG banking, 2 more for mirroring and 16 more for the IRQ states and counters. I will plan on adding a special register for WRAM write protection, which will need 2 more bits. For combinational outputs we will need 8 for CHR banking, 8 for PRG banking and 4 for RAM/ROM enables. That comes out to 136 macro-cells for state keeping. The logic should be very low though.
The Xilinx XC95144XL is a 144 cell CPLD with 5V-compatible outputs. This could fit the design, I'm not 100% sure though. It's $5.80 in single quantities from DigiKey.
This is looking good!
qbradq wrote:
Tokumaru, can you write up a demo on using FME-7's CPU interrupts for screen splits? That would be a great start for the documentation. Could you also write a test ROM so we can see which emulators support this properly?
Sure, I never used this mapper before but it looks simple enough. The only problem is I don't own an FME-7 devcart, because I really like the only game I own that uses this mapper and I'm not willing to "destroy" it... Does anyone have an FME-7 devcart?
That's the whole point of this project
If you can code it in an emulator we can test the other emulators to make sure they all behave the same way. Then I will write the CPLD to behave like the emulator. In the mean time I will be on the lookout for a Batman: RotJ cart to donate to the cause. I saw one not too long ago at a shop just South of here. Any excuse to go retro shopping is a good excuse
But, but...
But I like digging through piles of NES carts
Hey, how about using VRC7 without sound? It has almost the same feature set as FME-7 (it cannot bank PRG-ROM into $6000-$7FFF), but it uses single-write registers and an IRQ counter that can act as a cycle counter (max cycles = 256) or a pseudo scanline counter. It also supports one-screen mirroring (either name table).
It seems like this would be a better solution. The only real feature we would loose is a CPU cycle counter that can handle > 256 cycles. This could easily be worked around with a library.
Support for PAL systems is flaky though. We would have to somehow signal the mapper IC to use a different CPU clock divider for scanline counting.
Thoughts?
Why do you keep trying to make "mapper subsets" and stuff? Who cares what other mappers have done, this shouldn't backwards compatible to anything. I don't get it.
The Konami VRC conters are downright horrible for PAL users.
What they do is count 113, 114, 114, pattern, so that this works flawlessly with NTSC scanlines.
But with a granuarly of 113 + 2/3 cycles on a PAL scanline which is 106 + 9/16, this is a real nightmare to work out.
And 256 cycles is slightly more than 2 scanlines (on both video standards) not very useful for scanline counting, but it could be great for $4011 streaming.
In other words, if you use a scanline counter, use a "simple" 16-bit CPU counter instead of the horrible Konami counter (that is, horrible if you has plan for supporting PAL consoles). As tokumaru said, you can (and should) convert from scanlines to CPU cycles with a simple lockup table. The lockup table just have to be changed when switching to PAL/NTSC and that's it.
PS : About your current project not needing a scanline counter, I edited my older post to show a link to Tepple's demo who do scanline counting with DMC (does not require any mapper).
Thank you for your input Bregalad! This is pretty much what I was thinking too, I just wanted to throw this out there. Also, FME-7 does support one-screen mirroring as well. I do not know why I forgot that. I guess I've got mapper overload today
Yeah, I agree that making it accessible to new developers is the best thing. Debugging with serial port hardware is actually pretty decent because you can easily log anything in ASCII format while the game is running to a remote terminal. The CopyNES software shows that NES code can be single-stepped on the NES (though it emulates the 6502 to do it). But single stepping the CPU and PPU in an emulator surely is easier to do. Point is though, there are some debugging features that can be done on hardware that can't be done on an emulator yet.
PowerPak has a separate ROM for the NES to boot into. If you're using Flash, presumably you'd just boot into that, with pull-up resistors on the mapper-controlled lines. My Squeedo redesign (rev3) would be SRAM-based, and boots into a single-byte of ROM which is disabled (tri-stated) by the FPGA after it and RAM are loaded. All memory accesses will go through the FPGA, which is quite a lot of I/Os, so I doubt this same trick is usable on a smaller sized design.
Quote:
But not everybody is next to a real system all the time. I do a lot of coding on the bus, for example, and carrying an NES, TV, and EPROM emulator around with me wouldn't do. Nor can an EPROM emulator single-step, can it?
Nah, an EPROM emulator typically is just writable from one side and readable from the other, not much else. I suppose technically you could code without the system, but without testing it's not as fun. Luckily (so far) we're still talking about a relatively standard type of mapper, so I have a lot of faith that it would be super easy to support it in any emulator. I've been using C lately so maybe even I could do it.
3gengames wrote:
Maybe this mapper won't be doable in a affordable price range. That's always possible.
I kinda see what you mean about the price range. I've sorta gravitated towards doing a design that is either super cheap (the 36 macrocell CPLD one, basically is just a replacement for using some 74xx chips, it just turned out to be far better than I originally thought) and a higher-end one (Squeedo rev3) that you only buy once. Sorta like Codemasters was getting at with their Aladdin cartridge - buy the mapper once, and the games only cost a couple bucks in parts and plug right in (or do binary release and copy it in). Then you can sell games for really cheap, or if you really worked your ass off on it and it's a good game, sell for some high price like $20 and you'd net maybe $15 each even after shipping. Then, your game release isn't an NES cart by itself, it's going to have a much smaller label area for artwork, but is much cheaper to build. A mid-range sort of hardware would be can be reproduced, but not as cheaply. Good deal for buying a smaller number of games, but something like Squeedo rev3 would have a better cost/benefit ratio depending on how many games people would want to use it with.
Squeedo rev3 will be costly to produce and time-consuming to complete. Compared to the original Squeedo, there is lot more hardware and extreme increase in capability, but I'm still wanting to sell it for the same price that I'd hope could be under $100. Hard to imagine I can make my money back easily on it, but no one said hardware as a hobby is cheap, heh. The focus of my part of the design is making the ultimate memory controller for the NES, and not a replacement of the PowerPak, so I won't be doing much mapper emulation though I suppose others could create that if they wanted. So it's mostly a tool for hardcore hobbyists and musicians, though it seems like it could do pretty well with players if there were good games released that used it. I'm eager to start on it, but Garage Cart #2 (and the CPLD mapper) come first to supply a little seed money.
3gengames wrote:
Why do you keep trying to make "mapper subsets" and stuff?
Because of emulator support. Nobody will want to program for a mapper they can't test on emulators. Sure you can design a new mapper and try to get emulator authors to implement it, but we're not certain they will want to. Existing mapper are already there and they just work (er... kinda).
What about combining some features from FME7 and the current derived subset from your MMC5 clone.
Hamtaro126 wrote:
What about combining some features for FME7 and the current derived subset from your MMC5 clone.
See Tokumaru's post immediately above yours
No emulator support, which does not fulfill the requirements.
FME-7 has built-in WRAM write protect to some degree I just noticed. It has a seperate WRAM enable bit. At boot up $6000-$7FFF would be the first bank of ROM.
I am working on adding documentation for FME-7 to the Wiki. After that the MMC_NESDEV1 page will not be needed, as ours will be a 100% recreation.
I only have the credentials needed to delete pages on one machine, and I'm not sitting at it. So instead, I repurposed a page as a soft redirect to the FME-7 clone project.
The FME-7 IRQ has no separate latch for the reload value, unlike the MMC3 scanline counter and the timers in the GBA. When it expires, it is always set to $FFFF. This poses a problem for multiple splits in a frame. Every time the IRQ activates, it is delayed by up to 7 cycles (worst case: INC $FFFF,x). This uncertainty can accumulate over the course of a frame and eventually fail to guarantee that subsequent raster updates are fully in hblank. But it might be possible to dick with the IRQ Counter High Byte and then just let the low byte run free over the course of a frame, sort of like dpcm_split except with easier sync at NMI time.
(Warning: I didn't read the complete thread so I may have missed some details. Sorry if this is the case).
About the "no emulator support" part, I still think people are over-reacting over it. All the emulators that are supposed to be accurate enough are open source. this mean they can be easily updated if the need arise. If we always stop for such trivial stuff, nothing will ever move forward.
Actually, did anything actually move forward in the dev-cart department in the last 3 years? No, not really because we always too concerned about trivial stuff and we just focus on babbling what would be the next best dev-cart in the forum.
I think we should stop talking about it and just make one and see where it goes. I'm sure some people in the community have enough knowledge to update some emulator source code. Look at TheFox project that added the debugging part to nintendulator for CC65. When the need arise, people will surely contribute for this part.
It's my point of view on the subject. Am I the only one to think that way?
Thank you for your perspective Banshaku!
Banshaku wrote:
It's my point of view on the subject. Am I the only one to think that way?
Not at all. There are currently two active dev cart projects that I am aware of. The first is Membler's custom mapper project, which will require such efforts. The other is this one, which takes the other route. Between the two we should have our bases covered
I believe the hem-hawing about what to do and why is over and done with now. FME-7 is a good compromise between features, support and ease of use. All that's left is to implement the thing, cram a bunch of memory onto a board and stick a USB interface on it. I doubt there will be much debate over those portions.
I hope some people didn't think I was bashing existing dev cart projects. If this is the case, I'm sorry for that. I'm aware of Membler's project, which he's been working for a while on it. I hope I have a chance to see it someday since it has some extra audio on it.
My comment was more related about the "perfect" dev cart that we have been debating for so many years on this forum since I started posting here. It never went anywhere.
These days I have a little bit of time on my hand so I restarted reading briefly a few messages in the current threads. I removed the wiki page at the same time.
I am not any programmer (yet) but I really want to learn in the future. This sounds exciting when it comes to developing games and stuff. I recently bought an eprom burner and that made me want to learn to code even more.
What are the plans for this devcart? Things that will be developed on it, will it be possible to make games on carts later. Or are the plans to just use it on the devcart and in emulators? I think, if it's possible at a reasonable cost, "reproboards" should be produced as well.
I live in Sweden (PAL-B) so I hope that you guys think of the PAL possibilities for the carts too. Even though NTSC would probably be used mostly, PAL could be nice to use too.
tepples wrote:
Every time the IRQ activates, it is delayed by up to 7 cycles (worst case: INC $FFFF,x). This uncertainty can accumulate over the course of a frame and eventually fail to guarantee that subsequent raster updates are fully in hblank.
I don't think this is such a big problem. For small updates that don't mess with $2006 (like bankswitching CHR or modifying the color emphasis bits), it will take some time for the accumulated error to have any effect (about 4 splits I think), specially considering that instructions that take 7 cycles are very rare. Also, considering that the IRQ will always happen after the specified number of cycles, never before, you could reload the counter with slightly lower values (2 or 3 cycles less) than the exact number of cycles, to compensate for the delays that are likely to happen.
Quote:
But it might be possible to dick with the IRQ Counter High Byte and then just let the low byte run free over the course of a frame, sort of like dpcm_split except with easier sync at NMI time.
I don't understand what you mean here. Could you explain in better detail?
Kreese wrote:
What are the plans for this devcart? Things that will be developed on it, will it be possible to make games on carts later. Or are the plans to just use it on the devcart and in emulators? I think, if it's possible at a reasonable cost, "reproboards" should be produced as well.
After the dev cart prototype has been created and tested the next step is to create the repro board. I hope we can figure out some way of adding a programming port to the repro board (on the super-cheap) so that a software producer will not need an EEPROM burner at all.
tokumaru wrote:
tepples wrote:
Every time the IRQ activates, it is delayed by up to 7 cycles (worst case: INC $FFFF,x). This uncertainty can accumulate over the course of a frame and eventually fail to guarantee that subsequent raster updates are fully in hblank.
I don't think this is such a big problem. For small updates that don't mess with $2006 (like bankswitching CHR or modifying the color emphasis bits)
I was thinking of multiple splits involving $2006. (By the way, I've been recommending
your post to people who ask on IRC about splits.) Think of a huge boss drawn as the scrolling background. Drawing it, the ground, and the status bar would involve multiple $2006 writes.
Quote:
it will take some time for the accumulated error to have any effect (about 4 splits I think), specially considering that instructions that take 7 cycles are very rare.
JSR and RTS take six, and INC a,x takes seven.
Quote:
Also, considering that the IRQ will always happen after the specified number of cycles, never before, you could reload the counter with slightly lower values (2 or 3 cycles less) than the exact number of cycles, to compensate for the delays that are likely to happen.
How many ±3s does it take to knock the sync out of hblank?
Quote:
Quote:
But it might be possible to dick with the IRQ Counter High Byte and then just let the low byte run free over the course of a frame, sort of like dpcm_split except with easier sync at NMI time.
I don't understand what you mean here. Could you explain in better detail?
The NMI handler starts executing roughly 3 ± 3 cycles after the start of line 241. At that point, set the counter to the first split value. Afterward until the next NMI, treat it as a low-frequency timer that counts in multiples of 256 CPU cycles, and only rewrite the high byte. I wonder if that would work on the real thing.
It should, according to the mapper documents the registers write directly to the counter bytes.
That's definitely something we need to put in the IRQ test ROM.
Speaking of test ROMs I have finished the memory mapping and name table mirroring test ROM. I am creating the Google Code project for this and uploading everything. Please see the first post for links.
OK, for the memory mapping and name table mirroring test ROM in FCEUX 2.1.4a the RAM pages 1-63 failed, everything else passed, even the nametable mirroring was in the correct order.
Maybe I don't know how to use the ROM or emulator, and I don't understand most of this thread, I was just trying to be a little helpful
Thanks for that report! I will add it to the Wiki page. I did notice that the name table mirroring stuff is all messed up some emulators because they do not always default to vertical mirroring. I have updated the test ROM. I have also created a second version for emulators that do not support more that 256 KB of PRG-ROM (like Nestopia). You can find it in the SVN archives.
This makes absolutely no sense.
You calim to do a FME-7 clone instead of a custom mapper so that it is compatible with existing emulators, but wants to push it so that it can adress 2MB ROM and 512kB RAM, which will NOT be supported in most, if not every unmodified emulator.
If you do that, since emulators won't emulate your mapper anyways, you'd as well do a better mapper with more features.
Again I'm pretty sure your game is perfectly feasible on a "normal" mapper so all of this is pointless. Even if it's not, then you should either clone an existing mapper or make your own mapper (as already mentionned), but clone an existing mapper and add functionality to it will not get it "miraculously" compatible with emulators.
I think it'd be okay to REMOVE features to an existing mapper though (as it was originally planned, a MMC5 with less features), but not to ADD them.
qbradq wrote:
Thanks for that report! I will add it to the Wiki page. I did notice that the name table mirroring stuff is all messed up some emulators because they do not always default to vertical mirroring.
The iNES header specifies the power-on state of the mirroring registers.
I think a PowerPak with an EPROM emulator would make a much better devcart than whatever it is this is supposed to be. It'll work in emulators, but have the added bonus of having a quicker testing cycle.
Bregalad wrote:
This makes absolutely no sense.
You calim to do a FME-7 clone instead of a custom mapper so that it is compatible with existing emulators, but wants to push it so that it can adress 2MB ROM and 512kB RAM, which will NOT be supported in most, if not every unmodified emulator.
Thank you for your continued input Bregalad! I too have had concerns about this, however many have expressed that they feel they need more that 512 KB of ROM and 8 KB of RAM in a dev cart. I have specified 2048 KB ROM and 512 KB RAM for those folks that want to push this as far as they can.
The emulator compatibility requirement is "what works in (most) emulators works on the hardware". This makes it easy to target software at emulators and hardware.
Also I'd like to point out that many emulators (including FCEUX) do support 2048 KB ROM for this mapper.
It comes down to a balancing act. This seems to be the best compromise between features, compatibility and feasibility.
Bregalad wrote:
Again I'm pretty sure your game is perfectly feasible on a "normal" mapper so all of this is pointless.
Yes, my game is feasible on a normal mapper. I completed the demo using MMC1, and I could have done it with UNROM just as easily. This dev cart is not about me and my game, it is about giving the community and new developers an easy to use development cart with a clear path to fabrication for retail carts.
Drag wrote:
I think a PowerPak with an EPROM emulator would make a much better devcart than whatever it is this is supposed to be. It'll work in emulators, but have the added bonus of having a quicker testing cycle.
Thank you for your input!
Yes, it would be a faster dev cycle. Heck, anything with an EPROM emulator would be
Here are the factors that made me not want to use the PowerPak as a development platform. These factors may not apply to you. Again this all comes down to what your specific requirements are.
1. The PowerPak does not work on clone systems (by reports anyhow). This is problematic for me because I am specifically wanting to support clone systems with my software.
2. The PowerPak is prohibitively expensive for a casual purchase (for me anyway). This board should be 1/2 to 1/3 the cost.
3. The PowerPak uses Compact Flash, which requires me to purchase media and a dongle which I would only use for it.
4. If I used the PowerPak (or a repro board for that matter) for development I would need to invest in an EEPROM burner come fabrication time. Again I would have no other use for this investment.
Again I appreciate that my requirements and perspectives are going to be different from yours. If this cart does not meet your requirements (or something else fits them better) then you have no need of it.
Update: Emulator compatibility tables have been updated. We still need an IRQ test ROM. I am starting on the MyHDL code for the full mapper now. I plan on deriving subsets from that base code with lower CPLD requirements for the first dev board.
I still strongly advise using a unique iNES mapper number regardless of any compatibility with existing mappers. Otherwise, I foresee all kinds of problems and confusion.. Plus iNES is already full of different mappers and incompatible board types sharing the same mapper number (and that's the main complaint some people have against iNES format). I guess it could be an iNES 2.0 'submapper', but that and every other road leads to having emulators need to add support for it specifically.
But yeah there's definitely plenty of room for multiple dev cart types, with different hardware and different price points for production.
qbradq wrote:
Doesn't work in Nestopia because reset vector points to RTI. Needless to say that's not good.
On emus which initialize RAM to 0 it RTIs to $0000, executes a BRK and thus an IRQ (and somehow manages to run itself), but Nestopia initializes RAM to $FF.
tepples wrote:
qbradq wrote:
Thanks for that report! I will add it to the Wiki page. I did notice that the name table mirroring stuff is all messed up some emulators because they do not always default to vertical mirroring.
The iNES header specifies the power-on state of the mirroring registers.
Is that really the case? To me that seems like bad practice.
thefox wrote:
tepples wrote:
qbradq wrote:
some emulators [...] do not always default to vertical mirroring.
The iNES header specifies the power-on state of the mirroring registers.
Is that really the case? To me that seems like bad practice.
The feature was designed for mappers that represent boards with hardwired traditional mirroring (NROM, C*ROM, U*ROM, BNROM, GNROM/MHROM, Color Dreams, and Namco's predecessor of MMC3). If a specific mapper always powers on in vertical mirroring mode, all ROMs for that mapper should have the mirroring bit in the header set to vertical.
What's 512KB of RAM? 512K WRAM? 512K CHR-RAM? 128K for both? I hope it's for both, I think that'd be amazing for handling any imaginations game, lots of room for stuff to happen.
tepples wrote:
thefox wrote:
tepples wrote:
qbradq wrote:
some emulators [...] do not always default to vertical mirroring.
The iNES header specifies the power-on state of the mirroring registers.
Is that really the case? To me that seems like bad practice.
The feature was designed for mappers that represent boards with hardwired traditional mirroring (NROM, C*ROM, U*ROM, BNROM, GNROM/MHROM, Color Dreams, and Namco's predecessor of MMC3). If a specific mapper always powers on in vertical mirroring mode, all ROMs for that mapper should have the mirroring bit in the header set to vertical.
From your original post I thought you meant that iNES header mirroring should define the powerup state of mirroring even for mappers that have hardware controllable mirroring. I'm still not sure if that's what you meant or not... I wouldn't call hardwired mirroring "power-on state of mirroring registers".
@thefox,
Nestopia only loads the first 256KB of PRG-ROM, so I had to make a seperate image just for it. Needless to say it is the least compatible emulator
@memblers,
I understand your concerns. Perhaps a better road to take would be to support several different mappers on one cart. We could have a "stock" FME-7, an FME-7 with 2048KB ROM using a sub-mapper and a custom mapper with a totally unique mapper number. That would seem to satisfy all sides of the emulator compatibility split, and it could easilly be done in a single package.
I like this line of though. Progressive super-sets of the same mapper, each with differing levels of emulator support and cost of production boards. Thank you very much for the challange!
@3gengames,
512 KB of PRG-RAM is the most that the register setup of the FME-7 will allow. The real mapper only supported 8. 256 KB of CHR-ROM is the max for the origional mapper and the register space.
qbradq wrote:
@thefox,
Nestopia only loads the first 256KB of PRG-ROM, so I had to make a seperate image just for it. Needless to say it is the least compatible emulator
Ah, so it seems. Very strange limitation. Anyway, you still have your IRQ and RESET vectors swapped.
Thank you for pointing that out! It is fixed now.
I have the Verilog complete for a stock version of the FME7 mapper and a test bench for it. As this my first Verilog design I would really appreciate someone with some experience reviewing the code.
Module Source
Test Bench Source
Also, the design will not fit into a $5 144 cell chip. It comes in at 152 cells. I've done what I can to try and reduce this, but without much experience I am not sure of what I can and cannot do. This will be a major issue for production boards as the next step up chip is $15, or we would have to use a chip from a different family that would need 5V level translation on the inputs.
OK, I have been around the bush on this more times than I care to. I have reworked the logic so many times I've lost count. I even tried removing the PRG-ROM banking at $6000 but that didn't even work.
$15 for the mapper chip is prohibitively expensive for a production cart (in my view anyhow).
I am now investigating using iNES Mapper 67 (Fantasy Zone II). It has the following features:
* One 16 KB PRG bank at $8000
* One 16 KB Fixed PRG bank at $c000
* Four 2 KB CHR banks at $0000, $0800, $1000 and $1800
* Mapper-controlled name table mirroring: H, V, 1SCA and 1SCB
* CPU cycle-counting IRQ, 16-bit
* No provisions for WRAM, although I'll hack in a backwards-compatible WRAM protect register
* No provisions for CHR-RAM
* All mapper functions are single-write operations, meaning they are atomic by default
This will be a fun project I think
A quick survey of popular (and semi-popular) PC-based NES emulators shows that most support iNES Mapper 67 (as used by Fantasy Zone 2). Jnes, FakeNES and Nesticle do not support this mapper at all. The others at least displayed the title screen.
Also, if you haven't tried Fantasy Zone 2 and you have the means to do so, please do! It's a surprisingly fun game. It's Defender, Gradius and Clash at Demonhead all crammed into one adorable package
This is an earlier generation of mapper from the same company behind FME-7. I made a
preliminary wiki page about mapper 67 based on Disch's doc.
qbradq wrote:
* One 16 KB PRG bank at $8000
* One 16 KB Fixed PRG bank at $c000
So PRG bankswitching is like mapper 2. One disadvantage compared to MMC3 and FME-7 is that SMB3 drums, Klax drums, and Sunsoft bass would eat up more of the fixed bank, but that's still manageable if this is considered an upgrade from mapper 2 or 1.
qbradq wrote:
All mapper functions are single-write operations, meaning they are atomic by default
Loading the IRQ counter takes two writes like loading PPUADDR ($2006).
Disch wrote:
The IRQ counter, when enabled, counts down every CPU cycle. When it wraps ($0000->FFFF), it disables itself and triggers an IRQ.
So the counter pauses until the IRQ is acknowledged. This means the free-running 256-cycle-period counter technique would appear not to work because the IRQ handler would have to reenable counting again with the plus or minus 3 cycle uncertainty.
Please remind me again: Apart from mappers like MMC5 that act as a bus master, what "provisions for CHR RAM" would a mapper have to make other than running a trace from PPU /W on the cart edge to the 62256's /WE?
tepples wrote:
qbradq wrote:
* One 16 KB PRG bank at $8000
* One 16 KB Fixed PRG bank at $c000
So PRG bankswitching is like mapper 2. One disadvantage compared to MMC3 and FME-7 is that SMB3 drums, Klax drums, and Sunsoft bass would eat up more of the fixed bank, but that's still manageable if this is considered an upgrade from mapper 2 or 1.
All very true. I do only consider this an upgrade from mappers 1 and 2. At this point I am just trying to get the most useful mapper that I can fit in a cheap CPLD.
tepples wrote:
Disch wrote:
The IRQ counter, when enabled, counts down every CPU cycle. When it wraps ($0000->FFFF), it disables itself and triggers an IRQ.
So the counter pauses until the IRQ is acknowledged. This means the free-running 256-cycle-period counter technique would appear not to work because the IRQ handler would have to reenable counting again with the plus or minus 3 cycle uncertainty.
Right, and that bites. It's still better than using sprite 0 hits. DCPM IRQs may be the way to go if you need more than one split. Not that I have to tell you that
tepples wrote:
Please remind me again: Apart from mappers like MMC5 that act as a bus master, what "provisions for CHR RAM" would a mapper have to make other than running a trace from PPU /W on the cart edge to the 62256's /WE?
From the hardware perspective that is all that is required. From the emulator perspective the emulator must be flexible enough to see that there is no CHR-ROM defined and create an 8 KB RAM array to use as the CHR-RAM. Lots of emulators do not do that for FME-7.
Honestly what lead me to this mapper is that I am trying to create an 8-way scrolling engine using UNROM, but I wanted to use one-screen mirroring. On hardware I could do all sorts of things, like tie the 8th output of an 8-bit latch to the CIRAM /A10 line, or just tie it directly to GND, but none of this will work on an emulator
I think this is a good compromise. It provides more functionality that any of the discreet mappers or MMC1, yet will (probably) still fit into an affordable CPLD for production carts.
qbradq wrote:
Honestly what lead me to this mapper is that I am trying to create an 8-way scrolling engine using UNROM, but I wanted to use one-screen mirroring.
If that's all you want, you can do like Rare: give up the fixed bank at $C000 and use mapper 7. But then your DPCM capability becomes even more limited, as you have to repeat the sample data in all banks.
Quote:
I think this is a good compromise. It provides more functionality that any of the discreet mappers or MMC1, yet will (probably) still fit into an affordable CPLD for production carts.
I agree.
Heh, cool little mapper, #67. I had never heard of it, but I really like what I see, I'd definitely develop games for it. My current "mapper of choice" is mapper 2, so this would really feel like a direct upgrade. I don't even miss the WRAM, but if you want to add it, even better.
The good thing about bankswitching CHR-ROM in 2KB chunks is that you can have a total of 512KB of it, which somewhat compensates for the repeated tiles that will inevitably be there because of background animations and such.
I don't see any real problem with the cycle counter... Any error you get from successive IRQs is still much smaller than the errors you'd get with DMC IRQs... Seriously, you guys are worrying to much about this. I'm pretty sure it would take several splits for this little timing error to accumulate enough to cause visual glitches.
Batman: Return of the Joker appears to split the screen several times in a frame without problems.
Why not using a mapper like the MMC3 that is much simpler and cheaper? eBay is full of pirate cartridges with DIP MMC3 and standard EPROM chips
socram8888 wrote:
Why not using a mapper like the MMC3 that is much simpler and cheaper? eBay is full of pirate cartridges with DIP MMC3 and standard EPROM chips
We've already discussed this. We want to finally break free from having to destroy existing carts in order to make new ones. Also, the scanline counter on the MMC3 imposes some limitations on how we can use the pattern tables, limitations that homebrewers would rather not have (well, pretty much only me for now, but I'm sure others will be glad in the future!
).
I'm just saying this because I'm sure we would finish up with a supercomplex mapper that only some persons could build a cartridge with it
That's not what qbradq is going for at all. It's actually the opposite of what you said. He's looking for a mapper that already works in emulators and that can be implemented in hardware using cheap parts.
qbradq wrote:
All very true. I do only consider this an upgrade from mappers 1 and 2. At this point I am just trying to get the most useful mapper that I can fit in a cheap CPLD.
This mapper sounds like a good one for developers to have more options. I hope you succeed. No mapper is going to please everyone as there will always be some features missing that someone wants. As you said it's a nice upgrade over mappers 1 and 2.
Hmmm FME7 should definitely fit into 144 macrocells. I know this because I've fit condensed versions w/ reduced register file bits or no $6000 switching (which is hardly used) into 108 (on ancient 95XX architecture). You can doooo it.
from memory:
4 index
2 irq flags
16 irq counter
64 2M CHR
18 4M PRG
-------------
104
In my opinion if you give people the option of JTAG, it doesn't matter as much what mapper it ships with, the most important thing is that it ships, and inexpensively.
kyuusaku wrote:
Hmmm FME7 should definitely fit into 144 macrocells. I know this because I've fit condensed versions w/ reduced register file bits or no $6000 switching (which is hardly used) into 108 (on ancient 95XX architecture). You can doooo it.
from memory:
4 index
2 irq flags
16 irq counter
64 2M CHR
18 4M PRG
-------------
104
In my opinion if you give people the option of JTAG, it doesn't matter as much what mapper it ships with, the most important thing is that it ships, and inexpensively.
Care to take a look at the Verilog and help us out? It's all open-source
Web SVN Link to Mappers Directory
The registers by themselves fit just fine, but the logic takes up quite a few as well. Again this is my first Verilog design, and I really do not know what I'm doing here
Ok, so i did an initial draft of the Verilog for Sunsoft3, and it fit into the $5 chip with plenty of room to spare. It is not small enough for the $2.50 chip though.
I am begining to think that using a new mapper is a flaw in the plan. It might be best to develop a dev board compatible with the already available production carts from RetroZone. That way we can leverage the production scale and services that RetroZone offers.
As long as I can fit DIP sockets on the thing for sel-programming I think this would work out quite well. Thoughts?
qbradq wrote:
Ok, so i did an initial draft of the Verilog for Sunsoft3, and it fit into the $5 chip with plenty of room to spare. It is not small enough for the $2.50 chip though.
I am begining to think that using a new mapper is a flaw in the plan. It might be best to develop a dev board compatible with the already available production carts from RetroZone. That way we can leverage the production scale and services that RetroZone offers.
As long as I can fit DIP sockets on the thing for sel-programming I think this would work out quite well. Thoughts?
How do you know how many macrocells does it use?
qbradq wrote:
I am begining to think that using a new mapper is a flaw in the plan. It might be best to develop a dev board compatible with the already available production carts from RetroZone.
What sense does that make? I don't know about everyone else, but to me the whole appeal was the more capable mapper, not the fact that this is a "development system".
tokumaru wrote:
qbradq wrote:
I am begining to think that using a new mapper is a flaw in the plan. It might be best to develop a dev board compatible with the already available production carts from RetroZone.
What sense does that make? I don't know about everyone else, but to me the whole appeal was the more capable mapper, not the fact that this is a "development system".
Yup.
However, every project has to start someplace. Getting a 1.0 project into beta, polished and shipped is an important step in making a 2.0 project. Although some of us would like to see a more capable mapper, it might be more beneficial to qbradq to focus on
_a_ mapper first (instead of many different ones).
I have a development system. It's a Emulator and EPROM programmer. I think you wanting to base this off a mapper that is already released to be "compatible" is a greater flaw than anything.
3gengames wrote:
I have a development system. It's a Emulator
Again, a new mapper would require plug-ins for debugging emulators on all major PC platforms. Being "compatible" with an existing emulator is a means toward not needing to make new plug-ins.
The thing about designing in HDL is that it doesn't always get translated into efficient hardware, even with area priority and the highest optimization effort.
I'm sure the full FME7 will fit into a '144 (I tried it again and I fit a 1M/1M FME7 into a 108), you just need to see what the "platform" (hardware) implementation view or whatever shows and rework and rework until it's decent.
I think this project should be a XC95144XL TQ144 w/ 2x 32-pin sockets (for <=27c080), 2x 28-pin sockets (for <= 62256) + LDO linear regulator.
tepples wrote:
3gengames wrote:
I have a development system. It's a Emulator
Again, a new mapper would require plug-ins for debugging emulators on all major PC platforms. Being "compatible" with an existing emulator is a means toward not needing to make new plug-ins.
So you cripple the mapper instead? Why not contact FCEUX or Nintendulator crew to help with this.
Thanks for the advise 3Gen! I took a crack at changing the optimization parameters in Xilinx ISE, but the result was a 20% increase in macrocell usage
I will read up on this more and try to find my way. Any advice on what tools are good to use, or books / websites to read?
Seems like good improvement, hope it can help the mapper some. I'm not sure about where to look for information at, though...hmm....
I mean it is using 20% more now
Wow, so much for optimization!
@qbradq:
Since I love sarcasm (and I hope you won't take it the wrong way) and just want to tease you a little bit:
"Welcome to nesdev! Were we talk more about our projects than actually doing them."
After reading that thread I see that we are debating again on the subject instead of really moving forward. In the last 3 years I have seen that numerous time (collaborative fighting game anyone?) and nothing move usually die, period.
My advice would be that before talking more about it you should figure out what you really want to do and in the limit of your own knowledge. From what I read, you may not even know how to design it properly so are you sure that you can attain your goal?
Many people (myself included I guess) I set the bar too high for many projects and they don't go forward. The only thing that happened is talks, and talks, and talks etc. This thread seems to be going that way. It's not the first time we have a talk about the subject.
I hope you won't take my criticism (if that's the proper way to say in english) too hard and maybe actually it would help you see what can you achieve and the moment and if it's worth going forward. The initial idea already went from an FM7 something to another sunsoft board so who say that it may not change again?
If the board change again then I guess this thread will lose credibility with time. This is what I'm afraid could happen.
Quote:
If the board change again then I guess this thread will lose credibility with time. This is what I'm afraid could happen.
For me this credibility was lost when the autor claimed to do something that is 100% compatible with existing emulators, but allows for 512k PRG-RAM and 2048k PRG-ROM.
I mean both the "super powerful new mapper" and the "compatible with existing stuff" mapper would be vaild and honorable routes. Something in-between, probably not.
Bregalad wrote:
Quote:
If the board change again then I guess this thread will lose credibility with time. This is what I'm afraid could happen.
For me this credibility was lost when the autor claimed to do something that is 100% compatible with existing emulators, but allows for 512k PRG-RAM and 2048k PRG-ROM.
I mean both the "super powerful new mapper" and the "compatible with existing stuff" mapper would be vaild and honorable routes. Something in-between, probably not.
I have learned a lot with this project. I have learned that:
1. Emulator implementations of iNES mapper descriptions vary quite a bit
2. Verilog is easy
3. Efficient Verilog and hardware fitting is hard
4. The current technical requirements I have stated are outside of my range
5. No community help is forthcoming at this time
Given the above this project is dead. Not a suprise, I know
I still think my objective, to provide an easy entrance to hardware testing on NES and clones, is a sound one. I will continue to pursue this goal with my MMC1 development board tutorial on the wiki. I've just got to get that danged Willem programmer figured out.
I don't know why do you want to use a very complex mapper. This is a NES, not a Nintendo 64. NES programmers didn't have these complex mappers; they had to exploit NES features to the limit.
Personally, I think you should go for a simple mapper using CHR-RAM and 74xx chips for mapping and IRQing, because they're very cheap and they're available everywhere
You can do this using:
An octal latch to store bank number (eg. 74HC373)
Two 8-bit presettable counters for the IRQ, and a D latch and AND gates if you want to be able to disable it (eg. 74F269)
Some NAND/NOR gates to prevent bus conflicts and map IRQ and bank select on the bus (eg. 74HC00, 74HC02...)
Or even better: the 6502 needs ~4 clocks for each command, and a PIC needs only 1 clock for each instruction. I'm pretty sure it's possible to use a PIC or an AVR to do these stuff without having to use expensives CPLDs or FPGAs
But how much would your proposal cost for parts, soldering, and PCB space?
And pics you can clock to what, 40MHz? If you could get that on a NES board [A pic clocked fast enough to process writes] I think that'd be the way to go now that you say that.
The problem is the IRQ counter: I've found some chips but none is available on Digikey (also, they're marked as "discontinued")
Also I've found a problem with the PIC: there is no SYS_CLK on the cart edge (damn Nintendo, why didn't they put this signal there?). Anyway, there's still a 4MHz on the NES from the CIC
This was just an idea. Maybe going for the initial PAL/GAL/CPLD idea is a better way...
Yes there is a clock signal, it's called M2.
The CIC lines aren't reliable as they doesn't exist on toploaders nor famicoms.
3gengames wrote:
And pics you can clock to what, 40MHz? If you could get that on a NES board [A pic clocked fast enough to process writes] I think that'd be the way to go now that you say that.
A 8-bit PIC can go as fast as 80MHz, so there's no problem
Here's a list with many powerful 8-bit with many I/O pins:
http://www.microchip.com/ParamChartSear ... &pageId=74
socram8888 wrote:
3gengames wrote:
And pics you can clock to what, 40MHz? If you could get that on a NES board [A pic clocked fast enough to process writes] I think that'd be the way to go now that you say that.
A 8-bit PIC can go as fast as 80MHz, so there's no problem
Woah, crazy. Should be enough time to calculate everything in between NES clocks. Has anyone ever done this with a PIC? Could you tie the NES's clock to the PIC and get everything down in the PIC within 1 NES clock? If so, this might be crazy enough to work....
There are many 8-bit PICs in the mid-range (less than 5$ in Digikey for a single piece) that has ~20 I/O pins and can work as fast as 32MHz using its internall oscillator (no need for an additional external oscillator)
Syncronizing the PIC with the NES is as easy as wait the M2 to go up, then do whatever do you need
These PICs also have internal EEPROM. Just some bytes, but enough to store a game savestate or the configuration for an application
Others have many useful features like a USART (for debugging, for example), a SPI interface (you can interface a SD card with this!), many individual timers (like IRQs), ...
I didn't know PICs had single-cycle opperations. AVR's do, and they are dirt cheap.
My first thought was to use an AVR for the mapper, but even at 20 MHZ using only single-cycle opperations there in barelly enough time to implement UNROM.
Maybe a dual-pic could work. One for the PRG and CHR mapping, and one to keep track of the IRQ. Adding 8 IO's, one for each chip (PRG and CHR) would be plenty of room for expansion, the hardest thing would be having one 16KB bank, one 8K bank, and a fixed bank. But I would bet with some optimization, there'd be time to do the needed calculatons.
Remember that the average of each 6502 instruction is 4 clocks, so a PIC running at 32MHz gives us more than 50 instructions for each 6502 instructions. That's a lot!
socram8888 wrote:
Remember that the average of each 6502 instruction is 4 clocks, so a PIC running at 32MHz gives us more than 50 instructions for each 6502 instructions. That's a lot!
What about CHR-ROM fetches? Those occur at a much higher frequency, would it really be possible to modify the higher CHR address lines based on the memory range being accessed in time?
If each instruction is 30 or so clocks on the pic, that means we have 30 instructions to process it. That seems reasonable to me. If you had an IRQ for read, and one for writes, it should be easy....right? Just have to use only 30 instructions, but it wouldn't be too bad, would it? C'mon, you're the guy who can tell exactly how much RAM you need for a routine on Atari 2600, and you don't know the least amount of instructions for a PIC mapper handler? Heh. ^_^
And CHR-ROM fetches are 3x as fast, but with an 80Mhz pic on that side if there's 3 pics, that's 20 or so instructions. All this is probably going to be is just a converter for the higher 8 pins or however many we can add. It shouldn't take 20 instructions to process anything.
You folks are not really thinking about how the 6502 (and the PPU) access memory. The shortest instruction may be four clocks, but the first of those clock cycles is always a memory fetch. The timing of that memory fetch is such that you have roughly 135 ns from the time M2 goes high until you have to have data stable on the data lines.
Even if you are using 40 ns Flash memory that leaves you with 95 ns to:
1. Detect that M2 has gone high
2. Read the address bus
3. Assert the appropriate high address on the PRG bus
95 ns is roughly three clocks at 32 MHZ.
Also, the documentation I can find on modern PIC architecture states that a minimum of two clock cycles are required for every instruction because the decoder is implemented as a Look Up Table. Also external interrupt sources take four cycles to synchronize and acknowledge.
Now that I review the timing my old AVR code would not have worked either. For some reason I forgot about the M2 delay and was using the entire read cycle wave.
Anyhow, this is the reason we have programmable logic. You can do an awful lot with a micro (I have generated 1/2 resolution NTSC video with an AVR), but it cannot replace fast logic. It can replace slow logic, but even that is very hard.
But the PIC or whatever would be used, two cycles would be 1/20th of the time, would it not? And is there any device that uses only one clock per instruction?
Using the PIC for a mapper was what the original Squeedo did. Started it with the PIC16F877, then to 18F452 and even later to 18F4525. On the later board I want to move to PIC32. I actually have maybe 35 of those boards left (the version that use all DIP parts), if anyone wants a DIY PIC18
dev board. Bummer that it doesn't have an ICD (in-circuit-debugger) hookup, so you either use a bootloader (easy), or remove the chip from the socket to reprogram, and do the debugging in the MPLAB software. I actually wrote and tested the main part of the software in the debugger before I even made the board.
And yeah, it is faster than the NES, but not in a huge way. You can't emulate an actual mapper, so you'd use a 74hc139 or something for the actual address decoding. On Squeedo what I did with the PIC was use it's outputs to control the bankswitching (PRG was just 32kB, but you could use whatever logic parts to make different pages). The NES reads/writes to the PIC's parallel port peripheral, there's a significant amount of latency while the PIC gets interrupted and finds out what it is you're doing. So the NES has to wait a little bit before the bank is actually switched. There are some advantages to this though, you can have the PIC changes the CHR switching mid-frame without an NES interrupt. One thing I tested out successfully was an MMC3-style scanline counter that takes a CHR address as an input to a timer. You set the PIC register to pre-divide by 8 I think it was, and then your timer is 1:1 with scanline counts. Another timer peripheral had the M2 line connected to it, for a CPU-cycle counter.
On top of that, I also wrote code that had the PIC generating sound, which was sent to the NES to write to $4011. Everything worked fine in real-time, just with some delays on the NES-side for some stuff. So you can really do a lot with a cheap PIC. Something like the cheap CPLD mapper I'm working on is, if I had know how at the time, what I would have used instead of the address decoding logic on the original Squeedo. A PIC can complement a CPLD/mapper, but not replace it. Looks like qbradq made that point before I finished this post, though.
3gengames wrote:
But the PIC or whatever would be used, two cycles would be 1/20th of the time, would it not?
It is faster, but importantly, they can't be synchronized (PIC will have to run on it's own clock, NES doesn't give it anything usable - there is that 21Mhz output pin that exists only on front-loaders, but I'm very doubtful it's usable - you'd have to run the PIC much slower than it's maximum, if it was usable). Even if they could be, you'd still be faced with the task of covering every possible situation within a very small number of instructions (just not enough time for anything else). It'd be too fast to use a timer, or an interrupt in a reasonable way, so it'd have to be all timed code.
It was just an idea. Going for glue logic or something like that, cheap and easy to build, will be a better way
Well like, if you want cheap and easy, I'd recommend discrete parts. All you need are a couple of latches to hold bank numbers, a decoder to go to the /OE pins of the latches (or some other way to select which latch's output gets used), a counter tied to M2 for IRQs, and potentially a 4-bit latch to control mirroring (each bit selects Nametable A or B for each quadrant of the screen). To make it more simple, you could even hardwire the mirroring up to a switch on the cart.
I can almost guarantee that this configuration would be satisfactory for 99% of the homebrew developed on this forum.
Drag wrote:
I can almost guarantee that this configuration would be satisfactory for 99% of the homebrew developed on this forum.
I don't think the goal is to make something suitable for the kind of software that we're currently making, but something that will offer us NEW possibilities.
In all honesty, all I miss is a scanline/cycle counter (without the serious limitations of the one in the MMC3), and, to a lesser degree, CHR-ROM bankswitching in 1KB or 2KB chunks (without that I'd rather use CHR-RAM, like I do now).
I imagine that PRG-RAM is something that a lot of developers miss (I personally don't), not so much because of the extra work RAM but because they want to use a battery with it in order to save games.
tokumaru wrote:
socram8888 wrote:
Remember that the average of each 6502 instruction is 4 clocks, so a PIC running at 32MHz gives us more than 50 instructions for each 6502 instructions. That's a lot!
What about CHR-ROM fetches? Those occur at a much higher frequency, would it really be possible to modify the higher CHR address lines based on the memory range being accessed in time?
Maybe it would be possible to go at this from a different angle... don't even try to modify the CHR addr lines based on realtime input, but have some kind of list of "instructions" that starts executing in the PIC every NMI (kind of like the copper list on Amiga OCS). So instructions would be something like "wait for X cycles, set CHR addr lines to X", and PIC would use timed code to run them.
I mean, there's no reason why the PIC mappers should try to emulate mappers based on digital logic.. there are a wealth of other possibilites.
tokumaru wrote:
Drag wrote:
I can almost guarantee that this configuration would be satisfactory for 99% of the homebrew developed on this forum.
I don't think the goal is to make something suitable for the kind of software that we're currently making, but something that will offer us NEW possibilities.
In all honesty, all I miss is a scanline/cycle counter (without the serious limitations of the one in the MMC3), and, to a lesser degree, CHR-ROM bankswitching in 1KB or 2KB chunks (without that I'd rather use CHR-RAM, like I do now).
I imagine that PRG-RAM is something that a lot of developers miss (I personally don't), not so much because of the extra work RAM but because they want to use a battery with it in order to save games.
Unless the point of this thread changed (I haven't been keeping up much, because there's been too much fantasizing going on here), I was under the impression that this thread was about coming up with a new mapper that was feature rich and was a cheaper, more compatable alternative for development (specifically) than other solutions currently available.
Everyone was trying to rip off the FME too much, and now I'm hearing talk about a PIC, and all I can think about is how a lot of the people here can barely code Tic Tac Toe, how in the hell is anyone going to use 4MB of PRG rom, and why is anyone going to need a math co-processor capable of fourier transformations?
I mean, there's extending the NES's capability, and there's extending the NES's capability
practically. You don't need anything fancy to make a mapper. With a few simple latches, and a counter, you could get functionality that would rival the MMC3, and
trust me, most software developed here would be well suited for it.
All I was doing was bringing that fact up. I don't care what you guys want to stick on it, you can stick a damn x86 on it for all I care, but you're not going to get anywhere unless you have a good base to go off of.
^^what he said
socram8888 wrote:
I don't know why do you want to use a very complex mapper. This is a NES, not a Nintendo 64. NES programmers didn't have these complex mappers; they had to exploit NES features to the limit.
I think we should use CHR-RAM because this simplifies the design a lot (nor CHR banking), and allows to make tiles on the-fly
All we need is something like Wisdom Tree's mapper using a simple octal latch, and with this as base, add some features (IRQ, PRG-RAM, mirroring control...)
These thing should fit easily on a CPLD (or at least is what I think, because I never worked with them)
With discrete parts, I think anyone making one could consider using the 74HC670. That would give you four addressable 4-bit registers. It's around 50 cents at Mouser, more than a lot of 74xx parts but it's pretty good for this use.
thefox wrote:
Maybe it would be possible to go at this from a different angle... don't even try to modify the CHR addr lines based on realtime input, but have some kind of list of "instructions" that starts executing in the PIC every NMI (kind of like the copper list on Amiga OCS). So instructions would be something like "wait for X cycles, set CHR addr lines to X", and PIC would use timed code to run them.
I wrote about something like that in the old Squeedo mapper doc:
http://www.parodius.com/~memblers/nes/squeedo/micromapper.txt (at the end). I had not implemented it, but it would have been straight-forward. The only addition to what you said, would be that the NES could also write the vertical scroll value to the PIC. The game I was designing the mapper for, the map size was 2 nametables tall, so the CHR switching script would begin/end based on scroll position.
Well, I've got my el-cheapo CPLD mapper design is coming along (real-life stuff - buying a home and related research/tasks - is taking more time away from it than I'd like), but that will surely be available after a while. It'll do all the basic stuff everyone wants I think, including nametable selection and an MMC2-style IRQ/CHR-switcher. Would always be cool to see a better mapper made by anyone, but I like this one because it's cheap.
All this mapper discussion is really interesting, but I think this thread is a little side-tracked from what qbradq was talking about. I think the USB devcart portion is more needed than the mapper part. What I'd like to see is something like a ROM emulator that's more suitable for NES (having series resistors on the data bus, for one thing - the ROM emulator I use gets some corruption in sprite-RAM without it), designed in such a way that it could be plugged into any NES cart that uses DIP or PLCC ROM. ROM emulators traditionally use an IDC-to-DIP adapter, but I was thinking maybe something like an FPC (flexible printed circuit) could be used instead - bringing the connector pitch down to 20 mils. You'd need 32 signals (34 if you don't want to power it over USB), if that was split into 2 connectors/FPC cables then it might even fit onto a PLCC-sized package. I doubt anyone else besides me cares about using PLCC though. But what I envision, is that instead of an IDC-to-DIP adapter, you'd have a DIP or PLCC sized PCB, with these small FPC connectors on it. You would solder that board onto the NES cart in place of the ROM, either SMT-style or maybe with legs for the DIP version. Then you'd just make different versions of that adapter board to make it work with any system that uses an 8-bit ROM.
Just sharing some ideas.
Have a really old
proposal of a 74HC670 based mapper. It needs to be updated with what I know now about decoding writes and the like, but it's something to consider.
Yea, this topic is way sideways, but it's so interesting
I really like the idea of a USB ROM emulator. That could satisfy a lot of my requirements. I'll look into that. It may still be out of my range
tepples wrote:
Have a really old
proposal of a 74HC670 based mapper. It needs to be updated with what I know now about decoding writes and the like, but it's something to consider.
From reading your description, it seems that the only actual feature this mapper has is breaking up the PRG-ROM space into many slots, which is not of much use for anything besides DPCM playback, am I right? No IRQs, no mirroring control, no CHR bankswitching and no PRG-RAM? Why would anyone want a mapper like that, specially considering it takes 6 chips (plus memory and lockout) to implement? I'm not even considering the 4 chip version, because 128KB of PRG-ROM is ridiculously small, specially if CHR-RAM is used.
Why using a external USB device + ROM? Why not serial through a NES controller port + BIOS + external RAM?
Running things through the NES controller port will allow to make some applications using that cable to transfer data from the PC to the NES, like a NES cartridge dumper, an Hex viewer (for example, to check how an unknown mapper works)..., running in the internal RAM
Everyone is going to have potentially different ideas on what a new mapper should have. For example people that don't seem to like CHR-ROM and that CHR-RAM is all you need. Or people that want PRG banking a certain way, etc.
That's one thing I thought was appealing to the idea of cloning the FME7. There is no debate on what it should be really, it's just a FME7. I suppose there is some slightly room for debate since the original boards apparently only supported so much PRGRAM and PRGROM. But minor details rather than having the entire mapper to debate.
Everyone as usual is getting hung up on the small stuff and interjecting. Logic mappers would suit the most people, so wouldn't it make sense for a logic mapper to be produced? Going with a cheap CPLD means everyone could design their own mapper that suited their project--THEY could be in charge of compromising between resources and features.
Also I think EVERY piece of information about timing in this thread is wrong, I hope nobody references it.
kyuusaku wrote:
Going with a cheap CPLD means everyone could design their own mapper that suited their project--THEY could be in charge of compromising between resources and features.
And what about emulators? Are you going to implement each version based on this mapper? Or are you going to implement a CPLD emulator?
This is exactly the problem with NES: there are loads of mappers already. We need a universal standard
???? Going with a CPLD gives people the choice of implementing an existing mapper, or not. You won't be able to get everyone to agree on a "universal standard" much less enforce it.
Are you talking about what I think was mentioned before, about producing a board with a CPLD that would be programmable on the board somehow so people could put whatever they want on it but it would still be a completed board that just needs to be programmed and have PRG ROM, PRG-RAM, CHR ROM/RAM added?
That would be nice to have such a board so if you wanted to use a mapper that was an exact clone of FME7 or MMC3, or perhaps a variant of MMC3 which has a better scanline counter, you could do that.
I don't see the point about worrying so much about what emulators support. And if the mapper is programmable then it wouldn't be an issue.
MottZilla wrote:
And if the mapper is programmable then it wouldn't be an issue.
That depends. Can the same Verilog be translated into both CPLD fusemap and a plug-in for an emulator?
Not to detract form the discussion, but I'd just like to mention for those that haven't read the first seven pages that this project is dead. Implementing this in hardware is beyond my skill level and there has been no help offered.
This is a great discussion of mappers though! I know I have learned a lot.
I do like the idea of a programmable CPLD board, but then you get into the debate about which lines should be present on the CPLD and which should pass through. That's a whole other can of worms
I think the advice that was offered earlier in the thread is sound: make a good game with what you have available first. The mapper does not make the game.
I've been inspired. To fill out the last few minutes of my lunch break, I will list some of the games I have enjoyed that use no mapper, UNROM or MMC1 (because it's easy to filter for this on nescartdb
)
1942 and 1943
The Addams Family
Bionic Commando
Castlevania and Castlevania II
Contra
Dragon Warrior I - IV
Faxanadu
Final Fantasy
Ghosts 'n Goblins
The Legend of Zelda
Little Mermaid (good game, don't be fooled
)
Mega Man and Mega Man 2
Metroid
Ninja Gaiden
Pirates!
Super Mario Bros.
Teenage Mutant Ninja Turtles
Ultima: Warriors of Destiny
Willow
Zelda II
And that's not even counting CNROM games
An emulator compatibility isn't an issue? Then, what about the PowerPak, for example? How are you going to "translate" it on the fly?
Also, what's wrong with the original MMC3?
socram8888 wrote:
what's wrong with the original MMC3?
In before tokumaru: The scanline counter breaks if the game uses 8x16 sprites from both pattern tables.
But we can get that fixed on a CPLD, can't we?
I mean: is there any feature lacking on the MMC3?
socram8888 wrote:
But we can get that fixed on a CPLD, can't we?
Possibly, at the cost of famiclone compatibility.
Quote:
I mean: is there any feature lacking on the MMC3?
The biggest noticeable lacking feature in a scanline-counter-fixed MMC3 is PRG RAM bankswitching. The mapper is conjectured to output PRG A18-A13 for CPU $6000-$7FFF the same way it does for $E000-$FFFF: all high. I already have a proof that the saved game in a hypothetical port of a well-known sandbox sim game probably can't be cut down to fit into 8 KiB.
Emulator compatibility was a major goal for me.
The power pak does not work on clone systems, and I want to support yhe clones.
Here's my proposal:
$8000-9FFF - Bank A
$A000-BFFF - Bank B
$C000-DFFF - Bank C
$E000-FFFF - Fixed
The motivation for Banks A and B is for swappable code/data. The motivation for Bank C is for swappable DMC samples, or more code/data if the program doesn't need DMC.
Since each bank is 8k, there's an 8k bank fixed to the last 8k page of the PRG rom. Although this could theoretically be split in half to form Bank D, it would be impractical, because half of the page would be unused, and the only way to use it would be to swap it into one of the other banks, which is redundant because you'd have 4k duplicated without much to gain.
So instead, put your IRQ routines and bankswitching code in the fixed bank.
If we're dealing with 128K rom, we can use 2 74116s (dual 4-bit latch with clear) to implement banks A, B, C, and nametable control (described later).
Each latch on the 74116 has two enable pins that must both be low in order to write the value to the latch, which is pretty convenient for us. We already need to decode CPU A13-14 to choose which latch's output to use, so send the output of that to one of the enables for each latch. Then wire CPU R/W to the second enable for each latch. Send CPU D0-3 to D0-3 of each latch.
Write to 8000-9FFF to set Bank A, A000-BFFF to set Bank B, C000-DFFF to set Bank C, and E000-FFFF to set mirroring.
The nametable latch would just simply be 4 bits to determine which page of the NES's internal CIRAM to use in the four quadrants. Decode PPU A10-11 to select one of the bits, and output the selected bit to CIRAMA10.
This circuit used alone would require CHR-RAM, but hey, it's a good start for now. It wouldn't be much more difficult to set up CHR-ROM bankswitching, and to set up an IRQ counter.
My comment on emulator compatibility not being an issue was if the board had a programmable mapper then it would be up to the developer if they wanted to use a clone of an existing mapper or a modification/new mapper. If they did a mod or new mapper then it's more likely they could add such support to an emulator themselves.
This discussion really goes in circles, doesn't it?
I honestly don't see the point of creating a new mapper if it doesn't have IRQs.
I said it was a good start, an IRQ counter could be added pretty easily, I just didn't do it yet (nor has anyone else).
Baby steps, the easiest way to kill a project is to start too ambitiously.
You have forgot something: the PRG-RAM support at 6000-7FFF
I'll try to do an schematic or something in class if I get bored
And about the CHR-ROM support: what about using a dual configuration of CHR-ROM and CHR-RAM? Some Nintendo cartridges did this
Well, I had some ideas:
Five banks:
Code:
A A A
1 1 1
5 4 3
-----
Bank 0 6000 0 1 1 R/W
Bank 1 8000 1 0 0 R/W
Bank 2 a000 1 0 1 R/W
Bank 3 c000 1 1 0 R/W
Bank 4 e000 1 1 1 R
The mapper can map RAM and ROM at every bank but 4 (fixed to ROM), with size up to 512KB of ROM+512KB of RAM, or 1MB ROM
That bank 4 is writeable to configure the mapper
This could be implemented using a 74LS138 (3-to-8 address decoder) to do the decoding, many latches and some logic gates
>_< how about a split for people and their creative mappers?
kyuusaku wrote:
>_< how about a split for people and their creative mappers?
Why split? Just pick one of the 379 existing threads about new mappers that never get past the first draft...
EDIT: Yeah, I've been feeling a bit pessimistic. That's because every time someone suggests a cool new mapper I get all excited for nothing. Maybe it really is better to stick to something that already exists.
socram8888 wrote:
You have forgot something: the PRG-RAM support at 6000-7FFF
I haven't forgotten, but at the same time as conceptualizing this, I was also trying to imagine the actual hardware implementation of this. It's one thing to say what you want the mapper to support, it's another thing entirely to actually implement it. Keep in mind, lots of these logic gates are on individual ICs, so I'm trying to be as efficient with resources as possible. For example, I can get two 4-bit latches on one IC, which is why the maximum addressable ROM space is 128k (it can be 256k if you're willing to deal with a limitation). This is versus having 3 seperate ICs each with one latch.
If I ever finish the PRG bankswitching portion of the mapper, /then/ I'll see about adding more features, but as I've said in my previous post, BABY STEPS.
The first needed feature is IRQ support. Even UNROM + usable cycle or scanline counter would be helpful.
tepples wrote:
The first needed feature is IRQ support. Even UNROM + usable cycle or scanline counter would be helpful.
Yeah, I did say that latter thing, didn't I?
Ok, I guess I'll just set the 3-bank solution aside for now as a personal project, and work on extending UxROM, since UxROM can address up to 256k without funky limitations, and already has a wram solution (right?). The only drawback is that the DMC area can't be bankswitched, but I doubt that'll be a huge problem for now.
There are multiple ways to implement an IRQ counter. We can make it scanline-based (with multiple ways to accomplish this with/without quirks), or M2-based.
M2-based would allow us to do fancy things like streaming raw PCM, and it could function as a scanline counter, with some effort. However, it'd be oblivious to vblank, so there'd need to be compensation for that in software.
Scanline-based seems like the more useful option, but this requires a bit more circuitry to accomplish than a simple M2 counter,
unless we go with MMC3's solution, which seems like it's the most hardware-simple (but with one drawback that I'm sure a certain someone is going to point out abundantly
).
Thoughts?
I would agree that some sort of IRQ either PPU or CPU based is probably one of the main features people would like to have. UxROM type PRG and PRG-RAM support would probably be enough for most people. That leaves mirroring and CHR-RAM/ROM to specify too though. As it has been stated though, whatever actually materializes is all that matters.
Is 74HC133 (13-input NAND gate) still made? If so, use it to pull a flip-flop's /CLR input low when PPU $1FF7 or $1FFF is read. Then you could leave the last tile or two blank and place sprites wherever you need a split.
tepples wrote:
Is 74HC133 (13-input NAND gate) still made?
Yes.
I think that the IRQ-when-accessing-a-specific-tile idea is very good, because it's simple to implement and it just works. It's also versatile because you get to chose when in the scanline the IRQ will happen by using different X coordinates. You are also free to use the special tile(s) as sprites or background.
The only real disadvantage I can see is that you can't have another IRQ for another 7 scanlines, and if you do want one after that you have to somehow ignore/avoid those 7 extra IRQs, something that might require timed code.
EDIT: Wait, did I misunderstand the idea? Are 13 address lines enough to detect access to a specific byte in the pattern tables? Actually you wouldn't even need the lower bit, since detecting access to just one of the bitplanes of a tile is enough to know it's being rendered... This would be great, and the problem I mentioned above wouldn't exist.
If you get it such that the IRQ occurs when the PPU fetches
0FE0 or 1FE0 specifically, then the IRQ would fire when the PPU renders the top row of tile FE from either pattern table. An advantage would be that this could be either a sprite tile or a BG tile. Stick tile FE at the end of your status bar, and you can split the screen to your playfield; no sprites needed.
So basically, this is a similar idea to MMC2, except it fires an IRQ instead of bankswitching.
This would require:
(PPU A-lines)
/A0 * /A1 * /A2 * /A3 * /A4 * A5 * A6 * A7 * A8 * A9 * A10 * A11 * (A12?) * /A13 * /RD
Where A12 can be either A12 (for pattern table 1), /A12 (for pattern table 0), or omitted if you want the IRQ from both pattern tables.
Drag, it doesn't look like 74xx116 (at least in HC, HCT and LS families) is made anymore. It's not at any major distributors, anyways.
I remember some years ago during previous mapper discussions, the 74HC670 wasn't available either, but now Mouser sells new ones. Kinda weird.
I like the PPU IRQ, that's what I've put into my small CPLD mapper. The lowest address it takes in is A4 though. I had thought about the disadvantage of what tokumaru said, that you're going to get an IRQ per line for 8 lines. But my reasoning was that maybe it's not as often you'd want multiple splits, compared to just using one or using one every line for some effects. But yeah putting code to skip it after the first time adds overhead to the IRQ routine, and disabling it for a time requires a deterministic delay.
But the other reason I thought it was good idea in my case to have it operate like that, was because it can also select CHR banks. This would make, for example mid-line CHR switching pretty easy to use, compared to having it only switch on an exact pixel (instead of every pixel). I'm not sure what all the applications of it may be, but a simple one would be having a text box where the font doesn't use any of your background tiles that are outside the box. So I'm pretty curious to see how it'll work out in practice, hopefully it won't be too long now.
Well poopy! I liked my idea so much, too.
Anyway, you will only get 8 consecutive IRQs if you
don't decode the lower 4 bits of the PPU's fetch address. Remember, you'd be looking specifically for 0FE0 or 1FE0, which is only the
first row of the first plane of tile FE in their respective pattern tables. That's only fetched once for each time tile FE gets rendered.
Drag wrote:
Anyway, you will only get 8 consecutive IRQs if you don't decode the lower 4 bits of the PPU's fetch address.
Yeah, that's what I though tepples was suggesting, but I realized I was wrong. Memblers just confirmed he's doing this in his mapper though.
Quote:
Remember, you'd be looking specifically for 0FE0 or 1FE0, which is only the first row of the first plane of tile FE in their respective pattern tables. That's only fetched once for each time tile FE gets rendered.
That's the perfect way to go about this! I'd definitely code for a mapper with this feature.
I'm kinda on the fence about it though, is it better to fire the IRQ on the first row of the tile, or on the last row?
Maybe FE can fire on the first row, and FD can fire on the last row?
In this case, you'd be looking for two addresses: 0FE0/1FE0 and 0FDF/1FDF.
Alternatively, you could have a 4-bit latch, and just look for 0FEn/1FEn with n being the value of the latch.
That way, you could specify which row of tile FE you want the IRQ to fire on. (and which plane, though that's only makes a 2-pixel difference)
Drag wrote:
I'm kinda on the fence about it though, is it better to fire the IRQ on the first row of the tile, or on the last row?
I'd have to say on the first, because otherwise you wouldn't be able to fire IRQs near the top of the screen with sprites (this will already be a problem for 8x16 sprites, that won't be able to generate IRQs for the first 8 scanlines), even though there are cases that would benefit from IRQs on the last row (like status bars at the top of the screen).
Quote:
Maybe FE can fire on the first row, and FD can fire on the last row?
In this case, you'd be looking for two addresses: 0FE0/1FE0 and 0FDF/1FDF.
Alternatively, you could have a 4-bit latch, and just look for 0FEn/1FEn with n being the value of the latch.
That way, you could specify which row of tile FE you want the IRQ to fire on. (and which plane, though that's only makes a 2-pixel difference)
That would needlessly complicate things... I honestly consider this to be a very minor issue.
I just though of another thing... since sprite patterns are fetched at the start of HBlank, IRQs generated by sprites would always happen there, and for most raster effects you'd have to wait a whole scanline until the next HBlank. Not an issue, just an observation.
Another important detail is the order in which the PPU fetches sprite patterns... is the priority of the sprites respected? If I use the sprites with higher priority does that guarantee that their patterns will be fetched at the same time every frame regardless of the other sprites that share the scanlines with them?
Detecting background tile fetches is also problematic if you are using scrolling. And if you're not using scrolling, why do you need IRQs?
qbradq wrote:
Detecting background tile fetches is also problematic if you are using scrolling.
Not if it's to split the screen at the end of a status bar at the top of the screen.
Drag wrote:
I'm kinda on the fence about it though, is it better to fire the IRQ on the first row of the tile, or on the last row?
Doesn't really matter. A sprite can be flipped such that the last row is the first. I chose the last because of how 8x16 sprites work.
tokumaru wrote:
Another important detail is the order in which the PPU fetches sprite patterns... is the priority of the sprites respected?
I don't know about famiclones, but on an NES, I believe sprites are fetched in the order that they are placed into secondary OAM, which respects priority.
tokumaru wrote:
I just though of another thing... since sprite patterns are fetched at the start of HBlank, IRQs generated by sprites would always happen there, and for most raster effects you'd have to wait a whole scanline until the next HBlank. Not an issue, just an observation.
Another important detail is the order in which the PPU fetches sprite patterns... is the priority of the sprites respected? If I use the sprites with higher priority does that guarantee that their patterns will be fetched at the same time every frame regardless of the other sprites that share the scanlines with them?
Yeah, I was just thinking about this during my commute this morning. When you use BG tile $FE, the IRQ will trigger wherever the top of the tile appears onscreen (actually, a bit to the right, but that's aside the point), and when you use a sprite with tile $FE, the IRQ will always trigger at the end of the
previous scanline the top of the tile appears on. That's more of a gotcha for developers though, they'd just need to keep this behavioral difference in mind.
Yes, sprite priorities (as in, the priorities among the sprites themselves, not BG priority) would be respected. Given this, sprite 0 will always cause an $FE IRQ on PPU cycle 260. No other sprite has any similar guarantee though, it's just sprite 0.
I didn't realize why MMC2 and MMC4 use tile $FD and $FE, and not $FF, but after talking with kevtris today I learned the PPU will be doing dummy reads to tile $FF when there are less than 8 sprites to fetch.
I've been curious about having my CPLD board support the next CPLD step up, I believe I could fit a CPU-cycle counter IRQ by dropping on a 72-macrocell in place of a 36-cell one. I probably could support it on the board, it'd just cost a few extra bucks for that version. I do like the idea of having that, then you can do all sorts of fun stuff with the $4011 register.
Memblers wrote:
I didn't realize why MMC2 and MMC4 use tile $FD and $FE, and not $FF, but after talking with kevtris today I learned the PPU will be doing dummy reads to sprite $FF when there are less than 8 sprites to fetch.
Good call! When I first read Tepples's IRQ idea (and then Tokumaru's follow up), I noticed how similar it was to MMC2/4, and recalled that MMC2/4 used tiles FD and FE (but not FF). That's why I changed the idea to use tile FE when I posted about it; if Nintendo's developers used FD and FE, but not FF, there probably was a good reason.
But yeah, dummy fetches to tile FF are made because of how the secondary OAM contains dummy data of FFs (save for the first unused byte) when there are less than 8 sprites. I just went to look this up on the wiki so I could add this nugget of info to the PPU rendering section.
Drag wrote:
Given this, sprite 0 will always cause an $FE IRQ on PPU cycle 260. No other sprite has any similar guarantee though, it's just sprite 0.
I imagine that if you always use the topmost sprites (from 0 up) for IRQs and those don't appear on the same scanlines, it should OK (i.e. if you use sprite 1 for a second IRQ after sprite 0 has been fully rendered, both would happen at the same point in the scanline).
tokumaru wrote:
Drag wrote:
Given this, sprite 0 will always cause an $FE IRQ on PPU cycle 260. No other sprite has any similar guarantee though, it's just sprite 0.
I imagine that if you always use the topmost sprites (from 0 up) for IRQs and those don't appear on the same scanlines, it should OK (i.e. if you use sprite 1 for a second IRQ after sprite 0 has been fully rendered, both would happen at the same point in the scanline).
As long as (Y[1] < Y[0] OR Y[1] > Y[0]+7), Sprite 1's $FE IRQ will occur on PPU cycle 260.
So basically, if you want multiple sprite-based $FE IRQs to occur closer than 8 scanlines together, you'd need to order the sprites from top down, in decreasing order. Keep the sprite limit in mind though, even if tile $FE is completely transparent, it still counts towards the scanline limit, so I doubt anyone would want to do this in something other than a tech demo.
Oh yeah, you are right about the decreasing order! I agree that one would hardly need to have several IRQs so close together, so the sprite limit would have little impact. It's good to know that it's still possible though, under atypical circumstances.
<sarcasm>
So it was a nesdev thread after all!
</sarcasm>
Now joking a side, maybe the title of the thread should be renamed since the project is dead by itself? Or just split this thread and make one about "what would be the best mapper" etc?
Edit:
And instead of talking about mappers we should focus on making simpler game with less hardware so we can have some code base to work on more ambitious projects. I guess that was people in the past did indirectly anyway.
Bunnyboy said on NA that he hasn't introduced new mappers because nobody has asked about them yet: "nobody has asked for them or even contacted me about them".
EDIT: alleged lies retracted
tepples wrote:
Apparently you're supposed to make your game for the Sunsoft mapper and then ask bunnyboy if he can make you a mapper for you to mapper-hack your game.
And if it turns out he can't make the mapper you're screwed, right?
BTW, why the Sunsoft mapper?
tokumaru wrote:
And if it turns out he can't make the mapper you're screwed, right?
No, the game will just end up hacked to one of the mappers he
can make, just as Castlevania III was hacked to MMC5.
Quote:
BTW, why the Sunsoft mapper?
Sunsoft mappers are the one we happened to be discussing in this topic. See
thread on NA. I'd link the exact post, but I don't see "permanent link to this post" on NA's forum software. Follow the link and search for the text "No homebrew comes close to needing it".
tepples wrote:
No, the game will just end up hacked to one of the mappers he can make
But that's exactly the problem we have, we don't know which ones he can make (besides the ones he sells), so we don't know what features we can use in our homebrews.
Quote:
How cute, you mentioned me and my frustration towards the MMC3! XD
Youch, Bunnyboy seems entirely too worked up about this. And apparently Tepples is full of lies, LIES I TELLS YOU!
(see the last post on that thread)
That's why I stay away from Nintendoage...
Anyhoo, the core message is also stated on the NA thread: the reason home brew projects do not get completed has nothing to do with the mapper.
Personally I could care less what mappers Bunnyboy can make. If (and it's a big if) I bring a game out on cartridge it won't be through him. Too many ethical issues there.
That said I do find his development products to be top quality, and very useful.
And now I've been accused of "lies" and "just blabbering to appear smart". Maybe it's
my avatar.
We appear to have run into a few hard questions:
- Why hasn't anybody got on #nesdev and asked retrousb what other mappers are available or could be made available in the foreseeable future?
- Why hasn't anybody finished an MMC3 game, checked price lists for dirt-cheap donors, replicated the game on donors, and sold the carts?
- Why hasn't anybody even finished a game that takes full advantage of what the available boards can already do (e.g. SUROM, DPCM split)?
EDIT: contact method changed
qbradq wrote:
Youch, Bunnyboy seems entirely too worked up about this. And apparently Tepples is full of lies, LIES I TELLS YOU!
Looks like he is worked up about tepples bitching instead of helping. Notice how many times tepples has posted here and there about the boards, without ever actually asking about them. "Why hasn't anybody asked bunnyboy" he asks, when he hasn't bothered to do it either! At least he retracted his lies about mapper hacking crap.
qbradq wrote:
That's why I stay away from Nintendoage...
Too bad, you are missing out on the biggest paying market. Really think there is less complaining here?
qbradq wrote:
Personally I could care less what mappers Bunnyboy can make. If (and it's a big if) I bring a game out on cartridge it won't be through him. Too many ethical issues there.
What ethical issues? Think he is going to steal from you? Sell your game to some chinese pirates? Claim he wrote it?
ibeenew2 wrote:
Looks like he is worked up about tepples bitching instead of helping.
What help is requested? If you mean help as in asking for a price quote and then publishing it for the world to see, I foresee confidentiality issues. But I could try next time I see him on IRC; should I?
Quote:
"Why hasn't anybody asked bunnyboy" he asks, when he hasn't bothered to do it either!
I have e-mailed bunnyboy once about another project that required battery save, though not MMC3. At the time, I considered the price he quoted to be a bit on the high side, which led me to
ask about alternatives.
Quote:
At least he retracted his lies about mapper hacking crap.
I want to learn how people distinguish lies from mistakes. Can you help?
tepples wrote:
And now I've been accused of "lies" and "just blabbering to appear smart". Maybe it's
my avatar.
I always wondered where your avatar came from
So here are my responses to your hard (and fair, and extremely pertinent) questions.
- Why hasn't anybody e-mailed bunnyboy asking what other mappers are available or could be made available in the foreseeable future?
- I have no interest in releasing a cartridge through bunnyboy due to ethical concerns, therefore I have not inquired.
- Why hasn't anybody finished an MMC3 game, checked price lists for dirt-cheap donors, replicated the game on donors, and sold the carts?
- I ended up deciding that MMC1 was a good enough fit for my current game project. There are things that annoy me about it, but it works.
- Why hasn't anybody finished a game that takes full advantage of what the available boards can already do (e.g. SUROM, DPCM split)?
- That's the magic question. There have been many promising home brew games that use SxROM, like Super Bat Puncher (which looks freaking awesome and great!)
Again what this all comes down to is that the mapper has little to do with weather or not you ship your game. Well, unless you get hung up trying to develop the "perfect mapper" for your game, like I did for a few weeks
Now if only I could develop the "perfect assembler" for my game...
ibeenew2 wrote:
What ethical issues? Think he is going to steal from you? Sell your game to some chinese pirates? Claim he wrote it?
The products listed on
this page contain copyright material (or works based on copyright material) for which I assume bunnyboy has no license to resell. No where on his page does he claim that he does have a license, nor is Nintendo a fan of licensing their previous works, especially in the Mario franchise, to individuals.
The above is a clear display of a lack of integrity, and that's not someone I want to do business with.
Now again, with all of that said, I do enjoy his products and will continue to be a customer in the future, however I do not purchase those questionable products, nor do I want to enter into a business relationship with him.
As far as I see someone could fairly easily produce their own game without using donors. It should actually be cheaper and easier than using donors if you know how to make the mapper. Ordering up PCBs with or without components programming the roms/logic and selling somewhere like ebay wouldn't be to hard unless you don't want to deal with all the work involved.
The only real obstacle I see is the cart case I guess bunnyboy has someone making him his using injection molding? I'm sure he'd be happy to sell a boat load of em to ya for a better rate though. But there are other options out there but I doubt you'd be able to do much better on price. Unless you went the unholy route of donor carts, but atleast you wouldn't need to mod the board.
infiniteneslives wrote:
Unless you went the unholy route of donor carts, but atleast you wouldn't need to mod the board.
But a new board and CIC might be worth the $2 loss of profit per game, since doing a run of 200 or so carts would be insane to desolder the chips....
I can't believe he asked if you were blabbering to be smart, that wasn't even anything technological. Just what the MMC3 does over the MMC1. Nothing trying to be smart there, that's just how tepples is, we all know that here. Apparently he doesn't, and that was just a jab at making tepples seem dumb to me.
I also would like to know how to ask him about his boards and stuff when he is so hard to get contact with. I agree with the ethnics thing more-so now, too.
And I know that small projects are hard to finish just themselves, but the complexity of a big game over a small game isn't even the game engine, but the mass ammount of content. Anyone who can even make a small game can make a full-fledged NES game to me. You just have to take more time with the content and not the engine. The engine is the easy part if anything.
3gengames wrote:
I can't believe he asked if you were blabbering to be smart, that wasn't even anything technological. Just what the MMC3 does over the MMC1. Nothing trying to be smart there, that's just how tepples is, we all know that here. Apparently he doesn't, and that was just a jab at making tepples seem dumb to me.
Maybe it's that I
am dumb. I'm smart software-wise but dumb art-wise, dumb soldering-wise, dumb Verilog-wise, and dumb business-wise.
Quote:
I also would like to know how to ask him about his boards and stuff when he is so hard to get contact with.
According to
RetroZone FAQ, one should try catching
retrousb on AIM or catching
retrousb on EFnet when he's in #nesdev.
Quote:
You just have to take more time with the content and not the engine. The engine is the easy part if anything.
Which changes the problem from a technical one to one of team organization and art production if one is to hop the
asset complexity wall. That's where I am dumb.
Okay so I know this whole project was officially claimed dead. The project was trashed because there was too much debate about what mapper options/capabilities were best and no one stepping up to work on the hardware.
Coincidentally I'm working on a related project that could satisfy what you guys were initially looking for. I didn't have any intention of making more than one for myself because I didn't see why anyone would be interested when the powerpak was out there. I was more so just don't it to learn more about the NES and have fun in the process.
Now I'm not a game developer or anything nor do I really have plans to start in the near future but I would love to help you guys make new and better games if I could. I've also been looking for a project for senior design next year. One of my friends convinced me to pitch this idea to our adviser at school and he gave us the preliminary approval, that provided some specifics. So we would really like to do the NESDEV cart for our senior design project next year if there is enough interest.
Since how I'm not a developer, I'm a "hardware guy" and would need you're guys' input along the way. Assuming there are still people interest who haven't lost hope, I read through all 12 pages of this post to try and gather together what it seemed would satisfy most people.
Here's some goals I've put together:
Compatibility:
*Original equipment
*Clones
*PAL and NTSC
Quick Interface for both game and mapper development:
*Using SD and perhaps USB
*Potential for debugging interface (I'm not sure what this would entail but there was discussion about it)
Cost
*Must be less than $100
*Ideally would be around $60
The cost will obviously depend on what options are included and what quantities of parts are purchased. There may even be options if they are easily selected and use the same PCB.
Time
*Prototype by the end of the year
*Final product within a year (12 months)
(Some of this is dependent on my senior design project, and while it may seem like a while, at least the chances of cancelling the project are slim to none.)
Hardware
*Need to decide how much of what memories.
*Programmable logic
*AVR microcontroller mostly for use with programming via JTAG logic and RAM but other NES interface capabilities will be included.
Mapper support:
*FME-7 / MMC3+ capabilities minimum
Now this is obviously one of the biggest topics of debate. There are some who would like to have it all and some who'd be happy with a few discrete logic chips. This also heavily ties into the cost which is important to most. It appears to me that most people would be happy to have something comparable to a sunsoft FME-7 or the MMC3 with the potential for some added capabilities.
Either way it needs to have more than 144mcells. I know the FME-7 should be able to fit in 144 cells but for this project to succeed someone needs to be able to code up a mapper in verilog and easily test out their mapper. I don't feel they should have to figure out how to minimize everything to implement a mapper like qbradq was trying to do.
If you're the type that doesn't want a custom mapper because of emulator issues and everything that's fine, you should be able to your FME-7, MMC3 or comparable mapper or even a really basic mapper. Some of these options will be provided and can easily be swapped out.
Right now I don't exactly have an answer to this issue of CPLD size/cost/5v issues. And maybe an expensive CPLD, FPGA, or level shifting is the answer. I know some out there might say well if you had all that it wouldn't be reasonable to cheaply manufacture a cartridge and try to sell it. But the cost shouldn't be the same after some time and this would let someone play around with a mapper to fit it on the smallest and cheapest piece of logic out there at that time.
So let me have it tell me what you think. I know I've said it a few times but my biggest question is whether or not there is actual interest in the project, and not just that everyone likes to talk about it.
I'll go ahead and apologize for all the dead horses right now...
EPM3128 - $8
PIC32 - $8
done. the max3000a cpld is 5v tolerant and 3.3v is enough for the TTL inputs.
WARNING: feature creep! stay simple. if you REALLY must have complex mappers, then go with MAXII and level shifting.
a hint: if this is a group project, it will fail. ONE PERSON needs to take point and do this, you did a good thing by volunteering.
you need to decide when to stop taking input. if you don't, everybody else here will continue to post page after page of generally pointless suggestions and you will never get done.
I'd encourage you to take enough interest in nes coding to see this through. otherwise I doubt you'll finish it.
1 last thing: you will NEVER be able to make everybody happy, and make this work for everybody. As long as it works for most people, good enough
Infinite,
Hey man, glad to see someone with hardware knowledge is interested in the project! I did decide on a direction to go with: to implement FME7. I did what Marshall was talking about and stopped taking input after a certain point. All of that fizzled out because I don't know enough about hardware to make it happen.
Generally speaking though any mapper on this type of cart would be useful to the development community.
So here are the requirements as I see them:
1. USB interface for programming PRG-RAM, PRG-ROM, CHR-ROM and the CPLD-based mapper.
2. PRG-ROM and CHR-ROM would really be RAM chips with a battery backup to reduce cycle time. We also can support CHR-ROM and CHR-RAM games at the same time without extra hardware.
3. Give the CPLD enough cart and chip connections to fully implement FME7, MMC3 and the other, simpler mappers (like UxROM, MMC1)
4. Use a large CPLD to give mapper design flexibility.
If we can meet these requirements then the question of what mapper to support is moot. We can supply the Verilog and bit streams for common mappers and provide enough hardware documentation for folks to write their own. This would also make the cart valuable to people that want to develop custom mappers.
The USB interface is the killer feature I had wanted for the cart. This is easy as pie to implement on an AVR. You can either use pre-existing software USB drivers or use a FTDI chip. Either way is very well documented and trivial to implement.
I can supply the (apparently very unoptimized) Verilog for several of the mappers, and I can write all of the MCU and desktop code and any test NES programs we may need.
Other than those, what deliverables do you need from me? Please note if there is any particular order you need them in to help your work.
Thanks guys I appreciate the support. Sorry for the huge post, but I figure it's best to tell you everything I know about now and what I'm thinking so we can get on the same page as much as possible.
Since how I'd be doing this as my senior design project the timeline for the whole project is pretty well structured for me. So the only thing I can really do is work to get as much of a head start as I can. Here's the basic timeline I'm planning..
Summer: Generally speaking no one really works or even knows what their project is. But since I've submitted my own I can use the summer to do all the research and I'm hoping to learn some basics to program on the NES. I'd also like to get some fairly solid customer requirements for myself. And trust me I don't plan on shooting myself in the foot and biting off more than we can tackle. I would just like to brainstorm what might be asked of the device down the road. That way if there is an easy way to make it possible without much/any modification to the board.
I also have a simple through hole prototype with a 72 mcell Xilinx CPLD: XC9572-15PCG84C And a atmega664. So I'd like to play around with the interfaces and get to the point where I'm programming the RAM and loading simple UNROM mappers and such.
Fall: When I'll actually have to turn in my customer requirements. Regardless of anything that gets said here, I'm not going be changing anything significant with the design after this step. This is also the time I think I'll be able to start asking my school for money to build the surface mount prototype. My wife will also be having our second child in November, so this is one of the many reasons I'm taking advantage of the summer as much as possible.
Winter break: I would actually like to have the basic features working at this point like getting MMC3 and FME-7 on the logic and programming everyhing via USB/SD card interface. Chances are I'm not going to be requiring my team and I do actually code up any mappers beyond the complexity of MMC1. This is where we'll use support from you guys like the how qbradq already has something written up for the FME-7.
Winter term: working out the bugs and getting everything working like the end product. Most people teams aren't actually to this point until Spring.
Spring term: Settle on final board assuming there are changes since the Fall. This may be making room for bells and whistles at the end since how I'm hoping to basically done as far as senior design is concerned. If all goes well this is when I'd be taking orders from anyone here who'd like to get a board made on the same run. I think it would be awesome to have our project out in use when all the other teams basically only have a completed first build.
Beyond: Basically it would be up to the community from here. The whole thing will be open source so people could make changes and assemble new orders as they please. I can't be certain I would continue to be a supply for boards but I guess that all depends what I want to spend my free time after graduation.
As far as deliverables go qbradq, because we're required to do things essential to the project I won't really be able to ask you to write up the AVR code to program the ram and usb interface. But if we have troubles or anything we'll be sure to use you as a reference.
One of our customer design requirements will probably be that developers must beable to make a mapper in something like the Xilinx IDE and easily get the mapper onto the logic. The best way for us to show this is do things like taking your FME-7 mapper you've already done and show it's easy to program the CPLD. Any of the MMC mappers or their variants that you guys would like to write up would only further prove that the board works like we wanted. The other thing is NES programs, and that'll be somewhat dependent on what options we provide with our hardware. Here are some things I'd like to make possible with the cart but I don't intend to complete them myself. (or at least until my advisors tell me I'm not doing enough work this fall:)
We'll do:
Provide a more manual way to program everything via USB or/and by pressing a program button while holding reset on the console to program everything from the data on the SD card.
What I would like to provide:
An interface that would allow you guys to write an NES program so you could load roms and mappers via the NES on screen control similar to how the PowerPak works.
This interface could also allow for added features if the developer decided to create them. I don't know much about this so correct me if need be, but I think this could allow you to do things like multiplication and sound similar to the MMC5 perhaps. Except here you'd have a AVR at your disposal to handle do this type of stuff for you as a co-processor.
Keep in mind I'm not giving any promises on things like this. But if all I need to do is provide a register interface between the NES and AVR to do things like this I don't see why not allow for these types of features. I need you're guys' input on how you'd like this whole interface to work from a software/signal standpoint and I'll make the hardware to do it.
The other thing I would need help with is debugging capabilities (NES game type of bugs.) I don't really know what you guys would need as far as hardware requirements to do things like this. But I'm sure a good interface between the NES and AVR is what will allow a lot of these tools to be created by you guys.
This is really the idea of my end of the project. From my point of view it seems you guys could benefit from a somewhat simple piece of hardware for game development. The trouble is, it's a lot a work and money to make such a specific tool especially if you're on your own and don't know a whole lot about hardware. So I provide the hardware and a simple way to program the logic and memory along with an interface you asked for and let you guys go wild with open sourcing everything. With any luck I'll get to enjoy a few homebrews that might not have made it otherwise.
I really like your attitude and approach to this Infinite!
As for hardware debugging features you're not going to be able to provide that from the cartridge. As far as I understand there is no way to single-step the CPU like that. Besides it's not a terribly needed feature. Most program debugging is done on emulators, and the hardware hackers use a CopyNES.
As for the NES to MCU interface, I really like that idea. At that point it would be kinda like the PowerPak, which ain't a bad thing. From a software standpoint, here's what I would personally like:
1. System boots into "MCU Mode", where the CPLD mapper is in a pass-through configuration and a small boot ROM is connected to the system bus.
2. Provide an SPI interface to the MCU mapped into the $5000-$5FFF address range. The NES would be the SPI master.
3. A command set would be used for the MCU. Something like "send sorted ROM list" and "load ROM #".
4. A hardware reset would be required to return to the MCU Mode to load a new game. Clones and such don't handle cartridge-driven reset very well from what I have heard.
Let me just say that this is not a requirement for me. Here are my requirements in customer terms, to get you started
1. USB interface to read and write PRG, CHR and SRAM
2. Support CHR-RAM
3. PRG-RAM support
4. MMC1 mapper support
5. 256 KB PRG-ROM
6. 8 KB PRG-RAM
7. 8 KB CHR-RAM
Anything above this would be nice-to-have's for me. Other developers here will have other requirements, probably with regards to mapper support. However the above would support the development of most of the homebrew that I am currently aware of, including my own projects. Something that this discussion has taught me is that the MMC1 has all you need to make some pretty awesome software.
Just a little tip: if you spring for an FTDI interface chip, you can make the AVR programmable through USB as well. The FTDI chips have a bit-bang mode that let you control the logic level on all of it's output pins.
You can wire up four of these pins that are not used for normal USART operation to the ICSP port of the AVR. Then using software on the client side you can engage bit-bang mode on the FTDI chip and use the AVR SPI ICSP protocol to program the AVR. This is how the previous generation of Arduino boards program their MCU's boot loader.
Combine that with a JTAG port (either from the USB controller like above or from the AVR) to the CPLD and now your development prototype is also your production prototype
I think you'll find that reading and writing the memory from the AVR is going to require either a very high pin-count AVR or an I/O extender.
Sounds exactly like my Squeedo design would have been 7 years ago, if this better hardware would have been usable by me at the time (especially the cheaper CPLD, and USB integration, and MCU with more than one serial port). In short, sounds good to me!
Not sure I'd want to rewrite my synth or not for an AVR, since I've done it once in PIC18 asm and again in C (for PIC32). How does this AVR's speed compare roughly to a PIC18 @ 40Mhz, do you know? (it's 4 clocks per instruction)
BTW, I would strongly recommend checking out the standard that chykyn and I have come up with regarding the use of the expansion port pins.
http://nesdev.com/bbs/viewtopic.php?t=7313
In particular, if you provide the EXP port /CE (you can put it anywhere pretty much, I'd recommend $48xx, $5xxx, or $58xx) and address lines, then the cart will be useable with more stuff in the future.
qbradq wrote:
As for the NES to MCU interface, I really like that idea. At that point it would be kinda like the PowerPak, which ain't a bad thing. From a software standpoint, here's what I would personally like:
1. System boots into "MCU Mode", where the CPLD mapper is in a pass-through configuration and a small boot ROM is connected to the system bus.
2. Provide an SPI interface to the MCU mapped into the $5000-$5FFF address range. The NES would be the SPI master.
3. A command set would be used for the MCU. Something like "send sorted ROM list" and "load ROM #".
4. A hardware reset would be required to return to the MCU Mode to load a new game. Clones and such don't handle cartridge-driven reset very well from what I have heard.
This whole part is what I'm having the hardest time figuring out what may be best. Here's what I'm wondering about your approach:
1) This may require the CPLD to be programmed every time and I'd like to avoid that if we can. What would this boot rom be physically? If it's not one of the chips you listed in the requirements we're talking about a EEPROM or something else that we have to allow to be programmed in circuit.
2) so something like serial parallel shift registers? One NES parallel in serial out to the MCU and a second one for communication the other way Serial in from the MCU to parallel out to the NES? The other route would be to sacrafice MCU pins for speed and use parallel both ways. In actuality I think there will be 8 pins allocated to the NES PRG data bus anyways. I think the speed would be vital for trying to things like Membler's synth. I can't imagine you'd be willing to sacrafice 16 MCU cycles to get something in and out.
qbradq wrote:
Let me just say that this is not a requirement for me. Here are my requirements in customer terms, to get you started
1. USB interface to read and write PRG, CHR and SRAM
2. Support CHR-RAM
3. PRG-RAM support
4. MMC1 mapper support
5. 256 KB PRG-ROM
6. 8 KB PRG-RAM
7. 8 KB CHR-RAM
I get everything but the 8KB CHR-RAM. Were there games that had CHR-ROM and RAM? Are there significant number of people working on games that would need this? It just seems to me if the CHR-"ROM" was actually a 256KB SRAM you wouldn't need the extra 8KB.
qbradq wrote:
Just a little tip: if you spring for an FTDI interface chip, you can make the AVR programmable through USB as well. The FTDI chips have a bit-bang mode that let you control the logic level on all of it's output pins.
I like that idea.
qbradq wrote:
now your development prototype is also your production prototype
That's what I would really like to see.
Quote:
I think you'll find that reading and writing the memory from the AVR is going to require either a very high pin-count AVR or an I/O extender.
Yeah I know... One thing that could help is using the CPLD to gain access to the pins it already sees but this complicates mapper. There's a good chance we'll end up extending the I/O if we need read write capabilities of everything by the MCU. But I may just ditch the idea of being able to "manually" program everything with the MCU and just rely solely on the NES.
We may end up with a combination of this though as well, I'm at constant debate with myself about this part.
Memblers wrote:
Not sure I'd want to rewrite my synth or not for an AVR, since I've done it once in PIC18 asm and again in C (for PIC32). How does this AVR's speed compare roughly to a PIC18 @ 40Mhz, do you know? (it's 4 clocks per instruction)
BTW, I would strongly recommend checking out the standard that chykyn and I have come up with regarding the use of the expansion port pins.
Yeah I know you've got your AVR guys and your PIC guys as I see it. I hate to tell all the PIC guys though nuggets but, I can't do everything. One thing I might be willing to entertain though if there is enough board space and it's not too tricky is provide separate solder pads for a PIC if one chose. But it would be up to you to write all the code we did in AVR. So this may not really solve anything...
I was planning to use the Atmega128 for 5V reasons it runs at 20Mhz but most instructions are 1-2 cycles. I'm not sure how this compares though with the PIC. Things are pipelined in the AVR so that may affect the comparison.
As far as the expansion port goes, that sound and CAN stuff is a little over my head right now. But I would be more than willing to entertain the idea once I knew what it was all about.
For my requirements I only need CHR-RAM, not CHR-ROM. If you make the CHR memory 256 KB SRAM that would be fine for my uses.
As for the whole MCU Mode thing, although I like the idea I think it is over reaching. My opinion is it is best to leave it out. It's your project though, so what ever you decide
I wouldn't worry about the audio guys either. I think they are well served already, and Memblers has a new cart in the works as well.
This thread started out as a cheap development board, now it's a crazy school project
And I really don't understand the design. Is this trying to be a cheaper PowerPak or not? Most CPLD can only be reprogrammed a few thousand times.
kyuusaku wrote:
Most CPLD can only be reprogrammed a few thousand times.
This is the biggest flaw in this cart's design I think. I wouldn't buy it for this very reason, I don't like hardware with expiration dates.
This is the type of feedback I'm looking for. Keep in mind as far as my project is concerned we're still brainstorming here.
I've basically been putting up what ideas I have, and I'm not going to get my feelings hurt if people shoot them down. Especially if a lot of people shoot it down then they obviously deserve to die.
Realistically we've got the whole summer to hash things out, hopefully everyone doesn't get tired of talking and lose hope. Because as long as you guys support the project I'll be doing it. There's still a good chance I'd do it anyways because I've got to do something and this is the best project I think I can find.
As far as the CPLD write cycle limitation is concerned the chips are rated at over 10,000 write cycles.
Really the choice of CPLD and FPGA is a trade off of several things. I went through the pros and cons here:
http://nesdev.com/bbs/viewtopic.php?t=7796&highlight= If anyone is unfamiliar.
Quote:
kyuusaku wrote:
Most CPLD can only be reprogrammed a few thousand times.
tokumaru:
This is the biggest flaw in this cart's design I think. I wouldn't buy it for this very reason, I don't like hardware with expiration dates.
If it's a devcart I don't see someone actually getting anywhere close to the 10,000 cycle write limit. If it were a powerpak clone it might be a different story but that's not what we're going for here. For the most part once you got your mapper set up you wouldn't have to reprogram the CPLD again until you decided the to swap out the mapper. I did some quick calculations:
*Some one who used this thing for 20 years:
Could reprogram it more than 2 times a day every single day.
*Some one who programmed the CPLD 100 times for every game they developed:
Could develop 100 games
*Someone who programmed it four times a week:
Could use it for 50 years
*Someone who used it in place of a powerpak and played 20 different games a week:
Could use it for 10 years.
I think you'll agree these estimates are VERY conservative and I know the idea of something dieing from over use isn't fun to think about. But If someone used this thing enough times to wear out the EEPROM should deserve an award. And if they were really that serious about this thing they will probably want to upgrade to something more capable before they get anywhere close to wearing it out. Not to mention it will probably last a lot longer than 10,000 cycles.
CPLDs are simpler and cheaper which seem to be main goals of this project and that's why I've been leaning towards them. Also the idea is someone could easily take this devboard replicate the parts of the design they needed for production. A FPGA simply is NOT a production cart option for several reasons. Your choices would basically be to use discrete logic for simple mappers or a CPLD. Just incase it's not obvious to everyone you would only have to program the CPLD once when assembling the cart.
As far as the MCU goes, I think it's going to be difficult to not include one of some sort for communication via USB or SD card. Now the idea of sound capabilities and all kinds of other craziness is probably doubtful. But I wanted to bring it up. Because if someone said "Oh, if you provided this one simple feature I could do all this kind of stuff with it." And if that feature was something as simple as wire connections or a super cheap register or something I would like to know.
both altera MAX3000A (5v tolerant) and MAXII(no5 5v tolerant) are only rated for 100 erasures.
marshallh wrote:
both altera MAX3000A (5v tolerant) and MAXII(no5 5v tolerant) are only rated for 100 erasures.
Best steer clear from those then! I didn't realize there were ones out there rated so low. I can see why you might not care though if it was something you only had to worry about upgrading firmware or something and could reduce the cost.
I'll be sure to double check for something like this if we don't go with the Xilinx ones we're currently looking at.
infiniteneslives wrote:
One thing I might be willing to entertain though if there is enough board space and it's not too tricky is provide separate solder pads for a PIC if one chose. But it would be up to you to write all the code we did in AVR. So this may not really solve anything...
I was planning to use the Atmega128 for 5V reasons it runs at 20Mhz but most instructions are 1-2 cycles. I'm not sure how this compares though with the PIC. Things are pipelined in the AVR so that may affect the comparison.
As far as the expansion port goes, that sound and CAN stuff is a little over my head right now. But I would be more than willing to entertain the idea once I knew what it was all about.
I looked up the Atmega128 specs and at 20Mhz it should be at least as fast as the old PIC18. On PIC18 I managed to get 4 channels mixed at 22khz and 30khz pretty reasonably, so if the MCU->NES communication is decent, then it should be able to pull that off (tho I'm not sure how that interface can be done without adding a couple 8-bit latches and using a lot of MCU I/Os like you said).
With the newest version of my synth, perhaps the (low frequency) C code could still work on the AVR, and the more intensive resampler/mixer done in assembly, but the difference in RAM size (4kB vs 128kB w/ PIC32) might require cutbacks. But anyways, yeah some kind of sound will be possible (just not comparable to what I'll do with the PIC32, as it's a whole different beast compared to anything I've used before).
Here's a description of what the expansion port pins would be for:
- /CE and address lines - expansion port has the CPU data bus, so this allows devices on it to have addressable ports for NES to talk to connected device(s). The expansion port also has the $4016/$4017 ports on it, so it may still be possible to do SPI communication with any cart lacking the EXP/CE. Anyways, SPI mode would be required for Famicom, Top-loader, and NES clones - EXP/CE is more of a bonus feature for the front-loader NES.
- CAN bus of course is networking for microcontrollers, it's provided because my synth will be using it already, then I figured since my future rev3 Squeedo (as an NES cart) will use the same PIC32 that I'd go ahead and link those 2 MCUs up directly. One thing I was thinking about, was that if one of these MCUs can get internet access, then with the CAN bus maybe all of them could use it. This is pretty much the "expansion port on the expansion port", so it remains to be seen what will be done with it (other than my plans with the synth).
- Audio input - You would have to make a DAC on the cart, the audio will be mixed in with the NES's internal sound (expansion port device or audio mod is required, front-loader only).
I looked more closely into the AVR MCU's that looked like the could fit the bill they are all obviously trade offs between price, io, ram, and speed. The number in the name signifies program flash memory (128/64KB) Prices are quantities of 1 and 25.
atmega128A 16Mhz 4K ram 53io $5.80/9.23
atmega1280 16Mhz 8K ram 86io $10.13/16.13
atmega1284 20Mhz 16K ram 32io $5.04/8.03
atmega640 16Mhz 8K ram 86io $7.40/11.80
*atmega6450A 20Mhz 4K ram 69io $3.93/6.27
The last one actually looks the most attractive to me. But it all really depends what the final design of everything else comes down to on which will be best I think.
Looking further into parts it's becoming more and more apparent that the price will significantly depend on whether there are 25 people willing to buy. We could add a lot of options for the same price or just offer a simple board for less.
I checked SRAM prices too and found some suprises.
8KB SRAM $2.37/2.75
*32KB SRAM $1.60/1.85
256KB SRAM $5.05/5.86
*512KB SRAM $5.12/6.25
So 32KB was actually cheaper and smaller than 8KB and the difference between 256 and 512 for the PRG/CHR 'ROM' was negligible.
So it looks like we'll end up with 32KB of WRAM and 512KB of PRG/CHR 'ROM'
May as well put these on the plate too:
XC95144XL-10TQG100C 144mcell 81ioCPLD $5.55/5.80
*XC95288XL-10TQG144C 288mcell 117io CPLD $13.45/14.70
For fun I looked up some dual ported SRAM:
1KB $5.87/8.47
* I marked these with what I'm leaning towards for chips right now and the total is $29 for quanties of 25 and $35 for single quanties.
This isn't everything obviously but it's the major silicon we're talking about. All the extra stuff is going to put cost of parts close to $50 which will make it hard to ship for $50...
The only real place to make a significant dent in price is the CPLD by saving $8-9. One option would be to step up from the TQ100 package to the TQ144 on the smaller CPLD for about $1. Then people could pick their own. It seems like the $8-9 is worth it to me to be able to use MMC3/FME-7 complexity level of mappers, when you're already laying down the money but you guys can be the judge of that. It sounds like it might be overkill for most of you.
A lot of the 8bit AVR can be reliably overclocked to 30Mhz with reports of some models going as high as 40!
A few random thoughts:
What were you parameters for choosing these microcontrollers? at least on the PIC18, 64KB of program memory is huge, easily 20kloc. (Of course, it would be easy to stuff it full of e.g. wavetables)
I'm pretty certain that the right way to do dual-ported memory on all older consoles is time multiplexing instead: you have the entire time while φ2 is low — 279ns.
I am guessing pin count is a big concern here. I know that's what led me to the ATMega series when I was trying to do the hardware side of this.
lidnariq wrote:
A few random thoughts:
What were you parameters for choosing these microcontrollers? at least on the PIC18, 64KB of program memory is huge, easily 20kloc. (Of course, it would be easy to stuff it full of e.g. wavetables)
I'm pretty certain that the right way to do dual-ported memory on all older consoles is time multiplexing instead: you have the entire time while φ2 is low — 279ns.
There's no point to go lower.
Stepping down to atmega32 is only 1K ram, and only saves us $1
As far as time muxing goes, It'll require several massive muxes to prevent bus conflicts. Not sure but I don't think they will be much cheaper but it's been awhile since I priced that option out.
Quote:
A lot of the 8bit AVR can be reliably overclocked to 30Mhz with reports of some models going as high as 40!
Yeah I figured you could clock quite a bit more out of them. I'm getting the impression that no one will be planning to make use of it though. It would be pretty simple and cheap to provide an over clocking option though if one desired.
You know, the more I think about this the more I think Memblers had it right: let the NES take care of writing the memory. There is a pretty easy way to make a USB cable that will connect to the controller port on the NES for PC communications, and it would be pretty easy to do the same for an SD card.
Now that I think about it, it's kind of odd to imbed an MCU in the cartridge if you've already got an MPU in the main system. By letting the CPU do all of the writing you also remove the need for muxing and all that.
Seeings hows you are still in the requirements phase, let me run this scenario by you:
1. Cartridge boots into a small boot ROM, bypassing the mapper and having access to CHR-RAM (so we only need one boot ROM chip).
2. This boot ROM provides a menu (I can write this) to either boot the current program, load a new program from PC link cable (or SD card peripheral), or load a program into RAM and execute it.
3. The boot loader will need a way to switch the mapper "on" so to speak. This can be done from a program stub running in main RAM, so the exact timing wouldn't be an issue.
This would seem to satisfy my requirements, and might be a lot easier and cheaper maybe?
Also, if you can make the boot ROM writable that would be pimp. I could just load a program into RAM to read data from the PC and overwrite the firmware.
You could even use say a 32KB Flash ROM for the boot ROM and mirror the boot loader into four 8KB pages, and set the top two address lines with dip switches. This would give you some protection against bricking the cart.
And you could easily replace a fixed-function mapper with a CPLD and provide an interface to it's JTAG port so the boot loader could load arbitrary code on it as well. I think this would over-complicate matters though. But hey, it's your project
That is an interesting solution. But I don't know if I see how it's much easier or cheaper. But ease is relative to skills also.
We'd be trading a NES cord (from a $5 NES controller) for a $5 MCU. However I happen to have a seemingly never ending supply of NES cords so the NES cord would coincidentally be "free."
We would also be losing any added functionality that could be gained from the MCU. But if no one really planned to use it this isn't really a loss. It would also be a LOT slower transferring everything serially at 2Mhz which means several minutes. I don't know about how that would relate to you guys. If I had to wait several minutes vise 10s of seconds every time I flash an MCU for a project I'm working, I would go crazy waiting for everything to program.
EDIT: I have a feeling I may be wrong about the speed here...
And I realize you're offering to code all the NES stuff, which would happen to be ALL the coding with this approach. I guess that would make it "easy" for me but really I'm not doing the work. I wouldn't necessarily have a problem with that but I'm willing to bet my advisers would
However even if they did I could still make a one off with an MCU. I don't want you guys to make decisions on how to do a devcart based on whether or not it will satisfy what I'm doing for school.
But I do agree with the NES doing the coding, and I think the whole idea of dual ported memory is beyond the scope of the project. I've kinda been thinking that for awhile now even though I may not have been voicing that. Perhaps I should explain better. The only real reason I was leaving an out for the MCU to directly code the RAM was because it would remove the requirement for me to directly rely on you to code it up. Not that I think you'd leave me out to dry or anything but If something were to happen it's not like I can just ditch the project once I'm relying on it for graduation. So for that reason alone I would try to make my customer requirements as lenient as possible saying the That "the memories must be programmed in circuit."
What I would really like to see is a design process something like this:
1)Using the basic "unofficial" prototype I already have:
*Design an interface designed to communicate between the MCU and NES. So the NES. Then you (or anyone who'd like to pitch in) could start working on some code that would allow the memory to be programmed from an on screen selection. That would have the MCU feed bytes to the NES that would then be writing all the RAM.
To take care of the boot rom issue I think we could a chunk or all of the 32 KB of WRAM I already have.
*Physically set it up so that all the memory can be programmed by the MCU from the SD card. The CPLD would be programmed from an external JTAG programmer. This would allow me to completely test everything out without NES coding. This would all happen with the NES off or with the reset button held. I need to program everything somehow at first. I would also construct the interface for your program to work.
This also provides me an easy way to program the bootrom you write to the WRAM for the time being.
+With some clearly defined and thoroughly designed interface we would be able to work in tandem. You could code while I'm wiring up the prototype.
I'm hoping this will allow us to better define what how the final interface will work thus making the "official" prototype better. It will also give us the capability to debug hardware and code separately. I could make sure my hardware works first before your code starts to use said hardware.
2) Now that we have the basics working we could do away with things like the MCU's ability to program all the RAM while holding reset with the second "official" prototype.
*Provide EEPROM on the board for boot rom so we don't have to hold reset at power up anymore. We could allow this EEPROM firmware to be upgraded by the AVR while holding the RESET button on the console but I'm sure this could also be done by the NES as long as we didn't have self modifying code. It would be safer to have the AVR do this though to prevent bricking.
*Now we let the MCU program the CPLD. But this might be a little more tricky. Perhaps the NES should do this I'm not sure right now what will be best. I might be hard to program logic that's tied to it's own bus there may be bus conflict issues.. I think the powerpak gets away with this since it's an FPGA. But we'll figure out what's best when we get closer to that point.
*If people wanted to start writing demos that made use of the MCU we could test this stuff out and make any changes needed. We might find a better way to program the bootrom or CPLD.
3) Done with entire design start producing carts for whoever wants one.
You could learn NES assembly
It's not very hard compared to AVR assembly.
But seriously, do what's best for your school project. That is much more important that what a bunch of nerds do in their spare time
I'm sure we'll benefit either way.
Yeah I do plan on learning it, I just hope I can leave myself enough time to over the summer with all my other projects going on.
Hi guys! I must appreciate your hardware knowledge. It's great when electronic systems can be explained in a step-by-step manner that makes it easy to understand.
Anybody have the "FME-7 Test ROM for Memory Mapping and Name Table Mirroring" from the first post (test_rom.nes)?