nesdev.org

So I finished the mess of wires that is my current prototype of INL-ROM:


I had high hopes of ordering the boards Monday, but as luck would have it my Xilinx JTAG programmer crapped out. I wasted all night yesterday trying to get it running and took a stab at making my own but no luck... To make my life easier for when a new programmer shows up in a couple days I created testbenches and fully verified my code running on the CPLD's. No issues there, so I'm pretty confident with the whole design now. Assuming all is well with this new programmer, I'll be sending off the files this week after checking a couple things I can only do with hardware.

tepples wrote:Could you consider a 512/32 version for people who don't need CHR ROM support and think they can make the next Mega Man 4/6?

I think I can do a little better, what about using the last 4KB to facilitate 4 screen mirroring as well?

Dropping CHR down to 32KB (presumably VRAM) gives a LOT of breathing room for the available logic. I know the idea of making new mappers raises a lot of brows around here, but I can't help but spill the beans on what is coming down the pipe. Getting the thing released as STOCK FULL MMC3 and others is the priority here supporting repros/hacks and the likes. All of this nonsense to follow won't be ready until I've had time to play around with it, write a test ROM etc. Basically I'm not looking to change the MMC3 much for this 'homebrew/hybrid' version, just attempt to make full use of what hardware is already on the board. To keep things simple I don't think I'll allow much configurability to the user for this alternative mapper choice. Some things will be limited to make room for improved functionality in other areas.

Firstly I was reminded the other day of how something like this would be great with chykn's ENIO that I'll have in my hands shortly. The simple thing is to support the "direct addressing" mode of his device by porting PRG R/W and /CE through the EXP pins. Beyond that, I'm looking to make some slight modifications to the MMC3 allowing for Flash PRG-ROM programming via his IO. Not sure how I'll do the boot-ROM yet, I've thought about reserving a ~64KB sector of the 512KB flash for the bootrom. Somewhat dangerous, but I can build some safeguards into the mapper blocking unintentional writes to the bootrom sector.

Aside from compiling up the idea of using the 32KB for name, attribute, and pattern tables; I also compiled a way to utilize the 32KB of WRAM. Previously I was thinking of adding some register below the WRAM. I found an even better solution though, since it's only 2 bits, it'd actually fit in the first 'control' register's unused bits. Just directly mapping 2 of those bits (D5-D3) to WRAM A14 & 13. The other idea would be to use the $A000/A001 registers could be used instead. I've still got around 20 macro cells to work with at this point.

I've got a few other ideas kicking around, but not enough data at this point to be sure that I can provide them yet.

Impressive prototype. Sorry to here about the dead programmer. I hope you get it all sorted out and we see new MMC3 boards soon.

Aside from compiling up the idea of using the 32KB for name, attribute, and pattern tables

