koitsu wrote:
Have the IP capability added to PowerPak
Sure, that would be an excellent use. No swapping CF cards, allow for the transmission of saved games, etc.
koitsu wrote:
Somehow make the USB keyboard work like the Famicom keyboard
lidnariq wrote:
Make it backwards compatible with the family basic keyboard, maybe?
Right now the USB KB adapter loads a full byte at a time directly to the data bus, but I can rework it to include a 4021 and pass data to the second controller port. Either that or bitbang it in software like I did with the NES232 last year. This might allow for the addition of a device to emulate the tape drive down the road. Biggest obstacle to all this? I don't have an original Famicom keyboard and tape drive to examine and test with.
koitsu wrote:
Some general jerk-off device. That is to say, some sort of "Bragging rights" thing;
Bragging rights would be nice and all, but I had something a little more useful in mind. The guys that built the Ethernet cart for the Atari had a wicked idea. Problem is that I don't know of any games or dev tools that take advantage of it. Writing a web browser or telnet client for the NES would be a neat proof of concept, but that's about it. A device which simply replies to pings and provides no useful functions would indeed be a "jerk-off device". Look at Rob the Robot. Poor little bastard only had two games and didn't really do much. How sad.
I don't really care about appeasing any architecture fanatics. I just want to make sure I include the functions necessary for a ROM to tell the device to initiate an IPv4 session and watch for failures. The device itself is loosely similar to an HP JetDirect. It runs the actual IPv4 stack and passes data to the NES. The NES tells it where to connect, sets dictates data channels, gets session stats, etc.
So let's say you're rewriting the firmware for the PowerPak to download a file from a web server. From a developer's standpoint, how would you like to accomplish this?
For example...
Write channel setup command to $4800
0x08 - Command length
0x01 - Virtual Channel ID (1 = command channel)
0x01 - Command (1 = new session)
0x0A - New Virtual Channel ID
0xC0 - IP Byte 1
0xA8 - IP Byte 2
0x01 - IP Byte 3
0x0A - IP Byte 4
0x00 - TCP Port High
0x50 - TCP Port Low
Read response from device
0x03 - Command length
0x01 - Virtual Channel ID
0x02 - Command (2 = session status)
0x01 - Status (1 = Successful channel setup)
Send data over channel
0x10 - Command length
0x0A - Virtual Channel ID
(followed by "GET / HTTP/1.1\n")
Then read the response from the device.
[Weren't you forgetting ports 256 on up? --MOD]