Newsgroups: comp.sys.amiga.misc,comp.sys.amiga.advocacy,comp.sys.amiga.hardware
From: dnavas@oracle.uucp (David Navas)
Subject: Re: WOC Toronto: Amiga's Future
Organization: Oracle Corporation, Redwood Shores CA
Date: Tue, 15 Dec 1992 17:35:35 GMT
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

To csa.hardware to attempt to get clarification from some kind of person
who knows :)
There are a LOT of questions here, and anyone that knows anything about what
was said, or even simple things like chip design cycles are welcome to
respond.

Please followup to the appropriate newsgroup, though.  I read all three,
thanks.

In article <20068@ucdavis.ucdavis.edu> Shawn_E_Switenky@engr.usask.ca (Shawn E Switenky) writes:
>[ Thanks for putting in the work, Shawn!     -Dan             ]

Indeed.
And now, a few questions if you please.

>pleasure of sitting next to him for the Saturday night seminar.  He is a

Is it public what was covered in the Sat. night seminar -- I didn't see any
specific mention of it?  If you compiled both seminars into these posts,
nice job!  Of course, I like my news -raw- rather than well-done :)

[cringe]  anyway.

>Low End:
>	- 57 MHz Pixel Clock

This isn't the gfx bus speed, just the pixel clock.  From what I gather here,
the bus speed will be 14Mhz, correct?

Anyway, that's a 17ns pixel -- which is what we need for 1024x768x60, right?
Any mention of such a mode?

>	- 8x Memory Bandwidth Increase

This is relative to?  ECS?  AGA?
This is memory bandwidth from CPU to CHIPbus or CHIPbus to video?
And on what machine architecture (if the former -- memory bandwidth is
already different between the CPU and the CHIPbus in the A3000 vs. the A500,
for example).

>	- 2x Blitter Performance ( gets twice as many clocks as on AGA )

Yeah, for free.  This, along with the 100% backwards compatible makes it
yet-again a 16bit blitter.  Sigh....

>	- 800x600x8bit Non-Interlace 72Hz Refresh Rate

Goodness, I should hope so.

>	- Larger screens at lower Refresh Rates

;)  Specifically?  Like 1024x768x60 for example?  I could really dig a $700
computer (A1200+) that did that ;)

>	- 16 bit True Color mode ( although recent developments with the
>	  completion of the first cycle of chipset design indicate that this
>	  will actually be a 24 bit True Color Mode )

As Ty pointed out to me in email, this sounds rather the funny thing to say.
I mean, they asked for a 16bit TC mode and it came back from the designers
with an extra 8bits layed out or something?  ;)

What resolution would such a mode run in?  And goodness, does this mean 24
separate bitplanes.  Yeesh!

>	- FIFO serial ports

About time.  Will this include DMA as well (like, say, the IIfx?).

>	- increased Chip Ram ( 8Mb )

Good idea ;)  How are they going to make this 100% backwards compatible
though?  Are they ripping ZorroII space into Chip RAM?  Personally, I've
always thought it a good idea for ZII memory-space to become fully
devoted to CHIP (except maybe the IO space).

All in all, pretty reasonable for, say, six months in the future.
My guess is that it's going to be longer than that, in which case a DRAM
backwards compatible chipset seems kinda silly.

---

>High End:
>	- 4 Chips ( 750k transistors each )

Each or total?  I seem to remember these being -totals- in the WOC Pasadena
address?

>	- 32/64 bit VRAM Chip Memory ( could be DRAM for mid range machines )

Pass on the DRAM please.  64bit VRAM seems like a minimum for work designed
to be one year in the future.  128bit would have been better....
[Hey, I can't afford an SGI, doesn't mean I don't want one :)]

>	- 57/114 MHz pixel clock

Hmm, 1280x1280x60 pretty easily there....  That seems very reasonable for
future chipsets.

>	- Chunky Pixel Mode as well as Bit Planes Modes ( Blitter works with
>	  both )

About time -- 24bitplanes are kinda sloppy...
Plus bitplanes and wide busses often give rise to bizarre alignment pre-
conditions....

>	- 1280 x 1024 24 bit color 72 Hz Refresh Rate

Okay, BIG quesiton here.  This is REALLY THE QUESTION I'm posting this
whole message because of!

Is this really 1280x1024x24?  Or is it simply a note that says -- hey,
we have a 24bit palette in our hi-res mode?  The former is impressive, the
latter is marketing ;)

>	- 16 bit 8 channel 100KHz sampling rate Audio ports

Impressive. So is lots of other stuff.  Let's hope they get the
audio state machine -fixed- this time :)

>	- New 'On-Demand' DMA Architecture for Balanced DMA Usage

You're kidding, right?  This is for us "balanced" dweebs out there that
keep longing for the days when our systems seemed "balanced".

What the devil does this really mean?

>	- 12 to 20 x Memory Bandwidth Increase ( mostly from VRAM )

AGAIN!  Over ECS, over AGA?  20x over ECS doesn't give me a non-interlaced
1280x1024x24 screen.  Or is this memory bandwidth related to CPU<-->chip
as opposed to chip-->video?  I imagine quite a rise in bandwidth given the
higher bus clock (28Mhz?) and the use of dual-ported VRAM....

