Note:. The remainder of this post below is still very important, but I’d like to make sure everyone has the most up-to-date information about compatibility between the different DLLs and parallel port cards out there. If you’re looking for my patched io.dll for Willem programmer compatibility, see below.

Jun 18, 2012 - 11 min - Uploaded by KillertamagotchiHier mal ein kleines Unboxing von meinem neuen Willem EPROM Programmer in der. SIVAVA is authorized by Thai. Willem EPROM Programmer PCB50B© + PSOP 44 Socket to. Willem EPROM Programmer PCB50B©. 2.) CD Installation Software and.

Last year I bought a Willem EPROM programmer board from. It’s basically a cool little board with various sockets for plugging in EPROM/EEPROM/Flash/etc chips for reading/erasing/writing. Apparently it can even program some AVR microcontrollers. I have the PCB50 version of the board. Here’s the deal.

It has a USB port, but it’s only for supplying power. All communication goes through the parallel port. As everybody should know at this point, the parallel port is on the way out. No, scratch that.

The parallel port is long gone. I had to use a really old HP Pavilion with a Celeron running Windows 98 to do anything with it.

The programmer worked great, and I was able to fix a computer’s BIOS chip that I had messed up while trying to hack its BIOS. Let’s fast forward to over a year later (a.k.a. I have a homebuilt PC with an Intel DX58SO motherboard and a Core i7 CPU, running Windows 7 Ultimate edition, 64-bit. The DX58SO literally has no legacy peripherals, other than a single PCI slot. It has no PS/2 ports, no parallel port, no serial ports, and no standard IDE ports. It does have a variety of types of PCI Express slots, though.

I recently bought a sweet from Newegg. (Note: Newegg’s product specs lie about this card — the parallel port does not support EPP or ECP mode, according to a sticker on the box, even though Newegg says it does). I remembered that I had my programmer and decided I totally needed to get it working in Windows 7.

Easier said than done. It’s difficult enough to get low-level legacy stuff working in Windows 7, but when you’re using the 64-bit edition, a lot of older stuff breaks even more. Also let’s remember that add-on parallel ports do not get mapped to the standard I/O addresses for parallel ports (0x378 and 0x278), but instead some other random address (mine is at 0x3000). I tried running the software that came with the board, but it just gives me errors and actually won’t let me exit without forcing it to quit from the task manager. Let’s go on a Google adventure. Google lesson #1: sometimes when you’re looking for info about Windows 7 64-bit, you can find very useful stuff when you search for Vista 64-bit (or XP 64-bit) instead.

My first search was willem vista 64-bit. The second result was a digg posting titled Willem Eprom for Vista and 64bit XP (digg post is no longer available; link removed).

The linked page is a forum posting at a forum called onecamonly.com. The post is by the admin of the site, and he mentions to install software called and then a modified io.dll file. The first comment on the digg posting was by a user named rabitguy, who said he had a Willem board working on Windows 7 64-bit with tvicport and iodllwrapper. So I kept seeing this io.dll and iodllwrapper stuff. What exactly is it? Let’s Google for “io.dll”.

The first result is to a. Basically, it explains that it’s a library allowing direct port access from several different Windows versions. Except it doesn’t mention Windows Vista or Windows 7, or anything 64-bit at all.

Well, I looked in the installation directory for the Willem software that came with my Sivava programmer board, and sure enough, in C: Program Files (x86) EPROM50, there’s an evil file named io.dll. So that’s why it doesn’t work. So anyway, I searched for iodllwrapper, deciding to follow the advice of rabitguy. The first result is to a. I did a search on that page for “Willem” and found a posting by Toni Wilen who wrote a 64-bit-compatible io.dll wrapper which depends on TVicPort and uploaded it as an attachment to the forum, called iodllwrapper.zip. He even included the source code.

So I think I get it. He wrote a DLL that provides all the functions that io.dll would provide, except rather than implementing the raw functionality himself, he forwards the relevant function calls to TVicPort, which handles all the low level stuff (in a manner that works on 64-bit operating systems!). Actually it’s a pretty genius idea. So I downloaded his DLL and tried it out, replacing the stock io.dll file that came with the Willem software with his new wrapper. I crossed my fingers and opened the programmer software. I no longer got a bunch of weird errors when the program opened! I’m pretty sure Toni’s DLL would have worked great, but there’s a problem in my case.

I don’t have a built-in parallel port, so my parallel port is at a non-standard I/O address (0x3000). The Willem software only lets you choose from a list of three standard I/O addresses where built-in parallel ports would appear.

So I was stuck again. At this point I was about to throw in the towel. But first, I thought about it and came to the conclusion that I can’t be the only one with this problem. So I searched for io.dll willem address. The first result this time was.

So someone else had the exact same problem! Ben also wrote an IO.DLL wrapper (and he included his source code, too!). His solution is to add an additional file called io.ini into the same directory as io.dll. You put the I/O address of your parallel port into that file (so my io.ini file would contain one line — 0x3000), and set the Willem software to use LPT1.

The wrapper DLL looks for any I/O reads/writes in the LPT1 range and remaps them to actually occur at the address specified in the io.ini file. This is exactly what I needed! It uses another DLL called inpout32.dll to do the dirty work. Actually, Ben’s site very nicely describes everything his DLL does, so I won’t go into any more detail about it. Well, it turns out that his DLL didn’t work for me, either. It seems that it’s just not compatible with 64-bit Windows 7, at least in my experience. I just could not get it to work.

The Willem software would not detect the connected board. I looked at the homepage for inpout32, and apparently there is a 64-bit version, so maybe if I had fiddled long enough I could have gotten inpoutx64 to work, but at this point I actually had an idea of my own, after looking at the source code that Ben included for his DLL. I knew from everything I had read that Toni’s 64-bit-compatible io.dll wrapper using TVicPort did work. All it was missing was the remapping. So I took Ben’s code and modified it to use TVicPort rather than inpout32.dll. (Alternatively I could have added the remapping to Toni’s code.) I only changed a few lines.

I just changed the calls to inpout32.dll for reading/writing to use the corresponding TVicPort functions instead, and also added initialization and deinitialization code for TVicPort. So I compiled it with Visual C++ Express Edition 2008ran the “Test Hardware” function on the Willem softwareand success! It found the hardware! I was stoked, so I grabbed a BIOS chip from an old motherboard I’m not using anymore (Asus A7V133).

It’s a SyncMOS F29C51002T. I chose that model in the software, set up the DIP switches correctly, and stuck the chip in the cool ZIF socket on the programmer board. I then read the BIOS from the chip. I looked at the read buffer and it looked good!

I saw stuff about an Award BIOS, so it sure looked like it was working. I happened to have a good copy of the same BIOS file from when I had messed with that same chip on the older computer, so naturally I did a diff against them to make sure that the file was read correctly. It didn’t read correctly.

It differed by just a few bytes. It was mostly OK, but mostly is not good enough when you’re reading to/writing from chips that contain computer code and/or data. At this point I decided to sleep on it and think about it the next day. That approach really works well in all aspects of life in my experience.

When I had trouble learning to play a piano piece I would sleep on it and the next day it was like my brain had somehow prepared itself ahead of time, and I would play the part I had been struggling with perfectly. The next day I noticed that the TVicPort driver actually has an option for two I/O port access “modes.” The default mode is hard mode, which is slower, but provides more reliable access to an I/O port if it’s already been opened by a different driver.

Soft mode is faster, but has trouble if a port is already open by another driver. On a whim I decided to try out soft mode. I read the chip again, and this time it worked perfectly. I then erased it, wrote the file back, and compared it.

I did this several times just to make sure I wasn’t getting lucky, and it worked every time. So either I got really unlucky on my first try with hard mode, or using soft mode fixed it. I don’t know which one is the case, but regardless, I now have my programmer working in Windows 7 64-bit. And this is the end of our Google adventure. Google can do a lot of great things if you’re willing to sit down and search. I didn’t actually find all this stuff that easily. I tried many different searches, wording things slightly differently.

I ended up only showing you guys the search queries I tried that gave me interesting results. Sothank you to everyone I mentioned in my post. I’ve never met you or even corresponded with you, but you all helped me get this working. Thank you rabitguy, admin at onecamonly, Toni, and Ben. With all of your info I got it working.

So naturally, here’s my io.dll wrapper, based on Ben’s wrapper, along with the source code for it. Remember, I’m not responsible for any damage done by this software–it’s been tested lightly and seems to work for me, but your mileage may vary! (new version 1.1 which fixes a bug–thanks Paco!) You will also need to download TVicPort from. Install TVicPort, then restart your computer (mine didn’t work until I restarted, and it does ask you to restart). Replace the io.dll file in the Willem software directory (C: Program Files (x86) EPROM50 on my computer) with this patched version. Open up the io.ini file, replace the address there with your parallel port’s I/O address (make sure you keep the “0x” before the address or it won’t work), and put it in the same directory you just copied the DLL file to.

Set the Willem software to use LPT1 (0x378). If everything is working correctly, you should be able to go to the Help menu and choose Test hardware, and it will say “Hardware present” in the status bar at the bottom. If you need to compile the modified io.dll for yourself or make modifications, grab TVicPort.h and TVicPort.lib from the TVicPort installation (C: TVicPortPersonal Examples MSVC) and put them in the project directory. After doing that it should compile. Hope this helps anyone out there, and thanks again to everyone whose information and source code helped me out! A quick note: To find your parallel port’s I/O address, go into the Device Manager and open up your parallel port.

It’s in the Resources tab: The I/O range that is 8 bytes long (in my case, 3000-3007) is the important one. So prefix the start address with 0x (so in my case, I ended up with 0x3000) and that’s the value you should put in the io.ini file. Version History: • 1.1 – Fixed a bug where I was calling functions from DllMain that I should not have been calling, causing the DLL to not work for at least one person – August 15, 2011. • 1.0 – Initial release – October 9, 2010. Hi Shuan, It was an option that I compiled my patched IO.DLL with.

So if you downloaded the patched DLL from me, it is already using soft mode. I do have another idea, though — newer versions of Windows apparently poll the parallel port automatically for devices every so often. It’s possible that the polling process is interfering with reading/writing the EEPROM.

You could try doing the registry fix mentioned on the third question on this page: It mentions Windows XP, but I went ahead and added it on Windows 7 as well. Not sure if it will make a difference but it might be worth adding the registry entry there ([HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services Parport Parameters] “DisableWarmPoll”=dword:00000001) and rebooting. I hope that helps! Hi Amit, I’m not a Willem expert — in fact I’ve only used mine a handful of times. I’ll try to think of ideas though. It’s basically saying that it tried to write a 0x52 as the first byte, but it found a 0 there instead.

I’m not familiar with this particular chip, but a lot of the chips I have used end up with all the bytes being 0xFF after an erase. Are you sure the erase is working properly?

Also, have you verified that all the jumpers are correct? If you had to solder it, have you checked that all pins have good solder joints?

Other than that, it’s always possible that you have a bad chip, too. Hi Andy, Did you prefix the address in io.ini with “0x”? Also, make sure you only put the start address (0xDC00). So your io.ini file should be a single line containing: 0xDC00 There’s nothing special about that address that should cause it not to work, so hopefully that’s the problem there. 🙂 As for TVicPort, have you rebooted since installing it? I found that it didn’t work until I rebooted.

Let me know how it goes, and if it still doesn’t work we can do some troubleshooting to figure out why it’s not loading. Hi Doug, thanks for responding so quickly. Regarding your questions: Yes,I rebooted after installing the TVIC. Yes, my OS is windows 7 64 bit. Your new dll file and io.ini are in the same directory as the EpromM51.exe We also tell you that I do not happen the error “Could not parse adress in io.ini” as happens to Andy, I have only the error: “Could not open ICVT Driver” and does not detect the hardware. My motherboard has integrated parallel port at address 0x378. Doug thanks for your interest.

Hey no problem! Sorry about taking longer to reply today. Interestingthe fact that you’re not getting the first error about io.ini means that it is correctly reading the io.ini file, so that file is OK.

The “Could not open TVIC driver” error message appears if the call to TVicPort’s OpenTVicPort() function fails. Immediately after opening TVicPort, I check if it’s open. That message only is displayed if I’ve determined that it didn’t open correctly. It’s acting like TVicPort isn’t installed correctly, or it’s refusing to initialize for some other reason. Did you notice anything strange happen when you installed TVicPort?

I have 2 other ideas: 1. Install Usb Mouse Windows 95. Have you tried to find a newer version of EpromM51.exe? I have one version of that particular program name here that won’t run at all on my computer, but a newer one with that same name will. However it doesn’t exhibit the same problems you have with yours — it just doesn’t load at all. Have you tried Ben Ryves’ original remapped DLL that I linked to in the article?

His says that it does support 64-bit now, so it might be worth a shot. It doesn’t use TVicPort, so that might help. I could also try writing a simple program for you to run on your computer that only loads TVicPort and tells you whether it succeeded or not, so we could eliminate EpromM51.exe as causing any problems. Let me know if you’d like to try that out and I can throw something together pretty quick. Hello again Dough I have been testing the solutions that have told me with the following results: I uninstalled the TVIC and I installed the Ben Ryves Dll with the three files: “io.dll, io.ini, inpoutp32.dll” At this point the program does not fail at startup but the programmer is not recognized in the test. I’ve also tried another version of the program, specifically the 097ja version with the same result, anyway I can´t find more versions. (Now I use the version 098D11 whit the pcb50) My programmer works well because I can use with a virtual version of Windows XP.

Anyway, I’m willing to try anything that you propose to me. Hi Paco, Very interesting! Well, I made a quick test program for you to try: It will tell you whether it could open TVicPort or not.

Also, it will print some results in the command prompt window that appears. Here is what mine says: SERVICE_NAME: TVicPort64 TYPE: 1 KERNEL_DRIVER STATE: 4 RUNNING (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) WIN32_EXIT_CODE: 0 (0x0) SERVICE_EXIT_CODE: 0 (0x0) CHECKPOINT: 0x0 WAIT_HINT: 0x0 Let me know what you get! Make sure you have installed TVicPort and rebooted before running this app. Hi Paco, Thanks for running the app. The results show that TVicPort is running and installed correctly. In fact, it succeeded at opening TVicPort at the spot where it’s failing in the patched io.dll.

Have you tried running the programmer software again with the patched io.dll? Is it still showing the error? If it’s still showing the error when you use the DLL, I’m running out of ideas to try — have you redownloaded the patched io.dll in case your copy of it was corrupted or something? Do you have any antivirus software or something that might be interfering with loading the library through the DLL?

Have you tried running it as administrator? That’s a wild guess and I doubt any of those will help, but it might be worth trying. Even though you get that error message, does it work anyway? Have you tried the Test Hardware function to see if it’s communicating despite the error message?

Since your parallel port is at the standard 0x378 address, you could also try a non-remapped 64-bit io.dll. This one also uses TVicPort (it’s where I got the idea to use TVicPort): (iodllwrapper.zip). It might be worth a try. Let me know and I’ll keep trying to think about what else might be causing it not to load.

Hi Paco, Glad you got it working! The DLL that worked for you is also open source. It does a few different things when it loads TVicPort, but both methods should be working. The one that works for your computer explicitly loads TVicPort with LoadLibrary() and gets function pointers to the relevant functions through that. The DLL I’ve provided (originally by Ben and patched by me) links against TVicPort and tries to call it directly. So that LoadLibrary() call must be fixing it on your computer — I’m not sure why though!

🙂 If anybody else ever comes across this comment and has any ideas why, I would really appreciate it if they posted a comment here and told me. Well, thanks for letting me know that you got it working, I appreciate hearing back from you! I agree, this will be useful info to have for others out there. I noticed the other library doesn’t call SetHardAccess(FALSE).

If you run into any problems with bytes reading or writing incorrectly sometimes, you might want to add a call to that after the code that initializes TVicPort. You can call it in a similar way to how the other TVicPort functions get called in that library. Ever since I added that to my DLL, I have never gotten a bad read from a chip. Edit: I just did some research, and it looks like both of these DLLs are doing naughty things that Microsoft says to not do. The says: The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order.

This can result in a DLL being used before the system has executed its initialization code. This could definitely be causing problems. I may want to change my DLL’s code to delay initializing TVicPort until the first request to read/write the port, or something like that.I hope it doesn’t add too much overhead. Hi Paco, Yes–that was my experience. I needed SetHardAccess(FALSE) because I sometimes ended up with a few bytes wrong when I would read from a chip. Maybe it will work fine for you, though — you will only be able to tell by trying it out. If you look at the edit I made to my comment above, I have determined that both of the libraries are doing things they shouldn’t do when they load.

This could be creating weird problems. It’s possible that this is the reason that my library isn’t working for you.

I’m going to patch my library to behave according to Microsoft’s requirements, and I’ll post a link to a test version for you to try. If that version still doesn’t work, then I’ll patch the iodllwrapper that worked for you to include SetHardAccess(FALSE). I’ll try to get that done today soon, so keep checking here 🙂 •. Hi Doug Here I am again with good news. I’ve tested the program with everything I had on hand, and when all tests have been successful: 27256 ->ok AT49F002T->ok reading and writing. 62256 ->tests ok. 24C02->ok reading and writing.

PIC16F84A->ok reading and writing. For now, I have no devices to test, but I think the prospects are good. If you give me your approval, I will link to your article on my website, is a small website that I recently started: (sorry is in Spanish). By the way, you are interested ARM Cortex M3 micros, I’m starting with them and find them very interesting. Hi Paco, Great! Thanks for doing all that testing. I think it’s safe to say the bug in my DLL is gone and it’s working for you.

I’ll update the download link in the article to point to the new one now. Cool website, I would be honored if you linked to my article on it. Thanks 🙂 Yes the Cortex-M3 is great! It just feels like it makes some of the low level stuff easy (like interrupt handlers), the same stuff that was a little bit more difficult on other microcontrollers. Anyway thanks again for helping find the bug!

I’ve been following the messages here with interest. I recently received a Willem Programmer from a Chinese company via Ebay. My programmer sure looks like the Standard PCB3B Willem Programmer shown here: Installation & Configuration I’ve downloaded and installed the Willem Programmer software, the TViPC software and changed the io.ini and io.dll files per the above info. But when I select Test Hardware, I still get “Hardware Error: Check Power & connection.” My parallel port is from a Rosewill RC-302E PCIe card, which provides an ECP Parallel Port. (I got the PCIe card from NewEgg.com.) The LEDs all light up on the Programmer. But I get the Hardware Error indication. Any ideas on what I should do?

Hi Steve, The parallel port card you got seems like it should work fine. When I plug in my programmer to my parallel port, all the lights turn on also.

As soon as I open the software, the lights go off — that’s another way to tell if the communication is working. If your board is a PCB3 board, it’s possible that you need matching software — I noticed the directions say you have to click the “Willem” in the toolbar to select PCB3 mode. Just to make sure — have you done that so that the window says you’re using a PCB3 board? The version I have doesn’t seem to let me change to anything other than PCB5, but hopefully you have one that matches.

Do you get any errors when you open the app at all? If not, the remapped io.dll is probably working. Also, just to make sure–what is the I/O address you put into io.ini, and what is the range that the Device Manager reports? Mine shows two ranges: 3000-3007 and 3028-302B. That 8-byte-long one from 3000-3007 is the important one, so my file contains “0x3000”. Have you tested the board on an XP or older computer with a built-in parallel port? It might be easier to try getting it working there first.

Or even running XP or Windows 98 in a VMware Player virtual machine with the parallel port forwarded to it would be a way to test it too •. Thanks, Doug. I’ll bet the first thing you mentioned is the problem. My software is PCB45(0.98D5). I don’t have a “Willem” in the toolbar. I see now from Installation & Configuration that for the PCB3B hardware, I should use the 0.97ja software. That software does have a “Willem” on the toolbar.

In that location on the toolbar, my software has only “PCB45.” I think I’ll try different software this evening. (I’m on lunch break now.) I’ll let you know what happens.

I’ll also check the I/O Address Range. I haven’t tested the Programmer with an older computer. I don’t have any computer with a built-in parallel port. Hi Steve, Sounds like a good plan!

My software also has that same thing except it says “PCB50”. You might try clicking on the “PCB45” to see if it changes the version number on your current software. I’m not sure though–clicking the “PCB50” on mine does nothing. Some of the old versions of the software won’t run for me on Windows 7 64-bit, so hopefully 0.97ja will run correctly.

Also some of the older versions use a different I/O DLL — I think it’s DLPORTIO.DLL or something like that. I don’t think it’s compatible with io.dll. Anyway I’ll wait to hear back from you and then we’ll see where to go from there. I uninstalled the software that I had and installed the 0.97ja software. I still got the Hardware Error. So I then went down your list. I looked for I/O Range in Device Manager for the PCIe Parallel Port, but could only find Address = 00000000.

I tried many variations for that in the io.ini file, but nothing worked. Looking some more, I discovered “Resource Type” which I initially thought was something else. Under the Resource Type tab, I found “I/O Range: E010 -E017” and “I/O Range: E000 – E003.” With 0xE010 in the io.ini file, the programmer worked! I’ve now programmed my first 28F512, and the programmed part checks perfectly!

Thanks for your help. – Steve, in Peachtree City, GA •. Hi, I am working on a problem and while browsing i came to your blog, i think you can help me to solve this problem.

Please understand my need and guide me properly. I have a hardware device(very old fashion) which gives direct print to printer through parallel port. I wants to capture data and get it to the pc through parallel port, i tried so many ways to read data from parallel port but i am not getting any single string on my parallel port. Please do tell me if you have any sample application to get data from hardware to computer. Thanks in Advance. Regards Rohit Gupta •. Hi Rohit, It should be possible using TVicPort.

You just have to link against TVicPort and then use its provided functions to read/write to the I/O address of your parallel port. See my DLL’s source code as an example for how to initialize TVicPort (although keep in mind I do my initialization in a weird place in the code because I had no choice). There are a ton of resources at, much more than I could provide. I don’t have any sample programs, but TVicPort comes with many examples that will probably be helpful. Michael, To find your parallel port’s I/O address, open up the Start menu. Right click on “Computer” in the Start menu and choose Properties (this is just a quick way to get to the System control panel). Click on Device Manager.

One of the Device Manager categories should be called “Ports (COM & LPT).” Expand that category and find your parallel port. Double-click the parallel port.

Click on the tab called “Resources”. On my computer, two I/O ranges appear in the list. Find the one that is 8 bytes long (mine is 3000-3007 — this is 8 bytes long because there are 8 addresses in that range [3000, 3001, 3002, 3003, 3004, 3005, 3006, and 3007]). Take the first number of that I/O range (3000 in my case) and put “0x” before it. So mine is “0x3000”. That is what you should put into the io.ini file.

For example, if your I/O range is 2300-2307, you would write 0x2300 into io.ini. Just for a little more detail, here is one more example — the I/O ranges are written in hex, so it’s possible you might see a range like this: 3008-300F. This is also an 8-byte range: [3008, 3009, 300A, 300B, 300C, 300D, 300E, and 300F].

I hope that helps — let me know if you run into any other snags and I will try my best to help. Hi again, You’re welcome — I always hope to help solve problems like this 🙂 It sounds like you’ve tested everything just as I was hoping, so TVicPort is working (since the test program works and you aren’t getting any errors when you open the willem software).

Have you verified that you have entered the correct I/O address? It looks like you have entered everything correctly based on what you said in your first comment (0x9010), but I just want to make sure. What I/O ranges do you see in the device manager for your parallel port card?

Is 0x9010 the 8-byte range? (Is there a range 9010-9017 listed in the device manager? What other I/O ranges are also listed?) Also, are you powering the board? Other than the parallel port cable, you also need to power the Willem board using either a USB cable or the DC-in jack. Just making sure that you have also done this Other than those suggestions, the only other thing I can really think of is to test the programmer on an older computer with a built-in port to ensure that it is functionalanyway, let me know and we can try to go from there. Doug, I have verified, I have enter the correct I/O address 0x9010 in io.ini. In the device manager properties, the I/O address is 9010-9017 and on the second line 9000-9003.

There is no other range of address for LPT1, LPT2 or LPT3. The willem card is powered with USB. I will try the willem card on a old XP with built in parallel port, when I found it.

I will test the continuity of the cables I use. As long as I connect the willem the orang LED is light on. There is no other led light on. Only the red VPP one which blink two time 0.1 second when plugging the Express card. There no change when running the willem software •. Hi Migwell2, Thanks for the info.

Hmmmyou definitely have io.ini configured correctly for your computer’s I/O addresses. Only other thing I can think of is: you did choose LPT1 in the Willem software, right? (No matter what number your parallel port is given in Device Manager, you must choose LPT1 in the Willem software) Other than that, the “XP computer with a built in parallel port” test is definitely the next best thing you can do.

I haven’t heard from anyone else who has tried getting the remapped io.dll working with an ExpressCard parallel port adapter, but it should definitely work — it’s just PCI Express in a different form factor. ExpressCard carries both PCI Express and USB signals, but the Shentek website clearly states that your card is using the PCI Express interface (plus, the fact that your parallel port *has* I/O addresses means it has to be using the PCI Express signals). It’s no different from putting a PCI Express card with that same chipset into a desktop PC. Anyway, let me know how it goes with the XP test. If the XP test succeeds, then I’m going to be very confused •.

Hi Migwell2, Rats 🙁 So something about that ExpressCard isn’t working with your Willem programmer. At this point I’m very confused. If you have access to an oscilloscope, it would be interesting to see if the data pins on the ExpressCard parallel port toggle when you try to tell the Willem software to burn a chip. That way, we could verify that the DLL is correctly controlling the parallel port. I have a MacBook Pro with an ExpressCard/34 slotI just bought one of those cards from Shentek’s eBay store and I will see if I can get it working with my Willem programmer, first of all in stock 32-bit XP, and then possibly Vista afterward. I think it will be useful to the community to know what adapter cards work with the Willem programmers. I’m also thinking about eventually making a USB to parallel adapter that would be compatible with the Willem programmer.

It doesn’t seem too difficult to do at first thought — a custom io.dll could communicate over USB to a microcontroller to bit-bang the pins as needed. Not sure if performance would suffer though •. My understanding from reading the schematic is that one of the LEDs should always be on (indicates the programmer is powered) and the other two indicate that VCC and VPP are being supplied to the chip to program. VCC and VPP are controlled by two of the parallel port pins. So their state depends on what the parallel port pins are outputting–as soon as the Willem software has control of them, it tries to turn them off. The oscilloscope would be useful so we can see if some of the data pins are doing anything at all under control of the Willem software. I think the reply from Shentek is just saying that their parallel port card can’t use the standard LPT1-3 I/O addresses and IRQs.

Not a problem though–the remapped DLL takes care of the address problem (and the Willem software does not use any IRQs) •. Hi Migwell2, I have received my Shentek ExpressCard parallel port card. The card isn’t working with my Willem programmer either. I’m running Windows XP 32-bit, but that shouldn’t matter — the DLL is 32-bit and links against TVicPort’s 32-bit DLL. I’ve tried both my remapped DLL and Ben Ryves’ original remapped DLL.

Ben’s DLL doesn’t print any errors, but it doesn’t work. My DLL prints out a TVicPort error. My red VPP light doesn’t do anything when I plug in the ExpressCard, but I see the same behavior that you see with the lights. I’m tempted at this point to grab a PCI Express to ExpressCard adapter, stick it into my desktop machine, and try *that*. First, I’m going to try to figure out if communication with the card is working at all by writing some test patterns to the pins on the parallel port.

I’ll update again if I discover anything. I just don’t understand why this card isn’t working — it meets all of the requirements necessary for a Willem programmer •. Ok, so I made a quick test app to control the parallel port pins and see if I can find anything weird. It turns out that the eight parallel data pins are definitely working correctly. At first I was a little concerned because the pins are only at 3.3V instead of 5V, but my working card is also only at 3.3V, so that’s not a problem.

However, there are other output and input pins that the Willem programmer uses as well. What I’ve seen so far is that the other status/control pins are behaving strangely. (My desktop PC’s parallel port card’s pins *are* behaving as I expect, and it works fine). I’ve experimented endlessly with putting the card into the correct SPP mode that the Willem programmer software expects, but nothing seems to be working as it should according to the OXPCIe840 datasheet (that’s the chip that the adapter uses). Before I make any conclusions, I’ve ordered two other ExpressCard parallel port adapters from other manufacturers to test out. I may be nuts, but it will be useful to know for future recommendations.

Stay tuned for more information next week •. I’ve pretty much come to the conclusion that the Shentek adapter just doesn’t work with the Willem programmer. I’ll know for sure once my PCI express to ExpressCard adapter arrives and I can test it in my desktop machine running Windows 7. Arrived today, and it works fine with the Willem hardware on my MacBook Pro. My DLL doesn’t work well with it in Windows XP, but Ben’s remapped DLL works fine. I have been fighting a bit with the DisableWarmPoll registry setting, but I think I have it working right now. Again, once my adapter arrives, I’ll try all of the various ExpressCards in my desktop PC.

That should give us some good hard info on what cards work in Windows 7. Latest update: (MCS9900 chipset) works fine in Windows 7 64-bit with my DLL and also in Windows XP with my laptop. However, in both OSes, it appears that every 5 seconds it tries to turn on VPP, so the red light keeps coming on. This goes on for a while until it gives up and quits doing it. This is despite the fact that I have the DisableWarmPoll registry item added on both machines. Not sure what causes this, but other than that weird quirk, it works fine.

The Shentek adapter (link removed, product no longer available — 33006, OXPCIe840 chipset) does not work with the Willem software (and my DLL or Ben’s DLL) in Windows XP or Windows 7. (OXPCIe952 chipset) also doesn’t work with the Willem software (and my DLL or Ben’s DLL) in Windows XP or Windows 7. The next step, I guess, is to figure out why the Oxford chipsets do not work with the Willem software. The Willem software is not fancy — it writes to the parallel port as a standard parallel port (SPP). It writes to the data register and control register, and reads from the status register.

This is all very basic parallel port I/O that any parallel port should support. Is Windows doing something weird to screw up raw access to the device? Do the Oxford chipsets have strange quirks in SPP mode?

I just don’t know. I may try to contact Oxford (now PLX Technology) about this, but I don’t know if that’ll get me anywhere. I’m just really puzzled now.

Anyway, my recommendation as for now is: if you’re going to try to get this working with your Willem programmer, get something that has a Moschip (now ASIX) MCS9900 or MCS9901 chip! I have a PCIe card with an MCS9901 chipset, and this ExpressCard with an MCS9900, and they are both working •. Hi Migwell2, Not a problem 🙂 It was worth it for the research.

At this point, I just don’t know if it will ever work with the Oxford chipset. I tried to sign up for PLX Technology’s support site, but because I’m a private individual and not a business, apparently they aren’t interested in talking to me (my signup for their support site was rejected). I’m still planning on trying a few things — particularly, I’m interested in knowing if the parallel port behaves correctly in Linux as opposed to Windows. If you’re in a hurry to get your parallel port working, I’d recommend the Syba card. Like I said, the Syba card does do some weird behavior with VPP when you first start using it, but it stops acting weird after a while and seems to be OK. Also, ExpressCard I/O addresses change depending on whether you plug them in before or after booting the computer, so that might get annoying changing the I/O address around. Keep those in mind if you get the Syba card •.

Hi Migwell, Unfortunately I haven’t had time to play with the Oxford chipset to determine why it isn’t working correctly. I still have the ExpressCard adapters here and I want to hopefully figure it out sometime, but right now I don’t have any new info for you–sorry 🙁 The MCS7715 appears to be a USB chipset, which won’t work. You have to use a PCI Express chipset.

The USB chipsets don’t give you a full parallel port (and even if one of them did give a real parallel port, it would be extremely slow compared to a PCI Express card) Doug •. I’ve finally had some time to look into the incompatibility between the Willem programmer and the Oxford/PLX chipsets.

There are two problems I’m seeing. First of all, every card I’ve tried with an Oxford chipset does not have pull-up resistors on its bidirectional pins (strobe, auto/linefeed, initialize, and select printer). It sounds like it’s pretty normal for parallel ports to include those pull-up resistors, so the Willem programmer doesn’t have any.

The lack of pullups causes an issue when you try to use these pins as outputs. If you drive them low, it will correctly drive a low value onto the pin. But if you try to drive a high value, it leaves it floating instead (open drain/open collector). This would be remedied with a pull-up resistor to put the high value onto the pin when it’s floating.

It might be possible to add extra pull-ups to the Willem board (or maybe on a cable in between) to fix that behavior. I’m planning on trying that soon to see if it helps at all. The second problem is that I can’t get any of the input pins to work correctly (ack, busy, paper out, select, and error).

They don’t appear to respond to me putting voltages onto the pins. With a Moschip/ASIX chipset, those pins correctly respond as I touch them to ground or +3.3V (or +5V). I would also assume most motherboard parallel ports would respond correctly the same way. With the Oxford chipset I’m not seeing a response at all, at least with my little tester program.

I can’t figure out why those pins aren’t working. I don’t think it’s related to the first problem at all. So in simpler terms, only the eight data pins are behaving correctly for me.

I need to figure out why the rest of the pins won’t behave. Hmmmm, I have no idea about that particular device you’re using. As long as the I/O range is 8 bytes long and it responds like a typical parallel port would in those 8 bytes, it should work.

No idea on the other error — that’s meaning it attempted to write 0x4C and it read back 0xFF — as in the programming operation didn’t work. Have you verified that you can read other known good chips?

I guess it’s possible the I/O range isn’t correct and it’s just happening to respond correctly to make the hardware test pass in the willem software. It could also be a bad chip you’re trying to flash. Hi Otto, It seems to me that it shouldn’t be that hard to make an io.dll wrapper for Wine that forwards the io.dll calls onto Linux’s parallel port driver. I really do want to try that, especially with one of the Shentek cards that I can’t seem to get working in Windows. It would basically be a special version of io.dll that only works while inside of Wine.

Maybe if I could get it working inside of Linux it would give me some clues about why it doesn’t work in Windows. I haven’t been able to get the Shentek ExpressCard card to work in Windows XP or Windows 7, with my library or with someone else’s library (Ben’s I think). I just don’t know what the deal is with that chipset, but it doesn’t seem to behave correctly when you try to control its control lines for whatever reason. The company that makes the chipset was not interested in talking to me — my request for a developer support account with them was denied because I’m not a business 🙁 •. I added pull-up resistors to the four bidirectional pins on my Willem programmer, and now the programmer seems to behave just fine with both the Shentek and the StarTech card (using Ben Ryves’ DLL in Windows XP, anyway).

The input pins must have been a non-issue. I still can’t manually get data from them in a TVicPort-based program, but they seem to work fine when controlled by the programmer software and Ben’s DLL. It’s a pretty ugly hack that I had to do to the bottom of the Willem board, though. It would be way too easy to accidentally short something out. You have to find the four bidirectional pins on the parallel port and find a convenient place to solder to VCC. Then you solder resistors between each pin and VCC.

I’ll make a blog posting about it, but I don’t like the solution. I think a cleaner solution would be to make a parallel cable that includes the pull-ups and somehow gets +5V onto it too (maybe through another USB connector or something) •. One final update on this. My observation about the input pins acting up has revealed something really weird that I can’t explain. If I do a byte read of the data register or control register (base + 0x00 and base + 0x02, respectively), everything appears OK on all of the parallel port cards I’ve played with, with both TVicPort and Inpout32.

If I do a byte read of the status register (base + 0x01), it works OK on MosChip chipsets, but it returns junk on Oxford chipsets. This only appears to apply to TVicPort though, because other libraries such as Inpout32 seem to do a correct byte read from the Oxford chip. If I do a word read starting at base + 0x00 with TVicPort in that failure case, it correctly reads the status register. That makes me think it’s a problem caused by accessing odd addresses, but I don’t understand why the problem only applies to the Oxford chipsets with TVicPort. I’d understand if it applied to ALL chipsets with TVicPort, or if it applied to Oxford chipsets with ALL software drivers, but the TVicPort + Oxford chipset combination inducing the bug doesn’t make much sense to me.

Regardless of how much sense it makes, that’s how it is, at least from my testing. So in order to get these Oxford-based chipsets working with the Willem programmer, in addition to adding the pull-up resistors, it is probably wise to use Ben Ryves’ DLL instead of mine — because I think his is going to work correctly with the byte read of the status register and my TVicPort-based one won’t. I don’t understand why it’s acting the way it is, but all I can say is that’s what the results appear to be implying to me. Dear Doug, Before i begin i should note the wonderful job you are doing and that the knowledge you are sharing is unbelievable. I will share my problem with you. I have purchased my willem programmer but i am facing problems (after following your guide at every detail).

I just can’t seem to make it work (it gives: Hardware Error: Check power and connection). All the leds are ON as stated in the manual. I use a PCI parallel port (It appears as SUNIX in device manager) on windows 7 64bit. The weird part is that at the device manager it does not give me a resources tab so i can check the I/O range. Your parallel port tester I think gave me fine results since when i toggled the outputs the data register altered. Please advice, i am kindly waiting for your reply.

Hi there, Thanks! Here are a few things: Did you actually look at the data pins on the parallel port when testing with the tester utility?

The data register value changing in the display doesn’t really mean much, because it will still do that even if you don’t have a working parallel port. The important thing to do is look at the actual pins with a voltmeter to see if they do something as you click the checkboxes. Also check if the input pins correctly change state if you ground them. That’s very strange that the port doesn’t show a resources tab in the device manager. Did my tester utility find the port’s base address?

In the dropdown menu it should say something like LPT1 (0x3000). In that case, 0x3000 should be the base address you stick into io.ini. I would try that If you can’t get it to work, it might also be worth trying Ben Ryve’s remapped IO.DLL instead of mine–especially if the tester works, because it also uses inpout32. Hi Carl, Thanks! I actually just went back through my archives and I did take a picture of what I did to my Willem board temporarily to make it work: The black wire is soldered to VCC, and I hooked each of those resistors to the other end of the black wire and it magically started working. You can probably find a prettier/safer way to make the mod.

I would recommend using heat shrink or something to insulate it all. Just as a description to go along with it, there are four bidirectional pins on the parallel port: strobe, auto/linefeed, initialize, and select printer. Pins 1, 14, 16, and 17. If you solder a 10K resistor between each of these pins and VCC on the Willem programmer, that should make it work. Also, you have to use Ben Ryves’ DLL instead of mine because mine has trouble doing I/O with that particular chipset’s registers for some reason. I hope this helps!

Unfortunately, I failed Soldered the resistors “on the fly”, and test again I get always “check hardware and power connection” red messagge on status bar. Considerations: After this mod, I noticed that green and red leds (vdd & vpp) stay always on when I connect USB cable. Keygen Iveco Easy here. Yellow (vcc) led is powered too. But before this mod, only yellow led was on with usb cable.

The other two leds only lit up during read/write eproms process. I have PCB45. I don’t know if there are significant differences. Many thanks for any other help you can give me.

Hey, I know this article is a few years old. But recently, I dug out my old Willem board (bought about 12-13 years ago) to flash a 29F040 chip. Downloaded the latest software from that Sivava (or whatever) site, but kept getting those same weird errors & the inability to shut it down w/o using Taskman. And I still had an installed PCI parallel card that was also on a weird address (previously used w/ an old, now-dead HP Laserjet). Well, after following your instructions, I got my Willem workingon Windows 10!