alan@ecrcvax.UUCP (Alan P. Sexton) (10/06/87)
I've just bought an atari 1040st and need some info. If anyone can tell me this stuff it would save me a lot of detective work. This is all to do with exactly what happens to a '.prg' file when you double click it: I know that there is a header block that has specific info about the sizes of the text, data and bss areas etc., but I also know that the atari does not do any address translation and yet, that according to some refs I have, programs do not know where they will be loaded in memory. This implies one of the following a. All programs must be position independant (This could be done but I don't believe it is so for the atari). b. All programs must have their addresses fixed up when they are loaded into memory. Case b would certainly be the way I would do it if it were up to me (given that I wasn't allowed put an mmu in there) but that opens another question: are address patches done on the program by pure analysis of the program? (difficult, costly and inefficient) or is there symbol table info in the .prg file that allows the system to patch addresses directly? (seems much more likely). Finally, Given that a symbol table approach is being used then either 1. TOS understands the symbol table and does the patching itself (in which case it must be the same format for all .prg files) or 2. the first part of the program must be a position independant address patcher which will understand the 'nonstandard' symbol table format, patch the rest of the program and then jump to the start of the patched program. So, can anyone tell me whether 1 or 2 above is correct and if so then what is the format of the symbol table and position dependant instructions in the .prg file if case 1 is true. Also is there anything else in the .prg file which is not header, code or putative symbol table? -- Alan Sexton ECRC, Arabellastr 17, alan@ecrcvax.UUCP 8000 Muenchen 81, West Germany mcvax!unido!ecrcvax!alan tel. (089) 92699164
tom@cogpsi.UUCP (Tom Vijlbrief) (10/15/87)
In article <439@ecrcvax.UUCP> alan@ecrcvax.UUCP (Alan P. Sexton) writes: >I know that there is a header block that has specific info about the >sizes of the text, data and bss areas etc., but I also know that the atari >does not do any address translation and yet, that according to some refs >I have, programs do not know where they will be loaded in memory. >This implies one of the following >a. All programs must be position independant (This could be done > but I don't believe it is so for the atari). >b. All programs must have their addresses fixed up when they are loaded > into memory. > >Case b would certainly be the way I would do it if it were up to me (given (Rest of text deleted) Case b is indeed the way it is implemented. The binary file consists of three parts. 1. The header 2. The Code and data. 3. The relocation information. The code and data is position dependent and can be loaded at address 0 for execution. The program is however always loaded at another position in memory and should be patched (because of the lack of a MMU). TOS patches the code and data by adding the actual position of the program in memory to all absolute memory references which the binary image contains. Because the symbol table has been deleted by the linker, TOS has to use a special relocation table. This table specifies the offset between succesive patch locations in the binary image. This format is compact and allows for fast patching. After the binary image has been patched by TOS, it starts execution by jumping to the start of the binary image. Tom Vijlbrief TNO Institute for Perception P.O. Box 23 Phone: +31 34 63 14 44 3769 DE Soesterberg E-mail: tnosoes!cogpsi!tom@mcvax.cwi.nl The Netherlands {uunet|...}!mcvax!tnosoes!cogpsi!tom
c9c-eh@dorothy.Berkeley.EDU (Warner Young (WHY)) (10/17/87)
In article <318@cogpsi.UUCP> tom@cogpsi.UUCP (Tom Vijlbrief) writes: >In article <439@ecrcvax.UUCP> alan@ecrcvax.UUCP (Alan P. Sexton) writes: >>I know that there is a header block that has specific info about the >>sizes of the text, data and bss areas etc., but I also know that the atari >(Rest of text deleted) > >Case b is indeed the way it is implemented. The binary file consists >of three parts. >1. The header >2. The Code and data. >3. The relocation information. > > ... >TOS patches the code and data by adding the actual position >of the program in memory to all absolute memory references which the >binary image contains. >Because the symbol table has been deleted by the linker, TOS has to use a >special relocation table. This table specifies the offset between >succesive patch locations in the binary image. This format is >compact and allows for fast patching. Can anyone elucidate on the exact formats of the Header section and the relocation information? I'd like to experiment with some of the stuff I have, but I don't want to do it blindly. Also, while I'm at it, can someone tell me some common ways to go about de-protecting copy-protected programs? I have some games I would like to de-protect, because it's a pain to wait for the next release of ProCopy to back them up. Thanks. \ / Disclaimer: I'm not associated \ /\ /arner with the latest revision \/ \__/ of SANITY. |oung \___| Last known address: dorothy.Berkeley.EDU!c9c-eh (I think)