Perihelion tutorial 3 - Revision history

AtariWikiSysop: 11 revisions imported

2018-06-03T23:00:59Z

11 revisions imported

Niceguyuk: Correction to code for clean exit - was jsr instead of clr

2016-09-03T18:33:01Z

Correction to code for clean exit - was jsr instead of clr

Niceguyuk: removed rogue extended chars

2015-05-07T09:23:43Z

removed rogue extended chars

Wongck at 12:24, 31 December 2012

2012-12-31T12:24:44Z

Wongck at 12:20, 31 December 2012

2012-12-31T12:20:34Z

Show changes

Wongck at 03:31, 19 February 2012

2012-02-19T03:31:47Z

Wongck at 14:33, 12 October 2011

2011-10-12T14:33:48Z

Silver Surfer: clean up

2009-05-03T15:37:40Z

clean up

Silver Surfer: clean up

2009-05-03T15:31:54Z

clean up

Muguk at 10:33, 1 February 2006

2006-02-01T10:33:27Z

Show changes

@@ Line 118: / Line 118: @@
               move.w 	d7,$ffff8240 	move back old color
               jsr 	restore 	jump to restore
-              jsr 	-(a7) 	clean exit
+              clr 	-(a7) 	clean exit
               trap 	#1 	call gemdos

@@ Line 3: / Line 3: @@
 Hello again! I've gotten some positive feedback on the first two tutorials, so I'm glad to begin writing this third one. As promised, I'll try to explain how computers think when it comes to numbers, the layout of the Atari hardware which will guide us to the workings of traps. I bet a very few understood anything about that. My mother has a bad back, so she can hardly move about, less so stand up, meaning I have to cook and fix her sandwiches. This blows, truly, and makes me wonder how it'll be like having kids one day, I feel kinda trapped. However, neither my martial training nor my tutorials will suffer :)
-So, now I'll try to explain what may have been a bit lofty in the previous two parts of the tutorial; how we express numbers. When you see three rocks, you count them, one, two, and three. We have speech in order to communicate our thoughts and emotions to other people, and we have writing in order to communicate speech in written form. We use numbers to communicate "œcounting". We have chosen the symbol '3' to express the amount you reach when counting one, two and three. However, this value, this "œthere are three things of something", can of course be written in different ways.
+So, now I'll try to explain what may have been a bit lofty in the previous two parts of the tutorial; how we express numbers. When you see three rocks, you count them, one, two, and three. We have speech in order to communicate our thoughts and emotions to other people, and we have writing in order to communicate speech in written form. We use numbers to communicate "counting". We have chosen the symbol '3' to express the amount you reach when counting one, two and three. However, this value, this "there are three things of something", can of course be written in different ways.
-Our number system is based on base 10, meaning that we have ten different symbols to express values, one of them being no values (also known as zero), which leave us with the ability to count to nine. Once the number nine has been reached, we need to start using numbers over again, we don't have a symbol for the value ten, so we have to combine the numbers we have in some way in order to express this. What we do is to say that different positions are "œworth" different. For example, in the expression 23, the number 2 is worth ten times as much as three. Do we see a connection here? We use base 10, each number is worth ten times as much as its predecessor. In the expression 123, 1 is worth ten times as much as 2, and one hundred times as much as 3. To calculate the value of the expression 123, we really use this formula
+Our number system is based on base 10, meaning that we have ten different symbols to express values, one of them being no values (also known as zero), which leave us with the ability to count to nine. Once the number nine has been reached, we need to start using numbers over again, we don't have a symbol for the value ten, so we have to combine the numbers we have in some way in order to express this. What we do is to say that different positions are "worth" different. For example, in the expression 23, the number 2 is worth ten times as much as three. Do we see a connection here? We use base 10, each number is worth ten times as much as its predecessor. In the expression 123, 1 is worth ten times as much as 2, and one hundred times as much as 3. To calculate the value of the expression 123, we really use this formula
               (1 * 10 ^ 2) + (2 * 10^1) + (3 * 10^0)