Anything specific fleshed out here yet? (I kinda like the MMC5's mechanism for specifying extended banking)

infiniteneslives wrote:Previously I was thinking of adding some register below the WRAM. I found an even better solution though, since it's only 2 bits, it'd actually fit in the first 'control' register's unused bits. Just directly mapping 2 of those bits (D5-D3) to WRAM A14 & 13.

A yearish ago, Tepples was asking about the possibility of banking WRAM with MMC3 (discussion on the wiki); one thought that would be trivial but perhaps awkward would be enabling a 4kB RAM window in the $5000-$5FFF page. This would then track the bank setting for the $C000-$DFFF bank in the MMC3. Although not directly supported by the MMC3, it's a hardware modification that's just a simple variant on the standard "add prg ram" circuit— half of a 74'20 (/(M2·/ROMSEL·A14·A12)) to get a 4+4F RAM banking.

The other idea would be to use the $A000/A001 registers could be used instead.

See also the MMC6: It's not unprecedented to reinterpret the bits of the PRG-RAM protect register.

lidnariq wrote:

Aside from compiling up the idea of using the 32KB for name, attribute, and pattern tables

Anything specific fleshed out here yet? (I kinda like the MMC5's mechanism for specifying extended banking)

So the MMC5's setup of mirroring is still limited to 2 NT's plus EXRAM for a 3rd choice, and fill mode for a forth. In contrast my idea was just straight up 4screen mirroring. I would completely disable the 2KB VRAM on board, and make a simple change to the CHR bank select circuitry that would enable the last 4KB of CHR RAM when CHR A13 is high. So from a programmer's perspective you'd just have 4 sets of NT and AT from PPU $2000-3FFF. So really there wouldn't be any mechanism to control from the programmer's view. The only thing you'd want to keep in mind though is that you wouldn't want to set any of the CHR bank select registers to point to the last 4 banks (4KB). You actually could if you really wanted to, but you'd end up rendering the NT/AT as pattern tables (trash/static basically). My setup is really just double using 32KB of SRAM for name, attribute, and pattern tables to give you true four screen mirroring without any additional cost. The logic required to do so is about the same to implement normal MMC3 mirroring so it effectively comes at no logic cost either.

A yearish ago, Tepples was asking about the possibility of banking WRAM with MMC3 (discussion on the wiki); one thought that would be trivial but perhaps awkward would be enabling a 4kB RAM window in the $5000-$5FFF page. This would then track the bank setting for the $C000-$DFFF bank in the MMC3. Although not directly supported by the MMC3, it's a hardware modification that's just a simple variant on the standard "add prg ram" circuit— half of a 74'20 (/(M2·/ROMSEL·A14·A12)) to get a 4+4F RAM banking.

So if I were to answer Tepples' question from that discussion, with my MMC3 would output high on all upper address bits when enabling WRAM. That's because I only base the A13 and above upon the current status of PRG A13 & 14 on the NES. Them being high for $5000-5FFF would be the same as enabling the last bank of PRG ROM. I'm pretty sure what's what you and Drag were saying.

I could base the WRAM bank off of the bank selected for $C000-DFFF, but I don't see much benefit. It'd actually make the logic more complex than just using something like the lower bits of the $A001 register and always mapping those bits to WRAM A13/14. This also seems simpler to program because you don't have to keep track of what reg6 is mapping to.

Aside from this stuff I'm hoping to tidy up the Scanline counter. I did some checking with my logic analyzer previously that confirmed that Tepples' idea of sensing scanlines based on CHR A13 should be pretty simple. It would end up firing IRQ later than the actual MMC3 (a little after sprite fetching instead of immediately) This should remove sprite/background restrictions and no longer require careful use of $2006/7. Additionally it would require significantly less logic to sense scan lines in this manner so it should free up some logic space. One thought I had was to try and implement a RAMBO-1 style counter that could be used to count scanlines or CPU cycles and be able to change on the fly. None of this has been tested yet though, just ideas and brainstorming for the most part.

Beyond that I didn't really have anything on the plate for minor improvements/additions to my MMC3. If you have ideas/requests though feel free to share, there won't be room for logic but there is a sizable amount, simple stuff like more PRG-ROM is possible. Hmm now that I think of it, with some luck there should be enough for some MMC2/4 latch style bankswitching though.

infiniteneslives wrote:

A yearish ago, Tepples was asking about the possibility of banking WRAM with MMC3 (discussion on the wiki); one thought that would be trivial but perhaps awkward would be enabling a 4kB RAM window in the $5000-$5FFF page. This would then track the bank setting for the $C000-$DFFF bank in the MMC3. Although not directly supported by the MMC3, it's a hardware modification that's just a simple variant on the standard "add prg ram" circuit— half of a 74'20 (/(M2·/ROMSEL·A14·A12)) to get a 4+4F RAM banking.

I could base the WRAM bank off of the bank selected for $C000-DFFF, but I don't see much benefit. It'd actually make the logic more complex than just using something like the lower bits of the $A001 register and always mapping those bits to WRAM A13/14. This also seems simpler to program because you don't have to keep track of what reg6 is mapping to.

Sorry, I must have stated myself poorly. What I meant was "because the original MMC3 ignores /ROMSEL for banking, if you map RAM into $5000-$5fff, it'll follow the bank in $d000-$dfff". Shouldn't be any more complicated in hardware, although it is definitely weird enough to be of dubious utility.

Beyond that I didn't really have anything on the plate for minor improvements/additions to my MMC3. If you have ideas/requests though feel free to share, there won't be room for logic but there is a sizable amount, simple stuff like more PRG-ROM is possible. Hmm now that I think of it, with some luck there should be enough for some MMC2/4 latch style bankswitching though.

The ideas that come to mind in the bucket of "probably sufficiently simple" are 1- FME-7's ability to bank PRG ROM into $6000-$7fff, 2- automatic IRQ redirection so that the vector for the MMC3 IRQ is pre-separated so that the software doesn't need to check/only use one of the different IRQ sources, and 3- automatic controller DPCM-deglitcher by watching for reads and writes to $4xxx, clocking on reads and stopping the shift register after 8 bits have been read.

infiniteneslives wrote:In contrast my idea was just straight up 4screen mirroring. I would completely disable the 2KB VRAM on board, and make a simple change to the CHR bank select circuitry that would enable the last 4KB of CHR RAM when CHR A13 is high. So from a programmer's perspective you'd just have 4 sets of NT and AT from PPU $2000-3FFF. So really there wouldn't be any mechanism to control from the programmer's view.

Which would make it harder to have a status bar. When revising one of NovaYoshi's mapper ideas over the past couple days, I came up with a different plan: allow switching between standard mirroring modes in CIRAM and a four screen mode in CHR RAM $7000-$7FFF.

lidnariq wrote:Sorry, I must have stated myself poorly. What I meant was "because the original MMC3 ignores /ROMSEL for banking, if you map RAM into $5000-$5fff, it'll follow the bank in $d000-$dfff". Shouldn't be any more complicated in hardware, although it is definitely weird enough to be of dubious utility.

Ahh I get it now I didn't pick up on the fact it would be different at $5000. Yeah it wouldn't take much more logic to allow something like that assuming my direct mapping of $A001 bits wasnt implemented. The combination of yours and my solution wouldn't be a good use of the limited logic though. One thought would be to use my idea but only control A14 with the mapper, and just connect A13 to the NES. It'd be even simpler logic, but you'd loose 8KB of WRAM because you'd just have two 12KB banks. If one had a hard time even utilizing 4 8KB pages of WRAM that loss of 12KB might not be an issue. More Linear WRAM seems like a better benefit than the full 32KB, I'm just speculating though...

The ideas that come to mind in the bucket of "probably sufficiently simple" are 1- FME-7's ability to bank PRG ROM into $6000-$7fff, 2- automatic IRQ redirection so that the vector for the MMC3 IRQ is pre-separated so that the software doesn't need to check/only use one of the different IRQ sources, and 3- automatic controller DPCM-deglitcher by watching for reads and writes to $4xxx, clocking on reads and stopping the shift register after 8 bits have been read.

1- what is it exactly that makes having a prg rom bank at $6000 appealing? This probably wouldnt cost too much logic, but it'd probably be low priority unless I'm missing some benefit that'd make it worth the logic cost.

2- how would you imagine preseparating the IRQ? I'm not familiar enough with other IRQs to realize a way to do this more easily than how they are normally distinguished. Oh wait... What if the mapper always switched to something besides the last bank upon the issue of a mapper IRQ. How much time/trouble would this really save though?

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

Tepples: I like some of your ideas there with the Nova. One comment though, I think you might be under estimating the CHR window logic. That arithmetic is going to suck up some considerable logic I would guess.

But I see what you mean about the status bar difficulty. I'd have to check some things, but I think it'd be simpler logic to implement H/V mirroring from the same on cart VRAM by just fixing A10/11.

Also, would you mind branching off these last few days of discussion about a hybrid mapper to another thread? I don't want to confuse people interested in only the stock mapper styles. Thx.

lidnariq wrote:The ideas that come to mind in the bucket of "probably sufficiently simple" are 1- FME-7's ability to bank PRG ROM into $6000-$7fff, 2- automatic IRQ redirection so that the vector for the MMC3 IRQ is pre-separated so that the software doesn't need to check/only use one of the different IRQ sources, and 3- automatic controller DPCM-deglitcher by watching for reads and writes to $4xxx, clocking on reads and stopping the shift register after 8 bits have been read.

None of these ideas are really worth wasting hardware resources on, IMO.

1) When you already have two switchable 8K banks and two fixed 8K banks, having a third switchable bank doesn't really help much (two switchable banks + a fixed bank really is the sweet spot IMO, it's so much better than for example UxROM's one switchable bank + one fixed bank because you can map code in the other bank and data in the other, whereas with 16K banking you have to either fit all of your code in the fixed bank or always worry about not being able to easily switch data in when running code from the switched bank).

EDIT: OK, there's one case where a third switchable bank could be useful: DPCM. Even in that case it would be just as useful to have 3 switchable banks at $8000-DFFF and one fixed bank at $E000-FFFF.

2) If you have a scanline IRQ, I can't really think of much reason to have any other IRQ sources (e.g. the DPCM IRQ and frame IRQs are mostly useless).

