[comp.sys.apple] IIgs Software Reboot

Les_Ferch@MTSG.UBC.CA (12/10/89)

I need a routine that will reboot a IIgs in the same way that
pressing Control-Apple-Reset does.  I already have the program
sreset.sys, but it's just a little too severe for my needs because
it clears the /RAM5 volume.
 
I've already looked in the IIgs firmware reference manual and the
IIe reference manual and didn't find anything (which doesn't
necessarily mean the answer isn't there).  And I do know that PR#n
will reboot, but I need a routine that doesn't assume a particular
slot number.  My thanks in advance for anyone who can post Hex,
assembler, or Applesoft code that will do the trick.
 
Internet: Les_Ferch@mtsg.ubc.ca
BITNET:   USERLSF@UBCMTSG

gt0t+@andrew.cmu.edu (Gregory Ross Thompson) (12/13/89)

Les_Ferch@MTSG.UBC.CA writes:
> I need a routine that will reboot a IIgs in the same way that
> pressing Control-Apple-Reset does.  I already have the program
> sreset.sys, but it's just a little too severe for my needs because
> it clears the /RAM5 volume.
[stuff omitted]

  In ProSEL 16 by Glen Bredon, there is a Warm Shutdown option that
does exactly what you're looking for.  I don't know how Glen does it,
but you could try sending mail to him...

> Internet: Les_Ferch@mtsg.ubc.ca
> BITNET:   USERLSF@UBCMTSG

		-Greg T.

wombat@claris.com (Scott Lindsey) (12/13/89)

In article <1949868@mtsg.ubc.ca> Les_Ferch@MTSG.UBC.CA writes:

> I need a routine that will reboot a IIgs in the same way that
> pressing Control-Apple-Reset does.  I already have the program
> sreset.sys, but it's just a little too severe for my needs because
> it clears the /RAM5 volume.

I do it by faking the ADB sequence after munging the power-up byte.
Note that this can do bad things if GS/OS is busy at the time, just
like rebooting manually when the drive's spinning.

	LDA >$0003F4	; Power-up byte
	EOR #$00FF	; muck it up.
	STA >$0003F4

	PEA $0000
	PEA $0000
	PEA $0000
	PEA $0010
	LDX #$0909
	JSL $E10000	; Send the ADB message for Ctl-Apple-Reset

	; Not reached: tool call doesn't return.



Scott Lindsey     |"Cold and misty morning. I heard a warning borne in the air
Claris Corp.      |    About an age of power when no one had an hour to spare"
ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple,
wombat@claris.com |    StyleWare, the author, or anyone else living or Dead.

farrier@Apple.COM (Cary Farrier) (12/14/89)

In article <WOMBAT.89Dec12132951@claris.com> wombat@claris.com (Scott Lindsey) writes:
>In article <1949868@mtsg.ubc.ca> Les_Ferch@MTSG.UBC.CA writes:
>
>> I need a routine that will reboot a IIgs in the same way that
>> pressing Control-Apple-Reset does.  I already have the program
>> sreset.sys, but it's just a little too severe for my needs because
>> it clears the /RAM5 volume.
>
>I do it by faking the ADB sequence after munging the power-up byte.
>Note that this can do bad things if GS/OS is busy at the time, just
>like rebooting manually when the drive's spinning.
>
>	LDA >$0003F4	; Power-up byte
>	EOR #$00FF	; muck it up.
>	STA >$0003F4
>
>	PEA $0000
>	PEA $0000
>	PEA $0000
>	PEA $0010
>	LDX #$0909
>	JSL $E10000	; Send the ADB message for Ctl-Apple-Reset
>
>	; Not reached: tool call doesn't return.
>
>
>
>Scott Lindsey     |"Cold and misty morning. I heard a warning borne in the air
>Claris Corp.      |    About an age of power when no one had an hour to spare"
>ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple,
>wombat@claris.com |    StyleWare, the author, or anyone else living or Dead.

A better solution is to use the OS_SHUTDOWN call ($2003).  When using this
call, an os_shutdown message is sent to everybody in the system who would 
like to know when the system is going down.  This call will also flush out
any data to any files that has not been written out by the FST yet.  If your
programs would like to be notified of a shutdown, you can use the notification
queue.

