i was thinking after reading the posts her about pushing the nes to its limits and about the "hellraiser" cart, and i had a strange idea. i would normally just describe my idea, but since i am sleep deprived and probably not making alot of sense at the moment, i made a nifty block diagram :)

what i am thinking, is using a microprocessor on the nes cart that uses the NES for input an output, but does the processing itself. then, have a basic library that programmers could use to make games for this cart, systems like screen bliting for multiple bg layers, transparency, etc. and basic nes input output. the only thing that i can think of that might be a problem , is finding a method to make sure the NES and the Cart dont both try to read or write to the expansion ram at the same time. this cart might be a little expensive, but if you do something like the Alladin deck enhancer that has a smaller cart connect to the main cart, it could be done in a cost effective way so that people could buy one cart with the microprocessor, and then as many "mini" game carts as they wanted (or as there are out).

PRG ROM:
1. load the boot code to control the security bypass circuit to disable the lock chip.
2. write $00 to $ff to NAM table, repeating every 8 rows
3. enable NMI routine
NMI routine:
1. write to certain byte of expansion ram to tell the microprocessor on the cart that vblank has happened (so we can help keep it in sync with the ppu to calculate where it is refreshing
2. grab joypad and other information write to expansion ram on cartridge
3. read information from expansion ram that the microprocessor has put there for the PRG rom to write to certain registers inside the NES (such as music?)

cart microprocessor:
1. run the game rom (could possibly be programmed in c/c++ so someone doesnt have to know/understand 6502 assemble, and so more people could program thier favorite 8 bit beast)
2. renders information in a screen buffer to CHR RAM, changing the patterns every 8 rows to get pixel X pixel control
3. maybe have the microprocessor cause an interrupt on hblank to have fun with the palette?


well, that is my basic idea, i have not thought much about the major technical issues that would be involved, but i bet someone could find a way to make it work, rite? and with any luck, someone would use this power to make a good ol' fashioned powerfull nes type game and not one of the new style 3d ones where you dont do anything special except run around :P

interesting

I like your idea. however, what I think would be best is if, instead of just plugging an 8K CHR RAM chip in for gfx, we eliminate the use of any name tables, and use extra circuitry to feed the PPU raw bitmapped data from a frame buffer. This would almost eliminate the requirement for using the PPU's hardware objects, as now the objects could be manipulated inside the frame store buffer with the second processor.

Additionally, color areas as low as 8*1 pixels would be possible. This would still force 8 sequential pixels to share the same playfield palette, but I was thinking that maybe objects could be used to hide some of the glitches that would occur when a pixel of another palette has to share the same color area with a different one. In this case, the second processor could also be in charge of compiling an OAM set, specifically designed to hide graphical color glitches.

But you see what I'm saying: each frame buffer would consist of 2*7680*8 bits of RAM for bitmaps, plus another 2*7680 bits for palette select values. Generally you'd have 2 frame buffers at all times: one that the PPU reads, while the other one is worked on by the on-cart processor (and the two swap places on VINT/NMI).

As far as the shared PRG RAM goes, it's easy to hide the fact that the device may be accessed simultaniously by the NES, and the on-cart processor. Since I'd assume that you'd want your expansion RAM to run at the speed of your on-cart processor, and that this will be running at least a dozen times faster than the 6502 (say like, 21.48 MHz), then it's just a matter of using some buffering logic to ensure that the 6502 always gets it's data when it needs it, while only stealing 1 bus cycle away from the main processor (so, like 1 out of 12 clocks available in the same time frame).

If you're really serious about building this thing, then I'll assist you to make sure that this is infact the most versatile and powerful NES cart ever developed.

>cart ever developed.

correction: "enhancement" device. (since it makes more sense to allow all this hardware to be shared with individual interchangable ROMs.)

That's interesting. I like Brad's idea of bitmapped graphics, too. Then the NES could possibly handle a game like Llamatron (one of my favorite PC games), or other shooting games with lots of sprites.

Though we're still kinda limited with the palette itself, and if a bitmapped background is used for software sprites, then even more so than usual.

I am going to try to build something like this sometime, but for now all my money is currently going to be tied up in another NES project. for now i am only thinking about this idea to see what all i can come up with for when i try to assemble something like that.

I am interested in this device and would like to hear more once you figure it out(I'm not a programmer, but I do have Electronics experience and an EPROM burner, so I might make one once it is ready (if possible)). I'd also like to hear some specs on it. ^^

I hope it would be used for a few 3-D titles as well as advanced NES games. I've played some 3-D games on the Commodore 64 that were fun, including a 3-D PAC-MAN type game that ran quite well. It even had an overhead map. I wonder, would this permit SNES quality games or close(I loved Starfox)? I'm also interested in hearing if it boosts both the total and displayable colors, as well as the music. Supposedly there was a Famicom game(not FDS) that had sound closer to the SNES than the NES. The game pak was large, though. It is called "Lagrange Point", I think.

Curse you, evil RF shielding! CURSE YOU, I SAY!
-MM007, the novice console case modder

>I wonder, would this permit SNES quality games or close(I loved Starfox)?

Well, that depends on what you mean. Even if the cart contained some hardware to force a conflict on the CPU bus in order to reprogram the entire palette in 16 clocks, that would still limit the programmer to 13 on-screen colors per scanline, plus whatever the PPU objects are programmed to display. However, there's no reason why any kind of rotation/scaling/etc. couldn't be possible: the on-cart processor would be handling all that. With that said, ports of games like Mario Kart, F-Zero, and yes, even Star Fox, could be possible.

When I have some time, I'll draw up some preliminary schematics for a cart with these capabilities. I'll post my project whenever I finish it (and that is, if, since it seems I'm currently swamped in about a dozen NES projects :)

>since it seems I'm currently swamped in about a dozen NES projects :)

hehe, who isnt these days?

With the sound, the Famicom has audio in/out connections on the cart connector, but the NES doesn't (only on the expansion port). We sorta got the shaft there. :|

MMC5 even has a 3 extra sound channels that can't be used for anything on the NES.

I'm hoping to get my revenge, though, heheh. Doing stuff with $4011 with an IRQ timer should have some good possibilities. That's something I want to try with the Maxicart, whenever that's available.

Lagrange Point was one of Konami's works, they had their own FM synth chip/mapper (VRC7) in the cart. Between the SCC on the MSX, VRC6, VRC7, and who knows what else, heh, those people at Konami never fail to amaze me.

It was mentioned that the expansion port had the extra sound-in. I was thinking, how about making a game with a cart and a ribbon that came out of that cart, so that the cart took advantage of both the normal and expansion connections. I also heard here that the cart could pass 10 bits of data directly to said port, so maybe you could use that for a kind of singal looping thingy(from cart to connector back to cart via ribbon cable) that could be used to time stuff(Usable on the NES->PC???). Heck, put it on the original Cart-microprocessor idea for timing. I was wondering, could the microprocessor be placed entirely on the expansion port, put the games in the normal slot in the control deck, and have the games use such an upgrade via a loader in the software(remember, 10 bits of data pass-through) that would activate the microprocessor and extra stuff in said module(If it also had a pin for video out of the NES or a pin directly connected to said video out, could you possibly make your module squeeze out more color, as well as more sound channels and better processing power? Then not only would you be able to play your "special" games, but get a faster one to emulate the "normal" 6502(small processor emu on EPROM, maybe?) to have more cycles and more smooth game-play(The timing loop thingy could limit its speed if needed).

Curse you, evil RF shielding! CURSE YOU, I SAY!
-MM007, the novice console case modder