It is currently Sat Dec 16, 2017 8:11 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Sun Jan 26, 2014 8:29 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
What bits should the serial bootloader read from? The candidates for input are D0, D1, D2, D3, and D4 of the second controller port (we keep the first controller port free for a normal controller).

Supporting anything different than just D0 in the serial receive routine only adds a couple of extra instructions and isn't a problem. This allows it to receive serial on any one of the inputs, *as long as the other inputs stay idle (high)*. This is the case for D1-D4 when nothing is connected. For D0, if we set the controller latch to 1 (LDA #1; STA $4016), and nothing is pressing the A button, it will output high and not interfere.

Ideally we'd just connect to an unused data line (D2?), but this would require modification of the NES and an extra plug/cord coming out since it's not on the controller port. So we allow connection through the controller port. Some information about what pins are available and limitations:

  • The NES controller port exposes D0, D3, and D4.
  • The expansion ports of the NES and Famicom expose D0, D1, D2, D3, and D4.
  • The second Famicom controller is hardwired to D0.
  • Many NES controller/extension cables only connect to D0, not D3 or D4.
  • NES expansion port connectors aren't very available AFAIK.
  • External Famicom controllers use D1.

* D0 seems like a must, to allow normal NES controller cables to be modified for this.

* D1 would be useful to allow modification of an external Famicom controller cable, which definitely connects D1 but may not connect to others (as with D0 on NES controller cables).

* D2 is nice because no controllers use it.

* D4 allows modification of a NES extension cable to pass through D0 to a second controller, and route D4 to serial, so you can have two controllers while doing PC communication. And it's available on expansion ports. Since I believe only the Zapper uses this, it would be a minor conflict. It should be solvable, as the Zapper just uses this for the trigger, so as long as the trigger isn't pressed while the PC is sending data, they wouldn't conflict.

Currently I have D0, D1, D2, and D4 specified, but this seems like an overkill. Having this many also seems risky because each one opens the opportunity for possible conflict; if anything is connected that generates a signal, it will confuse the bootloader so that it doesn't work.

At this point D0 and D4 seem like a good set. This allows using a normal NES controller cable, working on the Famicom with its built-in controllers, making a pass-through cable for a second controller on the NES, and connecting to the NES/Famicom expansion ports.


Top
 Profile  
 
PostPosted: Mon Jan 27, 2014 1:13 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 941
I recommend either D3 or D4, on the second port, since those are available in both NES and Famicom systems (and you can then connect a standard controller on the first port without having to rewire anything). Furthermore, you can use the standard controller at the same time, without interference. I also recommend to clear bit2 of the output port so that the keyboard doesn't interfere (hardware could be designed to automatically switch between the serial bootloader and keyboard based on this signal).

If you need to, due to "Many NES controller/extension cables only connect to D0", you could provide support for D0 as well as D4 (maybe do something in the program to check which one of D0 or D4 works, before actually loading, if this is possible and/or useful).

_________________
.


Top
 Profile  
 
PostPosted: Wed Jan 29, 2014 2:00 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
zzo38, I agree with everything you said. Thanks for the input.

I've thought more about the context, because these decisions depend on the purpose of the bootloader. I also realized that it might not be clear what its purpose and scope is. So...

* Bootloader's *only* purpose is to give PC control of NES by allowing it to upload a control program. Then PC can upload more code, send commands to control program, whatever. It's the minimal wedge the PC needs to "get into" the NES. It's the intentional remote-execution exploit so the PC can own the NES.

* Many different PC-to-NES connections are possible: bit-banged asynchronous serial, synchronous serial, parallel using multiple controller data bits (D0-D4), parallel over expansion port, parallel via I/O port on cartridge. Each connection type generally needs its own bootloader, because the protocol differs for each.

* Serial bootloader *only* addresses giving PC control using bit-banged serial over $4017.

I see the serial bootloader as being useful for entry-level program running on the NES. Getting it on a cartridge and running on the NES is the biggest hurdle, since it requires some kind of development cartridge, EPROM/flash programmer, and all the debugging. It's small, so it can be included as an extra feature in homebrew cartridges. Someone who wants to run small programs out of NES RAM can then build a simple serial interface and use the bootloader. The simplest cables just involve splicing a few wires from a few-dollar USB-TTL serial adapter to a NES controller/extension cable, something requiring just a pair of scissors and tape.

For people getting more capable interfaces, like parallel in a cartridge, the interface will come with a bootloader or they will already be able to program a cartridge with an appropriate bootloader. So the serial bootloader doesn't need to accommodate these people.

The main question is how much we want the bootloader in a homebrew cart to support. Would someone wiring serial up inside the NES (to say D2, to avoid conflict with anything else) not have already upgraded to a dedicated bootloader cartridge, and still just be using the one built into some homebrew cart they got? What about building a pass-through controller cable that allows connecting a second controller and serial at the same time?

If there were a risk-free way to have the serial bootloader support connection to any controller input pin, that'd be great. Perhaps it could first run in a loop that ORs repeated $4017 reads together for a while and ignores any bits that had a 1 on them (and of course ignores bits we know aren't reliable on a stock NES: D5-D7); this would leave only those that were 0 the whole time, either unconnected or serial (which is 0 in the idle state). This is still potentially more risky than deciding on one or two pins for serial and verifying through manual testing/research that these will be 0 if not being used for serial.


Top
 Profile  
 
PostPosted: Thu Jan 30, 2014 1:07 am 
Offline