20x over AGA is too incredible to believe.

What I really want to know is -- what are the max. screen modes -- what
resolutions, what "bitplane" depth?

1024x768x24 seems to be a minimum from where I stand, interpolating one
year into the future....  3-5x AGA screen resolutions, though, seems still
like catchup to current SVGA bandwidth -- hardly the right target to
shoot at.  [Eliminate FUD, thank you :)]

>	- 24 bit True Color Mode

Guess the question (hint: resolution?).

>	- Video Upgrade module ( You can add more chips for parallel processing
>	 chip set i.e. multiple blitters, and Higher Resolution Display Modes )

Like I really am going to believe this?
Really, I'd prefer a wider CHIPbus....  What is more than one blitter going
to do for me?  I've only -got- one bloody bus (or do I?).
 
>	- Hardware Graphics Decompression Modes

GDM == HAM/DYUV/MPEG?  This is a great way to market HAM, is that what they're
doing or are we getting real-time JPEG or something like that....

>	- ECS & AGA compatibility

Sure....

>	- 32 bit Processor Independent Processor Bus ( hinted at RISC by 
>	  calling the bus 'RISC ready' )

It actually sounds like Lew is trying to raise market expectations for
RISC in the public, forcing Cmdre's upper management to actually commit
to such a product.  This is not unheard of, though it's a really crappy
way to run a company.  If true, this is hardly Lew's fault....

At anyrate, I'm all for RISC, so tell me the dweeb I have to shoot to make
this possible :)

This sounds like an interesting bus, though....

>- There are no plans for virtual memory.

Bad, very bad.  For a hardware person, ain't doing too bad.  But this is
a VERY BAD MISTAKE INDEED!  [Hint -- saying "we won't..." will illicit this
type of response....]

>- Commodore will release a series of Quad-Syncing monitors in February to 
>  replace their current series.

I'll pay the extra price for a Japanese as opposed to Taiwanese import....
I don't want my video having the "shakes" or the "shimmies" thank you, and
every 1950 monitor I've ever seen looks like it needs additional shielding....

>- Full motion video support is well on its way.  The feature is here now, but
>  the development systems for this technology is not.

Software....

>- Prime goal with the CDTV is to cost reduce it and then enhance it.

Got that upside down, methinks.

>  Instead of being last to bring something out, Commodore is
>  going to be first or second.

I'll be the judge of that...

>- DSP technology will be available for the A4000 in summer.  DSP will feature
>  the AT&T 32000 series DSP and a 68040 processor module for the A4000.  A

AT&T 32000?  AT&T3210?  AT&T32C?
Never heard of the first, might it be ne of the last two?  :)

>- A new, higher performance Ethernet card will be available soon, after

IE: ZIII?

>- Retargetablity is a major goal, and Audio will merge with DSP ( this didn't

Well, our friendly audio system's state machine is kinda messy anyway, I
wouldn't mind seeing something better....

>  The NewTek people are very difficult to 
>  work with and are resistant to change.

Does this remind us of someone?  It's almost a sure sign that, in a battle
between two foes, the accusations that come out of mouth A are more
applicable to person A than person B....  :)
Hence, I suppose, the phrase "takes one to know one."

>  I believe he said that if you had one, you can have it fixed on your
>warrantee.

I'd rather have it fixed on my desk  (da dum).
[Light humor, make sure I don't get flamed for other things I'm saying here]

>More than one year....

It was more than one year in September.  It should no longer be more than
one year :)  Not if they truly want to be "first or second".  That concerns
the high-end.  While the low-end is interesting, if the high-end is
promising I could live without it....  :)  Assuming the high-end found its
way into an A1200 style computer....

>First design cycle....

Someone familiar with chip design cycles?  What does this mean?  How many
cycles does one usually go through?  Does this mean they have a prototype
on someone's desk, or just that the design got run on a simulator?

>  The results of this cycle are better than expected and they
>  are ahead of their development plan.

Cmdre's design did always seem to be conservative (expecting the worst) --
except maybe where heat dissipation is concerned :)

>While he did metion that the exact CPU has not been decided,

If something as basic as a CPU hasn't been decided on, then I can only
conclude that this is a pipe-dream.  An interesting one, to be sure, but
one that hasn't been sold to the people that say "OK, go do it".

Opinion only, as usual.

>a RISC Amiga will be able to run not only UNIX, but Windows NT.

Well, if ever I heard a reason for NTs demise :) :)

>I am very excited about the future of the Amiga.  The new features are
>nice, but the best part is that, clearly, Commodore has a plan.  This plan

Bingo -- a plan is good.
A plan is long overdue.
A plan that says "we will do" instead of "we won't do/it's hard for us to do/
it takes time for us to do" is, like, way OVERdue....
Now, I'd like that same logic applied to the software.  Where VM and Mem.
Prot. is concerned we're still in the "we won't do" phase.  It's going to
be a long haul, sigh....

>[Lew] is very capable and has had much success in the industry.

Let's try and keep this one in a position to make a difference, shall we?

David C. Navas						dnavas@oracle.com
Working for, but not speaking on behalf of, Oracle Corp.
Newsgroups: comp.sys.amiga.misc