kim@amdahl.uts.amdahl.com (Kim DeVaughn) (10/01/88)
In article <12453@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: > > The 2090A is identical to the 2090 except that it has autoboot > ROMs. Uh ... I really hope this is just an over generalization you've made, Marco, and not true. I had thought the 54 Meg partition size limitation/bug was to have gotten fixed in the 2090A. And also the number of heads limit, etc. CATS? /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25
steveb@cbmvax.UUCP (Steve Beats) (10/01/88)
In article <bb0RR3dgvg1010O6Xxs@amdahl.uts.amdahl.com> kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: > >Uh ... I really hope this is just an over generalization you've made, Marco, >and not true. I had thought the 54 Meg partition size limitation/bug was to >have gotten fixed in the 2090A. And also the number of heads limit, etc. > >CATS? > >/kim > The 54 Meg partition size limit is a bug in the filing system. That limit is present on ANY hard disk (or RAM disk) that has the old 1.2 Filing system mounted on it. Partition was the key word. The device doesn't handle partitions, the filing system does. This has been theoretically raised to 2.5 Gigabytes by the Fast Filing System in the V1.3 Workbench release. Now I have a question. How can we transparently handle disk media that has a capacity >2.5 Gigabytes. A lot of software is going to break just because they've gone over 31 bits of offset (a longword becomes negative then). An even larger problem exists when you go over 4.2 Gigabytes since that will overflow a longword. IO_OFFSET specified in blocks would have made sense (especially since everyone in the world says IO_OFFSET must be a multiple of the devices blocksize), but that's not an available option. The only safe thing I can think of are CMD_READ_EXTENDED and CMD_WRITE_EXT on future device drivers. It isn't possible to just limit partitions to <2.5 Gigs since the filing system has to make it's requests in terms of physical blocks, not blocks relative to the start of the partition. Anyone got any ideas they'd care to air ? Steve
thad@cup.portal.com (10/03/88)
Re: Steve Beat's request for ideas addressing massive storage devices ... Present SCSI (for example) uses 32-bits to address a logical block. Assuming one's block size is 512 bytes, this would permit one to "reach" 2 TeraBytes (2^12). Given the possibility of, say, optical media having capacities in that ballpark within a few years, the problem is not moot. At the MINIMUM, I see the need for 48 bits of addressing such devices; at the least would be 32-bits for a "block" and 16 bits for a byte-offset within the block. As a suggestion, I would recommend contacting the (known) developers of such large storage devices now and ask them how they expect their devices to be incorporated and used in computing systems. As a matter of general interest, the ANSI X3T9.2 SCSI committee operates a BBS system dedicated to the discussion of such matters as they pertain to ANSI standards and the manufactuers of equipment expected to be in compliance with the standards. The SCSI-2 standard is nearly completed (for review), and SCSI-3 is in the planning stages. John Lohmeyer (the Chairman of X3T9.2) recently informed me of some exciting new developments on the horizon. Since CBM has a need to also be compliant with future standards, I'd recommend applying for an account on the SCSI BBS; contact me (email) if you'd like additional info. Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]
eric@hector.UUCP (Eric Lavitsky) (10/03/88)
In article <bb0RR3dgvg1010O6Xxs@amdahl.uts.amdahl.com> kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: >In article <12453@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: >> The 2090A is identical to the 2090 except that it has autoboot ROMs. > >Uh ... I really hope this is just an over generalization you've made, Marco, >and not true. I had thought the 54 Meg partition size limitation/bug was to >have gotten fixed in the 2090A. And also the number of heads limit, etc. The 54 Meg partition problem was a limitation caused by a "bug" in the original (slow) file system, it has nothing to do with firmware on the 2090/A. The only real problem that should have been fixed in the 2090A firmware was the limitation of 8 heads or less for ST-506 devices. >CATS? Thank the lord we have them! >/kim Eric ARPA: eric@topaz.rutgers.edu or eric@ulysses.att.com UUCP: {att,ucbvax}!ulysses!eric or {wherever!}rutgers!topaz!eric SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854 "To err is human; To really f*ck up requires the root password."
daveh@cbmvax.UUCP (Dave Haynie) (10/03/88)
in article <bb0RR3dgvg1010O6Xxs@amdahl.uts.amdahl.com>, kim@amdahl.uts.amdahl.com (Kim DeVaughn) says: > Summary: I hope not ... > In article <12453@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: >> The 2090A is identical to the 2090 except that it has autoboot >> ROMs. > Uh ... I really hope this is just an over generalization you've made, Marco, > and not true. I had thought the 54 Meg partition size limitation/bug was to > have gotten fixed in the 2090A. That's a bug in the Standard FileSystem, not the controller. Fast FileSystem fixes it, so you now get partitions around 2.5 Gigs if you can use 'em. > And also the number of heads limit, etc. There's no head limit on SCSI, due to the nature of SCSI (eg, it's all software aside from the SCSI port). The standard number of ST-506 heads, which is what the 2090 supported, was 8. At some point along it's lifetime, an additional line was usurped by several manufacturers to give you 16 lines. Don't know if this was ever done in a standard way (here's that CPU guy trying to answer a disk question again...), or if there's any chance 2090s or 2090As will support it. > CATS? Them too. > /kim -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
kim%amdahl.uts.amdahl.com@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 2401; Sat, 01 Oct 88 18:39:41 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Sat, 01 Oct 88 18:39:28 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa17521; 30 Sep 88 20:58 EDT Received: by Louie.UDEL.EDU id ab17361; 30 Sep 88 20:47 EDT Received: from USENET by Louie.UDEL.EDU id aa16902; 30 Sep 88 20:16 EDT From: Kim DeVaughn <kim@amdahl.uts.amdahl.com> Subject: 2090A and DMA (was: Re: 2000-and-1 expansion box) Message-ID: <bb0RR3dgvg1010O6Xxs@amdahl.uts.amdahl.com> Date: 30 Sep 88 22:02:50 GMT Organization: Amdahl Corporation, Sunnyvale, CA 94086 To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU In article <12453@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: > > The 2090A is identical to the 2090 except that it has autoboot > ROMs. Uh ... I really hope this is just an over generalization you've made, Marco, and not true. I had thought the 54 Meg partition size limitation/bug was to have gotten fixed in the 2090A. And also the number of heads limit, etc. CATS? /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25
steveb%cbmvax.uucp@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 3767; Sat, 01 Oct 88 23:04:50 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Sat, 01 Oct 88 23:04:47 EDT Received: by Louie.UDEL.EDU id ad04019; 1 Oct 88 15:42 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa03602; 1 Oct 88 15:14 EDT Received: from USENET by Louie.UDEL.EDU id aa03428; 1 Oct 88 15:01 EDT From: Steve Beats <steveb@cbmvax.uucp> Subject: Re: 2090A and DMA (was: Re: 2000-and-1 expansion box) Message-ID: <4912@cbmvax.UUCP> Date: 1 Oct 88 15:36:15 GMT Organization: Commodore Technology, West Chester, PA To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU In article <bb0RR3dgvg1010O6Xxs@amdahl.uts.amdahl.com> kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: > >Uh ... I really hope this is just an over generalization you've made, Marco, >and not true. I had thought the 54 Meg partition size limitation/bug was to >have gotten fixed in the 2090A. And also the number of heads limit, etc. > >CATS? > >/kim > The 54 Meg partition size limit is a bug in the filing system. That limit is present on ANY hard disk (or RAM disk) that has the old 1.2 Filing system mounted on it. Partition was the key word. The device doesn't handle partitions, the filing system does. This has been theoretically raised to 2.5 Gigabytes by the Fast Filing System in the V1.3 Workbench release. Now I have a question. How can we transparently handle disk media that has a capacity >2.5 Gigabytes. A lot of software is going to break just because they've gone over 31 bits of offset (a longword becomes negative then). An even larger problem exists when you go over 4.2 Gigabytes since that will overflow a longword. IO_OFFSET specified in blocks would have made sense (especially since everyone in the world says IO_OFFSET must be a multiple of the devices blocksize), but that's not an available option. The only safe thing I can think of are CMD_READ_EXTENDED and CMD_WRITE_EXT on future device drivers. It isn't possible to just limit partitions to <2.5 Gigs since the filing system has to make it's requests in terms of physical blocks, not blocks relative to the start of the partition. Anyone got any ideas they'd care to air ? Steve
thad%cup.portal.com@cunyvm.cuny.edu (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 5896; Mon, 03 Oct 88 21:54:43 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Mon, 03 Oct 88 21:54:40 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa13333; 3 Oct 88 19:24 EDT Received: from USENET by Louie.UDEL.EDU id aa13142; 3 Oct 88 19:17 EDT From: thad@cup.portal.com Subject: Re: 2090A and DMA (was: Re: 2000-and-1 expansion box) Message-ID: <9670@cup.portal.com> Date: 2 Oct 88 23:55:34 GMT Organization: The Portal System (TM) XPortal-User-Id: 1.1001.2826 To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU Re: Steve Beat's request for ideas addressing massive storage devices ... Present SCSI (for example) uses 32-bits to address a logical block. Assuming one's block size is 512 bytes, this would permit one to "reach" 2 TeraBytes (2^12). Given the possibility of, say, optical media having capacities in that ballpark within a few years, the problem is not moot. At the MINIMUM, I see the need for 48 bits of addressing such devices; at the least would be 32-bits for a "block" and 16 bits for a byte-offset within the block. As a suggestion, I would recommend contacting the (known) developers of such large storage devices now and ask them how they expect their devices to be incorporated and used in computing systems. As a matter of general interest, the ANSI X3T9.2 SCSI committee operates a BBS system dedicated to the discussion of such matters as they pertain to ANSI standards and the manufactuers of equipment expected to be in compliance with the standards. The SCSI-2 standard is nearly completed (for review), and SCSI-3 is in the planning stages. John Lohmeyer (the Chairman of X3T9.2) recently informed me of some exciting new developments on the horizon. Since CBM has a need to also be compliant with future standards, I'd recommend applying for an account on the SCSI BBS; contact me (email) if you'd like additional info. Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]
thad%cup.portal.com%cunyvm.cuny.edu@cunyvm.cuny.edu (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 6657; Mon, 03 Oct 88 23:54:49 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Mon, 03 Oct 88 23:54:45 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa16810; 3 Oct 88 22:16 EDT Received: from USENET by Louie.UDEL.EDU id aa16625; 3 Oct 88 22:08 EDT From: thad%cup.portal.com@cunyvm.cuny.edu Subject: Re: 2090A and DMA (was: Re: 2000-and-1 expansion box) Message-ID: <4484@louie.udel.EDU> Date: 4 Oct 88 02:07:26 GMT To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 5896; Mon, 03 Oct 88 21:54:43 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Mon, 03 Oct 88 21:54:40 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa13333; 3 Oct 88 19:24 EDT Received: from USENET by Louie.UDEL.EDU id aa13142; 3 Oct 88 19:17 EDT From: thad@cup.portal.com Subject: Re: 2090A and DMA (was: Re: 2000-and-1 expansion box) Message-ID: <9670@cup.portal.com> Date: 2 Oct 88 23:55:34 GMT Organization: The Portal System (TM) XPortal-User-Id: 1.1001.2826 To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU Re: Steve Beat's request for ideas addressing massive storage devices ... Present SCSI (for example) uses 32-bits to address a logical block. Assuming one's block size is 512 bytes, this would permit one to "reach" 2 TeraBytes (2^12). Given the possibility of, say, optical media having capacities in that ballpark within a few years, the problem is not moot. At the MINIMUM, I see the need for 48 bits of addressing such devices; at the least would be 32-bits for a "block" and 16 bits for a byte-offset within the block. As a suggestion, I would recommend contacting the (known) developers of such large storage devices now and ask them how they expect their devices to be incorporated and used in computing systems. As a matter of general interest, the ANSI X3T9.2 SCSI committee operates a BBS system dedicated to the discussion of such matters as they pertain to ANSI standards and the manufactuers of equipment expected to be in compliance with the standards. The SCSI-2 standard is nearly completed (for review), and SCSI-3 is in the planning stages. John Lohmeyer (the Chairman of X3T9.2) recently informed me of some exciting new developments on the horizon. Since CBM has a need to also be compliant with future standards, I'd recommend applying for an account on the SCSI BBS; contact me (email) if you'd like additional info. Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]
mlelstv@faui44.informatik.uni-erlangen.de (Michael van Elst ) (10/05/88)
In article <4413@louie.udel.EDU> kim%amdahl.uts.amdahl.com@UDEL.EDU writes: >> The 2090A is identical to the 2090 except that it has autoboot >> ROMs. > >Uh ... I really hope this is just an over generalization you've made, Marco, >and not true. I had thought the 54 Meg partition size limitation/bug was to >have gotten fixed in the 2090A. And also the number of heads limit, etc. > Hello, This might be an over generalization, but the partition size limitation has nothing to do with the controller and the heads limit is just a software problem i.e. ROMs that are changed. The interesting thing is: Have they fixed the DMA bug that occurs under overscan + hires + max. bitplanes ? I hope. Michael van Elst E-mail: UUCP: ...uunet!unido!fauern!faui44!mlelstv