[comp.sys.apple] //gs Boot Blocks

blochowi@rt5.cs.wisc.edu (Jason Blochowiak) (12/23/89)

In article <37492@apple.Apple.COM> farrier@Apple.COM (Cary Farrier) writes:
>In article <4136@puff.cs.wisc.edu> blochowi@rt5.cs.wisc.edu (Jason Blochowiak) writes:
> [...stuff about not understanding why there would be incompatiblity...]
>	The point I am making is that if you depend on the machine booting
>	in a specific manner, then there's a reasonable chance that things
>	will change later and you will have to revise your software for
>	each new change.  What happens when say, a new FST which allows
>	booting off of that file system appears?  Are you going to revise
>	SB 8/16 again?  There is probably a more elegant solution to
>	the problem, perhaps intercepting the boot process at a later
>	step common to both P8 and GS/OS.

	Oh, now this is interesting - are you saying that ProDOS 8 will
allow for different file systems? If not, then paying attention to non-ProDOS
file system conventions would seem to be pointless for the boot block.

	As for a more elegant solution - I'd be interested in hearing about
it. The boot block installation is very minor surgery (remember all those
posts about getting Bird's [sp?] Better Bye into ProDOS 8?), whereas modifying
something else would be more of a pain, and would almost certainly be version
dependent. Besides, how many more steps are there that are common? As I
understand it, the (standard) boot block finds & loads *:ProDOS, which, in the
case of P8, is the entire OS, and in the case of GS/OS, is a loader of some
sort. If this is correct, then the ways the OSes boot diverges right after
the boot block, and a common intercept point would be rather difficult to
find.

	Please note that I understand the point you're making, but I can't
see a better way, and waiting 25 seconds per boot is horrendous when working
on a P8 program that crashes regularly... P8 loads nice & quick off my HD
with SB 8/16, and my cycle isn't stretched as much by waiting.

>| Cary Farrier				| Internet  : farrier@apple.com   |

--
      Jason Blochowiak - blochowi@garfield.cs.wisc.edu or jason@madnix.uucp
       "Education, like neurosis, begins at home." - Milton R. Sapirstein

farrier@Apple.COM (Cary Farrier) (01/03/90)

In article <4145@puff.cs.wisc.edu> blochowi@rt5.cs.wisc.edu (Jason Blochowiak) writes:
>	Oh, now this is interesting - are you saying that ProDOS 8 will
>allow for different file systems? If not, then paying attention to non-ProDOS
>file system conventions would seem to be pointless for the boot block.
	
	No Comment.  Remember, however, that the boot blocks produced
	by the ProDOS FST changed, and it could be possible that they
	may change again.  That is why the boot block should be left
	alone.

>
>	As for a more elegant solution - I'd be interested in hearing about
>it. The boot block installation is very minor surgery (remember all those
>posts about getting Bird's [sp?] Better Bye into ProDOS 8?), whereas modifying
>something else would be more of a pain, and would almost certainly be version
>dependent. Besides, how many more steps are there that are common? As I
>understand it, the (standard) boot block finds & loads *:ProDOS, which, in the
>case of P8, is the entire OS, and in the case of GS/OS, is a loader of some
>sort. If this is correct, then the ways the OSes boot diverges right after
>the boot block, and a common intercept point would be rather difficult to
>find.

	I was thinking along the lines of replacing the *:ProDOS file.
	The format of the file would be irrelevant, so you wouldn't need
	to go to the block level, the modification could be done at a
	higher level.  One way would be to rename the original *:ProDOS
	file to ProDOS.GSOS, then create a new ProDOS file which checks
	to see whether you want to go to P8 or GS/OS, and take the
	appropriate action.
>
>	Please note that I understand the point you're making, but I can't
>see a better way, and waiting 25 seconds per boot is horrendous when working
>on a P8 program that crashes regularly... P8 loads nice & quick off my HD
>with SB 8/16, and my cycle isn't stretched as much by waiting.
>--
>      Jason Blochowiak - blochowi@garfield.cs.wisc.edu or jason@madnix.uucp
>       "Education, like neurosis, begins at home." - Milton R. Sapirstein


-- 
+---------------------------------------+---------------------------------+
| Cary Farrier				| Internet  : farrier@apple.com   |
| Apple II Systems Software Engineering	| UUCP      : apple!farrier       |
| Apple Computer, Inc.			| Fax	    : (408) 974-1704      |
| 20525 Mariani Ave.			| AppleLink : FARRIER             |
| Cupertino, CA 95014			|  or farrier@applelink.apple.com |
+---------------------------------------+---------------------------------+
|          I don't speak for Apple Computer, our products do.             |
+-------------------------------------------------------------------------+

jason@madnix.UUCP (Jason Blochowiak) (01/04/90)

In article <37554@apple.Apple.COM> farrier@Apple.COM (Cary Farrier) writes:
[I wrote]
>>	Oh, now this is interesting - are you saying that ProDOS 8 will
>>allow for different file systems? If not, then paying attention to non-ProDOS
>>file system conventions would seem to be pointless for the boot block.
>	No Comment. [Reminds us that the ProDOS boot block changed, and should
>	be left alone]

	[I asked about a more elegant solution than replacing the boot block]

>	I was thinking along the lines of replacing the *:ProDOS file.
>	The format of the file would be irrelevant, so you wouldn't need
>	to go to the block level, the modification could be done at a
>	higher level.  One way would be to rename the original *:ProDOS
>	file to ProDOS.GSOS, then create a new ProDOS file which checks
>	to see whether you want to go to P8 or GS/OS [...]

	Although the *:ProDOS file would be loaded in without any attention
to disk format, there still wouldn't be any file-level services available to
the alternate loader (or are there?). As such, the new *:ProDOS would still
have to access the volume at a block level. Although installing an alternate
*:ProDOS file is slightly cleaner than installing an alternate boot block,
it doesn't seem to address the block level access problem.

>| Cary Farrier				| Internet  : farrier@apple.com   |


-- 
  Jason Blochowiak - jason@madnix.UUCP (blochowi@garfield.cs.wisc.edu is dead)
       "Education, like neurosis, begins at home." - Milton R. Saperstein

farrier@Apple.COM (Cary Farrier) (01/06/90)

In article <1026@madnix.UUCP> jason@madnix.UUCP (Jason Blochowiak) writes:
> [ how the ProDOS file would still have to go to the block level ]

	Very true, but we can't go changing the ProDOS file system like
	we can do to the boot blocks.

>  Jason Blochowiak - jason@madnix.UUCP (blochowi@garfield.cs.wisc.edu is dead)

-- 
+---------------------------------------+---------------------------------+
| Cary Farrier				| Internet  : farrier@apple.com   |
| Apple II Systems Software Engineering	| UUCP      : apple!farrier       |
| Apple Computer, Inc.			| Fax	    : (408) 974-1704      |
| 20525 Mariani Ave.			| AppleLink : FARRIER             |
| Cupertino, CA 95014			|  or farrier@applelink.apple.com |
+---------------------------------------+---------------------------------+
|          I don't speak for Apple Computer, our products do.             |
+-------------------------------------------------------------------------+

jason@madnix.UUCP (Jason Blochowiak) (01/08/90)

References: <3388@sage.cc.purdue.edu> <0ZWjDCW00WAB00WG8F@andrew.cmu.edu> <4118@puff.cs.wisc.edu> <37432@apple.Apple.COM> <4136@puff.cs.wisc.edu> <37492@apple.Apple.COM> <4145@puff.cs.wisc.edu> <37554@apple.Apple.COM> <1026@madnix.UUCP> <37627@appl

johnmac@fawlty.towers.oz (John MacLean) (01/11/90)

In article <1026@madnix.UUCP> jason@madnix.UUCP (Jason Blochowiak) writes:
>	Although the *:ProDOS file would be loaded in without any attention
>to disk format, there still wouldn't be any file-level services available to
>the alternate loader (or are there?). As such, the new *:ProDOS would still
>have to access the volume at a block level. Although installing an alternate
>*:ProDOS file is slightly cleaner than installing an alternate boot block,
>it doesn't seem to address the block level access problem.

Try this:
- put PRODOS in your root directory named PRODGS
- put P8 in your root directory named PRODP8
- create a PRODOS file that allows you to select what you want
- search for the string 'PRODOS' in $0800-$09FF
- patch this name as selected
- jump back to the boot code at $0801

This should work regardless of what apple does to the boot blocks in
the future.
I have done this in the past, and it works, but I take no responsibility.

John MacLean.
-- 
This net: johnmac@fawlty.towers.oz.au			  Phone: +61 2 427 2999
That net: uunet!fawlty.towers.oz.au!johnmac		  Fax:   +61 2 427 7072
Snail:    Tower Technology
	  Unit D 31-33 Sirius Rd, Lane Cove, NSW 2066, Australia.

jason@madnix.UUCP (Jason Blochowiak) (01/14/90)

In article <155@fawlty.towers.oz> johnmac@fawlty.ips.oz (John MacLean) writes:
>In article <1026@madnix.UUCP> jason@madnix.UUCP (Jason Blochowiak) writes:
>> [I wrote about how *:ProDOS would still have to screw with block-level
>>   disk access]
>Try this: [Rename ProDOS as ProDGS, copy P8 to ProDP8, make own ProDOS for
>            selection, have it patch loaded boot block for appropriate OS]

	I like that - it's nice.

>This should work regardless of what apple does to the boot blocks in
>the future.

	Well, assuming they only keep one copy of the "PRODOS" string around,
and assuming that the boot code can be safely re-executed.

	Of course, this could all be avoided if Apple were just to hack at
the boot code a wee bit, and have it alternately load "PRODOS" or "PRODOS8"
from the root directory based on the Caps Lock key (nice 'cause you don't have
to hold it down "at some point" during the boot), or the Option key ('cause
it's the standard "do something different" key). I suppose it'd have to be
documented tho', as otherwise I'd be willing to bet that a lot of people
would get really confused, particularly those that rest the heels of their
hands on the bottom of the keyboard... .5 :)

	Speaking of stuff that Apple could do, any probabilities/guarantees
as to the two conditions in the paragraph two up from this one staying static?
(Ack, shut up about my grammar - it's 9:45am, and I woke up ~10am yesterday).

>I have done this in the past, and it works, but I take no responsibility.

	Damn. And I read that right after I toasted my HD ;) (bigtime)
But seriously, thanks for the info.

	One last thing - I'm just curious as to how many people followed this
thread. Could the folks that did (aside from the folks that participated) just
send me some email (no posting, that'd be 'orrible!) saying "I read it"?
Thanks.

>John MacLean.
>This net: johnmac@fawlty.towers.oz.au			  Phone: +61 2 427 2999
>That net: uunet!fawlty.towers.oz.au!johnmac		  Fax:   +61 2 427 7072


-- 
                      Jason Blochowiak - jason@madnix.UUCP
       "Education, like neurosis, begins at home." - Milton R. Saperstein