I'm thinking about hooking some kind of network adapter (be it serial or some kind of embedded ethernet) to the ol' NES.
I've been trying to get some information about the expansion port, but haven't found too much. It seems like all you have to work with is an 8-bit data register, and the controller lines.
One ethernet controller I've been looking at (
http://www.invector.se/iet8900.asp) has the following signals:
A[0..4], D[0..7], reset, CS, RD, and WD.
Is there any way to use the signals on the expansion bus to drive it?
I suppose another way would be to use the cart lines, and put special hardware in the cart, but I'd rather not do that.
Failing that, could it be possible to hook up to a RS-232 device, like a modem?
Planning on using it with Contiki or something?
I don't think the expansion connector provides any address lines for decoding. This would be a very easy thing to hook up to the cartridge bus, just decode the chip's /CS to some area and make /RD = !(Phi2 && RW) and /WR = !(Phi2 && !RW), could be done with a 74138 and 7400.
You can definately use a modem too, you'd just need a MAX232 type device connected to the controller port or the expansion bus (through the controller bits) if you don't want to interface through memory I/O.
Technically, you could get away with just using $4016 D1/D2 for output and $4017 D1/D2 for input without conflicting with any controllers, and you'd get Famicom compatibility as a bonus (using its smaller expansion port).
I'm still pretty new at all this, so sorry if some of these questions are a little basic.
kyuusaku wrote:
I don't think the expansion connector provides any address lines for decoding. This would be a very easy thing to hook up to the cartridge bus, just decode the chip's /CS to some area and make /RD = !(Phi2 && RW) and /WR = !(Phi2 && !RW), could be done with a 74138 and 7400.
So if I understand correctly, you would map a certain memory area to the ethernet chip's address space?
I can't find any information on the Phi2 or RW lines - what do they do?
gannon wrote:
Planning on using it with Contiki or something?
Maybe at some point, but right now I'm just experimenting. I'd probably first make it a webserver or make a telnet client.
atarimike wrote:
kyuusaku wrote:
This would be a very easy thing to hook up to the cartridge bus, just decode the chip's /CS to some area and make /RD = !(Phi2 && RW) and /WR = !(Phi2 && !RW), could be done with a 74138 and 7400.
So if I understand correctly, you would map a certain memory area to the ethernet chip's address space?
Yes. See [[
Memory-mapped I/O]]. The networking controller would in effect become part of the mapper.
Quote:
I can't find any information on the Phi2 or RW lines - what do they do?
Phi2 is the clock. R/W is +5V for reads or GND for writes.
I like the idea of telnetting into retroMUD from a NES.
The problem with a telnet client is the difficulty of text entry: The NES (as sold in Latin-alphabet countries) has no alphabetic keyboard.
The Miracle Piano Teaching System game uses the strobe signal of controller port 1 to send midi data to the instrument.
EtherNES is still on my list of projects. My basic idea was to use an isa ethernet card, very basic to memory map into an address like the 5x00 range. The card is already set up to decode address ranges so you just need to connect the address lines in a way that will work. Control of the card is very easy through the isa registers and the card already has 8/16KB to buffer data.
You will find the net stack far more difficult than the hardware or low level driver software. UDP and DHCP are pretty basic but TCP is way complex. If you are using a proxy you can cut out some of the stuff like reordering but it is still messy. Frequently games will use UDP and add their own system to make sure messages are received, but web browsers/servers and telnet clients fully use TCP.
The last part of my plan was to take some classic games and rewrite them for net play. Latency should be no problem if the data rate is low. Yay multi player Excite Bike!
kyuusaku wrote:
I don't think the expansion connector provides any address lines for decoding. This would be a very easy thing to hook up to the cartridge bus, just decode the chip's /CS to some area and make /RD = !(Phi2 && RW) and /WR = !(Phi2 && !RW), could be done with a 74138 and 7400.
So the data lines are already hooked up to the expansion port, I would just need to worry about the address lines, right?
When you say decode to some area, how exactly would I do this? Would I wire the low 4 bits of the address bus to the expansion port, hook the chip to those lines, then pick some random region in memory, like $6000 - $6015, detect (how?) that location being active on the bus, and throw the /CS line in the ethernet chip?
quietust wrote:
Technically, you could get away with just using $4016 D1/D2 for output and $4017 D1/D2 for input without conflicting with any controllers, and you'd get Famicom compatibility as a bonus (using its smaller expansion port).
dwedit wrote:
The Miracle Piano Teaching System game uses the strobe signal of controller port 1 to send midi data to the instrument.
It looks like using the 8-bit data bus will work. I think I'm going to try to use that, as it's much faster.
tepples wrote:
The problem with a telnet client is the difficulty of text entry: The NES (as sold in Latin-alphabet countries) has no alphabetic keyboard.
That is a problem, as using an on-screen keyboard is really annoying.
bunnyboy wrote:
You will find the net stack far more difficult than the hardware or low level driver software. UDP and DHCP are pretty basic but TCP is way complex. If you are using a proxy you can cut out some of the stuff like reordering but it is still messy. Frequently games will use UDP and add their own system to make sure messages are received, but web browsers/servers and telnet clients fully use TCP.
Luckily, the full net stack is more in what I'm experienced, as opposed to the low-level hardware stuff. There's some a few good embedded stacks out there, such as the one for Contiki. Still, you're right, it's going to be quite a challenge working with the limited NES power.
As for text entry, it'd be a lot less annoying to just add a PS/2 keyboard connector than trying to implement an onscreen keyboard. Whatever extra cost might be added would be worth it, if you ask me.
What about the Famicom Keyboard.
-Rob
Only works with Famicoms, unless a connector were added to the cart, and is hard to obtain. PS/2 keyboards are all over the place for dirt cheap and are, in my experience, sturdier and more reliable than USB keyboards.
Why are they called PS/2 keyboards if they don't even work in a PS2? (Keyboards for PlayStation 2 are USB.)
Because they were intruduced with the
PS/2.
(actually the same kind of keyboard used on the AT, but with another connector)
I don't think I'm going to worry about a keyboard until I get the whole network thing going. It's going to be a big enough project without the keyboard.
I guess it would actually be much easier to get a keyboard working than a network, huh.
Yeah, hold off on the keyboard for now, but if you are going to do a telnet client, it'd be much easier to use than an onscreen keyboard.
I have keyboard working on Squeedo, that's how you navigate the UI currently, as a matter of fact.
Goes like:
PC Keyboard -> terminal (XMODEM) -> PIC interrupted, buffers -> NES gets IRQ when enabled, receives buffer.
There is also the el cheapo way, skipping the PIC and just hooking the serial line to the controller port. It's a crappy way to go though, because the NES can only receive keys when it keeps polling constantly.
I've been meaning to write a program that would allow the NES to write to the PIC, then have the PIC relay it to the PC where it could go to any TCP/IP port. The only prog I'd seen like that costs hundreds of bucks, which seems pretty nuts with how simple it should be..
Memblers wrote:
I've been meaning to write a program that would allow the NES to write to the PIC, then have the PIC relay it to the PC where it could go to any TCP/IP port. The only prog I'd seen like that costs hundreds of bucks, which seems pretty nuts with how simple it should be..
What you want to do is
set up a PPP server. What makes you think the PPP server software costs >200 USD? Or are you talking about having to put together a second PC using Linux-friendly hardware?
What about just interfacing it with CopyNES? Is that possible? Would it take any work out of the problem?
-Rob
tepples wrote:
Memblers wrote:
I've been meaning to write a program that would allow the NES to write to the PIC, then have the PIC relay it to the PC where it could go to any TCP/IP port. The only prog I'd seen like that costs hundreds of bucks, which seems pretty nuts with how simple it should be..
What you want to do is
set up a PPP server. What makes you think the PPP server software costs >200 USD? Or are you talking about having to put together a second PC using Linux-friendly hardware?
Here is the prog I was talking about, that does what I was looking for:
http://www.taltech.com/products/tcpcom.html
Seems simple enough.
Setting up a linux PC isn't really an option, I want to find or make software that would be included with the Squeedo kit and usable by almost anybody.
Did anyone ever get a NES Ethernet device working? This is an awesome idea.
No one has really started it yet. Just to review what's needed if a relay computer isn't used:
Hardware- basic (for me), I could hook up an ISA ethernet card in a couple minutes
UDP- somewhat easy, can include stuff like DHCP without too much extra work
TCP- INSANELY HARD! A cut down TCP stack would be barely possible with the amount of ram available. Stuff like reordering and reconstructing packets gets really messy. Could be ripped out of ContikiOS.
I'm actually working on this project right now,
More later...
I think you guys are missing a much easier solution to the EtherNES idea. Instead of trying to use one of the ethernet chips with address and data lines, why not use the Microchip ENC28J60. It is a 10baseT chip with an SPI interface.
There are two different designs that I have schematics for, one is just a simple ethernet adapter to get your NES on the net, the other has a PIC uC and the ENC28J60 so that it can do more stuff.
Simple EtherNES:
The design uses a 74HCT08 to do the 3.3V to 5V level shifting of the SO and INT lines from the ENC28J60. The ENC28J60 can tolerate the 5V SI and CLK signals from the CPU, but can only output 3.3V SO and INT signals. The interfacing is then done by bit-banging the SPI protocol using the expansion port pins of the controller registers $4016 and $4017. The
NinTech.txt file shows two pins/bits in each registister that go to the expansion port. My design uses the two bits in $4016 for the SPI CLK and CS lines and the two bits in the $4017 for the MOSI and MISO lines. The ENC28J60 pulls down the expansion port /IRQ line when it has received a packet. Incidentally, this design is so simple and compact that the PCB can be fitted to the expansion port and then the expansion port snap cover can be fitted back over it. You still have to cut a small hole in the cover for the ethernet port though.
The More Complex EtherNES:
This design uses one of PIC uC's to give the adapter more capabilities like audio output by hooking an analog out pin from the PIC uC to the AIN pin in the expansion port. The uC is also connected to the cart through the expansion port cart pins. This allows for things like downloading game code/data updates over the network and storing them on the cart, and also reading data from the cart at runtime for things like MP3 decoding and output. The primary 6502 interface works through the controller ports the same way the the simple design above does. This allows the same SPI protocol library to be used to talk to both devices.
If I could figure out how to successfully use the data lines on the expansion port, I could do a lot more in fewer clock cycles, since the serial protocols through the controller port registers are much slower. Maybe there's a way to use a custom mapper chip in the cart that will allow the expansion port cart pins to be used as address lines. The cpu could set a bit in a mapper register to flip it into "expansion mode". This would dynamically remap a segment of the cart's memory space into the "expansion port" by routing the address lines from the CPU to the expansion port cart pins allowing the CPU to send an address signal to the expansion port. The data bus pins work as normal to read/write a byte of data from/to the address specified by the expansion port cart pins. The only reason I don't like doing this for the primary access to the expansion port is that it (1) breaks possible famicom compatibility, and (2) it means the EtherNES would only be usable with specially built carts with the correct mapper hardware.
You know, the only thing that is preventing me from building and releasing either of these EtherNES adapters is a lack of a good part to interface with the expansion port. At this point, I'm talking with a company that may be able to customize their 48-pin card edge connector to fit the unusual dimensions of the expansion port "card" on the NES. If anybody has a good part for this, let me know and I'll unleash the long dreamed about EtherNES adapter on the world. I'll also release a software library for implementing the SPI protocol to talk to the device and port one of the embedded stacks to use it.
Ultimately, if I can get a connector part, I'll probably go with the more complex EtherNES design in the end because I really want to build a cart that has a ton of serial flash memory (256MB) that can be accessed through the expansion port cart pins to allow for code/data updates. The game would then be able to have short loading screens to pull data from the flash and populate parallel flash memory/ROMs. I have a completely fleshed out game design that would take advantage of the capability for some true 8-bit awesome.
Wookie wrote:
I think you guys are missing a much easier solution to the EtherNES idea. Instead of trying to use one of the ethernet chips with address and data lines, why not use the Microchip ENC28J60. It is a 10baseT chip with an SPI interface.
The parallel ethernet chips are generally chosen for speed (at least 10x faster than serial) and because they can be interfaced directly to the NES CPU bus with no parts. An ISA ethernet card can be configured to map its registers directly into the $4200 or $4300 range with no more hardware, just wires.
For networking the hardware is incredibly basic, and the software is incredibly hard. Unless you already have at least a UDP implementation programmed you haven't even started. No, most libs you can download will not work with the NES, they use far too much RAM and processor time. Soldering ~15 address/data lines isn't stopping anyone, its the huge programming job.
Wookie wrote:
You know, the only thing that is preventing me from building and releasing either of these EtherNES adapters is a lack of a good part to interface with the expansion port.
So you have finished network stacks using a prototype hand built version? What internal resources are left for the game?
Wookie wrote:
At this point, I'm talking with a company that may be able to customize their 48-pin card edge connector to fit the unusual dimensions of the expansion port "card" on the NES. If anybody has a good part for this, let me know and I'll unleash the long dreamed about EtherNES adapter on the world. I'll also release a software library for implementing the SPI protocol to talk to the device and port one of the embedded stacks to use it.
Unless you plan on making many thousands of parts there is no way injection molding will work (and I guarantee you will not sell thousands of these). It will cost many thousands of dollars for the mold alone, ~$10k last time I got it quoted. May be able to find a more direct place to do it for $3-5k, but if you only sell 100 then thats $30-50 for the plug alone. A far better idea would be to sell systems with the EtherNES board installed, or available as a solder in board like the CopyNES. If its really that cheap then you could have it inside the cart instead.
bunnyboy wrote:
The parallel ethernet chips are generally chosen for speed (at least 10x faster than serial) and because they can be interfaced directly to the NES CPU bus with no parts. An ISA ethernet card can be configured to map its registers directly into the $4200 or $4300 range with no more hardware, just wires.
Yes, but this solution doesn't work through the expansion port because the CPU's address lines aren't available there.
The network stack available for free from Microchip runs on embedded systems with much less resources than the NES. Speed isn't an issue either because the NES is going to be the bottleneck. You're right about the coding being a big job but I've implemented embedded stacks before. It really isn't that hard.
I have 48-pin connectors that almost fit. They're the right size, but the opening is just barely too skinny to take the thickness of the expansion port "card".
I found a solution to the connector problem. I just sliced my 48 pin connectors down the middle splitting the two rows of pins in two. It turns out that each side is just the right thickness to fit snugly between the expansion connector and its shell, so the two halves of the female socket don't have to be connected to ensure a good connection with the expansion bus.
Memblers wrote:
Setting up a linux PC isn't really an option, I want to find or make software that would be included with the Squeedo kit and usable by almost anybody.
How about this one
http://www.virtual-serial-port.org/prod ... -ethernet/ ?
Especially for telnet, I think a physical keyboard will definitely be better than the on-screen keyboard. Famicom keyboard protocol should be supported if possible even if it also supports another keyboard protocol. Even if implementing a gopher client, you should still support an external keyboard (to enter host names, selector strings, and query strings), although it can be less important in that case and on-screen might also be implemented in case you do not have the keyboard. (You can also implement both protocols in the same program.)
... Is there a reason we're necroposting?
No-one mentioned ConnectedNES because it didn't exist in 2009.
I'm not going to say that robroyo is spamming, but ... virtual-serial-port is a commercial product and basically entirely unrelated to the NES expansion port.
Oops sorry, didn't pay attention to the dates...