It is currently Thu Jun 29, 2017 5:31 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: Sat May 13, 2017 1:19 am 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 172
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 :)


Top
 Profile  
 
PostPosted: Sat May 13, 2017 3:30 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3439
Location: Indianapolis
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.


Top
 Profile  
 
PostPosted: Sat May 13, 2017 8:10 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 151
Location: Poland
Quote:
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.


Top
 Profile  
 
PostPosted: Sat May 13, 2017 9:46 am 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 172
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)


Top
 Profile  
 
PostPosted: Sat May 13, 2017 10:50 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5333
Location: Canada
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.


Top
 Profile  
 
PostPosted: Sat May 13, 2017 5:03 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1819
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Mon May 15, 2017 4:20 am 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 172
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.


Top
 Profile  
 
PostPosted: Mon May 15, 2017 8:56 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1819
Location: WhereverIparkIt, USA
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.

Quote:
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


Top
 Profile  
 
PostPosted: Wed May 17, 2017 1:19 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3439
Location: Indianapolis
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.


Top
 Profile  
 
PostPosted: Wed May 17, 2017 1:49 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1819
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Wed May 17, 2017 6:19 am 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 172
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?


Top
 Profile  
 
PostPosted: Wed May 17, 2017 9:41 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1819
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Wed May 17, 2017 2:20 pm 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 172
Thanks. I'm getting ahead of myself :P


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Majestic-12 [Bot] and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group