Page 1 of 1

JR-IDE add-on feature board

PostPosted: Sun Aug 31, 2014 12:20 am
by alanh
So I've been kicking around the idea of building an add-on board for JR-IDE (or usable on XT-IDE v2 or James' XT-IDE-Lite). It would have a right angle female 40 pin header that opposes the male header on the JR-IDE. So it would plug in just like a DoM and get its power from +5V on pin 20. It would basically have four things:

1) Level translation from 5V to 3.3V
2) Small FPGA - probably a MachXO2 1200 or 2000
3) Micro-SD card socket
4) WiFi Module w/ u.FL antenna connection

An IDE command set to SDIO card translator seems pretty straight forward in Verilog - respecting the normal IDE register set so the current code would not have to change. I have most of that design mapped out in my head already.

Since I'm already doing SDIO, I thought about using some of the reserved IDE register addresses on CS1 to implement a link layer to a WiFi module. My main question (mainly for Mike B) is which would be better? A relatively 'dumb' module where the host has to manage SSIDs, connections, possibly authentication, etc. Or a 'smart' module that handles most of the stack for you? The later seems preferable, however usually the smart modules just give you a connection handle and data primitives and it handles transporting that data over TCP or UDP including all the IP stack and TCP connection management. It doesn't lend itself to a simple packet driver implementation where it just marshalls raw frames to the wire.

This would replace whatever storage you currently have plugged into the JR-IDE and you would use a uSD card instead. Then you would coil up the u.FL 802.11 'wire' style antenna inside the side car connector. Packet driver format is pretty standard. Maybe we could write an NDIS driver to so MS-LANMAN, NETWARE, and related protocols would also work. Maybe ATA-over-Ethernet as well.



Re: JR-IDE add-on feature board

PostPosted: Sun Aug 31, 2014 12:31 am
by alanh
Oh and for reference the two module I am currently considering are 'dumb' = BlueGiga WF111 and 'smart' = WizNet WIZFI220

The WizNet module uses AT commands to setup a single TCP or UDP connection to a remote host. It might be interesting to set that up and have a packet driver tunnel frames to a server on a PC then it deliver them to the network. Just a though.

Re: JR-IDE add-on feature board

PostPosted: Sun Aug 31, 2014 8:20 pm
by Brutman
Hi Alan,

MicroSD would be really cool. They are dirt cheap compared to DOMs too. And they are easily movable to other systems with generic USB readers.

Disclaimer: I have to do some background research ... I've been moving the house the last two weeks so I'm finally in my new place, but everything needs to be organized. (I am finally at a permanent address again after a very long year!) The next time my Jr goes online it is going to be on 35MB/sec FIOS.

If "dumb" can be setup to give us basic connectivity to an access point without encryption then dumb is the closest thing to a conventional wired connection. The BlueGiga mentions it has Linux device drivers, so we at least would know how to talk to it. I'm not sure how much effort is required to get something like that associated with an AP; besides having a packet driver that sends and receives frames we might have to write a setup util for DOS that gets it associated with an AP. (And that's the research part that I need to do.) Assuming that isn't too painful, we'd have to write a packet driver. Existing software would work as is.

"Smart" would not be compatible with any TCP/IP software that exists today. Those kinds of devices are great for making a machine that is no more powerful than a terminal "Internet" ready, similar to the Lantronix devices. The single UDP or TCP connection works for a lot of applications, but you are never going to run a server type app (FTP server, web server, telnet BBS, etc.) on it. The packet driver trick seems problematic; it would have to be a pretty smart packet driver. If would have to detect the TCP/IP 3-way handshake and substitute the appropriate AT commands. The socket teardown process has similar problems.

I'll do some homework to see how things like The BlueGiga get associated.


Re: JR-IDE add-on feature board

PostPosted: Sun Aug 31, 2014 11:04 pm
by alanh
The trick would work differently than you assume. The packet driver would write a raw frame over a TCP connection setup and maintained by the smart module to another box. It would then feed that frame through a raw driver to the NIC (like the Linux tun/tap driver). Likewise, it would listen for and duplicate any frames received to the TCP pipe to the packet driver on the JR. You could even pre-screen frames on the PC to cut down on traffic by more than just mac address, broadcast address, and multicast hash.

Just a thought. I would rather have an simple interface to put frames 'on the air'. The authentication and encryption part worries me though. Maybe the FPGA could add a WPA2 accelerator. I'll do some additional research too.

Re: JR-IDE add-on feature board

