Refining design for really low-cost devcart
Moderators: B00daW, Moderators
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.
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.
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).
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.
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.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.
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.
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.
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.
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?
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?
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).tokumaru wrote:They could have a whole set devcarts using different mappers.
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.
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).
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).
And then you might as well buy a ROM emulator, heheh.tepples wrote:But once you have three such carts, you might as well buy a PowerPak, unless you're developing for an unsupported mappertokumaru wrote:They could have a whole set devcarts using different mappers.
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.
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.
Last edited by arfink on Thu Aug 05, 2010 1:55 pm, edited 1 time in total.