The best video?!
*Mike Flynn (Applied Resources Consultant)
dissappointed with it! I would like to have quicker 256 color support
than my bit-planed AGA A4000 can deliver. HERe are my questions:
1. Are there ANY video cards out there that will give me video as fast as
say a MAC LC520/LCIII machine? From what I have heard, the only board
that can do this is MERLIN (correct?).
2. I am planning on buying a CD32 internal CD unit and I assume that it
comes with a planar<>chuncky chip. Will this effectively give me a chunky
pixel mode and speed up my graphics in the emulation? I would guess not
since this chip would exist on the CD32 card and not be accessible by the
EMPLANT SW.
3. I think that the Picollo board is ZIII. Is it as fast as MERLIN?
(because it is a few $$$ cheaper).
Thanks!
#;-> Mike
mike=flynn%man%csa...@sso.sci.sp-agency.ca
A4000/040 8megs fast
1960 colour monitor
Emplant/eceMIDI/MAC MIDI
PSOUND3 digitizer
2 cooling fans
And a neat mouse pad!
Jay Rymal
*Mike Flynn (Applied Resources Consultant) <mfl...@edx.ed.dreo.dnd.ca> wrote:
>
>
>3. I think that the Picollo board is ZIII. Is it as fast as MERLIN?
>(because it is a few $$$ cheaper).
>
The Piccolo Board by DKB is a ZorroIII/ZorroII autosensing card. It is quite
fast on the EMPLANT (as seen at WOCA Toronto). I liked it so much I ordered
one today for my A4000...;^)
It will dramatically improve your gfx updates, resolutions and colours!
>
>
--
************************** A M I G A 4 0 0 0 / 0 3 0
* Jay Rymal *
* UofT Computer Shop * AGA Power for the Masses
**************************
Art Warner
>In article <1993Dec8.2...@valet.dreo.dnd.ca>,
>*Mike Flynn (Applied Resources Consultant) <mfl...@edx.ed.dreo.dnd.ca> wrote:
>>
>>
>>3. I think that the Picollo board is ZIII. Is it as fast as MERLIN?
>>(because it is a few $$$ cheaper).
>>
>
>The Piccolo Board by DKB is a ZorroIII/ZorroII autosensing card. It is quite
>fast on the EMPLANT (as seen at WOCA Toronto). I liked it so much I ordered
>one today for my A4000...;^)
>
stock ECS Amiga (ala 3000)? (just curious)
If so, how much faster?
Thanks.
--
--------------------------------------------------------------
William "Art" Warner
tel# (317) 497-1946 << This space for rent. >>
wwa...@en.ecn.purdue.edu
Neil Richmond
impressions of the speed? Thanks.
neil
--
" Give a skeptic an inch and he'll measure it. "
Neil F. Richmond ne...@rhythm.com
Rhythm & Hues Inc.
Barry Einstein
: Has anyone tried the Piccolo in millions of colors mode?
If anyone is using the Piccolo board, please share your findings here about
the board, it's features, speed etc.
I've heard a lot about the PicassoII but there's been very little said about
the Piccolo so far.
I have a Zorro III Amiga 3000 and it's been recommended that the Piccolo would
be a good choice for Zorro III machines.
Jim Drew
In <1993Dec8.2...@valet.dreo.dnd.ca>, mfl...@edx.ed.dreo.dnd.ca
(*Mike Flynn (Applied Resources Consultant)) writes:
> I have owned my emplant board since the summer and I have never been
> dissappointed with it! I would like to have quicker 256 color support
> than my bit-planed AGA A4000 can deliver. HERe are my questions:
>
> 1. Are there ANY video cards out there that will give me video as fast as
> say a MAC LC520/LCIII machine? From what I have heard, the only board
> that can do this is MERLIN (correct?).
than LCIII video displays.
> 2. I am planning on buying a CD32 internal CD unit and I assume that it
> comes with a planar<>chuncky chip. Will this effectively give me a chunky
> pixel mode and speed up my graphics in the emulation? I would guess not
> since this chip would exist on the CD32 card and not be accessible by the
software only routines are.
Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
jd...@cryo.rain.com 790 Lake Havasu Ave #16
GEnie: j.drew2 Lake Havasu City, AZ 86403
BBS #:(602) 453-9767 Orders:(602) 680-9004
Tech #:(602) 680-9234 FAX:(602) 453-6407
Jay Rymal
Give me a couple of weeks..hopefully not TOO many..I'm waiting for my
Piccolo order at my store and my vsn 3.2 of EMPLANT in the mail....
I'll post how this works in my a4000/030 10Mb 420Mb system...(w/ 33Mhz '882)
Cheers,
Stefan Boberg
>The Akiko chip is actually slower at converting chunky->planar than our
>software only routines are.
<cough> <cough>
That's quite a misleading statement. Given the two are running on the
same processor, there's no way any software routine would be faster than
the Akiko conversion. Period. (Question: Why the hell would Commodore
include the corner-turn memory on Akiko otherwise?)
>Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
> jd...@cryo.rain.com 790 Lake Havasu Ave #16
--
Stefan Boberg, Amiga/SEGA/CD32 programmer - Team 17 Software / LhA Devel.
Applied Physics and Electrical Engineering Student, Linkoping University
InterNet: bob...@lysator.liu.se bob...@team17.adsp.sub.org
========== Disclaimer: I only speak for myself, not Team 17. ============
Olaf Barthel
> > 2. I am planning on buying a CD32 internal CD unit and I assume that it
> > comes with a planar<>chuncky chip. Will this effectively give me a chunky
> > pixel mode and speed up my graphics in the emulation? I would guess not
> > since this chip would exist on the CD32 card and not be accessible by the
>
> The Akiko chip is actually slower at converting chunky->planar than our
> software only routines are.
BZZZT! You are talking about a routine running on an 16 MHz MC68020
style CPU which converts an array of pixels of an arbitrary size into
planar bitmap data, aren't you?
--
Olaf Barthel | Internet: ol...@sourcery.han.de
Brabeckstrasse 35 | o.ba...@a-link-h.comlink.de
D-30559 Hannover |
MXM, ECG127 | Z-Netz: O.BARTHEL@A-LINK-H
-------------------------------------------------------------------------
Ceci n'est pas une signature.
Jim Drew
In <1993Dec13....@ida.liu.se>, y91s...@odalix.ida.liu.se (Stefan
Boberg) writes:
> jd...@cryo.rain.com (Jim Drew) writes:
>
> >The Akiko chip is actually slower at converting chunky->planar than our
> >software only routines are.
>
> <cough> <cough>
>
> That's quite a misleading statement. Given the two are running on the
> same processor, there's no way any software routine would be faster than
> the Akiko conversion. Period. (Question: Why the hell would Commodore
> include the corner-turn memory on Akiko otherwise?)
routines can always beat it. Yes, Commodore knows about this.. they are
now using our routines, and you will find them shortly when the new CD-32
developers package comes out...
Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
jd...@cryo.rain.com 790 Lake Havasu Ave #16
Jim Drew
In <9427...@sourcery.han.de>, "Olaf Barthel" <ol...@sourcery.han.de> writes:
> In Article <CHuE0...@percy.rain.com>, Jim Drew <jd...@cryo.rain.com>
>wrote:
> > > 2. I am planning on buying a CD32 internal CD unit and I assume that it
> > > comes with a planar<>chuncky chip. Will this effectively give me a
>chunky
> > > pixel mode and speed up my graphics in the emulation? I would guess not
> > > since this chip would exist on the CD32 card and not be accessible by
>the
> >
> > The Akiko chip is actually slower at converting chunky->planar than our
> > software only routines are.
>
> BZZZT! You are talking about a routine running on an 16 MHz MC68020
> style CPU which converts an array of pixels of an arbitrary size into
> planar bitmap data, aren't you?
that Commodore didn't just use the blitter to do the 'rotate 90' routines
as it is nearly as fast as Akiko, and was already created.
Ricardo Hernandez Muchado
|> Tue, 14 Dec 93 18:33:06 PDT<19931214.84...@cryo.rain.com>
|> In <9427...@sourcery.han.de>, "Olaf Barthel" <ol...@sourcery.han.de> writes:
|> > In Article <CHuE0...@percy.rain.com>, Jim Drew <jd...@cryo.rain.com>
|> >wrote:
[stuff deleted]
|>
|> Yes, that is exactly what I am talking about. In fact, it is rather odd
|> that Commodore didn't just use the blitter to do the 'rotate 90' routines
|> as it is nearly as fast as Akiko, and was already created.
|>
|>
|> Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
|> jd...@cryo.rain.com 790 Lake Havasu Ave #16
|> GEnie: j.drew2 Lake Havasu City, AZ 86403
|> BBS #:(602) 453-9767 Orders:(602) 680-9004
|> Tech #:(602) 680-9234 FAX:(602) 453-6407
So your routines are actually faster than the Akiko on the EC020 on
the CD-32 at 14Mhz? Oh, my God!
I guess it would have been better If C= did Akiko to read a whole
buffer and go directly to the screen.... Oh, well.
-------------------------------------------------------------------------
Raist A1200/CSA '12 Gauge' 030/882 @ 50Mhz, 16 megs Fast Ram, 200 meg HD
// >>> I LOVE IT <<<< My comments are my own, not of my employer
\X/ 256,000 + colors, 24-bit palette Real 3D V2, Image FX, Scala MM210
>>> New internet address: ra...@vnet.ibm.com <<<<
James McCoull
>> BZZZT! You are talking about a routine running on an 16 MHz MC68020
>> style CPU which converts an array of pixels of an arbitrary size into
>> planar bitmap data, aren't you?
>
>Yes, that is exactly what I am talking about. In fact, it is rather odd
>that Commodore didn't just use the blitter to do the 'rotate 90' routines
>as it is nearly as fast as Akiko, and was already created.
Jim this is a blantant lie. To convert a 320x200x256 colour chunky image
will take of the order of 120ms using the most efficient blitter routine
possible. Akiko and 020 + no_fast takes only 35ms to do the same job.
Save your time and ours by going to a psychologist and having treatment for
your condition -- you are a "Pathological Liar". I dont like to be rude in
such a public forum but if you would ease up a little on the ripe falsehoods
people might take your beta product (Emplant) a little more seriously.
Regards, James McCoull.
Mike Powell
James... I hate to be rude in public... but you are scum... the lowest
bag o sewage I ever ran across. You lie, you cheat, and you probably steal.
Perhaps you could schedule an appointment with Dr. Kevorikan... maybe
he could help you with your condition...
(geez.... some people. At least we can all feel good after slinging
around childish insults at eachother.... *food fight*!!!)
-Mike- (an everyday EMPLANT Deluxe user...)
Jason Compton
JM> for
JM> your condition -- you are a "Pathological Liar". I dont like to be rude
JM> in
JM> such a public forum but if you would ease up a little on the ripe
JM> falsehoods
JM> people might take your beta product (Emplant) a little more seriously.
Save your time and ours by keeping your ridiculous comments to yourself.
If you think he's wrong, fine. If you think he's wrong a lot, great. Prove
him wrong then, don't assault him. As far as I can tell, he's done you no
public wrong.
------------------------------------------------------------------------------
: Jason Compton Nothing Absolutely :
: jcom...@tcity.com jcom...@tcity.com :
: Columnist at Amiga Report ...read it, it's good. :
: Emulation fanatic Amiga and CD32 advocate...:
: Only Amiga makes it possible... ...as only we know. :
------------------------------------------------------------------------------
Jim Drew
In <2f5ihs$k...@diemen.utas.edu.au>, jmcc...@bruny.cc.utas.edu.au (James
> Jim this is a blantant lie. To convert a 320x200x256 colour chunky image
> will take of the order of 120ms using the most efficient blitter routine
> possible. Akiko and 020 + no_fast takes only 35ms to do the same job.
>
> Save your time and ours by going to a psychologist and having treatment for
> your condition -- you are a "Pathological Liar". I dont like to be rude in
> such a public forum but if you would ease up a little on the ripe falsehoods
> people might take your beta product (Emplant) a little more seriously.
>
> Regards, James McCoull.
>
Sheesh... maybe you should go to programming school. I am not going to
argue with you about it. The routines exist, Commodore has obtained the
rights to them for use with CD-32 stuff and they have patents pending...
People like you can cause the death of the Amiga with these 'that is not
possible' type of statements...
Nico Francois
message to All:
JM> Jim this is a blantant lie. To convert a 320x200x256 colour chunky
JM> image will take of the order of 120ms using the most efficient blitter
JM> routine possible. Akiko and 020 + no_fast takes only 35ms to do the
JM> same job.
JM> Save your time and ours by going to a psychologist and having treatment
JM> for your condition -- you are a "Pathological Liar". I dont like to be
JM> rude in such a public forum but if you would ease up a little on the
JM> ripe falsehoods people might take your beta product (Emplant) a little
JM> more seriously.
And another one sees the light ;-)
_o
#> Email: ni...@augfl.be
Nico Francois 4 Fido : 2:292/603.10
... Aaah! I see you have the machine that goes PING!
Ken Dyke - Amiga Gfx Kcd FMV
>Mon, 13 Dec 93 15:55:39 PDT<19931213.8...@cryo.rain.com>
>In <1993Dec13....@ida.liu.se>, y91s...@odalix.ida.liu.se (Stefan
>Boberg) writes:
>> jd...@cryo.rain.com (Jim Drew) writes:
>>
>> >The Akiko chip is actually slower at converting chunky->planar than our
>> >software only routines are.
>>
>> <cough> <cough>
>>
>> That's quite a misleading statement. Given the two are running on the
>> same processor, there's no way any software routine would be faster than
>> the Akiko conversion. Period. (Question: Why the hell would Commodore
>> include the corner-turn memory on Akiko otherwise?)
>
>Read it and weap. Because Akiko's bus access is so slow, software
>routines can always beat it. Yes, Commodore knows about this.. they are
>now using our routines, and you will find them shortly when the new CD-32
>developers package comes out...
How about read it and laugh, Mr. Drew. I found it quite odd that nobody that
deals with the CD32 over in CATS knew anything about your famed chunky to
planar routines. Nor did anyone else in engineering for that matter. Do you
have the name of the person I should get your routines from since apparently
we now have them? I'd love to run some benchmarks on them.
I would be really interested in seeing a c2p routine that can convert 32
pixels and write them out to 8 bitplanes in less time on an 020 than this:
move.l (a0)+,(a2)
move.l (a0)+,(a2)
move.l (a0)+,(a2)
move.l (a0)+,(a2)
move.l (a0)+,(a2)
move.l (a0)+,(a2)
move.l (a0)+,(a2)
move.l (a0)+,(a2)
move.l (a2),(a1)+
move.l (a2),36(a1)
move.l (a2),76(a1)
move.l (a2),116(a1)
move.l (a2),156(a1)
move.l (a2),196(a1)
move.l (a2),236(a1)
move.l (a2),276(a1)
[okay, so it's a bit contrived and only works with an 8 bitplane interleaved
320x200 screen, but it's easily modified for other cases].
And as for Akiko's c2p hardware, it's zero-wait states, so I'm not exactly
sure what you mean by Akiko's bus access being so slow. You might also find
it interesting to know that all chip ram accesses by the 68020 must go
through Akiko, as it's the bridge between the 020 bus and the custom chip
bus. So no matter what you do, c2p hardware accesses will always be faster
than chip ram accesses.
So, care to back up your claims?
-Ken
--
------
Kenneth Dyke - Commodore Technology Internet: k...@commodore.com
Amiga Graphics & Full Motion Video BIX: kcd
"Just One Fix..." - Ministry
flam
: jd...@cryo.rain.com (Jim Drew) writes:
: Regards, James McCoull.
WOW...What crawled up your butt?
I understand people wanting Jim to clarify his claims.
Many of them DO seem impossable (and some may be)
BUT it has been said that the color MAC emulator
was also impossible
hmm...
my BETA emplant (bullshit) works so flawlessly that it
even bombs JUST LIKE A MAC!
I take it very seriously...
I own a mac and the emplant blows its socks off!
Mac IIfx and Emplant/4000/40
Yes Jim gets carried away... but you are looking a little worse to me :(
Regards
James
--
__________________________________________________________
Q. What is the least spoken phrase in the english laguage?
A. Hey isn't that the banjo player's porche?
Fear is just the effect of being too lazy to get excited!!
-Flam (makealotofnoise)
__________________________________________________________
Jim Drew
In <1993Dec20.1...@cbmnews.commodore.com>, k...@mintaka.commodore.com
>
> How about read it and laugh, Mr. Drew. I found it quite odd that nobody
>that
> deals with the CD32 over in CATS knew anything about your famed chunky to
> planar routines. Nor did anyone else in engineering for that matter. Do
>you
> have the name of the person I should get your routines from since apparently
> we now have them? I'd love to run some benchmarks on them.
James McCoull
>Thu, 23 Dec 93 02:29:07 PDT<19931223.8...@cryo.rain.com>
>In <1993Dec20.1...@cbmnews.commodore.com>, k...@mintaka.commodore.com
^^^^^^^^^^^^^^^^^^^^^ ^^^
>>
>> How about read it and laugh, Mr. Drew. I found it quite odd that nobody
>>that
>> deals with the CD32 over in CATS knew anything about your famed chunky to
>> planar routines. Nor did anyone else in engineering for that matter. Do
>>you
>> have the name of the person I should get your routines from since apparently
>> we now have them? I'd love to run some benchmarks on them.
>
>I find it odd you don't know who Jeff Porter is.
So would I if they didnt work for the same company.
Gee couldnt kcd be Ken Dyke? The very man who works at commodore on graphics
and FMV. The very man who kindly timed akikos performance for me, while
I ran the chunky2planar conversion competition?
For the sake of clarity I'll give some information on the results of the
chunky2planar competition (which by the way I ran, despite being painted
as the amiga-antichrist etc):
Best result on A1200/EC020+nofastram, 100ms to convert 320x200x256 from chunky
to planar.
Best result on A1200/EC020+fastram, 50ms to convert 320x200x256 from chunky
to planar.
Best result on A1200/nofastram+akiko, 35ms to convert 320x200x256 from chunky
too planar.
Best blitter only solution, 120ms to convert 320x200x256 from chunky to planar.
Now lets review Jim Drews claims on his "awesome" chunky2planar routines:
Claim #1: He has routines which are faster than akiko -- on the 020. So
you have a routine which can convert a full 320x200x256 chunky image
to planar quicker than akiko? Lets see it? Its certainly not in
the v3.4 release of the emplant software, because I've taken the
liberty of diassembling the video drivers for AGA, and found some
fair to middling chunky2planar convertors, but nothing as good as
those which won the chunky2planar competition.
Claim #2: C= shouldnt have worried with the c2p convertor in akiko because
the blitter can be used to convert almost as quickly from chunky to
planar. Great Jim... you must have managed to put the blitter in
overdrive mode or something. lets just review the mechanics of
what a blitter chunky2planar convertor must do...
Let the input buffer contain:
offset 0 2 4 6 8 A C E ...
pixels AB CD EF GH IJ KL MN OP ...
where pixel A = bits a7 a6 ... a0
pixel B = bits b7 b6 ... b0
Now we will have 8 output planes of the form:
plane 0 = a7 b7 c7 ... p7
plane 1 = a6 b6 c6 ... p6
etc...
Now lets look closely... first word in plane 0... gosh its made up
from bits which are sourced from 8 words in the original buffer.
Lets use a common programming technique
[gee Jim I've been to programming school!
(Only for 5 years sorry)]
of "doubling" to provide an optimal solution using the blitter.
Input: AB CD EF GH IJ KL MN OP ..
\/ \/ \/ \/ First pass
\ / \ /
\ / \ /
\/ \/ Second pass
\ /
\ /
\ /
\ /
\ /
\ / Third pass
So we have an optimal solution taking 3 passes over the data.
Each pass must read 2 input words to output 1 output word.
[thats the only way the blitter can merge bits from separate words]
So for this optimal solution we perform numberpasses * cost * words
memory cycles with the blitter.
= 3 * 3 * ( 320*200/2)
= 144000 memory cycles.
Now a memory cycle costs the blitter 280ns.
144000 memory cycles = 80ms.
So a mega optimal blitter solution has a lower limit of 80ms.
So Jim, show me a blitter routine that can do it in 35-40ms
["close to akikos speed"] and I'll have seen the light.
Please Jim, oh please Jim show me your mega hot c2p routines and I'll
be a happy man.
Regards, James McCoull.
Jim Drew
In <2fg1fa$p...@diemen.utas.edu.au>, jmcc...@bruny.cc.utas.edu.au (James
McCoull) writes:
>
> Now lets review Jim Drews claims on his "awesome" chunky2planar routines:
>
> Claim #1: He has routines which are faster than akiko -- on the 020. So
> you have a routine which can convert a full 320x200x256 chunky
>image
> to planar quicker than akiko? Lets see it? Its certainly not in
> the v3.4 release of the emplant software, because I've taken the
> liberty of diassembling the video drivers for AGA, and found some
> fair to middling chunky2planar convertors, but nothing as good as
> those which won the chunky2planar competition.
interesting that you looked at my routines. You must
also know that I saw your routines months ago when Peter and I were
trading ideas back and forth. You guys are stuck in 320x200 hell. We
have to deal with 640x400 0 (or 480) displays.... so we are dealing with
DMA contention. My routines are designed for this enviroment. You guys
are doing the 'convert 8, write 5' testing which does not cut it...
especially in low-res mode without any DMA contention. EVERYTHING that I
have been talking about deals with Productivity/Multiscan 256 color
modes. If you look at my routines (which you are doing) you will find
that I am converting the data FASTER than the Amiga
's display hardware can take it. If you don't believe this to be true,
run a simple test... open a 640x480 256 color screen, and simply move
from one address to another [ (a0)+,(a1)+ ] using FAST memory to CHIP
memory. You will find that the majority of the time is spent waiting for
the bus to free up. With this in mind, you can see that using the
blitter in the same enviroment (since shifting is done internally,
asyncronous to the bus) can be as fast as AKIKO, which I have also tested
in 640x400x8 bit mode. We don't deal with low-res, no DMA contention
modes... so, we are comparing Apples to Oranges here.
Whip up some routines yourself, test the speed of the chip memory bus,
break out the calculator, and logic analyzer... I did.
>
> Claim #2: C= shouldnt have worried with the c2p convertor in akiko because
> the blitter can be used to convert almost as quickly from chunky to
> planar. Great Jim... you must have managed to put the blitter in
> overdrive mode or something. lets just review the mechanics of
> what a blitter chunky2planar convertor must do...
Jani Miettinen
: Sun, 26 Dec 93 03:49:51 PDT<19931226.8...@cryo.rain.com>
: In <2fg1fa$p...@diemen.utas.edu.au>, jmcc...@bruny.cc.utas.edu.au (James
: McCoull) writes:
: >
: > Now lets review Jim Drews claims on his "awesome" chunky2planar routines:
: >
: > Claim #1: He has routines which are faster than akiko -- on the 020. So
: > you have a routine which can convert a full 320x200x256 chunky
: >image
: > to planar quicker than akiko? Lets see it? Its certainly not in
: > the v3.4 release of the emplant software, because I've taken the
: > liberty of diassembling the video drivers for AGA, and found some
: > fair to middling chunky2planar convertors, but nothing as good as
: > those which won the chunky2planar competition.
:
: Where do your C2P conversion routines fall into competition? It is
: interesting that you looked at my routines. You must
: also know that I saw your routines months ago when Peter and I were
: trading ideas back and forth. You guys are stuck in 320x200 hell. We
: have to deal with 640x400 0 (or 480) displays.... so we are dealing with
: DMA contention. My routines are designed for this enviroment. You guys
: are doing the 'convert 8, write 5' testing which does not cut it...
: especially in low-res mode without any DMA contention. EVERYTHING that I
: have been talking about deals with Productivity/Multiscan 256 color
: modes. If you look at my routines (which you are doing) you will find
: that I am converting the data FASTER than the Amiga
: 's display hardware can take it. If you don't believe this to be true,
One question: Could the Amiga's CPU or other chips do something else meanwhile
the Akiko chip does converting between chunky to planar?
If it can, how come the overall result would be "faster"?
: Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
-Jani
Ken Dyke - Amiga Gfx Kcd FMV
>Thu, 23 Dec 93 02:29:07 PDT<19931223.8...@cryo.rain.com>
>In <1993Dec20.1...@cbmnews.commodore.com>, k...@mintaka.commodore.com
>>
>> How about read it and laugh, Mr. Drew. I found it quite odd that nobody
>>that
>> deals with the CD32 over in CATS knew anything about your famed chunky to
>> planar routines. Nor did anyone else in engineering for that matter. Do
>>you
>> have the name of the person I should get your routines from since apparently
>> we now have them? I'd love to run some benchmarks on them.
>
>I find it odd you don't know who Jeff Porter is.
A) I know exactly who Jeff Porter is. He's a good friend of mine.
B) I don't know why Jeff would be dealing with your code, as he has
nothing to do with software development or developer support for CD32.
C) I find it odd that Jeff didn't know what you were talking about, either.
And yes, I asked. He found your claims to be quite amusing.
D) I'm sure if he had your code, he would have mentioned it to someone in
engineering who's involved with the CD32.
So, who might I try next?
James McCoull
>Where do your C2P conversion routines fall into competition?
First on 68000,
First on 68010,
First on 68020,
First on 68040,
and maybe first on 68030, I cant remember.
> It is
>interesting that you looked at my routines. You must
>also know that I saw your routines months ago when Peter and I were
>trading ideas back and forth.
Thats a little hard to believe as Peter never got all my routines.
When I discovered the fastest way to convert from chunky2planar, I lost
interest in the project for a few months and forgot to send my source on
to peter.
>You guys are stuck in 320x200 hell.
How do you work this one out? You basing this on one of peters test
programs? How do you extrapolate that thats the only test program
I have used?
>We
>have to deal with 640x400 0 (or 480) displays.... so we are dealing with
>DMA contention.
We all are honey dear.
>My routines are designed for this enviroment. You guys
>are doing the 'convert 8, write 5' testing which does not cut it...
Since when. Every C2p routine I have ever written converts 8,
writes 8.
>especially in low-res mode without any DMA contention. EVERYTHING that I
>have been talking about deals with Productivity/Multiscan 256 color
>modes.
Ok lets review your two claims in light of this environment.
Claim #1 - Blitter can convert c2p almost as fast as akiko.
Claim #2 - 020 on nofastram AGA machine can convert faster than
akiko.
Review of claim #1 in light of 100% hdisplay contention.
Errr... major logic flaw jim. An akiko convertor only needs to read and write
(from chipram -- which is under heavy contention)
one long word for each long word in the chunky buffer. A blitter convertor?
Well thats gotta read each word at _least_ 3 times [as i explained in a
previous post], and its only dealing with short words.
So jim a blitter routine has to do at least 9N short word accesses to chipram
to do its conversion [N= number of short words in chunky buffer], while
a routine usiing akiko only has to do N long word accesses to chipram.
As chipram on AGA machines is 32 bit... thats
N chipram accesses for akiko vs 9N chipram accesses for blitter.
I dunno about you jim, but with chipram under heavy display DMA i'd
rather the N chipram accesses over the 9N chipram access any day.
Even when we factor in that the blitter can access chipram every 280ns
versus the cpus 560ns [for the hblank and vblank in the case of this
contention]... thats N vs 4.5N.
Review of claim #2 in light of 100% hdisplay contention.
Again a major logic flaw. Both an akiko routine and a routine without akiko
will need to do the same number of chipram accesses.
So the display contentin doesnt make 1 little bit of difference to the argument
>If you look at my routines (which you are doing) you will find
>that I am converting the data FASTER than the Amiga
>'s display hardware can take it.
I doubt it Jim. Converting faster than the display hardware can take
it implies being abled to convert faster than 640*480*60 Megabytes per second.
Thats 18.4 megabytes per second. Whats the 040 in the A4k/040 do? about 20mips?
That means you are converting 1 chunky pixel to planar with a little over one
instruction. Or you are converting 32 chunky pixels to planar with about
9 instructions -- very unlikely.
If you mean you are converting faster than you can read data from
fastram and write to chipram, then why dont you say this. No one would dispute
this. Under 640x480x256 screen display modes you can be locked out of chipram
accesses for up to 80 chipram cycles. Thats a whopping 560 040 cycles.
If you couldnt convert 32 pixels in that time we would be a little worried.
Still dont make the mistake of assumpting that this means you any conversion
latency up to 560 040 cycles can be tolerated. Its a matter of restructuring
your c2p convertor to burst thru the data on hblanks and vblanks.
>If you don't believe this to be true,
>run a simple test... open a 640x480 256 color screen, and simply move
>from one address to another [ (a0)+,(a1)+ ] using FAST memory to CHIP
>memory. You will find that the majority of the time is spent waiting for
>the bus to free up.
Not in the hblanks and vblanks, where a programmer who has been to
programming school might know this is the time to try and write to chipram.
> With this in mind, you can see that using the
>blitter in the same enviroment (since shifting is done internally,
>asyncronous to the bus) can be as fast as AKIKO, which I have also tested
>in 640x400x8 bit mode.
As I explained above this argument is bad. A routine using the blitter has
to do more chip bus activity than a routine using AKIKO. Thus if the
performance of the chip bus is degrading then the blitter routine will slow
dramatically compared to a routine using akiko.
> We don't deal with low-res, no DMA contention
>modes... so, we are comparing Apples to Oranges here.
As I explained, your arguments become worse under higher DMA contention.
>Whip up some routines yourself, test the speed of the chip memory bus,
>break out the calculator, and logic analyzer... I did.
Jim I have. I started working on efficient c2p way before you did. Let
me quote from a letter I recieved:
] Message 1/41 From Peter McGavin
]
] [...]
] Just so you know what's going on... I wrote to Jim a few months ago
] saying I thought I could speed up his c2p. I said I would do it for
] free (for a better Emplant). He sent me a source code fragment (which
] he instructed me not to pass on) which did a very slow 8-plane c2p
] using an enormous lookup table. It included some tricky MMU code for
] testing for changes to the video RAM and updating only 32-pixels at a
] time. I substituted some code of my own based around peterm/chunky4
] in the core of his routine and sent it back to him. At first he
] didn't believe that it was faster, so I sent him some timing test
] binaries (640x480 as requested) that convinced him that it was much
] faster. Later he asked me about 2-plane and 4-plane routines and I
] obliged by sending him some routines based around Michael van Elst's
] code but modified to handle packed chunky-pixels using various 4
] kbyte, 16 kbyte and 256 kbyte tables. I also sent him a copy of your
] 8-plane blitter algorithm and the 68040 test binary that you sent me
] some time ago, saying that I thought you had some faster routines.
] Jim never told me whether he used the routines I sent him or not, but
] a few days later a new version of the Emplant software came out with
] much faster c2p. Jim then started his "faster than Akiko" claims. I
] haven't had any communications since.
]
] Regards, Peter.
See jim, the blitter routine which you claim is licensed to commodore and under
patent is mine. Its also the routine which sparked your claim i should go to
programming school, so I can learn to program as well as it.
Also the fastest 040 chunky2planar routine I have seen is the one I wrote
[with hints and tricks from many folks -- Ken Dyke, T21, ...]
From all accounts the chunk2planar convertors in Emplant are not overly your own
work any more. Now if you apologize nicely to me and send me a A1200 emplant
[if such a device exists], I'd be more than willing to improve your c2p
routines further as they appear not to be hblank and vblank aware.
Regards, James McCoull.
Dan E Babcock
- In article <CIHH6...@percy.rain.com> jd...@cryo.rain.com (Jim Drew) writes:
- >Thu, 23 Dec 93 02:29:07 PDT<19931223.8...@cryo.rain.com>
- >In <1993Dec20.1...@cbmnews.commodore.com>, k...@mintaka.commodore.com
- >>
- >
[stuff deleted]
- >I find it odd you don't know who Jeff Porter is.
-
- A) I know exactly who Jeff Porter is. He's a good friend of mine.
- B) I don't know why Jeff would be dealing with your code, as he has
- nothing to do with software development or developer support for CD32.
- C) I find it odd that Jeff didn't know what you were talking about, either.
- And yes, I asked. He found your claims to be quite amusing.
- D) I'm sure if he had your code, he would have mentioned it to someone in
- engineering who's involved with the CD32.
Uh oh. I'm afraid this is likely to trigger one of Jim Drew's bouts of
amnesia. Come to think of it, I'm not completely sure myself that this
thread happened. It probably didn't - it would make Jim a "pathalogical
liar", which we have already dismissed as a childish thought.
Dan
Nico Francois
All:
>> Claim #1: He has routines which are faster than akiko -- on the 020. So
>> you have a routine which can convert a full 320x200x256 chunky
>> image
>> to planar quicker than akiko? Lets see it? Its certainly not
>> in
>> the v3.4 release of the emplant software, because I've taken the
>> liberty of diassembling the video drivers for AGA, and found some
>> fair to middling chunky2planar convertors, but nothing as good as
>> those which won the chunky2planar competition.
JD> Where do your C2P conversion routines fall into competition? It is
JD> interesting that you looked at my routines. You must also know that I
JD> saw your routines months ago when Peter and I were trading ideas back
JD> and forth. You guys are stuck in 320x200 hell. We have to deal with
JD> 640x400 0 (or 480) displays.... so we are dealing with DMA contention.
If a routine/algorithm is faster in 320x200 it will also be faster in 640x400.
Even if DMA contention holds everything up both routines will be equally fast.
You were claiming you had a _faster_ routine, something that beats even Akiko.
You seem to very easily forget what you say. Look at this thread:
--
You wrote:
> BZZZT! You are talking about a routine running on an 16 MHz MC68020
> style CPU which converts an array of pixels of an arbitrary size into
> planar bitmap data, aren't you?
Yes, that is exactly what I am talking about. In fact, it is rather odd
that Commodore didn't just use the blitter to do the 'rotate 90' routines
as it is nearly as fast as Akiko, and was already created.
--
And you wrote:
> Jim this is a blantant lie. To convert a 320x200x256 colour chunky image
> will take of the order of 120ms using the most efficient blitter routine
> possible. Akiko and 020 + no_fast takes only 35ms to do the same job.
[...some insults deleted ;)...]
Sheesh... maybe you should go to programming school. I am not going to
argue with you about it. The routines exist, Commodore has obtained the
rights to them for use with CD-32 stuff and they have patents pending...
--
Nowhere did you mention DMA contention here. You were _clearly_ stating your
routine was faster than Akiko (full stop). And you were _clearly_ stating the
blitter was nearly as fast as Akiko (and the blitter suffers from DMA
contention too BTW). Both of these claims now appear to be totally false.
What about the claim that Commodore has obtained the rights to your routine
(patents pending even, where have we heard that before ?) ? Nobody at
Commodore knows what you are talking about. No, Jeff Porter doesn't either.
You do here exactly as you always do. First you make an outrageous claim
(which is usually complete and utter nonsense), and then when people start to
react and are about to show just how stupid your claim is, you cloud
everything up by dragging in lots of other facts and start talking besides the
subject.
Sheesh...
I'll probably get flamed to death by all the followers of the Jim Drew
religion here, but who cares. You must be laughing your head of Mr. Drew. You
have discovered how easy it is to fool most people, and you seem to be
enjoying it _thoroughly_...
This message is not an insult. It is an observation.
_o
#> Email: ni...@augfl.be
Nico Francois 4 Fido : 2:292/603.10
... I had so many problems, And then I got me a walkman
Jim Drew
In <1993Dec26....@mail.vitech.fi>, t93...@mail.vitech.fi (Jani
Miettinen) writes:
>
> One question: Could the Amiga's CPU or other chips do something else
>meanwhile
> the Akiko chip does converting between chunky to planar?
>
> If it can, how come the overall result would be "faster"?
akiko), but to move an address in and get the result out requires to bus
accesses generally. You could use the blitter in 3/4 mode (non-nasty)
and have a little more CPU time available... which I have found to help
out tremendously with the blitter 'rotate 90' routines.
But.. basically, the machine is pretty useless while doing video stuff.
Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
Jim Drew
In <2flefl$2...@diemen.utas.edu.au>, jmcc...@bruny.cc.utas.edu.au (James
McCoull) writes:
> From all accounts the chunk2planar convertors in Emplant are not overly
>your own
> work any more. Now if you apologize nicely to me and send me a A1200
>emplant
> [if such a device exists], I'd be more than willing to improve your c2p
> routines further as they appear not to be hblank and vblank aware.
have heard a lot of them)...
Everything contained within EMPLANT is property of myself and Utilities
Unlimited, Inc. with nothing obtained from outside sources. No ideas
exchanged between Peter and I conceived by Peter were used, they were
slower. Ask Peter, we argued over the net about our 8 bit routines. His
routines were slower under our emulation, but faster using his test
program, strictly because of DMA contention.
Also, the 2 bit and 4 bit routines were faster than what Peter could come
up with.
I am well aware of the hblank and vblank syncronization and the 'burst
window' that chip mem has.
Jim Drew
Well, that is interesting since Jeff Porter (along with Carolyn) did the
entire CD32 developer presentation in September, which is when I talked
to them about the routines, and Commodore setup the CEI4000 deal. Oh,
but I suppose that doesn't exist either... right Dan?
Jani Miettinen
: Tue, 28 Dec 93 00:59:54 PDT<19931228.8...@cryo.rain.com>
: In <1993Dec26....@mail.vitech.fi>, t93...@mail.vitech.fi (Jani
: Miettinen) writes:
: >
: > One question: Could the Amiga's CPU or other chips do something else
: >meanwhile
: > the Akiko chip does converting between chunky to planar?
: >
: > If it can, how come the overall result would be "faster"?
:
: The blitter can do shifting internally while the bus is tied up (as can
: akiko), but to move an address in and get the result out requires to bus
: accesses generally. You could use the blitter in 3/4 mode (non-nasty)
: and have a little more CPU time available... which I have found to help
: out tremendously with the blitter 'rotate 90' routines.
:
: But.. basically, the machine is pretty useless while doing video stuff.
So CPU is useless on "Chip Ram", but can it even be used on "Fast RAM"-bus?
-Jani
Dan E Babcock
- Tue, 28 Dec 93 01:13:22 PDT<19931228.8...@cryo.rain.com>
- In <2flsn9$m...@genesis.ait.psu.edu>, D...@ECL.PSU.EDU (Dan E Babcock) writes:
- > In <1993Dec23.1...@cbmnews.commodore.com> k...@mintaka.commodore.com
- >writes:
[much deleted]
- > Uh oh. I'm afraid this is likely to trigger one of Jim Drew's bouts of
- > amnesia. Come to think of it, I'm not completely sure myself that this
- > thread happened. It probably didn't - it would make Jim a "pathalogical
- > liar", which we have already dismissed as a childish thought.
- >
- > Dan
- >
-
- Well, that is interesting since Jeff Porter (along with Carolyn) did the
- entire CD32 developer presentation in September, which is when I talked
- to them about the routines, and Commodore setup the CEI4000 deal. Oh,
- but I suppose that doesn't exist either... right Dan?
Typical Jim Drew lying technique: change the subject. (I have never mentioned
the "CEI4000 deal", nor has anyone else in this thread).
Fact: You lied. Whether you talked to Jeff Porter once about your routines
has nothing to do with your claim that you have _licensed_ them to
Commodore and have been incorportated into the CD32 developer material,
which turned out to be totally false.
At least Jim didn't _forget_ this thread. He's _rewriting_ it instead.
Three words you will never hear from Jim Drew: "I was wrong".
Dan
Jay Rymal
Dan E Babcock <D...@ECL.PSU.EDU> wrote:
>-
>- Well, that is interesting since Jeff Porter (along with Carolyn) did the
>- entire CD32 developer presentation in September, which is when I talked
>- to them about the routines, and Commodore setup the CEI4000 deal. Oh,
>- but I suppose that doesn't exist either... right Dan?
>
>Typical Jim Drew lying technique: change the subject. (I have never mentioned
>the "CEI4000 deal", nor has anyone else in this thread).
>
>Fact: You lied. Whether you talked to Jeff Porter once about your routines
>has nothing to do with your claim that you have _licensed_ them to
>Commodore and have been incorportated into the CD32 developer material,
>which turned out to be totally false.
>
>At least Jim didn't _forget_ this thread. He's _rewriting_ it instead.
>Three words you will never hear from Jim Drew: "I was wrong".
>
>Dan
>
Hmm...remember, I'm just an impartial bystander, and you're using a
public forum:
I have been following this silly thread for it's entire lifespan.
I don't recall any mention from JD regarding HIS c2p routines being
used in any C= application... He has said that he has discussed c2p
with members of C= software engineering and he feels that his routines
are faster. (ie his non Akiko based code).
or I could have missed it...it would be much better for your arg.
if you quoted when you're flaming a person, esp. when accusations
of lying are involved...
The way you do it looks like you're raving...(and I don't mean staying
up all night dancing, doing coke while wearing funny clothes...;^)
--
************************** A M I G A 4 0 0 0 / 0 3 0
* Jay Rymal * EMPLANT MacIIci Emulation
* UofT Computer Shop * Apple CD-300 SCSI CD-ROM
************************** <watch for Piccolo gfx card in this space ;^>
Dan E Babcock
- Tue, 28 Dec 93 01:09:54 PDT<19931228.8...@cryo.rain.com>
- In <2flefl$2...@diemen.utas.edu.au>, jmcc...@bruny.cc.utas.edu.au (James
- McCoull) writes:
- Everything contained within EMPLANT is property of myself and Utilities
- Unlimited, Inc. with nothing obtained from outside sources. No ideas
Since this seems to be the week for beating up on Jim Drew, maybe I should
post the couple (small) routines in sybil.library that you stole from
Amax. (Not that I consider it a big deal, it's just funny).
Dan
Dan E Babcock
- In article <2fqj7g$f...@genesis.ait.psu.edu>,
- Dan E Babcock <D...@ECL.PSU.EDU> wrote:
- >-
- >Fact: You lied. Whether you talked to Jeff Porter once about your routines
- >has nothing to do with your claim that you have _licensed_ them to
- >Commodore and have been incorportated into the CD32 developer material,
- >which turned out to be totally false.
- I don't recall any mention from JD regarding HIS c2p routines being
- used in any C= application... He has said that he has discussed c2p
- with members of C= software engineering and he feels that his routines
- are faster. (ie his non Akiko based code).
-
- or I could have missed it...it would be much better for your arg.
- if you quoted when you're flaming a person, esp. when accusations
- of lying are involved...
Right you are. Here tis (which is not the only lie involved, just the
one I refered to):
Newsgroups: comp.sys.amiga.emulations
Path:
news.cac.psu.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!psgrain!percy!news
From: jd...@cryo.rain.com (Jim Drew)
Subject: Re: The best video?!
X-Newssoftware: BBX-UMB 0.37 beta (November 29, 1993)
References: <2f5ihs$k...@diemen.utas.edu.au>
Sender: ne...@percy.rain.com (Jeff Beadles)
Organization: CryoCafe - Portland, OR (503)257-4823
Date: Wed, 22 Dec 1993 10:35:27 GMT
Message-ID: <CIFMr...@percy.rain.com>
Lines: 28
Wed, 22 Dec 93 02:33:49 PDT<19931222.8...@cryo.rain.com>
In <2f5ihs$k...@diemen.utas.edu.au>, jmcc...@bruny.cc.utas.edu.au (James
> Jim this is a blantant lie. To convert a 320x200x256 colour chunky image
> will take of the order of 120ms using the most efficient blitter routine
> possible. Akiko and 020 + no_fast takes only 35ms to do the same job.
>
> Save your time and ours by going to a psychologist and having treatment for
> your condition -- you are a "Pathological Liar". I dont like to be rude in
> such a public forum but if you would ease up a little on the ripe falsehoods
> people might take your beta product (Emplant) a little more seriously.
>
> Regards, James McCoull.
>
Sheesh... maybe you should go to programming school. I am not going to
argue with you about it. The routines exist, Commodore has obtained the
rights to them for use with CD-32 stuff and they have patents pending...
People like you can cause the death of the Amiga with these 'that is not
possible' type of statements...
Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
jd...@cryo.rain.com 790 Lake Havasu Ave #16
GEnie: j.drew2 Lake Havasu City, AZ 86403
BBS #:(602) 453-9767 Orders:(602) 680-9004
Tech #:(602) 680-9234 FAX:(602) 453-6407
I went overkill here, but I didn't want to be accused of taking the
statement "out of context".
- The way you do it looks like you're raving...(and I don't mean staying
- up all night dancing, doing coke while wearing funny clothes...;^)
You're right, of course. I now have the entire thread (from Dec. 12) on
disk and will quote from it liberally.
Dan
Dan E Babcock
- In <CIrup...@gpu.utcc.utoronto.ca> jayr...@gpu.utcc.utoronto.ca writes:
-
- - In article <2fqj7g$f...@genesis.ait.psu.edu>,
- - Dan E Babcock <D...@ECL.PSU.EDU> wrote:
- - >-
- - I don't recall any mention from JD regarding HIS c2p routines being
- - used in any C= application... He has said that he has discussed c2p
- - with members of C= software engineering and he feels that his routines
- - are faster. (ie his non Akiko based code).
- -
As an addendum to my last post, there's an earlier post from Jim Drew that
I overlooked that expresses the lie more explicitly:
Mon, 13 Dec 93 15:55:39 PDT<19931213.8...@cryo.rain.com>
In <1993Dec13....@ida.liu.se>, y91s...@odalix.ida.liu.se (Stefan
Boberg) writes:
> jd...@cryo.rain.com (Jim Drew) writes:
>
> >The Akiko chip is actually slower at converting chunky->planar than our
> >software only routines are.
>
> <cough> <cough>
>
> That's quite a misleading statement. Given the two are running on the
> same processor, there's no way any software routine would be faster than
> the Akiko conversion. Period. (Question: Why the hell would Commodore
> include the corner-turn memory on Akiko otherwise?)
Read it and weap. Because Akiko's bus access is so slow, software
routines can always beat it. Yes, Commodore knows about this.. they are
now using our routines, and you will find them shortly when the new CD-32
developers package comes out...
Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
[cut]
I hope everyone can agree that the meaning contained in the above is
completely unambiguous.
Dan
Jay Rymal
Dan E Babcock <D...@ECL.PSU.EDU> wrote:
>
>Right you are. Here tis (which is not the only lie involved, just the
>one I refered to):
>
>
>argue with you about it. The routines exist, Commodore has obtained the
>rights to them for use with CD-32 stuff and they have patents pending...
>
>People like you can cause the death of the Amiga with these 'that is not
>possible' type of statements...
>
>
>Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
>
ok...so to be even more picky...there is NO mention by Jim that C=
uses HIS c2p code...just that the routines exist, and they use them.
And THEY have patents pending...not UU/JD...
This could be a simple case of not following the thread tho' on my part.
(tho' I thought I was...;^)
Jay Rymal
Dan E Babcock <D...@ECL.PSU.EDU> wrote:
>routines can always beat it. Yes, Commodore knows about this.. they are
>now using our routines, and you will find them shortly when the new CD-32
>developers package comes out...
>
>Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
>[cut]
>
>I hope everyone can agree that the meaning contained in the above is
>completely unambiguous.
>
>Dan
>
Yes..this is better evidence...but I can only still take your word
over his...I will NEVER see cd32 devel docs... Will you?
You're a cd32 developer? C= staff?
Cheers,
J.P. Hillenburg
>In article <2fqm1a$s...@genesis.ait.psu.edu>,
>Dan E Babcock <D...@ECL.PSU.EDU> wrote:
>>
>>Right you are. Here tis (which is not the only lie involved, just the
>>one I refered to):
>>
>>
>>Sheesh... maybe you should go to programming school. I am not going to
>>argue with you about it. The routines exist, Commodore has obtained the
>>rights to them for use with CD-32 stuff and they have patents pending...
>>
>>People like you can cause the death of the Amiga with these 'that is not
>>possible' type of statements...
>>
>>
>>Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
>>Dan
>>
>ok...so to be even more picky...there is NO mention by Jim that C=
>uses HIS c2p code...just that the routines exist, and they use them.
>And THEY have patents pending...not UU/JD...
>This could be a simple case of not following the thread tho' on my part.
It is, indeed. See this:
In <1993Dec13....@ida.liu.se>, y91s...@odalix.ida.liu.se (Stefan
Boberg) writes:
>> jd...@cryo.rain.com (Jim Drew) writes:
>>
>> >The Akiko chip is actually slower at converting chunky->planar than our
>> >software only routines are.
>>
>> <cough> <cough>
>>
>> That's quite a misleading statement. Given the two are running on the
>> same processor, there's no way any software routine would be faster than
>> the Akiko conversion. Period. (Question: Why the hell would Commodore
>> include the corner-turn memory on Akiko otherwise?)
>
>Read it and weap. Because Akiko's bus access is so slow, software
>routines can always beat it. Yes, Commodore knows about this.. they are
^^^ ^^^^^^^^^ ^^^^^ ^^^^^ ^^^^ ^^^^ ^^^
>now using our routines, and you will find them shortly when the new CD-32
^^^ ^^^^^ ^^^ ^^^^^^^^ ^^^ ^^^ ^^^^ ^^^^ ^^^^ ^^^^^^^ ^^^^ ^^^ ^^^ ^^ ^^
>developers package comes out...
^^^^^^^^^^ ^^^^^^^ ^^^^^ ^^^
J.P. Hillenburg
>In article <2fqmnj$s...@genesis.ait.psu.edu>,
>Dan E Babcock <D...@ECL.PSU.EDU> wrote:
>>routines can always beat it. Yes, Commodore knows about this.. they are
>>now using our routines, and you will find them shortly when the new CD-32
>>developers package comes out...
>>
>>Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
>>[cut]
>>
>>I hope everyone can agree that the meaning contained in the above is
>>completely unambiguous.
>>
>>Dan
>>
>Yes..this is better evidence...but I can only still take your word
>over his...I will NEVER see cd32 devel docs... Will you?
>You're a cd32 developer? C= staff?
No, but he is:
>From: k...@mintaka.commodore.com (Ken Dyke - Amiga Gfx Kcd FMV)
>Newsgroups: comp.sys.amiga.emulations
>Subject: Re: The best video?!
>Message-ID: <1993Dec23.1...@cbmnews.commodore.com>
[...]
> A) I know exactly who Jeff Porter is. He's a good friend of mine.
> B) I don't know why Jeff would be dealing with your code, as he has
> nothing to do with software development or developer support for CD32.
> C) I find it odd that Jeff didn't know what you were talking about, either.
> And yes, I asked. He found your claims to be quite amusing.
> D) I'm sure if he had your code, he would have mentioned it to someone in
> engineering who's involved with the CD32.
>
> So, who might I try next?
[...]
There it is...
Chris Gordon
I am a little bit shocked by this whole thread. I see that a flame
war is going strong between a C= employee and Jim Drew, with some 'oh
so helpful' quips from 3rd parties.
I know the net *is* a place for free speach, but can I point out a
few things to the two professionals posting here:
1) The posts by Ken (C= employee) seem to bash Jim Drew quite a bit,
but I can only see the Emplant as a winfall to Commodore to establish
cheap and high quality emulations in all machines (the pending ms-dos
emulation should boost sales considerably). May I just point out to
the Ken that Jim Drew is a stolid amiga supporter as well as
developer, so he is on your side. If you hurt him, you hurt the amiga
and yourself.
2) The posts by Jim Drew are getting critiqued by a C= employee,
and this makes either of the two of you look like raving banshees, and
from the responses not all of them think that Ken is wrong, while
others probably do. You don't need to prove yourself in this way, a
multitasking emulation of a Mac II is a near impossible task, and
anyone who thinks you are an incompetent should keep this little fact
in mind. As in #1, you hurt yourself by hurting the amiga and C=.
3) To all others posting, I don't know what your angle is, perhaps
just to sound off, but if you love the amiga and/or emplant you might
want to lay off on the bashing of either side, as this only makes the
others look bad in the eyes of readers ( if the others are bad, let
their actions prove it, not accusations and flames).
I can only speak for myself as a reader, but it is very disconcerting
seeing this kind of arguing from two heavy hitters on the net. As a
very loyal customer to both companies it was even more so.
If you don't pay attention to any of the above , please at least think
about this:
WHAT ARE YOU GAINING BY THIS DEBATE? WHAT IS IT COSTING YOU,
ESPECIALY IN THE EYES OF CUSTOMERS?
(rhetorical questions, please consider them objectively)
I usually remain a silent reader, and post only when questions are
asked that I can answer or when I have questions, but this was getting
so out of hand I had to step forward.
Please do not respond to this on the net, as it only makes other look
bad. Email me if you think I'm an idiot, or someone else is and you
just want to complain, or you agree, or you want to flame me, etc. I
don't really mind, and everyone has the right to an opionion. I only
want to keep this off the net in the interests of C= and UU, and Ken
and Jim.
Let's let this thread end with this article, and leave it that 'you
are both right', and everyone is happy.
For all other curious about the real facts, hold on a bit and wait
until the products mentioned are out and can be compared, then compare
them yourself.
Sorry, I got a little carried away.
-Chris
mark.blanke
--
Mark S. Blanke - Systems Engineer - AT&T - bla...@hogpa.ho.att.com
All comments and views are mine and do not represent AT&T in any way.
L. Todd Masco
>If you don't pay attention to any of the above , please at least think
>about this:
>
>WHAT ARE YOU GAINING BY THIS DEBATE? WHAT IS IT COSTING YOU,
>ESPECIALY IN THE EYES OF CUSTOMERS?
>
>(rhetorical questions, please consider them objectively)
Intellectual integrity, perhaps?
Just a guess.
--
Todd Masco | "life without caution/ the only worth living
cac...@clinton.com, DoD #269 | love for a man/ love for a woman
SysAdmin, Clinton Group, Inc. | love for the facts/ protectless" - A Rich
Ken Dyke - Amiga Gfx Kcd FMV
>
>Well, that is interesting since Jeff Porter (along with Carolyn) did the
>entire CD32 developer presentation in September, which is when I talked
>to them about the routines, and Commodore setup the CEI4000 deal. Oh,
>but I suppose that doesn't exist either... right Dan?
Hrmm....let's see.....so giving a talk at a Developer conference automatically
makes someone part of developer support? NOT. Oh, and Carolyn didn't know what
you were talking about, either. Stop name dropping and cough up the name of
the person who has your code and ran the tests to convince us to use your
routines. I've mentioned several times that I've talked to everyone in both
Engineering and CATS who might even remotely be involved in CD32 software
development or developer support, and I've yet to find anyone who either knows
about your routines or knows where I might be able to find them.
Mr. Drew, you still have been unable to tell me who I need to get your code
from, short of disassembling it from Emplant myself. You have claimed quite
a few things so far, none of which you have been able to back up with any
hard evidence whatsoever.
Ken Dyke - Amiga Gfx Kcd FMV
>jd...@cryo.rain.com (Jim Drew) writes:
>
>>have been talking about deals with Productivity/Multiscan 256 color
>>modes.
So what is needed is an algorithm that does the absolute minumum number of
chipram accesses, ESPECIALLY on a machine like the CD32 where a display such
as this will effectively kill the machine.
>Ok lets review your two claims in light of this environment.
> Claim #1 - Blitter can convert c2p almost as fast as akiko.
> Claim #2 - 020 on nofastram AGA machine can convert faster than
> akiko.
>
>Review of claim #1 in light of 100% hdisplay contention.
>Errr... major logic flaw jim. An akiko convertor only needs to read and write
>(from chipram -- which is under heavy contention)
>one long word for each long word in the chunky buffer. A blitter convertor?
This is an excellent point. Not only this, but the inner loop of a c2p
converter that uses Akiko can easily fit in the 020's instruction cache so
that the only things chip ram is used for are the source chunky data, the
destination planar data, and a few misc. accesses to fetch the bitplane
pointers.
Demetri
>In article <CIqMz...@percy.rain.com> jd...@cryo.rain.com (Jim Drew) writes:
>>
[Ken D's talks about trying to find someone at C= who can verify what Jim is
saying about the c2p routines deleted...]
>Mr. Drew, you still have been unable to tell me who I need to get your code
>from, short of disassembling it from Emplant myself. You have claimed quite
>a few things so far, none of which you have been able to back up with any
>hard evidence whatsoever.
>
>Kenneth Dyke - Commodore Technology Internet: k...@commodore.com
>Amiga Graphics & Full Motion Video BIX: kcd
Ken, could it be that Jim talked to Chris Green, or maybe Mike Sinz or maybe
another person who left C=?? While all this dribble is intresting, I would
much rather see source code or a demo to demonstrate Jim's point, that would
settle it once and for all. We know both you guys are competent programmers,
or you would both not be where you are today! :)
About that "FMV", can the module handle say 1/4 screen playing some video off
the CDROM, and have the other 3/4 of the screen doing something else (like
maybe a game is playing!?) What I am trying to get at is, how much CPU/DMA
time is the FMV module gonna take up??
-DD
flam
: Well, Phew!!
: -Chris
AMEN!!!!!!
(IM GLAD TO REPOST ALL THAT!)
--
__________________________________________________________
Q. What is the least spoken phrase in the english laguage?
A. Hey isn't that the banjo player's porche?
Fear is just the effect of being too lazy to get excited!!
-Flam (makealotofnoise)
__________________________________________________________
Ken Warm
Bravo, Chris, you speak for more than yourself. Thanks!
Video
> At least Jim didn't _forget_ this thread. He's _rewriting_ it instead.
> Three words you will never hear from Jim Drew: "I was wrong".
Actually that isn't true. Back when the software was adding the SCSI support,
he inadvertantly disabled the mac scsi when messing with other stuff. After I
called his bbs, he happened to be there, and started a sysop chat with me. He
then ADMITTED, that he MADE a mistake....and to my utter disbelief, an update
was readily available the following day. Now whatever beef you have with Mr
Drew, valid or invaild (only you two will know) is none of my business or anyone
elses here not directly conected to Commodre or UU. As far as I am concerned, I
bought a product that functions as advertised, and has more than sufficiant
support.
-Michael Perbix
michael...@satalink.com
mpe...@onix.com
BTW if you have anything to add to this that doesn't concern the public in
general, please reply to me via e-mail.
** UNREGISTERED EVALUATION COPY - PLEASE SUPPORT THE SHAREWARE CONCEPT **
---
| AmiQWK 2.2 | --T-A+G-L-I+N-E--+M-E-A+S-U-R+I-N-G+--G-A+U-G-E--
Ken Dyke - Amiga Gfx Kcd FMV
>but I can only see the Emplant as a winfall to Commodore to establish
>cheap and high quality emulations in all machines (the pending ms-dos
>emulation should boost sales considerably). May I just point out to
>the Ken that Jim Drew is a stolid amiga supporter as well as
>developer, so he is on your side. If you hurt him, you hurt the amiga
>and yourself.
First, I'd like to point out what is (I hope) the painfully obvious --
my posts to Usenet do not reflect the opinions of my employer, Commodore.
They are my own opinions.
I have tried very hard to not bash Jim's product in any way. If I had a
color monitor hooked up to my Amiga and also had a Picasso I'd probably own
an Emplant by now, as there is some Macintosh software that I would like to
run on my Amiga (Sorry, I like my 2024, and resolution wins over color in
this case). Emplant's Mac emulation (from what I've read) appears to be
quite nice, and I won't refute that.
However, what I don't like seeing is people using Commodore's name in any
way they see fit in order to promote their product, especially the way that
Jim has done regarding his chunky to planar conversion code. If he had
claimed something like "Our routines on an A4000 are as fast as Akiko in
CD32" I probably never would have spoken up on the subject, as that isn't
an unreasonable claim to make.
However, Jim claimed (and yes I have the posts to back this up) that his
routines running on a CD32 were faster than using the c2p hardware in
CD32, _and_ that Commodore is going to be including his code in the next
CD32 developer release, _and_ that Commodore is seeking patents on his
code. Why did he claim this? I don't know. I have some personal opinions,
but I'll keep them to myself.
>If you don't pay attention to any of the above , please at least think
>about this:
>
>WHAT ARE YOU GAINING BY THIS DEBATE? WHAT IS IT COSTING YOU,
>ESPECIALY IN THE EYES OF CUSTOMERS?
Maybe getting people to be honest about their products? I'm sick of people
having to bash other people's products in order to promote their own.
>(rhetorical questions, please consider them objectively)
Oops.
-Ken
--
------
Kenneth Dyke - Commodore Technology Internet: k...@commodore.com
Amiga Graphics & Full Motion Video BIX: kcd
All opinions are my own. "Just One Fix..." - Ministry
Nico Francois
message to All:
>> routines can always beat it. Yes, Commodore knows about this.. they are
>> now using our routines, and you will find them shortly when the new CD-32
>> developers package comes out...
>> Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
>> [cut]
>> I hope everyone can agree that the meaning contained in the above is
>> completely unambiguous.
>> Dan
JR> Yes..this is better evidence...but I can only still take your word over
JR> his...I will NEVER see cd32 devel docs... Will you?
Why don't you take Ken Dyke's word ? He _works_ for Commodore. He is one of
the persons _responsible_ for the CD-32 developer stuff.
"Yes, Commodore knows about this.. they are now using our routines, and you
will find them shortly when the new CD-32 developers package comes out..."
This statement is a clear lie. All the evidence presented on this newsgroup
clearly indicates so. You are trying _very_ hard to believe Jim I must say.
But then again, that is his strength. Because he is the Emplant guy, he
_must_ be telling the truth... NOT.
_o
#> Email: ni...@augfl.be
Nico Francois 4 Fido : 2:292/603.10
... I met a man, He was a good man
Peter McGavin
wouldn't work with the raw chunky data in Chip ram, because of
Macintosh memory-mapping problems and other considerations (like
quickdraw rendering performance).
Therefore any blitter- or Akiko-based routine in Emplant would be
further slowed by copying the chunky data to Chip ram first
(contending with video-DMA), and also by the blitter or Akiko reading
it out again (contending with video-DMA again). I'm assuming that
Akiko only has access to Chip ram, and has to contend with video-DMA
in 640x480x8 mode, just like the other custom chips.
Therefore a direct Fast ram to Chip ram CPU-based c2p in Emplant is
even more likely to beat an Akiko-based routine in the same
environment.
--
Peter McGavin. (pet...@maths.grace.cri.nz)
Peter McGavin
640x480x8 c2p routine on a Chip-only 16 MHz 68020 Amiga could possibly
be faster than Akiko on the same hardware.
However, I've been looking back through messages in this thread (as far
back as 20th Dec, before which time all messages have expired at this
site) and I've noticed that nowhere in those posts does Jim Drew claim
or confirm that the c2p converter in Emplant is running on a Chip-only
machine when he compares it with Akiko on an '020.
Is it possible that a CPU-based '020 routine that reads chunky data
from Fast ram and which does longword writes to the Chip raster could
be faster than an equivalent Akiko routine on the same hardware?
After all, I think the Akiko routine would necessarily have to do
extra Chip ram reads of chunky data with associated DMA contention.
Secondly, is it possible that Jim might be considering 2-plane and
4-plane routines, which are possibly ill-suited for Akiko, when he
makes his claims?
--
Peter McGavin. (pet...@maths.grace.cri.nz)
Peter McGavin
>] Just so you know what's going on... I wrote to Jim a few months ago
>] saying I thought I could speed up his c2p. I said I would do it for
>] free (for a better Emplant). He sent me a source code fragment (which
>] he instructed me not to pass on) which did a very slow 8-plane c2p
>] using an enormous lookup table. It included some tricky MMU code for
>] testing for changes to the video RAM and updating only 32-pixels at a
>] time. I substituted some code of my own based around peterm/chunky4
>] in the core of his routine and sent it back to him. At first he
>] didn't believe that it was faster, so I sent him some timing test
>] binaries (640x480 as requested) that convinced him that it was much
>] faster. Later he asked me about 2-plane and 4-plane routines and I
>] obliged by sending him some routines based around Michael van Elst's
>] code but modified to handle packed chunky-pixels using various 4
>] kbyte, 16 kbyte and 256 kbyte tables. I also sent him a copy of your
>] 8-plane blitter algorithm and the 68040 test binary that you sent me
>] some time ago, saying that I thought you had some faster routines.
>] Jim never told me whether he used the routines I sent him or not, but
>] a few days later a new version of the Emplant software came out with
>] much faster c2p. Jim then started his "faster than Akiko" claims. I
>] haven't had any communications since.
In reading back the above I feel I used some stronger terms than I
intended. Let's just say Jim's old, original 8-plane routine was
relatively slow compared with the best ones I've seen. In all
fairness to Jim, I think his MMU algorithm is very efficient and
clever and I did not mean to imply that I suggested any changes to
that part of his routine (only to the c2p core). Also I was surprised
to find that Jim's original 2-plane and 4-plane c2p routines were
faster than any other routines for packed-pixels that I had tested up
to the time he sent them to me. It was only when I tried some
variations of Michael van Elst's 1-pixel/byte routine that I found
anything significantly faster (and passed them back to Jim). I
believe that Jim probably did some comprehensive tests of all the
routines I sent him, and probably improved them. Also I am now not
certain whether I did send James McCoull's blitter algorithm to Jim
(although James did post it to comp.sys.amiga.programmer, and I did
send Jim the 68040 test binary credited to James). Finally, all
credit to Jim for that great product, Emplant!
--
Peter McGavin. (pet...@maths.grace.cri.nz)
Michael van Elst
>After all, I think the Akiko routine would necessarily have to do
>extra Chip ram reads of chunky data with associated DMA contention.
Well, if you choose a machine with FastMem then you have to compare
to such a machine plus Akiko. When using Akiko there are _no_ more
chipmem accesses than without on the same machine. Akiko cycles are
no chipmem cycles.
>Secondly, is it possible that Jim might be considering 2-plane and
>4-plane routines, which are possibly ill-suited for Akiko, when he
>makes his claims?
If you start with one byte per pixel chunky then Akiko does the best
job. It is not necessary to fetch all 8 bitplane longwords from Akiko,
you just fetch the right number and store them in chip memory. You
always have to send Akiko 8 longwords as you have to generate 32
pixels.
Regards,
--
Michael van Elst
Internet: mle...@mpifr-bonn.mpg.de mle...@serpens.rhein.de
"A potential Snark may lurk in every tree."
Jim Drew
In <2fqj7g$f...@genesis.ait.psu.edu>, D...@ECL.PSU.EDU (Dan E Babcock) writes:
> In <CIqMz...@percy.rain.com> jd...@cryo.rain.com writes:
> Typical Jim Drew lying technique: change the subject. (I have never
>mentioned
> the "CEI4000 deal", nor has anyone else in this thread).
>
> Fact: You lied. Whether you talked to Jeff Porter once about your routines
> has nothing to do with your claim that you have _licensed_ them to
> Commodore and have been incorportated into the CD32 developer material,
> which turned out to be totally false.
>
> At least Jim didn't _forget_ this thread. He's _rewriting_ it instead.
> Three words you will never hear from Jim Drew: "I was wrong".
>
> Dan
>
"I was wrong" about a lot of things in my life... so what? This is how
we learn.
I have no idea where *you* get your information from, but a LOT of
routines have been 'licensed' to Commodore in the last few months... but
you won't give a rip either way, so there's no sense talking anything
with you...
Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
Jim Drew
Interesting?? Before you spout off your mouth again, Dan, remember who
was writing the SYBIL disk routines for support with AMAX... ReadySoft.
They are not the exact same routines, as I optimized them...but some of
the code was given to me by Simon Douglas about 3 years ago.
Michael van Elst
>Akiko only has access to Chip ram, and has to contend with video-DMA
>in 640x480x8 mode, just like the other custom chips.
Well, that is wrong. Akiko has _no_ access to Chipmem. You feed
it with 32 pixels (8 longword writes) and read up to 8 longwords
planar data that you have then to write to chipmem. Every data
movement is done by the CPU.
And the Akiko cycles are not subject to ChipMem contention.
>Therefore a direct Fast ram to Chip ram CPU-based c2p in Emplant is
>even more likely to beat an Akiko-based routine in the same
>environment.
No, see above.
With Akiko you just do 32 longword cycles per block of 32 pixel (with
8 bitplanes). A routine that just uses the CPU needs 16 longword cycles
_plus_ everything to do the conversion. This can happen completely
in the caches, together with operations that hide behind the synchronous
chipmem cycles it is possible that such a routine is faster than the
Akiko routine.
However, the EC020 can not do the conversion as fast as it takes
to do the 16 extra longword cycles. It takes a 25MHz 040 to beat a
14MHz EC020 with Akiko and even a 040 system might benefit from
Akiko as the faster c2p routine fills a large part of the 040's cache
while the Akiko routine is just a few words and leaves lots of space
for other tasks.
James McCoull
>Is it possible that a CPU-based '020 routine that reads chunky data
>from Fast ram and which does longword writes to the Chip raster could
>be faster than an equivalent Akiko routine on the same hardware?
>After all, I think the Akiko routine would necessarily have to do
>extra Chip ram reads of chunky data with associated DMA contention.
No it is not possible.
Here is how an akiko routine could work:
;; Convert 32 pixels with akiko. (a0=chunkybuffer, a1=akiko_c2p, a2=planeptr)
;; Dump 8 longs representing 32 adjacent 8bpp chunky pixels to akiko
rept 8
move.l (a0)+,(a1)
endr
;; Dump out a long for each bitplane
move.l (a1),-4*plnsize(a2)
move.l (a1),-3*plnsize(a2)
move.l (a1),-2*plnsize(a2)
move.l (a1),-1*plnsize(a2)
move.l (a1),+0*plnsize(a2)
move.l (a1),+1*plnsize(a2)
move.l (a1),+2*plnsize(a2)
move.l (a1),+3*plnsize(a2)
Beat this with a 14MHz 020 only routine and you are a better person than
I expect can exist.
[assuming you meant akiko on 020+fastram machine].
I'd even go so far as to ay that a 020@14MHz+fastram routine would
have lots of trouble beating an 020@14MHz+akiko+nofastram routine.
The trouble is the 020 can only execute subsequent instructions in the shadow
or writes, it has no datacache or touchloading mechanism, so all read latency
costs you -- there is no escape.
ZZ
James McCoull
>I should also add that Jim once told me that the Emplant emulation
>wouldn't work with the raw chunky data in Chip ram, because of
>Macintosh memory-mapping problems and other considerations (like
>quickdraw rendering performance).
>Therefore any blitter- or Akiko-based routine in Emplant would be
>further slowed by copying the chunky data to Chip ram first
>(contending with video-DMA), and also by the blitter or Akiko reading
>it out again (contending with video-DMA again). I'm assuming that
>Akiko only has access to Chip ram, and has to contend with video-DMA
>in 640x480x8 mode, just like the other custom chips.
Wrong. Akiko isnt a dma engine, its fed by the cpu. Its a 0 waitstate [020]
device. You write a 020 routine that copies longs from fastram to the 0ws
akiko registers and then from here to chipram. That means you use the
chipram databus only once for every long word in the image.
>Therefore a direct Fast ram to Chip ram CPU-based c2p in Emplant is
>even more likely to beat an Akiko-based routine in the same
>environment.
Wrong. Using akiko is writing a direct fastram to chipram convertor.
Ken Dyke - Amiga Gfx Kcd FMV
>
> Ken, could it be that Jim talked to Chris Green, or maybe Mike Sinz or maybe
> another person who left C=?? While all this dribble is intresting, I would
> much rather see source code or a demo to demonstrate Jim's point, that would
> settle it once and for all. We know both you guys are competent programmers,
> or you would both not be where you are today! :)
Sure, it's entirely possible that he did. It still doesn't explain why nobody
around here knows anything about it or why noone can find the code. I know
of at least on SW Engineer here that Jim spoke to his routines about, but Jim
never sent him the code. Oh well.
> About that "FMV", can the module handle say 1/4 screen playing some video off
> the CDROM, and have the other 3/4 of the screen doing something else (like
> maybe a game is playing!?) What I am trying to get at is, how much CPU/DMA
> time is the FMV module gonna take up??
Sure, no problem. Last I checked, full-screen playback chews about 50% of the
CPU. The amount of CPU consumed is pretty much proportional to the amount
of data being fed to the audio and video decoders, so 1/4 screen would most
likely use up a lot less CPU time.
-Ken
--
------
Kenneth Dyke - Commodore Technology Internet: k...@commodore.com
Amiga Graphics & Full Motion Video BIX: kcd
All opinions are my own. "Just One Fix..." - Ministry
Jay Rymal
>Check out what Jay (jayr...@gpu.utcc.utoronto.ca) wrote on 29 Dec 93 in a
>message to All:
>
>
>
> JR> his...I will NEVER see cd32 devel docs... Will you?
>
>Why don't you take Ken Dyke's word ? He _works_ for Commodore. He is one of
>the persons _responsible_ for the CD-32 developer stuff.
I do NOT take anybody's word based on their employment record. I don't take
anybody's word at ALL! I need PROOF.. But I really don't care enough
about this topic to persue it...
>
>"Yes, Commodore knows about this.. they are now using our routines, and you
> will find them shortly when the new CD-32 developers package comes out..."
>
>This statement is a clear lie. All the evidence presented on this newsgroup
>clearly indicates so. You are trying _very_ hard to believe Jim I must say.
>But then again, that is his strength. Because he is the Emplant guy, he
>_must_ be telling the truth... NOT.
>
Sure...I got the above quote..but no I am NOT trying to believe anybody.
I'm trained under many scientific disciplines... as such I don't believe
in many things that are not backed up with solid refereced fact.
I don't believe anything I read on the Internet...do you? ;^)
If there was an independant published source of the codes, copyrights and
such that would be proof...Jim's or Ken's word are no different to me.
They are just a couple of guys...not the EMPLANT GOD and Super Commodore Man!
<grin>
Dan E Babcock
- Fri, 31 Dec 93 04:45:41 PDT<19931231.8...@cryo.rain.com>
- In <2fqklb$f...@genesis.ait.psu.edu>, D...@ECL.PSU.EDU (Dan E Babcock) writes:
- > In <CIqMt...@percy.rain.com> jd...@cryo.rain.com writes:
- >
- > - Tue, 28 Dec 93 01:09:54 PDT<19931228.8...@cryo.rain.com>
- > - In <2flefl$2...@diemen.utas.edu.au>, jmcc...@bruny.cc.utas.edu.au (James
- > - McCoull) writes:
- >
- > - Everything contained within EMPLANT is property of myself and Utilities
- > - Unlimited, Inc. with nothing obtained from outside sources. No ideas
[deleted]
- Interesting?? Before you spout off your mouth again, Dan, remember who
- was writing the SYBIL disk routines for support with AMAX... ReadySoft.
- They are not the exact same routines, as I optimized them...but some of
- the code was given to me by Simon Douglas about 3 years ago.
So, some things contained within Emplant _are_ obtained from outside
sources. :-)
Dan
Dan E Babcock
> > At least Jim didn't _forget_ this thread. He's _rewriting_ it instead.
> > Three words you will never hear from Jim Drew: "I was wrong".
> >
> "I was wrong" about a lot of things in my life... so what? This is how
> we learn.
He said it! Or did he...it was in quotes. :-)
Anyway, you seem to have missed the point.
> I have no idea where *you* get your information from, but a LOT of
> routines have been 'licensed' to Commodore in the last few months... but
> you won't give a rip either way, so there's no sense talking anything
> with you...
Well, gosh, I've been reading the same postings from the Commodore graphics
man Ken Dyke that everyone else has (except you?). (I'll ignore your
gratuitous flame).
Dan
Peter McGavin
way to beat Akiko for 8-plane c2p on any '020-based machine. I should
have paid more attention to Ken Dyke when he said Akiko has no wait
states.
However I'm still not convinced for 2-plane and 4-plane c2p. The Mac
uses packed pixels. If you feed raw packed pixels through Akiko, the
bits come out scrambled. It could take nearly as long to unscramble
them as it would take to do a full CPU-based c2p in the first place
(unless Akiko has another mode of operation that I don't know about).
So you need to unpack or rearrange them first. But again, that could
be nearly as slow as doing the entire c2p with a 256kb lookup table.
Also, unpacked pixels would take longer to feed through Akiko. I
think the best approach is to rearrange the packed pixels initially so
that the results come out of Akiko in the right order for moving
longwords directly into the bitplanes. But I can't see a fast way of
doing that either.
Ignoring DMA contention (which I think is a red-herring) James
mentioned that 320x200x8 c2p takes 35ms with Akiko on an A1200. So
packed-pixel 320x200x4 c2p with Akiko would take about 17.5ms plus
however long it takes to unscramble the bits at the end (guess another
20-30ms). Unpacked 320x200x4 would take roughly 26ms plus whatever
time it takes to unpack the pixels. For the best Akiko-based approach
I would guess about 20+17.5=37.5ms. However the best CPU-based
320x200x4 routine I've seen takes only 21ms with a 256kb table on my
A3000 (35ms is probably an over-estimate for an A1200) and I'm sure
there are faster non-Akiko routines than that. Disclaimer: I don't
have an A1200 or an Akiko to try any of these out.
-------------------------------------------------
Original packed 4-plane chunky data:
0 a3a2a1a0b3b2b1b0 c3c2c1c0d3d2d1d0 e3e2e1e0f3f2f1f0 g3g2g1g0h3h2h1h0
4 i3i2i1i0j3j2j1j0 k3k2k1k0l3l2l1l0 m3m2m1m0n3n2n1n0 o3o2o1o0p3p2p1p0
8 q3q2q1q0r3r2r1r0 s3s2s1s0t3t2t1t0 u3u2u1u0v3v2v1v0 w3w2w1w0x3x2x1x0
12 y3y2y1y0z3z2z1z0 A3A2A1A0B3B2B1B0 C3C2C1C0D3D2D1D0 E3E2E1E0F3F2F1F0
16 G3G2G1G0H3H2H1H0 I3I2I1I0J3J2J1J0 K3K2K1K0L3L2L1L0 M3M2M1M0N3N2N1N0
20 O3O2O1O0P3P2P1P0 Q3Q2Q1Q0R3R2R1R0 S3S2S1S0T3T2T1T0 U3U2U1U0V3V2V1V0
24 W3W2W1W0X3X2X1X0 Y3Y2Y1Y0Z3Z2Z1Z0 !3!2!1!0@3@2@1@0 #3#2#1#0$3$2$1$0
28 %3%2%1%0^3^2^1^0 &3&2&1&0*3*2*1*0 (3(2(1(0)3)2)1)0 +3+2+1+0=3=2=1=0
-------------------------------------------------
Packed 4-plane chunky data after Akiko (no use at all):
0 b0d0f0h0j0l0n0p0 r0t0v0x0z0B0D0F0 H0J0L0N0P0R0T0V0 X0Z0@0$0^0*0)0=0
4 b1d1f1h1j1l1n1p1 r1t1v1x1z1B1D1F1 H1J1L1N1P1R1T1V1 X1Z1@1$1^1*1)1=1
8 b2d2f2h2j2l2n2p2 r2t2v2x2z2B2D2F2 H2J2L2N2P2R2T2V2 X2Z2@2$2^2*2)2=2
12 b3d3f3h3j3l3n3p3 r3t3v3x3z3B3D3F3 H3J3L3N3P3R3T3V3 X3Z3@3$3^3*3)3=3
16 a0c0e0g0i0k0m0o0 q0s0u0w0y0A0C0E0 G0I0K0M0O0Q0S0U0 W0Y0!0#0%0&0(0+0
20 a1c1e1g1i1k1m1o1 q1s1u1w1y1A1C1E1 G1I1K1M1O1Q1S1U1 W1Y1!1#1%1&1(1+1
24 a2c2e2g2i2k2m2o2 q2s2u2w2y2A2C2E2 G2I2K2M2O2Q2S2U2 W2Y2!2#2%2&2(2+2
28 a3c3e3g3i3k3m3o3 q3s3u3w3y3A3C3E3 G3I3K3M3O3Q3S3U3 W3Y3!3#3%3&3(3+3
-------------------------------------------------
This is what we want to get out of Akiko:
0 a0b0c0d0e0f0g0h0 i0j0k0l0m0n0o0p0 q0r0s0t0u0v0w0x0 y0z0A0B0C0D0E0F0
4 a1b1c1d1e1f1g1h1 i1j1k1l1m1n1o1p1 q1r1s1t1u1v1w1x1 y1z1A1B1C1D1E1F1
8 a2b2c2d2e2f2g2h2 i2j2k2l2m2n2o2p2 q2r2s2t2u2v2w2x2 y2z2A2B2C2D2E2F2
12 a3b3c3d3e3f3g3h3 i3j3k3l3m3n3o3p3 q3r3s3t3u3v3w3x3 y3z3A3B3C3D3E3F3
16 G0H0I0J0K0L0M0N0 O0P0Q0R0S0T0U0V0 W0X0Y0Z0!0@0#0$0 %0^0&0*0(0)0+0=0
20 G1H1I1J1K1L1M1N1 O1P1Q1R1S1T1U1V1 W1X1Y1Z1!1@1#1$1 %1^1&1*1(1)1+1=1
24 G2H2I2J2K2L2M2N2 O2P2Q2R2S2T2U2V2 W2X2Y2Z2!2@2#2$2 %2^2&2*2(2)2+2=2
28 G3H3I3J3K3L3M3N3 O3P3Q3R3S3T3U3V3 W3X3Y3Z3!3@3#3$3 %3^3&3*3(3)3+3=3
-------------------------------------------------
So we need to start with:
0 G3G2G1G0a3a2a1a0 H3H2H1H0b3b2b1b0 I3I2I1I0c3c2c1c0 J3J2J1J0d3d2d1d0
4 K3K2K1K0e3e2e1e0 L3L2L1L0f3f2f1f0 M3M2M1M0g3g2g1g0 N3N2N1N0h3h2h1h0
8 O3O2O1O0i3i2i1i0 P3P2P1P0j3j2j1j0 Q3Q2Q1Q0k3k2k1k0 R3R2R1R0l3l2l1l0
12 S3S2S1S0m3m2m1m0 T3T2T1T0n3n2n1n0 U3U2U1U0o3o2o1o0 V3V2V1V0p3p2p1p0
16 W3W2W1W0q3q2q1q0 X3X2X1X0r3r2r1r0 Y3Y2Y1Y0s3s2s1s0 Z3Z2Z1Z0t3t2t1t0
20 !3!2!1!0u3u2u1u0 @3@2@1@0v3v2v1v0 #3#2#1#0w3w2w1w0 $3$2$1$0x3x2x1x0
24 %3%2%1%0y3y2y1y0 ^3^2^1^0z3z2z1z0 &3&2&1&0A3A2A1A0 *3*2*1*0B3B2B1B0
28 (3(2(1(0C3C2C1C0 )3)2)1)0D3D2D1D0 +3+2+1+0E3E2E1E0 =3=2=1=0F3F2F1F0
-------------------------------------------------
--
Peter McGavin. (pet...@maths.grace.cri.nz)
Olaf Barthel
> Thanks, you and Michael van Elst have convinced me that there is no
> way to beat Akiko for 8-plane c2p on any '020-based machine. I should
> have paid more attention to Ken Dyke when he said Akiko has no wait
> states.
>
> However I'm still not convinced for 2-plane and 4-plane c2p. The Mac
> uses packed pixels. If you feed raw packed pixels through Akiko, the
> bits come out scrambled. It could take nearly as long to unscramble
> them as it would take to do a full CPU-based c2p in the first place
> (unless Akiko has another mode of operation that I don't know about).
You do not need to convert eight bits to eight bit planes with
Akiko. Any unwanted bit planes can be ignored, so one would feed
n pixels to the hardware and read back only the plane data wanted.
--
Home: Olaf Barthel | Internet: ol...@sourcery.han.de
Brabeckstrasse 35 |
D-30559 Hannover | Z-NETZ: OLSEN%SOURCER...@UUCP.ZER
------------------------------------------------------------------
Ceci n'est pas une signature.
Peter McGavin
<ol...@sourcery.han.de> wrote:
> You do not need to convert eight bits to eight bit planes with
>Akiko. Any unwanted bit planes can be ignored, so one would feed
>n pixels to the hardware and read back only the plane data wanted.
That's true, but as I tried to explain, the chunky pixels are packed
(i.e, 2 pixels in each byte, a3a2a1a0b3b2b1b0). If you are going to
ignore unwanted bitplanes you have to unpack them first (i.e, 1 pixel
in each byte, --------a3a2a1a0, --------b3b2b1b0), otherwise the
output from Akiko is useless. I can't see a fast enough way to
perform this unpacking. Furthermore, unpacked pixels will take longer
to feed through Akiko (roughly 26ms for 320x200x4) than the fastest
CPU-based c2p that I've seen on my A3000 (21ms).
--
Peter McGavin. (pet...@maths.grace.cri.nz)
Jim Drew
> However, what I don't like seeing is people using Commodore's name in any
> way they see fit in order to promote their product, especially the way that
> Jim has done regarding his chunky to planar conversion code. If he had
> claimed something like "Our routines on an A4000 are as fast as Akiko in
> CD32" I probably never would have spoken up on the subject, as that isn't
> an unreasonable claim to make.
>
> However, Jim claimed (and yes I have the posts to back this up) that his
> routines running on a CD32 were faster than using the c2p hardware in
> CD32, _and_ that Commodore is going to be including his code in the next
> CD32 developer release, _and_ that Commodore is seeking patents on his
> code. Why did he claim this? I don't know. I have some personal opinions,
> but I'll keep them to myself.
carefully read what has been written...
My routines are indeed faster that the Akiko chip used in the CD-32.
Very simple to prove... run our emulation with a benchmark, and run a
CD-32 bench system. Remember, the enviroment that our emulation is in is
really nothing like the enviroment that CD-32 is usually programmed in.
Fast memory, MMU, 030 vs all chip mem. What do you expect? Nobody has
ever bothered to even think about the enviroment difference...
Commodore is not seeking patents for my routines.. that's insane. There
were 11 patents submitted to the US patent office, 8 of which were for
video conversion routines.
Before you flame... please read.
The only thing that could really be disputed was my statement about the
blitter being nearly as fast as Akiko in multiscan/productivity mode. I
still contend that the speed is very close...but it depends on your
definition of close. Akiko is not (in our testing) twice as fast as the
blitter, and depending on what the CPU overhead is, tests vary
dramatically. So, depending on the circumstance, the blitter could look
appealing.
Jim Drew
> Why don't you take Ken Dyke's word ? He _works_ for Commodore. He is one
>of
> the persons _responsible_ for the CD-32 developer stuff.
>
> "Yes, Commodore knows about this.. they are now using our routines, and you
> will find them shortly when the new CD-32 developers package comes out..."
talking to Jeff and Carolyn at WOC Pasadena, I have been dealing only
with Commodore's US management.
Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
Jim Drew
In <2g1ijn$2...@diemen.utas.edu.au>, jmcc...@bruny.cc.utas.edu.au (James
McCoull) writes:
> pet...@kea.grace.cri.nz (Peter McGavin) writes:
>
> >I should also add that Jim once told me that the Emplant emulation
> >wouldn't work with the raw chunky data in Chip ram, because of
> >Macintosh memory-mapping problems and other considerations (like
> >quickdraw rendering performance).
>
> >Therefore any blitter- or Akiko-based routine in Emplant would be
> >further slowed by copying the chunky data to Chip ram first
> >(contending with video-DMA), and also by the blitter or Akiko reading
> >it out again (contending with video-DMA again). I'm assuming that
> >Akiko only has access to Chip ram, and has to contend with video-DMA
> >in 640x480x8 mode, just like the other custom chips.
>
> Wrong. Akiko isnt a dma engine, its fed by the cpu. Its a 0 waitstate
>[020]
> device. You write a 020 routine that copies longs from fastram to the 0ws
> akiko registers and then from here to chipram. That means you use the
> chipram databus only once for every long word in the image.
cycle timing at all? 0ws is not the same as 0 cycle timing. Akiko does
sit on the bus and it is required to wait for access...just like RAM or
ROM does... but this does take time. ..and in an 020 cycle enviroment,
this is not nearly as quick as an 030/040 cycle enviroment.
James McCoull
>Somebody is a bit confused... go back through all of the threads and
>carefully read what has been written...
[Excellent, Dan Babcock could you send me your entire log of posts on this
thread? At last a chance to settle this once and for all].
>The only thing that could really be disputed was my statement about the
>blitter being nearly as fast as Akiko in multiscan/productivity mode.
Nope jim you have changed your claim. Originally it was an expression of
surprise that cbm had bothered with c2p conversion in akiko... because
the blitter was almost as fast. No mention of multiscan/productivity or
the emplant (lots of chipram contention) was made. I'll quote you
exactly when Dan Babcock sends me his archive of your posts.
> I
>still contend that the speed is very close...but it depends on your
>definition of close.
35ms for akiko, versus 120ms for blitter on an A1200+nofastram.
I dont call 35ms versus 120ms close. This isnt even the worst
case comparison. Originally you did not modulate your claim with
any food colouring and as such, this subsequent colouring must be
ignored.
> Akiko is not (in our testing) twice as fast as the
>blitter, and depending on what the CPU overhead is, tests vary
Yeah i get 3x faster.
James McCoull
>> Wrong. Akiko isnt a dma engine, its fed by the cpu. Its a 0 waitstate
>>[020]
>> device. You write a 020 routine that copies longs from fastram to the 0ws
>> akiko registers and then from here to chipram. That means you use the
>> chipram databus only once for every long word in the image.
>
>Huh? Are you saying that the Akiko magically obtains data without any
>cycle timing at all?
May i quote from the above as you had trouble reading it the first time:
"That means you use the chipram databus only once for every long word in the image."
The data comes from the cpu via a write to akiko. Akiko is not on the chipram
data bus, so no chip data bus access is used.
Michael van Elst
>sit on the bus and it is required to wait for access...just like RAM or
>ROM does... but this does take time. ..and in an 020 cycle enviroment,
>this is not nearly as quick as an 030/040 cycle enviroment.
What 030/040 machine with an Akiko chip did you test ? And did you
use static RAM to cut down the 200ns RAM cycle in say the A3000
so the 210ns Akiko cycle is not 'nearly as quick' ?
Inquiring minds want to know.
Dan E Babcock
I first note with amusement that Jim deleted the message's attribution, which
looks to be deliberate since the attribution to Jim's message is intact.
Anyway, the author is k...@mintaka.commodore.com (Ken Dyke - Amiga Gfx Kcd FMV).
- Mon, 3 Jan 94 01:45:45 PDT<19940103.8...@cryo.rain.com>
- > However, what I don't like seeing is people using Commodore's name in any
- > way they see fit in order to promote their product, especially the way that
- > Jim has done regarding his chunky to planar conversion code. If he had
- > claimed something like "Our routines on an A4000 are as fast as Akiko in
- > CD32" I probably never would have spoken up on the subject, as that isn't
- > an unreasonable claim to make.
- > However, Jim claimed (and yes I have the posts to back this up) that his
- > routines running on a CD32 were faster than using the c2p hardware in
- > CD32, _and_ that Commodore is going to be including his code in the next
- > CD32 developer release, _and_ that Commodore is seeking patents on his
- > code. Why did he claim this? I don't know. I have some personal opinions,
- > but I'll keep them to myself.
-
- Somebody is a bit confused... go back through all of the threads and
- carefully read what has been written...
As I predicted, the onset of amnesia. No Jim, we're not confused (I have
the entire "episode" on disk and will email it to anyone who asks) but
somebody is a bit of a liar.
- Fast memory, MMU, 030 vs all chip mem. What do you expect? Nobody has
- ever bothered to even think about the enviroment difference...
On the contrary, some people (e.g. Olaf Barthel) were quite willing to
give you the benefit of the doubt until you specifically stated you
were talking about the same '020 environment. Later, you said you
only meant to include modes with high chip bus contention, but
unfortuntely that made your argument even worse.
- Commodore is not seeking patents for my routines.. that's insane. There
- were 11 patents submitted to the US patent office, 8 of which were for
- video conversion routines.
So, are you seeking a patent for your c-to-p or not?
- Before you flame... please read.
Hey, we agree on something! :)
- The only thing that could really be disputed was my statement about the
- blitter being nearly as fast as Akiko in multiscan/productivity mode. I
- still contend that the speed is very close...but it depends on your
- definition of close. Akiko is not (in our testing) twice as fast as the
- blitter, and depending on what the CPU overhead is, tests vary
- dramatically. So, depending on the circumstance, the blitter could look
- appealing.
Sorry, Jim, that isn't going to work this time. I quote:
Newsgroups: comp.sys.amiga.emulations
Path:
news.cac.psu.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!psgrain!percy!news
From: jd...@cryo.rain.com (Jim Drew)
Subject: Re: The best video?!
X-Newssoftware: BBX-UMB 0.37 beta (November 29, 1993)
References: <1993Dec13....@ida.liu.se>
Sender: ne...@percy.rain.com (News maintainer)
Organization: CryoCafe BBX - Portland, OR USA
Date: Mon, 13 Dec 1993 23:56:50 GMT
Message-ID: <CHzzu...@percy.rain.com>
Lines: 26
Mon, 13 Dec 93 15:55:39 PDT<19931213.8...@cryo.rain.com>
In <1993Dec13....@ida.liu.se>, y91s...@odalix.ida.liu.se (Stefan
Boberg) writes:
> jd...@cryo.rain.com (Jim Drew) writes:
>
> >The Akiko chip is actually slower at converting chunky->planar than our
> >software only routines are.
>
> <cough> <cough>
>
> That's quite a misleading statement. Given the two are running on the
> same processor, there's no way any software routine would be faster than
> the Akiko conversion. Period. (Question: Why the hell would Commodore
> include the corner-turn memory on Akiko otherwise?)
Read it and weap. Because Akiko's bus access is so slow, software
routines can always beat it. Yes, Commodore knows about this.. they are
now using our routines, and you will find them shortly when the new CD-32
developers package comes out...
Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
jd...@cryo.rain.com 790 Lake Havasu Ave #16
GEnie: j.drew2 Lake Havasu City, AZ 86403
BBS #:(602) 453-9767 Orders:(602) 680-9004
Tech #:(602) 680-9234 FAX:(602) 453-6407
Later, we learned among other things:
1. Aikiko's c-to-p registers are 0-wait-state for a 14Mhz '020.
Slow bus access???
2. Commodore does _not_ "know" that statement that isn't true, and not
only are they not using Jim's routines, they don't even have them.
3. I guess that means that the "new CD-32 developers package" (if such
a thing exists) doesn't contain Jim's routines.
How did Jim respond to this "crisis" of his own making? Did he correct his
statements? Did he apologize? Did he stop posting misleading statements and
outright lies? No. No. And No. This isn't a borderline call, folks.
Dan
Nico Francois
All:
>> However, Jim claimed (and yes I have the posts to back this up) that his
>> routines running on a CD32 were faster than using the c2p hardware in
>> CD32, _and_ that Commodore is going to be including his code in the next
>> CD32 developer release, _and_ that Commodore is seeking patents on his
>> code. Why did he claim this? I don't know. I have some personal
>> opinions, but I'll keep them to myself.
JD>
JD> Somebody is a bit confused... go back through all of the threads and
JD> carefully read what has been written...
You really crack me up :) Read on...
JD> My routines are indeed faster that the Akiko chip used in the CD-32.
JD> Very simple to prove... run our emulation with a benchmark, and run a
JD> CD-32 bench system. Remember, the enviroment that our emulation is in
JD> is really nothing like the enviroment that CD-32 is usually programmed
JD> in. Fast memory, MMU, 030 vs all chip mem. What do you expect? Nobody
JD> has ever bothered to even think about the enviroment difference...
Yet it seems _you_ have "bothered to think about the enviroment difference":
--- cut ---
Mon, 13 Dec 93 15:55:39 PDT<19931213.8...@cryo.rain.com>
In <1993Dec13....@ida.liu.se>, y91s...@odalix.ida.liu.se (Stefan
Boberg) writes:
> jd...@cryo.rain.com (Jim Drew) writes:
>
> >The Akiko chip is actually slower at converting chunky->planar than our
> >software only routines are.
>
> <cough> <cough>
>
> That's quite a misleading statement. Given the two are running on the
> same processor, there's no way any software routine would be faster than
> the Akiko conversion. Period. (Question: Why the hell would Commodore
> include the corner-turn memory on Akiko otherwise?)
Read it and weap. Because Akiko's bus access is so slow, software
routines can always beat it. Yes, Commodore knows about this.. they are
now using our routines, and you will find them shortly when the new CD-32
developers package comes out...
Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
--- cut ---
You clearly claim your routines are faster than the Akiko chip. Yes, "running
on the same processor". What processor ? Look at this post:
--- cut ---
>> BZZZT! You are talking about a routine running on an 16 MHz MC68020
>> style CPU which converts an array of pixels of an arbitrary size into
>> planar bitmap data, aren't you?
>
>Yes, that is exactly what I am talking about. In fact, it is rather odd
>that Commodore didn't just use the blitter to do the 'rotate 90' routines
>as it is nearly as fast as Akiko, and was already created.
--- cut ---
Here you even drag the blitter into the picture.
You claim 1) your routines are faster than Akiko and 2) even the blitter is
nearly as fast. And don't talk about the "enviroment difference" as you
clearly confirm this is all on a CD-32 type machine. But of course it is, why
else would Commodore obtain rights to your routines.
JD> Commodore is not seeking patents for my routines.. that's insane.
JD> There were 11 patents submitted to the US patent office, 8 of which were
JD> for video conversion routines.
Now who mentioned Commodore was "seeking patents" ?
--- cut ---
Sheesh... maybe you should go to programming school. I am not going to
argue with you about it. The routines exist, Commodore has obtained the
rights to them for use with CD-32 stuff and they have patents pending...
--- cut ---
Gee, that looks like you again.
JD> Before you flame... please read.
You must be joking! :-) :-)
JD> The only thing that could really be disputed was my statement about the
JD> blitter being nearly as fast as Akiko in multiscan/productivity mode.
JD> I still contend that the speed is very close...but it depends on your
JD> definition of close. Akiko is not (in our testing) twice as fast as
JD> the blitter, and depending on what the CPU overhead is, tests vary
JD> dramatically. So, depending on the circumstance, the blitter could
JD> look appealing.
Do you think we are _stupid_ or what ?
It is unbelievable to see how you are twisting this thread into something
entirely different. I suggest you read this message five times. The things
quoted above were indeed said (typed) by you.
All this -- yet again -- contradicts what you claim now.
_o
#> Email: ni...@augfl.be
Nico Francois 4 Fido : 2:292/603.10
... People they call Romanes go house!
Peter McGavin
Claim #1: The blitter is almost as fast as akiko at c2p conversion.
For 8-plane c2p on a 16MHz 68020, we all know that Akiko is at least 3
times faster. The only way I can see Jim claiming this is if he
argues that using the blitter leaves more CPU cycles free on the Fast
bus, thereby giving a faster mac emulation (but the elapsed c2p time
is still much longer). However that would imply having the chunky
data in Chip ram, drastically slowing quickdraw. For 2-plane and
4-plane c2p in Emplant I have no idea --- neither seems ideal.
Claim #2: The 020 alone can beat an 020+akiko routine.
I do not believe this is true for 8-plane c2p. However it is probably
true for 2-plane and 4-plane c2p in Emplant, given the unpacking
problem I mentioned in a previous post. DMA contention seems to be a
red herring.
Claim #3: The CD32 native developer kit includes his chunky2planar
routines and C= has a patent pending.
This seems to be entirely false, but there is no way I can fully know
either way.
I should also like to mention that Jim appears not to have used the
routines I sent him in the latest Emplant software. (Source: private
mail from James McCoull.)
--
Peter McGavin. (pet...@maths.grace.cri.nz)
James McCoull
>Somebody is a bit confused... go back through all of the threads and
>carefully read what has been written...
[have done, thanks to a kind soul who has been recording the entire thread]
>My routines are indeed faster that the Akiko chip used in the CD-32.
>Very simple to prove... run our emulation with a benchmark, and run a
>CD-32 bench system. Remember, the enviroment that our emulation is in is
>really nothing like the enviroment that CD-32 is usually programmed in.
>Fast memory, MMU, 030 vs all chip mem. What do you expect? Nobody has
>ever bothered to even think about the enviroment difference...
May I quote, from From: jd...@cryo.rain.com (Jim Drew) on 15 Dec 1993.
] > > The Akiko chip is actually slower at converting chunky->planar than our
] > > software only routines are.
] >
] > BZZZT! You are talking about a routine running on an 16 MHz MC68020
] > style CPU which converts an array of pixels of an arbitrary size into
] > planar bitmap data, aren't you?
]
] Yes, that is exactly what I am talking about. In fact, it is rather odd
] that Commodore didn't just use the blitter to do the 'rotate 90' routines
] as it is nearly as fast as Akiko, and was already created.
]
] Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
The claim I dispute is this one. No fool would dispute that its possible
for an A3k or A4k using even a braindead c2p routine to beat a fastram less
CD32.
We are disputing what you said, not what you are dreaming you wish you had
said.
Regards, James McCoull.
Ken Dyke - Amiga Gfx Kcd FMV
>Mon, 3 Jan 94 01:45:45 PDT<19940103.8...@cryo.rain.com>
>> However, what I don't like seeing is people using Commodore's name in any
>> way they see fit in order to promote their product, especially the way that
>> Jim has done regarding his chunky to planar conversion code. If he had
>> claimed something like "Our routines on an A4000 are as fast as Akiko in
>> CD32" I probably never would have spoken up on the subject, as that isn't
>> an unreasonable claim to make.
>>
>> However, Jim claimed (and yes I have the posts to back this up) that his
>> routines running on a CD32 were faster than using the c2p hardware in
>> CD32, _and_ that Commodore is going to be including his code in the next
>> CD32 developer release, _and_ that Commodore is seeking patents on his
>> code. Why did he claim this? I don't know. I have some personal opinions,
>> but I'll keep them to myself.
>
>Somebody is a bit confused... go back through all of the threads and
>carefully read what has been written...
Okay, here's what I read from article <CHzzu...@percy.rain.com> by you
in response to a post by Stefan Boberg:
-----------------------------------------------------------------------
> jd...@cryo.rain.com (Jim Drew) writes:
>
> >The Akiko chip is actually slower at converting chunky->planar than our
> >software only routines are.
>
> <cough> <cough>
>
> That's quite a misleading statement. Given the two are running on the
> same processor, there's no way any software routine would be faster than
> the Akiko conversion. Period. (Question: Why the hell would Commodore
> include the corner-turn memory on Akiko otherwise?)
Read it and weap. Because Akiko's bus access is so slow, software
routines can always beat it. Yes, Commodore knows about this.. they are
now using our routines, and you will find them shortly when the new CD-32
developers package comes out...
-------------------------------------------------------------------------
...and now this...
>My routines are indeed faster that the Akiko chip used in the CD-32.
>Very simple to prove... run our emulation with a benchmark, and run a
>CD-32 bench system. Remember, the enviroment that our emulation is in is
>really nothing like the enviroment that CD-32 is usually programmed in.
>Fast memory, MMU, 030 vs all chip mem. What do you expect? Nobody has
>ever bothered to even think about the enviroment difference...
Well, the above posting that you responded to was pretty explicit I thought.
"Given the two are running on the same processor", coupled with your claim
that Commodore is using your routines in the next upcoming CD-32 developer
release seems to hint pretty strongly that you meant to compare your routines
and Akiko on equal grounds.
If this wasn't the case, then _why_ would Commodore even use the code if
it wasn't faster than using Akiko to do it? It boggles the mind...
>Commodore is not seeking patents for my routines.. that's insane. There
>were 11 patents submitted to the US patent office, 8 of which were for
>video conversion routines.
Then what was this posting made by you in response to James McCoull
referring to? [from <CIFMr...@percy.rain.com>]
------------------------------------------------------------------------
Sheesh... maybe you should go to programming school. I am not going to
argue with you about it. The routines exist, Commodore has obtained the
rights to them for use with CD-32 stuff and they have patents pending...
------------------------------------------------------------------------
Okay, so these routines supposedly exist, yet nobody in Engineering or
CATS knows _anything_ about them. Neither does our lawyer. Neither
do Jeff Porter or Carolyn Scheppner. I do NOT beleive Commodore would
go through the trouble of liscensing or obtaining the rights to use your
code without having consulted someone in either of these two departments
about the code.
Ken Dyke - Amiga Gfx Kcd FMV
>Mon, 3 Jan 94 03:35:23 PDT<19940103.8...@cryo.rain.com>
>In <2g1ijn$2...@diemen.utas.edu.au>, jmcc...@bruny.cc.utas.edu.au (James
>McCoull) writes:
>>
>> Wrong. Akiko isnt a dma engine, its fed by the cpu. Its a 0 waitstate
>>[020]
>> device. You write a 020 routine that copies longs from fastram to the 0ws
>> akiko registers and then from here to chipram. That means you use the
>> chipram databus only once for every long word in the image.
>
>Huh? Are you saying that the Akiko magically obtains data without any
>cycle timing at all? 0ws is not the same as 0 cycle timing. Akiko does
I think James knows this, that's why he said 0 waitstates and not 0 cycles.
>sit on the bus and it is required to wait for access...just like RAM or
Wait for what? Akiko _is_ the bus aribter in CD32 and is hooked directly
up to the 020. Akiko register accesses don't "wait" for anything. They
respond as fast as the 020 can do a bus access. You can't get much faster
than that.
Carl W Howard
>In article <CJ1sE...@percy.rain.com> jd...@cryo.rain.com (Jim Drew) writes:
>>Mon, 3 Jan 94 01:45:45 PDT<19940103.8...@cryo.rain.com>
>>
>>were 11 patents submitted to the US patent office, 8 of which were for
>>video conversion routines.
>
>Then what was this posting made by you in response to James McCoull
>referring to? [from <CIFMr...@percy.rain.com>]
>
>------------------------------------------------------------------------
>rights to them for use with CD-32 stuff and they have patents pending...
Did you stop to think that both these pronouns may have been used to refer
to the routines rather than Commodore? The first obviously was, and at least
I originally read the post as: "and the routines have patents pending".
The above quote by Jim definitely does not imply that Commodore is seeking
any patents for these routines.
Don't you just love the ambiguity of the English language? :)
>-Ken
-Carl
---------------------------------------------------------------------------
Carl W. Howard email-> ca...@mines.utah.edu
System Administrator - College of Mines and Earth Sciences
102 WBB - University of Utah - Salt Lake City, UT 84112 - (801) 581-3485
Patrick Fleming
fest against Jim, please spare the rest of us and carry on via e-mail.
If you must prove your superior programming knowledge publicly, post when
you guys determine who's the winner.
Thanks!
--
Patrick Fleming (w...@apple.com) Apple Computer
--------------------------------------------------------- Inc.
All opinions expressed are NOT necessarily those of Apple
hos...@elpp5.epfl.ch
archive. Amazing.
Yes, please do it. This thread ( 'Jim Drew is a liar', 'I have the whole discussion archived on my disk', etc.) is irritating. Insisting on flaming
Jim is no proof of intelligence. As there is still no
c.s.a.emulations_advocacy, I suggest you stop it now, or go on in alt.flame or
via e-mail.
Armand
Peter McGavin
Howard) wrote:
>[Jim Drew wrote:]
>>argue with you about it. The routines exist, Commodore has obtained the
>>rights to them for use with CD-32 stuff and they have patents pending...
> ^^^^ ^^^^
>Did you stop to think that both these pronouns may have been used to refer
>to the routines rather than Commodore? The first obviously was, and at least
>I originally read the post as: "and the routines have patents pending".
Thanks for pointing that out. I got the wrong idea completely.
--
Peter McGavin. (pet...@maths.grace.cri.nz)
Harri Pesonen
> Dan and James and whoever else who insists on carrying on in this flame
> fest against Jim, please spare the rest of us and carry on via e-mail.
I don't agree. This has been one of the most interesting threads I have
ever read.
> If you must prove your superior programming knowledge publicly, post when
> you guys determine who's the winner.
They are not arguing about a "superior programming knowledge". They are
arguing about Jim Drew's unbelievable claims.
> Thanks!
At least I think that Jim is a pathological liar, what do you think?
> Patrick Fleming (w...@apple.com) Apple Computer
--
Harri Pesonen ha...@elfuerte.fipnet.fi Spellbound with Amiga CD32
I run CD32 at 1280x512 in 256000 colors, if it happens to use that mode!
Stefan Boberg
>Ken Dyke/Commodore writes:
>> However, Jim claimed (and yes I have the posts to back this up) that his
>> routines running on a CD32 were faster than using the c2p hardware in
>> CD32, _and_ that Commodore is going to be including his code in the next
>> CD32 developer release, _and_ that Commodore is seeking patents on his
>> code. Why did he claim this? I don't know. I have some personal opinions,
>> but I'll keep them to myself.
>
>Somebody is a bit confused... go back through all of the threads and
>carefully read what has been written...
You're the one who's confused. It's about time you faced fait accompli
and admitted that you've been found out, and A) lied, B) talked about
things you don't have a clue about or C) both.
>My routines are indeed faster that the Akiko chip used in the CD-32.
>Very simple to prove... run our emulation with a benchmark, and run a
>CD-32 bench system. Remember, the enviroment that our emulation is in is
>really nothing like the enviroment that CD-32 is usually programmed in.
>Fast memory, MMU, 030 vs all chip mem. What do you expect? Nobody has
>ever bothered to even think about the enviroment difference...
I did. In one of my posts you responded to, I said that there was no
way any software chunky->planar conversion routine could be faster than
the Akiko corner-turn memory circuit "given the two are running on the
same processor". In your reply you explained that Akiko was indeed slower
since it's "bus access was so slow".
>Before you flame... please read.
Before you make extravagant claims ... consider the fact that there are
pretty knowledgeable individuals out there reading your posts.
>Jim Drew - CEO - Product Engineer - Utilities Unlimited, Inc.
> jd...@cryo.rain.com 790 Lake Havasu Ave #16
--
Stefan Boberg, Amiga/SEGA/CD32 programmer - Team 17 Software / LhA Devel.
Applied Physics and Electrical Engineering Student, Linkoping University
InterNet: bob...@lysator.liu.se bob...@team17.adsp.sub.org
========== Disclaimer: I only speak for myself, not Team 17. ============