Re: How to boot 16k program?

[dempson@actrix.gen.nz (David Empson)]

Dave Althoff <dalloff@gcfn.org> wrote:

> ]INT
> >CALL-151
> *C600G
> 
> ...you activate the Integer BASIC "ROM".  Not really ROM, but it might be
> close enough.  Anyway, since the mere act of initiating a boot cycle
> shouldn't affect the ROM switch (unless something in the boot process
> does)

It probably does, though I'd have to disassemble the relevant code to
prove it.  Beneath Apple DOS isn't clear enough on this point, and I
don't feel like digging out a IIe and DOS 3.3 boot disk to experiment
with.

> : Another possibility is it may use undocumented 6502 opcoded that
> : didn't make it to the 65c02.  I have seen a couple of programs that
> : will only run with a 6502 installed.
> 
> Possible, but somehow I don't think that would keep the thing from booting.

It is certainly a possibility.  The original Apple Logo would crash on a
65C02, because it was using an "undefined" 6502 opcode and relying on
the effect.  The instruction became a NOP on the 65C02, so the boot code
crashed.

> By the way, the big difference between DOS 3.2 (or DOS 3.2.1) and DOS 3.3
> is that DOS 3.2(.1) uses 13-sector tracks while DOS 3.3 is 16-sector.  The
> upgrade from DOS 3.2 to DOS 3.3 included a ROM swap, I believe in the disk
> controller

Two of them: the P5 and P6 PROMs on the disk controller were replaced
with P5A and P6A.  This replaced the firmware at C600 as well as the
logic state sequencer.

That raises another point: an old DOS 3.2 program may be relying on the
code in the original disk controller ROM, and the 16-sector changes
could be causing a problem.

> (I never dealt with DOS 3.2 and certainly never did a 16-sector
> upgrade!)

Likewise.  I didn't start using the Apple II until 1981.  16-sector was
well established by then.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand