arfink and I are discussing a really low-cost NES development cartridge that can be constructed from SNROM (MMC1) boards. The basic idea is to replace the PRG ROM with a 128K/256K/512K Flash ROM and connect the write line. I'd like input, especially from Memblers, who I know has also done similar things, and bunnyboy, about the cost-effectiveness of making this as a custom board, or whether it would work with his unpopulated MMC1 board's automatic-chip-detection.
The MMC1 and Flash chip would both get writes to the $8000-$FFFF region, but this shouldn't be a problem because the Flash chip doesn't respond to writes unless preceeded by several writes to particular addresses, ones that wouldn't ever occur accidentally. And the values written often have the high bit set, so it naturally resets the MMC1 shift register as well, avoiding MMC1 disruption when programming the Flash. I realize that 5V DIP Flash chips aren't produced anymore, but these are just too convenient. Jameco Electronics at least seems to have them, and for a decent price (around $4 USD).
We're also considering making the CHR RAM battery-backed and write-protectable, using one of the MMC1 CHR bank selection lines. Both of these features have worked on another MMC1 cart I've modified to implement these features.
To allow programming, we're making cheap serial interface cables for the NES, with the NES implementing the UART in software. The basic design uses a MAX232 or equivalent to convert between the NES 5V and RS232 +/-12V signals. An alternate design uses an
FTDI TTL-232R cable which has a USB connector on one end, and bare wires on the other with 5V serial signals. While more expensive, the cable can be made by literally just splicing it to a NES controller cable. With some heat-shrink tubing, such a cable would look very elegant.
A third approach not yet tried is to use a few resistors and diodes to interface the NES directly with RS232, without any level shifting. This should work for sending data from the PC to the NES, but might not work the other direction. For many uses, this is sufficient.
In the Flash ROM resides a tiny bootloader that waits for a 256-byte program from the PC, then executes it. This 256-byte program can then receive a larger loader program, or whatever. This design has worked very well on my devcart. The benefit is that the tiny bootloader doesn't have to be updated every time you improve the larger loader, lessening the chance of bricking the cartridge.
In order to reduce the chance of an end-user bricking the cartridge, we're considering a small bank-select switch/button that selects an alternate copy of the bootloader, in case the main one gets corrupt. Since the end-user has no way of reprogramming the cartridge beyond the PC interface, something like this seems important.
While the initial goal is to make and sell some at a $40 price point (I've left all monetary decisions to arfink, and declined to receive any money for this), it'd be nice if anyone could make one of these, or at least other people also make some. They should at the very least allow running 32K NROM NES programs, and provide a cheaper platform if you just want to run other homebrew stuff.
Thoughts on the design/improvements/problems?
I'll just add that while I will be making a few batches of these, my target audience is the folks at the various chipmusic sites and such. If people here want to buy ready-made hardware from me when the time comes I'll be happy to do that. However, something Bargg forgot to mention is that there will be a full tutorial made up which will detail the construction of these devices.
Also, as you'd expect, since there is lots of RAM on board this can be used for running NROM stuff pretty easily too.
The idea is interesting, but I think that $40 is a bit too much for a cart that can only run NROM and MMC1 games.
I still didn't understand exactly how this work though. Does your program get written to the Flash ROM or is that chip only for booting? If the Flash is used for the program I think that the cart doesn't qualify it for intense use (i.e. emulator replacement), so the only advantage I see over standard socketed carts + EPROM programmer is the direct PC connection that eliminates the chip swapping.
blargg wrote:
And the values written often have the high bit set, so it naturally resets the MMC1 shift register as well
A string of multiple bytes with set to true will likely disrupt which bank you're reprogramming. You might have to use discrete logic or an extra feature in an MMC1-clone CPLD to add a register at $5000 that switches writes between the MMC1 and the flash chip. This technique would also allow saving without a battery, as I've
explained in another topic.
tokumaru wrote:
I think that $40 is a bit too much for a cart that can only run NROM and MMC1 games.
Compare to the difference between a SuperCard and an M3. Both are flash cards that run GBA programs, but most programs have to be patched to run properly on a SuperCard. In the case of an MMC1-only card, this might involve mapper-hacking a CNROM or UNROM game.
tepples wrote:
In the case of an MMC1-only card, this might involve mapper-hacking a CNROM or UNROM game.
If you try to mapper-hack my UOROM game that uses a timed NMI routine for the MMC1 you will probably fail.
But yeah, I can see that with the MMC1 you can play most UxROM games, while the reverse is not true, so it makes sense to use that mapper. Most CNROM games probably don't need instantaneous CHR switching either (although a program of mine does - but I guess I just like to "break the rules"...).
Part of the reason is that it's fun to do! One thing to note is that the bootstrap is intended to be able to load code into flash or ram, or both. In some ways this then becomes the poor-man's CopyNES. With the lockout chip disabled Blargg seems to think that it would even be possible to do a stop-n-swop type thing in order to work with other RAM cartridges and such.
While $40 may seem somewhat steep to some people, that's the price for everything, including the donor cartridge (if we go that route) the flash chip, cabling stuff, and a less-than-minimum wage for me so compensate for building them. A DIY-er who follows the tutorial could make a similar one for far less money with a donor cart he already has, stealing a flash chip from an old PC motherboard's bios, etc. I don't know of any other dev cart which you can just buy outright that comes with everything needed to get going with basic NES development for $40.
EDIT: lastly, with something like this which is a basic development kit, hopefully more people will find doing some NES development work a little more interesting, and maybe more people will try it. I'm really stretching my knowledge of the NES working on this project.
EDIT2: Also, newbs shy away from NES development because they don't want to fork over the dough for an EPROM programmer. This design allows reprogramming the cartridge without needing an EPROM programmer at all.
Every PC made in the last decade has a USB port, but a lot of newer machines (especially Macs and smaller laptop PCs) lack an RS-232 serial port. Would it be cheaper to use the TTL-232R, or would it be cheaper to use the MAX232 and bundle a USB to RS-232 adapter?
Well, if you can load code to RAM that's already better than what I though. How much RAM is there?
BTW, I don't think $40 is an outrageous price or anything, I understand what that much covers and it makes sense, but for what the cart does it might not be worth it, that's what I meant. I can see the appeal for a person who doesn't own an EPROM programmer and/or a PowerPak though, since it is a much cheaper alternative.
Quote:
The idea is interesting, but I think that $40 is a bit too much for a cart that can only run NROM and MMC1 games.
The point is to allow chip musicians to run homebrew stuff more cheaply, so that more people can afford to. It would of course also run other homebrew stuff as well. And with the PC cable, you can do fun things like use the NES as an authentic output device for an NSF player running on the PC or Famitracker, and even do homebrew development with a very short edit-test cycle. If the CIC is disabled on your NES, you can do stop-n-swop and dump your own cartridges/back up their battery RAM, or even load your code into WRAM (if the swapped-in cart has it) and test with its mapper, e.g. test code on the MMC5 or whatever.
Quote:
A string of multiple bytes with [the high bit] set to true will likely disrupt which bank you're reprogramming.
I believe that simply resets the bank mapping, but not the bank, so I can do all writes to the appropriate 16K bank without any disruption. I'll see once I have a prototype to test on.
Quote:
Also, newbs shy away from NES development because they don't want to fork over the dough for an EPROM programmer. This design allows reprogramming the cartridge without needing an EPROM programmer at all.
And greatly shortens the edit-test cycle. No cartridge swapping or EPROM chip swapping.
Quote:
Would it be cheaper to use the TTL-232R, or would it be cheaper to use the MAX232 and bundle a USB to RS-232 adapter?
Yeah, I think TTL-232R cable would be the simplest, and with proper heat shrink tubing, would look professional. But arfink believes he can do the MAX232 adaptor + cheapo USB to RS232 adaptor cheaper (which is kind of funny because the USB adaptor basically has a MAX232 in it as well). This as an option is necessary anyway because some people might already have a serial port.
Quote:
Well, if you can load code to RAM that's already better than what I though. How much RAM is there?
The RAM would just be WRAM at $6000. The Flash is what is intended for most code loading. We could probably put 32K WRAM and have it bank-switched by the MMC1, but then code written for it wouldn't run on emulators anymore. I think it's best for code to be written for standard mappers. An earlier design was considering running code from WRAM, before I learned about these great Flash chips (that are sadly not even manufactured anymore).
blargg wrote:
The point is to allow chip musicians to run homebrew stuff more cheaply
Aren't most of those guys crazy about expansion chips?
Expansion chips? Heh, not really. Surprisingly enough, alot of them don't deal with them because it's "too hard" to use the real hardware. Actually, with a stop-n-swop it'd be possible to do more with expansion hardware too, probably. Hmm, an interesting possibility...
Quote:
Aren't most of those guys crazy about expansion chips?
Simple: disable the CIC on your NES, then use stop-n-swop and put in a cartridge with the audio expansion chip of your preference, and run the NSF player with that.
blargg wrote:
Quote:
Aren't most of those guys crazy about expansion chips?
Simple: disable the CIC on your NES, then use stop-n-swop and put in a cartridge with the audio expansion chip of your preference, and run the NSF player with that.
Only $0000-$07FF and possibly $6000-$7FFF can be loaded after a stop-n-swop. Your NSF would have to copy itself down there, and this location is off limits to APU DMC.
Well, not necessarily Tepples. Once swopped, presumably a loader program will still be in the 2k WRAM of the NES, and then one can draw more data off the serial cable for playback and use it immediately, discarding it. One would not have to store everything.
EDIT: correct me if I'm wrong Blargg, but if NSF playback is all that is desired, once the player is in the WRAM then you could run without a cartridge at all, and simply play NSF's being fed through the controller port.
arfink wrote:
Well, not necessarily Tepples. Once swopped, presumably a loader program will still be in the 2k WRAM of the NES
It would have to use the DPCM samples that are already in the PRG ROM. The only mappers I know of that can map RAM into $C000 are FDS and MMC5.
Right, DPCM samples probably wouldn't work with another cartridge.
I think $40 isn't bad since the goal is not a device like the PowerPAK. The stop-n-swap idea is interesting. What's the life time on these Flash chips?
The life time on the flash chips is variable based on what manufacturer they come from. I'll have to check on exactly how many cycles it is.
Of course, a DIY-er who makes his own can just socket the Flash and when it dies you can drop a new one in.
The Atmel one says 10K erase-program cycles. It uses 256-byte sectors, so I doubt it means merely erasing 10K sectors and reprogramming them, because given 512K device size, that would only mean only 4 total reprograms of the chip.
The AMD one guarantees 1M erase-program cycles per sector, with the chip heated to 90 C. Clearly AMD had superior technology at the time.
Yeah, I think this would be a great thing to build. And $40 is about right, too for a whole kit that is a great deal. Making the cables is a lot of labor, I built 6 RS232 to NES/SNES* adapters. I shipped 4 of them I think. I think I sold them for $15, not sure
My biggest advise is this - it's time for RS232 to go to bed. The newer FT232 chips are much better than the older ones, but for the same price you can get a PIC18F or PIC32 that has all USB hardware on-board. Then you need I guess an 8mhz crystal, and that's it.
From there it would be simple to translate 5V synchronous from the NES, through USB, and then a required USB driver which gives you the data on a COM port so it still works with RS232 software (as long as it lets you select COM19 and stupidly high port numbers like that). The synchronous NES part is important, because then the NES can read buffered data at it's convenience. You could get a highest-specc'ed PIC with 128kB of RAM for maybe $7, which is just an absurd amount of RAM. There are much cheaper ones though since this wouldn't need much RAM/ROM.
There's also a lot of other stuff you can do with an MCU.. like letting the games use it's program flash (or some of them have dedicated EEPROMs) as a non-volatile save memory. You can get 10,000 writes out of that minimum (maybe 100k or 1 million with it's smaller EEPROM), at least, but it'll have a longer life since the wear can be spread around easily).
As for MMC1 I don't know if it would work or not. I guess the flash chip won't have any problems, but the mapper might. If the banked address lines have any chance to do weird stuff while it's programming, that can't be good (since the entire address is the programming address, of course). It would smart to do a custom board. I've been really interested in making a lower-cost dev board board design (cheap enough to be used for game distribution as well since maybe it can be done in quantity), but I didn't want to get too much in the business of building cables (but now I do that sometimes at my workplace, heheh).
For the board I would go with PLCC memory. PLCC flash is available enough for development, and OTP EPROM can be used for production if needed. PLCC can be socketed (and fit in the cart shell) in case the cable fails or ROM needs updated. I believe I may be able to make the board compatible with both PLCC and DIP, I have a layout for that type of thing that only needs the close tolerances to be cleaned up.
*it was interchangeable but writing the code for the SNES was a nightmare since I wasn't aware of the SNES CPU timing being variable and also HDMA stealing cycles (initially tested on the SNES clone I have, where it actually worked fine). synchronous comms would solve all those problems.
Quote:
The AMD one guarantees 1M erase-program cycles per sector, with the chip heated to 90 C. Clearly AMD had superior technology at the time.
Yeah, that's why I wanted those for Squeedo. So if play your NES once a day and save the game when you're done, you'll be good for about 2,700 years. With wear-leveling and say a 256-byte save, I'm sure the metals making up the components will be transmuting themselves (or whatever they do) before you wear out the chip, heheh.
So would be an NES board be interesting to you guys if I made one up?
edit: BTW I can help out with the PIC programming if you need.. I've done PIC18 asm and now that I've been using C I can use that just as well (since the USB libraries probably will require it). If you're not real familiar with PICs I could help pick one out too maybe (there are hundreds of different types, but amazingly, availability is never an issue).
As far as I'm concerned, the board is interesting, but not right away. I want these so that they can be provided to people at cost, but people can also still build them for themselves. A design which uses existing carts can do that more easily, I think, than a custom PCB. But if you can build it, I'm sure people would be interested in such a thing.
As far as using serial, I understand how ideal it would be to use a PIC, but right now we don't want to deal with writing drivers, and RS232 has the advantage of being very robust and universal across OSes. I have commented to Blargg that I'd like to use this with my Apple IIgs, even if just for kicks. Blargg mentioned this is his other thread here:
[quote=blargg]A big benefit of using serial (even if just a USB-serial adaptor) is that the host-side drivers use a well-worn protocol. You don't have to mess with special drivers or communication models when using serial, so it's easy to port to different operating systems. That's not to say you couldn't have a microcontroller with a USB interface to the PC acting like a serial device, but giving the NES a clocked interface (maybe that was your point). If someone wants to release such a cable for the NES, please do![/quote]
Lastly, while this cartridge is a cool idea for NES development and could have alot of potential, I think that our primary goal has not been to make a cheap cartridge with lots of cool development features, but a cheap cartridge for non-devs to use homebrew.
Yeah, it adds I guess $5 or so to the cost of parts. I don't think RS232 is as robust and universal when bit-banged, half-duplex mode is fine but the NES can't do anything else (not easily) while it's waiting for input. Kinda harder to use from the NES side. But oh well, either way the NES and PC software is pretty much compatible with both hardware types. Also, I'm sure there would be a USB PIC18 in DIP package if that helps for people building it themselves.
Would be cool to use it with older hardware too. I think I looked it up for the Atari 8-bit and C64 and (IIRC) it was 0V-5V RS232, so no adapter is even needed for those, just connectors.
I might make a cartridge like that, sounds kinda fun, I have a feeling it may be useful once more communication adapters are around. These type of carts can work with CopyNES, too. I could use DIP parts, but it's more expensive for the RAM.
Well, you could just go find a copy of Ultima Exodus (which nobody really wants to put themselves through the torture of playing these days) and it has everything you'd need. 8k battery ram, 8k CHR RAM, PRG ROM. Dirt cheap game if you look on evilBay.
Make sure to grab
Ultima Exodus and not regular Exodus. Regular Exodus runs on Color Dreams' nibble-swapped GNROM clone.
In which regions was
Ultima Exodus released? And how many copies are probably out there? Would they need a new battery soldered in?
On eBay, I see listings for the US version of Ultima Exodus for anywhere from $1 to $12. But is
this Ultima Exodus, or is it Yoshit?
I dunno what regions ultima exodus got released in. I believe most, if not all the Ultima games have an appropriate mapper and configuration for this. I have also used Bard's Tale.
I guess to find out, one could hit up Bootgod and check SUROM.
It would be cool if you made different designs for different mappers (with instructions on how to modify different donor carts), so people wouldn't have to stick to the MMC1. They could have a whole set devcarts using different mappers.
tokumaru wrote:
They could have a whole set devcarts using different mappers.
But once you have three such carts, you might as well buy a PowerPak, unless you're developing for an unsupported mapper (such as one involving flash memory writable by the program itself). But this project is good not only for learning how to make devcarts but also for learning how to make repros of one's finished product to sell (that is, if anyone ever gets around to finishing a product).
You can buy a lot of cheap donor carts for the price of a PowerPak... Of course you still have to consider the Flash memory, but at least the PC connection would be shared between all carts.
I'm saying this because I'm not the biggest fan of the MMC1, and I think that a development solution that's limited to a single mapper (and its few subsets) is not that useful.
Hm, here's an idea maybe, for modding mappers to work with flash. If the mapper covers a $8000-$FFFF normally, maybe a 74hc139 or 138 could be used on the enable to move it to $0800-$7800. So a latch at $8001 would show up at $0801. It would also end up overwriting zero-page RAM and breaking compatibility, so it's kind of debatable if it's even worth it at that point (though I guess further mods could avoid that, but it's getting to be quite a lot of rewiring by now).
Also BTW Ultima Exodus was the cart that I had modified to take an EPROM a long time ago (and haven't used it much, really since my development tests had typically been pretty small). Before I had a ROM programmer and emulator, I had put some stuff together and had it burned but it didn't work right because of it being MMC1A and starting in a different bank than all the emulators (at that time). Later then, on my Squeedo cart (so I can just use the highest bank for the loading code) I had put a resistor network as pullups on the address lines so it could start up properly. I didn't think of that until now, this MMC1A random bank startup is another potential problem for a flash cartridge. You need vectors in every bank. The loader code could just reserve $FFF0+ in every 32kB and be OK I think, then point the NMI and IRQ vectors into RAM so user programs can put JMPs there (or rather, the load code copies the vectors there).
tepples wrote:
tokumaru wrote:
They could have a whole set devcarts using different mappers.
But once you have three such carts, you might as well buy a PowerPak, unless you're developing for an unsupported mapper
And then you might as well buy a
ROM emulator, heheh.
Thanks for pointing that out Memblers. As it turns out, we haven't used Ultima Exodus, it was just the first that came to mind. Bards Tale and NES Open Tournament Golf have been ones that I have actually used, and they have the MMC1B2 and MMC1B3 inside. That should save us some trouble.
EDIT: I just checked the bootgod database, and Ultima Exodus does, in fact, have an MMC1B chip inside, not the MMC1A. If you have a strange version with a different revision MMC1 inside, you should post that information to the bootgod database.
tokumaru wrote:
The idea is interesting, but I think that $40 is a bit too much for a cart that can only run NROM and MMC1 games.
$40 is a fucking deal.
heres my proposal:
http://search.digikey.com/scripts/DkSea ... -80I/PT-ND
256KB flash , 64KB sram. 12KB boot flash memory so all 256kb can be used for NES purposes.
TQFP100 package. Anybody who has a $15 radioshack iron, flux, and solder wick can solder it.
Usb 2.0, possibility for SD card support, all sorts of crazy stuff. Yes, this would require a batch of PCBs to be made.
This chip is $9.50. The parts costs will be close to $40 for everything but you will have a lot more at your disposal.
I'm no expert on MMC1 but that PIC supports hardware DMA and can be clocked pretty fast, if it comes to it.
Sure, a custom design would be best, but I'm more interested in something that will actually happen, hence the incremental approach. If we get this minimal-modifications-to-existing-board working, then someone can do something like you propose, with more confidence of success and the ability to build on our software etc.
First Flash test allowed successful booting off Flash and write of a byte to it. Didn't even need any of the MMC1 CHR bank outputs, aside from one for A17 of the flash since it was larger than 256KB. Next test, putting a NES program into it.
Heh, I missed the PIC32 mention.
marshallh wrote:
TQFP100 package. Anybody who has a $15 radioshack iron, flux, and solder wick can solder it.
Anybody can, but not many will. I don't think this part would work as well in a build-it-yourself kit. This part is extremely small and I think 0.4mm pitch, it's nothing like the TQFP packaging on the MMC3.
I'm actually designing the PIC32 into my rev3 Squeedo (the old one designed 5 years ago used PIC18). I think the NES could run sequential code directly off if it, but I don't see how that could work for random accesses like the NMI/reset vectors, branches, jumps and stuff like that. So you still pretty much need a normal memory chip. The rev3 Squeedo will have some extra stuff in there to tie it all together, so my design isn't really made to be inexpensive. It definitely will be cheaper than the PowerPak though (and far more capable for development).
Flash works perfectly (if you don't
leave one of the address pins floating, that is!). To handle writing, Flash /CS goes to /CART (50 on edge connector), and /OE goes to ROM /CS from the MMC1, and of course /WE goes to /WR on the bus. This was a 512K Flash, so A18 was wired to a CHR bank output of the MMC1. Sweet Home and Zelda both ran successfully on this.
Writing to Flash worked fine, as predicted. I selected the 16K bank at $8000 via the MMC1 PRG register, then wrote to the Flash there, repeated for each 16K bank. Programming the flash involves alternating writes with the high bit set and clear, so the MMC1 shift register gets reset and thus no registers get modified. Resetting the shift register sets bits 2 and 3 of the $8000 MMC1 register, but that's the mode I have it in, so no problem.
The next step is to add the ability to disable the MMC1, and make CHR RAM read-only. This involves a resistor+diode pair each. That's being wired as I write this...