nesdev.com

Actually Akumajou Densetsu/VRC6 can easily fit onto a CPLD, it requires about 120 macrocells. VRC7 can probably too, I haven't tried. All games with similar bankswitching schemes have similar requirements.

Also both protection against writing PRG and CHR ROM is very simple, all it requires is two register bits and two OR gates to lock the /WR pins on the RAM.

VRC7 bankswitching could fit easily enough, but forget about trying to fit the sound in such a small chip (because Lagrange Point is effectively nothing without its magnificent music).

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

There's always Tiny Toons 2 J and homebrew potential which deserve an implementation.

8 MiB? No NES or Famicom game is larger than 1 MiB, apart from multicarts.


Are you sure about these drawbacks of PSRAM? Can you cite sources?


SuperCard has a 32 MiB RAM (to hold the running program, believed to be some form of PSRAM), a 64 KiB RAM (for saving), and an ATA interface (for reading the CF card).


SuperCard patches GBA games for three reasons, mostly related to saving:

1. There are three GBA mappers, distinguished by how they save. Patches mapper-hack games that use the serial EEPROM mapper or the 8-bit flash mapper to use the 8-bit SRAM mapper instead.
2. SuperCard save memory is not battery backed. Patches make the game occasionally write the SRAM to the CF card.
3. "Exit hack" allows the game to go back to the menu.

The DS, on the other hand, acts more like the FDS because the DS card is a block device. SuperCard patches DS games to read and write a file on the CF card instead of the DS card (which sits in another slot).


We have to decide: Are we trying to make carts solely for development and piracy, or should we consider how to make carts for replication once we get some sort of lockout defeater working?

Nope, but I was only babbling on about my current project, which is a USB MSD cart for the Sega Mega Drive. For a NES equivalent, the RAM size wouldn't be a problem since the price of 1MB-2MB of SRAM is still reasonable for the cart's functionality. But there, the choice of a suitable FPGA is a bigger dilemma.



No, I'm not certain. Only thing I know is that I've spent countless hours googling "PSRAM" along with other keywords, and have never managed to find any evidence for PSRAMS in non-BGA packages. And all sites I found had no pricing information. I only tried to ask for pricing information on one of Samsung distributors here in Sweden, and they informed me that they don't have it in stock and that the minimum order quantity from Samsung is 3,600 pieces. But if you find evidence to counter my somewhat premature claims, no one would be happier than I.

Hey, just to go a total different way....
As long as Artos' Flash Cart can run 95% of existing NES games (commercial and homebrew) duplicate it isn't very much necesary.
So if the option would be to build a cart with super-powerfull mapper instead, I think that would be cool too.
I have a nice idea : A PIC or similar microcontroller could write data into an external RAM during the frame, and a programmable logic circuit would read it for the previous frame in order to replace normal attribute and maybe pattern table data by graphics that would be buffered in the external RAM (there exists chips that have a different bus for reading and writing for this kind of purposes...) Also, the NES CPU would just tell instructions to the PIC processor trough a communication bus and registers, and the PIC would handle parametring and comunicating with the programmable logic circuit, but during rendering all the fast operations would just be read by the logic circuit trough the RAM buffer. The programmable logic circuit could also hold some PRG bankswitching and IRQ counters.

This is just a basic sheme of how a very modern and powerfull NES mapper would be. Then, color resolution can go up to 8 pixel horizontally, and 1 pixel vertically, but unfortunately you're stick with 4 BG palettes, wich make things pretty limited. However, quite nice effects could go, including :

- Show raw 13-color bitmaps wich are just stored in a special format with this horizontal limitation. Videos could even be displayed, but that would waste a lot of memory !! Also, only a small portion of the screen could use such graphics for example just a face picture in a RPG that would be more detailed.

- Do transparency effects (no flickering). It's common use to have NES palettes composed of the same color, but with different light intensity (i.e. $0f, $07, $17, $27; $0f, $01, $11, $21, etc..) because it allow luminosity effects and make games look a lot nicer (at least to my personal experience).
So the chip could manually add '1' or '2' to given pixels regardless of scrolling, and by overlapping the color addition to the nomral color, this would create AWESOME light&transparency effects on the NES !

- Very fast moving BG data : Typically, the NES programm could tell the pic to render very different images in the buffer from one frame to another and trus do a lot more than what normal NES BG can do without any particlary complicated algorithm in the PIC : Typically move a fighter totally in BG in a fighting game to trick the 8-sprite limitation.

Of course, multi-layered background, polygon rendering of 3D images and mode-7 comes in mind, but that would work only in 4-color mode and would look very bad I think. I personally would prefer the effects I listed above to those classic things everyone has in mind. I hope this will give everyone some ideas. I'm not hoping something particular to be made, just imaginating pushing the NES cartridge connector to it's limits !!

_________________
Life is complex: it has both real and imaginary components.

So without selling copies, how does a developer eat?

Well, anyone hoping to put food on his table thru NES game development should be prepared to loot the local garbage cans for lunch.

I didn't mean "day job". I meant "something that makes the whole effort not a complete waste of time".

I'm not much interested in money, and I hope noone in this board is. What I'm interested in is to programm for the NES system. Pushing the hardware in it's limits is something interesting.

