Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!tektronix!reed!kamath
From: kamath@reed.UUCP (Sean Kamath)
Newsgroups: comp.sys.apple
Subject: Re: Reset in different IIs
Message-ID: <9003@reed.UUCP>
Date: 23 Apr 88 23:34:42 GMT
References: <8804201856.aa04123@SMOKE.BRL.ARPA>
Reply-To: kamath@reed.UUCP (Sean Kamath)
Organization: Reed College, Portland OR
Lines: 59

In article <8804201856.aa04123@SMOKE.BRL.ARPA> PGOETZ@LOYVAX.BITNET writes:
>
>   I'm disappointed to hear that you can't change the ROM reset vector in
>the IIc.

You can.  You just burn a new PROM. . . :-) 

>	  It can be a useful cracking tool in the II+: I modified my RAM
>card so I can flip a switch & write-protect it.  So I load in the monitor,
>change the reset vector to do what I want it to, flip the switch, & boot
>the protected program.  Then I (hopefully) reset into the monitor.
>   So:  Can people with manuals or who actually try this tell us on which
>IIs reset pulls in the old ROMs?  (Actually, this is hard to believe - I
>think in the II+, the 6502 Reset line is hard-wired to put the contents
>of FFFE and FFFF in the program counter.)
>
>Phil Goetz
>PGOETZ@LOYVAX.bitnet

A better way is to buy an old integer card.  Then you *do* reset into the
monitor, no matter what.  When they came out with the autostart monitor, how
do you think they got it to autostart?  It no longer jumps to the monitor.
When you turn on a 6502, you do the same thing as a RESET, the only
difference being the general state of the machine is known, but memory is
scambled.  Because the memory is garbage, the possibility or the 3fe vector
having the third byte being the second eor'ed with $a5 is almost humorous.
In anycase, on an autostart rom, the reset is not vectored to to ROM, as it
originally was.  If you look at FFFC & FFFD (the reset vectors, I believe)
on a ][ and ][+ (that's why they called it a plus. . .), they both point to
ROM, but one (on the ][) goes straight to ff59, while the other goes to fe
something, which checks for the "powerup byte", and if it's invalid, starts
the startup sequence, and usually reboots (it doesn't reboot if you don't
have a disk driver, fer instance).  If it's valid, it goes to where it
points (via a push and rts, I believe, but I don't have my rom listings with
me, and I'm not at home. . .  BTW:  If you want to get out of DCOM and look
at the ROM, fer instance, to the OA-ESC @ sequence.  The do what you want.
When you are done (this includes disk access), PR#3, call 2*4096+16+12
(which is 201c in hex).  THis warmstarts DCOM without initiallizing the
modem or screen (hence the PR#3).), which is usually ff69, until DOS get's
to it, then it's 9d84 (I think it's a d, though it might be a b or
something), which is DOS's warmstart.  This is why you fiddle with that
vector.  

On an integer card, it has the old ROM in it, which is not vectored.  Also,
because the card pulls ROMEN' lo, it has abolute control over these vectors,
and thus there is *no way* short of hardware to circumvent this.  Also, if
you want, you can burn your own 2732's and put some neat stuff in there.  I
want to get Understanding the Apple ][ by Mr. Sather.  He appearently has
some neat stuff in there.  I have Understanding the Apple //e.


Well!  Anymore questions? :-)

Sean Kamath
-- 
UUCP:  {decvax allegra ucbcad ucbvax hplabs ihnp4}!tektronix!reed!kamath
CSNET: reed!kamath@Tektronix.CSNET  ||  BITNET: reed!kamath@PSUVAX1.BITNET
ARPA:  reed!kamath@psuvax1.arpa
US Snail: 3934 SE Boise, Portland, OR  97202 (I hate 4 line .sigs!)