Forum unknown
· Programming
#Kickstart Help
21 messages in this thread
Great! now what do you do with it? (In direct query to C-A guys on this,
there is NO way (other than a reset, alt-a-a) to get the KS area writeable).
You will also find that DOS is in BCPL, with REALLY WIERD register usage and
stacks that grow UPWARD and NO usage of RTS (you call a subroutine to return
from one). -'jes thot I'd warn you before you go bonkers trying to understand
any disassemblies. -Larry-
Unless c-a-a is directly wired to some hardware in the machine, it's just
calling a software routine which then unprotects the WCS and jumps back to
the WB load routine… so obviously it can be unprotected by software. Wait,
c-a-a doesn't reload WCS! Is there a way to get the machine to "rekick"
without powering down? – Bela
Got this message on "another BBS system"..shows a way that one man has
deprotected the WCS. It does have a problem tho..one you return from the
program the Amy crashes and you need to re-Kick it. Here it is:
Msg: #3338 Sec: 9 – Programmer's Corner Date: 18-MAY-86 01:36 PM
To: John Mesiavech (F) (U) From: Ken Jordan Subj: Write Many Ram:
I still haven't figured out how to write protect the ram but try this: –(in
68000 m.l.)-setsuperstate disable interupts & all dma do a RESET instruction
(this pulls the reset pin so that everything resets except the 68000 which
continues on) -presto- the 64k boot rom will be at 0 and you can write to
kickstart (fc000000) (and read also). If you do this the hit ctrl-amiga-amiga
the machine will see that the kickstart checksum is wrong and ask you to
insert kickstart and WILL reload the kickstart proving that the ram was
modified and gets reloaded. Like I say I am still reversing all of the roms
to figure out just what re-write-protects the KS. —Hope this will help->Ken
Jordan
Yeah. That doesn't really qualify as a way to modify the WCS until it can be
done without crashing (and forcing a rekick), tho… – Bela
Hmm..Upon rereading Ken's message..I find that the system will crash upon
REBOOT (Ctrl-Amiga-Amiga)..NOT on exit from program. Presumably this has to
do with the self-check that the Amiga does on each reboot. So..it IS
feasable to open the WCS and write what's in there out..or patch it
dynamically…just have to be cautious of rebooting.
On the Kickstart disk, block 1CA, there is a string… "DF0:" I changed it to
read "DF1:" The Kickstart booted normally without any sign of checksum
problems. The only effect was that the Current Directory ended up as DF1:
Fascinating. Useless, but fascinating.
wait a minute! do you mean it then went to DF1: for the workbench disk? or
once CLI came up it was as if you had done a CD DF1:? if it's the former,
that's a MAJOR wonderfulness! –Scotty
No Scotty, it was definitely as I called it, a useless but fascinating
excercise. It acted as if I had done a CD DF1: Since it is just as easy to do
that from the startup-sequence, it's no big deal. The fascination comes into
it when you think about why the Kickstart code didn't barf with a checksum
error. Another interesting block is 1F9 (or thereabouts. It has the strings,
"Movebytes", "Xref", and "Chksum" in there.
No Scotty, it was definitely as I called it, a useless but fascinating
excercise. It acted as if I had done a CD DF1: Since it is just as easy to do
that from the startup-sequence, it's no big deal. The fascination comes into
it when you think about why the Kickstart code didn't barf with a checksum
error. Another interesting block is 1F9 (or thereabouts. It has the strings,
"Movebytes", "Xref", and "Chksum" in there.
wait a minute! do you mean it then went to DF1: for the workbench disk? or
once CLI came up it was as if you had done a CD DF1:? if it's the former,
that's a MAJOR wonderfulness! –Scotty
On the Kickstart disk, block 1CA, there is a string… "DF0:" I changed it to
read "DF1:" The Kickstart booted normally without any sign of checksum
problems. The only effect was that the Current Directory ended up as DF1:
Fascinating. Useless, but fascinating.
Hmm..Upon rereading Ken's message..I find that the system will crash upon
REBOOT (Ctrl-Amiga-Amiga)..NOT on exit from program. Presumably this has to
do with the self-check that the Amiga does on each reboot. So..it IS
feasable to open the WCS and write what's in there out..or patch it
dynamically…just have to be cautious of rebooting.
Yeah. That doesn't really qualify as a way to modify the WCS until it can be
done without crashing (and forcing a rekick), tho… – Bela
Got this message on "another BBS system"..shows a way that one man has
deprotected the WCS. It does have a problem tho..one you return from the
program the Amy crashes and you need to re-Kick it. Here it is:
Msg: #3338 Sec: 9 – Programmer's Corner Date: 18-MAY-86 01:36 PM
To: John Mesiavech (F) (U) From: Ken Jordan Subj: Write Many Ram:
I still haven't figured out how to write protect the ram but try this: –(in
68000 m.l.)-setsuperstate disable interupts & all dma do a RESET instruction
(this pulls the reset pin so that everything resets except the 68000 which
continues on) -presto- the 64k boot rom will be at 0 and you can write to
kickstart (fc000000) (and read also). If you do this the hit ctrl-amiga-amiga
the machine will see that the kickstart checksum is wrong and ask you to
insert kickstart and WILL reload the kickstart proving that the ram was
modified and gets reloaded. Like I say I am still reversing all of the roms
to figure out just what re-write-protects the KS. —Hope this will help->Ken
Jordan
i think if you execute a RESET instruction, the KS RAM will be unprotected.
unfortunately, the rest of the hardware gets reset, too.
–Scotty
Right. That's not good enough — it's akin to what the IBM AT does to access
"extended" memory, and is reasonably kosher in a single tasking environment,
but you'll never get away with it in a multitasking environment like the
Amiga. – Bela
Right. That's not good enough — it's akin to what the IBM AT does to access
"extended" memory, and is reasonably kosher in a single tasking environment,
but you'll never get away with it in a multitasking environment like the
Amiga. – Bela
i think if you execute a RESET instruction, the KS RAM will be unprotected.
unfortunately, the rest of the hardware gets reset, too.
–Scotty
Unless c-a-a is directly wired to some hardware in the machine, it's just
calling a software routine which then unprotects the WCS and jumps back to
the WB load routine… so obviously it can be unprotected by software. Wait,
c-a-a doesn't reload WCS! Is there a way to get the machine to "rekick"
without powering down? – Bela
Well, one of the other replies to this tells of a way to modify KS, and it
might be fun to play with. I was going to try modifying KS on the disk
itself. (easy with Diskzap), and see if I could get it booting the WorkBench
from DF1: (or DH0: if available). The place to do this MIGHT be in block
X01CA or so. Of course, that would change the checksum, and the KS would
probably be asked for again. Depending on the checksum method, it may be
sufficient to merely change another "text" message character to compensate.
Well, one of the other replies to this tells of a way to modify KS, and it
might be fun to play with. I was going to try modifying KS on the disk
itself. (easy with Diskzap), and see if I could get it booting the WorkBench
from DF1: (or DH0: if available). The place to do this MIGHT be in block
X01CA or so. Of course, that would change the checksum, and the KS would
probably be asked for again. Depending on the checksum method, it may be
sufficient to merely change another "text" message character to compensate.