Phase5's A\BOX
Fabio Bizzetti
http://www.phase5.de/news/aboxe.html
Looks like a very nice custom chip (I remember some people that said it was
*impossible* both for development time and costs), and looks like the twin
of the custom device I wished and described (rasterlists), to provide e.g.
hardware windows and much more, through the long-time-ago wished programmable
device to execute rasterlists (that Phase5 calls "display-list"), thus the
capacity to build a custom virtual display chip reprogramming the hardware.
The 128 bits bus and the use of SDRAMs are great, which can provide all the
bandwidth necessary to all these "random-access capable" internal components.
All the rest is as good as the previous, following the philosophy of providing
programmable processors instead of fixed hardware functions, killing thus the
chance that the hardware could become obsolete as design, and allowing easy
and cheap upgradability of the custom chips, simply improving the bandwidth
and the internal clock speed of the custom chip.
Looks exactly as my design, described publicly and privately (to Phase5,
Amiga Technologies and VIScorp) many months ago, then also cut-down and
adapted to AGA as AgaEXTENDER to provide part of these features also to
the old Amigas.
I really hope the A\BOX shows up for real, this can really be the next Amiga.
---------------------------------------
Fabio Bizzetti - bizz...@mbox.vol.it
PS: quoting from the text in http://www.phase5.de/news/aboxe.html:
---
Now, Davy, that's what we call Cool Stuff!
Special thanks to competent individuals such as Dr. Edward L. Hepler who
spent some of their valuable time to enlighten common newsgroup discussions
with valuable comments.
---
Oh well.. considering all the *public* messages I posted on Usenet where
I described this idea/design/technology in detail, it wouldn't have been
that bad to not ignore me. Fortunately I posted them as public messages,
so the people remembers (or eventually can be helped to remember).
Regards and best of luck to Phase5 with the A\BOX.
---------------------------------------
Fabio Bizzetti - bizz...@mbox.vol.it
PhiRatE
: http://www.phase5.de/news/aboxe.html
[Drool-generating description of software-reprogrammable custom-chip]
: Looks exactly as my design, described publicly and privately (to Phase5,
: Amiga Technologies and VIScorp) many months ago, then also cut-down and
: adapted to AGA as AgaEXTENDER to provide part of these features also to
: the old Amigas.
: I really hope the A\BOX shows up for real, this can really be the next Amiga.
Me TOO!!! Now that WOULD kick a PC :))))))))
: Regards and best of luck to Phase5 with the A\BOX.
Yup! I want one of those already!! I reckon with the wizards we have on
the Amiga (Yourself included :) we could think up 1000's of illicite and
awesome uses for that sort of system!
Hmmm, wonder if you would do a self-decompressing screen-system with
that...
<starts drooling>
Richard,
-*--*--*--*--*--*--*--*--*DiGiTaL ViSiOn*--*--*--*--*--*--*--*--*-
__ __
/\ /_/ / /\ /\ / /_ System: Amiga 1200 2/4
/ / / / /\ / / / /_ E-Mail: phi...@sans.vuw.ac.nz
__ __
http://www.sans.vuw.ac.nz/~phirate/ /\ /_/ / /\ /\ / /_
http://www.compkarori.co.nz/amiga/gamelib/ / / / / /\ / / / /_
-*--*--*--*--*--*--*--*-Sarcastic Software-*--*--*--*--*--*--*--*-
Paul Kenneth Egell-Johnsen
Fabio Bizzetti wrote:
>
> http://www.phase5.de/news/aboxe.html
>
> Looks like a very nice custom chip (I remember some people that said it was
> *impossible* both for development time and costs), and looks like the twin
> of the custom device I wished and described (rasterlists), to provide e.g.
> hardware windows and much more, through the long-time-ago wished programmable
> device to execute rasterlists (that Phase5 calls "display-list"), thus the
> capacity to build a custom virtual display chip reprogramming the hardware.
> The 128 bits bus and the use of SDRAMs are great, which can provide all the
> bandwidth necessary to all these "random-access capable" internal components.
> All the rest is as good as the previous, following the philosophy of providing
> programmable processors instead of fixed hardware functions, killing thus the
> chance that the hardware could become obsolete as design, and allowing easy
> and cheap upgradability of the custom chips, simply improving the bandwidth
> and the internal clock speed of the custom chip.
What do you think about the 64 bit to the processor bus? Do you think
that would be upgradeable in a future design. And what about 24 bits to
the DMAs/DACs, isn't the current graphics cards at 128 bit?
And it seems to lack 3d (important) and mpeg (not important). Also I
miss a network card on board... (And a minor point, what about surround
output of sound;) How about HDTV... (needs 1920 by 1200 in 24 bit).
Good points are the PCI bus, the local 16-bit bus (cheap cards).
But, is the whole design scalable i.e. would an OEM be in a position to
use better buses to the different parts, add the sound capabilities etc.
(A lot could be done by PCI cards etc., but it would be more effective
to put it on motherboard silicon (chips)).
Can't hope for everything (perhaps I really want a SGI Reality
Monster;), all in all it seems very promising. Hope we will see it, and
within reasonable time (14 months). (If not it will only be current (at
that time) technology, I believe).
Paul K Egell-Johnsen
mailto:paul...@afrodite.hibu.no
http://afrodite.hibu.no:8001/paulken4/
Chris Handley
In article <3279D7...@afrodite.hibu.no>, paul...@afrodite.hibu.no says...
>What do you think about the 64 bit to the processor bus? Do you think
>that would be upgradeable in a future design. And what about 24 bits to
>the DMAs/DACs, isn't the current graphics cards at 128 bit?
>
>And it seems to lack 3d (important) and mpeg (not important). Also I
It sounded as though MPEG could be done very easily (YUV,4:2:2,etc)... But
I'd rather they write a decent OS before doing stuff like that ^_^
What's that about 3D? Apart from having a RISC processor & some kick-ass
gfx-features that'd make 3D shadind/etc a lot faster, P5 already have a 3D
card for current Amigas (well, soon) - so incorparating some 3D stuff should
be too much of a problem... (relatively speaking that is)
>miss a network card on board... (And a minor point, what about surround
>output of sound;) How about HDTV... (needs 1920 by 1200 in 24 bit).
HDTV????? Next you'll be wanting a DVD drive as standard!
>Good points are the PCI bus, the local 16-bit bus (cheap cards).
<snip>
Well, if they can keep to their stated price-point, I'd be more than happy to
buy one - it really does sound like an Amiga innovation/implementation wise :)
Fingers crossed Phase5 doesn't go belly-up, or muck-up seriously..
--
From Christopher Handley; Email: ela9...@sheffield.ac.uk
-------------------------------------------------------sig v2.50 A---------
A1200/`030/40MHz/4Mb FastRam + PowerStation (SCSI: 540Mb Hd, 2.4 speed CD
drive + SyQuest EZ135). And _soon_ upgrade to a Blizzard 040/40MHz & 8Mb!
-"There are always 2 reasons for doing something: a good reason, and the
real reason." Eg. Commodore's PR reason, and Medi Ali's reason...
Fabio Bizzetti
PhiRatE (phi...@sans.vuw.ac.nz) wrote:
>: http://www.phase5.de/news/aboxe.html
>[Drool-generating description of software-reprogrammable custom-chip]
>: Looks exactly as my design, described publicly and privately (to Phase5,
>: Amiga Technologies and VIScorp) many months ago, then also cut-down and
>: adapted to AGA as AgaEXTENDER to provide part of these features also to
>: the old Amigas.
>: I really hope the A\BOX shows up for real, this can really be the next
>: Amiga.
>Me TOO!!! Now that WOULD kick a PC :))))))))
This custom hardware stays to a PC as a PC stays to a Vic20. 8)
I just hope they aren't so fool to pretend to program it only through APIs:
it doesn't work with programmable/flexible hardware, at all.
It's time to provide two things:
1) Rigid rules for the OS: max protection for applications, but also an
OS legal way to allocate the resources and switch to direct hardware
programming. This was invented with the Amiga 12 years ago, and worked as
long as the Amiga was competitive, as this kind of computers have to be.
2) Hardware compatibility (easy, as I wished/explained many times in the
past it's perfectly possible with such a kind of device: and also cheap);
"abstraction of the hardware" is exactly what would make this device suck.
Nobody thinks that you can run the real games of A\BOX on another hardware..
through the WritePixel(tm) "abstraction of the hardware", it works on SVGA,
perhaps, not on such clever custom hardware.
Jeffrey William Davis
In article <2145.687...@mbox.vol.it>,
Fabio Bizzetti <bizz...@mbox.vol.it> wrote:
>
>
>http://www.phase5.de/news/aboxe.html
>
>Looks like a very nice custom chip (I remember some people that said it was
>*impossible* both for development time and costs), and looks like the twin
>of the custom device I wished and described (rasterlists), to provide e.g.
>hardware windows and much more, through the long-time-ago wished programmable
>device to execute rasterlists (that Phase5 calls "display-list"), thus the
>capacity to build a custom virtual display chip reprogramming the hardware.
>The 128 bits bus and the use of SDRAMs are great, which can provide all the
>bandwidth necessary to all these "random-access capable" internal components.
>All the rest is as good as the previous, following the philosophy of providing
>programmable processors instead of fixed hardware functions, killing thus the
>chance that the hardware could become obsolete as design, and allowing easy
>and cheap upgradability of the custom chips, simply improving the bandwidth
>and the internal clock speed of the custom chip.
I think that the being *impossible* due to development time and costs
only applies to big business - they can't afford to make anything new.
Their bloated overhead costs would kill them. Besides, why would they
make something new and spend the money on it when they could keep
selling the same junk they already have. Big busness would wait for
a company like Phase-5 to develop something, and then buy the company
or the technology; market it, attempt some "cheap" updates, and
eventually kill it. Not unlike Amiga and C= .(sarcasm mode off).
--
============================== ____ =================================
Jeffrey W. Davis (317)451-0503/ / /UNIX: c23...@eng.delcoelect.com
Delco Electronics Corporation/ / /UUCP: deaes!c23jwd
Software/Project Engineer_ / / /GM: 8-322-0503 Mail: CT40A
Fabio Bizzetti
Paul Kenneth Egell-Johnsen (paul...@afrodite.hibu.no) wrote:
>Fabio Bizzetti wrote:
>>
>> http://www.phase5.de/news/aboxe.html
>>
>> Looks like a very nice custom chip (I remember some people that said it was
>> *impossible* both for development time and costs), and looks like the twin
>> of the custom device I wished and described (rasterlists), to provide e.g.
>> hardware windows and much more, through the long-time-ago wished
>> programmable device to execute rasterlists (that Phase5 calls
>> "display-list"), thus the capacity to build a custom virtual display chip
>> reprogramming the hardware. The 128 bits bus and the use of SDRAMs are
>> great, which can provide all the bandwidth necessary to all these
>> "random-access capable" internal components. All the rest is as good as the
>> previous, following the philosophy of providing programmable processors
>> instead of fixed hardware functions, killing thus the chance that the
>> hardware could become obsolete as design, and allowing easy and cheap
>> upgradability of the custom chips, simply improving the bandwidth and the
>> internal clock speed of the custom chip.
>What do you think about the 64 bit to the processor bus?
PPC 603/604 have 64bit databuses anyway, it's the 620 that has a 128bit bus.
>Do you think that would be upgradeable in a future design.
I bet.
>And it seems to lack 3d (important) and mpeg (not important).
It looks fully programmable and flexible: this means that clever coders can
beat every hardware-implemented 3D/MPEG algorithm, those (expecially the
first) become obsolete quickly and make all the rest of the chipset obsolete.
The A\BOX definitely doesn't lack of these features, they're implemented in
a different way, much more flexible and powerful.
>Also I miss a network card on board...
They said ISDN, better than nothing.. but adding e.g. a Ethernet card should
be trivial and absolutely cheap with that PCI bus.
>(And a minor point, what about surround output of sound ;)
They said it has 4 outputs, and being the audio part fully programmable,
you can't wish any better from it.
>How about HDTV... (needs 1920 by 1200 in 24 bit).
Looks like a fully programmable architecture = no problems.
>Good points are the PCI bus, the local 16-bit bus (cheap cards).
>But, is the whole design scalable i.e. would an OEM be in a position to
>use better buses to the different parts, add the sound capabilities etc.
There's nothing to improve in the design, only the clock rates, the bandwidth
and eventually adding extra functions to the chip, which doesn't seem really
necessary since e.g. it already supports YUV and CMYK for video.
>Can't hope for everything (perhaps I really want a SGI Reality
>Monster;), all in all it seems very promising. Hope we will see it, and
>within reasonable time (14 months). (If not it will only be current (at
>that time) technology, I believe).
I dont think so, at all.
Let away the "up to 1.6 GB/sec" bandwidth that is not going to be obsolete
tomorrow: its fully programmable design makes it virtually impossible to
become obsolete, as design, and upgrading it (clock rates and bandwidth,
eventually additional features/functions) looks easy, cheap and effective.
>Paul K Egell-Johnsen
---------------------------------------
Fabio Bizzetti - bizz...@mbox.vol.it
Babbage
In article <2145.687...@mbox.vol.it>, bizz...@mbox.vol.it (Fabio Bizzetti) writes:
>
>
> http://www.phase5.de/news/aboxe.html
>
*SNIP*
> I really hope the A\BOX shows up for real, this can really be the next Amiga.
>
it looks cool
i HOPE for gods sake they make it a PPC + Strong arm machine though
babbage =:)
Marc Forrester
PhiRatE wrote:
> Yup! I want one of those already!! I reckon with the wizards we
> have on the Amiga (Yourself included :) we could think up 1000's
> of illicite and awesome uses for that sort of system!
Er. Illicit? Wouldn't it help the system more if the first owners
just did legitimate things until the market was up to strength?
Byron Montgomerie
Fabio Bizzetti (bizz...@mbox.vol.it) wrote:
: This custom hardware stays to a PC as a PC stays to a Vic20. 8)
^^^^^ ^^^^^
What exactly does that mean? :) Is this hardware available to buy? There
are no apps written for it so you still have the same amiga apps running on
top of different hardware. Where are all the experts who will know how to
program the machine immediately and where are the docs they will use?
: I just hope they aren't so fool to pretend to program it only through APIs:
: it doesn't work with programmable/flexible hardware, at all.
API's are great for everything but games that need to run with more speed
than they can with an API. The thing to consider is, with such vastly
increased speed of the hardware, does the time it takes to call a function
instead of putting data in hardware registers make a lot of difference?
Unless you want a game running so fast it looks like a snowy blur on the
screen it is not going to matter.
: It's time to provide two things:
: 1) Rigid rules for the OS: max protection for applications, but also an
: OS legal way to allocate the resources and switch to direct hardware
: programming. This was invented with the Amiga 12 years ago, and worked as
: long as the Amiga was competitive, as this kind of computers have to be.
I think the standard of games on such hardware would be a bit higher than
that, they would be expected to run at the same time as the os. Network
play is a lot more attractive with faster hardware.
: 2) Hardware compatibility (easy, as I wished/explained many times in the
: past it's perfectly possible with such a kind of device: and also cheap);
: "abstraction of the hardware" is exactly what would make this device suck.
You are lacking in imagination. :) Sounds like you want a $2000 US game
console. :)
: Nobody thinks that you can run the real games of A\BOX on another hardware..
: through the WritePixel(tm) "abstraction of the hardware", it works on SVGA,
: perhaps, not on such clever custom hardware.
Surely you know that hardware abstraction is a bit more involved than that.
:)
Regards,
BM
Marc Forrester
Fabio Bizzetti wrote:
> I really hope the A\BOX shows up for real,
> this can really be the next Amiga.
Certainly looks that way.. Hopefully the AmigaOS clone aspect
won't get legally bogged down with Viscorp. Or whoever. :7
Ian Gledhill
Fabio Bizzetti wrote:
>
> I really hope the A\BOX shows up for real, this can really be the next Amiga.
>
to
stand out from the crowd! This is THE machine to repeat the Amiga's
early
success!!!!
> Regards and best of luck to Phase5 with the A\BOX.
>
My thoughts exactly! I`m right behind you (financially, too, once I've
got
enough money!!!!)
I WANT ONE!!!!! :-)
(Mind you, I'm not sure `A/BOX Format` and `CU A/BOX` have quite the
same ring
to them..... :-) )
Jakob Eriksson
On Fri, 1 Nov 1996, Paul Kenneth Egell-Johnsen wrote:
> that would be upgradeable in a future design. And what about 24 bits to
> the DMAs/DACs, isn't the current graphics cards at 128 bit?
>
Get a clue. No grafx card uses 128 bit color.
Do you know how many colors that would be?
Jakob
dat9...@mds.mdh.se
Byron Montgomerie
Jakob Eriksson (dat9...@mds.mdh.se) wrote:
340280000000000000000000000000000000000 colors. :)
Regards,
BM
Avatar
So how do you pronounce CAIPIRINHA?
Important things first, of course!
-------------------------------------------------------------------
A4000T/040/32Mb, 1.2Gb HD, .8Gb HD, 4xCD, 2 x Printers, 3 Modems...
Novell Connection, 32Mb,100Mhz PCI PC, 2Gb HD, 4xCD, 2Mb PCI Gfx...
Bored yet??? Ever wondered why folks post this crap all the time??
Coming soon... Quotes from the bible.
-------------------------------------------------------------------
Paul Hsieh
PhiRatE wrote:
> : http://www.phase5.de/news/aboxe.html
>
> [Drool-generating description of software-reprogrammable custom-chip]
>
Even if that PC had an MPACT Media-Processor in it? Go check out
http://www.chromatic.com/ and http://www.mpact.com/
--
Paul Hsieh
qed "at" chromatic "dot" com
Graphics Programmer
Chromatic Research
What I say and what my company says are not always the same thing
Thomas van Gulick
Byron Montgomerie (bmon...@morgan.ucs.mun.ca) wrote:
Too bad most people can only differentiate about 3,000,000 colors or so.
Probably even less. I have trouble seeing differences between colours in
HAM-8.
Furthermore I believe the 128 bits has to do with the buswidth, ie faster
graphics, not more colours. More colours seems useless.
Thomas
--
The Rim http://www.cybercomm.nl/~tvg/
The Prancing Pony http://www.dra.nl/~ppinn/
Petrus Canisius College http://www.dra.nl/~pcc/
Jenny Jones
PhiRatE <phi...@sans.vuw.ac.nz> wrote in article
<55bsa1$o...@totara.its.vuw.ac.nz>...
> : http://www.phase5.de/news/aboxe.html
>
> [Drool-generating description of software-reprogrammable custom-chip]
>
> : Looks exactly as my design, described publicly and privately (to
Phase5,
> : Amiga Technologies and VIScorp) many months ago, then also cut-down and
> : adapted to AGA as AgaEXTENDER to provide part of these features also to
> : the old Amigas.
>
> : I really hope the A\BOX shows up for real, this can really be the next
Amiga.
>
> Me TOO!!! Now that WOULD kick a PC :))))))))
>
> <starts drooling>
>
> Richard,
>
Just goes to show what you can do if your aren't limited by IBM 70's design
constraints
Cheers,
Chris Jones
ee6...@ee.surrey.ac.uk
Jakob Eriksson
On 2 Nov 1996, Thomas van Gulick wrote:
> >: Get a clue. No grafx card uses 128 bit color.
> >: Do you know how many colors that would be?
> >340280000000000000000000000000000000000 colors. :)
>
> Furthermore I believe the 128 bits has to do with the buswidth, ie faster
> graphics, not more colours. More colours seems useless.
>
Yes, and didnt the specs of Abox tell it was 128 bits bandwidth?
Jakob
Paul Hsieh
Jakob Eriksson wrote:
> On Fri, 1 Nov 1996, Paul Kenneth Egell-Johnsen wrote:
> > that would be upgradeable in a future design. And what about 24 bits
> > to the DMAs/DACs, isn't the current graphics cards at 128 bit?
>
> Do you know how many colors that would be?
He's probably talking about the width of the data path for the blitter,
not the color depth. You get a clue.
--
Paul Hsieh
qed "at" chromatic "dot" com
http://www.geocities.com/SiliconValley/9498
Philip Kaulfuss
Jakob Eriksson (dat9...@mds.mdh.se) wrote:
: > that would be upgradeable in a future design. And what about 24 bits to
: > the DMAs/DACs, isn't the current graphics cards at 128 bit?
: Get a clue. No grafx card uses 128 bit color.
: Do you know how many colors that would be?
An awful lot. =) There is very little need to go beyond 24-bit colour (why does
PNG support 48-bit colour when it is indistinguishable to the human eye?).
Anyhow, I think he means 128-bit architecture (as is the Cybervision 64-bit)
--
,-----------------------------------------------------------.
:-: Philip Kaulfuss :---------------------------------------:
:-: ph...@boehme.demon.co.uk :-------------------------------:
:-: PhilK in UnderNet #AmigaCafe :--------------------------:
:-: http://www.boehme.demon.co.uk :-------------------------:
:-: Gfx artist for the freeware gorefest 'Urban Massacre' :-:
`-----------------------------------------------------------'
Frank Wille
Avatar wrote:
> So how do you pronounce CAIPIRINHA?
>
> Important things first, of course!
Sounds portuguese in my ears. Maybe "CAYPIRINYA"? :)
-- _
_ // Frank EMail: fr...@phoenix.owl.de
\X/ IRC: Phx @ #amiga(ger)
Mike Redrobe
Hi, Fabio Bizzetti , on 01-Nov-96 17:37:47 you scribbled....
>This custom hardware stays to a PC as a PC stays to a Vic20. 8)
Indeed, time for another leap forward...
>I just hope they aren't so fool to pretend to program it only through APIs:
>it doesn't work with programmable/flexible hardware, at all.
no comment
>It's time to provide two things:
>1) Rigid rules for the OS: max protection for applications, but also an
> OS legal way to allocate the resources and switch to direct hardware
> programming. This was invented with the Amiga 12 years ago, and worked as
> long as the Amiga was competitive, as this kind of computers have to be.
Yes, we have had all this already, but provide people with forbid() and
they'll do their game inside it. Why would they allocate resources instead?
It could have been doen this way for 80% of amiga games, but wasn't, why would
the A/Box be different?
(I'm surprised those words came from you Fabio)
As to it ever working, even when the amiga was "competitive", I didn't see many
games keeping the OS AT ALL (e.g. just taking over the view)
>2) Hardware compatibility (easy, as I wished/explained many times in the
> past it's perfectly possible with such a kind of device: and also cheap);
> "abstraction of the hardware" is exactly what would make this device suck.
compatibility to what? I hope you don't mean AGA ?
>Nobody thinks that you can run the real games of A\BOX on another hardware..
>through the WritePixel(tm) "abstraction of the hardware", it works on SVGA,
>perhaps, not on such clever custom hardware.
well not WritePixel, but maybe BltBitMap ;)
Mike
--
---------------------------------------------------------------------------
Mike Redrobe - Mi...@Redrobe.demon.co.uk MikeRR on #Amiga
http://www.Redrobe.demon.co.uk
---------------------------------------------------------------------------
Volker Barthelmann
Byron Montgomerie (bmon...@morgan.ucs.mun.ca) wrote:
:
: : Get a clue. No grafx card uses 128 bit color.
: : Do you know how many colors that would be?
: 340280000000000000000000000000000000000 colors. :)
You forgot a few colors - 2366920938463463374607431768211456 to
be precise. :-)
Volker
Kenneth C. Nilsen
>Byron Montgomerie (bmon...@morgan.ucs.mun.ca) wrote:
>>Jakob Eriksson (dat9...@mds.mdh.se) wrote:
>>: > that would be upgradeable in a future design. And what about 24 bits to
>>: > the DMAs/DACs, isn't the current graphics cards at 128 bit?
>>: Get a clue. No grafx card uses 128 bit color.
>Probably even less. I have trouble seeing differences between colours in
>HAM-8.
I agree. A TV or Monitor can't display much more than what's represented in a
24-bit color resolution anyway. The human eye has the same situation. More
than 24-bit colors is wasted speed and money (as with 16-bit sound. The ear
has difficulties to distinguish between 16-bit and 24-bit sounds). If not
hardware limitation there is for sure biologically limitations.
>Furthermore I believe the 128 bits has to do with the buswidth, ie faster
>graphics, not more colours. More colours seems useless.
That is correct. There is no such thing as a 128 bit color card. The 128 bits
cards uses only 24-bit colors. The rest are control bits and data bits to
achieve larger transfer rates on the bus. And that is a plus though.
---
Kenneth C. Nilsen (kenn...@IDGonline.no) http://*** new comming up ***
Flemming Steffensen
Avatar wrote in comp.sys.amiga.programmer about "Re: Phase5's A\BOX":
A> So how do you pronounce CAIPIRINHA?
I belive in a japanese way: Ca I Pi Ri N Ha.
(English: CaiPiRinha or CaiPiRinwa)
However, what does it mean?
Old amiga-chips had names that indicated what they did!
--Flemming Steffensen
.: | FIRST Production -ETD 020-
.::: | Homepage: http://www.dannug.dk/~fsteff/ CATS's
.;' :: | INTERNET: fst...@dannug.dk |\ _,,,---,,_sleeping!
.;' :: | AMIGANET: 39:140/146.17 ZZZzz /,`.-'`' -. ;-;;,_
.::::::::: | FIDO-NET: 2:238/188.17 |,4- ) )-,_; ,\ ( `'-'
.::. .::. | '---''(_/--' `-'\_)
Using IS08859-1? Do you see © as copyright, ÷ as division and ½ as 1/2?
Michael van Elst
Philip Kaulfuss <ph...@boehme.demon.co.uk> writes:
>An awful lot. =) There is very little need to go beyond 24-bit colour (why does
>PNG support 48-bit colour when it is indistinguishable to the human eye?).
It isn't. :) 24-bit is _not_ enough, mainly because 8-bit per primary
color is not enough. But you are right that there is little need to
go beyond 24-bit color. Most people are satisfied with 24-bit as
for most images (but not all) you couldn't see a difference and
the common display technology can't even reproduce the 24-bit colors
precisely.
>Anyhow, I think he means 128-bit architecture (as is the Cybervision 64-bit)
Correct.
--
Michael van Elst
Internet: mle...@serpens.swb.de
"A potential Snark may lurk in every tree."
Byron Montgomerie
Juergen "Rally" Fischer (fisc...@Informatik.TU-Muenchen.DE) wrote:
: > 340280000000000000000000000000000000000 colors. :)
^
: wrong! all numbers 2^n got 2,4,6 or 8 as last char ;)
What's 1 Meg? :) 1024000. :) For that matter what's 2^0? :)
: unless we have robots playing games in future, 24bit will be
: suficient forever. as well as 16bit sound...
Sure, it may get refined to a better distribution though, or even something
other than RGB in hardware.
Regards,
BM
Byron Montgomerie
Byron Montgomerie (bmon...@morgan.ucs.mun.ca) wrote:
: Juergen "Rally" Fischer (fisc...@Informatik.TU-Muenchen.DE) wrote:
: : > 340280000000000000000000000000000000000 colors. :)
: : wrong! all numbers 2^n got 2,4,6 or 8 as last char ;)
: What's 1 Meg? :) 1024000. :) For that matter what's 2^0? :)
That's wrong. :)
Regards,
BM
gau
On 3 Nov 1996, Michael van Elst wrote:
> Philip Kaulfuss <ph...@boehme.demon.co.uk> writes:
>
> It isn't. :) 24-bit is _not_ enough, mainly because 8-bit per primary
Eight-bits per primary goes beyond the eye's ability to differentiate
(geez this is *old* published information too).
==============================================================================
Gau of the Veldt
"Draped in monster hides, eyes shining with intelligence.
A youth surviving against all odds..."
===== Email: g...@netbistro.com ===== WWW: http://www.netbistro.com/~gau/ =====
Andreas Fredriksson
Philip Kaulfuss (ph...@boehme.demon.co.uk) wrote:
:
: An awful lot. =) There is very little need to go beyond 24-bit colour (why does
: PNG support 48-bit colour when it is indistinguishable to the human eye?).
PNG is supposed to be more of a data standard than a picture standard. 16-bit PNG's is very useful when creating
so-called heightfields (geometrical height data) for raytracers like POV-Ray for example, since the heights can be specified
with more accuracy.
---
Andreas Fredriksson :: Dep/Stellar :: d...@canit.se :: www.canit.se/~dep
Manuel Lemos
>Avatar wrote:
>> So how do you pronounce CAIPIRINHA?
>>
>> Important things first, of course!
>Sounds portuguese in my ears. Maybe "CAYPIRINYA"? :)
CAIPIRINHA is a Brazilian hot booz!
You may pronounce it reading the way you typed, but make the sound of last
Y much shorter by pushing your whole tongue (rather than just the front)
against the top your mouth.
Manuel Lemos
---
MICHAEL F. SMITH
Frank Wille (fr...@phoenix.owl.de) wrote:
: Avatar wrote:
: > So how do you pronounce CAIPIRINHA?
: >
: > Important things first, of course!
: Sounds portuguese in my ears. Maybe "CAYPIRINYA"? :)
Or maybe kay-per-een-uh. What does it stand for, anyway?
_
--------------------+ "][ p|-|3aR B!11 ga|3Z!" +-------------------------
A1200/'020/'881/10/ | __ |Team Amiga
120/_CLOCK_/UPS/ | --==>Mike Smith<==-- /// +-------------------------
1084SD-1/1080/1702 | msm...@gmu.edu __ /// |800 watts of stereo power
--------------------+-------------------+\\\/// |and 18 speakers!
http://mason.gmu.edu/~msmithm/index.html| \XX/ +-------------------------
----------------------------------------+---------+Naked Fringe!
Philip Kaulfuss
Ian Gledhill (im...@aber.ac.uk) wrote:
: (Mind you, I'm not sure `A/BOX Format` and `CU A/BOX` have quite the
: same ring
: to them..... :-) )
No doubt they'll continue under the same name if they decide to actually support
the next gen Amigas. =)
Dr. Peter Kittel
In article <N.110296....@dynamic202.i-way.co.uk> ava...@patrol.i-way.co.uk (Avatar) writes:
>
>So how do you pronounce CAIPIRINHA?
Kye-pee-rin-ya
--
Best Regards, Dr. Peter Kittel // http://www.pios.de
Private Site in Frankfurt, Germany \X/ office: pet...@pios.de
Mans Engman
Juergen "Rally" Fischer wrote:
>> : Do you know how many colors that would be?
>>
>> 340280000000000000000000000000000000000 colors. :)
>wrong! all numbers 2^n got 2,4,6 or 8 as last char ;)
Right! But also, all numbers 2^(2^n), n>=2, ends with 6. So,
the correct answer is 340280000000000000000000000000000000006.
/Mans (.sig being recompiled)
Alfred Fent
|> Get a clue. No grafx card uses 128 bit color.
|> Do you know how many colors that would be?
2^128 of course...
SCNR ;-)
Alfred
--
-------------------------------------------------------------------------------
- Lazlo's Chinese Relativity Axiom: No matter how great your triumphs or how -
- tragic your defeats - approximately one billion Chinese couldn't care less. -
- Alfred Fent -- fe...@fmi.uni-passau.de -- http://www.uni-passau.de/~fent -
-------------------------------------------------------------------------------
Babbage
> > that would be upgradeable in a future design. And what about 24 bits to
> > the DMAs/DACs, isn't the current graphics cards at 128 bit?
> >
>
> Do you know how many colors that would be?
>
but thats only cause it has several 24bit colour values in there
and room for a nice alpha channel
(See Computer Graphics, principles and practise for more info)
But to 1st poster, 128 bits
!= 128bit colour, but the fact its processing more at once,
several 24bits at once for instance
babbage =:)
Babbage
> PPC 603/604 have 64bit databuses anyway, it's the 620 that has a 128bit bus.
yeh and PHASE5
PLEASE PLEASE PLEASE
slap a strong arm in there as well!
That would totally kick ass then =:)
> >And it seems to lack 3d (important) and mpeg (not important).
slap a strong arm in there and let it do that as coprocessor stuff
> >Also I miss a network card on board...
> They said ISDN, better than nothing..
yeh but why bother
Getting a 56k modem will be alot cheaper (dont have installation
costs etc.) and be almost the same speed youl get.
How about one of the newer 6meg a second down a normal
phone line technologies =:)
http://www.gte.com/Adsl/About/about.htm
> but adding e.g. a Ethernet card should
> be trivial and absolutely cheap with that PCI bus.
ethernet is slow though
fastethernet at least
or why not an ATM connection =:)
> >(And a minor point, what about surround output of sound ;)
> They said it has 4 outputs, and being the audio part fully programmable,
> you can't wish any better from it.
5 channel would be better
thats propper surround sound
(one in each corner and a central speaker)
And it would be nice if you could pan outputs between
channels as well =:) (Though they will probably do this
with the DSP or whatever, but that involved data duplication then)
> >How about HDTV... (needs 1920 by 1200 in 24 bit).
> Looks like a fully programmable architecture = no problems.
I want 4000x4000 32bit =:)
whats that, 62.5megs of screen ram needed?
> >But, is the whole design scalable i.e. would an OEM be in a position to
> >use better buses to the different parts, add the sound capabilities etc.
> There's nothing to improve in the design,
theres not much to improve in the design you mean =:)
> only the clock rates, the bandwidth
> and eventually adding extra functions to the chip, which doesn't seem really
> necessary since e.g. it already supports YUV and CMYK for video.
I wouldnt mind seeing a new colour format as well, 1 value for one colour
specified by its offset along the visible spectrum =:)
> I dont think so, at all.
> Let away the "up to 1.6 GB/sec" bandwidth that is not going to be obsolete
> tomorrow:
yeh
bit better than my 7meg a second max trasnfer to chip on my 1200 ;)
Hows the ram gunan keep up with everything though!
> its fully programmable design makes it virtually impossible to
> become obsolete, as design, and upgrading it (clock rates and bandwidth,
> eventually additional features/functions) looks easy, cheap and effective.
yeh
i want one
looks cool doesn it
I still think they need to put a strong arm in there
(specially considering its power and price)
keeping the PPC as well of course
babbage =:)
Babbage
> >340280000000000000000000000000000000000 colors. :)
>
> Too bad most people can only differentiate about 3,000,000 colors or so.
> HAM-8.
>
> graphics, not more colours. More colours seems useless.
and from a HCI course I did,
humans can only differenciate between around 8000 different colours
at max (and thats if your recognition is pretty hot)
at any one time!
babbage =:)
Johan Rönnblom
Paul Hsieh wrote:
>
> PhiRatE wrote:
> > : http://www.phase5.de/news/aboxe.html
> >
> > [Drool-generating description of software-reprogrammable custom-chip]
> >
>
> Even if that PC had an MPACT Media-Processor in it? Go check out
> http://www.chromatic.com/ and http://www.mpact.com/
Yes, even then IMHO. The only thing this MPACT thingy offers over the A\Box is the use of
RDram, which is supposedly faster than the SDram used in the A\Box. Although the figures
given are up to 600MB/s for RDram, and up to 1300MB/s for SDram, so I don't know.
Does anyone know more about this? I mean, if RDram shows to be better, and it becomes the
standard on PCs (making it affordable), Phase 5 better start looking at how to support
it..
OTOH, what does the A\Box offer over the MPACT?
Programmable - won't be outdated as soon as MPEG and 1,000,000 50-pixel, textured,
Gouraud-shaded, Z-buffered, perspective corrected, bi-linear filtered,
alpha blended with fog triangles per second goes out of fashion.
Unified memory access - means your computer won't complain about 'not enough memory'
when it in fact has lots unused mamory available - but of the wrong kind.
Hardware windows - this feature really sound interesting. And you might even be able to do
something *useful* with it.
Different colour description modes - I'm sure people will come up with *lots* of uses for
this.
/Johan Rönnblom, Team Amiga
Johan Rönnblom
Johan Rönnblom wrote:
>
> Paul Hsieh wrote:
> >
> > PhiRatE wrote:
> > > : http://www.phase5.de/news/aboxe.html
> > >
> > > [Drool-generating description of software-reprogrammable custom-chip]
> > >
> > > [...] Now that WOULD kick a PC :))))))))
> >
> > Even if that PC had an MPACT Media-Processor in it? Go check out
> > http://www.chromatic.com/ and http://www.mpact.com/
Sorry, I made an error in my last post, I'll try again..
Yes, even then IMHO. The only thing this MPACT thingy offers over the A\Box is the use of
RDram, which is supposedly faster than the SDram used in the A\Box. Although the figures
given are up to 600MB/s for RDram, and up to 1600MB/s for SDram, so I don't know.
Also some figure of 1300 MB/s is mentioned at the chromatic site, I don't know exactly
what it means though..
Does anyone know more about this? I mean, if RDram shows to be better, and it becomes the
standard on PCs (making it affordable), Phase 5 better start looking at how to support
it..
OTOH, what does the A\Box offer over the MPACT?
Programmable - won't be outdated as soon as MPEG and 1,000,000 50-pixel, textured,
Gouraud-shaded, Z-buffered, perspective corrected, bi-linear filtered,
alpha blended with fog triangles per second goes out of fashion.
Unified memory access - means your computer won't complain about 'not enough memory' when
it in fact has lots of unused memory available - but of the wrong kind.
Hardware windows - this feature really sounds interesting. And you might even be able to do
something *useful* with it.
Different colour description modes - I'm sure people will come up with *lots* of uses for
this.
Besides - the MPACT is only a video card, while the A\Box is a computer, so no matter how
good the MPACT would be, it wouldn't fix the crappy overall design of PCs.
/Johan Rönnblom, Team Amiga
Fabio Bizzetti
>> : Do you know how many colors that would be?
>>
>> 340280000000000000000000000000000000000 colors. :)
>wrong! all numbers 2^n got 2,4,6 or 8 as last char ;)
wrong, if n=0 then the last char is 1.. <grin> O;)
>unless we have robots playing games in future, 24bit will be
>suficient forever. as well as 16bit sound...
Yes, but in the pure spirit of tricks (as explained in the AgaEXTENDER doc)
it would be very useful to have the custom color format you wish, even wasting
some bits in some cases, to speed up the software part (e.g. bits reserved
for fixed point, etc..).
---------------------------------------
Fabio Bizzetti - bizz...@mbox.vol.it
Fabio Bizzetti
Ian Gledhill (im...@aber.ac.uk) wrote:
>Fabio Bizzetti wrote:
>>
>> I really hope the A\BOX shows up for real, this can really be the next
>> Amiga.
>>
>Quite right! IMHO this encapsulates the original idea of the Amiga....
>to stand out from the crowd! This is THE machine to repeat the Amiga's
>early success!!!!
Indeed!
I think I will be one of the pioneers in A\BOX games hardware banging <grin> :)
In the while, I've some PowerPC manuals to study to warm those custom chips. :D
Magnus E. Krisell
Byron Montgomerie wrote:
> >
> : Get a clue. No grafx card uses 128 bit color.
> : Do you know how many colors that would be?
>
> 340280000000000000000000000000000000000 colors. :)
>
340282366920938463463374607431768211456 colors :) :) :)
Magnus
Paul Kenneth Egell-Johnsen
Noah I Rosenberg wrote:
> I thought BeBox was an interesting new concept in computers. But
> this, this is EXCITING.
Yes, you are onto something, this is better than BeBox and with all the
'hype' around BeBox and it's capabilities, perhaps we just should enjoy.
(Regards to all other posts which are negative/pessimistic, including my
own;)
Paul K Egell-Johnsen
mailto:paul...@afrodite.hibu.no
http://afrodite.hibu.no:8001/paulken4/
Paul Kenneth Egell-Johnsen
Jakob Eriksson wrote:
>
> On Fri, 1 Nov 1996, Paul Kenneth Egell-Johnsen wrote:
> > that would be upgradeable in a future design. And what about 24 bits to
> > the DMAs/DACs, isn't the current graphics cards at 128 bit?
> >
>
> Do you know how many colors that would be?
I was discussing bus width, not color depth.
(BTW: SGI does 48 bit color, scanners 36 bit, the reason beeing that
when you work with filters etc. a lot of noise may be introduced, when
downsampling 48 bits to 24 bit, then the problems will be avoided, refer
to sound programs using 32 bits internally, just to keep on playing
clean sound.
Conclusion, someone probably will use 128 bit for color depth if they
can find the hardware to do it fast enough.
BTW: ADPro uses 64 bit internally, presumably for the same reasons as
stated above. But I where referring to the bus...)
Paul Kenneth Egell-Johnsen
Jakob Eriksson wrote:
> > Furthermore I believe the 128 bits has to do with the buswidth, ie faster
> > graphics, not more colours. More colours seems useless.
> >
>
> Yes, and didnt the specs of Abox tell it was 128 bits bandwidth?
> Jakob
128 bit for the whole system, 24 bit to the video system, 64 bits to the
processor. The 128 bit is only for the RAM (it seems from the docs).
Roger Wong
bab...@dmu.ac.uk (Babbage) wrote:
>and from a HCI course I did,
>humans can only differenciate between around 8000 different colours
>at max (and thats if your recognition is pretty hot)
>at any one time!
Babbage,
On a computer screen, a person can distinguish 16 million colors. Your
monitor displays red, green, and blue. Your eye sees each of these
primary colors separately. Each color only has 256 degrees of
intensity, so it isn't a big feat to differentiate between them.
Michael Abrash says "It's the brain that does the amazing part; the
16,000,000-plus color capability actually comes not from extraordinary
sensitivity to the eye, but rather from the brain's ability to
distinguish between all the mixes of 256 levels of each of three
primaries.
On a reflective medium such as paper, people can distinguish
between even more. At the Jet Propulsion Lab in the 70's, the color
research people came up with a way to print more than 50,000,000
precise colors on paper. They printed words out in various colors,
each one on a background that was only one color index away from the
word's color. No one had any trouble reading any of the words; the
human eye is both sensitive to color degradations and good at edge
detection.
Further reading: Michael Abrash, 1995. Zen of Graphics Programming.
Coriolis Group Books. ISBN 1-883577-08. I picked up my copy for $5.00
at a discount book store during a vacation in Texas.
Roger Wong's
THE UNOFFICIAL C&C STRATEGY FAQ
http://www10.torget.se/temple
Johan Rönnblom
Byron Montgomerie wrote:
> : Too bad most people can only differentiate about 3,000,000 colors or so.
> : Probably even less. I have trouble seeing differences between colours in
> : HAM-8.
>
> develop a bit more sensitivity to color than most people, it is all a matter
> of training your brain to distinguish between colors. 24 bit is good enough
> for me, more at a time is all I require, but it doesn't cover the spectrum
> of the human eye, just has the right number of colors, not the distribution.
> RGB itself can't display all the colors the eye can see so it doesn't really
> matter. A different distribution of 24 bit color would be a better
> solution than generating more shades of yellow with 32 bit color. :)
And the A\Box is capable of doing that! It really has everything...
It's a shame that today's monitors won't make a difference with this 'problem' :)
/Johan Rönnblom, Team Amiga
Paul Kenneth Egell-Johnsen
Philip Kaulfuss wrote:
> An awful lot. =) There is very little need to go beyond 24-bit colour (why does
> PNG support 48-bit colour when it is indistinguishable to the human eye?).
I believe it's because scanners scan in 36 bit, SGI uses 48 bit for
colors (check out the specs at their page). And my theory is that
imageprocessing may degrade color information in some cases, thus the
need for more bits to do the processing and then downsample it to 32
bits for display).
PNG Should've supportet 64 bit, 16 bit red, 16 bit green, 16 bit blue
and 16 bit for transparancy (alpha).
> Anyhow, I think he means 128-bit architecture (as is the Cybervision 64-bit)
Yes, the Phase 5 doucument says 24 bits to the video sub-systems.
Michael van Elst
gau <g...@vortex.netbistro.com> writes:
>On 3 Nov 1996, Michael van Elst wrote:
>> Philip Kaulfuss <ph...@boehme.demon.co.uk> writes:
>>
>> It isn't. :) 24-bit is _not_ enough, mainly because 8-bit per primary
>Eight-bits per primary goes beyond the eye's ability to differentiate
>(geez this is *old* published information too).
It isn't if you use these 8 bits as a linear value for intensity. And
yes, that is *old* published information too and you may even test it
yourself. Just display two larger rectangles adjacent to each other,
one at gray level N and the other at gray level N+1. For some values N
some people (maybe not you) can see the border.
Regards,
Paul Hsieh
Ralph Schmidt wrote:
> On 11/02/96, Paul Hsieh wrote:
> >Even if that PC had an MPACT Media-Processor in it? Go check out
> =
> The MPACT DSP looks like a TI clone to me so i=B4m wondering
> if they have improved the learning curve of their processor ?
> The problem with the TI is that it looks really neat on
> a paper and the DSP itself isn=B4t slow but it needs far
> better development tools and it takes time to use all
> the power.
> IMHO the DSP is too complex as a general unit.
You're damn right its complex. However, that hasn't kept *us* from =
writing a realtime microkernel for tasks including 2D/3D graphics
acceleration, audio mixing, a 28.8 modem, and MPEG playback that will
knock your socks off. The general concensus is that we've kind of =
left the TI part (and other similar solutions) behind in the dust.
We're the only ones that can even deliver DVD to the PC (and we do it
quite nicely thank you very much.) You can get more information from =
the web pages listed above.
-- =
Paul Hsieh
qed "at" chromatic "dot" com
http://www.geocities.com/SiliconValley/9498
Graphics Programmer
Chromatic Research
What I say and what my company says are not always the same thing
Fabio Bizzetti
Juergen "Rally" Fischer (fisc...@Informatik.TU-Muenchen.DE) wrote:
>Fabio Bizzetti (bizz...@mbox.vol.it) wrote:
>> I just hope they aren't so fool to pretend to program it only through APIs:
>> it doesn't work with programmable/flexible hardware, at all.
>>
>> It's time to provide two things:
>>
>> 1) Rigid rules for the OS: max protection for applications, but also an
>> OS legal way to allocate the resources and switch to direct hardware
>> programming. This was invented with the Amiga 12 years ago, and worked
>> as
>I'd sugest another kind of display hw-allocation:
>you get it but user still can switch screens.
>just like a ucopl (imagine ucopl was more polwerful).
I personally dont want the user to mess up with the display.
>and the copper is not to have acess to bits like interrupts and dma
>which is not of display.
I personally dont want limitations.
>> long as the Amiga was competitive, as this kind of computers have to be.
>the joke is the hack stuff failed on the machines that were longer
>competitive (A3000).
That was because of the CPU, more than anything else.
Hopefully with these PowerPC they dont start privileging instructions in the
middle of their evolution.. and most of the problems will not occur anymore
anyway (they were because of the introduction of cache memories, and such).
>> 2) Hardware compatibility (easy, as I wished/explained many times in the
>> past it's perfectly possible with such a kind of device: and also
>> cheap); "abstraction of the hardware" is exactly what would make this
>> device suck.
>what would make this device suck is only games available that shut it down!
>all current games I can think of would work as well through API.
I absolutely dont think so, perhaps you have already in mind only the first
Quake clone.. :/
>So, which fx you talk about saying "back to hw hack" ?
Come on.. I dont wanna start a list now.
If you've followed all my postings until now, you should know.
>The copper for example could have been driven through API if the ucopl
>stuff would have been done more clever.
I want to run my fast optimized specialized copperlist generator every frame,
I dont want to pass through a lame generical API.
Can't you already see the limitations? I can, and will program every piece of
the hardware that has to be programmed directly..
>This and clever graphx drivers
Who writes them? Besides that "clever gfx drivers" dont exist because they've
to be generical anyway.
Hardware evolution is the key, and now it's possible.
>would have leaded to rasterfx (lionhart) games beeing playable on
>gfx-card now.
Bah.. maybe on a ZorroII gfx board?
What rasterfx? Only 5% of the ones I've seen in games.
What speed?
With the A\BOX the abyss between "it can be done on standard gfx devices" and
"it can be done FAST ENOUGH on standard gfx devices" will be even bigger than
it was with Amiga OCS and CGA/EGA/VGA of that time.
>> Nobody thinks that you can run the real games of A\BOX on another
>> hardware.. through the WritePixel(tm) "abstraction of the hardware", it
>> works on SVGA, perhaps, not on such clever custom hardware.
>actually lot of the SVGA stuff does lot of hw acess.
What? The VESA driver? ;)
>future of gfx is rendering a array of 8,16, 32bit pixels and then
>dumping it to screen (or maybe direct render), without any usage
>of rasterfx or "hwwindow" stuff.
Come on.. I will stop answering to such affirmations.
That is LAME future for LAME hardware manufacturers and sad programmers.
For what it concerns to me, the future is the AgaEXTENDER, A\BOX, and all
the other programmable custom chips that will exist (when and if, and some,
enough, will surely exist).
>those hwwindows might be useful for 2d sprites,
HOW DO YOU KNOW??
You're starting to talk as those academical engineers that didn't give chunky
gfx to the Amiga "just because we dont see how it could be useful...<yawn>".
>how about giving some examples where hw hack on that machine
>would do things you need hw hack for.
I dont need to waste my time this way, download and read all the postings
I made on c.s.a in the last year, I ain't going to rewrite all again for you..
Anyway, nobody says you must buy an A\BOX.
This computer is for openminded programmers, not for the ones that wanna limit
every feature in the name of a wannabe compatibility seeked in the wrong way.
>-------------------------------------------------------------------------
> fisc...@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) =:)
> http://www.informatik.tu-muenchen.de/~fischerj/
>
Flames go to NIL:
Paul Hsieh
PhiRatE wrote:
> : > [Drool-generating description of software-reprogrammable
> : >
> : > [...] Now that WOULD kick a PC :))))))))
>
> completely flexible hardware (maybe) but we'd still have A) A better
> O/S
AmigaDOS versus Win 95? Why don't you put your money where your mouth
is and explain why.
> B) Better Coders
:o) Unlikely.
> C) A Future-Proof system, which means that while poor PC
> programmers are coding for 4 different types of MPACT clones, we're
> streaking ahead on a solid system base.
Poor PC programmers are not programming for any MPACT clones. They
program for Pentium clones and that's it. Its programmable for *US*,
not just anybody (though we may change this in the future.)
--
Martin Steigerwald
Mike Redrobe schrieb in comp.sys.amiga.programmer ueber "Re: Phase5's
A\BOX":
>Yes, we have had all this already, but provide people with forbid() and
>they'll do their game inside it. Why would they allocate resources
I really dont see any necessary to provide Forbid() publically on a
A\BOX anyway. The machine would be fast enough to even run good programmed
games with enabled multitasking. The only thing maybe needed is to give
higher priority to it. (That could be done automatically be a scheduler
like Executive.)
--
|_| _ |o _ _ Martin stei...@stud.uni-frankfurt.de Team
| |(/_||(_)_> Steigerwald http://home.pages.de/~helios AMIGA
ultimate_answer_t deep_thought(void)
{ sleep( years2secs(7500000)); return 42 }
Marc Forrester
Byron Montgomerie wrote:
> : > isn't the current graphics cards at 128 bit?
>
> : Get a clue. No grafx card uses 128 bit color.
> : Do you know how many colors that would be?
>
Well, 340,282,300,000,000,000,000,000,000,000,000,000,000
to be more precise. :P Now, does anyone know how many
colours the human visual system can differentiate?
Marc Forrester
Michael van Elst wrote:
> It isn't. :) 24-bit is _not_ enough, mainly
You can tell $000 from $010 ?
Where did you get your monitor? :)
Marc Forrester
Paul Hsieh wrote:
> > [...] Now that WOULD kick a PC :))))))))
>
> Even if that PC had an MPACT Media-Processor in it?
> Go check out http://www.chromatic.com/ and http://www.mpact.com/
Well, if this machine does turn out like an Amiga with processor
power, native high-bandwidth RTG, and no chip ram limitations,
yes. Basically. The PC will have all the software, of course,
but we have the OS, and the best shareware support on earth.
What does the Media-Processor do, anyway?
(The web site is a complete mess, unfortunately)
That an A\Box couldn't do in software and still
outperform any Microsoft OS based system, that is.
Marc Forrester
Byron Montgomerie wrote:
> : This custom hardware stays to a PC as a PC stays to a Vic20. 8)
> ^^^^^ ^^^^^
> What exactly does that mean? :)
'Relates' or something, presumably. It's not his first langauge.
> Is this hardware available to buy?
Well, obviously not yet, but Phase5 do generally deliver. Eventually.
> There are no apps written for it so you still have the
> same amiga apps running on top of different hardware.
So what's wrong with Amiga Apps?
Plus, it'll almost certainly be able to run X11 stuff.
> Where are all the experts who will know how to program the
> machine immediately and where are the docs they will use?
Certainly sounds like anyone already expert with AmigaOS
will be an expert on this with very little training,
especially if they've used any RTG stuff.
Besides, what of it? Acorns, Macs, IBM's, Amigas and UNIX
were all brand new when they were brand new, and it didn't
take long for the experts to turn up. The thing is,
you get people who are naturals at things that haven't
been invented yet, and if they're lucky enough to live
to see their natural field appear, they flower on it
very quickly indeed.
Steve Koren
> > It isn't. :) 24-bit is _not_ enough, mainly because 8-bit per primary
>
> (geez this is *old* published information too).
No, it does *not* go "beyond the eye's ability to differentiate".
Try it yourself. Get a paint program. Make a horizontal no-dither green
fill from 0 on the left side to 255 on the right. You will see banding
(at least most people will. I do). Thus, 8 bit color does not go beyond
your ability to differentiate. 12 bits per primary, *maybe*, although
even there I'm not sure.
That's the wonderful thing about usenet: misinformation is doomed to live
forever. Come back in 10 years. Someone will be posting, "8 bits per
primary goes beyond the ability of your eye to differentiate".
- steve
Juergen Rally Fischer
Fabio Bizzetti (bizz...@mbox.vol.it) wrote:
>
> Juergen "Rally" Fischer (fisc...@Informatik.TU-Muenchen.DE) wrote:
>
> >I'd sugest another kind of display hw-allocation:
> >you get it but user still can switch screens.
> >just like a ucopl (imagine ucopl was more polwerful).
>
> I personally dont want the user to mess up with the display.
>
> >and the copper is not to have acess to bits like interrupts and dma
> >which is not of display.
>
> I personally dont want limitations.
>
hehe, beeing in sarcastic mood, right ? ;)
I never had fx where I needed to set interrupt bits or disk-dma bits
or such stuff with the copper. though it is a useless danger if copper
can do it. Same would go for the future-"whatever"-box.
its copper isn't to poke anything that would break the system.
of course it is to be able to cause interrupts, but not any that
would danger the system.
and if Amiga-M messes up your display the coder is the one that did
wrong, not the user ;)
don't tell me you suggest future hardware where it is not possible
to switch between Workbench and Gamescreen! well, then the hardware sucks
and I stay to my A1200 where this is possible (without any limitations
of the gamescreen). it would be still possible with the limitations
I told. (BTW what about that CDANGER bit, which bits are protected ?
I wish the AGAGuide was written by people whose native language isn't
english, so I could understand ;D
>
> >> long as the Amiga was competitive, as this kind of computers have to be.
>
> >the joke is the hack stuff failed on the machines that were longer
> >competitive (A3000).
>
> That was because of the CPU, more than anything else.
Yep, just the 030 and fastmem. a configuration that can play
something like Breathless much better than with a A500.
I like the chunky games as well, sorry.
and btw, you could do more collision controll on 2d game with a 030 ;)
turrican more often stays 1 frame, that's why I found out on my A1200.
better cpu, same chispet mode.
> Hopefully with these PowerPC they dont start privileging instructions in the
> middle of their evolution.. and most of the problems will not occur anymore
here I agree. Motorola just did incompatible chips, you can't blame
the coders if the ccr stuff fails.
> anyway (they were because of the introduction of cache memories, and such).
I thought it was rather mmu stuff...
>
>
> >> 2) Hardware compatibility (easy, as I wished/explained many times in the
> >> past it's perfectly possible with such a kind of device: and also
> >> cheap); "abstraction of the hardware" is exactly what would make this
> >> device suck.
>
> >what would make this device suck is only games available that shut it down!
> >all current games I can think of would work as well through API.
>
> I absolutely dont think so, perhaps you have already in mind only the first
> Quake clone.. :/
Yep, I got in mind Quake and Descent.
Lionhart (dunno a better copper example, gimme) could as well build
and update copper lists via a API.
>
>
> >So, which fx you talk about saying "back to hw hack" ?
>
> Come on.. I dont wanna start a list now.
> If you've followed all my postings until now, you should know.
No, please, I got no idea, I read about your modes and the engine-flames,
but can't remember anything that wouldn't work ;)
just gimme one hint, don't hide.
>
>
> >The copper for example could have been driven through API if the ucopl
> >stuff would have been done more clever.
>
> I want to run my fast optimized specialized copperlist generator every frame,
> I dont want to pass through a lame generical API.
let's assume the new chipset got 32bit planeptrs.
then do this:
cm=getcmoveadr(ucopl)
cmove(plane,0)
.
.
.
game:
*cm=mypoke;
*xx=.....
.
.
dumpucopl(ucopl); /* do nothing on chipsets that got copper.
do your emulation stuff on vga or whatever */
done!
> Can't you already see the limitations? I can, and will program every piece of
> the hardware that has to be programmed directly..
>
>
> >This and clever graphx drivers
>
> Who writes them? Besides that "clever gfx drivers" dont exist because they've
it doesn't care. we're in a tech discussion.
> to be generical anyway.
the driver which got the poor job to do it on standard vga would
have to build the lionhart-scroller with copying lines. slow, but
it'd work.
> Hardware evolution is the key, and now it's possible.
yep, have fancy hw and just think a bit about future.
once the copperscreen might just be in a small window
on the enterprise-control-panel, with a dsp calculating
display contents from copperlist ;)
>
>
> >would have leaded to rasterfx (lionhart) games beeing playable on
> >gfx-card now.
>
> Bah.. maybe on a ZorroII gfx board?
yep. maybe slow, but works.
the joke is that everything changes rapidly.
fast blitters of future gfx-cards will copy the bits together
beyond a 100Hz-frame.
> What rasterfx? Only 5% of the ones I've seen in games.
If you could give me a conuterexample, I only know lionhart ;)
> What speed?
better speed on current copper driven computer.
same speed or better later on any other hw.
>
> With the A\BOX the abyss between "it can be done on standard gfx devices" and
> "it can be done FAST ENOUGH on standard gfx devices" will be even bigger than
> it was with Amiga OCS and CGA/EGA/VGA of that time.
hardware windows ? or what ? don't hesitate to give me a example
where my talk is wrong.
>
>
> >> Nobody thinks that you can run the real games of A\BOX on another
> >> hardware.. through the WritePixel(tm) "abstraction of the hardware", it
> >> works on SVGA, perhaps, not on such clever custom hardware.
>
> >actually lot of the SVGA stuff does lot of hw acess.
>
> What? The VESA driver? ;)
polling vblank bit. hacking higher modi withing standard-vga range.
lots of PC-demos do. some could do better using vesa.
>
>
> >future of gfx is rendering a array of 8,16, 32bit pixels and then
> >dumping it to screen (or maybe direct render), without any usage
> >of rasterfx or "hwwindow" stuff.
>
> Come on.. I will stop answering to such affirmations.
> That is LAME future for LAME hardware manufacturers and sad programmers.
well, I got no idea what your demo would want to do.
>
> For what it concerns to me, the future is the AgaEXTENDER, A\BOX, and all
the agaextender... well... seen the lepovitan commercial ?
tmaped energy drink bumping on the beat, cool.
50 hz 640x512. aga...
> the other programmable custom chips that will exist (when and if, and some,
> enough, will surely exist).
>
>
> >those hwwindows might be useful for 2d sprites,
>
> HOW DO YOU KNOW??
oh if a hwwindow can be transparent it is a sprite you know.
>
> You're starting to talk as those academical engineers that didn't give chunky
> gfx to the Amiga "just because we dont see how it could be useful...<yawn>".
hehe, he called me academic =:D
imagine copper driven demo on A\Box.
now I want to watch 4 of them in 4 windows on a B\Box.
your copper hack fails and my lame api demo wins ;)
>
>
> >how about giving some examples where hw hack on that machine
> >would do things you need hw hack for.
>
> I dont need to waste my time this way, download and read all the postings
> I made on c.s.a in the last year, I ain't going to rewrite all again for you..
now you took the effort to write multiple times that you don't talk
to me because I got different oppinion.
you could have written a 60char line ginving an example.
give me an example proving me wrong and will will have to
eat it.
>
> Anyway, nobody says you must buy an A\BOX.
> This computer is for openminded programmers, not for the ones that wanna limit
> every feature in the name of a wannabe compatibility seeked in the wrong way.
oh no, I even wanna have more features, see above.
Juergen Rally Fischer
Byron Montgomerie (bmon...@morgan.ucs.mun.ca) wrote:
> Juergen "Rally" Fischer (fisc...@Informatik.TU-Muenchen.DE) wrote:
> ^
>
> : wrong! all numbers 2^n got 2,4,6 or 8 as last char ;)
>
> What's 1 Meg? :) 1024000. :) For that matter what's 2^0? :)
No, only non-computer people use 1000 instead of 1024 ;)
and n is _n_atural, 1,2... ;)
>
> : unless we have robots playing games in future, 24bit will be
> : suficient forever. as well as 16bit sound...
>
> Sure, it may get refined to a better distribution though, or even something
> other than RGB in hardware.
well, the format of the gfx-card doesn't care anymore if the
cpu / dsp can convert beyond 1 frame.
>
> Regards,
>
> BM
>
-------------------------------------------------------------------------
fisc...@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) =:)
http://www.informatik.tu-muenchen.de/~fischerj/
^- dont forget this char
Johnny C. Kitchens
In article <327E37...@isy.liu.se> "Magnus E. Krisell" <y95m...@isy.liu.se> writes:
> Byron Montgomerie wrote:
> > >
> > : Get a clue. No grafx card uses 128 bit color.
> > : Do you know how many colors that would be?
> >
> > 340280000000000000000000000000000000000 colors. :)
> >
>
> 340282366920938463463374607431768211456 colors :) :) :)
>
> Magnus
It means that it processes the data in 128 bit. It still only displays
24 bit images. Like the Cybervision64 has a 64 bit processor, but it
still just shows 24 bit images...
--
Johnny C. Kitchens
kitc...@letter.com
Christian Wasner
Mans Engman (c92m...@und.ida.liu.se) wrote about Re: Phase5's A\BOX:
ME> Juergen "Rally" Fischer wrote:
>>> : Do you know how many colors that would be?
>>>
>>> 340280000000000000000000000000000000000 colors. :)
>>wrong! all numbers 2^n got 2,4,6 or 8 as last char ;)
ME> Right! But also, all numbers 2^(2^n), n>=2, ends with 6. So,
ME> the correct answer is 340280000000000000000000000000000000006.
Do you work for Microsoft ? :-)
Greetings
--
Christian Wasner (CRISI/PHANTASM)
Christia...@hamburg.netsurf.de
Q: How do I get the X11 sources ?
A: Post DPaint2 into comp.sys.amiga.misc.
Babbage
In article <55ljt4$q...@morgana.netcom.net.uk>, ro...@powhq.nildram.co.uk (Roger Wong) writes:
> bab...@dmu.ac.uk (Babbage) wrote:
>
> >and from a HCI course I did,
> >humans can only differenciate between around 8000 different colours
> >at max (and thats if your recognition is pretty hot)
> >at any one time!
>
> Babbage,
>
> On a computer screen, a person can distinguish 16 million colors. Your
>
> Further reading: Michael Abrash, 1995. Zen of Graphics Programming.
> Coriolis Group Books. ISBN 1-883577-08. I picked up my copy for $5.00
> at a discount book store during a vacation in Texas.
>
>
but still, at any one instance of time,
at any split second, the brain can only see around 8000 colours at once.
A split second later, it might be another 8000, and so on,
(I supose a bit like a 8bit palette out of a 24bit one)
lots of 8000`s make many millions
it still doesnt mean you can recognise a difference between them all
at the same time.
(Anyway, you try finding a computer screen around (in general)
that can display 16m colours at once to try it with =:)
Juergen Rally Fischer
Steve Koren (s...@frii.com) wrote:
> That's the wonderful thing about usenet: misinformation is doomed to live
> forever. Come back in 10 years. Someone will be posting, "8 bits per
> primary goes beyond the ability of your eye to differentiate".
Let's describe it different: digitize a TV picture to 24bit and compare
it to the original. no difference. So 24bit is enough for my needs.
Fabio Bizzetti
Mike Redrobe (Mi...@Redrobe.demon.co.uk) wrote:
>Hi, Fabio Bizzetti , on 01-Nov-96 17:37:47 you scribbled....
>>This custom hardware stays to a PC as a PC stays to a Vic20. 8)
>Indeed, time for another leap forward...
>>I just hope they aren't so fool to pretend to program it only through APIs:
>>it doesn't work with programmable/flexible hardware, at all.
>no comment
>>It's time to provide two things:
>>1) Rigid rules for the OS: max protection for applications, but also an
>> OS legal way to allocate the resources and switch to direct hardware
>> programming. This was invented with the Amiga 12 years ago, and worked as
>> long as the Amiga was competitive, as this kind of computers have to be.
>Yes, we have had all this already, but provide people with forbid() and
>they'll do their game inside it. Why would they allocate resources instead?
Simply because this way you can restore the original hardware status.. simple.
>It could have been doen this way for 80% of amiga games, but wasn't, why
>would the A/Box be different?
>(I'm surprised those words came from you Fabio)
What?
I know you dont know me, it shows also from the things you said about the
A\BOX design and the things that many people (not you..) have read from me.
>As to it ever working, even when the amiga was "competitive", I didn't see
>many games keeping the OS AT ALL (e.g. just taking over the view)
The OS sucked for the needs of arcade games programmers, that's all.
This issue was neither seen as a problem, because *the OS* was the problem.
>>2) Hardware compatibility (easy, as I wished/explained many times in the
>> past it's perfectly possible with such a kind of device: and also cheap);
>> "abstraction of the hardware" is exactly what would make this device
>> suck.
>compatibility to what? I hope you don't mean AGA ?
Of course not.. what may I expect from you then, besides comments about the
design that is proven I made in the past and the A\BOX that came after?
You look like the guy that told me I dont know about the Amiga and then he
thinks you can have a hires copperscreen.. same way to think your stuffs out..
>>Nobody thinks that you can run the real games of A\BOX on another hardware..
>>through the WritePixel(tm) "abstraction of the hardware", it works on SVGA,
>>perhaps, not on such clever custom hardware.
>well not WritePixel, but maybe BltBitMap ;)
As long as anything changes, it will not be optimal anymore.. as all the
standard things, even more when they've to cope with custom devices.
I am glad anyway that there will be people using stardard API's: less real
competition, less efforts to put in the development time.
>Mike
>--
>---------------------------------------------------------------------------
>Mike Redrobe - Mi...@Redrobe.demon.co.uk MikeRR on #Amiga
> http://www.Redrobe.demon.co.uk
>---------------------------------------------------------------------------
Fabio Bizzetti
Juergen "Rally" Fischer (fisc...@Informatik.TU-Muenchen.DE) wrote:
>Fabio Bizzetti (bizz...@mbox.vol.it) wrote:
>> >So, which fx you talk about saying "back to hw hack" ?
>>
>> Come on.. I dont wanna start a list now.
>> If you've followed all my postings until now, you should know.
>No, please, I got no idea, I read about your modes and the engine-flames,
>but can't remember anything that wouldn't work ;)
>just gimme one hint, don't hide.
Hide me?
hahahha (30 seconds after) hahahahahahah (2 minutes after) hahhhahahahahaha :)
You call "hide" what I call "waste of time"..
And no, I won't want to waste it anyway.
I'll just copy and paste some text I've just written, that's more than enough:
---
>IMHO the hardware should be shielded by providing an API for games.
I will be happy to hack it, I hate silly rules that in concrete exist only
to make computers of today less performant than hardware-banged computers of
yesterday.
I can release patches if the hardware changes, now modularity is a constant
for me and a lot of other game programmers, compatibility is not a problem
for all the time before a new innovative hardware comes out and it's time
for a new generation of games anyway. Not counting that a new hardware
generation can easily emulate the old one in software, as the A\BOX's
programmable custom chips will be easily capable of emulating the Amiga chips.
>There is no need to directly write to palettes, scroll registers, copperlists
>and so on.
That's what your lack of imagination makes you think, since you can only
think in terms of "games of today".
Even in old 2D games there's the need to write complex copperlists each frame,
to make complex scrolling and palette tricks hundreds/thousands times every
frame.
It's having the PC always in mind that makes you think all the games are more
or less a Doom clone.
---
Is it clear enough?
You probably dont have in mind a lot of old 2D games, let away the ones that
have still to be programmed.
Not only the OS has never let us use horizontal multiplexing sprites and other
fancy tricks, an API *cannot* lose its overhead (the becomes enormous in all
the special cases) because it's an interface to the hardware.
It's something in the middle that requires CPU time, and cannot be tuned to
anything else than generical or well-known problems.
I like to invent new innovative stuffs, not to clone the old PC games.
An API cannot be as efficent as hardware programming, by FAR, because the more
you try to make it as efficent as hardware programming, you make it simply
equal in a direct way to the hardware programming.
The choice then becomes:
1) Use the OS with all those hardware-specific tricks that dont work on
gfx boards, as copperlists, hardware sprites, etc.. you have to use the
native hardware anyway, also if you use it more or less through the OS.
2) Why bother then? Program the hardware God gave you, properly and directly.
An API cannot be as efficent as hardware programming, by FAR, because the more
you try to make it as efficent as hardware programming, you make it simply
equal in a direct way to the hardware programming.
>> Can't you already see the limitations? I can, and will program every piece
>> of the hardware that has to be programmed directly..
>>
>>
>> >This and clever graphx drivers
>>
>> Who writes them? Besides that "clever gfx drivers" dont exist because
>> they've to be generical anyway.
>it doesn't care. we're in a tech discussion.
It matters instead!
"Tech discussion" means about what is useful, not pure useless nice theory.
>the driver which got the poor job to do it on standard vga would
>have to build the lionhart-scroller with copying lines. slow, but
>it'd work.
Who cares?
Then run UAE, slow but it works.
I've even huger speed differences in mind once I get a programmable chipset.
>> >would have leaded to rasterfx (lionhart) games beeing playable on
>> >gfx-card now.
>>
>> Bah.. maybe on a ZorroII gfx board?
>yep. maybe slow, but works.
Emulation is the key for that, and a "new generation" programmable hardware
as the one in the A\BOX can provide excellent emulation, so..
>> What rasterfx? Only 5% of the ones I've seen in games.
>If you could give me a conuterexample, I only know lionhart ;)
I know a lot of more 2D games, but since you said you know only LionHeart,
it's useless to name them (unless you want to get them pirated..).
>> With the A\BOX the abyss between "it can be done on standard gfx devices"
>> and "it can be done FAST ENOUGH on standard gfx devices" will be even
>> bigger than it was with Amiga OCS and CGA/EGA/VGA of that time.
>hardware windows ? or what ? don't hesitate to give me a example
>where my talk is wrong.
I dont have time to waste, sorry.
I should pack and send all the articles I posted in the past, so you can read
them.
>> >> Nobody thinks that you can run the real games of A\BOX on another
>> >> hardware.. through the WritePixel(tm) "abstraction of the hardware", it
>> >> works on SVGA, perhaps, not on such clever custom hardware.
>>
>> >actually lot of the SVGA stuff does lot of hw acess.
>>
>> What? The VESA driver? ;)
>polling vblank bit.
WHO ever did that?
They use the PIT timer to simulate a VBL int, besides some hacker that
_experiments_ (but never uses it in games) the real VBL IRQ, which is in
the VGA standard anyway FYI, not SVGA that is not standard.
> hacking higher modi withing standard-vga range.
That's still using VGA registers, and works only with the cards that are
VGA extended rather than completely different.
>> For what it concerns to me, the future is the AgaEXTENDER, A\BOX, and all
>the agaextender... well... seen the lepovitan commercial ?
Read the whole phrase I wrote before cutting it in the middle.
>tmaped energy drink bumping on the beat, cool.
>50 hz 640x512. aga...
>> the other programmable custom chips that will exist (when and if, and some,
>> enough, will surely exist).
As you see, I made some examples, and said that some will exist and some
others will not, but some will exist for sure.
>> >those hwwindows might be useful for 2d sprites,
>>
>> HOW DO YOU KNOW??
>oh if a hwwindow can be transparent it is a sprite you know.
I meant.. you can't decide NOW what will be useful and what will not.
Are you Coders'God that writes the Ten Commandments of coders?
I learnt that one understands what he needs while coding and inventing, not
5 years before.
>> You're starting to talk as those academical engineers that didn't give
>> chunky gfx to the Amiga "just because we dont see how it could be
>> useful...<yawn>".
>hehe, he called me academic =:D
That's how you look like in those words.
>imagine copper driven demo on A\Box.
>now I want to watch 4 of them in 4 windows on a B\Box.
Useless.
>your copper hack fails and my lame api demo wins ;)
But my demo on the old A\BOX outperforms of 10:1 your OS demo in the new B\BOX.
<grin> ;)
If I have a fast car, I dont wanna limit it to 30mph just because others may
have problems, I dont get a fast car at all in this case.
>> >how about giving some examples where hw hack on that machine
>> >would do things you need hw hack for.
>>
>> I dont need to waste my time this way, download and read all the postings
>> I made on c.s.a in the last year, I ain't going to rewrite all again for
>> you..
>now you took the effort to write multiple times that you don't talk
>to me because I got different oppinion.
>you could have written a 60char line ginving an example.
>give me an example proving me wrong and will will have to eat it.
Good lunch, there's too much to eat.
Repeating the stuff of above:
---
>IMHO the hardware should be shielded by providing an API for games.
I will be happy to hack it, I hate silly rules that in concrete exist only
to make computers of today less performant than hardware-banged computers of
yesterday.
Article Unavailable
Babbage
In article <7127...@sunshine.stud.uni-frankfurt.de>, "Martin Steigerwald" <stei...@stud.uni-frankfurt.de> writes:
> Mike Redrobe schrieb in comp.sys.amiga.programmer ueber "Re: Phase5's
> A\BOX":
>
> >they'll do their game inside it. Why would they allocate resources
>
> A\BOX anyway. The machine would be fast enough to even run good programmed
> games with enabled multitasking. The only thing maybe needed is to give
> higher priority to it. (That could be done automatically be a scheduler
> like Executive.)
its used for saftey critical things
where your code must be guaranteed that something else wont swap
in and execute while its in the middle of something
so you can put saftey locks around it with forbid/permit
babbage =:)
Fabio Bizzetti
Michael van Elst (mle...@serpens.swb.de) wrote:
>gau <g...@vortex.netbistro.com> writes:
>>On 3 Nov 1996, Michael van Elst wrote:
>>> Philip Kaulfuss <ph...@boehme.demon.co.uk> writes:
>>>
>>> It isn't. :) 24-bit is _not_ enough, mainly because 8-bit per primary
>>Eight-bits per primary goes beyond the eye's ability to differentiate
>>(geez this is *old* published information too).
>It isn't if you use these 8 bits as a linear value for intensity. And
>yes, that is *old* published information too and you may even test it
>yourself. Just display two larger rectangles adjacent to each other,
>one at gray level N and the other at gray level N+1. For some values N
>some people (maybe not you) can see the border.
But.. would they see the border if it was N -> N+0.5 anyway?
No.. at least my (sane) eyes.
So 24bit is ok, because having more resolution would be useless anyway, since
we've to cope with 2^n resolutions.
Personally, also if your cat has 27bit eyes, I prefer 24bit colors because
handling bytes is faster than handling 9bit variables.
>Regards,
>--
> Michael van Elst
>Internet: mle...@serpens.swb.de
> "A potential Snark may lurk in every tree."
The hair (singular) is splitted now, it's up to you to comb it.. :)
Babbage
> It isn't. :) 24-bit is _not_ enough, mainly because 8-bit per primary
> color is not enough. But you are right that there is little need to
> go beyond 24-bit color. Most people are satisfied with 24-bit as
> for most images (but not all) you couldn't see a difference and
> the common display technology can't even reproduce the 24-bit colors
> precisely.
oh come on course its enough.
resolution is probably a more important facter
(after all, who sits there looking at bands of colour all day, you must be very sad)
Just take a look at 1/2 the photos in magasines
there just made up of hi resolution dots of 3 bloody colours
but they look good enough for most people!
and more and more these days images include more and more detail
= less room to fit colours in (eg. say a picture of a tree with lots of leaves, the leaves wont need to many colours each)
so nice bands of colour over a 17inch monitor where you can just about see some banding if your eyes
are good and you look closely isnt saying much.
With image compression as well at these kinds of levels, you loose bags o stuff anyway.
babbage =:)
Johan Rönnblom
Fabio Bizzetti wrote:
> Juergen "Rally" Fischer (fisc...@Informatik.TU-Muenchen.DE) wrote:
> >> 2) Hardware compatibility (easy, as I wished/explained many times in the
> >> past it's perfectly possible with such a kind of device: and also
> >> cheap); "abstraction of the hardware" is exactly what would make this
> >> device suck.
>
> >what would make this device suck is only games available that shut it down!
> >all current games I can think of would work as well through API.
>
> I absolutely dont think so, perhaps you have already in mind only the first
> Quake clone.. :/
Hey you two! Stop this. Fabio, you make the cool H/W bashing games of tomorrow, which I will
run when I feel for some serious :) gaming, and which may or may not work on future
PowerAmigas.
Juergen, you make the 'lame', systemfriendly Quake clones that I'll play when I'm working
with other programs in the background.
Phase5 finds out how Fabio does all his cool direct to H/W tricks, and puts the most useful
bits into the API. Then Juergen's next game uses this, and everything gets better and better.
Everyone's happy, OK?
/Johan Rönnblom, Team Amiga
Fabio Bizzetti
Johan Rönnblom (JRo...@ba.ssdn.skellefte.se) wrote:
>Fabio Bizzetti wrote:
>> Juergen "Rally" Fischer (fisc...@Informatik.TU-Muenchen.DE) wrote:
>> >> 2) Hardware compatibility (easy, as I wished/explained many times in the
>> >> past it's perfectly possible with such a kind of device: and also
>> >> cheap); "abstraction of the hardware" is exactly what would make this
>> >> device suck.
>>
>> >what would make this device suck is only games available that shut it
>> >down! all current games I can think of would work as well through API.
>>
>> I absolutely dont think so, perhaps you have already in mind only the first
>> Quake clone.. :/
>Hey you two! Stop this. Fabio, you make the cool H/W bashing games of
>tomorrow, which I will run when I feel for some serious :) gaming, and which
>may or may not work on future PowerAmigas.
>Juergen, you make the 'lame', systemfriendly Quake clones that I'll play when
>I'm working with other programs in the background.
Yeah.. great and perfect solution. :)
>Phase5 finds out how Fabio does all his cool direct to H/W tricks, and puts
>the most useful bits into the API. Then Juergen's next game uses this, and
>everything gets better and better.
But in this case I would take Phase5 to court for copyright violation. ;)
Let's remain in the first two points, so everyone agrees. ;D
> /Johan Rönnblom, Team Amiga
Michael van Elst
bizz...@mbox.vol.it (Fabio Bizzetti) writes:
>>one at gray level N and the other at gray level N+1. For some values N
>>some people (maybe not you) can see the border.
>But.. would they see the border if it was N -> N+0.5 anyway?
Yes. If you use linear RGB values you need about 11..12 bit per primary
to avoid such banding artifacts (that is, you avoid it for the hundreds
of test persons but probably for everyone else too).
>No.. at least my (sane) eyes.
Where did you try ? :)
>So 24bit is ok,
It is ok most of the time and the benefits of higher color resolutions
are probably too small to justify the costs.
>because having more resolution would be useless anyway,
It isn't useless. In fact, everybody can see the limitations
because a simple compensation of the monitor intensity function
will drop the resolution below 8bit/primary. Compute a gamma
curve in 8 bit and see what values are mapped to the same RGB
value and what RGB values are simply missing from the result.
This could easily be solved with a non-linear DAC (or one with
an internal gamma correction). You would still have 24bit per
pixel but the gamma correction would expand it to 30 or more bits.
The disadvantage is that such DACs are more expensive.
There are graphics boards that use such DACs though, they are
used together with expensive precision monitors in the prepress
stage.
>Personally, also if your cat has 27bit eyes, I prefer 24bit colors because
>handling bytes is faster than handling 9bit variables.
I don't think that speed is an issue here :)
Per Jacobsen
Dr. Peter Kittel (pet...@combo.ganesha.com) wrote:
> In article <N.110296....@dynamic202.i-way.co.uk> ava...@patrol.i-way.co.uk (Avatar) writes:
> >
> >So how do you pronounce CAIPIRINHA?
> Kye-pee-rin-ya
Tasted one, have you? ;-)
Jens Kristian Jensen
On Sun, 3 Nov 1996, gau wrote:
> > It isn't. :) 24-bit is _not_ enough, mainly because 8-bit per primary
>
> Eight-bits per primary goes beyond the eye's ability to differentiate
> (geez this is *old* published information too).
Hey. Let's get a few facts here and end this silly discussion. Even
though 24 bit graphics looks great, the human eye CAN differentiate
between SOME of the color ranges. The human eye (in general) is MOST
sensitive to green, then red and less sensitive to blue. Therefore the
equal 8:8:8 distribution of the 24 bits to red, green and blue respectively
is not optimal. The human eye (even mine!) is perfectly able to
distinguish between two levels of 8-bit green. Try it out for yourself!
you don't need a 24bit gfx card - just an AGA machine(they have a 24 bit
palette!). Use a paint program to do a range from black to full green
(0,255,0). then paint two of the middle colors (say 127 and 128) next to
each other (fill an area with both). See? Or don't you? I do!
For more information check out various books about computer graphics -
for instance Computer Graphics by Foley/Van Damme et. al.
---------------------------------------------
Jens Kristian Jensen - Certified Amiga addict
5th. semester CS student
Kyzer
Juergen "Rally" Fischer (fisc...@Informatik.TU-Muenchen.DE) wrote in alt.sys.amiga.demos:
: Byron Montgomerie (bmon...@morgan.ucs.mun.ca) wrote:
: > Jakob Eriksson (dat9...@mds.mdh.se) wrote:
: >
: >
: > : On Fri, 1 Nov 1996, Paul Kenneth Egell-Johnsen wrote:
: > : > that would be upgradeable in a future design. And what about 24 bits to
: > : > the DMAs/DACs, isn't the current graphics cards at 128 bit?
: > : >
: >
: > : Get a clue. No grafx card uses 128 bit color.
: get a clue. A500 already had 16bit bus. but 12bit palette. and 6bit planes.
: > : Do you know how many colors that would be?
: >
: > 340280000000000000000000000000000000000 colors. :)
: wrong! all numbers 2^n got 2,4,6 or 8 as last char ;)
: unless we have robots playing games in future, 24bit will be
: suficient forever. as well as 16bit sound...
No, you're possibly :-) missing the point here. Remember 'crossfading'?
Remember 'bitplanes'? Remember how parallax works?
128 bit would make an excellent set of 5 truecolour bitplanes, or 8
256-colour bitplanes, or ...
128 bitplanes would be cool, but imagine the size of the palette :-)
dc.w bpl000pth,$7002
dc.w bpl000ptl,$0000
;...
dc.w bpl127pth,$f007 ; blizzard memory :)
dc.w bpl127ptl,$0000
--
.-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-.
| _ __ _________ ____ http://www.abdn.ac.uk/~u13sac u13...@abdn.ac.uk |
| | |/\ \_/(__ / __) __ \ My opinions are not that of Aberdeen University |
| | (\ // /| _)| / or AUCC, thankfully. NEW!: ky...@hotmail.com |
| |_|\_\|_|/____)___)_|\_\ Adamant: telnet://130.83.9.19:4711 |100% Amiga, |
| Stuart Caie, mere undergraduate at Aberdeen University | always. |
`-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-'
Juergen Rally Fischer
Fabio Bizzetti (bizz...@mbox.vol.it) wrote:
>
> Juergen "Rally" Fischer (fisc...@Informatik.TU-Muenchen.DE) wrote:
> >No, please, I got no idea, I read about your modes and the engine-flames,
> >but can't remember anything that wouldn't work ;)
> >just gimme one hint, don't hide.
>
> Hide me?
>
> hahahha (30 seconds after) hahahahahahah (2 minutes after) hahhhahahahahaha :)
good joke, eh ? ;)
>
> I'll just copy and paste some text I've just written, that's more than enough:
ok, good.
>
> ---
>
> >IMHO the hardware should be shielded by providing an API for games.
>
> I will be happy to hack it, I hate silly rules that in concrete exist only
> to make computers of today less performant than hardware-banged computers of
> yesterday.
and you are happy doing things with hacks that wouldn't need own copperlist.
the display of VK would as well run in a intuiscreen (if it used the
method you described).
>
> I can release patches if the hardware changes, now modularity is a constant
You can, that's Microsoft philosophy ;)
> >There is no need to directly write to palettes, scroll registers, copperlists
> >and so on.
>
> That's what your lack of imagination makes you think, since you can only
> think in terms of "games of today".
either you enlighten us with your imagination, or you admit that for the
limited imaginated things we talk about (lionhart, turrican) it is possible
to build an API that allows same speed fx.
I really hope they'll think about coders and do it. it is possible.
that's all I talk about, those things could be done API.
that's the joke, demos/games which would not need it switching to hw copl,
that's also what I talk about.
> Even in old 2D games there's the need to write complex copperlists each frame,
> to make complex scrolling and palette tricks hundreds/thousands times every
> frame.
yes, there is. and if gfx.lib would have had the features, you could have
just written directly to a copperlist like you did. but it would work
on A\Box now. and UAE maybe would have benefited as well.
anyone read my example description how it could have worked and how it
could work on A\Box ?
On a PPC you maybe even could do the stuff doing CMOVE/CBUMP each frame ;)
(which is not what I suggest).
>
> It's having the PC always in mind that makes you think all the games are more
> or less a Doom clone.
no, I was thinking about A500 games.
>
> ---
>
> Is it clear enough?
> You probably dont have in mind a lot of old 2D games, let away the ones that
> have still to be programmed.
>
> Not only the OS has never let us use horizontal multiplexing sprites and other
> fancy tricks, an API *cannot* lose its overhead (the becomes enormous in all
it might be possible that you now miss imagination ;)
> the special cases) because it's an interface to the hardware.
> It's something in the middle that requires CPU time, and cannot be tuned to
> anything else than generical or well-known problems.
> I like to invent new innovative stuffs, not to clone the old PC games.
well, rasterfx are kinda out. they are too limited. do vertical split
paralax and bye bye copperfx. well, ok, maybe the A\Box copper could
do it. But then, paralax is nothing more than virtual scroll of hw windows,
so if it really can do hw windows next to each other, just have scrollvport
for windows and you're done, no copperpokes needed.
and palette is kinda out on 24bit screens...
you were still not precise enough to tell fx which really would fail.
maybe there are, tell. I blame for hacking those who don't need
to be hacked.
>
> An API cannot be as efficent as hardware programming, by FAR, because the more
> you try to make it as efficent as hardware programming, you make it simply
> equal in a direct way to the hardware programming.
>
> The choice then becomes:
> 1) Use the OS with all those hardware-specific tricks that dont work on
> gfx boards, as copperlists, hardware sprites, etc.. you have to use the
> native hardware anyway, also if you use it more or less through the OS.
> 2) Why bother then? Program the hardware God gave you, properly and directly.
>
> An API cannot be as efficent as hardware programming, by FAR, because the more
> you try to make it as efficent as hardware programming, you make it simply
> equal in a direct way to the hardware programming.
maybe. it's just that my demo runs on A\Box.
>
>
> >> Can't you already see the limitations? I can, and will program every piece
> >> of the hardware that has to be programmed directly..
> >>
> >>
> >> >This and clever graphx drivers
> >>
> >> Who writes them? Besides that "clever gfx drivers" dont exist because
> >> they've to be generical anyway.
>
> >it doesn't care. we're in a tech discussion.
>
> It matters instead!
> "Tech discussion" means about what is useful, not pure useless nice theory.
Ok, then you say as due to marketsituation is is not possible, I hack.
Ok.
But don't tell me there would be no different way, speaking about tech stuff.
for example demos are pure tech stuff and I care shit about market.
If we talk about what APIs can do, we are in tech stuff.
>
>
> >the driver which got the poor job to do it on standard vga would
> >have to build the lionhart-scroller with copying lines. slow, but
> >it'd work.
>
> Who cares?
> Then run UAE, slow but it works.
but UAE is slower than API driven lionhart would be on gfx-card.
>
> I've even huger speed differences in mind once I get a programmable chipset.
so what you say is true for what you got in mind, but people might
believe it is true for all those demos/games out there. it isn't, for
most of them.
>
>
> >> >would have leaded to rasterfx (lionhart) games beeing playable on
> >> >gfx-card now.
> >>
> >> Bah.. maybe on a ZorroII gfx board?
>
> >yep. maybe slow, but works.
>
> Emulation is the key for that, and a "new generation" programmable hardware
> as the one in the A\BOX can provide excellent emulation, so..
but API driven generated copperlist would do you A500 stuff
directly on A\Box copper now! no emulation, compatibility.
more speed, the thing we want.
>
>
> >> What rasterfx? Only 5% of the ones I've seen in games.
> >If you could give me a conuterexample, I only know lionhart ;)
>
> I know a lot of more 2D games, but since you said you know only LionHeart,
> it's useless to name them (unless you want to get them pirated..).
haha, again.
>
>
> >> With the A\BOX the abyss between "it can be done on standard gfx devices"
> >> and "it can be done FAST ENOUGH on standard gfx devices" will be even
> >> bigger than it was with Amiga OCS and CGA/EGA/VGA of that time.
>
> >hardware windows ? or what ? don't hesitate to give me a example
> >where my talk is wrong.
>
> I dont have time to waste, sorry.
> I should pack and send all the articles I posted in the past, so you can read
> them.
You didn't write different in them like you do now.
"imagination" etc etc. not one single solid example.
ok, if your secret-imagination-fx needs hacking A\Box, then I won't
blame you. I blame you for telling us hw hack is nessesary, and
people who have not thought it over for _their_ fx might believe
that, what simply is bad to the Amiga and bad to the A\Box.
> >> >> Nobody thinks that you can run the real games of A\BOX on another
> >> >> hardware.. through the WritePixel(tm) "abstraction of the hardware", it
> >> >> works on SVGA, perhaps, not on such clever custom hardware.
> >>
> >> >actually lot of the SVGA stuff does lot of hw acess.
> >>
> >> What? The VESA driver? ;)
>
> >polling vblank bit.
>
> WHO ever did that?
my frinds vector demo for example.
> They use the PIT timer to simulate a VBL int, besides some hacker that
> _experiments_ (but never uses it in games) the real VBL IRQ, which is in
> the VGA standard anyway FYI, not SVGA that is not standard.
I knew there are vbl ways on PC. more or less.
hw hack is not the same problem on PC. who cares.
> Read the whole phrase I wrote before cutting it in the middle.
I maybe misunderstood. seen the lepoviatan commercial ? :)
> >> the other programmable custom chips that will exist (when and if, and some,
> >> enough, will surely exist).
>
> As you see, I made some examples, and said that some will exist and some
> others will not, but some will exist for sure.
>
ok, maybe. It's just that 99% of the games they would do could be
done legal. As I said, have scrollvport for hwwindows and you covered
a lot 2d stuff. if that box becomes true, it'll be cool, the one demo
in yuv window, the other one in rgb win, 8bit piccy in background.
unless one of the both took something over.
>
> >> >those hwwindows might be useful for 2d sprites,
> >>
> >> HOW DO YOU KNOW??
>
> >oh if a hwwindow can be transparent it is a sprite you know.
>
> I meant.. you can't decide NOW what will be useful and what will not.
> Are you Coders'God that writes the Ten Commandments of coders?
It's just that lot known stuff can go API. can't talk about unnkown.
>
> I learnt that one understands what he needs while coding and inventing, not
> 5 years before.
well look at all the stuff. I don't know what you got in mind,
but the copperstuff that was done mostly could be covered by API.
>
>
> >> You're starting to talk as those academical engineers that didn't give
> >> chunky gfx to the Amiga "just because we dont see how it could be
> >> useful...<yawn>".
>
> >hehe, he called me academic =:D
>
> That's how you look like in those words.
>
yeah I'm da c0ding aCad3mic.
>
> >imagine copper driven demo on A\Box.
> >now I want to watch 4 of them in 4 windows on a B\Box.
>
> Useless.
having a glance if my download is ready while demo is running.
useless ? what about your imagination ?
even more, beeing API driven those 4 demos could be rasterdemos!
unless they are the fx you have in imagination.
but anything else, would work fine, and I could download next demos.
>
>
> >your copper hack fails and my lame api demo wins ;)
>
> But my demo on the old A\BOX outperforms of 10:1 your OS demo in the new B\BOX.
>
> <grin> ;)
but only your demo. for all other stuff all the others do, it stays 1:1.
I'd love to see one of the counterexamples. gimme, I'm bored!
I'm bored because I can't think of a copperlist that couldn't be API
driven and so be in 4 windows....
aaah! copperlists that change not just pointers, but the wait positions vertical.
these would need a new rethinkdisplay. horiz change of pos could work.
BUT! API could still allow "lonely hw window" where you can mess around with
the waits, too. Amiga-M, and you're back on WB.
[This method currently is already possible on Amiga, unsing ucopl, undocumented.
this means, any cool copper stuff you can think about on Amiga, I can
make it go Amiga-M! however not legal.]
but: usual stuff like copperscreens, paralax etc could still be done API,
same speed.
>
>
> If I have a fast car, I dont wanna limit it to 30mph just because others may
> have problems, I dont get a fast car at all in this case.
this is not a good comparison as I'm talking about racing without dangers
which is unfortunately not possible with car racing (fortunately =;D )
Article Unavailable
Juergen Rally Fischer
Johan Rönnblom (JRo...@ba.ssdn.skellefte.se) wrote:
> Juergen, you make the 'lame', systemfriendly Quake clones that I'll play when I'm working
> with other programs in the background.
it is not lame, as hw hacked Quake would not be faster.
just because you don't need to hack copperlists to get quakedisplay.
> Phase5 finds out how Fabio does all his cool direct to H/W tricks, and puts the most useful
> bits into the API. Then Juergen's next game uses this, and everything gets better and better.
hey stop that shit talk :D
So, phase5 puts it in API so coders can use ?
thanks, you agreed to my issue about "most fx could as well be API driven".
=;)
Juergen Rally Fischer
Kyzer (u13...@sysa.abdn.ac.uk) wrote:
> Juergen "Rally" Fischer (fisc...@Informatik.TU-Muenchen.DE) wrote in alt.sys.amiga.demos:
> : unless we have robots playing games in future, 24bit will be
> : suficient forever. as well as 16bit sound...
> No, you're possibly :-) missing the point here. Remember 'crossfading'?
> Remember 'bitplanes'? Remember how parallax works?
> 128 bit would make an excellent set of 5 truecolour bitplanes, or 8
> 256-colour bitplanes, or ...
ARGH! your answer is of same sense like "but 24bit are not enough to
store more then 3 pixels, and a quake texture got more than 3pixels" ;)
> 128 bitplanes would be cool, but imagine the size of the palette :-)
and almost a frame needed to update by copper :D
Paul Kenneth Egell-Johnsen
Since we are still discussing hardware hacking vs. API.
An API would encapsulate the Hardware hacking, right?
Then you can call the API inline (i.e. with no overhead in a procedure
call, (moving stacks, etc.) BTW, I'm talking C/C++, it would be the same
in assembler, if the API was in assembler includes (or whatever you guys
call it:)).
Then when moving from A1200 to A\Box, the same API is available, your
favourite assembler and the API now hacks the A\Box hardware, delivering
the other services.
Where is the problem?
Paul K Egell-Johnsen
mailto:paul...@afrodite.hibu.no
http://afrodite.hibu.no:8001/paulken4/
Martin Steigerwald
Babbage schrieb in comp.sys.amiga.programmer ueber "Re: Phase5's A\BOX":
>where your code must be guaranteed that something else wont swap
>in and execute while its in the middle of something
>so you can put saftey locks around it with forbid/permit
This programming practice should be eradicated completely IMHO. OK, maybe
it still is needed to support Forbid(), Permit() for old applications
depending upon it... but programmers of new software should not even think
of locking a data structure access by blocking the whole multitasking
system. This way of blocking data structure access is simply stone-aged.
And at all... I surely would like to have Enable(), Disable() and
Forbid(), Permit() forbidden (e.g. replaced with dummy functions) for 3rd
party programmers! Wether and where to use those function in the OS
internally may be up to the OS developers. Those 4 function should be
*private* to the OS *core*.
And also no more rendering in input.task context and such... this isnt the
way it should be done.
Ideally on a new AmigaOS there would be NO situation where the mouse
pointer freezes... pull down menues should be non-blocking...(MagicMenu2.x
like), even layer locking should be reduced to the minimum. On those fast
machines we hopefully get more and more, it might even not be needed to
lock a layer to do a screen wide drag&drop action, as the dragged object
might be just a normal window moving realtime.
--
|_| _ |o _ _ Martin stei...@stud.uni-frankfurt.de Team
| |(/_||(_)_> Steigerwald http://home.pages.de/~helios AMIGA
"Thou shalt not battle over operating systems. I am wise and in My wisdom
have created diverse and various operating systems."
The Ten Usenet Commandments: One
Richard Allen
>
indeed
but still, at any one instance of time,
at any split second, the brain can only see around 8000 colours at once.
A split second later, it might be another 8000, and so on,
(I supose a bit like a 8bit palette out of a 24bit one)
lots of 8000`s make many millions
it still doesnt mean you can recognise a difference between them all
at the same time.
(Anyway, you try finding a computer screen around (in general)
that can display 16m colours at once to try it with =:)
>
And once you have found one try finding a picture to display on it which
has more than 500,000 colours in it.
Benjamin Hutchings
In article <32808C...@afrodite.hibu.no>,
Paul Kenneth Egell-Johnsen <paul...@afrodite.hibu.no> wrote:
>Since we are still discussing hardware hacking vs. API.
>
>An API would encapsulate the Hardware hacking, right?
>
>Then you can call the API inline (i.e. with no overhead in a procedure
>call, (moving stacks, etc.) BTW, I'm talking C/C++, it would be the same
>in assembler, if the API was in assembler includes (or whatever you guys
>call it:)).
No, you can't, because the *implementation* of the API is modular and
may be updated and upgraded to allow for games/demos to run on new systems
that the author could not test on or maybe didn't even know of. What you
are suggesting is just using macros for the calls, which if I understand
Fabio correctly is roughly what he does at the moment. Which often doesn't
work with machines significantly unlike the base A1200 he usually programs
for.
>Then when moving from A1200 to A\Box, the same API is available, your
>favourite assembler and the API now hacks the A\Box hardware, delivering
>the other services.
>
>Where is the problem?
You have to compile hundreds of different versions of the program for all
the different possible configs, and running the program on new hardware
is impossible if the programmer isn't willing to compile new versions later
on.
--
Ben Hutchings,|finger m95...@booth42.ecs.ox.ac.uk|mail benjamin.hutchings@
compsci&mathmo|lynx http://users.ox.ac.uk/~worc0223|worcester.oxford.ac.uk
Some mail sent on Saturday may have been lost, please resend if in doubt.
Beware of programmers who carry screwdrivers. - Leonard Brandwein
Porter Woodward
Paul Kenneth Egell-Johnsen (paul...@afrodite.hibu.no) wrote:
: Fabio Bizzetti wrote:
: >
: > http://www.phase5.de/news/aboxe.html
: >
: > Looks like a very nice custom chip (I remember some people that said it was
: > *impossible* both for development time and costs), and looks like the twin
: > of the custom device I wished and described (rasterlists), to provide e.g.
:
: What do you think about the 64 bit to the processor bus? Do you think
: that would be upgradeable in a future design. And what about 24 bits to
: the DMAs/DACs, isn't the current graphics cards at 128 bit?
Here's a quote from an article in November 1996's BYTE:
"Despite conventionalk wisdom that PC prices go nowhere but down, entry
level compters have been stuck at the $1200 to $1500 range for a decade
and have actually doubled in price from the early 1980s. Now that IBM,
Oracle, Sun Microsystems, and others are promoting economical network
computers, some PC vendors are exploring ways to make sub-$1000
systems without sacrificing.
Intel is taking a wait and see attitude. Cyrix, however is jumping in
with the Gx86, a highly integrated, low-cost PC-on-a-chip that allows a
full featured system to sell for about $800. Buyers would get a PC with a
Pentium 120 or 133 performance, 16MB of RAM, a hard-disk, a six-speed CD,
a modem, and input devices.
To make this possible, the Gx86 integrates several functions that normally
require extra chips. It has built in SVGA graphics, a PCI interface, and
16-bit soundblaster emulation. It also has a unified memory architecture
(UMA), which buffers screen data in main memory instead of in a separate
frame buffer. UMA can degrade performance, but Cyrix maintains the Gx86
avoids this by integrating the video logic with the CPU.
The CPU core is a stripped version of the Cyrix 6x86. It sacrifices
superscalar pipe-lines and speculative execution, but sill predicts
branches and retains a 16-KB cache. Although the Gx86 probably would not
do as well as a Pentium 120 or 133 when running a CPU level benchmark,
Cyrix claims the efficiencies of high integration allow the chip to
deliver that level of overall performance."
WOW - Does that sound familiar? Maybe it's just me, but it sure as hell
sounds a lot like the idea of the Caiphirana... Not that I mind. In
fact, that sort of thing makes a great deal of sense to me. It's really
just an extension of the Amiga "philosophy". Instead of having a tightly
integrated Custom chip-set with the CPU, the whole thing becomes a single
Chip. Alot like the ideas that were kicking around for the AAA set - just
roll all the custom chips into one.
Keep in mind that the Cyrix 6x86 P200+ is the fastest x86 compatible chip
on the market. It is easily faster than a 200 MHz Pentium (despite what
ever problems it has with Windows NT 4.0). It additionally boasts the
fastest I/O bus the desk-top market.
I'd really like to see something like this on the Amiga. Maybe not
coupling the CPU and all the chips, but coupling the the custom chips for
Gfx, sound, etc. Slap a PPC 604e in there, and BAM! Away you go.
In that same issue of BYTE, they benchmark the 225MHz PPC 604e. It is the
fastest single processor desktop system they have ever benchmarked. Keep
in mind that while the Alpha 21164 is a faster chip, it's not exactly a
main-stream desk-top system. Additionally, the PPC 604e runs at about
half the MHz of the Alpha - and is only slower by about 25 to 33%.
The PPC 604e blows the Pentium and Pentium Pro out of the water.
- Porter
--
//\ (wood...@tiac.net | wood...@acad.wit.edu)
// \ http://www.tiac.net/users/woodward/
\\ //----\ Out of sorts? Heck, I'm out of most algorithms.
\X/ \MiGA - Make up your own mind. "Spoon!"
Babbage
In article <55i623$i...@portal.gmu.edu>, msm...@mason2.gmu.edu (MICHAEL F. SMITH) writes:
> Frank Wille (fr...@phoenix.owl.de) wrote:
> : Avatar wrote:
>
> : > So how do you pronounce CAIPIRINHA?
> : >
> : > Important things first, of course!
>
> : Sounds portuguese in my ears. Maybe "CAYPIRINYA"? :)
>
> Or maybe kay-per-een-uh. What does it stand for, anyway?
>
> _
why didint they just call it the SEX chip or something!
babbage =:)
Babbage
> And once you have found one try finding a picture to display on it which
> has more than 500,000 colours in it.
easy =:)
Id just display a picture specially made up to have
16million colours in it
by people who want to see if they can see any
banding between pixels
*grin*
babbage =:)
Babbage
> Babbage schrieb in comp.sys.amiga.programmer ueber "Re: Phase5's A\BOX":
> >where your code must be guaranteed that something else wont swap
> >in and execute while its in the middle of something
> >so you can put saftey locks around it with forbid/permit
>
> This programming practice should be eradicated completely IMHO. OK, maybe
> it still is needed to support Forbid(), Permit() for old applications
> depending upon it... but programmers of new software should not even think
> of locking a data structure access by blocking the whole multitasking
> system. This way of blocking data structure access is simply stone-aged.
youve GOT to have some garenteed locking in there
in my opinion!
Anyway forbid/permit locking type things
are a DANG site easier than some of the other methods
you can use to lock stuff (eg. semaphore locking wank)
> Ideally on a new AmigaOS there would be NO situation where the mouse
> pointer freezes... pull down menues should be non-blocking...(MagicMenu2.x
> like), even layer locking should be reduced to the minimum. On those fast
> machines we hopefully get more and more, it might even not be needed to
> lock a layer to do a screen wide drag&drop action, as the dragged object
> might be just a normal window moving realtime.
there are all those other things out there in the big wide world as well =:)
babbage!
Jeroen T. Vermeulen
In article <Pine.BSI.3.95.961103...@vortex.netbistro.com> gau <g...@vortex.netbistro.com> writes:
> > It isn't. :) 24-bit is _not_ enough, mainly because 8-bit per primary
>
> Eight-bits per primary goes beyond the eye's ability to differentiate
> (geez this is *old* published information too).
Be careful with such "documented facts"! At one point not so very long ago for
instance it was believed that the human ear was unable to distinguish
frequencies beyond (what was it?) 9 kHz or something. The IETF is struggling
right now to overcome the old assumption that there were enough IP addresses for
the whole world. It's hard to predict what factors may come into play in the
future.
And, dare I say it, "640 Kb ought to be enough for anybody"! :-)
--
==========================================================================
# Jeroen T. Vermeulen \\"How are we doing?"// Yes, we use Amigas #
#--- j...@xs4all.nl ---\\"Same as always."//-- ... --#
#jver...@wi.leidenuniv.nl \\"That bad huh?"// Got a problem with that? #
Hey, you! Stop reading this Internet gibberish and get back to your work!
Babbage
> >As to it ever working, even when the amiga was "competitive", I didn't see
> >many games keeping the OS AT ALL (e.g. just taking over the view)
>
> The OS sucked for the needs of arcade games programmers, that's all.
> This issue was neither seen as a problem, because *the OS* was the problem.
I agree totally there,
so many things missing from the amiga OS that should be there
for games coding (and demos etc.)
babbage =:)
Paul Hsieh
Johan R=F6nnblom wrote:
> > Paul Hsieh wrote:
> > > PhiRatE wrote:
> > > > : http://www.phase5.de/news/aboxe.html
> > > >
> > > > [Drool-generating description of software-reprogrammable custom-c=
hip]
> > > >
> > > > [...] Now that WOULD kick a PC :))))))))
> > >
> > > Even if that PC had an MPACT Media-Processor in it? Go check out
> > > http://www.chromatic.com/ and http://www.mpact.com/
> =
> Sorry, I made an error in my last post, I'll try again..
> =
> Yes, even then IMHO. The only thing this MPACT thingy offers over the =
> A\Box is the use of RDram, which is supposedly faster than the SDram =
> used in the A\Box. =
Well, it also offers compatibility with the ever popular PC through
drivers, and the BIOS which are included. That may be irrelevant to
you, but its a multimillion dollar "feature" as far we are concerned.
> Although the figures given are up to 600MB/s for RDram, and up to =
> 1600MB/s for SDram, so I don't know. Also some figure of 1300 MB/s is =
> mentioned at the chromatic site, I don't know exactly what it means =
> though..
I don't know all the figures myself. All I know is its a hell of a lot
faster than the PCI bus, and allows real time non-frame dropping MPEG 2.
> Does anyone know more about this? I mean, if RDram shows to be better, =
> and it becomes the standard on PCs (making it affordable), Phase 5 =
> better start looking at how to support it..
RDRAMs are RAMBUS based. They are high throughput, high latency which
means that architecture and design play a big part in making use of =
them efficient.
> OTOH, what does the A\Box offer over the MPACT?
> =
> Programmable - won't be outdated as soon as MPEG and 1,000,000 =
> 50-pixel, textured, Gouraud-shaded, Z-buffered, =
> perspective corrected, bi-linear filtered, alpha =
> blended with fog triangles per second goes out of =
> fashion.
Lessee ... MPACT does all those things. Its programmable (though not
by end users) and there is a team of programmers dedicated to delivering
the latest capabilities like DVD, Wave Guide, Video Teleconferencing ...
> Unified memory access - means your computer won't complain about 'not =
> enough memory' when it in fact has lots of unused =
> memory available - but of the wrong kind.
This was the death of the original Amiga. (1) Sharing memory without =
a OS based protection mechanism (2) Paying performance penalties by
forcing all HOST Ram to run of the graphics clock. While I'm sure the
latest UMA standards have worked around some of these problems, I'm
told that the perfect high performance shared memory architecture has
yet to be invented.
> Hardware windows - this feature really sounds interesting. And you =
> might even be able to do something *useful* with it.
Well to me this means silicon has been wasted on implementing something
easily handled by software.
> Different colour description modes - I'm sure people will come up with =
> *lots* of uses for this.
I didn't read that far into the A\Box description.
> Besides - the MPACT is only a video card, =
Excuse me? Its a Modem, Audio and MPEG playback card too last I =
checked.
> while the A\Box is a computer, =
Right. Like the BeBOX, its compatible with nothing. And there is no
software for it. (According to the BeBOX web site, the onle game =
running on their system is NetHack.) Its foolish to underestimate the
importance of this.
> so no matter how good the MPACT would be, it wouldn't fix the crappy =
> overall design of PCs.
:o) You have to see it to believe it.
-- =
Paul Hsieh
qed "at" chromatic "dot" com
http://www.geocities.com/SiliconValley/9498
Graphics Programmer
Chromatic Research
What I say and what my company says are not always the same thing
Markus Castren
Babbage said about Re: Phase5's A\BOX:
>> PPC 603/604 have 64bit databuses anyway, it's the 620 that has a 128bit
>> bus.
>yeh and PHASE5
>PLEASE PLEASE PLEASE
[snip!]
>babbage =:)
Learn to quote you dork ;)
--
.---------------------------------+-----------------------------------.
| MARKUS CASTREN a.k.a. | EMail: sl...@xgw.fi |
| GANJA / NERVE AXiS | WWW: www.xgw.fi/~slice/ |
| A12oo/o3o/4o/6MB/85oMB/CD-ROM | The Official Gloom Pages: |
| AMiGA:MUSiC^GAMES^NET^SCENE^ETC | www.xgw.fi/~slice/gloom/gloom.html|
|_________________________________|___________________________________|
Fabio Bizzetti
PreScriptum: sorry for triggering also c.s.a.misc and comp.sys.amiga.hardware
but this is fully in topic, and I used much of my (little) free time to write
this reply, so it should be enough to not talk about my reasons anymore
( = write once for all ).
Juergen "Rally" Fischer (fisc...@Informatik.TU-Muenchen.DE) wrote:
>Fabio Bizzetti (bizz...@mbox.vol.it) wrote:
>> >IMHO the hardware should be shielded by providing an API for games.
>>
>> I will be happy to hack it, I hate silly rules that in concrete exist only
>> to make computers of today less performant than hardware-banged computers
>> of yesterday.
>and you are happy doing things with hacks that wouldn't need own copperlist.
>the display of VK would as well run in a intuiscreen (if it used the
>method you described).
Nope, you lose much of the quality because you lose the (interlaced or not)
"diagonal mask" effect. I know my stuffs, don't doubt. And even if the most
elementar use of it would be possible on a intuition_screen, all the more
advanced ones wouldn't be, anyway. Like a proper 2D game, where the copper
and the hardware sprites and the scrolling registers and the blitter have
to be really used and overworked.
It's always the same story: to print "hello world" on the screen you dont need
to program the hardware directly, but once some peple get that string on the
screen they think they can get everything in the same way..
>> I can release patches if the hardware changes, now modularity is a constant
>You can, that's Microsoft philosophy ;)
Then you think also that Microsoft invented multitasking. ;)
>> Even in old 2D games there's the need to write complex copperlists each
>> frame, to make complex scrolling and palette tricks hundreds/thousands
>> times every frame.
>yes, there is. and if gfx.lib would have had the features, you could have
>just written directly to a copperlist like you did. but it would work
>on A\Box now.
WHAT??
An API cannot be as efficent as hardware programming, by FAR, because the
more you try to make it as efficent as hardware programming, you make it
simply equal in a direct way to the hardware programming.
The choice then becomes:
1) Use the OS with all those hardware-specific tricks that dont work on
gfx boards, as copperlists, hardware sprites, etc.. you have to use the
native hardware anyway, also if you use it more or less through the OS.
2) Why bother then? Program the hardware God gave you, properly and
directly.
> and UAE maybe would have benefited as well.
Come on.. that's pure academical theorical talking!
Anybody (ehmm..) could write a much better emulator, programming the hardware
of the A\BOX specifically.
>> Is it clear enough?
>> You probably dont have in mind a lot of old 2D games, let away the ones
>> that have still to be programmed.
>>
>> Not only the OS has never let us use horizontal multiplexing sprites and
>> other fancy tricks, an API *cannot* lose its overhead (the becomes enormous
>> in all
>it might be possible that you now miss imagination ;)
I talk about the PARADOXES of APIs.
You can't run away from them:
[..] because it's an interface to the hardware.
It's something in the middle that requires CPU time, and cannot be tuned to
anything else than generical or well-known problems. I like to invent new
innovative stuffs, not to clone the old PC games.
An API cannot be as efficent as hardware programming, by FAR, because the
more you try to make it as efficent as hardware programming, you make it
simply equal in a direct way to the hardware programming.
The choice then becomes:
1) Use the OS with all those hardware-specific tricks that dont work on
gfx boards, as copperlists, hardware sprites, etc.. you have to use the
native hardware anyway, also if you use it more or less through the OS.
2) Why bother then? Program the hardware God gave you, properly and
directly.
>well, rasterfx are kinda out.
Oooops!!! O:)
>you were still not precise enough to tell fx which really would fail.
>maybe there are, tell. I blame for hacking those who don't need
>to be hacked.
You want me to program the A\BOX without having one yet (neither the precise
specifications)?
I anyway know the stuffs and the problems I am talking about, no doubt.
I've my experience, and I also designed an extremely equivalent device so
bet whatever you want that I've all the required clues to talk about these
problems.
Your affirmation "well, rasterfx are kinda out" is enough for me to not need
to go on. It would be already sufficient this big (for me) rasterfx limitation,
and I could continue (but is not necessary as you see) if I had free time that
I have not, I prefer to add more tracks to VKDeluxe with this free time instead.
>> An API cannot be as efficent as hardware programming, by FAR, because the
>> more you try to make it as efficent as hardware programming, you make it
>> simply equal in a direct way to the hardware programming.
>>
>> The choice then becomes:
>> 1) Use the OS with all those hardware-specific tricks that dont work on
>> gfx boards, as copperlists, hardware sprites, etc.. you have to use the
>> native hardware anyway, also if you use it more or less through the OS.
>> 2) Why bother then? Program the hardware God gave you, properly and
>> directly.
>>
>> An API cannot be as efficent as hardware programming, by FAR, because the
>> more you try to make it as efficent as hardware programming, you make it
>> simply equal in a direct way to the hardware programming.
>maybe. it's just that my demo runs on A\Box.
Also mine, under the Amiga emulator someone or me will write (my Vic20
emulator was a nice piece of software technology IMHO.. much faster than
the ones I've seen around (i.e. C64 emulators) on the A500).
Talking about possible (IYO) A\BOX -> B\BOX problems, my demo on the old
A\BOX outperforms of 10:1 your OS demo in the new B\BOX anyway..
And I will write a much better version for the B\BOX (that anyway, that you
believe or not, is going to be hardware compatible with the A\BOX due to its
programmable design, that not many people showed to have really understood).
You see, compatibility is reachable by me, it's only a question to release
some patches for a machine alive and kicking. If the machine is dead (read:
no more hardware improvements and few people that buy 3rd party gfx boards,
as some did on the Amiga) then the machine is dead anyway and it's pointless
to continue with it, I certainly wouldn't support PC UVGA boards on the A\BOX.
>> >> Can't you already see the limitations? I can, and will program every
>> >> piece of the hardware that has to be programmed directly..
>> >>
>> >> >This and clever graphx drivers
>> >>
>> >> Who writes them? Besides that "clever gfx drivers" dont exist because
>> >> they've to be generical anyway.
>>
>> >it doesn't care. we're in a tech discussion.
>>
>> It matters instead!
>> "Tech discussion" means about what is useful, not pure useless nice theory.
>Ok, then you say as due to marketsituation is is not possible, I hack.
>Ok.
>But don't tell me there would be no different way, speaking about tech stuff.
>for example demos are pure tech stuff and I care shit about market. If we
>talk about what APIs can do, we are in tech stuff.
1) Dont you think that the issue of performances is important in demos as well?
2) What do you think, that demo programmers (known as the most creative and
innovative around, that like challenges, etc..) will use Direct3D and calm
down their creativity, maybe just becoming simple demo "designers"??
Your coercive current is going to provoke the biggest "hackers revolution"
in the history of personal computers.. :)
>> >the driver which got the poor job to do it on standard vga would
>> >have to build the lionhart-scroller with copying lines. slow, but
>> >it'd work.
>>
>> Who cares?
>> Then run UAE, slow but it works.
>but UAE is slower than API driven lionhart would be on gfx-card.
But at least doesn't force the world to write lame games, so at the end is
the very best (and most natural) solution.
I care about the performances of present more than the performances of the
same software in the future; then there will be new software anyway, updated
as the hardware.
Even utilities that dont get upgraded become obsolete quickly..
You talk in an equivalent way to "get a Vespa a walk by feet", "then get
a Suzuki and dont go faster than 50 Km/h", "then get a Ferrari and dont
go more than 160 Km/h", "then get a spaceship and go below 320 Km/h".
What are we, grannies? ;)
>> I've even huger speed differences in mind once I get a programmable
>> chipset.
>so what you say is true for what you got in mind, but people might
>believe it is true for all those demos/games out there. it isn't, for
>most of them.
Surely if you clone PC stuffs you're right.
Do you know why the Amiga games sucked for many years?
Conversions from PC and Atari ST.
If ( = when ) I'll write A\BOX games, they will not be the conversion of PC
versions, there's space for a lot of programming originality, it's the PC
that can adapt itself (with a more or less "hardware abstraction") because
it's it that sucks and is only a CPU and a framebuffer, lame as much as
possible..
I bet it's easy to "virtualize" the hardware of a PC!! Where is it, anyway? ;D
>> >> >would have leaded to rasterfx (lionhart) games beeing playable on
>> >> >gfx-card now.
>> >>
>> >> Bah.. maybe on a ZorroII gfx board?
>>
>> >yep. maybe slow, but works.
>>
>> Emulation is the key for that, and a "new generation" programmable hardware
>> as the one in the A\BOX can provide excellent emulation, so..
>but API driven generated copperlist would do you A500 stuff
>directly on A\Box copper now!
Too bad we would have got LAME A500 games then!!!
Besides: every OS designer has always disappointed from this point of view
anyway: what do you expect, the perfect game OS next time?? Sounds naive..
The 2D world is not only Worms (a BlitzBasic game, BTW!) or Lionheart.
>> >> With the A\BOX the abyss between "it can be done on standard gfx
>> >> devices" and "it can be done FAST ENOUGH on standard gfx devices" will
>> >> be even bigger than it was with Amiga OCS and CGA/EGA/VGA of that time.
>>
>> >hardware windows ? or what ? don't hesitate to give me a example
>> >where my talk is wrong.
>>
>> I dont have time to waste, sorry.
>> I should pack and send all the articles I posted in the past, so you can
>> read them.
>You didn't write different in them like you do now.
>"imagination" etc etc. not one single solid example.
You want me to program the A\BOX without having one yet (neither the precise
specifications)?
I anyway know the stuffs and the problems I am talking about, no doubt.
I've my experience, and I also designed an extremely equivalent device so
bet whatever you want that I've all the required clues to talk about these
problems.
Your affirmation "well, rasterfx are kinda out" is enough for me to not need
to go on. It would be already sufficient this big (for me) rasterfx limitation,
and I could continue (but is not necessary as you see) if I had free time that
I have not, I prefer to add more tracks to VKDeluxe with this free time instead.
>ok, if your secret-imagination-fx needs hacking A\Box,
My 3D engine does, and I was happy reading that they didn't put a standard
polygons chips, but a programmable one "adapt to 3D algorithms that will be
invented in the future".
This is what I call WISE DESIGNERS!!! 8)
We are convinced that the PowerPC will have a future: why not these
coprocessors? They're programmable CPU's anyway!
Or the next brilliant idea you will think of is that everyone must use JAVA?
1/100 of the speed but, well, our demo works the same identical (also speed!)
on a PC!!!
Your coercive current is going to provoke the biggest "hackers revolution"
in the history of personal computers.. :)
>then I won't blame you. I blame you for telling us hw hack is nessesary,
As opposite as many people here, I NEVER say/said "everyone must do this way",
I always say how *I* personally do and wanna do my stuffs, then from these
discussion (like the one we're doing) people get their ideas and decide what
is better for themselves, each one with his brain.
>> >> >> Nobody thinks that you can run the real games of A\BOX on another
>> >> >> hardware.. through the WritePixel(tm) "abstraction of the hardware",
>> >> >> it works on SVGA, perhaps, not on such clever custom hardware.
>> >>
>> >> >actually lot of the SVGA stuff does lot of hw acess.
>> >>
>> >> What? The VESA driver? ;)
>>
>> >polling vblank bit.
>>
>> WHO ever did that?
>my frinds vector demo for example.
Then it doesn't work on my card.. bad!
He should use the PIT timer instead, in my very personal opinion..
>> Read the whole phrase I wrote before cutting it in the middle.
>I maybe misunderstood. seen the lepoviatan commercial ? :)
Nope, we barely got televisions here in Italy. :^)
Well, I dont see much television anyway, if I wanna see a movie I rent it.
>> >> >those hwwindows might be useful for 2d sprites,
>> >>
>> >> HOW DO YOU KNOW??
>>
>> >oh if a hwwindow can be transparent it is a sprite you know.
>>
>> I meant.. you can't decide NOW what will be useful and what will not.
>> Are you Coders'God that writes the Ten Commandments of coders?
>It's just that lot known stuff can go API. can't talk about unnkown.
For me only "unknown" is the hope to break the limits everyday, to not bore
people that left the Amiga because it has been the same for years, and then
they got a PC for this reason.
>> >> You're starting to talk as those academical engineers that didn't give
>> >> chunky gfx to the Amiga "just because we dont see how it could be
>> >> useful...<yawn>".
>>
>> >hehe, he called me academic =:D
>>
>> That's how you look like in those words.
>>
>yeah I'm da c0ding aCad3mic.
Getting the best defects of both? ;-)
>> >imagine copper driven demo on A\Box.
>> >now I want to watch 4 of them in 4 windows on a B\Box.
>>
>> Useless.
>having a glance if my download is ready while demo is running.
Pointless, you can't download 2000 demos / day anyway, who writes so many?
And anyway I wish all the I/O to be made 100% through an OS basic kernel,
unless it sucks again as on the Amiga.
>> >your copper hack fails and my lame api demo wins ;)
>>
>> But my demo on the old A\BOX outperforms of 10:1 your OS demo in the new
>> B\BOX.
>>
>> <grin> ;)
>but only your demo. for all other stuff all the others do, it stays 1:1.
I dont think so: it has been years that the Amiga lost its best developers,
~only people that clone PC games remained..
>I'd love to see one of the counterexamples. gimme, I'm bored!
>I'm bored because I can't think of a copperlist that couldn't be API
>driven and so be in 4 windows....
You know the CAIPIRINHA is programmable, you probably have read my postings
(the public Usenet thread with Dr Peter Kittel) about how to program such a
design, you probably even know (and hope fully understand) the AgaEXTENDER:
<tsb>
You dont have hardware functions (as sprites, rotation, scaling, strange
video modes/special_color_formats), you program the chip to provide them.
How? Writing a rasterlist. A rasterlist is "microcode" that describes all the
operations that the display has to perform, thus not in a fixed way anymore:
this way you can reprogram all the power of the video chip to generate a real
text mode, or a map blocks mode, or the most important stage of my 3D engine,
or sprites, or hardware windows, or planars modes, or chunky modes, or alien
modes, apparently infinite parallax levels ( = no need to copy what is not
visible): WHATEVER you may think of, you must rewrite part of the rasterlist
everytime something has to change on the screen.
<tsb>
You wanna use a realtime (!) high-level compiler to generate this microcode!!!
Instead this rasterlist processor can finally be designed future-wise, and be
upgraded as clock speed and bandwidth, as also Phase5 said they will do, and
eventually add _extra_ functions: as in a true CPU.
Perhaps the next brilliant idea you'll have is that everyone must use JAVA?
1/100 of the speed but, well, our demo works the same identical (also speed!)
on a lame PC!!!
Your coercive current is going to provoke the biggest "hackers revolution"
in the history of personal computers.. :)
Damn.. this seems written from an automa, I am copying/pasting text all
around just to repeat it enough times than it requires to be clear as much
as it really is..
>> If I have a fast car, I dont wanna limit it to 30mph just because others
>> may have problems, I dont get a fast car at all in this case.
>this is not a good comparison as I'm talking about racing without dangers
>which is unfortunately not possible with car racing (fortunately =;D )
I dont understand what you mean, anyway, fast cars give more active and
passive sureness than crap slow family cars..
>> >> >how about giving some examples where hw hack on that machine
>> >> >would do things you need hw hack for.
>> >>
>> >> I dont need to waste my time this way, download and read all the
>> >> postings I made on c.s.a in the last year, I ain't going to rewrite all
>> >> again for you..
>>
>> >now you took the effort to write multiple times that you don't talk
>> >to me because I got different oppinion.
>> >you could have written a 60char line ginving an example.
>>
>> >give me an example proving me wrong and will will have to eat it.
>>
>> Good lunch, there's too much to eat.
>>
>> Repeating the stuff of above:
>threre was nothing I had to eat. you gave me nothing to think about,
>yawn =:o
Read above and wake up finally!! :)
>I got some ideas by myself now. however they are not used in 99% of
>all games/demos! it's just all those 99% of programmers could do
>legal rasterfx if the API was done. still same fx, still same amount
>of phantasy, freedom to do a demo.
You refer to the last years of Amiga demos: crap PC clones.
The PC scene envys of the Amiga the old A500 demos, and they are bored of
what you call a "modern Amiga demo".
>> ---
>> You will use the OS, I will program the hardware directly.
>> You know what you want, I know what I want.
>> Then if anything has to be discussed, it's the comparation of the results
>> we care about: mine is performances, yours is compatibility. You will not
>> get
>nononono. this sounds like "yours is slower due to using OS".
>It isn't, because you do something different.
>For those things I talk about, they'd be 1:1.
Doom 5?
>> performances, I will get compatibility with some simple patches as long as
>> it will be worth to upgrade an old game, instead of making its stunning
>> sequel on the B/BOX.
>>
>> You make your choices, I make mine..
>If it really is 3.1 compatible, my demo will work =) aaaaaah.
As on the Draco? aaaaaaah. ;)
Requoting:
---
>but UAE is slower than API driven lionhart would be on gfx-card.
But at least doesn't force the world to write lame games, so at the end is
the very best (and most natural) solution.
I care about the performances of present more than the performances of the
same software in the future; then there will be new software anyway, updated
as the hardware.
Even utilities that dont get upgraded become obsolete quickly..
---
>but API driven generated copperlist would do you A500 stuff
>directly on A\Box copper now!
Too bad we would have got LAME A500 games then!!!
Besides: every OS designer has always disappointed from this point of view
anyway: what do you expect, the perfect game OS next time?? Sounds naive..
The 2D world is not only Worms (a BlitzBasic game, BTW!) or Lionheart.
---
>-------------------------------------------------------------------------
> fisc...@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) =:)
>
> http://www.informatik.tu-muenchen.de/~fischerj/
PS: again! (never enough) :)
Article Unavailable
Fabio Bizzetti
Paul Kenneth Egell-Johnsen (paul...@afrodite.hibu.no) wrote:
>Since we are still discussing hardware hacking vs. API.
>An API would encapsulate the Hardware hacking, right?
>Then you can call the API inline (i.e. with no overhead in a procedure
>call, (moving stacks, etc.) BTW, I'm talking C/C++, it would be the same
>in assembler, if the API was in assembler includes (or whatever you guys
>call it:)).
What's the point then?
You would need to re-compile (or re-assemble) the code anyway, and I've even
better solutions in this case (write your own special language and compiler).
Your games will not get more compatibility anyway, unless you use JAVA.. (no!)
>Then when moving from A1200 to A\Box, the same API is available, your
>favourite assembler and the API now hacks the A\Box hardware, delivering
>the other services.
What do the AGA and CAIPIRINHA have really in common?
It's like pretending to do it from C64 to OCS: rewrite the game and you save
time and also get better quality.
>Where is the problem?
O;)
>Paul K Egell-Johnsen
---------------------------------------
Fabio Bizzetti - bizz...@mbox.vol.it
Fabio Bizzetti
Roger Wong (ro...@powhq.nildram.co.uk) wrote:
> On a reflective medium such as paper, people can distinguish
>between even more. At the Jet Propulsion Lab in the 70's, the color
>research people came up with a way to print more than 50,000,000
>precise colors on paper. They printed words out in various colors,
>each one on a background that was only one color index away from the
>word's color. No one had any trouble reading any of the words; the
>human eye is both sensitive to color degradations and good at edge
>detection.
Then you could distiguish 50,000,000 colors also on monitors if you
played with contrast/brightness trimmers.. same principle.
> Roger Wong's
> THE UNOFFICIAL C&C STRATEGY FAQ
> http://www10.torget.se/temple
Dr. Peter Kittel
In article <55i623$i...@portal.gmu.edu> msm...@mason2.gmu.edu (MICHAEL F. SMITH) writes:
>Frank Wille (fr...@phoenix.owl.de) wrote:
>: Avatar wrote:
>
>: > So how do you pronounce CAIPIRINHA?
>: >
>: > Important things first, of course!
>
>: Sounds portuguese in my ears. Maybe "CAYPIRINYA"? :)
>
>Or maybe kay-per-een-uh. What does it stand for, anyway?
No, you pronounce it Kye-pee-rin-ya.
--
Best Regards, Dr. Peter Kittel // http://www.pios.de of PIOS
Private Site in Frankfurt, Germany \X/ office: pet...@pios.de
Christer Bjarnemo
On 05-Nov-96 12:38:54, Babbage wrote about Re: Phase5's A\BOX.
>(Anyway, you try finding a computer screen around (in general)
>that can display 16m colours at once to try it with =:)
I wonder if my 1084 can handle 4096x4096 to cover 16m pixels? :-)
The only problem is that i don't have ~5Omb gfx memory to hold the screen! :-)
(Imagine AB3D's byte-c2p dealing with 50mb every frame! :-)
--
Christer Bjarnemo My 8 bit Corner (now with games to dl):
Author of nothing useful http://www.interbalc.se/sales/christer/
--
Ian Gledhill
Fabio Bizzetti wrote:
>
> Indeed!
> I think I will be one of the pioneers in A\BOX games hardware banging <grin> :)
> In the while, I've some PowerPC manuals to study to warm those custom chips. :D
Of course, Hardware banging probably isn't a good thing....
BUT...
can you imagine the performance you'd get out of that beastie if you
write at the
very lowest level!! <drool>
Emmanuel Henné
Emmanuel Henné starrte gebannt auf die Nachricht von
Dr. Peter,die urplötzlich auf seinem PowerAmiga-Monitor
erschien und beschloss, auf den Betreff `Re: Phase5's A\BOX'
folgendes zu erwidern.....
DK> In article <N.110296....@dynamic202.i-way.co.uk> ava...@patrol.i-way.co.uk (Avatar) writes:
DK> >
DK> >So how do you pronounce CAIPIRINHA?
DK>
DK> Kye-pee-rin-ya
That seems to me like a holy person from Bajor ?!
Any trekkers around ???
Ciao,
Roi
ææææOO#m_ ææOOOæw O#N 1200-68060-18 MB RAM
OOO@"- OO, OOO@"°OOÑ OO# Workin` on PHOENIX
OOOOOOP ]OO# 7OO# OOO
OOO# OÑF ¬ ÑOOOOÑ' OOO @HOTLINE.PFALZ.DE
----------------------------------------------------
"Microsoft Dynamic RAM-o-Meter: Available HiMEM, LOWMEM, Protected MEM,
Enhanced MEM, Shadow RAM..."