Cary Farrier
-- 
+---------------------------------------+---------------------------------+
| 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.             |
+-------------------------------------------------------------------------+

Les_Ferch.@MTSG.UBC.CA (12/14/89)

In response to my query, Cary Farrier writes:
 
>A better solution is to use the OS_SHUTDOWN call ($2003).  When
>using this call, an os_shutdown message is sent to everybody in the
>system who would like to know when the system is going down.  This
>call will also flush out any data to any files that has not been
>written out by the FST yet.  If your programs would like to be
>notified of a shutdown, you can use the notification queue.
 
I agree, but doesn't that require running GS/OS?  I didn't state it
before, but the routine needs to run under plain old ProDOS 8.

rich@pro-exchange.cts.com (Rich Sims) (12/14/89)

In-Reply-To: message from Les_Ferch@MTSG.UBC.CA

> I need a routine that will reboot a IIgs in the same way that
> pressing Control-Apple-Reset does.  I already have the program
> sreset.sys, but it's just a little too severe for my needs because
> it clears the /RAM5 volume.

> My thanks in advance for anyone who can post Hex,
> assembler, or Applesoft code that will do the trick.

OK, hex, assembler, or Applesoft (not in that order)

Applesoft:      POKE 1012,0 : CALL 64098

8-bit hex/assembler:    92 F4 03        STZ 03F4
                        4C 62 FA        JMP FA62

Now it gets tricky.... full native mode.....

        I don't know an "elegant" way that's quick, easy, and that will
        always work - I'd use the exact same code as shown in the 8-bit
        mode above, but kick in emulation mode first!  :-)

All that stuff does exactly the same thing -- zaps the power-up byte and calls
a reset routine in the monitor -- it ought to work on any GS that can still
emulate an Apple II, but I've only checked it on my ROM 01 machine.

Non-GS owners can do exactly the same thing - but the 6502 doesn't understand
the STZ instruction, so you'll have to store the 0 with an LDA-STA pair.  An
INC or DEC should also work, since all you should "really" have to do is
*change* the value at $03F4, not necessarily zero it.

-Rich Sims-

UUCP: crash!pro-exchange!rich
ARPA: crash!pro-exchange!rich@nosc.mil
INET: rich@pro-exchange.cts.com

wombat@claris.com (Scott Lindsey) (12/14/89)

In article <37227@apple.Apple.COM> farrier@Apple.COM (Cary Farrier) writes:


> A better solution is to use the OS_SHUTDOWN call ($2003).  When using this

