Trying to realize BNROM + USB

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

Post Reply
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Trying to realize BNROM + USB

Post by pubby »

I'm a layman (read: idiot) when it comes to hardware, but recently I've been entertaining the idea of trying to make a BNROM cartridge that can be flashed (programmed?) via a USB connection. I probably won't succeed in the end, but maybe I can learn something in the process.

Searching around, I'm *guessing* BNROM could use the following parts:
  • 804-GLS27SF010-70PHE (1Mbit flash memory)
  • AS6C6264-55PCN (64Kbit SRAM)
  • 74HC161 (binary counter)
  • ATTINY13A-PU-ND (microcontroller for emulating CIC)
And then maybe a decoupling capacitor (or two?).

Since Deadly Towers exists, I could probably just use that cartridge's PCB as a starting point. I don't think I'd need an EE degree to figure BNROM out, but correct me if I'm mistaken.

But then we get to the USB part, which seems harder. I want the cartridge to have a USB connector that can retrieve binaries from my computer, without requiring any external devices. I looked at how the Kazzo does it, and it appears to use an ATmega16 for most of the work. It seems like with the V-USB library, an Atmel microcontroller could be wired to the flash memory and that's enough to erase/rewrite it.

I also wonder if it's possible to use a smaller chip than the ATmega16, and if it's possible to combine the USB microcontroller with the CIC microcontroller. A single chip for both sounds ideal, really.

Hopefully someone can straighten things out :)
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: Trying to realize BNROM + USB

Post by Memblers »

Using the CIC for double-duty would be tricky, I take it you've seen INL's recent posts on the subject. Seems like it can be done, but it would be an impressive accomplishment in itself.

What you're describing is similar to the starting point of my GTROM kit. :) The NES CPU can easily connect over USB if you use a chip like the FT232 or PL2303, it handles all the USB protocol-level stuff, and you get a dirt-simple data connection. The NES can send data at any time, but to receive data it will be missed if it's not constantly polling for it. I use these parts over the controller port, but if you're putting the interface on the cartridge, you have much better options. The FT245 would be great in that case, you won't have to poll and you read a byte at a time instead of a bit.

At least for PICs, the smallest USB capable one I've messed with is the PIC16F1454, it's about $1. With that I've been able to use Microchip's USB CDC (communications device class) library, and that seems to work. If you have an MCU involved, then you also need some kind of interface for the NES and MCU to communicate.

If on-cart USB is what you want, I would suggest the FT245. Then you'll need some logic to map the FT245 into memory, generating read and write control for it. Another thing is that chip has 2 status outputs, to check if it's ready for a read or write. For those you would create another readable register.

Maybe you could skip those status bits, assuming you can predict what it will return when you read when it's not ready (I'd assume 0, $FF, or open bus, but I don't know if it's specified). Then in your data you would use some kind of escape character to avoid sending that byte as data. But it's maybe a bit ridiculous to cut corners that much.

The reason I use a Game Genie with my GTROM kit, is so I can write to the cart while the chip is fully blank. You can use that to put a bootloader onto a cart, then you don't need the Game Genie anymore. You pretty much need some NES code to always live on the cartridge. If you don't want the Game Genie you could put an EPROM on the cartridge for the NES to boot into. You could also use RAM if you want the cart to write a little faster, could add battery backup maybe. If the speed really mattered.

You could have an MCU write the ROM, but that's going to require some hardware to prevent the MCU from conflicting with the NES.
User avatar
krzysiobal
Posts: 1036
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: Trying to realize BNROM + USB

Post by krzysiobal »

I also wonder if it's possible to use a smaller chip than the ATmega16, and if it's possible to combine the USB microcontroller with the CIC microcontroller. A single chip for both sounds ideal, really.
V-USB needs AVR to be clocked from external stable crystal (16 MHz), while in CIC-emulation mode, it is clocked from external source (NES CLK). That's one of million reasons you cannot combine those functionalities.

Second is that while in USB-polling function, AVR cannot do anything else because USB timigs will no longer be satisfied and thus device will be disconnected from PC. But CIC emulation need constant feeding out the data to console's CIC.
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: Trying to realize BNROM + USB

Post by pubby »

Oh, to clarify I would only use the USB connector when the cartridge is disconnected from the NES. The microcontroller would run the CIC code, or the USB code; not both. The flash memory would only be rewritable by USB, connected to a computer. I don't know if that makes it any more possible.
Memblers wrote:What you're describing is similar to the starting point of my GTROM kit. :)
The GTROM is my backup plan ;)