3) Not worth it to save ~500 or so cycles extra that it would take to do this on software.

infiniteneslives wrote:Also, would you mind branching off these last few days of discussion about a hybrid mapper to another thread?

PM me exactly which post IDs need split and I'll do it.

It was just brainstorming :p

infiniteneslives wrote:1- what is it exactly that makes having a prg rom bank at $6000 appealing? This probably wouldnt cost too much logic, but it'd probably be low priority unless I'm missing some benefit that'd make it worth the logic cost.

thefox wrote:1) When you already have two switchable 8K banks and two fixed 8K banks, having a third switchable bank doesn't really help much (two switchable banks + a fixed bank really is the sweet spot IMO, it's so much better than for example UxROM's one switchable bank + one fixed bank because you can map code in the other bank and data in the other, whereas with 16K banking you have to either fit all of your code in the fixed bank or always worry about not being able to easily switch data in when running code from the switched bank).

EDIT: OK, there's one case where a third switchable bank could be useful: DPCM. Even in that case it would be just as useful to have 3 switchable banks at $8000-DFFF and one fixed bank at $E000-FFFF.

I was specifically referring to FME-7's having 4 switchable banks plus the fixed bank at $e000. Is it obviously useful? I dunno, it keeps you from having to save context. The four banks could be something like "DPCM stream", "music data", "level data", "game code".

