[comp.sys.amiga.emulations] IBeM on a GVP A3001 and speeding the thing up.

rbabel@babylon.rmt.sub.org (Ralph Babel) (03/07/91)

In article <1991Mar8.003734.18281@uokmax.ecn.uoknor.edu>,
drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) writes:

> GVP has verified that indeed Mark Tomlinson has included
> odd word aligned references in his IBM emulator, IBeM.
> This is the reason that neither the GVP accelerator nor
> the Hurricane 2800 will run his software. Although this is
> strictly legal for the 68020/030 CPU, it is referenced as
> a no-no by Motorola AND Commodore and was thus built out
> of these two accelerators.

As I wrote about six months ago, this is not the complete
story. Yes, there are a few GVP accelerators in the field
that do not support non-word-aligned writes of longwords,
but fixing this is as simple as changing a PAL (U50). And
all current boards _do_ support this feature (in fact, I've
just tested it on mine).

Ralph

drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) (03/08/91)

GVP has verified that indeed Mark Tomlinson has included odd word aligned
references in his IBM emulator, IBeM.  This is the reason that neither the
GVP accelerator nor the Hurricane 2800 will run his software.  Although
this is strictly legal for the 68020/030 CPU, it is referenced as a no-no
by Motorola AND Commodore and was thus built out of these two accelerators.

Mark, I know you said that this wasn't your fault, but it might interest you
to know that (according to GVP) there are more GVP accelerators in Amigas
than Commodore A2620s AND A2630s combined.  I hope this and the following
is enough motivation for you to re-write your code without the boundary
violation.

While discussing this with GVP, it also came up that any long word reference
to 32 bit memory and any long word or word reference to fast memory would
require _2_ memory references and thus take double the amount of access time.
I don't know how many odd word references are in IBeM, but if there are many,
the speed improvement could be QUITE noticable (albeit the code size might
increase by a hair).

Please consider adjusting your code to take this into account and if you
have any questions or comments that I can relay to the rather knowledgable
GVP staff (probably much cheaper from this side of the pond), please don't
hesitate to let me know.

In the mean time, does the $30 registration fee include future updates for
serial, parallel, sound, 8087 emulation, and possible EGA support?

Thanks for your support.

Rick Tillery (drtiller@uokmax.ecn.uoknor.edu)

rbabel@babylon.rmt.sub.org (Ralph Babel) (03/08/91)

In article <1991Mar8.204144.10514@uokmax.ecn.uoknor.edu>,
drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) writes:

> We could all spend the $30 for the new PAL to run one
> _incorrectly_written_ program, but I think correcting the
> problem at the source rather than the end user would be a
                 ^^^^^^ :-)
> better answer.

Sure, no doubt about it. I was merely pointing out that -
instead of waiting for this bug to be fixed (which may or
may not happen any time soon) - it is also possible to fix
it in hardware.

> Also 50Mhz accelerator owners are S.O.L.

I'm confused - mine _is_ a 50-MHz board!

Ralph

drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) (03/09/91)

Maybe YOUR GVP board has this new PAL, but mine doesn't and according to GVP
the vast majority of them DON'T.  We could all spend the $30 for the new PAL
to run one _incorrectly_written_ program, but I think correcting the problem
at the source rather than the end user would be a better answer.

For anyone interested the PAL's number is U50 97A3 and is $30.  Specify this
particular PAL because if you don't they will ship you an updated but different
PAL labeled U50.  Also 50Mhz accelerator owners are S.O.L.

BTW, since Imtronics is out of business, what are Hurricane owners supposed
to do?  I still say if the author fixed his code, it would be a MUCH better
solution.

Rick Tillery (drtiller@uokmax.ecn.uoknor.edu)

koren@hpfcdc.HP.COM (Steve Koren) (03/10/91)

drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) writes:

> GVP has verified that indeed Mark Tomlinson has included odd word aligned
> references in his IBM emulator, IBeM.  This is the reason that neither the
> GVP accelerator nor the Hurricane 2800 will run his software.  Although
                          ^^^^^^^^^^^^^^

Dunno.  Seems to run just fine on my H-2800.  Or at least the demo version
does.  Maybe it breaks on only some H-2800s?

  - steve (koren@hpmoria)

drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) (03/11/91)

GVP said that there was no version of the U50 PAL for 50 Mhz boards so you
are out of luck...sorry.  Maybe they have some other solution for you.

As for fixing the program....well I am in communication with the author and
until I can convince him that he should fix it, we will have to upgrade 
through GVP (too bad for Hurricane owners).

Let's see...the GVP guy said their serial numbers were around 12,000 so if
we assume 10% of those people want to use IBeM enough to upgrade then that's
1200 x $30 = $36,000 for GVP.....Gee, Mark should get on there payroll (or maybe
he already is :-).

