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.
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.
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.