Dead or alive ? | Very old and very new TSR's | USB

[DOS386]

Hi

1. Is this forum / community / development active ? At http://bretjohnson.us/ I see a few DOS (?) programs, also source code is available (A86), most of them however are cca 10 years old

2. alt.ms-dog.prog... claims you would work on a DOS USB driver - is this true ?

3. FYI, I also recently brewed a few TSR's (more to come) using FASM

[Bret]

1. Yes, this is active. I actually have updates to most of the programs, as well as some new programs, but haven't completed the documentation for them so haven't released them. I've been too busy working for the last few years on the DOS USB drivers (see #2). If there's something specific you're looking for, ask me and I might be able to send you something.

2. That is true. I'm working on some DOS USB drivers. I am almost ready to release them in beta. I, along with Richard Bonner (http://www.chebucto.ns.ca/~ak621), am currently working on some basic documentation to go along with it. Once the initial version is released, I'm hoping to get some more programmers involved to create additional drivers and improve the existing ones. The architecture is completely different than anything that's been done with USB in DOS before: plug-and-play, modular, TSR (no need to edit CONFIG.SYS and reboot to install/uninstall the drivers), etc. Drivers currently exist for UHCI Hosts, Hubs, Mice, Keyboards, Joysticks, Printers, and Disk Drives. If you're interested in helping with the project, let me know and we'll figure out something for you to do. There are still LOTS of things that need to be added and upgraded (the Disk Drive driver needs the most work of the existing drivers, there are several associated support and test programs to be updated, drivers are needed for OHCI & EHCI Hosts, and drivers are needed for other types of devices like ethernet and serial/modem). There will also probably be a need in the near future for WHCI (Certified Wireless) and USB 3.0 host drivers. Since you already understand ASM and TSR's, it probably wouldn't take much to jump right in.

3. Interesting -- though your screen output doesn't look like it comes from a TSR.

[DOS386]

1. Yes, this is active. I actually have updates to most of the programs, as well as some new programs, but haven't completed the documentation for them so haven't released them. I've been too busy working for the last few years on the DOS USB drivers (see #2).

If you really bring out useful USB drivers than we can neglect away the "toy" rest anyway

If there's something specific you're looking for, ask me and I might be able to send you something.

Not really (except USB drivers )

2. That is true. I'm working on some DOS USB drivers. I am almost ready to release them in beta. I, along with Richard Bonner (http://www.chebucto.ns.ca/~ak621), am currently working on some basic documentation to go along with it. Once the initial version is released, I'm hoping to get some more programmers involved to create additional drivers and improve the existing ones. The architecture is completely different than anything that's been done with USB in DOS before:

Very good

> plug-and-play, modular, TSR (no need to edit CONFIG.SYS and reboot to install/uninstall the drivers)

Very good (still, I never use CONFIG.SYS, only DCONFIG.SYS and FDCONFIG.SYS ), but how about the volume letters ? They have been always implemented via "block device .SYS drivers" loaded at startup or via FreeDOS DEVLOAD. I have little idea how they work, and I decided to implement my new filesystem addon (long term thing, no release tomorrow) using a TSR rather than a "block" thing. BTW, the most important competitor DOSUSB (AKA JDOSUSB ) also uses a TSR for the main module dealing with UHCI and OHCI controllers, OTOH for the volume letters it uses a "block".

Drivers currently exist for UHCI Hosts, Hubs, Mice, Keyboards, Joysticks, Printers, and Disk Drives. If you're interested in helping with the project, let me know and we'll figure out something for you to do.

If there is anything to test feel free to send.

are needed for OHCI & EHCI Hosts, and drivers are needed for other types of devices like ethernet and serial/modem).

So UHCI only for now ... but how is this related to ethernet and serial/modem ?

There will also probably be a need in the near future for WHCI (Certified Wireless) and USB 3.0 host drivers. Since you already understand ASM and TSR's, it probably wouldn't take much to jump right in.

