Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!jarthur!nntp-server.caltech.edu!toddpw From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel) Newsgroups: comp.sys.apple2 Subject: Re: ASIC Prototype Message-ID: <1991Apr20.091354.5831@nntp-server.caltech.edu> Date: 20 Apr 91 09:13:54 GMT References: <9104192207.AA07944@apple.com> <10705@hub.ucsb.edu> Organization: California Institute of Technology, Pasadena Lines: 78 6600prao@ucsbuxa.ucsb.edu (Parik Rao) writes: >BTW, didn't tony say that "a large texas company" had bought the rights >to the chip about 1 year ago? And now, AE techs state emphatically that >they have NO PLANS WHATSOEVER to upgrade the chip speed beyond 7 mhz (claiming >the 32k cache is 'ns). That's because the TWGS would melt. Fixing it would be too much effort, and given their current attitude toward their customers... >I am very confused... maybe I'm just misinterpreting Jawaid's stance as a >beta-tester/developer relation, but it seems to me that giving a chip to 1 >person and saying "here, do whatever" hardly constitutes a trial run of >it. I thought the 65816asic wasn't even pin compatible with the wdc. I think he said he has to give it back. The chip is pin compatible, people are just confused about the difference between DIPs and PLCCs. The motherboard CPU is a DIP, but the TWGS and ZipGS use PLCC versions. The packaging is an option provided by the fab house, so they could make either if they wanted. Unless Jawaid has a socket adapter he's got to have a DIP because he said he didn't have and accelerator yet. >And I know the TWGS can't go beyond 13 mhz, and the Zip Chip around >the same (some max out at 10, a minute few at 14 [or so I'm told... >mine won't go past 10]). Zip's tech guy told me (in person, ooh ahh) that the simulator runs indicated the cache controller should run with a 20 mhz CPU. The cache hit latency is 10 ns plus the cache RAM access, and the data/tag chips are the same speed so the instant the cache hit comes in the cache data is also ready. I've just done some tests that indicate the Zip is using latch-on-write for GS bus writes, with a clocked 1 Mhz data rate storing data to the slow RAM. These tests were done on a 10 Mhz Zip with assembly routines written by myself (16x iteration of the unit macro, executed 64k times). I made the following assumptions and I believe they hold: loop is not noticably kicked from the cache (unless sever IRQ overhead occurs, like AppleTalk, which occasionally caused data points that I discarded) loop overhead is negligable (it was 3.1% at most and later 1.5%) system interrupt overhead is negligable (I used GetTick twice and subtracted to get the tick figures below; .5's indicate waffling on successive executions) except for AppleTalk (somebody opens Chooser on a Mac and whammo, I get two extra ticks in the count) The results I got: # of fast cycles average # of ticks to execute approximate time betwen slow writes 1 meg (64k * 16) operations to write (8 bit store) 3 64 1.017 uS 4-5 67 1.069 uS 6-8 67.5 1.072 uS 9 94.5 1.502 uS 10 98 1.557 uS 11 99 1.573 uS 12 110.5 1.756 uS 13 112 1.780 uS 14 120.5 1.915 uS 15 128 2.034 uS This means the Zip (at any speed) could clear the screen at 1 Mb/s if the screen clear code is a string of PHA's or something similar. I believe this is how FillRect works, so you get quickly appearing dialogs and erased windows and such. What I want to know is why the bitmap transfer code (for say, background pictures) doesn't do this for large rects. It is not hard to write code that transfers an arbitrary bitmap onto the screen at high speed using the stack mapping technique. The Zip makes the programmed move the desktop picture is currently drawn with almost as fast as stack-mapping on a stock machine... Todd Whitesel toddpw @ tybalt.caltech.edu P.S. This latch-on-write feature is partly to blame for the AppleTalk compatibility problems -- it's a long story so I won't go into it unless anybody's interested.