@@ Line 25: / Line 25: @@
-Think of it as tumblers, when we have base 10, the tumbler starts at zero, make nine "œticks", then the tumbler directly to the left makes one tick displaying one, the first tumbler reaches zero again, make nine ticks, the left tumbler makes one tick, reaching two, the first tumbler starts at zero again. When the second tumbler is at nine, and the first tumbler is also at nine, the next tick will take both tumblers back to zero, and a third tumbler, the one directly to the left of the second tumbler, will go from zero to one, and so forth. If we have base 2, there are only two numbers on the tumblers, 1 and 0.
+Think of it as tumblers, when we have base 10, the tumbler starts at zero, make nine "ticks", then the tumbler directly to the left makes one tick displaying one, the first tumbler reaches zero again, make nine ticks, the left tumbler makes one tick, reaching two, the first tumbler starts at zero again. When the second tumbler is at nine, and the first tumbler is also at nine, the next tick will take both tumblers back to zero, and a third tumbler, the one directly to the left of the second tumbler, will go from zero to one, and so forth. If we have base 2, there are only two numbers on the tumblers, 1 and 0.
 In order to facilitate things, we also have base 16, or hexadecimal numbers. The reason for this is that conversion between decimal (base 10) and binary (base 2) numbers are somewhat cumbersome, while conversation between hexadecimal, or hex for short (base 16) and binary is fairly easy. We use binary because the computer thinks in binary, we use hex because it's easier to convert binary into hex rather than decimal, and hex is much more manageable (less symbols required to express the same value), and of course we use decimal because we think in decimal.
@@ Line 33: / Line 33: @@
 In Devpac, values are expressed by putting '#' in front of a number, then further using '$' or '%' before numbers to indicate hexadecimal or binary numbers. Thus, '#' means decimal, '#$' means hexadecimal value and '#%' means binary value. So, as you see, it's customary to express memory addresses in hexadecimal. '$' (without '#') means value at memory address.
-Huh, that was that, now onto the architecture of the Atari! Every computer comes with a processor of different (or similar) brands, the Atari has a M68000 processor, so does the Amiga 500. The PC has an 8086 and so on. The processor comes with a different set of instructions and ways of working. This is the real challenge of assembly programming, you must know how the processor behaves that you are trying to program. In high level languages, such as Pascal and C, the programming language usually handles the processor dependent parts, and the code is much more portable between different platforms (computers). Assembly programming however, deals with processor level instruction, which makes it much more powerful and controllable. What the high level languages do, is to take the source code and "œtranslate" it into low level (assembly) language, which of course brings waste, since we can tailor make our programs in assembly, while high level languages have to be more generic (since they weren't tailor made for a specific processor).
+Huh, that was that, now onto the architecture of the Atari! Every computer comes with a processor of different (or similar) brands, the Atari has a M68000 processor, so does the Amiga 500. The PC has an 8086 and so on. The processor comes with a different set of instructions and ways of working. This is the real challenge of assembly programming, you must know how the processor behaves that you are trying to program. In high level languages, such as Pascal and C, the programming language usually handles the processor dependent parts, and the code is much more portable between different platforms (computers). Assembly programming however, deals with processor level instruction, which makes it much more powerful and controllable. What the high level languages do, is to take the source code and "translate" it into low level (assembly) language, which of course brings waste, since we can tailor make our programs in assembly, while high level languages have to be more generic (since they weren't tailor made for a specific processor).
 This is a good time to acquire a set of M68000 instructions, you will need to refer to these, also a good guide to the ST's hardware would be most useful, the ST Internals for example. With this tutorial should be a listing of the M68K instruction set, called INSTRSET.TXT. In order to explain the GEMDOS trap routine we used in the last tutorial, I'll have to explain registers. The M68K (K here stands for kilo, meaning 1000, thus M68K and M68000 are synonyms) have 16 registers plus one extra; eight data registers and eight address registers plus a program counter. The program counter is really an address register that points on the next instruction to be performed, simply put, it keeps track of the program execution so that the Atari knows where it's at.
@@ Line 56: / Line 56: @@
 It feels a bit confusing with traps and trap numbers, I'll try to sort it out. The BIOS, XBIOS and GEMDOS each have several special instructions, that aren't in the processor, and do special things. Since they all three have several functions, all three will have the function numbered 1. In the BIOS, function 1 is a function for returning the input device status, in the GEMDOS, function 1 gets a single character from the keyboard, and in XBIOS, function 1 will save memory space. This information must be gathered by referring to a list of all traps available. In the ST Internals, there is a list of all the traps available, and instructions on how to use them.
-What you do is to specify what trap function you want by putting information on the stack, then you call either BIOS, XBIOS or GEMDOS, and let them do something with the information. As an example, I give you this alternative way of changing the background colour. The "œ-(a7)" means put on stack, we'll cover that in the next tutorial.
+What you do is to specify what trap function you want by putting information on the stack, then you call either BIOS, XBIOS or GEMDOS, and let them do something with the information. As an example, I give you this alternative way of changing the background colour. The "-(a7)" means put on stack, we'll cover that in the next tutorial.
@@ Line 73: / Line 73: @@
 Now we are going to expand upon the program in tutorial two. It gets tedious to run the program, and then change the background back by running the program again. Good programs save all the data they change, in order to restore it once the program is complete. Also, it would be nice to be able to store the code for going in and out of super mode, since we will use this in every program.
-It's a good idea to have your own libraries of code, which you can cut and paste or include as you will in your code. Create a file called initlib.s (for initialization library) and in it put the code for the super mode. This file is for storing only, when you need the "œgo into super mode" instruction, you know where you have it. The file initlib.s should have the following content.
+It's a good idea to have your own libraries of code, which you can cut and paste or include as you will in your code. Create a file called initlib.s (for initialization library) and in it put the code for the super mode. This file is for storing only, when you need the "go into super mode" instruction, you know where you have it. The file initlib.s should have the following content.
               initialize
@@ Line 149: / Line 149: @@
 Soooo, what's different? Our routines for getting into and out of super mode have been neatly packed down the bottom of the code, the command jsr (Jump to SubRoutine) will take us where we want. Then, we put the value of the background colour in d7, saving it. Smack in the red colour. Here comes another fine trap, when executed, it will wait for a key to be pressed before continuing with execution. This trap will give the user a chance to see the lovely red background colour, and then hit a key in order to progress. Again, I looked after what I wanted in the ST Internals; something that would allow the program to pause and wait for a key to be pressed, lo and behold! I found it, and just copied the information. After this, the value from d7 is put into colour 0, effectively restoring the old background colour. Lastly, a jump to the restore subroutine and a clean system exit.
-Now we have begun to forcefully control the program flow, the code isn't executed "œtop down", but with commands such as jsr and rts (Return from SubRoutine) we can jump around. Usually, programs are built up of some initialization routine, and then a loop more or less, which only consists of calling other sub-routines. A game of asteroids would for example look something like this.
+Now we have begun to forcefully control the program flow, the code isn't executed "top down", but with commands such as jsr and rts (Return from SubRoutine) we can jump around. Usually, programs are built up of some initialization routine, and then a loop more or less, which only consists of calling other sub-routines. A game of asteroids would for example look something like this.
              Go into low resolution

@@ Line 3: / Line 3: @@
 Hello again! I've gotten some positive feedback on the first two tutorials, so I'm glad to begin writing this third one. As promised, I'll try to explain how computers think when it comes to numbers, the layout of the Atari hardware which will guide us to the workings of traps. I bet a very few understood anything about that. My mother has a bad back, so she can hardly move about, less so stand up, meaning I have to cook and fix her sandwiches. This blows, truly, and makes me wonder how it'll be like having kids one day, I feel kinda trapped. However, neither my martial training nor my tutorials will suffer :)
-So, now I'll try to explain what may have been a bit lofty in the previous two parts of the tutorial; how we express numbers. When you see three rocks, you count them, one, two, and three. We have speech in order to communicate our thoughts and emotions to other people, and we have writing in order to communicate speech in written form. We use numbers to communicate 'œcounting'. We have chosen the symbol '˜3' to express the amount you reach when counting one, two and three. However, this value, this 'œthere are three things of something', can of course be written in different ways.
+So, now I'll try to explain what may have been a bit lofty in the previous two parts of the tutorial; how we express numbers. When you see three rocks, you count them, one, two, and three. We have speech in order to communicate our thoughts and emotions to other people, and we have writing in order to communicate speech in written form. We use numbers to communicate "œcounting". We have chosen the symbol '3' to express the amount you reach when counting one, two and three. However, this value, this "œthere are three things of something", can of course be written in different ways.
-Our number system is based on base 10, meaning that we have ten different symbols to express values, one of them being no values (also known as zero), which leave us with the ability to count to nine. Once the number nine has been reached, we need to start using numbers over again, we don't have a symbol for the value ten, so we have to combine the numbers we have in some way in order to express this. What we do is to say that different positions are 'œworth' different. For example, in the expression 23, the number 2 is worth ten times as much as three. Do we see a connection here? We use base 10, each number is worth ten times as much as its predecessor. In the expression 123, 1 is worth ten times as much as 2, and one hundred times as much as 3. To calculate the value of the expression 123, we really use this formula
+Our number system is based on base 10, meaning that we have ten different symbols to express values, one of them being no values (also known as zero), which leave us with the ability to count to nine. Once the number nine has been reached, we need to start using numbers over again, we don't have a symbol for the value ten, so we have to combine the numbers we have in some way in order to express this. What we do is to say that different positions are "œworth" different. For example, in the expression 23, the number 2 is worth ten times as much as three. Do we see a connection here? We use base 10, each number is worth ten times as much as its predecessor. In the expression 123, 1 is worth ten times as much as 2, and one hundred times as much as 3. To calculate the value of the expression 123, we really use this formula
               (1 * 10 ^ 2) + (2 * 10^1) + (3 * 10^0)
@@ Line 11: / Line 11: @@
 the generic formula looks like this
-              value * base^position '¦
+              value * base^position "¦
 OK, you say hesitantly, perhaps I understand something of what you're trying to say; now what about computers? Computers use base 2, they are binary and can only count 1's and 0's. There is either current through a circuit, or there isn't. They only use two symbols to express values. As you can imagine, the result is very long expressions, like 101010101011101000101010. For presenting the value three, the computer uses the symbols 11. Using our generic formula above, we translate this to
@@ Line 25: / Line 25: @@
-Think of it as tumblers, when we have base 10, the tumbler starts at zero, make nine 'œticks', then the tumbler directly to the left makes one tick displaying one, the first tumbler reaches zero again, make nine ticks, the left tumbler makes one tick, reaching two, the first tumbler starts at zero again. When the second tumbler is at nine, and the first tumbler is also at nine, the next tick will take both tumblers back to zero, and a third tumbler, the one directly to the left of the second tumbler, will go from zero to one, and so forth. If we have base 2, there are only two numbers on the tumblers, 1 and 0.
+Think of it as tumblers, when we have base 10, the tumbler starts at zero, make nine "œticks", then the tumbler directly to the left makes one tick displaying one, the first tumbler reaches zero again, make nine ticks, the left tumbler makes one tick, reaching two, the first tumbler starts at zero again. When the second tumbler is at nine, and the first tumbler is also at nine, the next tick will take both tumblers back to zero, and a third tumbler, the one directly to the left of the second tumbler, will go from zero to one, and so forth. If we have base 2, there are only two numbers on the tumblers, 1 and 0.
 In order to facilitate things, we also have base 16, or hexadecimal numbers. The reason for this is that conversion between decimal (base 10) and binary (base 2) numbers are somewhat cumbersome, while conversation between hexadecimal, or hex for short (base 16) and binary is fairly easy. We use binary because the computer thinks in binary, we use hex because it's easier to convert binary into hex rather than decimal, and hex is much more manageable (less symbols required to express the same value), and of course we use decimal because we think in decimal.
-If you've understood what I said above, you'll wonder how on Earth we use hexadecimal values, since we would need six more symbols for expressing the values ten, eleven, twelve, thirteen, fourteen and fifteen. We simply use letters from our alphabet. A = ten, B = eleven, C = twelve, D = thirteen, E = fourteen and F = fifteen. So to express the value fifteen in hex, we simply use '˜F'. To express sixteen, we get 10 (1*16^1 + 0*16^0). Seventeen is 11 (1*16^1 + 1*16^0. AF would mean one hundred and seventy five (10*16^1 + 15*16^0) and finally F5A would be three thousand nine hundred and thirty (15*16^2 + 5*16^1 + 10*16^0). If you don't get all this, this topic will probably be covered by every beginners book and tutorial out there, go find an additional source of information.
+If you've understood what I said above, you'll wonder how on Earth we use hexadecimal values, since we would need six more symbols for expressing the values ten, eleven, twelve, thirteen, fourteen and fifteen. We simply use letters from our alphabet. A = ten, B = eleven, C = twelve, D = thirteen, E = fourteen and F = fifteen. So to express the value fifteen in hex, we simply use 'F'. To express sixteen, we get 10 (1*16^1 + 0*16^0). Seventeen is 11 (1*16^1 + 1*16^0. AF would mean one hundred and seventy five (10*16^1 + 15*16^0) and finally F5A would be three thousand nine hundred and thirty (15*16^2 + 5*16^1 + 10*16^0). If you don't get all this, this topic will probably be covered by every beginners book and tutorial out there, go find an additional source of information.
-In Devpac, values are expressed by putting '˜#' in front of a number, then further using '˜$' or '˜%' before numbers to indicate hexadecimal or binary numbers. Thus, '˜#' means decimal, '˜#$' means hexadecimal value and '˜#%' means binary value. So, as you see, it's customary to express memory addresses in hexadecimal. '˜$' (without '˜#') means value at memory address.
+In Devpac, values are expressed by putting '#' in front of a number, then further using '$' or '%' before numbers to indicate hexadecimal or binary numbers. Thus, '#' means decimal, '#$' means hexadecimal value and '#%' means binary value. So, as you see, it's customary to express memory addresses in hexadecimal. '$' (without '#') means value at memory address.
-Huh, that was that, now onto the architecture of the Atari! Every computer comes with a processor of different (or similar) brands, the Atari has a M68000 processor, so does the Amiga 500. The PC has an 8086 and so on. The processor comes with a different set of instructions and ways of working. This is the real challenge of assembly programming, you must know how the processor behaves that you are trying to program. In high level languages, such as Pascal and C, the programming language usually handles the processor dependent parts, and the code is much more portable between different platforms (computers). Assembly programming however, deals with processor level instruction, which makes it much more powerful and controllable. What the high level languages do, is to take the source code and 'œtranslate' it into low level (assembly) language, which of course brings waste, since we can tailor make our programs in assembly, while high level languages have to be more generic (since they weren't tailor made for a specific processor).
+Huh, that was that, now onto the architecture of the Atari! Every computer comes with a processor of different (or similar) brands, the Atari has a M68000 processor, so does the Amiga 500. The PC has an 8086 and so on. The processor comes with a different set of instructions and ways of working. This is the real challenge of assembly programming, you must know how the processor behaves that you are trying to program. In high level languages, such as Pascal and C, the programming language usually handles the processor dependent parts, and the code is much more portable between different platforms (computers). Assembly programming however, deals with processor level instruction, which makes it much more powerful and controllable. What the high level languages do, is to take the source code and "œtranslate" it into low level (assembly) language, which of course brings waste, since we can tailor make our programs in assembly, while high level languages have to be more generic (since they weren't tailor made for a specific processor).
 This is a good time to acquire a set of M68000 instructions, you will need to refer to these, also a good guide to the ST's hardware would be most useful, the ST Internals for example. With this tutorial should be a listing of the M68K instruction set, called INSTRSET.TXT. In order to explain the GEMDOS trap routine we used in the last tutorial, I'll have to explain registers. The M68K (K here stands for kilo, meaning 1000, thus M68K and M68000 are synonyms) have 16 registers plus one extra; eight data registers and eight address registers plus a program counter. The program counter is really an address register that points on the next instruction to be performed, simply put, it keeps track of the program execution so that the Atari knows where it's at.
@@ Line 56: / Line 56: @@
 It feels a bit confusing with traps and trap numbers, I'll try to sort it out. The BIOS, XBIOS and GEMDOS each have several special instructions, that aren't in the processor, and do special things. Since they all three have several functions, all three will have the function numbered 1. In the BIOS, function 1 is a function for returning the input device status, in the GEMDOS, function 1 gets a single character from the keyboard, and in XBIOS, function 1 will save memory space. This information must be gathered by referring to a list of all traps available. In the ST Internals, there is a list of all the traps available, and instructions on how to use them.
-What you do is to specify what trap function you want by putting information on the stack, then you call either BIOS, XBIOS or GEMDOS, and let them do something with the information. As an example, I give you this alternative way of changing the background colour. The 'œ-(a7)' means put on stack, we'll cover that in the next tutorial.
+What you do is to specify what trap function you want by putting information on the stack, then you call either BIOS, XBIOS or GEMDOS, and let them do something with the information. As an example, I give you this alternative way of changing the background colour. The "œ-(a7)" means put on stack, we'll cover that in the next tutorial.
@@ Line 73: / Line 73: @@
 Now we are going to expand upon the program in tutorial two. It gets tedious to run the program, and then change the background back by running the program again. Good programs save all the data they change, in order to restore it once the program is complete. Also, it would be nice to be able to store the code for going in and out of super mode, since we will use this in every program.
-It's a good idea to have your own libraries of code, which you can cut and paste or include as you will in your code. Create a file called initlib.s (for initialization library) and in it put the code for the super mode. This file is for storing only, when you need the 'œgo into super mode' instruction, you know where you have it. The file initlib.s should have the following content.
+It's a good idea to have your own libraries of code, which you can cut and paste or include as you will in your code. Create a file called initlib.s (for initialization library) and in it put the code for the super mode. This file is for storing only, when you need the "œgo into super mode" instruction, you know where you have it. The file initlib.s should have the following content.
               initialize
@@ Line 107: / Line 107: @@
               include \libraries\initlib.s
-However, there is a drawback to the method described above; every time you assemble your code, you will have to load all your include files into memory from disk, which takes time. Only the source code you are currently working on is in memory, and any includes will have to be loaded every time. So, in order to speed things up, I usually include my libraries (or rather, the subroutines I need) into the source code I'm working at. This can be done with the file '“ insert file command, which will append a file at the cursors position. Or you can just copy and paste from your library into your source code as you see fit
+However, there is a drawback to the method described above; every time you assemble your code, you will have to load all your include files into memory from disk, which takes time. Only the source code you are currently working on is in memory, and any includes will have to be loaded every time. So, in order to speed things up, I usually include my libraries (or rather, the subroutines I need) into the source code I'm working at. This can be done with the file insert file command, which will append a file at the cursors position. Or you can just copy and paste from your library into your source code as you see fit
               jsr 	initialize 	jump to initialize
@@ Line 149: / Line 149: @@
 Soooo, what's different? Our routines for getting into and out of super mode have been neatly packed down the bottom of the code, the command jsr (Jump to SubRoutine) will take us where we want. Then, we put the value of the background colour in d7, saving it. Smack in the red colour. Here comes another fine trap, when executed, it will wait for a key to be pressed before continuing with execution. This trap will give the user a chance to see the lovely red background colour, and then hit a key in order to progress. Again, I looked after what I wanted in the ST Internals; something that would allow the program to pause and wait for a key to be pressed, lo and behold! I found it, and just copied the information. After this, the value from d7 is put into colour 0, effectively restoring the old background colour. Lastly, a jump to the restore subroutine and a clean system exit.
-Now we have begun to forcefully control the program flow, the code isn't executed 'œtop down', but with commands such as jsr and rts (Return from SubRoutine) we can jump around. Usually, programs are built up of some initialization routine, and then a loop more or less, which only consists of calling other sub-routines. A game of asteroids would for example look something like this.
+Now we have begun to forcefully control the program flow, the code isn't executed "œtop down", but with commands such as jsr and rts (Return from SubRoutine) we can jump around. Usually, programs are built up of some initialization routine, and then a loop more or less, which only consists of calling other sub-routines. A game of asteroids would for example look something like this.
              Go into low resolution

← Older revision		Revision as of 03:31, 19 February 2012
Line 172:		Line 172:

	Last edited 2002-06-14		Last edited 2002-06-14
		+	<br/><br/>
		+	Go back to [[Perihelion tutorial 2]]<br/>
		+	Proceed to [[Perihelion tutorial 4]]

	[[Category: Perihelions Atari ST M68000 tutorial]]		[[Category: Perihelions Atari ST M68000 tutorial]]

@@ Line 172: / Line 172: @@
 Last edited 2002-06-14
-[[Category:Category Perihelions Atari ST M68000 tutorial]]
-[[Category:Programming]]
+[[Category: Perihelions Atari ST M68000 tutorial]]

← Older revision	Revision as of 23:00, 3 June 2018
(No difference)

← Older revision		Revision as of 15:37, 3 May 2009
Line 174:		Line 174:
	[[Category:Category Perihelions Atari ST M68000 tutorial]]		[[Category:Category Perihelions Atari ST M68000 tutorial]]
	[[Category:Programming]]		[[Category:Programming]]
		+	[[Category:Assembly Language]]

← Older revision		Revision as of 15:31, 3 May 2009
Line 1:		Line 1:
−	~~[[Category:Category Perihelions Atari ST M68000 tutorial]]~~
−
	'''The Atari ST M68000 tutorial part 3''' â€“ of various things mystic and important, mainly concerning the art of understanding digits and performing traps		'''The Atari ST M68000 tutorial part 3''' â€“ of various things mystic and important, mainly concerning the art of understanding digits and performing traps

Line 174:		Line 172:

	Last edited 2002-06-14		Last edited 2002-06-14
		+	[[Category:Category Perihelions Atari ST M68000 tutorial]]
		+	[[Category:Programming]]