Just a few additional comments on VTD and Merlin. Currently we have tested VTD and Merlin on two 486 level machines. One is an AMD 5x86 DX4-133 with 24MB RAM - the other is an AMD 486 DX4-100 with 32MB RAM. Both functioned well and performed all voice navigation functions fine.
Using dication was a bit sketchy as the processor was overrun with data to process... it would then subsequently generate an "Out of memory for voice processing" error as the memory allocated for voice dication was filled as the processor tried to catch up. Speaking slower and allowing the processor time to catch up seems to alleviate this problem - as we expect the optimized final release code to do also (on the very high end 486's such as the AMD 5x86 DX4-133).
Even with well below the recommended hardware, we were able to dictate with minimal pauses and very good recognition (until we overflowed the memory resources).
Problems we encountered: greater resources for Merlin with networking enabled. Will no longer boot on our 8MB machines with the same features loaded as Connect v3.0... still a few problems with Diamond cards, though driver support for them is improved. Almost negligible driver support for Trident cards (other than the ancient 8900 series) - which we find odd considering IBM uses the 94xx Trident chipsets and Warp on many of their Aptivas. No support or mention of Linksys at all - and they claim they have been trying for over 1 1/2 years to get their drivers included in Warp (and are fantastic with Warp support by phone).
Just a quick note after reading your article. I work for a major Canadian insurance firm and we have just installed the Merlin beta. If your current hardware is not up to snuff for all the fancy gee-gaws (VTD, VoiceNav) you will still be able to actually use Merlin. Our current installed machine is an IBM 486-DX2 66 with 24MB RAM and it is quite snappy even with the networking (Novell and LS) stuff loaded. So one alternative (if your 486 takes 72pin RAM) is to upgrade your memory while it's cheap and be ready to at least install this puppy. FWIW.
I read with interest about the cost of upgrading to run Merlin. With the prices of memory as they currently stand, cost is not an issue. I recently added 32 meg for $232 dollars. The speed and stability increases are well worth the money.
The second comment concerns the big BUT in the article. I've used PMagic to resize and generally adjust partitions and the text mode version is just fine. The DOS version even looks like a native OS/2 app! (unfortunately, the DOS/4GW version they use dies on my system under DOS 6.22) So, while the GUI does have limitations, calling it all but useless is kinda harsh...
If you were running a severly ram impared machine then the extra overhead of the PM based Alarm clock doesn't jive. Seems a more efficent solution would be to choose a command line based chron utility and In-joy.
[Earlier] I had Emailed Bjarne Jensen a long list of needed features for the "dream dialer" and I honestly didn't think I would ever get exactly what I was looking for. To my suprise he seemed happy to get the imput and wrote me back a nice letter asking me to check out his web site again and notice the list of features "under development". A couple of months later almost everything I had asked for was encorporated into In-Joy.
It will autodial when started, autolaunch my servers when connected, kill launched proggies when disconnected, redial a dropped connection, revert to a backup number if it has trouble, re-dial a busy signal, and much more. All of this functionality is in a lean textmode interface that uses a tiny amount of RAM compared to a PM app.
I liked your article and I'm confident that many users out there will use your good advice to automate their tcpip/apps. I am wondering what's your reason for not using In-Joy??
Copyright © 1996 - Falcon Networking