Dealing with the ARS USB2ISA hardware emulator #1


USB2ISA is an adapter designed by ARS Technologies. Its main purpose is to allow users to mount and use their old ISA-8 or ISA-16 slot cards on modern computers through the fashionable and always effective USB 2.0 bus. In order to do so, the basic idea of the ARS technology is to implement some kind of “hardware redirector”, allowing the original ISA vendor software and drivers to work transparently.

Bearing this in mind, and according to their web page, a user could use his or her old ISA card either on Windows, GNU/Linux or Mac OSX operating systems.

The issue

So, we bought one. The main idea was to be capable of using an MCDLAP measurements acquisition card,  commonly used in labs. This is a very simple ISA-16 card, with only one I/O port to be addressed, say 0x320. Despite the fact the ARS documentation seemed too simple, and even knowing that we could use the original driver developed by Fast ComTech for Windows NT and derivative operating systems – like XP -, our MCDLAP card was not detected at all with its original Windows software.

So, we had to do some experiments using another kind of old ISA hardware to be completely sure that technology was working well, just before trying to deal with the MCDLAP problem by itself.

Thus, I chose an old NE 2000 network card adapter, wearing a DP93805A chip.


Okay, first of all I had to re-deal with KDMs. You know, it’s like dealing with LKMs, but not quite funny. Windows OSEs allow a developer to deal, create and debug drivers through the Windows DDK, Device Driver Kit. But surely I was in need of some kinda sort of tool to catch the Kernel debugging messages – on GNU/Linux systems it is quite easy: one can use ksyslog to do so -. What I needed came to be known as DebugView, a trivial tool belonging to the SysInternals huge utilities package.

Having a quick look at the fastmcd.sys KDM sources, one came to realize this driver would load perfectly well no matter whether the MCDLAP card was plugged or not. How was that so? Easy: this driver only interacts with the hardware as soon as a user program tries to. It means there’s no pre-initialization code-phase directly inside the device driver sources, as, say, on an NE 2000 card. According to this, I fathomed I could use these very driver sources in order to figure out how ARS technology was or was not working on my test-box system.

Altering the fastmcd.sys driver

I was totally determined to add some messages on this driver, in order to catch them using DebugView. I tried to compile it, but if failed because of an error line inside the SOURCES file. So, I changed the variable TARGETPATH in order to fix it. Then, it looked like:

 1 # The sources for the FAST ComTec MCD driver:
 3 TARGETNAME=fastmcd
 7 INCLUDES=..\;e:\ntddk\inc
 9 SOURCES=fastmcd.c fastmcd.rc

Finally, I added some trivial DbgPrint() calls which would be intercepted using DebugView this way:

DbgPrint("%s", "This is a test\n");

So, as soon as I loaded manually the fastmcd.sys altered driver inside the Windows XP Kernel, nothing came to happen. It was obvious, ’cause this driver did nothing when it loaded. But, when I ran the MCDLAP Server software, the DebugView window started to show me a lot of intercepted Kernel-space driver debug messages, as shown in the next figure:

Thus, I came to realize that the fastmcd.sys driver could be loaded BEFORE the ARS Enumerator window showing no impact on this behaviour. According to an email message coming directly from the ARS technicians, I was told to do the other way around. Clearly, they proved to be wrong.

Back to the NE 2000 Adapter

Windows XP keeps the ne2000.sys KDM binary file, although there’s no INF. According to the UML facility description which can be found inside the ARS user’s manual, I had to be able to install my NE 2000 ISA 16 card using my own INF file, associating this ISA device card to the USB2ISA ARSTech\arsusbXYZ port, merely adding a single line in this very INF file.

First, I was in need of such an INF original file. I got it thanks to an old Windows 2000 installation-CD. Then, I removed all NE 2000 vendors and ports which had nothing to do with my particular ISA card. So, in the end, it looked like is shown in the next code snippet. Finally, I tried to load this INF file using the ARS Enumator user program, as I was told according to the ARS user’s manual. It did not work at all.

; Novell/Anthem Network Interface Cards.
; Copyright 1993-1997, Microsoft Corporation

LayoutFile = layout.inf
signature  = “$Windows NT$”
Class      = Net
ClassGUID  = {4d36e972-e325-11ce-bfc1-08002be10318}
provider   = %Msft%

; The following ClassInstall32 section is run by syssetup during
; GUI mode and is independent of the devices listed in this inf file
; Rather than introduce a new inf file for the classinstall32, we placed
; the section in this existing inf.
;  BE CALLED BY THE SYSTEM.  if the file must be removed, the section needs
;  to be relocated and Setup notified of the change

AddReg = NetClass.NT.AddReg

HKR, , ,                0, %DisplayClassName%
HKR, , EnumPropPages32, 0, “NetCfgx.dll,NetPropPageProvider”
HKR, , Icon,            0, “-5”
HKR, , Installer32,     0, “NetCfgx.dll,NetClassInstaller”



; *NE2000
Characteristics = 0x04
BusType         = 1
AddReg          = ne2000.ndi.reg
LogConfig       = *ne2000.LogConfig
CopyFiles       = ne2000.CopyFiles

