nesdev.org

Shiru wrote:46K with a single 74xx chip - that's neat.

Even if it can be accomplished with a single chip, BNROM can get you as much as 512KB, also with a single chip. I can understand this being an exercise you guys are doing for fun, but it's hardly practical when you can get 480KB at the same cost of these 14KB. The memory being contiguous is hardly an advantage, since there are things that can easily be offloaded to different banks, such as music code and data.

Offloading things to different banks requires knowledge of the 6502 assembler, compiler internals, and hardware layer in general. I seen this already, it is a serious obstacle for newcomers. In this case extra 14K is a nice thing to have, without any doubt. Of course, if you are not interested in programming in C (or other HLL) for NES, or in small scale projects, it is impractical, useless etc for you.

Isn't there a different 74 series chip that gets you up to 8MB?

Yeah you could use a 8x flipflop UxROM style to get 8MB but it obviously doesn't meet shiru's goal.

Edit: you'd give up the fixed bank that UxROM generally benefits from. Go down to 4MB and you could get it back with the addition of 8 or gates.

Shiru wrote:lidnariq, do you think, could this be considered a reliable design?

I'd trust it. I even have all 3 ICs necessary to try it out, but neither data nor a PCB.

There is a possibility that not all 74'85s use the same logic on nonsensical cascading inputs. But all the ones I've looked up just now — Phillips 74HCT85, Motorola SN74LS85, and Renesas HD74HC85 — all have the same truth table for the cascading inputs:
When A3…0 == B3…0, then:

• if only one cascading input is high, all 3 are copied verbatim
• if A=Bin is high, A=Bout is high and the other two are low
• if all cascading inputs are low, both A>Bout and A<Bout are high
• if both A>Bin and A<Bin are high and A=Bin is low, all outputs are low

If there exists some IC where we cannot get an inverting behavior, we can still get the 44kB I mentioned previously.

Seeing as the NES runs at only 2MHz, I strongly suspect the glitching will not be a problem. If you want to make an oversize variant of one of your existing games and have me try it out, I can, but it'll take me a little while.

----

Regarding bankswitching: C compilers *can* be written to deal with bankswitching elegantly. But CC65 isn't there. Without a call graph, you could just get away with putting the bankswitch command before every call; without a data "call" graph, you're basically entirely screwed. Even once you have these call graphs, you still need to do the search to map what data and code goes in what bank, dealing with relocations elegantly. All of these things, while not huge, are still probably a hundred hours of work to add to CC65.

lidnariq wrote:Without a call graph, you could just get away with putting the bankswitch command before every call; without a data "call" graph, you're basically entirely screwed. Even once you have these call graphs, you still need to do the search to map what data and code goes in what bank, dealing with relocations elegantly.

A call graph like this one?

I like the idea of the compiler minimizing the bank switching automatically, but this depends completely on the mapper, and for this reason it should be very complex.

I'd rather spend 100 hours improving CC65 to produce perfect code you couldn't tell apart from hand written assembly so I could code all NES games I want in a few hours and never deal with assembly again.

OK I exaggerate a bit but the idea is here.

A problem with CC65 is that it is not a NES compiler, it is a general 6502 compiler. NES has many mappers and specific memory layout, you would need to make a NES branch of the compiler to support these things. Generally it would be good to have many improvements in it, but for now we have things as they are, and it does not seem that there is a chance that something will change much in near future.

As for expanded NROM, there are things (that I consider) to do in order to make it practical:

- iNES format decision. I guess it will be 64K with the same layout as in actual ROM (top 32K, then a gap of 2K, then bottom 14K, then unused space). Probably still mapper 0, with extra memory detected by size.
- A modified emulator to be able to make some (test) software that will utilize the extra memory. Once there is some worthy software, I think authors of other emulators will support it.
- Hardware test.
- Popularizing the idea among homebrew developers and romhackers. Includes creating and publishing PCB layout.

The first thing that can run fairly independently of the rest of the program is audio. In fact, it can run so independently that Super NES games run it on a separate CPU with a separate address space. Loading tile data into CHR RAM is another thing that can run as its own self-contained deal. Perhaps the proper abstraction is to treat each PRG bank almost as a separate, cooperatively multitasked program that's linked up by message passing through shared memory.

As for "general 6502", don't the Commodore 64, PC Engine, Atari Lynx, and BBC Micro's "sideways" bus all use a 6502 family CPU and bank switching?

