nesdev.org

Seems like it'd be a pretty easy target for the INL-ROM board. I've got too much going at the moment to hook up a JTAG header and build a programmer though

The problem is that nobody will implement this on a PCB if there is no proper software to test it, and nobody will write software if there is no proper hardware to test it.

The only way to break this loop is to write an emulator extension that supports X-NROM, and to write a demo using this configuration.

Personally I think it's great to get an extra memory without bankswitching, but you get so little more than you might just as well optimize code and compress data for the same result, without the extra hardware and emulation incompatibilities.

Well, all you really need to do is write a good piece of software that people want to play that needs this. The funny thing is that writing a good game is a much harder problem than trying to trim a few kb. After going the distance to make a decent game, where do you find motivation to push new hardware at the same time?

Maybe someone would like to make an expanded version of an existing homebrew. Alter Ego with more levels and music, for example? A project like that might make the extra space worthwhile. (Still, this is kind of a situation where an existing mapper would normally solve the problem without much fuss.)


I've been working on a project with infiniteneslives to bring an NSF album into cartridge form, and for that one having a new specialized mapper made it drastically more feasible. I dunno if anyone will want to emulate it the new mapper, but we had motivation to create it because of the technical needs of the project. There's a similar story with Streemerz / Action 53, I suppose. You need to find (and execute) a worthwhile project that also requires the proposed hardware, and that's not an easy thing to do!

As a developer, it's not too hard to hack a new mapper into FCEUX or some other open source emulator, and use that to develop your software. That part of it is pretty easy to get going on. The hard part is making a game with it that anyone cares about.

The thing seems to be going to the second loop.

We have two emulators already. There is no need to have hardware to write a software for this mapper. To make hardware implementation happen we only need a software that is worth to be put on a cart. Not a test code.

I don't have time for NES projects currenty, and there aren't too many people who write NES games in C, so we'll have to wait for some time before a game that uses this mapper will appear.

qbradq wrote:Seems like it'd be a pretty easy target for the INL-ROM board. I've got too much going at the moment to hook up a JTAG header and build a programmer though

If you're interested in programming CPLDs on my boards I'd recommend the blackcat USB JTAG programmer. Those are what I use, they're on ebay for $35.

Bregalad wrote:The problem is that nobody will implement this on a PCB if there is no proper software to test it, and nobody will write software if there is no proper hardware to test it.

A test rom has already been written, and alterego was ported to this variant. It's been tested on real hardware. The things you say 'nobody will do' were done well over a year ago...

The hard part is making a game with it that anyone cares about.

Indeed...

I've got my boards configured with PRG A12-14 as inputs to the CPLD. It'd be trivial to implement, I've already provided the verilog earlier in the thread. If someone has a use for it I'll go through the trouble of putting it on one of my boards. But because there wasn't anything produced beyond a test/port and it was never requested it's been on the bottom of my 'to implement on my boards' list.

At that point I'd suggest something that makes better use of the hardware though if one were to go the CPLD route and presumably had 128KB of flash rom. Something like $6000-FFFF of linear fixed rom for code and a 4KB swapable bank at $5000-5FFF strictly for game data. That's about as basic as bankswitching could get IMO, and it effectively costs nothing in hardware. Even if one never used it, the bank would initialize to the first bank and could be treated as if there were NO bankswitching as long as the user never wrote to the bank select register. Then if at some point the user decided they wanted to store a little more game data and dabble with bankswitching they could start utilizing that bank they never touched previously.

Shiru wrote:No logic would be required, just three ROMs - PRG, CHR, and the extra ROM. The extra ROM would be basically 9th bit ('enable') for every byte of PRG, like D0 of the extra ROM connected to OE or CS of the PRG ROM.

Actually, it starts to look not that impractical, because price of the ROM chip is comparable with a CPLD, but you don't need extra tools to program that ROM, unlike CPLD.

OK before I'm engulfed in flames for necro'ing this post, Shiru is talking about a simple FSM; which was used before the widespread use of PLAs. I have seem designs from the '70 to decode complex switch panels as well as generating unique logic sums with PROMs.
The ADR lines are used as logic inputs and the DATA lines are the logic sum, depending on the stored values. Very complex truth tables could be designed.
The introduction of PLAs and uCs made this approach die out. In a way FPGA tech is very close to the same idea.
OK flashback over, sorry
Yogi

Yogi,

This community loves to necro-bump. This thread was last posted to like two weeks ago Interestingly enough, this technique is coming back in the FPGA world for complex address decoding thanks to having LUTs everywhere.

qbradq wrote:Yogi,

This community loves to necro-bump. This thread was last posted to like two weeks ago Interestingly enough, this technique is coming back in the FPGA world for complex address decoding thanks to having LUTs everywhere.

Haha, yea I suffer from 'ol' fart' flashbacks every now and then It's bad when I'm reading posts like this one, that cover a lot of ground.
Yogi

sorry for the further necro-bump, but I wanted to let you know that MESS now supports NROM368 extension, in case you want to use the MAME debugger to develop new software for this




at the moment, I haven't added support for the CNROM/CPROM extension, but if you have any software for that just point me to that and I will add it

I tried "alterego-nrom368.nes" and it doesn't seem to work in FCEUX 2.2.2. I thought support was added? Of course trying it in Nintendulator gave a bunch of 'illegal opcodes' after clicking 'run' (it paused itself for a reason, hehe).

No, FCEUX didn't add NROM368 support. IIRC, Shiru and I just both established that was easy and did it to our own local copies. (my patch had too much code duplication to be comfortable submitting it)