This file discribes how to modify kickstart to automatically "ADDMEM" on boot up, and how to change the upside down hand to any graphics you want. Also included in this file is the text of a message I posted some time ago discribing how to patch WACK to allow you to redirect output anywhere, such as a printer or disk file - super valuable for hacking. I hope this text informs and encourages you to have some fun of your own. Too many people have forgotten what computers really are - the world's greatest toy!!! On with it... Patching kickstart: The first question to answer is "Where do I put my patch?". One good spot is the place where the upside down hand is drawn, which is where I've put the "ADDMEM" patch. The second question is "How do I send the bootup routines to my code?". I have chosen to modify a pointer in the device driver-type structure at the beginning of the "strap" routine. How did I find out about "strap"? You type "mods" in the 1.0 version of WACK and it gives you a list of devices,resouces,and that kind of stuff. "strap" is the code that boots a "workbench" type of disk and displays the upside down hand. The address that WACK V1.0 gives you is the address of a "rom tag". A "rom tag" is a fancy name that means a bunch of data. The format of the data is found in the documentation of the skeleton device driver in the ROM KERNAL MANUAL VOLUME 2, near the very back. The pointer we are going to change is called "RT_INIT". It's a pointer to the "strap" routine. The pointer, located at address $FE889A normally contains $FE88D6. We'll change it to $FE8CFE, the part of kickstart that displays the upside down hand. I'll take about the display routine in detail later. Now we need code to put at $FE8CF8. Fortunately, V1.2 of kickstart added a very convenient command to add memory. Here's a routine to do it: JMP $FE8D6A ;SKIP OVER THIS PATCH (SO IT WILL ONLY BE RUN ONCE) MOVEM.L D0/D1/D2/A0/A1/A6,-(A7) MOVE.L 4,A6 MOVE.L #NUMBER OF BYTES TO ADD,D0 MOVE.L #$10005,D1 ; ADD "FAST" MEMORY MOVEQ #0,D2 MOVE.L #$ADDRESS OF EXTRA MEMORY,A0 SUB.L A1,A1 JSR -618(A6) MOVEM.L (A7)+,D0/D1/D2/A0/A1/A6 JMP $FE88D6 ;GO TO THE NORMAL "STRAP" PROGRAM. OUR PART IS FINISHED. Simple eh? IMPORTANT NOTE!!!: If you have done the AMAZING COMPUTING 512K upgrade and did the 2 chip fix which disables the RAM so it won't be allocated as chip RAM.... you must add a few lines of code to enable the RAM BEFORE you do the add!!!! A few lines like this: BCLR #7,$BFD100 ;TURN ON MOTOR BSET #3,$BFD100 BCLR #3,$BFD100 BSET #7,$BFD100 ;TURN OFF MOTOR BSET #3,$BFD100 BCLR #3,$BFD100 The changes can be made fairly easily using DISKZAP. Here are the sector numbers: (I think the byte numbers are right, but double check me! That goes for all the numbers I give in this file.) The pointer: SECTOR $145, BYTE $9A The display hand patch code: SECTOR $147, BYTE $F8 *********************************************************************** ******** NOW FOR THE REALLY FUN PART!!!!! ******** AMAZE YOUR FRIENDS WITH A CUSTOM BIT MAP WHERE THE ******** "INSERT WORKBENCH" SCREEN USED TO BE (BEFORE YOU MODIFIED ******** IT USING THE INFORMATION BELOW) *********************************************************************** THE DISPLAY HAND ROUTINE IN DETAIL: This is the routine that is called when you boot (or reset) and have a disk in the drive that is not a bootable disk (or no disk at all). The infamous "upside down hand" routine. It uses a combination of line drawing and straight bit maps to optimize memory use. The hand and the disk are made by drawing lines and doing area fills. The text - "Work Bench", "V1.2" - is made using straight bit maps. Because the routine is table driven, modifying the display is easy. All you have to know is the format of the tables. Since the AUTO-ADDMEM fix discribed above uses the line draw portion for space, I will talk about the bit map part. First, load up DPAINT and create a picture, any picture, as long as it isn't too big. USE THE ONE COLOR MODE! Before you get a feel for how much room you have, keep it very small. Save it as a brush, so it won't be saved in a compressed format. Now you need to know the format of the bit map in "strap": The first byte determines whether or not this is the last display sequence. If the high bit is set, the routine exits. The second byte is a bit plane mask, determining which bit planes may be written to. If this is $FF, then all bit planes are writable. Which ones are actually written to depend on which color register was defined as the "pen". In this case, color register 3 was chosen. This means that, assuming all bit planes are enabled, bit planes 1 and 2 will be written in with ones, selecting color register 3, just like we asked. If however, we set the mask to 2, only bit plane 2 will be written in, and so we will actually be displaying color register 2. If we put a 1 in, color 1 is displayed, and if 0 is there, nothing is displayed (not real useful). Nothing mysterious there. The third and forth bytes are the dimensions of the thing we are displaying, the third byte being the width and the forth the height. The fifth and sixth bytes are the coordinates to place the picture, first X, then Y. After that is the actual data. "Where do I get the 'actual data'?" We examine that DPAINT file you created. Type "TYPE FILENAME OPT H", where "FILENAME" is the name of your picture. You should see a bunch of hexadecimal numbers and ASCII text to the right. Notice "ILBMHMHD". After that notice 4 bytes which are of no use to us. Continue and note that you find the width and height as 1 word each next to each other in a convienient hex form. Write them down so we know them later. Next find "BODY" and notice the size in bytes following it. I hope that number isn't larger than about $190!! If it is, scale back a bit. Now the nasty part: copy down all those strange looking numbers following the size. This is another reason to keep the picture small!!! As mentioned before, your picture can be displayed in any of 3 color registers. You can define the color registers to be anything you want. Just locate sector $146 and find the byte sequence that is as follows: 0FFF0000077C0BBB. They are the first 4 color registers. Place your picture in the format discribed above at sector $148, byte $1B8 (or whereever you see "00010408...") For those of you who have been busily skipping over all of the above and just want an example, here it is: 00 01 04 08 55 66 0123456787898... more to come color #1 width height X & Y destination your picture (FF-the end) There is no limit to what kinds of things you can create except how many bytes you can find!! I personally have a simple white on black "INSERT DOS", but you could get really elaborate. For example, you could write a custom routine to draw a circle with a line through it and the letters S and T in the center. BE CREATIVE!!! HAVE FUN!!! NOTE: THIS NEXT ONE IS SUPER USEFUL FOR TEARING APART ROM ROUTINES (AND OTHER THINGS) Patching WACK V1.004: For those who are interested, I patched WACK so that you can redirect output anywhere, such as a printer or disk file (defaults to AmigaDOS window)...best of all, this can be done by CHANGING ONLY 3 BYTES!!!!!!!! Here it is: (assumes V1.004 of WACK) 1) From FILEZAP, go to record #178, change 2nd "23c2" to "6004" 2) Go to record 274 (maybe 275), find "660e2f3900000014". Change the "14" to "10". 3) ENJOY!!! (you will also want to change the "raw:..." text so the window is less bothersome) Here's why it works: WACK automatically calls INPUT and OUTPUT, but later overwrites them both with the filehandle returned from the opening of the "RAW:" window. The "6004" is a BRA.S *+4 which skips over the writing to _STDOUT. Why WACK does this is a mystery; I guess it was written in a funky language like "C". The "10" change causes WACK to send _STDIN to CLOSE instead of _STDOUT, so the "RAW:" window disappears. One more thing: If anyone knows a better way of hacking files than FILEZAP, please let me know. CONCLUDING NOTE: THERE ARE THOUSANDS OF OTHER NEAT INSIGHTS INTO KICKSTART TO BE MADE, PATCHES TO BE DONE. UNFORTUNATELY, COMMODORE DOESN'T PUBLISH SOURCE CODE (AND THUS FORFEITS MILLIONS IN POTENTIAL PROFITS) FOR SOME REASON. THIS IS ONE "WHY" NO ONE CAN ANSWER, NOT EVEN THE PEOPLE WHO HAD THIS BRILLIANT IDEA. ********* BUT ********* IF ALL THE TECHNICALLY ORIENTED PEOPLE OUT THERE WOULD DO THEIR SHARE AND HELP DOCUMENT SOME OF KICKSTART, ESPECIALLY THE BOOT UP CODE AND AMIGADOS, THE PROCESS WOULD BE VERY QUICK AND PAINLESS. AND WE WOULD ALL BENEFIT. -- Dan Babcock, user OPS239. If you ever have any questions at any time, just send me a message and I will try to answer.