AddService = ne2000, 2, ne2000.Service, ne2000.AddEventLog

IRQConfig      = 5
IOConfig       = 20@300-3FF%FFE0(3FF::)
ConfigPriority = HARDRECONFIG

; NE2000 Common
HKR, Ndi,               Service,    0, “ne2000”
HKR, Ndi\Interfaces,    UpperRange, 0, “ndis5”
HKR, Ndi\Interfaces,    LowerRange, 0, “ethernet”


DisplayName     =   %ne2000.Service.DispName%
ServiceType     =   1 ;%SERVICE_KERNEL_DRIVER%
StartType       =   3 ;%SERVICE_DEMAND_START%
ErrorControl    =   1 ;%SERVICE_ERROR_NORMAL%
ServiceBinary   =   %12%\ne2000.sys
LoadOrderGroup  =   NDIS

AddReg = ne2000.AddEventLog.reg

HKR,    ,   EventMessageFile,   0x00020000, “%%SystemRoot%%\System32\netevent.dll”
HKR,    ,   TypesSupported,     0x00010001, 7

; Destination Directories
ne2000.CopyFiles  =   12
; Localizable Strings
Msft = “Microsoft”
DisplayClassName = “Netzwerkadapter”
Novell = “Novell/Anthem”
pnp80d6.DeviceDesc = “NE2000-kompatible ARS”
ne2000.Service.DispName = “Novell/Eagle NE2000-Adaptertreiber”

I altered the I/O and IRQ channels directly in the INF file, in order to be sure its resources and those which were well-detected by the ARS Enumerator utility were exactly the same:

IRQConfig      = 5
IOConfig       = 20@300-3FF%FFE0(3FF::)
ConfigPriority = HARDRECONFIG

This NE 2000 ISA adapter card used twenty I/O ports, starting from 0x300. In theory, the line in charge of associating this ISA device card with the ARS USB2ISA adapter was this one:


Unluckily, it was not working.

Listing all KDMs loaded

So, it seemed quite clear to me there was a lack of USB2ISA facilities on my test-box system. I needed to determine what kind of KDMs were loaded. It was pretty clear that,  to redirect all I/O Kernel-space routines coming from an to the NE 2000 driver ne2000.sys, there had to be another KDM loaded and redirecting them. That means a KDM. A KDM developed by ARS, obviously. It seemed that was so, because I developed a trivial C program calling the ARS API in order to read from 0x300 I/O port having the USB2ISA adapter plugged and trying to do the same with this card unplugged. Clearly, there were differences reading from this port. So, it seemed something was missing.

#include "stdafx.h"
#include "arstech1.h"
#define _IO_PORT 0x300
int _tmain(int argc, _TCHAR* argv[])
	// Try to read from port
	BYTE i8;
	WORD i16;
	DWORD i32;
	i8 = in8(_IO_PORT);
	i16 = in16(_IO_PORT);
	i32 = in32 (_IO_PORT);
	printf("Byte, word, dword: %x, %x, %x\n", i8, i16, i32);
	return 0;

Having a look inside the Windows Registry HK_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services, there was no service referencing such a KDM but ArsUniv. I looked for another KDMs inside System32\DRIVERS\ directory, and I found this one: arsenum.sys. I determined whether this driver was loaded or not using driverquery command. It was not. According to the sc.exe command, ArsUniv was running on my test-box system, as shown below:

Jackpot! That KDM must be the UML layer, no doubt. But there was no trace of arsnum.sys KDM loaded on my system. Dissasembling arsenum.sys, one came to realize there was clearly some imported API calls from HAL subsystem in charge of reading or writing from or to I/O ports, as shown in the next figure:

Thus, I came to a halt: Hey! That must be what I was in need of! Surely there’s only one way to accomplish such I/O calls redirection, as UML pretends. That is, if you need to do something like that, you have to do it in Ring 0, or Kernel-space. Pretty common, as when it comes to my MODEST project. So, bearing this in mind, I tried to load this KDM by hand, using the sc.exe command utility. Finally, I started the KDM and checked it out:

sc start arsenum

sc queryex arsenum

That came out:

I restarted my Windows XP test-box. As soon as it booted up again, I could see that marvellous “New Hardware Found” message box dialogue showing up all of a sudden in front of my very eyes! At that very instant my NE 2000 ISA-16 card was detected as ARSTech\arsusb100 device port. So, I chose that altered INF file I told you earlier, and my NE 2000 ISA card was loaded and usable through the USB2ISA adapter!

There’s a demonstrative video showing the “New Hardware Found” message right HERE.

Right after adding this device driver using that modified INF file, we can disconnect the NE 2000 ISA device as if it was a normal USB gadget attached to the USB 2.0 bus, as clearly shown in the next screen shot:

What’s next?

Conclusions seem pretty clear: it is a BUG or maybe such an omission related to the install software for the ARS utility and drivers package on Windows systems. In theory, UML was working but there had to be another KDM previously loaded (arsenum.sys) in order to attach our  ISA 16 card to the USB port. Now, I’m going to check that MCDLAP card out again. I assume it could work, although I need to buy more time to be completely sure about that. I’ll post my  analysis right here, as soon as I can. So, please, stay tuned.