Complete IDE Disk Driver in Forth(colorforth.com)
colorforth.com
Complete IDE Disk Driver in Forth
http://colorforth.com/ide.html
14 comments
This is much more a statement about how simple the ATA port interface is than it is about Forth. Writing for hardware only sounds complicated to modern folks who have never tried it. Remember that these were devices built with a few thousand transistors at most. There's only so much complexity you can pack into that structure.
I wish there were more resources available detailing how to write drivers. I've had this dream in the back of my mind for a long time of hacking a standard USB port on the end of a Steel Battalion controller, and then writing a PC driver for it. But I wouldn't even know where to start, really.
You probably don't need to write a driver if the controller plugs into the Xbox's controller port. You can just download the Xbox controller drivers written by others.
That said, you may find the following resources useful (I certainly have):
Linux Device Drivers (a very helpful book, but the kernel API has changed a bit since its release):
http://lwn.net/Kernel/LDD3/
Windows Driver Development Kit (use Google to find the XP or Server 2003 versions if you need to develop for XP):
http://www.microsoft.com/whdc/devtools/WDK/default.mspx
libusb (write cross-platform USB drivers without touching kernel code):
http://www.libusb.org/
http://libusb-win32.sourceforge.net/
If you want to create a new device that's worth writing drivers for, start here (the USB Bit Whacker):
http://www.sparkfun.com/commerce/product_info.php?products_i...
http://www.curdes.com/gnupic/GnuPic.html
http://www.microchip.com/forums/tm.aspx?m=123533
That said, you may find the following resources useful (I certainly have):
Linux Device Drivers (a very helpful book, but the kernel API has changed a bit since its release):
http://lwn.net/Kernel/LDD3/
Windows Driver Development Kit (use Google to find the XP or Server 2003 versions if you need to develop for XP):
http://www.microsoft.com/whdc/devtools/WDK/default.mspx
libusb (write cross-platform USB drivers without touching kernel code):
http://www.libusb.org/
http://libusb-win32.sourceforge.net/
If you want to create a new device that's worth writing drivers for, start here (the USB Bit Whacker):
http://www.sparkfun.com/commerce/product_info.php?products_i...
http://www.curdes.com/gnupic/GnuPic.html
http://www.microchip.com/forums/tm.aspx?m=123533
Mac-specific, but cool. http://developer.apple.com/hardwaredrivers/
I've been working against IOKit lately.
I've been working against IOKit lately.
USB
Universal - No
Serial - No
Bus - No
leave the USB alone, seriously, that's my advice
Universal - No
Serial - No
Bus - No
leave the USB alone, seriously, that's my advice
Well, the issue is that Xbox controllers are already USB, they just have a special end.
...and they conveniently put those quick-disconnect dongles on the end so you can make your own normal dongles
It looks like some people have already written Windows drivers, if you wanted to experiment you might look at writing a userspace driver for Linux.
It's kind of strange that they built something custom instead of just implementing it as a couple standard HID devices with an internal hub.
It looks like some people have already written Windows drivers, if you wanted to experiment you might look at writing a userspace driver for Linux.
It's kind of strange that they built something custom instead of just implementing it as a couple standard HID devices with an internal hub.
It's kind of strange that they built something custom instead of just implementing it as a couple standard HID devices with an internal hub.
Depending on the USB chip/microcontroller used, it can be a lot easier to just toss in a bunch of vendor-specific requests instead of adhering to all the requirements of an HID-class device (though I haven't analyzed the Xbox controller itself, so I don't know if that's what was done).
Also, there's no need to use an internal hub, as a single USB device ("function" in the USB spec, IIRC) can have multiple "interfaces" that implement different (or the same) classes, such as HID, CDC, mass storage, or vendor-specific.
Depending on the USB chip/microcontroller used, it can be a lot easier to just toss in a bunch of vendor-specific requests instead of adhering to all the requirements of an HID-class device (though I haven't analyzed the Xbox controller itself, so I don't know if that's what was done).
Also, there's no need to use an internal hub, as a single USB device ("function" in the USB spec, IIRC) can have multiple "interfaces" that implement different (or the same) classes, such as HID, CDC, mass storage, or vendor-specific.
they do work fine once you replace the ends, I did it with mine
> There's only so much complexity you can pack into that structure.
This makes it sound complicated to us modern folk because that complexity hasn't gone away; it's just been moved into the software layer.
This makes it sound complicated to us modern folk because that complexity hasn't gone away; it's just been moved into the software layer.
I would not call it "complete". Maybe "complete" in the sense that it works under perfect conditions, but not "complete" in any real sense. I don't see any error handling or power-up initialization, I don't see any DMA, I don't see any timeouts, I don't see any interrupts.
I could write the same code in C and it would be just about as long.
I could write the same code in C and it would be just about as long.
Seeing things like this make me glad I started programming with a (then) higher level language like C.
Forth has made it to 1986!