Okay, some people seems to have tried developing an universal NES rewritable cartridge and everyone seems to have ended more or less on a failure. I still think it's a very cool idea and would be *very* pratical for overall developpement, so I'm just brainstorming what a such cart would need :
- Mediup-range inexpensive FPGA, if possible entierly in 5V, but else it would have to have 5V tolerent inputs. The FPGA should dissipate negligible power, because of course put heatsinks in a NES cart is impossible
- 3.3 Volt regulator (optionnal), could be made with a set of resistors and an op-amp
- 3.3 Volt to 5 Volts level transactors (optionnal).
- Min. 512kb PRG Flash ROM to be put on the CPU bus
- Min. 32kb of battery-backed PRG RAM to be put on the CPU bus. Will emulate WRAM, Saved-WRAM and FDS RAM.
- Min. 512kb of battery backed CHR SRAM. Will simulate all sizes of CHRROM and CHRRAM, on a single chip. (optionally two chips, but don't think it'd be needed to have flashrom)
- Battery backup magagement system (either integrated or discrete)
- Lockout chip defeater MCU (optionnal)
- 8-bit DAC to use external audio (less bits could be used by setting a R2R ladder manually on the cart without any intergreated device).
- USB management device for rewriting
- USB port
- Software to communicate with the cart
Just want to know what would be seriously lacking with a such configuration (assuming the FPGA has full control on the CHR bus, PRG bus and all chips input pins).
It certainly sounds nice. But the whole versatility/emulating all the mappers you can is clearly what casual rom players want. For development/homemade games, wouldn't it be easier if someone designed a programmable (Flash) cartridge that had a mapper with enough features for whatever your project may need? Wouldn't it be possible to make your own chip that emulates the MMC3, or another nice mapper, and use it in a flashable cartridge? Perhaps just make your own mapper all together.
I'm sure it'd be nice to have one very flexible cartridge that could run every game no matter if it needs WRAM, CHRRAM, CHRROM, MMC3, MMC5, etc. But that seems like a pretty tall order. But perhaps if someone didn't shoot for Mars, but only for the Moon, we might all actually be able to buy a NES Flash Cartridge.
I think one mapper would work, although it would be nice to have either 2 versions (one CHRRAM, one CHRROM) or one that could toggle between the two.
Just an idea. Afterall, people can hack up NES cartridges pretty easily, but making one that can emulate all the different configurations is alot harder than just making a cartridge that doe a single configuration. It would be really nice to be able to just buy an already assembled and ready to go NES Flash Cartridge, even if it was only say MMC3 with CHRROM, or MMC3 with CHRRAM. I imagine that would be a popular choice because of all the commercial games that used it. However like I said maybe you'd want to create your own memory mapper (which would be obviously for development/homebrew) and you could have whatever features you want. Like being able to swap small bits of CHRROM or whatever floats your boat.
Really I think part of the reason we've yet to see a commercially available NES Flash Cart is because they are aiming too high and it takes alot longer to do than something not quite so ambitious.
I think you have too much hardware going on there even if everything is SMD. How will your FPGA be configured? Will it be initialized through a SEEPROM?
I still feel that FPGA + FlashROM is a foolish design. The only way FPGA would be justified IMO is if there is RAM instead of Flash and a massive Flash storage device (CF)
Also having 512KiB of SRAM is VERY expensive. FPGA are VERY expensive. Level translators are semi-expensive and take up a lot of boardspace.
I would prefer a simpler design which is even more practical:
-Base unit which can dump games and flash the flashcart made from one CPLD.
Flash cart:
-512KiB PRG and CHR Flash (can be written 10,000+ times)
-32KiB WRAM battery backed
-32KiB CHR-RAM
-CPLD A 84-100 pin - 140 macrocell (can be written 10,000+ times)
-CPLD B 44 pin - 32 macrocell or so
This design would allow people to legally backup their games and would be 100% nonvolatile.
Busconflict and SRAM decoding can be done by the smaller CPLD, this CPLD would not have to be reconfigured. It would also act as a bidirectional tristate buffer and Flash security. The smaller CPLD will also have 32K/8K PRG bankswitching just to Flash the ROMs when the big CPLD isn't configured.
When asserting a specific address (such as $4FFF) on the base unit, the data bus would then propagate to the JTAG connector to configure the large CPLD. The Flash and WRAM can be written directly by the base unit without having to go through the CPLD like Funkyflash. This method would be extremely fast unlike Funkyflash.
My design has only 6 active parts for the cart, one active part for the base unit.
To keep things smaller, a single 1MB SRAM chip could handle all PRGRAM and WRAM on it. I just think it would be a bit simpler and less expensive to put one 512kb flashrom and one 32kb SRAM for separate between rewritable and non-rewritable stuff. I don't think wich one is the best. I just considered to have one single SRAM for both CHRROM and CHRRAM (only the inside of the FPGA would do the difference between them).
Note that making a such cart would be very expensive, but you could play *all* NES games on it (under the condition a plugin has been writen for a specific board), wich would make it a rentable buy after a while.
Your notes are interesting. Maybe a much smaller cart with only one signle mapper would also be pretty practical. A smaller logic like CPLD or even PAL would fit the mapper logic. This would delete the FPGA, level transactors, voltage regulator and DAC (since no common mapper have sound). I think it would be nicer to have a small working flash cart than a big projects that won't ever work and be commercialised. The idea to have two programmable logic componant, one for mapper logic and the other to handle reprogramming seems interesting, but I didn't fully undestand it. Maybe it's just simpler to have non-reprogrammable logic inside a chip and only the FlashRom could be rewritten (for PRGROM and maybe CHRROM).
I think one of the most open board to simulate would be SXROM : It would be backwards compatible with SUROM, SOROM, SNROM, SAROM and SGROM, and could be easily ported from UNROM, UOROM, ANROM, AMROM, AOROM, NROM, and maybe even CNROM if the game doesn't change the CHR banks too fast.
Even if more games actually uses TLROM and TSROM, I think that would just be backwards compatible with NROM and CNROM without too heavy ROM hacking. Maybe just both carts could come up alternatively.
The reason I have two CPLD is so that you can reprogram the big CPLD just like you reprogram the FlashROM. For example, if you want to play a MMC1 game, you can flash the specific MMC1 board to the big CPLD and flash the ROMs. If you switch to another game with the same board, you won't have to reprogram the CPLD only the flashrom.
I don't like the idea of having one FPGA with hundreds of mappers inside, the benefit of having programmable logic is so that you can change it! This way people can develop their own mappers and upload them as simply as the ROM data.
Really the only reason to have FPGA is to synthesize MMC5 and/or to have a static design containing many mappers. For an 8-bit console, this is bloat. I would prefer to not support MMC5 and have a flashcart which people aren't intimidated to develop for...
Also I don't know of any available 1M x 8 SRAM. Just 4M SRAM which generally cost $10-20! 4M of Flash on the other hand is ~$5 and 62256 chips are about $5. Mid-range CPLD also cost ~$10-20 in small quantities, FPGA will cost $30-80. USB requires a connector, controller, oscillator, passive components and a microcontroller or CPLD/FPGA (will only work with your design if it's static, otherwise you still need more PLD) but can power the device. All this could cost $30.
Parallel port path requires a DB25 connector and power connector, LM7805, passive components totalling <$5.
Bregalad wrote:
It would be backwards compatible with SUROM, SOROM, SNROM, SAROM and SGROM, and could be easily ported from UNROM, UOROM, ANROM, AMROM, AOROM, NROM, and maybe even CNROM if the game doesn't change the CHR banks too fast.
Even if more games actually uses TLROM and TSROM, I think that would just be backwards compatible with NROM and CNROM without too heavy ROM hacking.
Bankswitching takes much longer on S*ROM boards than on CNROM, U*ROM, and A*ROM boards. Wouldn't some games that use cycle timed bankswitching fail when trainered to S*ROM?
kyuusaku wrote:
Really the only reason to have FPGA is to synthesize MMC5 and/or to have a static design containing many mappers which IMO is bloat.
What about the ability to survive more than 10,000 power-ons?
Quote:
Also I don't know of any available 1M x 8 SRAM.
Have you tried searching for PSRAM?
Quote:
Parallel port path requires a DB25 connector and power connector, LM7805, passive components totalling <$5.
Plus an adapter to use parallel port devices on your computer's USB port, right? How much does that cost?
tepples wrote:
What about the ability to survive more than 10,000 power-ons?
A CPLD should survive as many power ons as any Flash or EEPROM device. If you mean programming cycles, then those that program the CPLD 10x a day for 3 years should expect to replace the CPLD. If this CPLD is a legacy CPLD, it would be possible for it to be socketed and perhaps still fit in a case. To enjoy another 3 years of the same usage, the user would only need to purchase another ~$10 CPLD.
Quote:
Have you tried searching for PSRAM?
Yes, PSRAM is generally available only in huge quantities, it only comes in very unfriendly packages and I've never seen one with 8-bit word modes.
I would sooner use archaic yet sourceable DRAM like I have in my other NES projects. DRAM drops the price of memory a lot, but then it's an extremely volatile design. DRAM would also eat more I/O, macrocells and require an oscillator to move a statemachine.
Quote:
Plus an adapter to use parallel port devices on your computer's USB port, right? How much does that cost?
Nope. It would in theory be fairly straightforward to use a FTDI controller and very small CPLD to implement a SPP port however. I figure this device isn't in it for the money or fame (ROM sceners who need convenience and simplicity over anything else), and the crowd likely to use this device already has a parallel port (CopyNES) or would be willing to install a PCI one.
Parallel<->USB adapters found on eBay apparently only emulate the Centronics handshake making it only suitable for printing.
kyuusaku wrote:
I figure this device isn't in it for the money or fame (ROM sceners who need convenience and simplicity over anything else), and the crowd likely to use this device already has a parallel port (CopyNES) or would be willing to install a PCI one.
I see a
PCI Express parallel port for 50 USD. The solution has to be affordable in order to attract sceners who would otherwise stick to emulation or jump ship to the GBA/DS scene.
eBay has a number of 32-bit PCI cards, which should be available all desktop motherboards still, for under $20 after shipping:
http://search.ebay.com/search/search.dll?submitsearch=Search&satitle=PCI+parallel
If PCI-E is necessary, there is also this for $35 including shipping:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=8817126652
Nothing wrong with shooting for Mars, I did and got almost everyting done in ~6 months. There have been enough of these threads I may as well announce what I did starting in Jan 2006....
NES POWERPAK:
First I choose to use compact flash instead of USB. Must have every rom ever made stored on the cart! SD cards are serial instead of parallel so when the nes is controlling them they are too slow. To handle the compact flash card I set it up as memory mapped registers then wrote FAT16/32 handling for the nes. To load games on the cf card you just put the cf card in your comp and copy them over. I think I can handle any size card, at least have tested up to 1GB. The ines headers are used to figure out mapper/mem size, I havent done ines v2 yet but everything is designed to be upgradeable so it should be no problem.
Boot rom on the cart configures the fpga then goes into a menu where you browse files on the cf card and set options like game genie and battery ram loading/saving. All folder parsing works so you can organize games however you want.
For the fpga I used a Xilinx Spartan 2. It is sram based (no programming cycle limit) and has 5V tolerant input. I just do simple tristate/pullup to get 5V output, no expensive level translators needed! The fpga holds one mapper at a time, not every mapper at once. It is reprogrammed by the nes using files off the cf card so everything is upgradeable.
Cart has 512KB prg sram, 512KB chr sram, 32KB wram sram, and uses 2KB ram inside the fpga for extra nametables. There is no battery because the wram can be saved back to the cf card when you exit the game. Takes ~1 sec to boot, 2-15 secs to load a game which means reconfiguring the fpga and copying game from cf card to sram. Game size is the time factor. 1MB games are the 15 sec ones, there are only a couple of those. Everything is controlled by the nes, there is no other processor on the board.
Here is a pict of the first board, completed April 2006:
The pict is mirrored, the cf card mounts flush opposite of the cart thumb notch. I have an ejector button to get it out, more picts on that later.
I have ~60 mappers done, game genie, wram saving, everything USA except MMC5. Finally play NWC1990 on a real nes without spending $2-8K! Most games run with absolutely no problems. A few games have some irq problems thats should be fixable. 4 screen games like gauntlet run fine. Loading battery ram files created by emulators also works.
The problem with that board is the fpga isnt big enough for MMC5, or the MMC3 + game genie + other stuff. So in July 2006 I upgraded the fpga and decided to make the boot rom upgradeable through the CopyNES flash system. Here it is apparently mirrored pict, from Oct 2006:
A bit more crowded! Also added spot for lockout chip. Getting that board produced took much longer than expected (slow China) so by the time I got it I was swamped with other stuff (blatent advertisement for
www.retrousb.com). I hope to start working again in Jan 2007 and it should only take about a month to get it done, mainly adding bank switching to boot rom to handle the bigger fpga and hopefully adding mmc5. At one time I was thinking about doing Game Action Replay functionality but how that works isnt really known. FDS will unfortunately not work unless someone significantly rewrites the bios. I think I routed some unused i/o to the expansion pins on the cart so audio is a possibility.
Eventually I will be selling this as a completed board or as a full cart. It will not be a kit because everything is surface mount and the fpga and cf slot are not hand solderable. Yes it will be "expensive" because it was a lot of work, no it wont be more than $150.
wow, awesome work!!
I be sure to order one when they're done
btw. about the CIC part.. will this also be solderd on in the complete board? if so, will you be selling PAL boards too?
Hell yeah man, looks awesome.
Complete carts will have the cic chip installed from the donor cart, so I could do something like you send in a pal cart and I will take the cic off that. Just the board will have the cic empty. Of course that all might change once the cic is cracked and put onto a pic chip.
Sounds amazing. I haven't gotten everything, but it seems like your cart has about anything a programmable cart must have. That's exciting.
bunnyboy wrote:
Complete carts will have the cic chip installed from the donor cart, so I could do something like you send in a pal cart and I will take the cic off that. Just the board will have the cic empty. Of course that all might change once the cic is cracked and put onto a pic chip.
great
I made a quick video (
www.nespowerpak.com/powerpak.mov ) that shows the basic usage. Ignore the colors they are horrid!
It boots to show rom version and card version. Press a button to get to the games list, showing only .nes files and folders. If there are more games than lines of text then the whole screen scrolls. Choose a game to get to the options where you can load wram file from card and set up to 3 game genie codes. Ignore the arcade dips, that cant be done without additional hardware on the expansion port. Choose Start Game and everything will load up, game starts when its done loading. If you hit reset and the game header says it has battery ram then there is a screen for saving the battery ram back to the card.
The main issue is that compact flash cards are expensive and I don't know how different models it exists. They often are application-specific, tough I don't know much about them.
How hard will it be to have the connector fit in a NES case and to insert the cart with it in the NES ?
Other than that the project really looks incredible, maybe worth $150.
Compact flash cards are really cheap, 256MB are ~$9 on ebay including shipping which is enough to hold every USA game. That is comparable to usb drives and sd cards. So far I havent found a card that fails and I have used about 5 cards from 3 companies. There is nothing application specific about them, at least not using them in the memory mode.
The cf card fits entirely inside the cart case, there is no clearance to have it sticking out in a toaster nes. That also means with a toaster nes you cant just keep the PowerPak inside the nes and put the cf card in. If you have a top loader then you can insert the cf card without removing the PowerPak. Some picts to make it more clear:
CF card inside PowerPak (the black part):
Eject button flipped out:
CF card ejected:
Congratulations ! I really didn't think a such thing were possible !
About expansion sound, while techincally you cannot directly have an audio pin I think you could just use all expansion pins as digial outputs for audio, and sell a separate device that would plug on the expansion port under the nes with a DAC on it that will mix the digiat cartridge audio with the analog audio from the NES together. Since there is 10 EXP pins, you could use 8 bits-for DAC (supporting every FC sound chip ever made, including the 4-bit FDS, 5-bit MMC5, 6-bit VRCVI and 8-bit VRCVII and all others wich are less bits anyway). That would leave one pin for clocking the DAC, and one pin left for backwards compatibility with analog sound (typically a switch could control between analog mode where audio is directly passed trough pin 18 (backwards compatible), and digital mode where audio is passed trough all other pins). The digital mode would seriously increase noise immunity, since the DAC would be placed much closer to the actual audio output, and won't pass trough the whole NES's mainboards.
Anyway, even without this, your projects sound like the best hardware project ever made on the NES.
This is very interesting! I wanted a device like this since years
What about a Famicom version? I always liked the Famicom a lot more than the NES, the American/European version in my opinion is too ugly. I think you probably can run roms designed for NES too using your cart, am I wrong?
Why still need to using the CIC chip from an original cart? Why not emulating it on the CPLD/FPGA? This could save a lot the price of the device.
Quote:
What about a Famicom version? I always liked the Famicom a lot more than the NES, the American/European version in my opinion is too ugly.
Heh, you're not the only one to think that. While I've never seen any real Famicom, it looks much better on pics. But anyways games are compatible (at least US/Japan, PAL compatibility is limited).
Quote:
Why still need to using the CIC chip from an original cart? Why not emulating it on the CPLD/FPGA? This could save a lot the price of the device.
Because the algorithms of the CIC aren't fully understood yet, only partically.
However, I think he'll allow oredering one without CIC if yours is defeated and if you want to save ~$5 on a ~$150 ammount.
Bregalad wrote:
The main issue is that compact flash cards are expensive and I don't know how different models it exists. They often are application-specific, tough I don't know much about them.
Just the other week, I bought a 2GB compact flash card for $40 at CompUSA. Such a card is large enough to hold every NES game.
If you are shooting for Mars, maybe you could also support compressed ROMs. LZO may be fast enough to decompress on the NES:
http://www.oberhumer.com/opensource/lzo/
I just have to say.. this looks amazing. I'll watch this thread for updates!
NC
Thats amazing! I was waiting on the funky flash cart for a while, and now that his schematics are released, I might still hold off for this.
My only question is, why CF? why not SD? Isn't that more of the defacto standard these days?
lungdart wrote:
My only question is, why CF? why not SD? Isn't that more of the defacto standard these days?
Because the NES CPU is controlling it directly. SD communicates through serial, so it could be roughly 10 times slower.
bunnyboy: how is the NES putting the FPGA in slave parallel mode? Is that what the smaller SOICs do?
How does the cart retain WRAM until you get back to the menu to back it up?
Will you release the pin constraints so people can develop their own mappers?
Wow, this is the end-all devcart. Very impressive.
Wow, custom cart that just might work! $150 to play potentially any NTSC game sounds like a good deal!
Three GameGenie codes is rather restrictive. I know that's all you get on a real GG, but I always hated that limitation. Could you expand this number to something less annoying? (Ideally, one should be able to insert codes as long as there is space in the mapping hardware for them, but if a hard limit is easier to implement, I'd be satisfied with six codes, the functional equivalent of two GameGenies connected to each other.)
Will the mapper implementations be open source, so that others can correct any errors that might've been made?
Hey, what kind of devices do you need to be able to use your CF cart with a PC ? Do you need an expansion PCI cart, or is there a device that place in the front of a PC and that is IDE/Floppy compatible ? Are those expensive ?
there's all kinds and they don't cost that much:
long ebay link
First some random notes. I added dates just to make sure people didnt think I was ripping off the FunkyFlashCart. Also I may be able to make some small changes to the CF interface to do generic IDE so you could attach a hard disk instead. A CD would still need different drivers written for iso instead of fat tho. Also for the price I am guessing more like 100-125, 150 is the highest over estimate.
Let me know if I missed any questions:
Bregalad: To use CF on your computer you either need a pcmcia slot with an adapter, or a cheapo usb card reader. There are usb card readers that do tons of types (cf, sd, mmc, smart media, memory stick, etc).
dvdmth: The limit to GameGenie codes is the hardware, and I should be able to add lots more codes with the bigger fpga. Most likely somewhere around 6 will be max with the setup screen still looking good. I will probably release all my docs, its all in schematic form.
kyuusaku: Slave parallel is just a mode option on the pins. The pin to start configuration and the config clock are set up as mem mapped registers, which is some of the small chips. The other ones are now for the flash writer handling and also the card registers. If you press the reset button on the NES the power is still connected so ram is still valid. I couldnt use lockout defeaters because they also break the reset button. I will definitely release the constraints files and how to make your own mappers.
Jagasian: I havent looked at compression yet, I think having slower load times would be more annoying than having to get a bigger card. Even my smallest card (32MB) holds ~150 games.
timofonic: I havent planned a Famicom cart mainly because I dont have one. Most Famicom games are completely playable on the NES, and I have done ~30 Famicom mappers. On my design the CIC will never be able to be incorporated into the fpga because the fpga gets reconfigured while the NES is running. Because the CIC is always communicating it would reset the console once the fpga is erased.
Bregalad: Looking back at my design there are 6(edit) fpga pins going to the expansion port. EXP0 is used by the CopyNES flash system so it shouldnt be used for mappers. EXP1-6(edit) could be used for some kind of audio with extra hardware needed at the port. Including those pins every i/o is used so using that fpga it will not be possible to use all the expansion pins.
That's cool. I cannot wait for the thing to be released. You really got me by surprise, and that's cool in it's way.
Quote:
Bregalad: Looking back at my design there are 5 fpga pins going to the expansion port. EXP0 is used by the CopyNES flash system so it shouldnt be used for mappers. EXP1-5 could be used for some kind of audio with extra hardware needed at the port. Including those pins every i/o is used so using that fpga it will not be possible to use all the expansion pins.
Well, that won't be enough pins to hold digital sound as-it I think. That's a bit a shame, but the project is cool even without this.
EXP1 could be used to clock data and EXP2-5 would be the low nybble, and then the high nybble alternatively of sample data to be mixed with NES audio. Or just have it in 5-bits, but then VRCVI, VRCVII and possibly FDS audio will get partially corrupted (just a lower of quality).
Ideally, a hardware switch could manually toggle between analog mode (EXP2 directly passed for FC carts using sound+FC adapter) and digital mode (for PowerPak and maybe other future designs).
Oh, and one last question. Did you get all that knownledge at work, or just by yourself ? Because that's really impressive to developp such a large project for spare-time.
Looking at my design I should be able to have EXP1-6 available, no reason for EXP0 to go to the fpga because it cant be used for i/o. Dont know how much of the FDS system needs to be there to do audio, but regular FDS games wont run on this system without something like a major bios rewrite. I havent looked at the VRC7 and generally dont know how the audio is done on any of the chips.
Most of this stuff I learned in college or on my own, my job ( blantent advertising for
www.retrousb.com ) isnt as hard as this. For me any digital hardware or asm is basic, analog stuff and high level programming languages are confusing. Actually havent programmed in C in a few years and never done anything serious in oo languages.
Bregalad wrote:
Quote:
EXP1-5 could be used for some kind of audio with extra hardware needed at the port. Including those pins every i/o is used so using that fpga it will not be possible to use all the expansion pins.
Well, that won't be enough pins to hold digital sound as-it I think.
You only need one pin for digital sound output as long as you toggle it really fast. Game Boy Advance, Nintendo DS, and modern CD players all feed a pulse-width or pulse-density modulation through a "1-bit" DAC followed by a low-pass filter. I can explain further if you'd like.
This is so cool! When and where can I buy one? Assembled of course.
I just realized something. If you hope to implement MMC5, you may want to expand WRAM size to 64KB, since the MMC5 can support that size. Although no commercial games used 64KB, a homebrew game might. Also, bear in mind that there's no reliable way to detect WRAM size in the INES header, so unless you plan on CRC-based detection, you may need to assume a full 64KB size.
MMC5 games using 32K of WRAM will use banks 0-3 to access each 8K section of the WRAM. However, 16K WRAM games use bank 0 for the first half and bank 4 for the second half. Thus, supporting 32K WRAM games will not be enough to support 16K games. On the other hand, having a full 64K WRAM support will suffice for all MMC5 games (assuming none of them take advantage of WRAM bank mirroring).
If my understanding is right, battery RAM files generated by emulators are typically 64K in size for MMC5, although some emulators (Nestopia for instance) which perform a CRC test will generate smaller .sav files based on the game being played.
I wouldn't touch FDS at all if I were you. Even if you rewrote the BIOS, some FDS games perform disk I/O directly, so those games will still not work. Further, the user will need to be able to switch sides/disks during play, which would most likely require either a button on the cartridge or something plugged into the expansion port.
Quote:
You only need one pin for digital sound output as long as you toggle it really fast. Game Boy Advance, Nintendo DS, and modern CD players all feed a pulse-width or pulse-density modulation through a "1-bit" DAC followed by a low-pass filter. I can explain further if you'd like.
Of course, you can but I didn't know this was used on NEW systems, rather on old ones. You mean the DPCM or something totally else ? CD are by definition 16-bits 44.1 kHz. Doing a similar qulity in DPCM would require a much higher frequency rate and a lowpass filter.
Aside of that if you're not planning to support VRCVII I don't think that's a big issue, but VRCVI and MMC5 sound souds definitely easy to implement. Both will ned not-so-complicated sequencial logic, a digital channel adder and a DAC. MMC5 has 2 4-bit square wave channels, so basically adding them will have a 5-bit result. VRCVI has 2 4-bit square wave channels, and one 5-bit saw wave channel, and adding them alltogether will make a 6-bit result.
iNES 2.0 by KH now has complete wram sizing, is there real location for this doc? Cant just let a game have the full 32/64KB when it only uses 8KB because there could be mirroring problems. The bank 0/4 problem isnt really a problem when the hardware can easily rearrange the banks. The 512KB prg code space could also be used for wram if the game is small enough. It has been too long since I looked at the mmc5 games... I was hoping to support Grand Theftendo but have never gotten any response about what it needs, most likely too much prg space. Also need to look at the Drip mapper which should be no problem.
FDS disk swapping could be done by watching the controller for a button combination and jumping to bios code, but there are probably other architecture problems. Might be an easy way using actual disk hardware instead. I dont have any of the real hardware and getting everything ready for release will obviously be first.
You can certainly emulate the FDS drive with RAM; map the WRAM to $6000 and make a 16-bit counter which acts as the head pointer. Sides can be switched with 64k bankswitching. This would be much better than rewriting the BIOS and be just as fast.
dvdmth wrote:
MMC5 games using 32K of WRAM will use banks 0-3 to access each 8K section of the WRAM. However, 16K WRAM games use bank 0 for the first half and bank 4 for the second half. Thus, supporting 32K WRAM games will not be enough to support 16K games.
It takes one XOR gate to map bank 4 on top of bank 3, right?
Bregalad wrote:
Quote:
You only need one pin for digital sound output as long as you toggle it really fast. Game Boy Advance, Nintendo DS, and modern CD players all feed a pulse-width or pulse-density modulation through a "1-bit" DAC followed by a low-pass filter. I can explain further if you'd like.
Of course, you can but I didn't know this was used on NEW systems, rather on old ones. You mean the DPCM or something totally else ?
Not
delta modulation, which has difficulty representing high frequencies, but
delta-sigma modulation, also called
pulse density modulation.
Quote:
CD are by definition 16-bits 44.1 kHz.
And the CD players using a 1-bit DAC oversample the audio to some megahertz rate and dither it down to 1-bit PDM.
Quote:
Doing a similar qulity in DPCM would require a much higher frequency rate and a lowpass filter.
Sony Super Audio CD is stored as
PDM at 2.82 MHz. We could get away with PDM at the Phi2 frequency, right?
kyuusaku wrote:
You can certainly emulate the FDS drive with RAM; map the WRAM to $6000 and make a 16-bit counter which acts as the head pointer. Sides can be switched with 64k bankswitching.
But what would trigger the bankswitching? On the FDS, the user mechanically bankswitches the file by ejecting the disk and flipping it.
tepples wrote:
But what would trigger the bankswitching? On the FDS, the user mechanically bankswitches the file by ejecting the disk and flipping it.
Hotkeys just like bunnyboy mentioned.
FDS disk swap could also be done by just putting a switch on the expansion pins, fpga can watch for that. There are a couple ways of watching for the controller, one would be to redirect the nmi and hope that games arent too spicky about having some cycles stolen. Could also use the fpga to keep track of the result when the game reads the controller, but that assumes the game reads all of it which it probably doesnt do while waiting for a disk swap. Now I really need to remember why I thought FDS just wouldnt work...
I think FDS games have some way to communicate with the disc driver when the user is supposed to change disc sides, and then the FDS virtual mapper could automatically switch sides when it decects when that's needed. I have no idea how to implement this and know nothing about the FDS, but one sure thing is that those button combos and hacks sounds really bad. I think you should run each game as it once it's booted and shouldn't relocate vectors or anything.
Nothing but the game knows when it's time to switch disks. The disk drive only communicates that there is a disk inserted or not. Having a physical button is the closest you'll get to a real drive since you must manually eject and insert disks.
FDS is not gonna happen. Unless theres enough ram on the board to stre an entire disk image, and then write it back to the CF card when swapping sides, its not possible, since you're forgetting an important feature of FDS disks: they're WRITABLE, and MOST games do this SEVERAL TIMES during play. unless you can do byte-granularity writes on a CF card, its pretty much impossible.
Lord Nightmare
I have very few idea on how the FDS works, but the CF card is very close to what a disk system would be I think. If the game takes very long write and read times to/from the disc, those acess would just acess the CF card instead. I don't know how hard this is to do, but that'd be fine.
And with 512kb PRGRAM, you can most certainly hold a whole disc, wich are 128kb.
On a different subject, I put some thought into how one might be able to add save state support to the PowerPAK. Here's what I'm thinking of:
First, allow the user to assign a hotkey that will interrupt the game. The user should also be able to disable the hotkey if he/she doesn't want one. The cart would monitor $4016 accesses until it finds the hotkey, then interrupt the cart at the next NMI. It's best to wait for NMI before the interruption to simplify state play resumption (a mere RTI right before V-Blank would be sufficient to get the game going again). I am only aware of one commercial game that didn't use NMI (a number of homebrew games don't, however), so this solution should be highly compatible.
Upon interruption, an options screen would appear, giving the user choices like the following:
1. Resume Play
2. Save Battery RAM
3. Save State
4. Load State
5. Software Reset
6. Hardware Reset
7. Change Game Genie
8. Exit Game
The cart will need to monitor writes to $2000, $2001, and $2005/2006. The registers should be restored during the scanline before V-Blank, when the PPU is idle. APU resoration may be tricky though, particularly if a game relies on frame IRQs or DMC IRQs.
Saving the mapper state should be fairly easy since all mapper registers are directly accessible in the FPGA. When the cart is interrupted, the mapper hardware should be suspended (particularly any IRQ counters that may be active) so that it can be saved in the condition it was in at the time of the NMI.
This solution isn't perfect, as it does require that (a) NMIs are enabled and (b) the game is actively reading controller input at the time the user wishes to interrupt the game. However, it should prove good enough for most games and situations, as the games I looked at usually keep NMIs active at all times (except when the screen is off) and will usually read controller input on every frame, whether it's used or not.
Lord Nightmare wrote:
FDS is not gonna happen. Unless theres enough ram on the board to stre an entire disk image
Not difficult. Even 128 KiB of RAM can hold 40 KiB for BIOS + PRG RAM and 68 KiB for a disk side (including 4 KiB of headroom for overburning) with 20 KiB to spare.
Bregalad wrote:
I have very few idea on how the FDS works, but the CF card is very close to what a disk system would be I think. If the game takes very long write and read times to/from the disc, those acess would just acess the CF card instead. I don't know how hard this is to do, but that'd be fine.
And with 512kb PRGRAM, you can most certainly hold a whole disc, wich are 128kb.
FDS disks work more like an audio cassette tape, after reading in 8 bits it raises a flag or interrupts the program so it can read that byte.
Using the counter method, the commands that would normally move the head could just move the counter. The counter would address a single byte in memory sort of like bankswitching. Once the game starts the reading routine, the counter would reset, raise the flag. After the CPU reads the byte the counter could be incremented and the process would go on. This would speed up disk reading immensely since the drive speed is normally around 96000 bits/s. If a game used timed reads the counter could be clocked at roughly the real disk speed using Phi2 and a divider.
Really it's just a hardware implementation of what emulators do.
The PowerPak has a total of 544KB of prg ram which is enough for bios and many disk sides at once. It is all sram instead of flash so there is no write time penalty. When the game is done it would be easy to write that data back to the CF card, just like the battery ram handling now.
The CF card access is done in large blocks of 512bytes, and real file access is usually in 512b-8KB blocks depending on the FAT system. It definitely does not match the way the FDS works, which is closest to a tape drive (start at beginning, read until you find what you want). Navigating through the dir tree to find where to save data is slow so it cant really be used for swapping in game. Byte access is possible but not usable when the file system is there and the card has long read/write delays. A game could be written to use the PowerPak bios to get access to files for more storage tho.
bunnyboy wrote:
[Block device access] definitely does not match the way the FDS works, which is closest to a tape drive (start at beginning, read until you find what you want). Navigating through the dir tree to find where to save data is slow so it cant really be used for swapping in game.
Not if the .fds files are contiguous on disk (that is, not fragmented). Then it's just base_sector+byte_position/512. If a game starts writing in the same sector that it had read from, just write to the last (cached) sector. But loading the entire side into RAM would still probably be a better idea.
tepples wrote:
Not if the .fds files are contiguous on disk (that is, not fragmented).
Definitely true but that is something that can't be assumed any time you plug the card into a computer. I have seen Windows rearrange blocks for no reason, when no files were added or changed. Not having to keep checking the fat tables would make loading games a bit faster too but one of my main points was to never need special apps to modify the card or the games.
Finally remembered why FDS wont work on my board and its pretty simple. The game reads disk data from one register. The easy thing would be to just have an incrementing 16 bit counter in the fpga that points to where in ram that register byte will come from. The problem is the fpga only controls the upper address bits (A18-A13) and not the lower address bits so the counter cannot set the full address. There is probably a simple answer but I havent thought about it yet, almost got boot rom updating from CopyNES done instead...
If cannot change all of the address lines with the FPGA, then you'll need to "trap" accesses to the I/O registers.
When the FDS is in write mode, trap accesses to the write register by injecting a BRK on the following cycle. The FPGA should maintain the value written, which the handler can access in order to update the FDS image. When ddone, subtract 2 from the return address, then RTI.
For reads, trap the read register in the same manner. Place the next byte of data in a register, subtract 5 from the return address (assuming absolute addressing was used), then RTI. When the instruction re-executes, the register contents can then be sent to the game.
This method will slow things down, however, but it's the only way I can think of that you can do FDS without having control over all address lines.
At this point, it might just be better to rewrite the BIOS and damn the compatibility with games that do direct disk access.
Or build another board using the same tech. Would be cheaper because of the smaller fpga and less ram needed. Audio stuff could also be added more easily. Must get this board done first!
tepples wrote:
At this point, it might just be better to rewrite the BIOS and damn the compatibility with games that do direct disk access.
It would be better to make a drop in replacement for it capable of being used with FDS games and hardware which use the FDS. This would require a new BIOS and the old BIOS. If the device had a 60 pin connector, it could directly switch to the FDS BIOS and not illegally contain it inside and also allow sound register writes to go to the extra 60 pin. As I understand it, FDS sound isn't fully understood yet.
I don't know about FDS support, but the cart is great anyway, and 95% of FDS games have their cartridge equivalent, either hack or official version.
I think the best for sound would be to create a device that plug on the bottom of the NES inside the connector and take it as a standard for future homebrew developpement.
I was planning to use extra MMC5 sound in Ecological Evolution, a game I'm planning to make (only some design is done right now, no game engine programming at all). If I use more channels, it would be great to not have people need to modify their hardware for it to work. On running on a real MMC5, I think all 72-pins carts needs additional wires form the MMC5 to the cartridge connector to work with a (modified) console. With a custom cart, I think I could port the sound to a device that would mix it with the NES audio on the bottom of the thing. I just don't know if it should be analog or digital, or both. FC carts uses analog format (sound is already mixed on the cart and ready to go on the connector), but I think using a different digital format could be better and increase noise immunity if done proprely. However, that would require some device that send data asynchronously to the expansion device, and the expansion device with a DAC on it mixing it with the NES audio output.
Bregalad wrote:
I think I could port the sound to a device that would mix it with the NES audio on the bottom of the thing. I just don't know if it should be analog or digital, or both.
If you make your audio hardware output a
delta-sigma modulated signal on one pin, then you do have both. The DAC for ΔΣ is just an inverter (to remove noise) and a low-pass filter (to turn it into analog).
Well, if you insist why not, but then what speed would your mapper logic have to send audio data to the DSM filter to have an acceptable quality ? And how could FC analog signals (trough an adaptater) pass the inverter as if they were digital without serious alteration ?
Bregalad wrote:
Well, if you insist why not, but then what speed would your mapper logic have to send audio data to the DSM filter to have an acceptable quality ?
M2 should be fast enough. It's almost as fast as Sony's Super Audio CD.
Quote:
And how could FC analog signals (trough an adaptater) pass the inverter as if they were digital without serious alteration ?
Separate pins.
Sounds good, however I've doubt when it comes to make good quality square waves with only pulse coding. The filter will add serious slew rate, and break all the nice sounding of square wave. Maybe not, but I'm afraid it will. And most custom sound mapper uses very-low-slew-rate waveforms (at least MMC5 and VRC6, the most popular extra sound chips arround).
Also I have no idea how complicated it is to split from standard digital sound (created inside a FPGA or so), to SDPCM sound (on a single pin).
Oh, and in case M2 would be too slow there is always the CIC 4MHz clock... however it won't work on top-loaders, and any chances of getting it working on a famicom are gone.
Quote:
I don't like the idea of having one FPGA with hundreds of mappers inside, the benefit of having programmable logic is so that you can change it! This way people can develop their own mappers and upload them as simply as the ROM data.
Good idea, but I would definitely pay more for the more expensive chip that emulates all. I wouldn't even think twice about it. Plus, the average joe user non-technophile would dig it more two. Best bet? Offer both. Those with the cash can pay it.
Quote:
I wouldn't touch FDS at all on this project if I were you. Even if you rewrote the BIOS, some FDS games perform disk I/O directly, so those games will still not work. Further, the user will need to be able to switch sides/disks during play, which would most likely require either a button on the cartridge or something plugged into the expansion port.
I think it would be acceptable to just make that an entirely different cart. You would have to emulate the FDS the same way FDSLoadr does, only without a real RAM adapter on the NES side. As for disk switching, you could make a physical switch if you felt you really had to emulate it (eject, flip), rather than use hot keys. No one wants to get up and hit a switch, but back in my day we had to get up and flip disks around by ourselves uphill both ways in the snow, and we liked it! Also, why rewrite the bios completely, when one could load the FDS Bios on there themselves? I would imagine that could take a lot of work out of it. Another option for hot keys would be to bring up a menu ala Game Action Replay that displays the selectable disk sides and maybe some other info about the image. Such a menu might be useful to show info on any game, really.
But anyway, in FDSLoadr, You send a game to the RAM Adapter, and when you want to switch disk sides, you press 2 on the keyboard for side B (or 3 for side C or 4 for side D, etc) and then space to send the side to the RAM adapter.
But like I said, a seperate cart for FDS might be better, but just throwing some ideas out there. I'd love to have a replacement for FDSLaodr, since it only works in true DOS, and it is somewhat limited. USB would be nice too.
-Rob
Bregalad wrote:
Sounds good, however I've doubt when it comes to make good quality square waves with only pulse coding. The filter will add serious slew rate, and break all the nice sounding of square wave. Maybe not, but I'm afraid it will.
Slew rate will show up as a loss of high frequencies, similar to overload in DPCM, but CD players manage to pull it off as long as slew-related phenomena are kept above 20 kHz.
Quote:
Also I have no idea how complicated it is to split from standard digital sound (created inside a FPGA or so), to SDPCM sound (on a single pin).
The first order approximation involves eight flip-flops and one 8-bit adder. Each cycle, add the linear PCM value created by the sound emulation circuit to the internal register. If there is a carry out, produce a 1 on the output; otherwise, produce a zero. Commercial implementations use noise shaping to move more of the noise into frequencies above 20 kHz.
Quote:
The first order approximation involves eight flip-flops and one 8-bit adder. Each cycle, add the linear PCM value created by the sound emulation circuit to the internal register. If there is a carry out, produce a 1 on the output; otherwise, produce a zero.
Heh, that is pretty cool. As long as only 2 MMC5 channels are emulated, that means 5-bit adder and only 5 flip-flops. Sounds easy.
Since M2 oscillates at 1.5 or 1.7k, this will make plenty of pulses even for a 20kHz square wave (approximately 40 pulses per high or low state).
Quote:
Slew rate will show up as a loss of high frequencies, similar to overload in DPCM, but CD players manage to pull it off as long as slew-related phenomena are kept above 20 kHz.
Yeah, after all even if there is some low-gabrage oscillation above 20kHz nobody will hear it exept cats and dogs (without counting that there is probably other filters from the NES output to the TV), so I think it's okay.
This could be improved by increasing the filter's order, however I don't know if this is needed or not. I guess some test should be done on this before any implementation in hardware is done.
As for flipping FDS disk sides, a button may not be enough unless a menu pops up. Without a menu, a three bit switch could emulate up to 8 disk sides. Iirc, the largest FDS game was 4 disks, but I could be wrong. I'm sure there were 2 disk games and possibly 3. A 4 bit switch could leave open possibilities for experimental FDS dev work.
-Rob
rbudrick wrote:
As for flipping FDS disk sides, a button may not be enough unless a menu pops up.
What about a button and four LEDs?
