NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/2990

Internet Message Format | 1996-08-05 | 3.7 KB

Path: informatik.tu-muenchen.de!fischerj
From: [e-mail] (Juergen "Rally" Fischer)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: need help on A1200/030 board programming
Date: 7 Feb 1996 16:53:33 GMT
Organization: Technische Universitaet Muenchen, Germany
Distribution: inet
Message-ID: <4faled$[e-mail]>
References: <4f4hiu$[e-mail]> <[e-mail]>
NNTP-Posting-Host: hphalle1a.informatik.tu-muenchen.de
Originator: [e-mail]


In article <[e-mail]>, [e-mail] (Accolyte) writes:
|> Organization: Information Services, The University of Sydney, NSW, Australia
|> Lines: 41
|> Distribution: inet
|> Message-ID: <[e-mail]>
|> References: <4f4hiu$[e-mail]>
|> NNTP-Posting-Host: dialup36.wr.com.au
|> X-Newsreader: THOR 2.22 (Amiga;TCP/IP) *UNREGISTERED*
|>
|>
|> > Hello,
|> >
|> > this will sound strange, but here's what happens.
|> > We have been testing some of the 030 boards for A1200 (Amiga Power,
|> > DKB...), and got some strange results.
|> >
|> > It appears that these boards are almost two times slower when accessing
|> > CHIP RAM, than a basic A1200 (no acel. no extra RAM)!?
acessing... reading ?

|> >
|> > 12 gauge, Blizzard and others, on the other hand, are two times faster
|> > (which is normal).

not 2 times faster when aceessing chip ram. 8 14MHz cycles.

maybe a synchronous one will be 50% fasster in reading, maybe 8 14MHz cycles
instead of the 020-14 needing 12 doing a normal move.l (An),Dn. Sometimes
(movem or instruction fetch) 020-14 manages a 8 cycle read.

So imho max 50% faster in reading, 0% faster in writing to chipmem.

Maybe you did a copy fast->chip on the 030, which will indeed be 2 times
faster than a chip->chip on vanilla A1200 (if the 030 board is one of
the 7mb/sec speeders).

|> >
|> > So, the question is - is there a solution to make these 030s access
|> > CHIP RAM at normal speed?
|>
|> I had a theory about.. well, let me explain:
|>
|> Say you have an 030 at 50MHz, and presuming the internal 020 is clocked
|> to 14. As I understand it, this comes from a 28MHz crystal that is
|> sent to the chip-ram and custom chips, etc before being halved and sent
|> to the processor.
|>
|> If you could replace that 28MHz clock with a 56MHz one, send that straight
|> to the 030, halve it then put the resulting 28MHz signal into the normal
|> pathway that goes to the custom chips and is halved again before reaching
|> the processor. This would give you a slightly overclocked 030 that's
|> perfectly timed with the chip-ram, and hopefully giving optimal performance.
|>
|> Unfortunately, theorising is the limit of my hardware knowledge. Could
|> some people more experienced in hardware comment on it's feasability?

Welllll....
Also async 030 boards are said to still _store_ at 7mb/sec speed.
So iff a board can't do that, it maybe (I GUESS) even won't do
7mb/sec when clocked synchronous.

|>
|>
|> For the moment though, the only solution seems to be using fast ram
|> whenever possible if it is present. Certainly for the code, and

SURE! 99% of gfx routines just need a render in fastmem and then
copy to chipmem.

Do an Allocmem(size,0). If fastmem available, the buffer will be there,
else you get a chipmem buffer.

Do not hold any buffers there which are acessed by chipset (planes,
copper, blitter, audio, disk,...). Use Allocmem(size,2) for them to
always get chipmem.

|> for the source bitmaps wherever it's possible. It might mean a seperate
|> routine to replace straight blits, but the result would be great
|> improvement.
|>
|>
|>
------------------------------------------------------------------------
   [e-mail] (Juergen "Rally" Fischer)   =:)