Peter J. Hahn <[log in to unmask]> writes
>We've found Bio-Rad's COMOS software fairly robust as a DOS application.  We
>actually run it under Windows as a full screen application so as to be able to
>hotkey between Windows Notepad and COMOS for "jotting" down general notes, of
>course we also have full 32mb RAM to be able to do this without worrying about
>insufficient memory.  A word of advice, when purchasing a confocal system which
>has a PC as a controller/image processor, demand a fully loaded PC with a large
>hard Drive and the maximum memory supported by its architecture.  Relative to
>the cost of the entire system, it's a negligible cost which I'm sure the vendor
>will accomodate.
 
apart from crashes which seemed to have been cured by ensuring there's at
least 10M free on the hard-disk (and no, I can't explain/understand that),
our experience has also been that COMOS is quite robust.
 
However we are disappointed that there's only been one slight update in the
nearly two years we've had the system. 15 months ago at the BioRad users
group meeting in Sydney, some bigwigs from England told us that the
programming staff had been doubled and placed under a somewhat better
management. Well we've yet to see *any* evidence of that. Maybe the effort
went in the MRC1000, ie it can't run the same COMOS if much more of the
system is under software control. Anyway the head of BioRad in Australia
recently dropped in here while he happened to be on campus, and apart from
listening to our saga with KrAr lasers, is also going to chase up on the
software front. One of the improvements we were lead to expect in COMOS was
an integration of SOM capaabilities, but accessible from the COMOS GUI. An
a real Windows version would be nice because of the printer driver support,
etc.
 
However in terms of the PC system, I don't think you need anything
particularly flash. Not that you want to look at cutting corners to save
the odd hundred doillars either, but a ordinary 486 system is fine. There
is no need to get gobs of memory since COMOS is a DOS application and can't
access memory outside the base 640K (somebody will tell me if I'm wrong,
but I'm pretty sure it can't access expanded or extended memory). If you
want to run in under Windows and have notepad open, then I'd imagine 4 or
8M would be plenty. In terms of disk-space we deliberately chose a small
disk (120M) because a large disk in a multi-user environment will just
encourage people to leave files lying around. We installed a 128M MO disk
and supply users with disks for $60. The university will soon be
establishing a CDROM production facility, and some users will probably
archive files onto those. We also have MO drives on our OS/2 microVoxel and
Macintosh* systems which will read the DOS-formatted MO disks, though NFS
is also used to transfer files around.
 
Personally, I'd like to see COMOS written to work under Windows, and with a
large screen you wouldn't need another (video) monitor, though it would be
useful to support a second screen. Perhaps they could also get rid of the
expensive frame-store boards, and use something simpler to get the data
into the PC where the 80x86 chip could do image operations perfectly well.
From memory of seeing them installed, those frame-store boards use a fairly
old ATT DSP chip (integer-only I think, not that this is significant here),
which probably doesn't match Pentium performance (though DSP chips when
properly programmed can do a lot in a cycle). The Win32 API with a flat
memory-model would probably be the way to go if the image processing is
being done by the PC, which is when extra memory would probably become
worthwhile.
 
cheers,
Danny Thomas ([log in to unmask])
(though you can also send to [log in to unmask])
 
* actually we experience an occasional problem using AccessPC to mount DOS
MO's on our Macintosh. Happens with all versions of AccessPC we've tried
(2.01, 3.0 and 3.01). The MO's are low-level formatted with CorelSCSI
because it is the only way for OS/2 (up to 2.1 anyway) to conveniently
access removable SCSI volumes.