scott@applix.UUCP (Scott Evernden) (06/26/87)
Because I can't stand not knowing, I'd like to find out how to open up the WCS for writing. I think I understand that some sort of checksum failure would likely fault the machine if anything got changed, but I assume that THAT code could be lobotomized. Please don't tell me it can't be done, because I won't believe you. Clearly, this info would be for my own mindless hacking... -scott
michael@stb.UUCP (Michael) (06/30/87)
In article <1017@bloom-beacon.MIT.EDU> wpd@athena.mit.edu (William P Doyle) writes: >In article <535@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: [Question: How do you write to WCS?] >enough?) Anyway, the PAL's contain a flip-flop labelled "WPRO" for >Write-Protect. This puppy is set up such that once it is enabled, the >only way to disable it is to issue a"RESET". It gets set when the Hmm... 1. Wasn't someone going to make some PAL's available that were a real toggle at that address? 2. I have a program called "changekickstart", which causes the machine to reboot back to "insert kickstart". Anyone know how that works? Michael -- : Michael Gersten seismo!scgvaxd!stb!michael : Monsters from outta space -- 3-11-2
ali@rocky.STANFORD.EDU (Ali Ozer) (07/02/87)
In article <1618@stb.UUCP> michael@stb.UUCP (Michael) writes: >2. I have a program called "changekickstart", which causes the machine to >reboot back to "insert kickstart". Anyone know how that works? There's an Exec call named "ColdReset". "Changekickstart" probably uses this call to cold boot the Amiga. To find out how that works, well, you can always single step through the code... Ali Ozer, ali@rocky.stanford.edu
ali@rocky.STANFORD.EDU (Ali Ozer) (07/03/87)
In article <389@rocky.STANFORD.EDU> I so surely wrote: >There's an Exec call named "ColdReset". "Changekickstart" probably uses >this call to cold boot the Amiga. To find out how that works, well, >you can always single step through the code... Well, the Manx libraries apparently have not read the manual I've read, cause they don't know about ColdReset. In fact, ColdReset isn't even included in the list of library vectors in the back of the Exec manual. Sigh. I saw it on page A-46 of the "Libraries & Devices" volume of RKM, published by Addison-Wesley, where there's a single paragraph about how ColdReset will cause a system reset identical to the one that occurs as power-on. I should try these things before I send out misleading messages! Thanks, Bryce, for pointing this out. ps. BUT, despite this, I guess you can still single step through Changekickstart to see how they do what they do to cold reset the Amiga! Ali Ozer, ali@rocky.stanford.edu
ford@crash.CTS.COM (Michael Ditto) (07/03/87)
In article <389@rocky.STANFORD.EDU> ali@rocky.UUCP (Ali Ozer) writes: >In article <1618@stb.UUCP> michael@stb.UUCP (Michael) writes: >>2. I have a program called "changekickstart", which causes the machine to >>reboot back to "insert kickstart". Anyone know how that works? > >There's an Exec call named "ColdReset". "Changekickstart" probably uses >this call [...] Actually, there is no such function. It is documented but does not exist. (sort of backwards from many other AmigaDos functions 8-). -- Michael "Ford" Ditto -=] Ford [=- P.O. Box 1721 ford@crash.CTS.COM Bonita, CA 92002 ford%oz@prep.mit.ai.edu
billk@pnet01.CTS.COM (Bill Kelly) (07/04/87)
About change Kickstart:
It's about 14 instructions long. (I re-wrote mine to not flash the diskpay
first.)
<this may be a slightly garbled message -- lots of line noise>
Basically it does a loop $300000 (I think) times to flash the display. (Writes
the loop count to $DFF180)
Then it re-vectors the privilege violation trap to point to it's own code.
(Trap number eight, address $20) It then commits a privilege violation by
trying to write to the status register. The 68000 goes "hey!" and jumps to
the privilege violation trap handeling code. This code moves to the stastatus
register to disable all interrupts. (If I remember correctly) and then puts
the addresses $F80000 in a0 and $F00000 in a1 (or vice-versa?) and does a
RESET. I think. What the heck -- I'll try to find it...
* QuicKick -- Re-KickStart without wasting time Bill Kelly
* by 'rainbowing' the CRT. 19-Mar-87
CODE
lea $C(pc),a0
move.l a0,$20
move #$2700,sr
nop ; Why?????
nop ; Why?????
move #$2700,sr
lea $FC0000,a0
lea $F80000,a1
moveq #0,d0
reset
END
NOTE: I am not the original author of this code! I just disassembled it,
looked at it, typed it in using Ed (omitting the initial loop in my
code so that the CRT wouldn't flash), and re-assembled it.
(And added a big .doc file)
For a disassembley of the original code and some discussion about
the way it works, see QuicKick.doc
Bill Kelly
-----
Well, I was close... BTW, since then I have found out why those nop's have to
be there. If they're omitted, QuicKick will not work with FAST RAM:
Interesting, huh? <darn line noise -- I hope it came through ok!??>
Bill
Arrgh! that's messed up! after the lea $Fc0000,a0 it should read:
lea $F80000,a1
moveq #0,d0
reset
Arrgh. I can't tell if it's messed or not. If it is, and you're interested,
leave me EMail and I'll mail the source to you..
Sorry,
Bill
--
Bill Kelly {akgua, hplabs!hp-sdd, sdcsvax}!crash!pnet01!billk
(Don't use pnet01!billk; try crash!pnet01!billk -- Thanks!)
"When your IQ reaches 28, sell."fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (07/10/87)
In article <390@rocky.STANFORD.EDU>, ali@rocky.STANFORD.EDU (Ali Ozer) writes: > In article <389@rocky.STANFORD.EDU> I so surely wrote: > >There's an Exec call named "ColdReset". > > I saw it on page A-46 of the "Libraries & Devices" volume of RKM, > published by Addison-Wesley, where there's a single paragraph about > how ColdReset will cause a system reset identical to the one that occurs > as power-on. According to the RKM ColdReset can only be executed in supervisor mode. If you try to execute it from user mode it will cause a privilege violation trap. How do you change to supervisor mode? --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...akgua!usfvax2!jc3b21!fgd3
kim@amdahl.amdahl.com (Kim DeVaughn) (07/11/87)
In article <1017@bloom-beacon.MIT.EDU>, wpd@athena.mit.edu (William P Doyle) writes: > In article <535@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: > >Because I can't stand not knowing, I'd like to find out how to > >open up the WCS for writing... > >Please don't tell me it can't be done, because I won't believe > >you. Clearly, this info would be for my own mindless hacking... > > > >-scott > > Now, understand, I am not saying it can't be done, but, I think that > it would be so hard as to not be feasable. Well, it really isn't too difficult, but you do need to do a little bit of soldering, and such ... Attached is something that I posted for Steve last September. Since there seems to be interest, here it is again. BTW, sorry for the delay in responding to this, but "amdahl" was off the net a week or so for a major equipment move, and then there were some problems getting the dial-ups working, etc. I *think* we're back online now ... /kim vvvvvvvvvvvvvvvvvvvvvvvvvv from Steve Schoettler vvvvvvvvvvvvvvvvvvvvvvvvvvvvv Making Kickstart RAM writable. If you've ever wanted to modify kickstart routines, here's the information you've been waiting for. If you use metascope and would like to trace your program as it calls some kernel routine or set breakpoints in the libraries, the following information should be very useful. How many times have you called OpenWindow() and bombed but didn't quite know why? Even with this modification, when you're not interested in writing to kickstart, you can switch the capability off and it's write protected just like a normal Amiga! Of course, this leaves the ram open to crazy programs, but that simply means that if a program goes wild and happens to write to a critical area you have to turn off the machine to reboot kickstart, rather than just inserting workbench. To me, the ability to debug is worth it. Besides I can easily return to write protection. First, a few words about how the kickstart sequence works: When you turn on your Amiga the bootup ROM reads the Kickstart disk into the Kickstart RAM at $fc0000. Then the 68000 does a read to the location $f80000. (Actually, anything with Address bits 19-23 high and A18 low would do). This condition is detected by a PAL called DAUGCAS, which write protects the kickstart ram. There are three methods you could use to disable the write protect: (1) Install a switch to force the write protect signal (WPRO*) inactive. This is the method I used, and is really simple because C-A graciously left two holes in the circuit board for the wires to my switch. It could probably be removed (in case you had to take it in for servicing at a later time) without leaving any traces. Well, actually you would have to drill a hole in the back panel to mount the switch. (2) Replace the PAL with one that had a different equation for the WPRO*. This has the glamor of not needing any solder. The equation could be set up to never write protect the RAM, but that's probably not such a good idea. A better method would be to make the RAM toggle the WPRO* signal with every read to $f80000. A simple C or Basic program could be written to read this location. Just so you know what state it's in (WPRO* or not), you could read location $ffffff, write something else to it, and read it back again. If it's the same, it's write protected, otherwise it's not so put the old value back. (By the way, the location you choose should not be any code another task might be executing. Maybe you could overwrite the copyright notice. To be safe, a forbid() and permit() would probably be a good idea.) (3) Remove the instruction that reads location $f80000 in the first place. This is in the Boot Rom, so you'd have to change that. I don't like that solution because it's permanent. If you like the PAL method (2), you're on your own for now. I have figured out how to make the new PAL, but I can't post the equations and I can't distribute the chips without violating C-A's copyrights. I have gotten a preliminary OK from Commodore to distribute the PALs, and as soon as I get a written OK, I'll let you know about it. They should cost less than $10. Following is a description of how to install a WPRO* switch (method (1), above): ********** But first, a disclaimer ******************************* **** **** 1. I can't be responsible for anything you do to your Amiga. **** I believe I've explained this thoroughly enough so someone **** with soldering experience and a reasonable mechanical **** intuition can do it without much difficulty, but you **** are taking your computer into your own hands. **** **** 2. Commodore may have or may in the future change the layout **** of the circuit board or change the PAL's, making these **** instructions obsolete. If your board doesn't look like **** what I'm describing, DON'T DO ANYTHING. **** **** 3. This will void your warranty. **** **** 4. I represent no company or organization in any way whatsoever. **** ******************************************************************** UNPLUG YOUR AMIGA!!!! It will be very easy to strike a metal object (soldering iron, solder, resistor, wire, watch, etc) across two consecutive traces and who knows what might happen. First, you need to take off the cover of your Amiga and take off the metal shield that covers the circuit boards (yes, all 19 screws and 2 twist tabs). So we agree on orientation, the front of the Amiga is towards you, the power supply is on the left, and the parallel port is on the upper right side. I will refer to the rear of the Amiga as the "top." There is a main mother board, and an L-shaped "daughter board" which is upside down, above the main board. The PAL is located on the daughter board at location J-6. It's on one of the inside corners, next to the letter "J" and it says "DAUGCAS" alongside it. This is a 20 pin chip. There should be a white outline of the chip between the pins with a notch at one end. From the notch, count pins clockwise until you get to pin #13, which is the third one from the upper right corner of the chip. Pin 13 is the WPRO* signal. Originally, the WPRO* signal went through a resistor and LED to +5V. Since WPRO* is active low, the LED would go on during bootup while the ram was being written, and then go off at about the time it told you to insert the Workbench, and remain off until you turned the machine off. Well, it's silly to have an LED inside a closed box, so C-A decided to save costs and not insert the resistor and LED, but the circuit board should still be the same. I don't know on how many boards the LED was inserted, or on how many boards the LED socket will still be around, so inserting the wire to the switch may be a slightly different procedure for some of you. If you follow the trace from pin 13 of DAUGCAS it will go to one of the resistor terminals. Insert the stripped end of a wire into this hole at the left end of the resistor. (Just heat the hole with your soldering iron and push the wire through). As a precaution, before working on the board, put a piece of paper under where you'll be soldering so solder splats don't hit the board below. I didn't get anything on my paper, but it's good prevention. Above the resistor space is a white box marked "1" with 2 solder holes. Insert the stripped end of another wire in the left-most of these two holes inside the box. You now have the two wires necessary to run to your switch: one is connected to WPRO* and the other to +5V. With the switch "on" you will pull WPRO* hi (inactive) and make the ram writable. A note about mounting of the switch. I suppose you will want to mount this in the back panel. This panel is removable, so it's easy to put it flat on a table and drill a new hole. Before you remove the back panel and drill the hole, however, put the metal shield back on (screws not necessary) and hold your switch in the location you wanted. If it's like most switches, it probably won't fit next to the metal shield UNLESS it's as far right as possible (over the keyboard jack). Now, go drill the hole. When cutting the wires, leave a few inches of slack so they can fit through the crack in the metal shield in the upper right corner. (convenient, huh?) Now put it back together and you have switchably writable kickstart! A note about operation: ======================= For normal operation, leave the switch "off" when you power up. This will look and act exactly like a normal Amiga. To enable writing the ram, turn the switch "on". If, after you have been writing the ram, you decide to write protect it, the switch alone won't do it - TURNING THE SWITCH BACK OFF STILL LEAVES THE RAM WRITABLE. You need to either do a read to location $f80000 or turn the machine off and on again. If you want the facility to turn off WPRO* with a switch, you can use a 3 pole switch with WPRO* in the middle terminal and +5V on one side and GND on the other, but there isn't a convenient hole for GND so you'd have to find one on the board. This would have an immediate reaction with any direction of the switch. Technicalities: =============== All of the above works, but if you want to know a little more about how, read on. The WPRO* signal is actually both an output and input of the DAUGCAS PAL. The logic used to generate it has what we call a "set" term and a "reset" term. It acts like a S/R flip-flop. The "set" term makes WPRO* active when the processor does a read cycle from an address whose bits 19-23 are high and bit 18 is low. The "reset" term comes from the hardware reset line that is active when the machine powers on. Once WPRO* is set, it won't be reset until power on again, and once it's reset it won't be set until that read instruction. WPRO* is both an output and an input of the PAL. The output is generated from the above equation, and the input is used to disable a write signal from ever getting to the RAM. The very astute of you might criticize the forcing high of a low output. Well, the only time the output is forced is during the read cycle (a couple hundred nanoseconds), because after that WPRO* is tricked into thinking it was reset and the output agrees with what is being forced so no more contention. The PAL used, according to the manufacturer, is able to handle voltage applied to outputs up to Vcc, which is +5V, so we're within specs. ******************************************************************** Happy hacking! Steve Schoettler ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,seismo,oliveb,cbosgd}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
billk@pnet01.CTS.COM (Bill Kelly) (07/12/87)
>How do you change to supervisor mode? [so that you can execute ColdReset]
Well, you could probably call Exec_Lib SuperState.
It says its purpose is to "enter supervisor mode with user stack."
If it doesn't work, (and since you want to reboot), you could re-vector the
68000's privilege violation trap to point to your own code and then do a
privilege violation. (i.e. Write to the status register from user mode.)
Then the 68000 will trap and jump to your routine (since you vectored the trap
to point to your routine). You will then be in supervisor mode and should
then be able to call ColdReset. I have not been able to find the LVO for Cold
Reset, myself. If anyone knows the LVO for ColdReset, could you please let me
know? (Or, if you know how GOMF resets the machine -- it does it really
quickly -- please clue me in.)
Thanks,
Bill
--
Bill Kelly {akgua, hplabs!hp-sdd, sdcsvax}!crash!pnet01!billk
(Don't use pnet01!billk; try crash!pnet01!billk -- Thanks!)
"When your IQ reaches 28, sell."