PostPosted: Mon Sep 01, 2014 7:23 am
by Brutman
I was not thinking about tunneling - I was trying to keep things as close to conventional Ethernet as possible.

If we go that route then we add a dependency of having another machine, even just a small one like a Ras-pi. And the packet driver becomes simpler than what I was envisioning, but you still are burning all of the CPU cycles on the host to do the TCP/IP processing and checksumming. The MTU would be slightly smaller to accommodate the encapsulation, but otherwise the host would think everything is the same. (Well, lost packets might be a problem ... the timers would still be running on the host side while the gateway dealt with them. That could result in an interesting mess of duplicate packets.)

We could improve things by basically "hollowing out" the TCP stack on the host side so that it just sends primitives to the gateway machine on the other side of the tunnel.

I still prefer stand-alone though. After you've added a TCP/IP co-processor you might as well be on a ZX81. But this technique is intriguing ...

Re: "dumb" adapters

My primary concern with WPA2 is not the overhead; I already assumed that would be painful. The concern is with the availability of libraries that can do whatever certificate and key exchange is required; I don't think those libraries exist for DOS and porting them (and their dependencies) probably is not feasible. My digging is going to revolve around figuring out what is the minimum required number of bits to twiddle to get the device associated with an access point. After that, I assume it looks and smells like wired Ethernet.


PS: Is your Jr networked yet? Do you want to try out a Xircom for giggles?

Re: JR-IDE add-on feature board

PostPosted: Mon Sep 01, 2014 7:56 am
by alanh
My Jr isn't networked and that's the main reason I wanted to try this. I have plenty of other DOS machines that are - usually using PC/TCP and/or Sun PS-NFS.

I always assumed there would be a DOS utility to scan for SSIDs and configure the login credentials.

There is another option, though it might be considered a bit more like cheating. I could add a Carambola 2 on the card. It's basically an Atheros/RALink SoC with a MIPS processor core running Linux. However it would add both a wired RJ-45 10/100 Ethernet port (or 2) and Wireless and run Linux on the side-car. Oddly enough it's actually cheaper than most embedded smart or dumb modules. You would configure and run wpa_supplicant on the Linux box to automatically authenticate to and connect to SSIDs. You would talk to it from both a DOS config utility and packet driver over SPI or UART. Then Linux would bridge the JR connection to both networks.

What do you think?

Re: JR-IDE add-on feature board

PostPosted: Mon Sep 15, 2014 9:37 pm
by Brutman
I've done a little bit of reading and I have a lot more to do. But here are the highlights:

  • Wireless frames are like wired frames, only with more headers and more complex.
  • Getting associated without authentication is just a matter of sending an authentication frame and getting a response back. If there is no authentication enabled, then there is no encryption to worry about.

Next on the todo list is to try to get one of my Linux boxes with a wireless card setup to sniff packets over the air and to see if I can capture an authentication request to an open network. If it is as simple as it seems, then the big challenge will just be to write a packet driver for a wireless card that we have a data sheet for.

If you attach a WiFi module this way, will we be able to get an interrupt signaled ? Reading and writing data is just a matter of putting bytes on the right I/O addrs or in memory, but how would the WiFi module cause an interrupt to be fired?

An interrupt is not absolutely required; the Xircom adapters can be set to run without an IRQ. They hook the clock interrupt and poll the adapter instead, simulating the interrupt that would happen when a packets shows up. It works but it is pretty slow because you only get to poll once every 55ms. (Reprogramming the PIT for a tighter interval is not a great idea; something else might have already done that. My PING program is an example of that ...)

Re: JR-IDE add-on feature board

PostPosted: Mon Sep 15, 2014 11:24 pm
by alanh
I've been slammed at work. It will be another week or two before I can submit a board to the fab.

Either we'd have to do polled mode or I could run a line to a free pin on the IDE header and one could flywire a rework from the header to any one of the three IRQ lines on the DIP switch.

Re: JR-IDE add-on feature board

PostPosted: Tue Sep 16, 2014 7:36 am
by Brutman
There is no hurry here - I'm on call this week at work and traveling next week. :-(

An interrupt would be desirable. I have no problems attaching little jumper wires around.

Unless the board design is really independent of what I come up with, you might want to hold off a little bit. Besides the packet sniffing I also need to read source code/application notes to see if any other weirdness is required besides the ability to send and receive "raw"ish looking packets. (I'm hoping that just the setting of the magic frame type in the header or maybe a few additional registers before sending the packet is all that needs to be done to get it to authenticate, associate, etc.)