(or maybe it's my real plan and this thread is my pipe dream)
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Trying to realize BNROM + USB

Post by rainwarrior »

pubby wrote:Since Deadly Towers exists, I could probably just use that cartridge's PCB as a starting point. I don't think I'd need an EE degree to figure BNROM out, but correct me if I'm mistaken.
I don't think Deadly Towers is a great starting point, since it has very limited capacity (doesn't connect all lines of the 161) and probably has a non-JEDEC pinout for its mask ROM.

A lot of existing repro boards have BNROM support, or can easily support it with one or two extra wires. I would suggest going with those.
pubby wrote:Oh, to clarify I would only use the USB connector when the cartridge is disconnected from the NES.
At this point though, wouldn't it be more cost effective to have the USB device outside the cartridge? (One device can program many cartridges.) I mean, that's what the Kazzo already is.

USB-on-cart is mostly helpful for trying to do rapid iteration, where you need to try a lot of quick software changes without having to unplug/reconnect stuff. Myself I used to think this would be useful, but after I got the hang of what works on emulators but not hardware, I haven't really had a case where it wasn't easier to just use emulators for the rapid iteration.

The only time I've ever really got good use out of a USB cart was when programming an Everdrive N8 mapper, but in that case I was updating the mapper itself, not the NES ROM. Something I couldn't do with an emulator anyway.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Trying to realize BNROM + USB

Post by infiniteneslives »

The biggest challenge you have to overcome is how this mcu of yours is going to access all 19 address lines (for 4Mbit), 8 data lines, and 2-3 enable pins of your BNROM's flash rom. The mcu needs to somehow directly or indirectly have access to all 29-30 pins of the flash. [EDIT: I thought you were targeting 4Mbit (512KB) BNROM, 1Mbit would be 2 fewer address lines]

A direct means would be to have an mcu with 30 some i/o to spare, which certainly isn't a small mcu. Could easily trim that down a little by having the mcu access rom A15-A18 via the same 161 counter the NES uses. That would save ~4 i/o, but also require some means to differentiate between flash and register writes prob costing you an extra i/o. That only gets you down to ~26io though, still quite a hefty mcu. Perhaps you could go with a smaller mcu and then bunch of io expanders of some sort, but in general I've found a bigger mcu with more i/o is going to be cheaper and simpler design overall.

Taking an indirect approach would allow the mcu to be simplified by a fair amount. This approach is the more common one and requires some other off cartridge device to handle the flash operations. The truest to your idea I can think of along the lines of what you've mentioned would be to have a USB capable mcu feed data to the NES CPU, and the NES handles the flash operations. From a hardware standpoint this is much simpler/cheaper than the direct approach above, but gets rather complex from a software standpoint. Have to figure out a means to get your flash routine up and running on the NES CPU, and orchestrate the data movements. This also comes with the complication that your mcu will most likely have to operate as a CIC and USB device at the same time. That's not really possible with bitbanged V-USB, but could be managed with hardware USB and a CIC implementation that doesn't manage timing by means of instruction cycle counting. Doing that gets rather complex, and if you're not very cost sensitive it's much easier to have two separate mcu's for CIC/USB. See my recent thread for a more in depth discussion.

Figuring out how you're going to get your little USB mcu access to perform all those flash operations is the biggest hurdle you have. This will be the most challenging without "EE skills", but IMO anything is possible without a EE (or any) degree if your motivated enough to learn and experiment with internet resources at your side. The BNROM mapper and PCB layout itself is rather simple, and well within reach for a hobbyist without a EE.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: Trying to realize BNROM + USB

Post by pubby »

infiniteneslives wrote:The biggest challenge you have to overcome is how this mcu of yours is going to access all 19 address lines (for 4Mbit), 8 data lines, and 2-3 enable pins of your BNROM's flash rom. The mcu needs to somehow directly or indirectly have access to all 29-30 pins of the flash. [EDIT: I thought you were targeting 4Mbit (512KB) BNROM, 1Mbit would be 2 fewer address lines]
For curiosity's sake, would it be possible to use something like a shift register or a ripple counter to reduce the number of MCU pins needed? I guess that wouldn't simplify the problem, but I want to make sure my understanding of what chips do isn't wrong.

I don't have much else to say until I get to experimenting. It will probably take a month or three before I even have parts in front of me, so this thread will go into hibernation until then.

I really appreciate the comments though. Memblers and INL: you guys are like rockstars to me.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Trying to realize BNROM + USB

Post by infiniteneslives »

