Windows 7 Usb Serial Converter Driver

0 views

Skip to first unread message

Algernon Alcala

unread,

Aug 3, 2024, 4:03:24 PM8/3/24

to manroscsetthap

Someone with a lot more knowledge than I can tell me why this is a stupid idea. If I get this, a device driver converts the device's IO scheme to one the OS can understand. If that's true, shouldn't it be possible to write a program to convert the windows standard for IO into the osx one? Then any device driver for windows would work (with this conversion) under osx. If it somehow is possible, it'd be darned useful, although I'd have a hard time seeing it for performance critical things like graphics cards, perhaps more for network cards and the like. Just tossing it out there.

I would like to see the day someone would make something like that. But I would have to say it would be close to impossible to make one. If you ask me it is impossible because of the huge differences between the OSs. Its like someone being able to make an OS that runs windows and mac apps. Simply out of this world.

A similar project exists for Linux and FreeBSD, it is called NDISwrapper or NDISulator, for wireless and network cards... taking a .sys driver for win and converting to a loadable module in linux or freebsd without recoding anything... It should be nice to port it to OSX.

Ndiswrapper is evil. On Linux it gives the false sense that a device is supported. You don't get the full features of your network adapter when you use it. Don't hold your breath waiting for an OSX version.

Imagine forking a few of the open source virtualization projects which presently exist, eliminating all the functions that would not be of any use and adding or improving appropriate support for direct access to hardware, a custom tailored version of Windows which all things unrelated to the functionality of the hardware and host software are removed. Integrate this product into the Darwin/XNU kernel and voila, Windows Native Driver Support. However, its limitations are obvious, this would consume a greater amount of system resources, also it would increase the overhead so performance will be more or so unpleasant.

Out of curiosity, how does parallels handle device drivers? I realize the conversion is the opposite way. Also, it bears mentioning that in theory this isn't one program, but several, one for each class of device (network card, printer, sound card, etc). I figured such a thing was in principle possible, but had no illusions that it was likely to be attempted anytime soon (if ever).

Good question. Windows has supported drivers for many more devices than OSX and I don't think Apple could re-write all of them. The technology must share the PCI/USB/Firewire/etc bus hardware between the native OSX operating system and the Windows guest, in which case it's actually the native Windows drivers controlling the devices with a thin sharing layer for interrupts and I/O data paths in between. But I'm not sure.

It depends from card to card... the project itself is very cool! It worked for me in freebsd + at those times an unsupported broadcom wifi card. There's even a thread in insanely about porting it to osx... supporters wanted!

I have an 800XL with U1MB and a built in SIO2PC board. Up until this evening I didn't know what model it was. It has a USB-B port. (I've since found out it is an Atarimax SIO2PC board. More on that later).

I read it needed the FTDI Virtual com port drivers here which I downloaded and ran the installation executable for. It looked like they were confirmed as installed, but nothing ever showed up after in device manager (ie no USB serial converter or USB serial port), even after reboots and unpluggung/plugging in the USB cable, etc, etc).

So after more reading up I managed to download the drivers separately from the FTDI website (CDM v2.12.36.4 WHQL Certified) and following the guide here on page 9 of the guide I installed the USB serial converter. I then went into the settings for the USB serial converter under device manager and enabled the "load VCP" option.

The USB serial port then appeared when I plugged and unplugged the USB cable, again with an alert indicating missing drivers. I repeated the process to manually load the drivers from the WHQL certified ones mentioned earlier.

...but powering up the Atari does nothing. It either just goers to the Basic ready prompt or, if enabled SpartaDOS-X, but I get 138 errors. Also the RespeQt activity log never does anything when I power up the Atari.

So as I say I then found with some help that I had an AtariMax SIO2PC board, so downloaded the 64bit drivers from the AtariMax forum. I removed the USB serial port and USB serial converter and their drivers via device manager, and installed the signed Atarimax drivers. Sure enough the device is listed as Atarimax SIO2PC in device manager. But even after a reboot and uplugging/plugging in the USB, I now do not get the USB serial port nor the USB serial converter set up.