I would postpone USB 3.0 for at least 3.0 years Sadly I have virtually ZERO idea about PCI

3. Interesting -- though your screen output doesn't look like it comes from a TSR.

It's a FreeBASIC app and indeed not a TSR, I just tested attach upload

[Bret]

If you really bring out useful USB drivers than we can neglect away the "toy" rest anyway

I think all of my programs are pretty useful, at least in certain situations. But I do understand all the interest in USB -- that's why I start the project in the first place.

but how about the volume letters ? They have been always implemented via "block device .SYS drivers" loaded at startup or via FreeDOS DEVLOAD. I have little idea how they work, and I decided to implement my new filesystem addon (long term thing, no release tomorrow) using a TSR rather than a "block" thing. BTW, the most important competitor DOSUSB (AKA JDOSUSB ) also uses a TSR for the main module dealing with UHCI and OHCI controllers, OTOH for the volume letters it uses a "block".

Block devices are usually loaded via CONFIG.SYS, but they don't HAVE to be loaded that way. As you've notices, DEVLOAD (and similar programs) don't do it that way, and neither do network drivers. What you have to do is add your own entries into some special internal DOS tables like the List of Lists (LOL), Current Directory Structure (CDS), and Drive Parameter Block (DPB). I plan on releasing the source code to all of the programs, so you can see how I did it.

f there is anything to test feel free to send.

I will send things our for testing when the documentation is ready, hopefully very soon.

So UHCI only for now ... but how is this related to ethernet and serial/modem ?

They're not really related, except that I see an immediate need for them. There is still a lot of equipment around that is controlled and configured through a serial port (e.g., requires a null modem cable or dial-up connection between the computer and the device). It would be nice to be able to configure the device from DOS (which takes a matter of seconds to boot) as opposed to Windows or Linux (which take several minutes to boot). For something as simple as VT100 emulation, being required to boot to Windows is just plain stupid (IMHO). Serial ports are disappearing from new computers, especially laptops, but they are still needed, and you should be able to use them from DOS. In the industry I work (telecommunications), every technician has a USB-to-serial converter on their laptop and uses HyperTerm on a regular basis. As far as programs go, HyperTerm is worse than any DOS communications program I've ever used.

Programs like Arachne and Lynx are suitable in many situations, and it's stupid to have to wait several minutes for Windows to boot and load IE or FireFox when you could be on the internet in less than a minute with DOS. Many of the newer NIC's that come in computers these days don't have DOS NDIS or ODI drivers, and packet drivers (which is what the DOS browsers use) are virtually non-existent. The new computer I recently got for work has a RealTek NIC, and does have NDIS and ODI drivers, but I can't get it to work from DOS. I've tried the shims that convert NDIS and ODI to packet, but haven't been able to get them to work with the RealTek NIC. I don't know where the problem is, but it's very frustrating. Even if they did work, though, NDIS and ODI use WAY more memory than is actually needed to get the job done, and it would be better to just have a straight packet driver. I think a good way around this problem is to use USB Ethernet converters with packet drivers, so you don't need to try and mess with the internal NIC's that you can never find DOS drivers for.

[DOS386]

Block devices are usually loaded via CONFIG.SYS, but they don't HAVE to be loaded that way. As you've notices, DEVLOAD (and similar programs) don't do it that way, and neither do network drivers. What you have to do is add your own entries into some special internal DOS tables like the List of Lists (LOL), Current Directory Structure (CDS), and Drive Parameter Block (DPB). I plan on releasing the source code to all of the programs, so you can see how I did it.

COOL

They're not really related, except that I see an immediate need for them.

OK.

Programs like Arachne and Lynx are suitable in many situations, and it's stupid to have to wait several minutes for Windows to boot and load IE or FireFox when you could be on the internet in less than a minute with DOS.

My TSR deBUGGER: http://board.flatassembler.net/download.php?id=4201 (85 KiB)