#EVO-9650
7 messages in this thread
I'm hoping you're up for a challenge and have a few minutes to spare…
We have been running EVO-9650's using DQ-232 and/or VTR-9650.EXP successfully
for nearly 2 years now. However we have run into a problem now that Lantastic
is running. The problem seems to be memory or hardware address related and
neither Diaquest nor Lantastic support can nail it down.
During DISK-TO-VTR operations, rendering direct to tape, or even tape editting
via Diaquest batch commands, I very regularly lock up in the edit sequence. I
need not be accessing the network; just having REDIR and/or SERVER loaded
causes the hang-up.
When running properly, the disk-to-VTR sequence happens as follows: Message
appears "Recording frame nnn of NAME*.TGA", Frame memory switches from DNR to
Buffer, VTR Queues up tape to inpoint, VTR prerolls 3:00 seconds, VTR rolls
tape and records frame, Sequence repeats.
When Lantastic is active, the VTR appears to hang just after the edit sequence
begins. Just prior to queuing up to the inpoint, the VTR hangs. I can
generally free it by laying on the <esc> key. The problem occurs somewhat
randomly. Sometimes after 5 frames, other times near 50 frames. It seems more
frequent the longer I let it run. Do you have any clues?
Thanks.
David,
I'll look into this as well, as I just put my systems on Lantastic and I also
have an EVO. I typically render to disk and then output to tape.
-JE
Thanks John.
I really suspect some unique conflict here. We hooked up an associates
computer to the net, and recorded to tape from his system and framebuffer
without incident. Both of my available systems had the problem and they have
quite different hardware arrangements.
If you have QEMM, run MFT and generate a complete report (you may skip the
Windows stuff). If not, run MSD (found in either Windows or DOS 6.0/2
directory). Zip the report and upload it to me. I have Lantastic and haven't
seen any problem. It might be a combination of sorts.
>>It might be a combination of sorts.
I'm pretty sure it is, but I'm at a loss. Check your e-mail later today for
the system reports you asked for. Thanks.
I used a Diaquest 422 card two years ago and ran into problems with
Lantastic. I found that the Diaquest driver used software interrupt 14 and so
did the REDIR program from Lantastic. This is different from the hardware IRQ's
you usually have to play attention to. One of my clients is an AT&T
installation here in Denver, and they also have a problem with the Diaquest
Driver for their 422 card and LAN Manager, I haven't had time to work that one
out yet.
The solution for my Lantastic problem was to spend a couple of hours tweaking
the loading sequence of the network and other drivers until I found the right
combination.
Regards,
Jim Pope
You hit the nail in the head. I knew Diaquest used int 14 for communication
between the resident code and its utilities but I never thought Lantastic would
mess with that since he (David) wasn't redirecting any printer. I traced the
code and found that SERVER.EXE will trap int 14 and do all kinds of stuff with
it. This is what causes the "delay" once in a while.
I could not find any references in the Lantastic docs telling how to disable
that "feature". One way to fix this is making sure you (David) load the
Diaquest driver "After" the Lantastic stuff. That way, the Diaquest driver will
trap int 14 after SERVER thus "owning" it. As long as you don't try to redirect
a "serial" printer, SERVER will never notice it.