@2 AMOS RIPPING by Steve Bye -------------------------- @4 Why? you may ask, would anyone want to rip anything out of an Amos program? Er, don't ask me mate! I am just looking for an excuse to write another article. Well, at least this subject hasn't been covered anywhere else before, as far as I know. So, Getting down to the nitty gritty then, how do we rip a spacked memory bank from an Amos compiled executable program? The answer is fairly simple, with hindsight that is. First off, present the user with a file requestor and Bload the selected file into a memory bank, let's say 10 for now. We can now get down to some serious byte searching. @3 'A cut down version of my search pac.pic routine @1 _SEARCHPICS: SEARCH$="pac.pic" ADR=HuntSTART(10)+COUNT To Start(10)+Length(10),SEARCH$) If ADR=0 Then Locate 24,24 : Print "ALL DONE!" : Wait 50 : Return Print "pac.pic HEADER FOUND AT ";ADR COUNT=ADR+100 Return @4 At first I tried a For-Next loop to search through the file, it took about 7 minutes to search 250k, ridiculous or what? The Hunt command is VERY fast, almost instant, even on a 250K+ file. The string used to I.D a Spacked picture bank is "pac.pic" this is what we tell HUNT to look for. You have to be exact with the text pac.pic for example won't work. ADR will either return 0, meaning not found or the address in memory of pac.pic after completing it's task. So if ADR=0 we simply print a message and end the routine. If on the other hand ADR returns <>0 then we are onto something. Here I have just printed the address. We add 100 to the COUNT variable to allow the next search (if any) to skip past this Pic header otherwise the routine would keep coming up with the same address. @4 OK, we have the possible address of a spacked pic. But first we have to do some DIY repair on the header of the file because when the compiler does it's job it wrecks part of the header (on purpose) The most sickening thing is the compiler cuts out the addresses holding the length of the spacked pic, we can get around that, but first the header: @1 ' Restore the header ' 'poke AmBk at new start of bank Poke ADR-12,65 Poke ADR-11,109 Poke ADR-10,66 Poke ADR-9,107 ' 'restore some data discarded by compiler Poke ADR-8,0 Poke ADR-7,$A Poke ADR-6,0 Poke ADR-5,0 Poke ADR-4,$80 Poke ADR-3,0 Poke ADR-2,$1C Poke ADR-1,$32 @4 That's the header restored as you would find the file as if it was saved out as a normal single ABK file. Now we have to extract the bugger from the main executable file and save it somewhere: @3 'Guess length for now Bsave "ram:pic.abk",ADR-12 To ADR+72000 Return @4 I have chosen the RAM: disk for simplicity but if memory is short anywhere will do. The 72000 is just a guess, not many pictures are going to be more than 70k when spacked, maybe 60k would be more reasonable? Anyway (shrugs shoulders) I can find no way of telling the length, so if anyone can let me know! It's show time folks! Time to show the ripped picture. Presuming our ripper menu is using screen 0 and we want the menu and currently displayed data unaltered we can use screen 1 to display the pic. So we load the file we previously saved off as if it were a normal ABK picture bank (Which it is now we have poked AMBK etc. to it) Amos won't load it as a bank without this lot poked in, by the way! @3 _VIEWPIC Screen Hide 0 Load "ram:pic.abk",11 Unpack 11 To 1 Screen Show 1 Wait 25 While Mouse Key=0 : Wend Screen Close 1 Screen Show 0 @4 And the picture should be there in all it's glory. You then offer the user a chance to save screen 1 as an IFF file and when saved it will be the original size of the source picture ie. NOT 72K. I have tested this is tons of Amos executables and it does work. It trips up on some HIRES and INTERLACED screens and occasionally the pic comes out corrupted, but 9 out of 10 times it works fine. It also works on source files but that's a bit pointless really unless you want to extract a load of pics from your source code quickly and easily. By the way Amos Pro ABK headers are slightly different as AP adds four extra bytes to the header as a next bank address pointer but it does not interfere with anything. @4 Don't forget that the executable file must NOT be crunched or use the SQUASH option from the compiler as the ripper won't find anything. [5 I suppose if you lose your source code (Hi Malc!!) at least you may be able to rip out some of your graphics. Especially, if like me, you prefer to have most or all of your GFX in one file and not in external ABK's that people can nick. I can now reveal why I wrote this article. I need your help. Ok I have NEARLY sussed out the ripping of spacked pics, but what about music banks, Icons, sprites etc. ? Searching and finding the headers is as easy as the spacked pic headers the problem is knowing what length the file is etc. I can't suss any bank other than spacked pics. If anyone can help maybe we can write a nice util together, any offers/ideas or any advice? @1 Lamer Steve. P.S Amos Pro users could use POKE$ instead of the series of POKES.