Contents | < Browse | Browse >
%% Reader Mail %%
Subject: Amiga report mail: GVP's Tech Support or the lack thereof
While on the subject of GVP, I would like the opportunity to tell a
little story. Recently an external SCSI HD failed. I attempted to
reformat the disk and block out the bad sectors by using GVP's
FastPrep. A message came screaming though my display, which I
missed, and now the HD isn't recognized by the workbench, FastPrep
You must understand that I am no computer genius but can work on
systems at a basic level. I am not a Human Computer Virus!
I decide this is a little beyond my capabilities and call GVP's tech
support. Their Automated Tech Support doesn't address my problem and
fax a very brief and generic question to them thinking I would get
voice response back. 24 hours later I receive their response fax asking
for my mailing address. I fax that. 24 hours later I receive another
response that primarily says "contact your dealer" and addresses an
anomaly inherent in SCSI devices. This was my fault as I expected a
voice response and didn't go into much detail. So I draft a detailed
letter and fax it. It's now 48 hours later and I haven't heard a word.
I really expected to hear from their tech support people via phone, live
in an interactive format. I may just be me, but I prefer dialogue
rather than listening to commands and pressing a number pad. Monkeys
were treated this way in the early days of the space program, weren't
they? And listening to the monotone voice without any interaction,
well I gave that up when I graduated school.
What is it I hope to accomplish by submitting this "view mail"? Maybe
someone at GVP reads Amiga Report. Maybe this will create a reaction
at their corporate level. Maybe they will realize that sometimes
"right sizing" a company, cutting corners dropping services might foster
poor customer relations. Poor customer relations will destroy a
company. After all its the customer that makes a company, not a Board
Thanks for letting me use Amiga Report to vent my frustration. All I
want is to get my HD back.
No HD in Texas:)
From: email@example.com (Maxwell Daymon)
Subject: Response to AR227
Date: Mon, 3 Oct 1994 02:19:53 -0600 (MDT)
In response to the concerns put forward by Hans Bergengren in AR227:
Although the Amiga 3000/4000 have primitive "time-share" logic to prevent
things such are serial overruns when used with Zorro III cards, the A2000
and A3000/4000 with Z2 cards does not.
To clairify, the Amiga 2000 serial port is especially intolerent of DMA
host adapters. There is a very specific moment that the serial port must
fetch the incoming data. The Zorro II bus can very quickly saturate with a
fast hard drive and controller causing the CPU to miss this window of
opportunity. There isn't much that can be done (other than a solution
similar to GVPPatch) to remedy this problem with the internal port.
The source I drew upon for my conclusions is based on information
posted by Dave Haynie on Wednesday, 24 Aug 1994 18:45:07 GMT
---Begin Included Text---
(The text without a '>' is written by Dave Haynie)
In <jdow.776935218@BIX.com>, jdow@BIX.com (jdow on BIX) writes:
>There is nothing that can really be done about this other than to
Of course, you compromise performance in either case; one hard disk
performance, the other interrupt performance. You'll find much the
same case on the FastLane Z3 card when running with a very fast drive
using the "Rev I Buster" workaround. With the workaround in place, you
have the drive on the controller for extended periods of time, which
gives you the fastest transfers on the A4000, but can sacrifice
>(The A3000 has logic that supposedly causes the bus to "time share"
>with other things demanding it.
Unfortunately that's only with Zorro III devices. The bus controller can
start and stop Zorro III DMA devices on a cycle-by-cycle basis, so it can
attempt to schedule them. It's still rather primitive on the A3000/A4000,
but it does help. On Zorro II, once a bus master has the bus, there's
nothing the controller can do to stop it, other than force an error (which
would crash the card or at least damage most Zorro II bus transfers)."
>With this facility I can STILL cause occaisional glitches on the
>internal serial port. This leads me to think there is little or no
>solution for the situation vis a vis the HardFrame. It is too
>efficient for the bus in a manner of speaking.)
It needs some kind of bus fairness mechanism, like the A4091 has (by
virtue of the 53C710). The only solution on Zorro II is to build a
controller which will back off at intervals. Unfortunately, that's
almost always an overall performance hit, since there's no way to tell
if anything actually wants to use the bus. This isn't strictly a Zorro
III problem, it's been a problem with all 680x0 CPUs (or buses based
on their bus protocol, like the Zorro II bus or A3000/A4000 local bus)
up until the '040, which can actually indicate when it wants the bus.
--- End included text ---
The main point is that although the 68040 speed will allow for much higher
transfer rates for the internal port (I reliably get 115,200 bps), it will
not work well when the on-board GVP SCSI controller is accessed and the
solution GVP provides did not work in my machine. Since the review was
published, I've been contacted by a number of other G-Force owners who are
experiencing the same problems with the GVP serial port and I'm still
looking for a solution.
The bottom line is that the serial port problems are not the fault of GVP.
I'm sure they did the best they could to make a fast, yet cooperative, DMA
(In practice, applying GVP Patch to the G-Force 040 causes a hard drive
that typically does 1.8MB/sec to 800KB/sec. That's about 40 times the
speed of a typical floppy read on the same system, and faster than many
hard drives hooked up to an unaccelerated machine.)
SCSI-BUS INTERFACE CONTROLLERS
GVP Series II controllers do NOT and have NEVER used the same bus interface
as an A3000/A2091. GVP uses the AMD AM33C93A-16JC, while the Amiga 3000
and A2091 use a Western Digital WD33C93A-00-04. The Western Digital
upgrade to a 00-08 fixes bugs in the revision -04 chip. The SCSI command
set is implemented through the device driver. GVP's driver supports the
SCSI-2 command set and Commodore's scsi.device does not.
The word "PROTO" printed on the Western Digital chip merely means the chip
is from the first production run (according to Western Digital).
A WD33C93A-00-04 is the same as WD33C93A-00-04 PROTO,
while a WD33C93A-00-08 is the same as a WD33C93A-00-08 PROTO.
The GVP chip does not need to be replaced as it does not share those
problems that A3000/A2091 users so often experience with CD-ROM drives.
The A3000T had a WD33C93A-00-08 when I purchased it, both A3000's I tested
the drive on were upgraded to -08 chips. Again, the chip does not
automatically make the driver support the SCSI-2 command set.
Dave Haynie pointed out what may be part of the problem. The IBM SCSI-2
drive I tested seems to use something called "FPT" (Forced Perfect
Termination). It was not compatible with any controller I tried - except
the GVP. It is not billed as a SCSI-1/SCSI-2 drive, so after much testing
I gave up on it with SCSI-1 controllers.
The only difference I could find with this drive other than the hardware is
that it reports a response data format of SCSI-2, while the SCSI-1/SCSI-2
drives I tested all reported a CCS (Common Command Set) response format.
The fact that the GVP controller handles it just fine when other fail is
still the point of the evaluation. The question of any review is "what
does it do for me?" In this case, for whatever reason, the G-Force works
with a wider range of drives.
I have also tried HDToolBox with my GVP controllers, but it is typically
unwise to use software from other controllers because they often set
options specific to the controller and companies do sometimes implement
ambiguous options differently.
Personally I like RDPrep, but I set up my drives with ExpertPrep (2.5)
because it tends to enjoy setting it up in a specific logical
configuration. Also, the GVP driver will not mount RESERVED partitions
regardless of the prep software used. That is my major complaint.
When purchasing a $1,200 product, I don't feel that the purchaser should
have to go find programs to replace the included ones. When a 33MHz 68040
based Macintosh Quadra costs the same as a G-Force 040/33 for an Amiga
2000, I expect benefits including solid, well-written, complete programs.
What's included with the G-Force looks like a good start, but it seems
almost as if GVP took the programmers off the job once they just got it
working. The software has a good foundation, it just doesn't seem
There can only be two types of 68EC030's. Those that have the MMU totally
and permanently disabled, and those that have been remarked to fulfill a
larger order than Motorola could provide at the time. If your chip has a
plastic package, the MMU is disabled and cannot be activated.
Before a 68030 goes through testing, it is decided whether or not it will
be a 68EC030 or a full 68030. If it is going to be a 68EC030, the MMUDIS
pin is permanently grounded, effectively disabling the MMU without removing
it from the mask. This insures a lower power consumption (CMOS logic
doesn't consume power when it's not changing states), and since there is
less heat generated, it can be put into a plastic package without the
possibility of melting.
So technically, the MMU is in the "mask" of ALL 68030's, but there is no
software that can magically "unground" the MMUDIS pin, causing the MMU to
function. Since the registers are still there, some software will
erroneously report that an MMU is present and try to use it.
The transparent translation registers _still exist_, though they are called
access control registers, which greatly reduce the need for testing.
The 68LC040 has the FPU physically removed from the mask resulting in a
smaller die and less time needed for testing. The 68EC040 is an even lower
cost version that disables both MMU's and the FPU _from the mask_.
Thanks to Skipper Smith of Motorola Technical Training for this information.
[For more information, see: Amazing Computing, Volume 8 Number 8, page 91]
The main points are:
1) Motorola does not ship "failed" 68030's as 68EC030's.
2) The terminology with regard to an MMU not being used and an MMU not
active or present in the chip is confusing, causing a lot of unnecessary
phone calls to GVP (and others) and probably led to fax-only style
I find it hard to believe that the MMU will work with the MMUDIS pin
grounded. Perhaps you have software that just deals with the registers
hence thinks and acts as if an MMU is present.
From: firstname.lastname@example.org (Walter Bock)
Subject: Reader MailTo: email@example.com
Date: Sat, 8 Oct 1994 05:23:48 +0100 (MET)
Concerning: AR #228, Reader Mail - wishes for new Amigas.
My thoughts on the new Amigas CPU:
First of all, I don't like the idea of a RISC processor in the new Amigas. I
have to work with those PowerPC Macintosh (too bad to work with anything other
than Amiga, but with 040 Macs you didn't have to go nuts) as a programmer and I
do not like the mass of incompatibilities produced by the new processor
Most important, with Apple being unable to port their operating system to
native RISC code, it is al slow as a 030 mac. And that does not seem to be due
to a bad emulation for 680x0 code - the emulation is real good, much more
stable than the OS.
I would not want to spend lots of money for an Amiga that is much slower than
A4000/40. I certailnly would not buy such a system. And I don't expect Amiga
Int. to get all the OS running on RISC code in time, let alone all the
commodities ... one got accustomed to - not if they have to write a real good
68040 emulator for the new machine, too. And anything else, which would render
the new Amiga incompatible with previous ones, would be suicide.
I have another more personal point in favor of 060 processors: I like to
program in assembler. The motorola one is quite good. And did you ever try to
program RISC assembler ? It's almost as sick as intel one...
Of course I know that you have to go with the time - and CISC processors seem
to come to an end - but they did not reach it yet ! The 060 is a fine machine
and would be perfect for the near future. You can clearly see how many
customers Apple scared by it's too-fast switch to the PowerPC and how much OS
engineering could not be done because they set themselves too tight deadlines.
(e.g. they still didn't implement preemtive multitasking :(
RISC may be the choice of the future, but don't be too quick. It's no good to
re-start the Amiga with a premature OS, it would take much longer to rewrite
all and everything for an integrated concept with a new processor than building
a good CISC computer so Amiga-owners can stop buying PCs and start to see a
perspective in the Amiga again.
My thoughts on AAA / 3D RISC.
are similar. I really don't believe Mr Pleasant if he says AAA OS
implementation would last 18 month whereas the implementation of a completely
new system could be done in 6. There has to be a miscalculation !
But if AAA is really as old stuff as stated (e.g. not much ahead of AGA), most
impotant if the Customchip data throughput is not MUCH higher they should
really can it. There would be no point making a computer which could not be
competitive to PCI in terms of BUS performance (or contain PCI :) and to the
cheap PC sound/gfx cards in terms of custom chip speed/ 16bit audio/ large
Chip ram ...
But after all, a new Amiga with only the name would be nonsense too ! There has
to be Amiga OS on it (even if it could take some stylish improvement -> X11)
and there have to run Amiga programs on it. OK, I'll give the old games a go,
but most of the applications should run on it !
And I would be willing to spend real money on a "professional" Amiga - not too
much a low end machine. If you see the prices of other non-IBM-compatible
which sell for over 6000 DM ($3.900) a price similar to this for a top notch
Amiga would be acceptable.
- That's quite a letter. I'll let it stand on its own. -Jason
From: firstname.lastname@example.org (AGENT GORDON COLE)
Date: Fri, 30 Sep 1994 23:11:04 -0400 (EDT)
I really enjoyed the CEI chat, and hope you guys can put some more of that
kind of stuff together! (I hereby give permission for you to use this as
the bi-weekly 'AR is cool' message :-)
- Why, thanks. Read the BIX transcript, then.