You're right, that's the more correct thing to do.  Mine has the advantage of
not being OS dependant, though.  If (for whatever reason) you're not running
GS/OS, _SendInfo is always available (I believe it's in the Cortland ROMs) no
matter what OS you're running.

At StyleWare, we had just that code as an EXE under APW for automatically
rebooting when we were writing NDAs for system software 3.1.




Scott Lindsey     |"Cold and misty morning. I heard a warning borne in the air
Claris Corp.      |    About an age of power when no one had an hour to spare"
ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple,
wombat@claris.com |    StyleWare, the author, or anyone else living or Dead.

sec1918@uxf.cso.uiuc.edu (12/14/89)

Referring to Apple IIgs tech note #49 "Rebooting (Really)"...

The Easy Way
GS/OS provides a mechanism for rebooting with the OSShutdown call.  This call,
documented in volume 1 of the GS/OS reference, will either reboot the system
(after first shutting down all loaded and generated drivers and closing all 
open sessions) or will shut down everything and present a dialog box which 
states, "You may now power down your Apple IIgs safely"...

  ok this is like choosing shut down from the finder...

also it mentions that OSShutdown can resize the ramdisk if it wants.  
"You should always use OSShutdown when using GS/OS"...

ok but GS/OS sucks huge, so they also provide

The Hard Way

Programs not using GS/OS have a little more work to do.  The supported 
non-GS/OS method of rebooting is similar to the method used on 8-bit machines: 
change the value of POWERUP ($00/03F4) and do a long jump to RESET ($FA62).  
However, there are a few catches:

1. the jump must be made in emulation mode.
2. Interrupts must be disabled.
3. The data bank register must be set to zero.
4. The direct page must be zero.
5. ROM firmware must be visible in the memory map.
6. Internal interrupt sources (such as the ones for AppleTalk) must be shut down

Simply disabling interrupts without shutting down AppleTalk intterupt sources 
inside the system will cause the system to hang when the jump to RESET is made.

Turning off these internal interrupt sources is accomplished by changing
softswitch values at $C039 (SCCAREG), $C041 (INTEN), and $C047 (CLRVBLINT).

The following code example demonstrates the correct method:

POWRUP	equ	$0003F4		;power up byte in bank zero
STATEREG equ	$C068		;ROM/RAM state register
CLRVBLINT equ 	$C047		;clear VBL intterupt flags register
INTEN	equ	$C041		;interrupt enable register
SCCAREG equ	$C039		;SCC register
RESET	equ	$00FA62		;ROM reset entry point

FROMNATV anop			;must be in native mode here
	sei
	pei	0
	pei	0		;push four zero bytes
	plb
	plb			;pull data bank register (must do twice)
	pld			;pull 16-bit data bank register
	sec
	xce			;emulation mode
	longa off
	longi off
FROMEMUL anop
	sei
	dec	POWRUP		;invalidate power up byte
	lda	#$0C		;rom parameters
	sta	STATEREG	;swap in the ROM and everything else out
	stz 	CLRVBLINT	;clear VBL interrupts
	stz	INTEN		;turn off internal interrupt sources
	lda	#$C0
	sta	SCCAREG
	jml	RESET		;kablamm

I must state that this was copied almost exactly from the tech note but hasn't
been tried so there may be some bugs... I dunno it looks good to me.

"All opinions above are those of Apple Computer, Inc., not me."

Don't send me any mail as this is just a temporary CS account dead in 2 days

217-344-3964 the Beach HST / 100 Megs

mattd@Apple.COM (Matt Deatherage) (12/15/89)

You folks really give me a rash sometimes.

EVERYONE:  PLEASE CONSULT THE TECHNICAL NOTES WHENEVER YOU HAVE A PROGRAMMING
QUESTION.  FAILURE TO DO SO IS PUNISHABLE BY FORCIBLE LISTENING TO DAVE LYONS
INTERPRET EVERY WORD YOU'VE EVER SAID IN THE INCORRECT, LITERAL WAY.

I mean this.

There are some cute methods in this thread, but *NONE* of them are supported
or even have much chance of reliably working on all machines except the one
in the Technical Note (IIgs TN #49, "Rebooting (Really!)".  No one really
knew how to do it, and that's why we wrote the note.

Scott is excused for having written the "post-the-ADB-code" routine before
the TN was written, but isn't excused for recommending it a year after the
Note was released.

Also please remember that rebooting is a last resort, to be taken only at
moments of extreme difficulty.  Rebooting is *NOT* the way to break as many
rules as you want and not have to worry about it.

The world does not need any more Apple II applications that require you to
reboot when you're done using them.  Those compatibility guidelines aren't
there just to annoy developers.

-- 
-----------------------------------------------------------------------------
Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome
Send PERSONAL mail ONLY (please) to:  | should not be construed to imply that
Amer. Online: Matt DTS                | Apple Computer, Inc., or any of its
ThisNet: mattd@apple.com              | subsidiaries, in whole or in part,
ThatNet: (stuff)!ames!apple!mattd     | have any opinion on any subject."
Other mail by request only, please.   | "So there."
-----------------------------------------------------------------------------

Les_Ferch.@MTSG.UBC.CA (12/15/89)

>The world does not need any more Apple II applications that require you to
>reboot when you're done using them.  Those compatibility guidelines aren't
>there just to annoy developers.
 
I completely agree.  The reason I was looking for reboot code is to write a
program or programs that will automatically (and hopefully properly) switch
my operating environment on my hard drive between plain ProDOS 8 and GS/OS.
 
The idea is to have the GSOS "ProDOS" file and the "P8" file on the root
directory along with my reboot program(s).  To go from GSOS to ProDOS 8
only, the reboot program would rename "ProDOS" to "GSOS" and "P8" to "ProDOS"
and then reboot or do an OS Shutdown call.  To go from ProDOS 8 to GSOS, just
basically reverse the process.  This is what I've been doing by hand whenever
I've wanted to switch between a ProDOS 8 environment and a GSOS environment,
but I just want to make it automatic.  I know you can run ProDOS 8 software
from GSOS, but if I'm working on a ProDOS 8 only program and hanging or
crashing the system a lot, I'd rather not wait for GSOS to boot each time.
Anyhow, if there is a better way to go about this, I'm listening.
 
PS. I'm diligently reading TN #49 now, thanks.

aj0@sage.cc.purdue.edu (Eric Mulholland) (12/16/89)

In article <1960244@mtsg.ubc.ca> Les_Ferch.@MTSG.UBC.CA writes:
>I completely agree.  The reason I was looking for reboot code is to write a
>program or programs that will automatically (and hopefully properly) switch
>my operating environment on my hard drive between plain ProDOS 8 and GS/OS.

[stuff on renaming files]

    A program called Smartboot 8/16 appeared in Nibble last summer.  I
don't remember which issue exactly though.  The program puts a special
boot block on the disk.  When the disk is booted, it checks the caps
lock key to see which postion it is in.  Depending on that, it will
either load PRODOS or SYSTEM/P8.  So just setting the caps key to the
operating system you want and rebooting, you get the operating system
of choice.  The article included three listings: hex dump, assembly
source and a basic program to install it (copy it onto block zero).
    I have it installed on my America Online disk so I can boot into
either version of the program.  Since the two versions use the same
data files, there is no problems.  Even though customer service say
this can NOT be done (according to a friend that called asking), I
HAVE been doing this for months now.  I perfer the look of the GSOS
version of the program but the games only work from the ProDOS 8 version.
    Having the source code to it, the caps lock test can be changed to
do whatever test you like (ex: calling a subroutine on a mindreader
card plugged into slot 8).  I typed in both listings just so I could
compare the two binaries to verify my typing skills.  After looking at
the source a bit, I see a few routines that can be shorter, but for
the moment, "it works," so why bother making changes (yet).
-- 
     ____
 Y_,_|[]|   Eric Mulholland
{|_|_|__|   aj0@sage.cc.purdue.edu
//oo--OO    ...!pur-ee!sage.cc!aj0

mmunz@pro-beagle.cts.COM (Mark Munz) (12/17/89)

In-Reply-To: message from Les_Ferch.@MTSG.UBC.CA

>I completely agree.  The reason I was looking for reboot code is to write a
>program or programs that will automatically (and hopefully properly) switch
>my operating environment on my hard drive between plain ProDOS 8 and GS/OS.

I boot into Prodos 8 (real quick!!) and run a little basic program that
asks me what OS I want. If I choose Prodos 8, it runs Prosel for me, if
I choose GS/OS, it runs "GSOS" for me which starts up the famed slow 
boot :-)

It works real well for me.

Mark Munz

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

	There was a program in Nibble awhile back that had something called
SmartBoot 8/16 - it was a replacement boot block that looked for ProDOS if the
Caps Lock key wasn't down, but looked for */System/P8 if it was down. This has
been really useful - if I'm working on a P8 program, I just press Caps Lock
when I reboot, and boom, into P8 I go, no waiting for GS/OS to boot. I would
post it, but I'm quite sure that doing so would be illegal...

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

bh1e+@ANDREW.CMU.EDU (Brendan Gallagher Hoar) (12/17/89)

just a word of warning.  

Apple changed the boot block on system 5.0 to allow the loading of
sparse PRODOS files.

I wanted to use Smartboot 8/16, but was afraid that the boot block that
it installs might cause the system to break  (or, said correctly, i was
afraid that the boot block that allows the choice between Pro 8 and
GS/OS would not work with later version of GS/OS).

If someone could explore the problems and possibilities of adding the
new boot block code to Smartboot 8/16, I'd appreciate it!

Thanks.

aj0@sage.cc.purdue.edu (Eric Mulholland) (12/17/89)

In article bh1e+@ANDREW.CMU.EDU (Brendan Gallagher Hoar) writes:
>Apple changed the boot block on system 5.0 to allow the loading of
>sparse PRODOS files.
>I wanted to use Smartboot 8/16, but was afraid that the boot block that
>it installs might cause the system to break  (or, said correctly, i was
>afraid that the boot block that allows the choice between Pro 8 and
>GS/OS would not work with later version of GS/OS).
>If someone could explore the problems and possibilities of adding the
>new boot block code to Smartboot 8/16, I'd appreciate it!

    No one says that once smartboot 8/16 is installed that it cannot be
removed if or when the system changes to make misfunction.  As mentioned,
the listing for it is included in the article, so by simply changing the
code to handle sparse files, no problem.
    I was curious to what the change to the boot block is and now read
that it's for sparse file handling.  When would the ProDOS file need to
be sparsed?  The only reason I can come up with why is the quit code for
ProDOS 8.  But IF that code was improved to be more "user friendly" than
this enter pathname stuff, than the extra space causing the sparseness
would be used up, for a good cause.
    Seriously, why would a prodos file need to be sparsed?
-- 
     ____
 Y_,_|[]|   Eric Mulholland
{|_|_|__|   aj0@sage.cc.purdue.edu
//oo--OO    ...!pur-ee!sage.cc!aj0

mattd@Apple.COM (Matt Deatherage) (12/18/89)

In article <3389@sage.cc.purdue.edu> aj0@sage.cc.purdue.edu (Eric Mulholland) writes:
>In article bh1e+@ANDREW.CMU.EDU (Brendan Gallagher Hoar) writes:
>>Apple changed the boot block on system 5.0 to allow the loading of
>>sparse PRODOS files.
>
The original message posted this as a word of "warning".  Not only should
nobody need to be "warned", but merely "informed" (yes, I'm still being
optimistic), but in fact this change took place for System 4.0.  It was
changed again for 5.0 because an annoying developer pointed out that the code
in the 4.0 boot block didn't correctly zero out the last half of a sparse
block.  We eventually got sick of this developer whining and hired him, and
today he's known as Dave Lyons.  (GET TO KNOW HIM!)

>    I was curious to what the change to the boot block is and now read
>that it's for sparse file handling.  When would the ProDOS file need to
>be sparsed?  The only reason I can come up with why is the quit code for
>ProDOS 8.  But IF that code was improved to be more "user friendly" than
>this enter pathname stuff, than the extra space causing the sparseness
>would be used up, for a good cause.
>    Seriously, why would a prodos file need to be sparsed?
>     ____
> Y_,_|[]|   Eric Mulholland
>{|_|_|__|   aj0@sage.cc.purdue.edu
>//oo--OO    ...!pur-ee!sage.cc!aj0

We'll ignore arguments for or against the existence of sparse files in the
ProDOS file system ("why would a prodos file need to be sparsed") and look
at the problem when the essential boot file PRODOS is sparse.

Before this change, there was no telling if the system could boot that way
or not.  The boot block read block zero into a space where there should have
been 512 zeroes, and that could cause a problem.

This was discovered in the testing of 4.0 (the initial release of GS/OS).
The ProDOS FST automatically makes a file sparse if it could be, and we were
interested to discover that using GS/OS to make a file-by-file copy of System
Disk 3.1 produced a sparse PRODOS boot file.  In other words, copying a disk
file-by-file left you with a system software disk you couldn't boot.  Since
it was a hole in the system that might cause problems some day, it was
changed.

-- 
-----------------------------------------------------------------------------
Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome
Send PERSONAL mail ONLY (please) to:  | should not be construed to imply that
Amer. Online: Matt DTS                | Apple Computer, Inc., or any of its
ThisNet: mattd@apple.com              | subsidiaries, in whole or in part,
ThatNet: (stuff)!ames!apple!mattd     | have any opinion on any subject."
Other mail by request only, please.   | "So there."
-----------------------------------------------------------------------------

blochowi@rt7.cs.wisc.edu (Jason Blochowiak) (12/19/89)

In article <0ZWjDCW00WAB00WG8F@andrew.cmu.edu> bh1e+@ANDREW.CMU.EDU (Brendan Gallagher Hoar) writes:
>just a word of warning: Apple changed the boot block on system 5.0 to allow
>the loading of sparse PRODOS files.
[Mentions concern about SmartBoot 8/16 causing problems]
>If someone could explore the problems and possibilities of adding the
>new boot block code to Smartboot 8/16, I'd appreciate it!

	First off, SmartBoot 8/16 is just a boot block - something of a
technicality. I've had SB installed for quite awhile now (I think since
System Software 4.0), and I've yet to have any problems with it, up to
System 5.0.2. As someone else pointed out, it would seem strange to have a
sparse ProDOS file, but apparently somebody out there did.

	As for looking into it - I don't think it'd be all that difficult to
disassemble Apple's new boot code just to see what it does differently, and
then add that to SB 8/16, but as far as distributing it, I dunno. I suppose
that I could manually generate a psuedo-diff file (what lines to delete, what
to add), but that'd probably be a pain. Anyone have other suggestions?
--
      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) (12/21/89)

In article <4118@puff.cs.wisc.edu> blochowi@rt7.cs.wisc.edu (Jason Blochowiak) writes:
>
>	As for looking into it - I don't think it'd be all that difficult to
>disassemble Apple's new boot code just to see what it does differently, and
>then add that to SB 8/16, but as far as distributing it, I dunno. I suppose
>that I could manually generate a psuedo-diff file (what lines to delete, what
>to add), but that'd probably be a pain. Anyone have other suggestions?

	Excellent idea if you are into incompatiblity.  What happens
	if we change the boot blocks again?  And again?  Your programs
	will have to change too...

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

Cary Farrier
-- 
+---------------------------------------+---------------------------------+
| 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.             |
+-------------------------------------------------------------------------+

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

In article <4118@puff.cs.wisc.edu> blochowi@rt7.cs.wisc.edu (Jason Blochowiak) writes:
> [I wrote about looking into adding support for sparse ProDOS files to
>  SmartBoot 8/16, someone else mentioned the problem, and I nuked the whole
>  thing :) ]

	Well, I took a poke at Apple's code briefly, but decided that I didn't
really need to, so I stopped. I then looked at SmartBoot 8/16 to see how it
loaded the files in, and I popped out one of Apple's manuals that details
the way ProDOS stores files. Anyways, SB stops when it gets to a block that's
0, so it'd almost certainly die on a sparse ProDOS file. What would have to be
changed (or, I hope you weren't expecting code :) is: After finding the
appropriate directory entry corresponding to the file being looked for, grab
the BLOCKS_USED field, and hold it somewhere. Then, in the file read routine
(forgot the name or location, but it's pretty obvious), instead of stopping
when you hit a 0 block, you: Look up the current block to be read. If it's a
0, you zero out the target area of memory, increment the target pointer, and
increment the index into the index block. If it's a non-0 block, you read it
in normally, and then decrement the BLOCKS_USED count - if it hits 0, you're
done, otherwise go back to read the next block. Being the lazy guy I am, I
probably won't code this unless I have to... If someone else does decide to
code it, I'd be interested in seeing the result.

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

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

In article <37432@apple.Apple.COM> farrier@Apple.COM (Cary Farrier) writes:
>In article <4118@puff.cs.wisc.edu> blochowi@rt7.cs.wisc.edu (Jason Blochowiak) writes:
>>	As for looking into it - I don't think it'd be all that difficult to
>>disassemble Apple's new boot code just to see what it does differently, and
>>then add that to SB 8/16, ... [I nuked part of my original article]
>	Excellent idea if you are into incompatiblity.  What happens
>	if we change the boot blocks again?  And again?  Your programs
>	will have to change too...

	Why would there be any incompatibility? This stemmed from the
discussion of sparse ProDOS files - the point of looking at Apple's code (which
I ended up not really doing) was to determine how sparse files were handled
by the new boot block.

	Unless there's going to be some additional functionality added to the
boot block (and I can't think of anything that would fit into the framework of
what Apple appears to be interested in providing), there wouldn't be any
problems.

	Perhaps you thought I was going to actually steal code from Apple's
boot block and insert it into the SB 8/16 code? I thought I made it
sufficiently clear that my intent was to learn what Apple considered reasonable
handling of sparse files. Oh, well... I always was better with verbal
communication ;)

	Btw, this isn't my program that's being discussed - SmartBoot 8/16 was
published in Nibble (sorry, can't remember the author at the moment).

>| 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