#Vibrant error 1806!!!!!!
12 messages in this thread
Ok, has anyone received the nasty error message:
ERROR: 1806 3D Studio can not run under the current configuration –
Contact your distributor (yeah, right <g>)
followed by:
VDM_INIT 6102 returned error 1806
I've been using the new Vibrant drivers with the VIPER PCI and have
had no problems until today. Once this message is issued the install
seems to be corrupted – some file, some where is shot. Although I
could get 3DS to run in vanilla VGA, who really wants to <g>.
Reinstalling the Vibrant files had no effect and only a complete
re-install of the 3DS root directory got the program running with the
Vibrant VIPER drivers again.
What happened? What can be done to make sure it doesn't happen again? Is
there an easier way of correcting it if it does blow?
Thanks to any with insight on this one,
– Phil
Firstly, I assume that you using the 1.0.1 Inline drivers. Did this
happen entering 3D Studio or while running the configuration's test?
This shouldn't have corrupted anything that I am aware off, unless
you had some other problem earlier (crashing or something).
Error #1806 is P9000 not found in system.
If it happens again, please send me the 3DS.SET file and I'll see if I can see
anything that might be related to Vibrant.
Chuck Walbourn – Vibrant Graphics
Yup, latest version of the drivers (I've been using them happily since the
first day they were posted here). It occurred when in a 3DS shell, using
AniPro, and exiting back to 3DS – then BAM, system reboots and I'm locked out
of true-color graphics.
The 3DS.SET file was not the culprit – I have several versions, for
various tasks and all would bring the same error. I could enter
VIBCFG, but of course could not select the VIPER card – the only one
that would work was VGA. The card itself was still working fine in
Windows (800x600x24) and DOS AutoCAD.
I reinstalled the Vibrant files first, but had no luck – same
persistant error message. The only way I KNEW it was a Vibrant
error/conflict was your signature display screen. I coppied another
station's 3DS.EXE over to the system – no luck again. Only when I
dumped the entire 3DS directory in did the problem resolve itself –
vibrant didn't like some file, some where. ANy gueses?
I have no idea. Has it ever happened again?
Chuck Walbourn – Vibrant Graphics
Nope, no problems since.
But I have found myself typeing ^P & choosing the "+" button quite a bit more
often then usuall! <g>.
– Phil
Good idea anyway!
Hey Chuck, did you get my notes on the Windows video handling code? I did not
get any reply and I was wondering if my message got there.
I don't remember getting a message about Windows handling code. I'll be on the
lookout…
Chuck Walbourn – Vibrant Graphics
>> I don't remember getting a message about Windows handling code. I'll
>> be on the lookout…
Weird but that's what I thought when I didn't get any replies. At any rate,
here it goes again…
—————————————————————————–
This is very simple. Well, it is once you know things that aren't readily
documented. I will give you some directions without going into excruciating
details. Let you guys go over it and if you have any problems let me know. I
have a couple of systems permanently set to do this sort of debugging so it
fairly simple for me to recreate all kinds of scenarios. This is breakfast
stuff for me. I love it. Yeah, I know… I'm warped…
First of all, you issue a 2Fh 1600h to find out if Windows is up and about.
Then you call the VDD (Virtual Display Driver) and tell it you want to take
care of the video state from now on. Do this by issuing a 2Fh with 4000h. This
function has no parameters. It does, however, return the video modes the VDD
can safely save and restore. Not much of use for the type of display devices
you support but good to know. It may be that you don't need to do anything
depending the Windows Display Device Driver present at the moment.
The returned values are:
01h – No modes virtualized in background
02h – Only text modes virtualized in background
03h – Only text and single-plane graphics modes virtualized
04h – Only text, single-plane, and VGA multiplane modes virtualized
0FFh – All supported video modes virtualized (I never saw such driver)
When you call this function, the VDD disables I/O trapping of unreadable
registers. It will, therefore, call you when it needs to save and restore
register state (functions 4005h and 4006h below). You should hook yourself
into the int 2Fh chain. You will be looking for some types of call:
AX 4001h – Notify Background Switch. Windows will issue this call whenever
it's putting your VM in the background. You can do anything you want as long
as it doesn't take longer than 1000ms. After that Windows will switch you out.
Note that the 3D Studio VM will continue to run in the background as long as
you don't touch the video (memory or ports). If you do, the VDD will pull the
plug on you. With some work in your driver, you could set a global flag
indicating that you're in the background and no video access should be
performed. This would allow 3D Studio to continue working (rendering,
whatever).
4002h – Notify Foreground Switch. This is the opposite. The VDD will call this
when your are about to go to the foreground again. Use this to enable you
"in foreground" flag allowing the video functions to access the video.
4005h – Save Video Registers. If you did the 4000h call, the VDD will call
this whenever it need to save the video register state. It's up to you to save
it but do it within 1000ms, after which the VDD will go ahead and do it.
4006h – Restore Video Registers. The opposite of above. It's up to you to
restore the video registers.
A couple of other necessary calls.
4007h – Disable these services. Issue this call when leaving if you had
issued the 4000h.
4003h – Enter critical section. Use this when you're doing something that
can't be stopped by a "Save/Restore Video Register" call above. If the VDD
decides to call you, it will postpone its call for up to 1000ms (the magic
number) before doing it itself.
4004h – Leave critical section. Disables the above.
Note that none of these calls expect parameters or return values (unless
otherwise noted).
Let me know if you get in trouble…
P.S. This should have been put in the hardware section, but, so what… Now,
only if I could get an answer for my quartenians nightmares… <g>
Another crazy idea… Has anybody ever thought the idea of implementing a
driver that would switch the video requests to the Windows GDI? You get a
request from 3D Studio, if you are in DOS, go ahead and do what you do. If
under Windows (and provided a special interface driver got loaded along with
it) you would call this driver and transfer the request over to it. This is a
the fastest and simplest way to have 3D Studio as a Windows application
without changing a single line of code. Scary but why not…
Thanks. We have been looking for this kind of information, but it isn't
exactly easy to find!
This won't address all of the problems however. One of the biggest problems is
the 1sec requirement for the operations. Saving a screen from a TIGA could
take more than 4-5 seconds… Also, using 'critical section' marks around our
draw-code could really screwup windows interrupt handling, particularly for COM
ports. Another problem is maintaining backstores for restoring the screen
would take a lot of memory and time.
We will look into it.
Chuck Walbourn – Vibrant Graphics
Hi Chuck,
PMJI, but I was curious if you ever came up with anything WRT my reports on the
mysterious error #18 with the new drivers and my Viper VLB ? (remember ?)
FYI, as I theorized in my last report, I have been entering the MatEd first
thing after booting 3DS, and the problem has not re-occured since. This HAS to
be some kind of clue.
Regards,
BILL
Still looking into it. We have found a few small bugs in the P9000 code which
could cause problems on some systems, but still should not have resulted in an
Error #18. We still think it has to due with either the .INI file or possible
the FILES lines in your config.sys. Then again, it could have just been a
fluke!
Chuck Walbourn – Vibrant Graphics