_________________
Life is complex: it has both real and imaginary components.

I like the idea, I remember thinking of something similar a while back too. I also drew part of a schematic for allowing the NES CPU to write to VRAM at any time. Using discrete parts though there were 6 octal bus drivers, amongst other stuff. It requires a lot of I/O pins any way it's done. I also never figured out exactly how to generate a write cycle without doing some real dirty tricks or using expensive/rare parts.



AFAIK they're expensive, very small, and you still actually can't write and read them at the same time. Seems to only move the pin count over to the RAM chip. I think it'd be better to use a standard RAM through some wild custom interface like Bananmos mentioned earlier in the thread.

Actually right now I'm looking at different chips that I could upgrade my Squeedo PIC to. Would be really great to switch to dsPIC, but Squeedo uses the PIC's parallel port to great advantage, and no version of the dsPIC has that. Haven't found a decent way to replace it..

Actually one solution that comes in mind would be to use TWO chips of RAM, to crate a double-buffered frame buffer.
You'll need a PIC with a lot of I/O pins. Also, there exits SRAM chips with IIC interface, but I think they're rare and much slower than parallel 62xxx SRAM chips. The PIC would just open it's bus on one chip, and deal with the other chip, while the discrete logic componant can read the first chip. On next frame, the bus that was open by the PIC become used, and vice-versa. Not sure how hard it would be to do and how well it would work.
Another idea would be to have the PIC only dealing with it's internal memory during the frame, and during VBlank, the programmable componant would trigger a kind of DMA trough the PIC from it's internal RAM to external SRAM/DRAM, and then during the frame the PIC could do it's rendering work again while the programmable componant would adress and read the frame buffer SRAM/DRAM and deal with the PPU bus. That solution sound almost idea, but I don't know if such a DMA is possible on PICs. Maybe on dsPICs.

I'm unsure of what parallel port you're talking about. You mean the PSP module, or just normal ports you can freely write to and read from ?

_________________
Life is complex: it has both real and imaginary components.

Yes, the PSP. I did some reading up the other day on Microchip's site, and actually the PIC24 sounds very nice. Some of them have a PMP (Parallel Master Port) for writing memory, and a DMA too (I'm not sure if that extends to the PMP peripheral, it very well might). It's a 3V chip with some 5V tolerant inputs, I was getting tempted to design it into Squeedo until I noticed the flash can only be written 1000 times.. That's quite a few times, but very reachable for someone doing PIC experimenting.

Sadly (or not, it's a pretty damn fun chip), I'll probably just stick with my current PIC18F family. Maybe upgrade to the newer one with a bit more flashrom (which would be the 4th PIC upgrade for Squeedo, wow, all with the same pinout too).

PMP peripheral is coming to some PIC18 chips too, but they all seem to be "future products". Probably not a DIP-40 one though. DIP-40 sure takes up some PCB space, but it looks oldschool as hell and sure beats soldering .5mm pitch pins!

The double-buffering thing sounds like a fine idea too. Damn, all this PPU hackery would be a bit easier if we had an equivalent of the M2 line for the PPU. Really I don't even know if it's been established that the PPU bus ever goes tri-state. I know it's multiplexed, because it has that address latch internally. Damn, I should've kept notes when I was working on my crazy mapper a while back, heh.

Isn't the M2 line the main 22.??? MHz clock ? If so that'd be fabulous, because you could just made it the external oscillator input for your PIC. However, the lenght of the connector contacts could significantly bring high noise to that fast clock. I don't know if that's what you have been doing, since nobody had any shemtics, and all pictures are down now.
1000 times is a lot, but if you manage to programm it on board, it will be actually not quite a lot. The main issues with PICs is that there is so many different version of them with so slight differences !!
It's a very fun thing, at work I'm working with PIC 18F252 and 18F2525 wich are the 28-pins counterparts of those you used on your squeedo, 18F452 and 18F4525. That's pretty much a micracle, considering how many different 18xxx there is on the market (above the hundred).
PIC24s looks good, but I don't know what you would gain from a 18xxx exept speed, if you use an external oscillator independant to the NES' wich I definitely wouldn't do for evident syncronisaiton issues.

Yeah, I agree DIP-40 looks oldscool as hell Actually even DIP-28s looks somewhat oldscool, while DIP-28 large looks just normal. A chip looks oldscool when it's much longer than wide, definitely. However, regardless of looking, a great advantage of DIP chips is that you can just programm them without any expensive adapter. This of course is no longer significant when you get on-board chip programming. An advantage of PLCC package would be that you can use very-low profile sockets to fit a cartridge plastic case.

If you need any help, don't hesitate to ask. Many people are very top-knownledged on detailed PPU operations I have trouble to undestand (especially Blargg and Quiestus), and I think I have some experience with hardware stuff such as shematic design and microcontroller programming, so don't hesitate to ask for ideas ! Squeedo sounds great, and improving it sounds even better !

_________________
Life is complex: it has both real and imaginary components.

Maybe you oughta wait with redesigning Squeedo for just a moment... it seems the lockout chip is about to be 0wn3d finally, and if the CIC functionality could be easily emulated by an MCU and some buffering logic, that mission alone justifies making a custom board with an MCU in it. :)