Rick Tillery (drtiller@uokmax.ecn.uoknor.edu)

rbabel@babylon.rmt.sub.org (Ralph Babel) (03/11/91)

In article <1991Mar10.193315.10566@uokmax.ecn.uoknor.edu>,
drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) writes:

> GVP said that there was no version of the U50 PAL for 50
> Mhz boards so you are out of luck...sorry.  Maybe they
> have some other solution for you.

I suppose I was unclear: Mine _is_ a 50-MHz version and
non-aligned word and longword accesses _do_ work fine!

Ralph

rbabel@babylon.rmt.sub.org (Ralph Babel) (03/11/91)

I just called GVP tech support (apparently right after
Donald had talked to them :-), so here's the final (?) word:

All current boards (no matter what speed) handle non-aligned
transfers properly, and all other GVP boards - except for a
very small number of one revision of the 50-MHz memory board
- can be upgraded. Technically, even this particular memory
board can be fixed, but so far nobody asked for the upgrade,
so they did not yet prepare the required PAL.

Ralph

DXB132@psuvm.psu.edu (03/12/91)

In article <1991Mar8.204144.10514@uokmax.ecn.uoknor.edu>,
drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) says:

>the vast majority of them DON'T.  We could all spend the $30 for the new PAL
>to run one _incorrectly_written_ program, but I think correcting the problem
>at the source rather than the end user would be a better answer.

Incorrectly written??? It seems you are blaming a programmer for a bug in
your hardware...

-- Dan Babcock

chem194@csc.canterbury.ac.nz (John Davis) (03/13/91)

In article <1991Mar8.204144.10514@uokmax.ecn.uoknor.edu>, drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) writes:
> Maybe YOUR GVP board has this new PAL, but mine doesn't and according to GVP
> the vast majority of them DON'T.  We could all spend the $30 for the new PAL
> to run one _incorrectly_written_ program, but I think correcting the problem
> at the source rather than the end user would be a better answer.
>
> Rick Tillery (drtiller@uokmax.ecn.uoknor.edu)

I'd really like to know exactly _where_ in the CBM manuals it states that
non-word aligned word accesses are illegal? Sure it kills you for backwards
compatibility with 000 machines, but that's irrelevant if you're writing
an 030 only product.

-----------------------------------------------------------
| o  John Davis - CHEM194@canterbury.ac.nz               o |
| o  (Depart)mental Programmer,Chemistry Department      o |
| o  University of Canterbury, Christchurch, New Zealand o | 

daveh@cbmvax.commodore.com (Dave Haynie) (03/13/91)

In article <91070.204643DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes:
>In article <1991Mar8.204144.10514@uokmax.ecn.uoknor.edu>,
>drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) says:

>>the vast majority of them DON'T.  We could all spend the $30 for the new PAL
>>to run one _incorrectly_written_ program, but I think correcting the problem
>>at the source rather than the end user would be a better answer.

>Incorrectly written??? It seems you are blaming a programmer for a bug in
>your hardware...

The deal is, both are technically wrong, from the Amiga point of view.  A
68030 can easily deal with the odd-byte alignments (data or stack).  The 
original GVP PAL does not.  Neither does the 68000.  So, unless that odd-byte 
alignment occurs in 68020/30 specific code, it is a bug for an Amiga system, 
if not a generic 68030 program.  Secondly, odd-byte alignments may cause a 
problem with any number of system function calls.  So they are, in general, a 
bad idea.

>-- Dan Babcock


-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
	"What works for me might work for you"	-Jimmy Buffett

dltaylor@cns.SanDiego.NCR.COM (Dan Taylor) (03/13/91)

In <91070.204643DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes:

>In article <1991Mar8.204144.10514@uokmax.ecn.uoknor.edu>,
>drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) says:

>>the vast majority of them DON'T.  We could all spend the $30 for the new PAL
>>to run one _incorrectly_written_ program, but I think correcting the problem
>>at the source rather than the end user would be a better answer.

>Incorrectly written??? It seems you are blaming a programmer for a bug in
>your hardware...

>-- Dan Babcock

NOT TRUE!  Although the 68030 is designed to do the unaligned transfers,
C-A EXPLICITY documented that Amiga software was NOT to do them, since the
68000 does not.

Therefore, broken software.

Dan Taylor

uzun@pnet01.cts.com (Roger Uzun) (03/14/91)

[]
Sorry I disagree, C-A said Amiga software rthat was to run on the 68000
was not to do them, IBeM requires an 020/030 or better to run at all.
It should be OK.   
In fact if he could fix the CGA emulation so it was tolerable speed-wise,
I think it would be a fantastic product.
-Roger

UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!uzun
ARPA: crash!pnet01!uzun@nosc.mil
INET: uzun@pnet01.cts.com