INL-ROM custom MMC3 hybrid mapper design

[rainwarrior]

So the mapper can pick up the extra read even though software can't? I guess that makes sense then. Afterwards you have 8 or 9 bits you could compare against the value you read in software?

[thefox]

So the mapper can pick up the extra read even though software can't? I guess that makes sense then. Afterwards you have 8 or 9 bits you could compare against the value you read in software?

Nah you don't need to compare it to anything, you'll know it's right. Something to keep in mind though is that according to some rumors, some pads (?) don't like being read too fast: viewtopic.php?f=2&t=4841. (I may try to reproduce the problem some day since I have a PAL NES.)

[infiniteneslives]

3- DPCM-deglitcher: How would you stop the shift register exactly?

a 9 bit shift register; when 0b???????1 is written to $4xxx the register is preloaded with 0b000000001, reads clock it, and when the 256s bit is 1 is blocks itself.

So Let me see if we're on the same page. It seems like we've got some complex ideas going on here that'll require to be simplified greatly if they're going to be a viable choice. I see the 500 cycle benefit to be substantial, not required obviously but worth a look in any event. Although I think it might be valid to just assume use of the DPCM costs you an extra 500 cycles, or controller inputs that can afford to be delayed a few frames.

I think you're alluding to the possibility of just watching for writes to $4000-$4FFF. That would require two additional inputs (PRG A11&12) which is feasible especially if we're using those to decode $5000-5FFF for PRG RAM potentially as well.

So if I understand this correctly the thought is to have a 8bit shift register that would read ONLY 8 bits after ANY write to $4xxx. Then the NES could then read ACTUAL controller data from the mapper in a single read. So the shift register would hold trash most of the time but we don't care, you can only consider the data valid after a single controller read. Not sure how you'd read back that shift register, it'd require a lot of address lines or mirroring which there may not be much left of either. Only other option being a special sequence of operations to read things back which requires even MORE logic.

Ah wait none of that non-sense works because the controller is being clocked by a signal which is only available at the controllers and EXP port. So ASSUMING one had a jumper or modified ENIO, the clock signal could be routed to the cart's mapper. Because you can't clock off of reads from $4xxx, that's why the NES is broke in the first place...

So unless I'm being oblivious to something, all I can see is a large cost for a modest benefit. So yeah I'm officially stumped as to how this work work at all even if we weren't trying to fix things like the paddle and other long winded peripherals. It'd probably be a lot easier to implement without such limited resources.

But I do have one other question... Do we KNOW that the controller data is actually VALID when the DPCM clocks it randomly? I guess what I'm wondering is if there is potential for bus conflicting on Data-0 when the controller is driving the line out of sync. If this were actually an issue I don't see how you'd ever resolve the problem with hardware.

Something to keep in mind though is that according to some rumors, some pads (?) don't like being read too fast: viewtopic.php?f=2&t=4841. (I may try to reproduce the problem some day since I have a PAL NES.)

Can't remember how those extra resistors are connected on the PAL NES pads, but the faster clock and some effect of that resistor could be the issue. I've got a PAL controller board sitting around here somewhere, but can't find it at the moment...

[lidnariq]

Let me try unpacking some things here:

I think you're alluding to the possibility of just watching for writes to $4000-$4FFF. That would require two additional inputs (PRG A11&12) which is feasible especially if we're using those to decode $5000-5FFF for PRG RAM potentially as well.

It could even just be watching $4000-$5FFF; the point is that you're not reading or writing to anything else in that range while you're reading the controller. (Also, how'd A11 get involved?)

Not sure how you'd read back that shift register, it'd require a lot of address lines or mirroring which there may not be much left of either.

No argument there; but I don't think (e.g.) mirroring it over all of $5xxx is that awful.

Ah wait none of that nonsense works because the controller is being clocked by a signal which is only available at the controllers and EXP port.

But it's not! That's the beauty of it. The NES asserts the /RD4016 line, but the address bus still contains $4016, and the data bus is still driven by the 74hc368. The only hardish part is coming up with a convention so that the cartridge doesn't need to full decode the address bus.

even if we weren't trying to fix things like the paddle and other long winded peripherals.

For the Vaus controller, some cleverness needs to be present to know whether the shift register should pay attention to D4 or D0. The mouse, I sadly agree, is a lost cause (32 bits of which you can throw away the first 8? eh...)

Do we KNOW that the controller data is actually VALID when the DPCM clocks it randomly?

The 74HC368 has a OE propagation delay of 45ns max at 4.5V; the CD4021has a maximum shift frequency of 2.5MHz (350ns). That's all the hardware that produces this is, the only way for it to screw up is if the 2A03 changed the address bus in the middle of an M2 cycle (it doesn't)

