unknown@ucscb.ucsc.edu (The Unknown User) (08/30/90)
In response to Mike Aos: >I think the thing most of you are forgetting to do is format /RAM5. You're >prolly just copying the files there, and that doesn't work. Think about it >for a sec... But if I'm using DigiCopy GS why should I have to format /ram5?? I don't have to do it with anything that's not System Disk 5.0 [Possibly 5.02, but certainly nothing earlier than 5.0] Those kinds of things can be copied directly to /ram5 with no formatting... So in my book that means there's a bug or a "feature", doesn't it? If this strangeness (Error $0028, unable to read boot path or somesuch weird error) is happening ONLY with System 5.0 (or possibly exclusively 5.02 but I doubt it), doesn't it say something's kooky w/System 5? -- / Apple II(GS) Forever! unknown@ucscb.ucsc.edu \ \ Computer engineering student seeking a job. /
dcw@lcs.mit.edu (David C. Whitney) (08/31/90)
In article <6432@darkstar.ucsc.edu> unknown@ucscb.ucsc.edu (The Unknown User) writes: > >In response to Mike Aos: >>I think the thing most of you are forgetting to do is format /RAM5. You're >>prolly just copying the files there, and that doesn't work. Think about it >>for a sec... > But if I'm using DigiCopy GS why should I have to format /ram5?? Digicopy no doubt does not copy the boot blocks as they contain disk-specific info (such as the name of the disk, number of blocks, etc). When you engage the Ramdisk, it sets aside RAM and turns on a driver. It also puts a directory on the "disk." It does not put boot blocks on the "disk," however (perhaps it should). At any rate, the RAMdisk is not bootable unless you explicitly format it. >-- > / Apple II(GS) Forever! unknown@ucscb.ucsc.edu \ > \ Computer engineering student seeking a job. / -- Dave Whitney | I wrote Z-Link and BinSCII. Send me bug Computer Science MIT 1990 | reports. I need a job. Send me an offer. dcw@goldilocks.lcs.mit.edu | My opinions, you hear? MINE! dcw@athena.mit.edu | Are you sure you know what you're doing?
mattd@Apple.COM (Matt Deatherage) (09/01/90)
In article <1990Aug31.123449.16156@mintaka.lcs.mit.edu> dcw@lcs.mit.edu (David C. Whitney) writes: > >Digicopy no doubt does not copy the boot blocks as they contain >disk-specific info (such as the name of the disk, number of blocks, >etc). When you engage the Ramdisk, it sets aside RAM and turns on a >driver. It also puts a directory on the "disk." It does not put boot >blocks on the "disk," however (perhaps it should). At any rate, the >RAMdisk is not bootable unless you explicitly format it. > >-- >Dave Whitney | I wrote Z-Link and BinSCII. Send me bug >Computer Science MIT 1990 | reports. I need a job. Send me an offer. >dcw@goldilocks.lcs.mit.edu | My opinions, you hear? MINE! >dcw@athena.mit.edu | Are you sure you know what you're doing? Not on this computer. The boot blocks contain the information necessary to start the rest of the operating system's load process. For ProDOS disks, this is code necessary to load the file PRODOS at $2000 and jump to it. (ProDOS disks initialized with Apple's FORMATTER routine from software licensing or with ProDOS 16 also are capable of booting SOS on an Apple ///, in case this is important.) The name of the disk, the number of blocks, etc. are not contained in ProDOS boot blocks. That's all in the volume directory. This may be different for other file systems, but when a program does a disk-to-disk copy it should copy all the blocks. (Davex has an option to the "init" command that lets you write boot blocks to an already formatted volume so it becomes bootable - I use that.) -- ============================================================================ Matt Deatherage, Apple Computer, Inc. | "The opinions represented here are Developer Technical Support, Apple II | not necessarily those of Apple Group. Personal mail only, please. | Computer, Inc. Remember that." ============================================================================
avery@netcom.UUCP (Avery Colter) (09/04/90)
I was able to make System.Disk run last night on an 800k /ram5, by
using Copy II Plus and the Copy Whole Disk function.
I did not use the Format command on /ram5, copying the whole disk
was sufficient... in the case of a Ramdisk set to 800k.
The question I haven't found an answer to is: is there any possible
was to make the /ram5 larger and have GS/OS boot from it?
The Advanced Disk Utility won't partition a ramdisk.
And copying file-by-file with Copy II Plus did not work.
However, I did not try formatting /ram5 from C2+.
Although I doubt that would work, it might.
It would seem that /ram5 is automatically formatted on startup though;
that is the only plausible reason why my machine sits there for 3 seconds
before booting the 3.5 drive when it's at 800k, and 6 seconds when it's
at 1600k.
--
Avery Ray Colter Internet: avery@netcom.uucp | {apple|claris}!netcom!avery
o/~ Mama, mama, mama, keep those skinny girls at home,
o/~ `Cause this skinny boy wants a BIG FAT BLONDE! - The Rainmakersjb10320@uxa.cso.uiuc.edu (Desdinova) (09/04/90)
In article <13181@netcom.UUCP> avery@netcom.UUCP (Avery Colter) writes: [...] >The question I haven't found an answer to is: is there any possible >was to make the /ram5 larger and have GS/OS boot from it? Yes, read on... >However, I did not try formatting /ram5 from C2+. > >Although I doubt that would work, it might. It does. >It would seem that /ram5 is automatically formatted on startup though; >that is the only plausible reason why my machine sits there for 3 seconds >before booting the 3.5 drive when it's at 800k, and 6 seconds when it's >at 1600k. RAM5 is "formatted" at coldboot. However, it doesn't write out the two boot blocks necessary for the "disk" to boot. Formatting with copy ][+ will indeed do the trick. >Avery Ray Colter Internet: avery@netcom.uucp | {apple|claris}!netcom!avery -- Jawaid Bazyar | Blondes in big black cars look better wearing Senior/Computer Engineering | their dark sunglasses at night. (unk. wierdo) jb10320@uxa.cso.uiuc.edu | The gin, the gin, glows in the Dark! | (B O'Cult)
dragon@pawl.rpi.edu (Carl L. Norden) (09/04/90)
In article <13181@netcom.UUCP> avery@netcom.UUCP (Avery Colter) writes: >I was able to make System.Disk run last night on an 800k /ram5, by >using Copy II Plus and the Copy Whole Disk function. I hate to sound silly, but why do you want to do this? >And copying file-by-file with Copy II Plus did not work. There is a good reason for that. GSOS writes some files a slight bit different from Prodos 8 & 16. The only files that act 'dangerous' on these older systems seems to be 'FINDER.DATA' (& ROOT) and sometimes ICN files. If can avoid copying these, C2+ should have no trouble. >It would seem that /ram5 is automatically formatted on startup though; >that is the only plausible reason why my machine sits there for 3 seconds >before booting the 3.5 drive when it's at 800k, and 6 seconds when it's >at 1600k. Not really at startup. Anytime the Apple GS is turned on, it will. Hitting cntl-Reset, or Open apple Reset WON'T usually do it. (Though Open apple/ Closed Apple/Cntl-Reset Will. This totally destroys EVERYTHING in memory.) That delay is not just formatting the ramdisk. That takes less time than you can imagine. Think about how fast C2+ formats them...) Most of the time is spent by the Memory Manager while it allocates and verifies the memory. But that is really unimportant. P.S. Does anyone out there know how to use the Memory_Manager StartUp routine? Every time I use it, I keep getting an error of $201, which isn't possible!! (That's without using GSOS or ProDOS 16. I prefer ProDOS 8... Tis faster }:) -Dragon
mattd@Apple.COM (Matt Deatherage) (09/05/90)
In article <N0{%8D$@rpi.edu> dragon@pawl.rpi.edu (Carl L. Norden) writes: >In article <13181@netcom.UUCP> avery@netcom.UUCP (Avery Colter) writes: >>And copying file-by-file with Copy II Plus did not work. > >There is a good reason for that. GSOS writes some files a slight bit >different from Prodos 8 & 16. The only files that act 'dangerous' on these >older systems seems to be 'FINDER.DATA' (& ROOT) and sometimes ICN files. If >can avoid copying these, C2+ should have no trouble. > This is absolute bunk. The only difference in the way ProDOS 8 and the ProDOS FST write files is that the ProDOS FST will automatically sparse files if it can. This will only affect programs doing direct block-level access to read their files; all file system reads and writes will behave as expected with sparse files. The Finder only does file system reads for $C9 and icon files. There is nothing "dangerous" about these files or GS/OS in general. >>It would seem that /ram5 is automatically formatted on startup though; >>that is the only plausible reason why my machine sits there for 3 seconds >>before booting the 3.5 drive when it's at 800k, and 6 seconds when it's >>at 1600k. > >Not really at startup. Anytime the Apple GS is turned on, it will. Hitting >cntl-Reset, or Open apple Reset WON'T usually do it. (Though Open apple/ >Closed Apple/Cntl-Reset Will. This totally destroys EVERYTHING in memory.) >That delay is not just formatting the ramdisk. That takes less time than >you can imagine. Think about how fast C2+ formats them...) Most of the time >is spent by the Memory Manager while it allocates and verifies the memory. But >that is really unimportant. > It doesn't destroy everthing in memory; it resets a power-up byte so that some things which survive rebooting (like the RAMdisk) don't survive and are re- allocated. "Most" of the time delay is the Memory Manager pre-zeroing the bytes allocated to the RAMdisk, not "verifying". The actual allocation is pretty quick because at that point virtually no other memory is allocated. >P.S. Does anyone out there know how to use the Memory_Manager StartUp routine? > Every time I use it, I keep getting an error of $201, which isn't possible!! > (That's without using GSOS or ProDOS 16. I prefer ProDOS 8... Tis faster }:) > MMStartUp will return an error if you call it from an unallocated block. See ProDOS 8 Technical Note #27, "Hybrid Applications". GS/OS is much, much faster than ProDOS 8, but to program with it you have to have your facts straight. > -Dragon -- ============================================================================ Matt Deatherage, Apple Computer, Inc. | "The opinions represented here are Developer Technical Support, Apple II | not necessarily those of Apple Group. Personal mail only, please. | Computer, Inc. Remember that." ============================================================================
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (09/05/90)
If I may clear things up: 1. To boot from /ram5, you have to get the 'boot blocks' onto it. This is NOT done when the GS powers up or is cold-started. It IS done when you format that ramdisk using ANY utility program that recognizes it as a formattable device (Shrinkit doesn't if it isn't 800K -- bleah). 2. To boot GS/OS from a bootable /ram5, you must copy the FORKED FILES properly with either a disk-to-disk block copy OR with a file copier that can deal with Storage Type 5. I don't know if anything besides the Finder can do this. It is the storage type 5 files that P8 utilities corrupt, and not the finder's data or icon files. Todd Whitesel toddpw @ tybalt.caltech.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/05/90)
In article <44521@apple.Apple.COM> mattd@Apple.COM (Matt Deatherage) writes: -In article <N0{%8D$@rpi.edu> dragon@pawl.rpi.edu (Carl L. Norden) writes: ->In article <13181@netcom.UUCP> avery@netcom.UUCP (Avery Colter) writes: ->>And copying file-by-file with Copy II Plus did not work. ->There is a good reason for that. GSOS writes some files a slight bit ->different from Prodos 8 & 16. The only files that act 'dangerous' on these ->older systems seems to be 'FINDER.DATA' (& ROOT) and sometimes ICN files. -This is absolute bunk. The only difference in the way ProDOS 8 and the -ProDOS FST write files is that the ProDOS FST will automatically sparse files -if it can. This will only affect programs doing direct block-level access -to read their files; all file system reads and writes will behave as expected -with sparse files. The Finder only does file system reads for $C9 and icon -files. There is nothing "dangerous" about these files or GS/OS in general. More importantly, Copy II Plus, like practically all existing ProDOS-8 copy utilities, when copying on a file-by-file basis fails to copy the resource fork of extended files. Thus if you try to install IIGS System Disk 5.0.2 files by such means, the resulting OS will not work right. "File forks" are an invention of the devil, or at least of someone who liked unnecessary complexity.
cs4w+@andrew.cmu.edu (Charles William Swiger) (09/05/90)
>"File forks" are an invention of the devil, or at >least of someone who
liked unnecessary complexity.
The forked files originally came from the Mac file system. The original
theory was that a program would consist of "resources", like icons,
program code, etc, and changable "data", like strings, which could be
modified easily (to a different language perhaps). This allows Mac
programs to be developed and modified much more easily than if data
items were buried in with the code. Play with a program called ResEdit
(for the Mac) sometime. It allows you to change various resources
without going through more elaborate methods like using a sector editor.
-- Charles William Swiger
cs4w+@andrew.cmu.eduq4kx@vax5.cit.cornell.edu (Joel Sumner) (09/06/90)
In article <13181@netcom.UUCP>, avery@netcom.UUCP (Avery Colter) writes: > I was able to make System.Disk run last night on an 800k /ram5, by > using Copy II Plus and the Copy Whole Disk function. > > And copying file-by-file with Copy II Plus did not work. > Did you try any 16-Bit copy programs. Since Copy II+ cannot copy forked files, none of the CDEVs or SYS.RESOURCES would have been copied. I know these files are not essential to the boot process but it may have something to do with it. How large is your machine RAM anyway? A nice fast hard drive would seem to be much better than all of this RAM copy contortioning. I have a 30 Meg Ehman with an Apple Rev 'C' card and it works wonderfully. > -- > Avery Ray Colter Internet: avery@netcom.uucp | {apple|claris}!netcom!avery -- Joel Sumner GENIE:JOEL.SUMNER These opinions are q4kx@cornella.ccs.cornell.edu q4kx@cornella warranted for 90 days or q4kx@vax5.cit.cornell.edu q4kx@crnlvax5 60,000 miles. Whichever .................................................... comes first. Never test for an error condition that you can't handle.
jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) (09/06/90)
In <13739@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > More importantly, Copy II Plus, like practically all existing ProDOS-8 > copy utilities, when copying on a file-by-file basis fails to copy the > resource fork of extended files. Thus if you try to install IIGS System > Disk 5.0.2 files by such means, the resulting OS will not work right. Actually, because of the way extended files are stored, ProDOS 8 programs that don't know about extended files can't copy them at all; see ProDOS 8 TN #25, which Matt Deatherage posted earilier. ----------------- Jeffrey Hutzelman America Online: JeffreyH11 Internet/BITNET:jh4o+@andrew.cmu.edu, jhutz@drycas.club.cc.cmu.edu >> Apple // Forever!!! <<
lhaider@pro-beagle.cts.com (Laer Haider) (09/10/90)
In-Reply-To: message from toddpw@tybalt.caltech.edu
Also keep in mind that the system.resources file is kept open when GS/OS is
active. Try booting from another disk, then copy the system files over to
your RAM disk. Works for me :)
/
\ / /
\\\' , / //
______________________________________________________ \\\//, _/ //,
Laer Haider (lhaider@pro-beagle.cts.com) \_-//' / //<,
/\\ (lhaider@pro-grouch.cts.com) \ /// <//`
//\\\ / >> \\\`__/_
///\\\\ My employer doesn't know who I am. /,)-^>> _\` \\\
////\\\\\ The opinions expressed here belong to (/ \\ / \\\
// IIgs \\\ no person or group living or dead! // _//\\\
------------------------------------------------------ ((` ((gwyn@smoke.BRL.MIL (Doug Gwyn) (09/29/90)
In article <8atGHuW00VpDI0tkZC@andrew.cmu.edu> cs4w+@andrew.cmu.edu (Charles William Swiger) writes: >>"File forks" are an invention of the devil, or at least of someone who >liked unnecessary complexity. >... The original theory was that ... I know all that. However, it is not necessary to devise file forks in order to attain all those goals. If the following code does not suffice to completely duplicate an object's contents, then the object has unnecessary structure: while ((c = getc(ifp)) != EOF) putc(c, ofp);