External EPROM burners are pretty handy gadgets to have around. They obviously can read and write EPROMS, but often times they will also handle a pile of PIC’s, some AVR’s, and other programmable logic like PAL/GAL and CLPD’s. While you can often find old models floating around for cheap (or free in my case) there are a few issues to be hammered out.
Typically the models you’re going to get for a song and a dance are old parallel port models that use software in MS-DOS or Windows and hasn’t been updated since. The software typically bit bangs the port using it like a 1 byte wide GPIO line, and this was a common trick, that is long gone from current operating systems by default.
[Doug] sought to find a solution to using one of these gadgets on Windows 7 X64, and lots of Google-fu, poking at libraries, and a little code modification he does just that getting his Sivava Willem EPROM programmer working like a champ on a nice new i7 with a parallel port add in card.
It sounds to me like there’s a market out there for a usb-based GPIO device. Since recent OSes don’t let you directly bit-bash parallel or serial ports any more, it’d be nice to have a cheap USB device that would allow us to do exactly that.
Or is there one already that I’m unaware of?
I’m sure there’s something out there, but a teensy-based device (or any USB capable AVR board) would be easy to make, fast, and quite extensible. Those qualities are certainly good to have in a product for hackers.
There is, but that doesn’t always solve the problem. At work we’re invested in a particular USB based SPI ROM burner that only has Win32 drivers. I discovered that this was a problem only after we upgraded a bunch of machines to Win7 x64
Try looking at FTDI modules, they are fairly easy to program, USB to JTAG/Serial/GPIO/etc.
http://www.ftdichip.com/Products/Modules/DLPModules.htm
I have used these for a number of different projects just to get quick and easy bit banging from a USB port.
There is no need to develop such a hardware. An Arduino with a simple program can do that. Just write a program that receives serial commands that can control the pins.
The problem is the timing. USB has no guarantee to send your message in time so it is impossible to do anything real time through that. To handle a digital protocol fine you need exact timings many times. With a real time kernel and a PCI-parallel port adapter you have chance to fulfil your timing constraints.
The problem is getting the existing software to talk to the device still. Doug bought a parallel port card but because it wasn’t at the usual IO address, it required extra work to get it running.
rizsi makes a good point regarding timing as well. USB is horribly inefficient with small packets and prefers that you do big bulk transfers. The timing for most parallel port attached devices is usually all within the software and the device itself has fairly minimal intelligence.
I think CLPD should be CPLD, I wanted to email Kevin but I have no idea where his email is.
kevin@thissite
A thanks for sending the article in would have been nice Kevin.
I wonder if this approach would work with a parallel to usb converter added to the mix instead of an expansion card?
There is no such thing as a commercial usb-parallel adapter. The things you use to hook up a centronics printer to usb are only parallel print support. Really using them as gpio as you could do with real parallel ports doesn’t just work like that. There is some guy the built a real usb-parallel adapter based on an atmega8, but it really was buggy at times of xp x32 already…
Actually there are usb-parallel adapters that have real parallel support. The problem is finding them for sale. The one made by epson contains the USS725 chipset . That chipset not only support printers but can even connect to ATA hard drives and provides true GP I/O . It is a shame it is so hard to come by now. I bought several when I took one apart and found out the chipset it uses. Very simple to interface too. It contains an external eprom to load the code to tell it what interface it should be , has usb lines on one side and the other side is straight I/O.
Here is a page with more info:
http://bjorn.haxx.se/uss725/
I also found this discussion on the same chip on the hackaday forums
I’d be interested to hear if someone knows where the 64-bit issues come from (I’m still using 32-bit Windows for its support for unsigned drivers and 16-bit software). I initially used the 32-bit version of io.dll but replaced it with the mentioned 64-bit-compatible version having had reports from people that it fixed the issues for them on 64-bit Windows. Evidently it didn’t fix the issues for everyone, but at least I now know where to point people when I get the next support email. :-)
Hi Ben,
Thanks for creating that remapped DLL! I would never have thought to create something like that. It’s interesting that you got reports from people who had it working on 64-bit. Maybe I was missing a step or something. Oh well, now we have two different options for people to try :)
Thank you, and I’m glad you’ve worked on the problem as it seems that what works on one machine doesn’t work on another for no apparent reason when it comes to parallel ports. The more options when it comes to fixing things the better!
I made a mistake in my previous post, though – I meant the 64-bit compatible version of inpout32.dll, not io.dll. I think I only got feedback about this alternative DLL working on both 32-bit and 64-bit Windows some time after you published your article, though, so I guess that’s why it didn’t work for you at the time.
What blows me away is that many current shipping programmers still don’t support Windows 7 x64. Like ATMEL’s SAM-BA stuff. At least, a year ago it didn’t, and Windows 7 x64 has been shipped on probably half of all computers for several years now.
Honestly, the idea that companies are just ignoring this issue is just insane. Our products don’t work on 50% of shipping computers? Eh, oh well. No biggie.
Maybe it’s more correct the other way round. M$ hasn’t managed it to create a proper backward compatible OS. For this very reason I changed to Linux years ago, also because of the huge amount of memory the new M$ OSes waste for themself. I still like to use my old SlotA Athlon with 1.5 GB Ram
What I want to know is why no hacker has come up with an “open source” programmer/reader that can read and/or write all these chips. I mean “open source” in that the PCB design, schematics and code would be free and open for anyone to use.
No more need to buy expensive addon modules to read obscure ROMs, if you have a datasheet or know how to talk to the ROM, you just build an adapter and write some code for the programmer that knows how to talk to the adapter.
An idea I have, but haven’t tried out yet to get the willem working on windows 7 64bit. The willem I’ve got uses portio32, which is a library to access ports. I’ve dealt with portio32 before, when dealing with flashing xbox 360 dvd drives. Since that’s a very common mod which requires direct access to a sata port (via portio), there are guides all over for getting portio64 to work on windows 7 64bit. Here’s a link to the dll: http://forums.360mods.net/downloads.php?do=file&id=19
just put it in the same folder as the exe for the program that uses it, or in windows\system32 (I think). You will also need to disable driver signing to get it to work.
I have yet to do this, because I have a lot of old crap that doesn’t work on anything newer than XP (and I didn’t wanna enable test mode in 7 for unsigned drivers), so I just put a second hard drive in my computer and dual boot XP. It’s an HP with a dual core proc (1.6GHz) and onboard parallel. Pretty decent for $10 too ;)
I have win 7 64 bit and a Willem from Sivava and it works great. I am actually the first poster in the posted article. ;)
A amusing illustration of windows x64’s issues is that MS includes a driver for the hardware ‘beep’ speaker on the motherboard, but it’s not capable of making the damn thing actually beep, even MS can’t manage to figure out things when going x64.