pubby wrote:For curiosity's sake, would it be possible to use something like a shift register or a ripple counter to reduce the number of MCU pins needed?
Yes, but whatever you connect needs to have the ability to tristate/disable its output driver so the NES can drive the signal when you're playing the cart.

Ripple counters prob aren't a very good choice as few/none of those lines are accessed sequentially. Take some time to read over the flash chip you plan on using to get a good understanding of how it works. 39SF0x0 is a popular one, and requires A0-14 to be toggled between $2AAA/$5555 to unlock the chip before each byte is flashed. So counting up to those addresses is possible but will take a lot of time. Shift registers would be much better suited.
I really appreciate the comments
No prob, much like everyone else on the forum we just enjoy helping others and rambling on about our hobbies. My biggest advice is to just start building something, and trying to get some portions working. The things you'll learn in the process are hard to learn any other way. Often your first projects start off looking nothing like how you first imagined. So don't get too caught up in making the best choices, just dig in and be prepared to scrap large portions once you've learned more and can make more educated decisions.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: Trying to realize BNROM + USB

Post by Memblers »

There are plenty of other options, but one I/O expander I've been using on some test equipment is MCP23S17. Might be overkill for this use, but that mostly depends if you're using 10s of them or thousands of them.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Trying to realize BNROM + USB

Post by infiniteneslives »

Memblers wrote:There are plenty of other options, but one I/O expander I've been using on some test equipment is MCP23S17.
Problem is at $1 for 13-16 extra i/o you may as well just go with a higher i/o count mcu with easily accessed i/o for a project like this. There are of course cheaper means of i/o expansion as you're eluding to though.

For pubby's project I would recommend starting with a larger mcu with enough i/o to directly address the PRG-ROM. Get everything working first by simplest means possible (KISS). Then once everything is working you can worry about making things efficient and cost effective if you want to take the project to the next level. That'll be the easy part once you get everything working. Trying to create a hardware design that's highly efficient when you're still learning the ropes is only going to make things unnecessarily difficult for yourself with no payout. As they say, learn to walk before you run.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: Trying to realize BNROM + USB

Post by pubby »

infiniteneslives wrote:The truest to your idea I can think of along the lines of what you've mentioned would be to have a USB capable mcu feed data to the NES CPU, and the NES handles the flash operations. From a hardware standpoint this is much simpler/cheaper than the direct approach above, but gets rather complex from a software standpoint. Have to figure out a means to get your flash routine up and running on the NES CPU, and orchestrate the data movements. This also comes with the complication that your mcu will most likely have to operate as a CIC and USB device at the same time.
I've heard disabling the CIC causes the NES to reset every second or so. This seems like a big enough window for the NES to perform flash operations before resetting. My hunch is that the entire flash chip could be programmed over several reset cycles without requiring the CIC to run properly.

This seems easiest if a boot loader is already programmed into the flash. Is it cheap to buy flash memory pre-programmed?
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Trying to realize BNROM + USB

Post by infiniteneslives »

You'll likely need more that 1 second to flash 128KB as flash operations can be quite lengthy. Take a look at the SST 39SF0x0 datasheet or whatever chip you choose to get an idea of typical flash times.

If you're trying to make use of multiple cycles of the CIC reset, you'll have to be very cautious and tricky as to how you handle everything. I can't really think of a good way to do it if the NES CPU is handling all the flash operations. I'd guess it's possible, but it'll require some real trickery. One of the biggest issues is the flash can't be executed from (including fetching reset vectors) while a flash/erase operation is in progress.

Another problem with trying to use a bootloader with BNROM is that you don't have a fixed bank for the NES to boot from. Leaving a bootloader stub in every single bank of a BNROM will be quite a limitation for whatever game you're trying to develop. Perhaps you can utilize the mcu to overcome this issue though.

Writing your own CIC implementation is no simple feat. IMO at this point trying to come up with a way to save 50cents by putting the CIC and USB into a single mcu over complicates things. Get everything working with two separate mcus allowing you to completely ignore the CIC for now. Then if you're really motivated to save that ~50cents figure out how to put the USB and CIC functions into a single mcu.

IDK how much it costs to have flash chips pre-programmed, in general you're better off simply flashing them yourself especially for a small scale just based on logisitics alone. Get the code and everything working and polished to the point where you think you're ready to freeze your code and then figure out the best way to flash the bootloader. Borrowing trouble to worry too much about it at this stage.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: Trying to realize BNROM + USB

Post by pubby »

Thanks. I'm getting ahead of myself :P
Post Reply