[infiniteneslives]

Yeah sorry I don't know where the A11 came from I must have miscounted. Is there anywhere that documents exactly how this glitch works/behaves? The previous thread that was linked to didn't even label the signals I think I can guess which ones they are though. Being a glitch and all I don't feel any of my normal assumptions are necessarily valid.

I suppose I could verify things more for myself with my logic analyzer. Honestly the more I think about this whole thing the less interest I have in trying to design, test, and implement a feature with modest returns at best IMO.

So if you all are seriously interested in this deglitcher, I suggest drawing up the schematic. I'll code it up in verilog and see how much logic it'll cost. If we're able to keep it simple enough to fit in the available room, then someone can write a test ROM and I'll test it out. Even still though I'd leave it up to a vote if it boiled down to this feature beating out some other feature of interest.

[lidnariq]

Is there anywhere that documents exactly how this glitch works/behaves?

The Visual2A03 answers all.

DPCM DMA deasserts RDY to take the CPU off the bus for (at least) two M2 cycles. At least one of those is junk, a repetition of the last value from the CPU. The second the DPCM hardware drives the address bus to the byte desired. (Example with reading $2002 instead).

The Joystick read strobes are known to be NOT (Address == $4016 AND Readnotwrite AND M2). Each time all 18 of those lines match, /RD4016 goes to 0V. Similar for /RD4017.

So if you all are seriously interested in this deglitcher, I suggest drawing up the schematic. I'll code it up in verilog and see how much logic it'll cost. If we're able to keep it simple enough to fit in the available room, then someone can write a test ROM and I'll test it out. Even still though I'd leave it up to a vote if it boiled down to this feature beating out some other feature of interest.

I'm really not trying to say "dude, this is so exciting, please build it!". I'm just trying to say "This should be a fairly inexpensive way of freeing up about 2% of CPU time for games that use DPCM".

Anyway, the attached image is how I'd build it using 74xx parts; something synthesized should be able to skip the inverters and nor gates.

[infiniteneslives]

So if you all are seriously interested in this deglitcher, I suggest drawing up the schematic. I'll code it up in verilog and see how much logic it'll cost. If we're able to keep it simple enough to fit in the available room, then someone can write a test ROM and I'll test it out. Even still though I'd leave it up to a vote if it boiled down to this feature beating out some other feature of interest.

I'm really not trying to say "dude, this is so exciting, please build it!". I'm just trying to say "This should be a fairly inexpensive way of freeing up about 2% of CPU time for games that use DPCM".

No I know, I don't mean to be a stick in the mud or anything either. I appreciate the ideas and discussion. Thanks for drawing that up, I'll code it up and compile it and see what we get. Assuming it fits, we can keep it as an option and pick and choose once I've got a few more compiled up and tested.

[infiniteneslives]

So the idea came up here to use a serial flash to store large amounts of data for a cart carrying 32KB of VRAM and WRAM for the level, music, and graphic data to be unpacked into.

I agree that the data rate should be effectively as fast as the rate the NES can take it making it look as if it were normal parallel memory reads. So ASSUMING I've got enough logic available with 2 the CPLDs on board to make this happen I started thinking about what commonly discussed problems this could effectively solve at little to no extra cost to the setup this 'hybrid MMC3' board already has.

The idea would be to maintain the code that is always used on a standard parallel ROM, things like the game engine, user input, and music routines. Tepples suggested you'd need 128KB which seems more than sufficient and still cheap for a 'boot/engine' ROM. Then you'd access the SPI flash through the CPLD and load level, music, and graphic data loading it into the 32KB of VRAM and 32KB of WRAM. Additionally the goal would be to allow WRAM to be mapped to $8000-BFFF or something similar.

lidnariq brought up good points about the cost comparison of parallel vs. serial. I agree that if you're ONLY looking for large amounts of ROM parallel is still probably your best option. But with this project I've got my sights set on this MMC3 like capable board. Depending what one has already bought into placing on the board the cost could effectively be free or even money saving.

