#GVP too smart for stds?
27 messages in this thread
Well, after some more experimentation I've found out why GVP '040
accelerators are slower than their 68030 counterparts: GVP's own
non-standard engineering practice – AGAIN. It amazes me that every
new priduct they come up with they seem to violate more and more
standards then have to provide kludgges to get around them so the
boards will work in an Amiga. If they don't like the standard CBM
adopts or creates, maybe they should just build their owm machines,
license ADos from CBM and hack away at it at will.
The slow 040 is due to the library (68040.library) supplied by GVP,
nominally to take care of trig and tanscendental functions (FLOPs not
handled byt the on-chip 6882 emulation of the 68040). What they
don't tell you is that apparently their apparently standard busting
approach requires their unique code instead of the ADos cpu command
to control things like burst/copyback mode, ROM image remapping and
supervisor stack relocation. The last item there is the interesting
one as it is necessary to move at the same time FastRom is turned on
or the machine will end up running slower than an '030 (in fact
slower than an '020). But, their default software installation does
not use the options of their GVPCPUCTRL routine to move the stack.
Even with the stack moved, the '040 is only as fast as an '030/882
combination with the undesireable side-effect that multi-taskin is
not possible when the 68040.library math calls are being made. In
the case of a rendering program this is a period of minutes to hours.
It really bothers me that they can get away with tellin you on the
phone and in their ads that the boards are "compatible" with all CBM
stnadard compliant software when in fact it is not. CPU is CBM
standard compliant software, but GVP in thier infinite wisdom had
created a product that only responds to its cache/nocache option. You
must use 68040.library called out of GVPCPUCtrl for FASTROM. And the
only way to turn of the burst mode is to remove their library and
reboot or move the jumper on the board. Yet nowhere do they makd a
statement about the facat that their stuff is so nonstandard so that
you can make an intgelligent buy decision.
Ther extra serial port also does not work with any terminal software
I have. AP, Platinum_Works, Platinum_Online… The SCSI that they
provide externally is useless unless any devices connected to it
contain thier own termination power (GVP hose not to implement pin 25
– they apparently know better than the standards makers and every
other peripheral designer). But again, the only way for you or I to
find this out is to buy their produt. On the phone they say
"completely compatible" and the ads say SCSI compatible.
Are PPS and RCS just as disreputable? Are there products asa
kludgey?
Man, it make me mad as H*%% to pay thousands for this stuff and then
findout I've been had by some plaid-pants wearing nit-wit who heads
off to a sleazy singles bar with my hard-earned money!
wmc – via Autopilot!
the RCS Fusion Forty IS C= Compatible and also CAN use the standard
68040 library… the only kludge I've seen so far is the use of the
MMU to load the Kickstart into RAM and a patch which causes Enforcer
to Constantly show HITS. I've been told by RCS that the Enforcer
problem is solved and that they are changing some other stuff too! As
I've only had probs with power packer and packed stuff I'm pleased to
have the board which is MUCH faster than any '030 I've seen. RCS also
seem to have a reasonably intelligent programmer as I've spoken to
him myself and he made good (intelligent programmer) impression on
me!
Thanks for the input. Do you use it with Lightwave? If so h ow long
does it take to render, say, Frame 1 from the NewTek supplied
CamCorder scene?
I've got a GVP G-Force 040, too. I think I lost $900 on it just in terms of
the street price in the six months it took before I figured out why it wasn't
working in my system. (It was somehow sensitive to the power supply – once I
swapped it, everything worked fine. Before that – constant SCSI garbage.)
Using the last beta of the new LightWave that will be in Toaster 4000, with
FastROM, MoveSSP and 'inst cache burst, data cache copyback', that first frame
of the "CamCorder" scene took 33 seconds to render on my system.
John,
Thanks for the data point. I'll try it with the '040 and old LW to see
what happens.
OK. With LW2.0_FP it takes 1m4s. With the integer LW 2.0 it takes 1m43s.
I shoulda looked for a scene with some mapping in it. Then the integer
version would have done better.
BTW, any thoughts on a Real3D converter?
wmc – via Autopilot!
Since Real 3D's first release, I've done the same thing I've done with every
other format we support. First, I answer the phone: because as soon as some
new 3D program is released in any part of the world, some customer calls to
play "Stump the 3D-Head" and pretend that we're the dumbest people in the world
because we haven't heard of Whiz-Bang 3D v1.0, recently released on a BBS in
Finland. 🙂
But seriously folks… we do start getting calls within minutes after a
release. Over the past two years, I've made personal contacts with Real 3D's
publishers, asking for a description of the file format, and to exchange a copy
of InterChange for a copy of their program, so we have something to work with.
Several times, with different people from the USA and Activa European offices,
they'd say, yes, yes, we'll send you something, but it's never arrived. Until
about two weeks ago, we received a developer's guide through Internet contacts
who were friends with people at Activa. Great, we finally have a spec, I
thought. Upon close perusal, they haven't yet documented their
surface/materials information. The raw geometry info is there. More FAXes
sent into Activa's black hole to no avail.
In short, we've tried, but they aren't very helpful. We've also tried to get
Aladdin's format, but it's never arrived. We do need some help from these
companies. Some (not these two) are downright unfriendly, others are too busy,
others… I dunno.
John,
Wow, Activa's as bad as those guys from VRLI! <g> But seriously, I haven't
forgotten about you, it's just a matter of being too busy and not wanting to
tackle such a tedious task….
John.
Actually, Clint just sent me more info about the color / elevation information
in the header. At least I think he sent it to me. I did get a bunch of C code
with #define values that made it look like it was massaging DEMs, but in 2600
lines of code, there was only a sprinkling of comments like "eat up rest" and
"will be set below". Job security? 🙂 Maybe. I'll "ask again" later to
decipher what I've got.
I've often wondered if I could ever convince a company that it would be
worthwhile for them to pay me to document their file format!
John,
I'll start pestering their support lines and mailbox. Maybe other
interested people will do the same. I wish I had known this prior to
seeing them at NAB – I would have pestered them there!
wmc – via Autopilot!
> The slow 040 is due to the library (68040.library) supplied by GVP,
'68040.library' is a C= supplied library. I think it actually came with
2.04 on my A3000. Their non-MMU-using GVPCpuCtrl, on the other hand, is of
course typical GVP.
> Even with the stack moved, the '040 is only as fast as an '030/882
> combination with the undesireable side-effect that multi-taskin is not
> possible when the 68040.library math calls are being made.
Neat trick, but 68040.library is C='s problem as they wrote it. If it
isn't re-entrant (as '.library''s are SUPPOSED to be), bug C=. Though it
is possible GVP distributed an old library by mistake.
> The SCSI that they provide externally is useless unless any devices
> connected to it contain thier own termination power (GVP hose not to
> implement pin 25 – they apparently know better than the standards
> makers and every other peripheral designer).
25 pin SCSI is my NO MEANS A STANDARD! It's just a little kludge dreamed
up by Apple to save $1 and 1 in**2 on connectors. Unfortunately, everyone
else picked up on it. Many Apple SCSI cables don't bother to connect pin
25 at all, causing people like me no end of annoyance.
> Ther extra serial port also does not work with any terminal software I
> have. AP, Platinum_Works, Platinum_Online…
Try VLT, "term", and Backtalk. If VLT doesn't work, you KNOW that the
serial port's dead — I've never SEEN an Amiga serial card VLT couldn't
communicate with.
// Brian — Cruising on AutoPilot…..
\X/
Brian,
I did find out about CBM as the lib source. But due to your tip, I might
puruse my 21.1 disks to see if there is a later version than that on the
GVP disks (37.4).
I also think I have a copy of VLT around somewhere to at least check the
port. However, since I am exclusively an AUtoPilot user, it doesn't do md
a lt of good. Note that AP works fine from the base amiga port, but from
GVP's it can't send an uncorrupted AT string to the modem, and receive a
modem response. It appears as if the modem doesn't respond at all.
wmc – via Autopilot!
Have you checked with GVP about the serial port driver revision? They may
have updated it since the combo card you have was packed.
Also, please don't discount that the serial port on the card may be
dying…
// Brian — Cruising on AutoPilot…..
\X/
Why should it die? Its brand new? I need to try it with some other
programs. AP doesn't like ANY other serial prot other than the amiga
native one if you have an accelerator. BackTalk, OTOH, aint so fussy –
maybe Ill use it to check the port.
GVP says the only thing changed is the rev of their serial prefs.
wmc – via Autopilot!
> Why should it die? Its brand new?
1) Card zapped in shipping/installation.
2) No manufacturer can afford to test ALL cards for proper operation.
3) Murphy's law.
// Brian — Cruising on AutoPilot…..
\X/
Brian,
Number 2 is not quite true, some manufacturers do test every board. At
DKB every board is checked for at least general functionality before
shipping. I find that it greatly reduces service calls due to defective
product.
Dean
DKB Software
You must eat up a lot of A2000's and 3000's. Those connectors only have so
much life in them.
After a while, when you get big enough, the effort needed to test EVERY
board out of the shop becomes just too time (and possibly computer)
consuming to be practical.
100% inspection does not guarantee "quality." The question is, how many of
your boards fail the check the first time around? And then how much work
is needed to fix them? If you look closely at this, you WON'T like what
you see. (If it's only 10% of manufacturing costs, you're LUCKY!)
// Brian — Cruising on AutoPilot…..
\X/
This is starting to happen to me….after running a couple hundred
bridgeboards through my A3000, not to mention all the normal playing I do,
my expansion card is starting to get flakey. :<
Dave
Elite MicroComputers – Flying high on AutoPilot
Maybe you should talk to Gary Nush about his card test rig. Maybe he'll be
able to whack something together for you….
// Brian — Cruising on AutoPilot…..
\X/
Brian,
I replace connectors when necessary, though it's not as often as you
might expect.
The effort to test each board is time consuming, and it is expensive.
However, in the long run it is much cheaper than repairing the equipment
after it has been shipped to the customer and returned. It also drasticly
reduces the number of repair phone calls we recieve. (a big money saver in
itself)
You are correct in that inspection does not guarantee quality – if
inspection and repair is all you do. A large part of the process is to
determine the reason for the failures and work back up the assembly and
design chain and correct the reason for the problems at the source. I am
quite aware of the costs involved in repair, which is why quality is
designed in rather than 'repaired in'! As an example, with the MegAChip,
only .5% – .8% fail final inspection as recieved from the assembly
process. The industry norm is much higher than this. Regardless of this I
still insist on 100% inspection prior to packaging so that problems don't
creep in, and so we can correct the few remaining glitches.
In general I feel that quality more than pays for itself when all
factors are considered, and those feelings are confirmed when I analyze
the numbers.
Dean
DKB Software
You sound like a Deming follower to me, "What in the PROCESS caused the
defect? Given that, let's fix IT, vice rolling heads."
My biggest worry was that the inspection process sounded like the ONLY QA
method. A frightening — and expensive — thought.
// Brian — Cruising on AutoPilot…..
\X/
"2) No manufacturer can afford to test ALL cards for proper operation."
Untrue. GVP, and I'm sure others, test each and every board off the production
line.
Our common test line consists of:
1-> An ATE electrical test
2-> An Amiga-based functional test
3-> A calibration station final test (if the product requires calibration)
—
If nothing else, this generated traffic… ;^)
Seriously, I don't doubt that every manufacturer uses some sort of
automation in testing all cards off the line. But after the number of
cards manufactured passes a certain level, your step "2-> An Amiga-based
functional test" may not be practical — you'd eat a computer a week. And
Amiga's ain't cheap. Now if there are ZIF sockets for Zorro bus cards,
maybe they wouldn't eat up computers, but I don't think there are….
// Brian — Cruising on AutoPilot…..
\X/
"…a certain level, your step "2-> An Amiga-based…. ….you'd eat a computer
a week,…"
We don't actually jam the cards into Amigas, but rather we have test fixtures
made up that hold a board on a flat surface, and clamp down on the edge
connector like a vise clamp. The fingers that clamp down on the edges are
wired to a real Amiga so that it thinks the card is inserted but the slots
don't get worn out within 2 weeks and the board edge connectors don't get
scarred up before it even leaves the factory…
The test fixtures are designed to allow for better testing without ruining the
test equipment, but they also try not to interfere with a "real world"
representation of product use. In other words, the test fixture tries to be as
close as possible to the actual Amiga (sometimes built right around it) so that
super long cables and other stuff like that don't change the operating
parameters of the product.
Now that's a nice rig. I'm not too sure if it would work for ZIII cards,
not surprising given that I'm not fluent in the ZIII spec. I have seen bus
extenders mess up timing adjustments, but I expect that you've battled
that when designing your card tester.
// Brian — Cruising on AutoPilot…..
\X/
We've spent quite a lot of time getting them "just right." The actual fixtures
themselves are designed by an outside test fixture company — that's all they
do all day long. A product's design engineer and our test engineer come up
with the specs, a sample is built and delivered, and if it meets the spec and
does what it's supposed to do, it goes to the production floor.
It's not truly a bus extender in the sense that it adds to the entire bus, it
merely takes one of the slots and moves it a bit farther away from the
motherboard (not that far though, maximum is 3 inches!).
What!! No pre-ship burn-in!!!??? With CMOS and Surface mount, if the
component is going to fail, it is usually in the first 100 hours. A VERY
large percentage of failures can be caught by a 100 hour burn-in. And it
is cheaper to junk boards caught at that stage (factored into price of
course) than to RMA and swap those that WILL fail in the first 100 hours.
wmc – via Autopilot!
Well, I wouldn't immediately junk the boards. Find out what went wrong
with it, record the problem for later analysis, and fix it if practical.
(with SMD's, not likely, but you could get lucky) That way you'd know if a
supplier sent you a bum run of chips.
I think this thread has brought the HW Hackers out of the woodwork. Now I
know who to bug…. ;^/
// Brian — Cruising on AutoPilot…..
\X/