s255@sol1.UUCP (alcmist) (01/21/86)
The Hyperdrive 2000, if you haven't heard, is General Computer's newest product for the Mac. The package includes a 20M internal disk, RAM to bring your machine up to 2M, a 68881 floating-point coprocessor and a 12 Mhz 68000. (I hope I got that right). I called GCC today for some details. The person who answered the phone quoted a retail price of $3195 with availability in April. That's the price for installation in a regular old Fat Mac. Owners of Hyperdrive 20's will be able to upgrade for $1995. It will be able to run HFS, since GCC promises HFS software for the first week of April. Over on Compuserve, Andy Hertzfeld said that some code in the ROM was timing sensitive. The GCC person to whom I talked did not have any information on whether the faster 68000 would break software or not. Also she did not know what policy would be on upgrades for people with 10M Hyperdrives. I invite the folks from GCC to correct or expand on this article. I'm practically drooling about the product and I want to know more about it. -Fred Wamsley ihnp4!sol1!s255
berger@datacube.UUCP (01/27/86)
HFS not untill April?!!!!!!!!!!!!!!!
That's what I call responsiveness (sarcasim from disgust)
I myself feel riped off as one who paid $2300 for a Hyperdrive 20.
GCC seems to be going further and further away from being compatable
and complementary to Apple products.
I suspect GCC will either die or have to lower its prices dramatically
when there are SCSI disks for $500....
[usuall disclaimer]
Bob Berger
Datacube Inc. 4 Dearborn Rd. Peabody, Ma 01960 617-535-6644
ihnp4!datacube!berger
decvax!cca!mirror!datacube!berger
{mit-eddie,cyb0vax}!mirror!datacube!bergerralphw@ius2.cs.cmu.edu.UUCP (01/27/86)
In article <412@sol1.UUCP> s255@sol1.UUCP (alcmist) writes: >The Hyperdrive 2000... includes a ... 68881 floating-point coprocessor and a >12 Mhz 68000. (I hope I got that right)... The person... did not have any >information on whether the faster 68000 would break software or not. If it breaks software, then they might as well use a 16 Mhz 68020 and break even more software :-) Seriously, one could still use the 68000 for software compatibility, ROM calls, and other I/O tasks (like disk cache control), and the 'meat' of the applications could be run on the 68020. -- - Ralph W. Hyre, Jr. Internet: ralphw@c.cs.cmu.edu (cmu-cs-c.arpa) Usenet: ralphw@mit-eddie.uucp Fido: Ralph Hyre at Net 129, Node 0 (Pitt-Bull) Phone: (412)CMU-BUGS
berry@tolerant.UUCP (David Berry) (01/31/86)
> In article <412@sol1.UUCP> s255@sol1.UUCP (alcmist) writes: > >The Hyperdrive 2000... includes a ... 68881 floating-point coprocessor and a > >12 Mhz 68000. (I hope I got that right)... The person... did not have any > >information on whether the faster 68000 would break software or not. > > If it breaks software, then they might as well use a 16 Mhz 68020 and break > even more software :-) Seriously, one could still use the 68000 for software > compatibility, ROM calls, and other I/O tasks (like disk cache control), and > the 'meat' of the applications could be run on the 68020. > -- > - Ralph W. Hyre, Jr. I would think that the 16Mhz 68020 would actually break less software than the 12Mhz 68000, since it has a superset of the 68K instruction set and the double speed clock should be significantly easier to drop down to 8Mhz when absolutely necessary. The only that should be timing dependent anyway is copy protection code that does it's own searching for file marks. -- David W. Berry dwb@well.UUCP Delphi: dwb {ucbvax,pyramid,idsvax,bene,oliveb}!tolerant!berry I'm only here for the beer.
sjl@amdahl.UUCP (Steve Langdon) (02/02/86)
In article <263@tolerant.UUCP> berry@tolerant.UUCP (David Berry) writes: > > I would think that the 16Mhz 68020 would actually break less software > than the 12Mhz 68000, since it has a superset of the 68K instruction set and > the double speed clock should be significantly easier to drop down to 8Mhz > when absolutely necessary. The only that should be timing dependent anyway > is copy protection code that does it's own searching for file marks. I have it on good (but second hand) authority that the Appletalk drivers contain processor speed sensitive timing loops. I would also not be surprised if the code to drive the old (ie. single sided) drives contained timing loops. -- Stephen J. Langdon ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl [ The article above is not an official statement from any organization in the known universe. ]
hedges@calma.UUCP (Tom Hedges) (02/03/86)
In article <263@tolerant.UUCP> berry@tolerant.UUCP (David Berry) writes: > > I would think that the 16Mhz 68020 would actually break less software >than the 12Mhz 68000, since it has a superset of the 68K instruction set and >the double speed clock should be significantly easier to drop down to 8Mhz >when absolutely necessary. The only that should be timing dependent anyway >is copy protection code that does it's own searching for file marks. Another unavoidable area of timing dependence is the Sound Buffer filling code. Since the sound buffer is a fixed location and length and DMA occurs comtinuously wrapping from end to front, it is necessary to 'lead' DMA load address in hardware, known as the 'beam', by a phase factor that is necessarily CPU timing dependent. This factor is fairly clock insensitive, but a change of 2 to 1 or more would probably cause problems, especially with some of the newer sound products that don't use the ROM sound driver. Tom Hedges
elwell@osu-eddie.UUCP (Clayton M. Elwell) (02/04/86)
The AppleTalk drivers are timing-sensitive, all right, but only in the sense that you'd better not use a SLOWER processor. Everything is written real tightly so that the receive buffer on the SCC won't fill up. Using a faster processor (like an '020) should not break AppleTalk. I may be wrong. -- -- Clayton Elwell Elwell@Ohio-State.CSNET Elwell%Ohio-State@CSNET-RELAY.ARPA ...!cbosgd!osu-eddie!elwell
timp@gcc-milo.UUCP (02/04/86)
This message is in reply to the on going debate on HyperDrive 2000 in specific and the effect of higher clock speeds for the 68K on the Mac in general. There has been mention that some of the code in the ROM is timing sensitive. On HyperDrive 2000, accesses to the ROM are clocked at 8MHz and not at the 12MHz rate. This was done primarily because the Mac ROMs are not fast enough for 12MHz. However, it also avoids the issue of any timing sensitive code. The SONY driver has also been mentioned as a possible candidate for problems. Since this driver is ROM based, the 8MHz clocking of the ROM avoids this problem also. Appletalk is RAM based and does contain timing sensitive code. GCC, through an agreement with Apple, will be distributing a version of Appletalk which works on HyperDrive 2000. Any application which uses the ROM based Sound driver should be OK. It is possible that RAM based sound applications could have problems. So far, GCC has not encountered such. Obviously, we are attempting to test all sound related programs we can get our hands on. Feel free to mail me about any you're concerned about. Custom copy protection is truly an interesting area of concern. Since the copy protection is always proprietary, developers rarely are willing to discuss details such as whether or not the code is timing sensitive. GCC will be testing what we can. Anyone who has other issues to bring up should feel free to email it. I'm willing to summarize such stuff to the net if there's interest. Tim Peacock General Computer Company Disclaimer: I am an employee of General Computer Company. As such I am biased towards its products. The message above was an attempt to answer questions being raised on the net, and was not intended as an advertise- ment.
radford@calgary.UUCP (Radford Neal) (02/05/86)
> I would think that the 16Mhz 68020 would actually break less software > than the 12Mhz 68000, since it has a superset of the 68K instruction set and > the double speed clock should be significantly easier to drop down to 8Mhz > when absolutely necessary. The only that should be timing dependent anyway > is copy protection code that does it's own searching for file marks. > -- > > David W. Berry The instruction timing on a 68020 will not match that of a 68000 even at the same clock rate, even if you add an extra wait state to bring its 3 cycle memory accesses up to the 68000's 4 cycle accesses, even if you disable its instruction cache. There's just no way, since, for example, a shift instruction will be much faster due to the barrel shifter. Radford Neal