Here are the benefits/costs I see:
1) Cost: Assuming you've already got WRAM, VRAM, 3.3v regulator, the logic available and level conversion (CPLD) You're only buying 1-2MBytes of ROM for ~$0.50. Now you're saving buying a large PRG ROM ($2.70+) for a smaller 128KB boot/engine ROM ($1) so you're actually saving money if you need/use the extra memory.

2) Game saves: you could effectively solve the age old issue of saves and ditch the problems of battery backing. This not only allows for better save integrity, but saves ~$1 worth of expense for the components.

3) Graphics: I can't really speak from much experience here since I'm only in the planning stages of my game. I've only really spent time doing artwork, but the idea of being able to create effectively as many tiles as I'd ever desire is appealing. Basically this just seems like it would make game development easier and less time intensive if I didn't have this constant thought that I need to save every byte of ROM space I can. I know there aren't a lot of artists around here so this might be falling on deaf ears, I happen to enjoy drawing on the NES albeit time consuming to do well. Armed with 32KB of VRAM(or 28KB with 4screen), 1MB or more of tiles, and MMC3 fine bank switching would allow for some pretty detailed and less repetitive graphics even with the color limitations.

4) Compression: Maybe it's just me but this sounds like the least fun part of making a homebrew. You could obviously still do it with this setup, but you could also just spend a few dimes more for another MByte and ignore the problem . It would definitely save development time and possibly even CPU time when comparing loading to decompressing. Again there is less motivation to pinch every byte of ROM you can, I agree it's still important to conserve for other reasons. But I imagine it'd save development time if I didn't feel the need to do with everything you wrote/drew/composed.

5) Music: open up possibilities for streaming audio without the 'hard' limits of ROM space. I'm not a music/sound buff but I know some people would might appreciate it.

6) Other: One interesting thought is with the engine stored on it's own ROM and some level specific code, level data, and graphics data separately I'd be simpler to run as a dev cart once the boot/engine ROM was complete. You could make most of your modifications to just the SPI memory which is more manageable than a large parallel ROM behind a mapper. Not sure how worth while this really is, but it's an interesting thought. It'd also be an interesting way for someone to share a 'generic platformer engine' and allow someone else to fill in the details of animations, graphics, levels, and music. Or to release a sequel using effectively same engine where you could sell the serial EPROM alone as an upgrade that included both games or something. Head in the clouds thoughts I know, but interesting to think about...

I know, I know, "where's my game to support this mapper???" "make the game, then then add capabilities to the mapper as needed!!" I agree with these arguments to for the most part. But being early in the game development process these things seem like they would change how the game were developed. But I'm curious to see what you guys think who are further along in game development or have something substantial under your belt unlike myself. Does something like this sound appealing? Am I being too naive? Thoughts?

[3gengames]

I like the idea of using a serial RAM to save data, especially when they can be flashed and such. But, you still have to have a backup of the current "file" in WRAM so it honestly doesn't help much, unless your game uses multiple states. But, if it does use multiple save slots/states, then it sure would be nice to be able to use this idea instead.

[MottZilla]

You could make your own version of the Famicom Disk System basically.

I find it hard to believe that a homebrew game is going to come along and say, be bigger than Kirby's Adventure. And if one does, I'm sure they will tackle getting more memory when that challenge presents itself. But it's a neat idea.

[tokumaru]

If I had the option to use vast amounts of data for a low cost, I'd make a couple of kick-ass animation sequences just for the heck of it, even if the game itself would fit in a traditional cartridge.

[infiniteneslives]

I like the idea of using a serial RAM to save data, especially when they can be flashed and such. But, you still have to have a backup of the current "file" in WRAM so it honestly doesn't help much, unless your game uses multiple states. But, if it does use multiple save slots/states, then it sure would be nice to be able to use this idea instead.

The idea would be that you wouldn't bother trying to retain the save data in battery backed WRAM. It wouldn't be worth the cost of components and risk of lost data when you've got MBytes worth of flash at your disposal. That alone would offset the cost of the SPI flash chip with what's already on the board. You could have dozens of save slots if you desired with no added cost.

One more benefit I thought of: Increased PRG ROM space does NOT come at the cost of more logic. Once you comsumed the logic to implement serial flash an extra MByte or two doesn't really change the mapper as compared to parallel extensions which are costly with logic especially with MMC3.

