VP doesn't work with EGS
11 messages in this thread
Clint,
I have a problem with VP running when I have an EGS-workbench clone
operating. My guess is that while VP is "initializing" it is polling the
workbench screen to decide whether the computer it is running on is ECS or
AGA. When it sees that MY EGS workbench screen can have a maximum of 256
colors it makes the reasonable assumption that I have an AGA chipset
(which I don't have – I am using an A3000), and tries to set up it's
display screen to be a 256 color one. The effort to try to open a 256
color screen on an ECS system leads to fatal error with a requester asking
me if I would like to reboot the system! There must be simpler and less
error prone method to poll the machine for its display capabilities.
I realize that you're REALLY busy, but I do MISS my VP!
BTW, there are other prgorams that have problems with an EGS WB, I will
issue a list in th enear future for the interested bystanders out there
<g>!
// ** Commodore **
\X/ -The Bosnia of Computer Companies- -RSL-
Roy:
Are you running Version 3.0 or higher of AmigaDOS? If not, VistaPro
will not assume that you have AGA, as it assumes that AGA will be running
only with V39.0 and higher libraries. Currently that should only be a
problem with developers who have legitimate beta copies of 3.0 running on
non-AGA machines. VP will never attempt to open a 256 color screen anyway,
(even if you have AGA) unless you specify 256-c in the GrModes panel. The
main control screen in VP is 16 colors, even on AGA machines. I suspect
there is another incompatibility with this WB Clone. Is this EGS WB Clone
a commercial product? Shareware?
Clint <VRLI>
Clint,
Guess who is a registered developer with access to OS 3.0 running
on his A3000/25? <grin> The EGS workbench clone is a commercial piece
of software which is being packaged with GVP's new Spectrum EGS
board, and should be released in one form or another for other EGS
style graphic boards in the near future. I would expect alot of
A3000 owners to be using it to "upgrade" past the AGA capability of
the A4000!
One of these days, C= is very likely to release 3.x for non 1200 & 4000
owners, and I think that they MIGHT have similar problems! Good olde VP
crashes right during the initiation portion when my WB is in 800x600x3
mode (with the capacity to go up to 256 colors listed in the viewmode's
database). When I return my WB to native Amiga screen all is well. VP
must be getting confused by looking at my WB screen and finding V39
libraries on an ECS system. I'm sure that I read about a reasonably
simple method of polling a machine to detect whether it was AGA or ECS
without checking the WB screen for maximum bit depth?
Help! I miss my VP <g>!
// ** Commodore **
\X/ -<Comment left to the reader's imagination>- -RSL-
I now have reliable code to detect for AGA, which is not yet in
VistaPro 3.05. However, I run with V39 mode turned on in debugging on
my machine all of the time, and the only time I get into trouble is
when I actually attempt to do an AGA function. The normal startup
code knows nothing about V39 and should be able to open up just fine
on any machine running V39 as long as the user doesn't try to open an
AGA screen. VistaPro won't try to unless requested by the user. (In
fact the code that opens the control panel should still run under
version 1.1 of AmigaDOS.) The only V39 checks that exist are in the
AGA specific code. That's why I suspect that the problem lies with
GVP's EGS WorkBench and not V39. I have several beta testers who also
run V39 on their 3000's and don't have any difficulties. VP will
crash if you select HAM8 or 256-c on a non-AGA machine, but that
doesn't seem to be your problem.
The new AGA checking algorithm worked! VP now runs as nicely as
ever! My guess is that it isn't the checking for V39 alone
(otherwise others would have found this problem long ago), it's the
combination of an ECS system (an A3000 in my case) running V39, AND
also having a workbench screen that is capapable of displaying 256
colors. The previous versions of VP considered this (now rare, but
soon to be less rare) to be too much like an AGA system, and
proceeded to crash, attempting to open a nonexistant AGA screen on my
A3000! I'm glad to have the problem fixed. <Now I'll have to get
Innovatronics to "fix" CanDo – it has a similar problem.>
I also want to thank you here in public for your help with this
problem! I know of at least one person on the forum that has not
been thrilled with my negative attitude regarding C=, but it's guys
like you in this industry, and the forum, that keep me loyal to my
old A3000. I'd love to clone you and a couple of other guys here and
let them loose on West Chester (can you just see a few hundred Ben
William clones overrunning C='s executive boardroom, reducing it to
chop sooey<g>)!
I just want to reiterate that I (along with a lot of people)
appreciate the hard work and care that you take in producing products
for the Amiga, and your tireless help when an occassional problem
pops up!
<Mark – It's guys like this ^ that will bring the Amiga back to
full throttle, not a chorus of people whistling the praise of C= on
the forum!>
It could be SAS. VistaPro 3.05 won't run on 1.3 machines, while
the SAS version (no changes) runs quite nicely. Several other
crashing problems have disappeared with the SAS version. There isn't
any code being executed at the time of the crash that was V39
dependent, so that can't be the problem, you can't crash code that
you don't run. Again, VP NEVER opens an AGA screen unless the user
specifically selects an AGA mode. (I like to get my bugs straight, it
was another bug, not _that_ one! <grin>) I want my customers up an
running, using VP! I don't know what plans VRLI has for 3.1, if they
want to wait for 4.0 (probably still a year off) or to come out with
an interim speedup with a few enhancements "update" release. That
will be up to them to decide. I hope to get ahold of Brick's code
which supports a couple of additional video cards and get that
incorporated asap.
Well… whatever the reason, I'm glad to have VP working like the
olde pre-EGS days. SAS/c is a nice little compiler, eh (I like the
way it is smart enough to open libraries, and close them
automatically without the programmer writing the specific code when
functions requiring specific library calls are used). Keep up the
great work!
SAS 6.3 is definitely a big improvement over the last version of
Manx, but being a compiler writer, I cringe whenever I look at the
code it generates. I keep promising myself that if I ever win the
Lottery, that I will devote myself to writing a decent compiler/code
generator for the Amiga. <grin> But SAS doesn't do bad considering
that they actually have to make a profit selling them, and can't just
write them as an artistic excersize.
Clint,
I would assume that writing "tight" optimizing code for a compiler is a
"black art"! All things considered, I am happier with the integration of
SAS/C as opposed to the rather primitive condition that Manx is (and
unfortunately will always be) in. I hope that SAS/C 6.5 will be better
still! (I'm gonna have to learn C++ one of these days!)
// ** Commodore **
\X/ -<Comment left to the reader's imagination>- -RSL-
Roy:
SAS is at least working in the right direction. When I was writing
compilers, I never understood why people had such problems with
codegeneration and optimization. I always found the parsing to be the
biggest pain (which was fortunate, as my partner on my team was just the
opposite). We used a technique using two pseudo-languages, and optimizing
for particular features at each language "boundary". This allowed us to
keep track of what was in each pseudo register across rather long pieces
of code, so when it came time to generate the actual assembly, there was
very little of the "reload this register" phenomenon. Also, we could catch
the "last occurance" so that we didn't need to transfer a register to a
temp for a calculation if we knew that it wasn't going to be used any
more. This allowed for "register variables" across small segments of code
within a procedure, and then a new set of register variables later on in
the same procedure. (Without the user telling us.) I was sorry that DRI
dropped the Language division when it did, as the multiple front
end/codegen/multiple assembler project was basically finished, but never
saw the marketplace. A few years later we tried to see if we could license
the code for the Amiga, but no-one there could tell us what happened to
the source. And no-one had any interest in figuring it out. <sigh> The
compiler had front ends for "C", Pascal, Basic and Fortran, and final
assemblers for 8086/80286 and 68000. It would have been a nice addition to
the Amiga repitoire back in '85-86.
Clint <Chaocity><VRLI>
Clint,
I agree, it would've been nice to have even more compiler choices
for the Amiga platform. Unfortunately code compilers is one of MANY
categories that are experiencing a "thinning" lately. It's a good
thing SAS/c is still around!
As a guy that wrote for both CPU's do you share the "brain dead"
opinion I have heard in the past about the Intel 80×86 series
(atleast until the 486 series), especially when it came to memory
management?