infiniteneslives wrote:2- how would you imagine preseparating the IRQ? I'm not familiar enough with other IRQs to realize a way to do this more easily than how they are normally distinguished. Oh wait... What if the mapper always switched to something besides the last bank upon the issue of a mapper IRQ. How much time/trouble would this really save though?

A fair amount, depending on how frequently interrupts come; interrupt ringdowns are present in almost all computing designs.

thefox wrote:2) If you have a scanline IRQ, I can't really think of much reason to have any other IRQ sources (e.g. the DPCM IRQ and frame IRQs are mostly useless).

But that's a fine point.

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.

3) Not worth it to save ~500 or so cycles extra that it would take to do this on software.

I disagree; 500cy is actually pretty huge, reliably always the same amount of time is better, and DPCM no longer conflicts with certain not-rereadable things (e.g. Arkanoid, SNES mouse).

What is DPCM deglitching? Is there a thread somewhere or a wiki page I could read about this? (Trying not to derail topic further.)

rainwarrior wrote:What is DPCM deglitching? Is there a thread somewhere or a wiki page I could read about this? (Trying not to derail topic further.)

viewtopic.php?f=2&t=4116

I know about the read conflict, but how would a mapper "deglitch" it?

The seeming read still happens; the 6502 inside the NES just isn't listening. By mapping a shift register that will pay attention to the same bits that the software would, you can make sure something listens, and then save the results for the NES. (Is that clear enough?)

In other words, something like this would work: But given the existence of devices that return 16-bit (Super NES controller), 24-bit (Four Score), or 32-bit (mouse) records on D0, or records on D3 and D4 (Power Pad and Arkanoid paddle), that could take a big CPLD with a lot of memory.