You could make your own version of the Famicom Disk System basically.

I find it hard to believe that a homebrew game is going to come along and say, be bigger than Kirby's Adventure. And if one does, I'm sure they will tackle getting more memory when that challenge presents itself. But it's a neat idea.

Yeah very similar to FDS. And I agree about the homebrew size comment. Really I guess If I'm making the mapper and the game I can do whatever floats my boat. If people want to tag along great, if they just want to watch me make big headed ideas that never come to life and laugh I'm okay with that too at least I had fun and they got a chuckle.

It just seems like having no reguard for ROM space would result in a different more enjoyable design process as compared to developing the game with the intent to save space where possible until you run out, only then looking for a solution. You wouldn't want to go back and implant more detail in your levels, music, and graphics now that you effectively don't have a limit. I feel that it would be required to prove it's can be done with the hardware before hastily programming without concern for space. Really my best point of reference is thefox's streemerz project, something he discussed often it seemed was space and compression (maybe it just seemed that way because it made my head hurt), and I'm not looking forward to that part of my project...

If I had the option to use vast amounts of data for a low cost, I'd make a couple of kick-ass animation sequences just for the heck of it, even if the game itself would fit in a traditional cartridge.

My thoughts exactly... Characters and animations are the first thing I've decided to work on and that's where I'm currently at. I keep telling myself, oh well how could I reuse this tile? Or how can I do this animation with fewest frames?
EDIT: I should be asking myself how can I make this as kick-ass as possible?

I feel like I'm holding myself back where I wouldn't with this setup. And I'm not going to want to revisit this step much once I move on to the next part. Not that you can't make good animations within normal limits, it was obviously done by MANY production games. But those were also made at a time when memory of this size didn't exist or wasn't cost effective, but they undoubtedly had to put a lot of effort in to making that happen. I'd think the leverage of dirt cheap bits should be utilized if it makes my life easier.

Aside from time, I just can't get myself to start a serious NROM project because I know I'll end up throwing most of the code out for a follow on project using a mapper I truly want to develop on.

[tepples]

The idea would be to maintain the code that is always used on a standard parallel ROM, things like the game engine, user input, and music routines. Tepples suggested you'd need 128KB which seems more than sufficient and still cheap for a 'boot/engine' ROM.

Actually I was thinking of an 8 KiB boot ROM and a 128 KiB RAM so that the engine could be loaded from NAND too.

It'd also be an interesting way for someone to share a 'generic platformer engine' and allow someone else to fill in the details of animations, graphics, levels, and music.

Sort of like my original plan for President before I got sidetracked with other projects.

[tokumaru]

Actually I was thinking of an 8 KiB boot ROM and a 128 KiB RAM so that the engine could be loaded from NAND too.

This would certainly be more versatile.

[infiniteneslives]

The idea would be to maintain the code that is always used on a standard parallel ROM, things like the game engine, user input, and music routines. Tepples suggested you'd need 128KB which seems more than sufficient and still cheap for a 'boot/engine' ROM.

Actually I was thinking of an 8 KiB boot ROM and a 128 KiB RAM so that the engine could be loaded from NAND too.

I see, well something like that would also be possible. I'm slightly regretting my choice to leave DIP as the only choice for PRG-ROM. I dismissed the fact I couldn't get PLCC to fit well, but I should have considered SOIC. Not too much of a biggie though, something to consider for the next rev I guess. 128KB does come in DIP for a couple dollars more and less common but will do just fine for development. Then the 8KB boot ROM could go in the location on the PCB designed for WRAM.

This idea would make the board a lot more universal as well. Effectively ALL game data is stored on the SPI flash. So it really would be like our own FDS but using DIP-8 SPI flash instead of diskettes. More comparable to the Aladdin deck enhancer I guess. More interesting thoughts.... If we were to use something like this for the bi-annual homebrew compo you could just sell the new SPI chip and users could swap it out with their cart. A fair number of people own programmers capable of SPI flash programming so updates would be more achievable.

It'd also be an interesting way for someone to share a 'generic platformer engine' and allow someone else to fill in the details of animations, graphics, levels, and music.

Sort of like my original plan for President before I got sidetracked with other projects.

Yes but your original plan is probably more likely, you'd at least have my vote