Shiru wrote: - Hardware test.
- Popularizing the idea among homebrew developers and romhackers. Includes creating and publishing PCB layout.

I know you guys are working on a design using the 74 series chips. As I see it the biggest obstacle to getting a published PCB is quantity. You can make a prototype PCB fairly cheaply if you accept thicker PCBs. I don't suggest that if you have respect for your 72 pin connector. I've created my own 72 pin connector that has no issue with them. Depending on the design it's possible 60 pin connectors might not be an issue.

Quantity is key for PCB cost and using something like the specialized 74 series design or flag rom is basically only good for that mapper. That's one of the biggest reasons I push for CPLD's, they are EXTREMEMLY versatile. With a well designed PCB you could support NROM through MMC3+ on the SAME PCB. This is my goal with my MMC3 reproboards, to not have limited mappers. Now to make this mapper with my boards it would require a CPLD, but it'd only be $1.20. Yes it might be $1 or more than a single discrete chip that's design is yet to be proven. BUT if 100's of these PCBs are purchased vice a couple dozen, the CPLD effectively becomes FREE.

I now I hadn't planned to include PRG A11 or A12 as possible mapper inputs because generally no mapper would make use of them. This design would be the exception. If else contributes to a test rom, and emu support (even better yet: a game) I'd consider this mapper serious enough to support on my PCB's. I've been trying to think what to name them for awhile. Call it vain if you'd like but this morning INLROM came to mind.

If you'd like to test something sooner vice later on actual hardware the first easy step is a devcart. If someone whats to write up a simple test rom I can create the mapper and run in on the NESDEV1. It would only take a few minutes with good mapper definitions. Maybe just a rom that verifies all of the new addresses are properly read from with no issue.

I don't mean to take over the design or anything, and I'd support where I could if someone else want to make the discrete or flag rom design. But my guess is there aren't too many other people willing to step up and invest the cash in a substantial number of PCBs to make this a reality. If my proposal offends anyone I'll quietly step down.

In regards to the file format, maybe it's just me but it makes more sense for the added address space to come AFTER NROM's $8000-FFFF. I know it's backwards to how things are actually set up, but when I think about designing the mapper and programming the NESDEV1 it makes more sense. I imagine address $0000 of the physical rom being $8000 of the NES and $8000 of the NES being $0000 of the rom which is the way it is currently. Also as you designed a game with this mapper you'd fill the begining of the file first with the traditional NROM filespace, and then spill over into added memory. I guess we'll have to see what makes sense to someone who'd right the emu support as well. Also the gaps would actually be filled with padding data vice just jumping to 'save' file space. Just denote the size as 64KB in the header as mapper 0.

The same PCB that is needed for this 'mapper' could be used for NROM with few jumpers. I'm pretty sure that there always will be way more NROM finished homebrew games than finished homebrew games that use any mappers (but vice versa for unfinished projects).

I honestly don't see any problem with PCBs prices. Don't know, maybe it is something region specific, and it is very expensive in US, but here in Russia hobbyists produce tons of DIY retro computers and devices with large PCBs, and it is affordable enough with quantifies of tens.

If there is an universal PCB for CPLD based mapper, this does not make discrete logic version obsolete, since you don't need a programmer to program 74xx chip, and you don't need someone to write mapper code for the CPLD as well. Both can co-exist, having many options is a good thing.

It's just that you need to invest a couple hundred dollars to get PCBs that are only a few dollars each. In the past not many people have been willing to invest the required money. Sadly most people willing to invest in PCBs are making repros and they generally choose the $2-4 solution for board, CIC, and case from donors. It's difficult to compete with prices of hacking carts... So far bunnyboy is the only one to keep something like this going with his retro boards.

Well, first things first. There is a lot of things to do before any PCB production, and making a PCB layout won't take too much time to worry that it will have low chances to be used.

So, making clear the ROM format. I think it should be like this (ROM offsets without the iNES header):
Because it is located in the chip that way, so it would be possible to simply cut off the iNES header and burn the binary into the chip.

So we have NROM extended to 3 pages, with the third mapped to $4000-$7FFF (first 2 KiB inaccessible). This can be identified with mapper=0 and PRG size=3. We might as well extend CNROM the same way, no? I'd make a test ROM for this, but how would I emulate it to test it?

I can whip up the mapper this evening and run your rom Tepples. You should be able to do the easy test of $6000-8000 if you denote SRAM in the header, most emus support. (can always test with yggi's pogo cats battery)

Do we want an even 64KB (4 pages) or odd 48KB (3 pages)?