So with the Atarimax driver installed I now don't get ResepQt appearing to handshake with the board. (Obviously because there is no VCP loaded or USB serial port is absent and isn't pointing to the Com3, etc etc.)

EDIT: Incidentally I also then tried to install the USB serial port and converter drivers alongside the Atarimax driver, which of course rendered the latter unable to start as indicated in the device manager.

I see. I think because only until this eve I was aware this was an Atarimax device I had just run on the understanding all Sio2pc devices worked with RespeQt. I was thinking it was more of a case of Windows 10 being the main issue.

Looking at thread posts like this one, it appears once you purchase an APE licence it's for a lifetime. So it may well be that if Steven has my original licence still on record I can just upgrade from the DOS version to the windows version and pay the lesser amount if I recall).

It's a real pity I can't use RespeQt as it does appear to have more features. Not that APE doesn't look good. I was just hoping to avoid spending more cash than I already have. I guess beggars can't be choosers.

@flashjazzcat Hi. Sure. Unfortunately Ape seems my only option with my installed Atarimax sio2pc USB board as per 1st post and days attempting to get it to work installing FTDi drivers automatically and manually. With this Atarimax board nothing is plug and play with the latter until I just installed the Atarimax 64 bit driver and ran it with Ape trial.

I could build up an FTDi USB Sio2pc but I've already got this one hardwired into the machine and I need to start to dump lots of disks at present. Have 1000s of disks to look through, (not saying I'll need or dump em all). ?

your old registration is more than likely there... he had mine... just be prepared to give all the information you had at the time you originally registered it so he can find it (and verify it's really you).

Cool... fingers crossed. I've already provided the only details I have as it is decades ago. (I couldn't even begin to recall what the reg number/ref or even the email address would have been at the time mind you!)

If you really want to use RespeQt, or just give it a try and compare it to APE, you can build an FTDI-based SIO2USB cable relatively easily for less than $20, assuming you have a spare SIO connector or an old SIO cable you can sacrifice.

I still have and use my AtariMax SIO2PC-USB Dual Port interface and it works great. I love APE and ProSystem software, but RespeQt is pretty great too and works really well. It's a toss up as to which I use sometimes. I just like having options.

Ok, so after a week's distraction fixing my latest acquisition - another 600XL (finally nailed it yesterday - it had several issues) - I am back on my driver PAL 800XL (U1MB, with the built in Atarimax SIO2PC USB, etc) to get on with dumping disks to ATRs on my laptop.

In the last hour I've been happy loading up various ATRs, (Numen demo, the Brundles, etc), via Ape for Windows onto my 800XL, and using the swap ATR function for the multiple ATRs which is great, albeit a little slow, (I am rather spoilt loading games from the SIDE3 these days).

Grasping at straws here but I am naturally assuming this has nothing to do with an intentional restriction given it's the tiral version of the software? (Incredibly unlikely given it's giving an error message for the com port, but worth mentioning). After all you would want to trial the function. As I say...grasping at straws here.

So I am back to the issue with regards to no way in Windows 10 settings to tell the Atarimax it is using a specified (virtual) COM port. (Eg Com3, which the APE for Windows seems to have no problem picking up).

Here is my Device manager view, where as you can see it just installs the SIO2USB universal adapter, (fine for APE for Windows), but doesn't install the VCP (Ports Com) or the USB serial converter - both of which I assume is needed so you can get Prosystem to work and recognise a COM port?):

Not thinking it would work but trying nevertheless, I tried reinstalling the auto exec FDTI VCP driver package, (as I've mentioned earlier in the thread), and also to add both the USB serial converter and USB serial port using the WHQL certified FDTI drivers "just in case". Of course that doesn't work - wasn't expecting it to tbh. Actually crashed the laptop with a blue screen of death.

Basically installing the driver for the Atarimax is automatic and APE for Windows works if you just want to load ATRs on the A8. However I can't get Pro-system to work because of this Windows 10 COM port issue.

"I did find this on the AtariMax forum regarding avoiding running APE for Windows AND Prosystem at the same time,. (including minimised in the sys tray). To be sure I definitely tried running the prosystem with no trace of APE for Windows running, not even in the system tray, so it's not that."