Joined: Sat Aug 28, 2010 9:01 am
Posts: 204
I don't know how critical the size of the bootloader is, but how about using a knock sequence of 55 or AA to detect and initiate the transfer on any of the lines? The alternating bit pattern should be easy enough to detect, and will tell you which line to receive data from.


Top
 Profile  
 
PostPosted: Thu Jan 30, 2014 11:50 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1941
Location: WhereverIparkIt, USA
blargg wrote:
The main question is how much we want the bootloader in a homebrew cart to support. Would someone wiring serial up inside the NES (to say D2, to avoid conflict with anything else) not have already upgraded to a dedicated bootloader cartridge, and still just be using the one built into some homebrew cart they got? What about building a pass-through controller cable that allows connecting a second controller and serial at the same time?


So I'm still a little cloudy on what the issue is here. But my response to this main question would be to make it as *SIMPLE* as possible. Even if it comes at the cost of not working with every version of the console. A part of me thinks that relying on the controller port would actually deter people from getting started. While cords are available, to many, the idea of splicing up wires with scissors and taping some wires together is a deal breaker. Personally the idea makes me cringe... You need a better connection method to have a durable splice.

That said, I do have a small collection of controller plugs from controllers which had bad cords. I've been saving them over the years and would love to offload them for this use. I'd entertain the idea of assembling and making cables available for people at a low cost if there was a desire for them from the community. I bought a couple of those few dollar USB-TTL adapters you suggested in the other post and they just showed up. Tepples was asking for one for testing, and I was thinking about sending you one as well Blargg if it helped the cause. I just need to know how you'd like them wired up.

In my opinion, if the whole thing requires a cartridge anyways, utilizing a method of connection through the cartridge seems like the best route. If a female header were installed into the cart and made accessible, the connection issue would be resolved. You could just plug in the few dollar USB-TTL as-is from ebay. And would also be universally compatible aside from 60/72 pin conversions possibly. But for something like that, wouldn't you need mapper involvement as well? However this idea is a trade off between simplicity for the end user and simplicity for the hardware design. I'm not sure it's really worth the effort on the hardware side. If fully assembled controller cables were made available, then that would keep things simple for the user, but only require the effort on an as needed basis.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Thu Jan 30, 2014 5:20 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
I guess my angle is this: I've benefited greatly by a serial connection to the NES for running code on it and reverse-engineering the NES and cartridge mappers. A bootloader is the biggest hurdle and I've got small ones (down to 32 bytes). This could be put on some homebrew carts so others could benefit from a serial cable more easily.

The CopyNES is the only system I know of where you can upload and run new code just by pressing a key on the host. Aside from a controller cable, there's an expansion port interface or cartridge-based interface. I don't have the means to develop those, and they are more expensive and "pre-packaged" as compared to a DIY serial cable. Maybe I've been tilting at windmills and there's no problem to be solved, no demand for this in the first place.

I appreciate your input, especially the advice to keep it as simple as possible, as I've tried to meet a vague, imaginary audience's requirements and ended up with something overly-complex. Maybe we could treat this first round as experimental and go with a dead-simple one that just receives on D0 only, does no checksumming or anything and just runs it.

I especially appreciate your offer to help with the serial cables, and gladly accept whatever help you can give. I'll contact you about getting a cable built so you can send it to Tepples.

Quote:
In my opinion, if the whole thing requires a cartridge anyways, utilizing a method of connection through the cartridge seems like the best route.

A big benefit of this setup is that the cable can be used on anything that has the bootloader, e.g. a PowerPak, or a hotswapped cartridge on a NES with the CIC disabled. In the latter case one can try code on the cartridge to see how the mapper behaves. I believe thefox made a module so that a ROM can be uploaded to the PowerPak through the cable at the touch of a key on the host.

Quote:
If a female header were installed into the cart and made accessible, the connection issue would be resolved. You could just plug in the few dollar USB-TTL as-is from ebay. And would also be universally compatible aside from 60/72 pin conversions possibly. But for something like that, wouldn't you need mapper involvement as well?

That's an interesting next-level appproach, since the header is cheap to add. It probably would need mapper involvement, unless one wanted to be really tacky and connect the PC->NES line via a resistor to the data bus, and read from any open-bus address to access it (this would preclude NES->PC of course).


Top
 Profile  
 
PostPosted: Fri Jan 31, 2014 12:39 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2983
Location: Tampere, Finland
blargg wrote:
I guess my angle is this: I've benefited greatly by a serial connection to the NES for running code on it and reverse-engineering the NES and cartridge mappers. A bootloader is the biggest hurdle and I've got small ones (down to 32 bytes). This could be put on some homebrew carts so others could benefit from a serial cable more easily.

I've also benefited big time from it, particularly it has made it a lot easier for me to test new versions of my custom PowerPak mappers on the hardware.

It does seem like a lot of people are either not seeing the benefits, or don't consider it beneficial enough for most of their use cases. And granted, the actual use cases are quite limited when the bootloader is on a homebrew cart with limited resources (e.g. no extra RAM). Reverse engineering is the main thing that comes to mind. For development I think many people find it too limited, especially because nowadays it makes sense to do most of the development on emulators anyways.

I guess it could enable some fun toys for the owners of homebrew cartridges, such as being able to use it to transfer sound register writes (NSF player, MIDI playback, etc). Maybe it could enable extra content in the game or upload entirely new content. But I don't think a lot of people would be using it for development, without a specialized cartridge.

That's my $3,50.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Fri Jan 31, 2014 3:23 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6534
Location: Seattle
Well, if nothing else, it would allow arbitrary MIDI-NES like things, which won't need that much support.

I'd find it useful, even though I have a random flashcart I could use right now, to have it baked into something a little more versatile.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 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