How did Apple ][ basic programs protect against listing?
up vote
37
down vote
favorite
I seem to recall from my high-school days that certain Apple ][ programs protected themselves from being listed and therefore modified.
If you tried to do it, the machine would simply reboot.
How did they achieve this, and can it be bypassed to get at the code?
apple-ii copy-protection
add a comment |
up vote
37
down vote
favorite
I seem to recall from my high-school days that certain Apple ][ programs protected themselves from being listed and therefore modified.
If you tried to do it, the machine would simply reboot.
How did they achieve this, and can it be bypassed to get at the code?
apple-ii copy-protection
add a comment |
up vote
37
down vote
favorite
up vote
37
down vote
favorite
I seem to recall from my high-school days that certain Apple ][ programs protected themselves from being listed and therefore modified.
If you tried to do it, the machine would simply reboot.
How did they achieve this, and can it be bypassed to get at the code?
apple-ii copy-protection
I seem to recall from my high-school days that certain Apple ][ programs protected themselves from being listed and therefore modified.
If you tried to do it, the machine would simply reboot.
How did they achieve this, and can it be bypassed to get at the code?
apple-ii copy-protection
apple-ii copy-protection
asked Nov 23 at 0:37
paxdiablo
1,6191235
1,6191235
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
up vote
37
down vote
accepted
One way was to place an in-line reboot command into the actual listing.
Apple ][ DOS had a feature that would monitor the output stream and, if it found a special character output at the start of a line, the rest of the line would be treated as a command. This character was Ctrl+D, meaning you could get a disk listing from your program with something like:
PRINT CHR$(4);"CATALOG"
You could also use the slot activation command IN#6
which would generally reboot the machine, assuming your disk controller was in slot 6 (it usually was).
But, of course, that would only work with a print
command if you were running your program. For protecting against someone listing it, an extra layer of trickery was required.
To do this, you would create a line at the start of your program:
10 REM XXIN#6
and then use POKE
commands to change the XX
into a Ctrl+M (to start a new line) and Ctrl+D (to flag a command), before saving.
After that, an attempt to LIST
the program would result in the machine rebooting. So this is probably something you wanted to do once development was done, just before shipping :-)
In order to bypass it, it's a simple matter of working out the errant line and just deleting it. In the case above, that would be acheived by just entering the stand-alone:
10
on the command line and, voila, the program is unprotected. To stop this, some developers started numbering the programs with less "normal" line numbers such as 2718
. However, since the line numbers are stored in memory as well, you could PEEK
at the program to work out what the first line number was, and then delete that one.
3
My recollection is that you could simply type the control-D as part of the input line. No need for poking about. One could list a program without processing such things by typing:PR#0
with a colon before it to ensure it's processed as a BASIC command rather than a DOS one.
– supercat
Nov 23 at 2:56
1
It's been a while for me, but I seem to remember that just a chr$(4) in the middle of a line wasn't enough; it had to be the first character on the line, i.e. there had to be a chr$(13) preceding it or it would be ignored.
– Mr Lister
Nov 23 at 11:05
Yes, it needed to be CR + Ctrl-D or DOS wouldn't see it. Issuing the "FP" command was probably better than rebooting, because it just quietly erased the program, leaving you to wonder what just happened. On a different note, some programs loaded up with Ctrl-G just to be annoying. Maybe they hoped the beeping and delays would be off-putting.
– fadden
Nov 23 at 16:07
2
@fadden Ha, one of the first machine language utilities I wrote was one that intercepted the output of control chars, checked if they came from LIST output, and displayed inverse letters if so. Those were the days.
– Mr Lister
Nov 23 at 16:24
@MrLister: Ah, probably the control-D could be typed, but a control-M needed to be poked in front of it.
– supercat
Nov 25 at 4:07
|
show 2 more comments
up vote
19
down vote
If I recall correctly, there were lots of variations to implement this scheme. Besides embedding characters in the listing that would reboot, or clear the screen every so often, a particular one I remember worked roughly like this:
The listing only consisted of a single CALL
. The internal structure of the BASIC program was carefully changed so the listing was stopped there, but there was a lot of stuff after this single command. This call would be to an embedded machine program somewhere in the BASIC listing, which would re-arrange the structure to make the whole program visible, and also register itself with some hooks to make it invisible again. You could defeat this protection by disassembling the machine code and running part of it. Or even by pressing RESET or something at a proper time, I forgot the details.
Not all BASIC programs that consisted of a single CALL
were like this. There were also pure machine programs which disguised itself as BASIC programs in this way for some reason I never understood.
1
Possibly to use the basic loader?
– Joshua
Nov 23 at 19:17
add a comment |
up vote
13
down vote
There were multiple ways of protecting the program, including:
order of line numbers could be altered to produce:
- circular listings;
- missing lines;
- out-of-order lines;
- out-of-bounds addressing;
the "resume" flag could be set such that any command could cause the program to run again;
- the start-address for the program could be altered so that another (or none) listing would show;
- line-linking could be altered to run "unreachable" lines;
- the DOS interpreter accepts special characters so that slot code can be run ("PR#6" being the most common, but "DELETE HELLO" works equally well).
This sounds like what you were seeing. - the code could be self-modifying as it ran.
There was also a modification to the KBDIN routine to point to the reset routine, so that if you achieved a prompt and tried to type something, the machine would reboot.
For a more detailed description, see section 7.20 in "A Brief Description of Some Popular Copy-Protection Techniques on the Apple ][ Platform" (http://pferrie.host22.com/papers/apple2_prot.pdf).
1
That's an impressive PDF by the way. I've only just finished reading it and it brought back some fond memories of some of the games :-)
– paxdiablo
Nov 25 at 0:22
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
37
down vote
accepted
One way was to place an in-line reboot command into the actual listing.
Apple ][ DOS had a feature that would monitor the output stream and, if it found a special character output at the start of a line, the rest of the line would be treated as a command. This character was Ctrl+D, meaning you could get a disk listing from your program with something like:
PRINT CHR$(4);"CATALOG"
You could also use the slot activation command IN#6
which would generally reboot the machine, assuming your disk controller was in slot 6 (it usually was).
But, of course, that would only work with a print
command if you were running your program. For protecting against someone listing it, an extra layer of trickery was required.
To do this, you would create a line at the start of your program:
10 REM XXIN#6
and then use POKE
commands to change the XX
into a Ctrl+M (to start a new line) and Ctrl+D (to flag a command), before saving.
After that, an attempt to LIST
the program would result in the machine rebooting. So this is probably something you wanted to do once development was done, just before shipping :-)
In order to bypass it, it's a simple matter of working out the errant line and just deleting it. In the case above, that would be acheived by just entering the stand-alone:
10
on the command line and, voila, the program is unprotected. To stop this, some developers started numbering the programs with less "normal" line numbers such as 2718
. However, since the line numbers are stored in memory as well, you could PEEK
at the program to work out what the first line number was, and then delete that one.
3
My recollection is that you could simply type the control-D as part of the input line. No need for poking about. One could list a program without processing such things by typing:PR#0
with a colon before it to ensure it's processed as a BASIC command rather than a DOS one.
– supercat
Nov 23 at 2:56
1
It's been a while for me, but I seem to remember that just a chr$(4) in the middle of a line wasn't enough; it had to be the first character on the line, i.e. there had to be a chr$(13) preceding it or it would be ignored.
– Mr Lister
Nov 23 at 11:05
Yes, it needed to be CR + Ctrl-D or DOS wouldn't see it. Issuing the "FP" command was probably better than rebooting, because it just quietly erased the program, leaving you to wonder what just happened. On a different note, some programs loaded up with Ctrl-G just to be annoying. Maybe they hoped the beeping and delays would be off-putting.
– fadden
Nov 23 at 16:07
2
@fadden Ha, one of the first machine language utilities I wrote was one that intercepted the output of control chars, checked if they came from LIST output, and displayed inverse letters if so. Those were the days.
– Mr Lister
Nov 23 at 16:24
@MrLister: Ah, probably the control-D could be typed, but a control-M needed to be poked in front of it.
– supercat
Nov 25 at 4:07
|
show 2 more comments
up vote
37
down vote
accepted
One way was to place an in-line reboot command into the actual listing.
Apple ][ DOS had a feature that would monitor the output stream and, if it found a special character output at the start of a line, the rest of the line would be treated as a command. This character was Ctrl+D, meaning you could get a disk listing from your program with something like:
PRINT CHR$(4);"CATALOG"
You could also use the slot activation command IN#6
which would generally reboot the machine, assuming your disk controller was in slot 6 (it usually was).
But, of course, that would only work with a print
command if you were running your program. For protecting against someone listing it, an extra layer of trickery was required.
To do this, you would create a line at the start of your program:
10 REM XXIN#6
and then use POKE
commands to change the XX
into a Ctrl+M (to start a new line) and Ctrl+D (to flag a command), before saving.
After that, an attempt to LIST
the program would result in the machine rebooting. So this is probably something you wanted to do once development was done, just before shipping :-)
In order to bypass it, it's a simple matter of working out the errant line and just deleting it. In the case above, that would be acheived by just entering the stand-alone:
10
on the command line and, voila, the program is unprotected. To stop this, some developers started numbering the programs with less "normal" line numbers such as 2718
. However, since the line numbers are stored in memory as well, you could PEEK
at the program to work out what the first line number was, and then delete that one.
3
My recollection is that you could simply type the control-D as part of the input line. No need for poking about. One could list a program without processing such things by typing:PR#0
with a colon before it to ensure it's processed as a BASIC command rather than a DOS one.
– supercat
Nov 23 at 2:56
1
It's been a while for me, but I seem to remember that just a chr$(4) in the middle of a line wasn't enough; it had to be the first character on the line, i.e. there had to be a chr$(13) preceding it or it would be ignored.
– Mr Lister
Nov 23 at 11:05
Yes, it needed to be CR + Ctrl-D or DOS wouldn't see it. Issuing the "FP" command was probably better than rebooting, because it just quietly erased the program, leaving you to wonder what just happened. On a different note, some programs loaded up with Ctrl-G just to be annoying. Maybe they hoped the beeping and delays would be off-putting.
– fadden
Nov 23 at 16:07
2
@fadden Ha, one of the first machine language utilities I wrote was one that intercepted the output of control chars, checked if they came from LIST output, and displayed inverse letters if so. Those were the days.
– Mr Lister
Nov 23 at 16:24
@MrLister: Ah, probably the control-D could be typed, but a control-M needed to be poked in front of it.
– supercat
Nov 25 at 4:07
|
show 2 more comments
up vote
37
down vote
accepted
up vote
37
down vote
accepted
One way was to place an in-line reboot command into the actual listing.
Apple ][ DOS had a feature that would monitor the output stream and, if it found a special character output at the start of a line, the rest of the line would be treated as a command. This character was Ctrl+D, meaning you could get a disk listing from your program with something like:
PRINT CHR$(4);"CATALOG"
You could also use the slot activation command IN#6
which would generally reboot the machine, assuming your disk controller was in slot 6 (it usually was).
But, of course, that would only work with a print
command if you were running your program. For protecting against someone listing it, an extra layer of trickery was required.
To do this, you would create a line at the start of your program:
10 REM XXIN#6
and then use POKE
commands to change the XX
into a Ctrl+M (to start a new line) and Ctrl+D (to flag a command), before saving.
After that, an attempt to LIST
the program would result in the machine rebooting. So this is probably something you wanted to do once development was done, just before shipping :-)
In order to bypass it, it's a simple matter of working out the errant line and just deleting it. In the case above, that would be acheived by just entering the stand-alone:
10
on the command line and, voila, the program is unprotected. To stop this, some developers started numbering the programs with less "normal" line numbers such as 2718
. However, since the line numbers are stored in memory as well, you could PEEK
at the program to work out what the first line number was, and then delete that one.
One way was to place an in-line reboot command into the actual listing.
Apple ][ DOS had a feature that would monitor the output stream and, if it found a special character output at the start of a line, the rest of the line would be treated as a command. This character was Ctrl+D, meaning you could get a disk listing from your program with something like:
PRINT CHR$(4);"CATALOG"
You could also use the slot activation command IN#6
which would generally reboot the machine, assuming your disk controller was in slot 6 (it usually was).
But, of course, that would only work with a print
command if you were running your program. For protecting against someone listing it, an extra layer of trickery was required.
To do this, you would create a line at the start of your program:
10 REM XXIN#6
and then use POKE
commands to change the XX
into a Ctrl+M (to start a new line) and Ctrl+D (to flag a command), before saving.
After that, an attempt to LIST
the program would result in the machine rebooting. So this is probably something you wanted to do once development was done, just before shipping :-)
In order to bypass it, it's a simple matter of working out the errant line and just deleting it. In the case above, that would be acheived by just entering the stand-alone:
10
on the command line and, voila, the program is unprotected. To stop this, some developers started numbering the programs with less "normal" line numbers such as 2718
. However, since the line numbers are stored in memory as well, you could PEEK
at the program to work out what the first line number was, and then delete that one.
edited Nov 26 at 0:40
answered Nov 23 at 0:49
paxdiablo
1,6191235
1,6191235
3
My recollection is that you could simply type the control-D as part of the input line. No need for poking about. One could list a program without processing such things by typing:PR#0
with a colon before it to ensure it's processed as a BASIC command rather than a DOS one.
– supercat
Nov 23 at 2:56
1
It's been a while for me, but I seem to remember that just a chr$(4) in the middle of a line wasn't enough; it had to be the first character on the line, i.e. there had to be a chr$(13) preceding it or it would be ignored.
– Mr Lister
Nov 23 at 11:05
Yes, it needed to be CR + Ctrl-D or DOS wouldn't see it. Issuing the "FP" command was probably better than rebooting, because it just quietly erased the program, leaving you to wonder what just happened. On a different note, some programs loaded up with Ctrl-G just to be annoying. Maybe they hoped the beeping and delays would be off-putting.
– fadden
Nov 23 at 16:07
2
@fadden Ha, one of the first machine language utilities I wrote was one that intercepted the output of control chars, checked if they came from LIST output, and displayed inverse letters if so. Those were the days.
– Mr Lister
Nov 23 at 16:24
@MrLister: Ah, probably the control-D could be typed, but a control-M needed to be poked in front of it.
– supercat
Nov 25 at 4:07
|
show 2 more comments
3
My recollection is that you could simply type the control-D as part of the input line. No need for poking about. One could list a program without processing such things by typing:PR#0
with a colon before it to ensure it's processed as a BASIC command rather than a DOS one.
– supercat
Nov 23 at 2:56
1
It's been a while for me, but I seem to remember that just a chr$(4) in the middle of a line wasn't enough; it had to be the first character on the line, i.e. there had to be a chr$(13) preceding it or it would be ignored.
– Mr Lister
Nov 23 at 11:05
Yes, it needed to be CR + Ctrl-D or DOS wouldn't see it. Issuing the "FP" command was probably better than rebooting, because it just quietly erased the program, leaving you to wonder what just happened. On a different note, some programs loaded up with Ctrl-G just to be annoying. Maybe they hoped the beeping and delays would be off-putting.
– fadden
Nov 23 at 16:07
2
@fadden Ha, one of the first machine language utilities I wrote was one that intercepted the output of control chars, checked if they came from LIST output, and displayed inverse letters if so. Those were the days.
– Mr Lister
Nov 23 at 16:24
@MrLister: Ah, probably the control-D could be typed, but a control-M needed to be poked in front of it.
– supercat
Nov 25 at 4:07
3
3
My recollection is that you could simply type the control-D as part of the input line. No need for poking about. One could list a program without processing such things by typing
:PR#0
with a colon before it to ensure it's processed as a BASIC command rather than a DOS one.– supercat
Nov 23 at 2:56
My recollection is that you could simply type the control-D as part of the input line. No need for poking about. One could list a program without processing such things by typing
:PR#0
with a colon before it to ensure it's processed as a BASIC command rather than a DOS one.– supercat
Nov 23 at 2:56
1
1
It's been a while for me, but I seem to remember that just a chr$(4) in the middle of a line wasn't enough; it had to be the first character on the line, i.e. there had to be a chr$(13) preceding it or it would be ignored.
– Mr Lister
Nov 23 at 11:05
It's been a while for me, but I seem to remember that just a chr$(4) in the middle of a line wasn't enough; it had to be the first character on the line, i.e. there had to be a chr$(13) preceding it or it would be ignored.
– Mr Lister
Nov 23 at 11:05
Yes, it needed to be CR + Ctrl-D or DOS wouldn't see it. Issuing the "FP" command was probably better than rebooting, because it just quietly erased the program, leaving you to wonder what just happened. On a different note, some programs loaded up with Ctrl-G just to be annoying. Maybe they hoped the beeping and delays would be off-putting.
– fadden
Nov 23 at 16:07
Yes, it needed to be CR + Ctrl-D or DOS wouldn't see it. Issuing the "FP" command was probably better than rebooting, because it just quietly erased the program, leaving you to wonder what just happened. On a different note, some programs loaded up with Ctrl-G just to be annoying. Maybe they hoped the beeping and delays would be off-putting.
– fadden
Nov 23 at 16:07
2
2
@fadden Ha, one of the first machine language utilities I wrote was one that intercepted the output of control chars, checked if they came from LIST output, and displayed inverse letters if so. Those were the days.
– Mr Lister
Nov 23 at 16:24
@fadden Ha, one of the first machine language utilities I wrote was one that intercepted the output of control chars, checked if they came from LIST output, and displayed inverse letters if so. Those were the days.
– Mr Lister
Nov 23 at 16:24
@MrLister: Ah, probably the control-D could be typed, but a control-M needed to be poked in front of it.
– supercat
Nov 25 at 4:07
@MrLister: Ah, probably the control-D could be typed, but a control-M needed to be poked in front of it.
– supercat
Nov 25 at 4:07
|
show 2 more comments
up vote
19
down vote
If I recall correctly, there were lots of variations to implement this scheme. Besides embedding characters in the listing that would reboot, or clear the screen every so often, a particular one I remember worked roughly like this:
The listing only consisted of a single CALL
. The internal structure of the BASIC program was carefully changed so the listing was stopped there, but there was a lot of stuff after this single command. This call would be to an embedded machine program somewhere in the BASIC listing, which would re-arrange the structure to make the whole program visible, and also register itself with some hooks to make it invisible again. You could defeat this protection by disassembling the machine code and running part of it. Or even by pressing RESET or something at a proper time, I forgot the details.
Not all BASIC programs that consisted of a single CALL
were like this. There were also pure machine programs which disguised itself as BASIC programs in this way for some reason I never understood.
1
Possibly to use the basic loader?
– Joshua
Nov 23 at 19:17
add a comment |
up vote
19
down vote
If I recall correctly, there were lots of variations to implement this scheme. Besides embedding characters in the listing that would reboot, or clear the screen every so often, a particular one I remember worked roughly like this:
The listing only consisted of a single CALL
. The internal structure of the BASIC program was carefully changed so the listing was stopped there, but there was a lot of stuff after this single command. This call would be to an embedded machine program somewhere in the BASIC listing, which would re-arrange the structure to make the whole program visible, and also register itself with some hooks to make it invisible again. You could defeat this protection by disassembling the machine code and running part of it. Or even by pressing RESET or something at a proper time, I forgot the details.
Not all BASIC programs that consisted of a single CALL
were like this. There were also pure machine programs which disguised itself as BASIC programs in this way for some reason I never understood.
1
Possibly to use the basic loader?
– Joshua
Nov 23 at 19:17
add a comment |
up vote
19
down vote
up vote
19
down vote
If I recall correctly, there were lots of variations to implement this scheme. Besides embedding characters in the listing that would reboot, or clear the screen every so often, a particular one I remember worked roughly like this:
The listing only consisted of a single CALL
. The internal structure of the BASIC program was carefully changed so the listing was stopped there, but there was a lot of stuff after this single command. This call would be to an embedded machine program somewhere in the BASIC listing, which would re-arrange the structure to make the whole program visible, and also register itself with some hooks to make it invisible again. You could defeat this protection by disassembling the machine code and running part of it. Or even by pressing RESET or something at a proper time, I forgot the details.
Not all BASIC programs that consisted of a single CALL
were like this. There were also pure machine programs which disguised itself as BASIC programs in this way for some reason I never understood.
If I recall correctly, there were lots of variations to implement this scheme. Besides embedding characters in the listing that would reboot, or clear the screen every so often, a particular one I remember worked roughly like this:
The listing only consisted of a single CALL
. The internal structure of the BASIC program was carefully changed so the listing was stopped there, but there was a lot of stuff after this single command. This call would be to an embedded machine program somewhere in the BASIC listing, which would re-arrange the structure to make the whole program visible, and also register itself with some hooks to make it invisible again. You could defeat this protection by disassembling the machine code and running part of it. Or even by pressing RESET or something at a proper time, I forgot the details.
Not all BASIC programs that consisted of a single CALL
were like this. There were also pure machine programs which disguised itself as BASIC programs in this way for some reason I never understood.
edited Nov 25 at 9:33
JakeGould
1115
1115
answered Nov 23 at 6:55
dirkt
8,88812447
8,88812447
1
Possibly to use the basic loader?
– Joshua
Nov 23 at 19:17
add a comment |
1
Possibly to use the basic loader?
– Joshua
Nov 23 at 19:17
1
1
Possibly to use the basic loader?
– Joshua
Nov 23 at 19:17
Possibly to use the basic loader?
– Joshua
Nov 23 at 19:17
add a comment |
up vote
13
down vote
There were multiple ways of protecting the program, including:
order of line numbers could be altered to produce:
- circular listings;
- missing lines;
- out-of-order lines;
- out-of-bounds addressing;
the "resume" flag could be set such that any command could cause the program to run again;
- the start-address for the program could be altered so that another (or none) listing would show;
- line-linking could be altered to run "unreachable" lines;
- the DOS interpreter accepts special characters so that slot code can be run ("PR#6" being the most common, but "DELETE HELLO" works equally well).
This sounds like what you were seeing. - the code could be self-modifying as it ran.
There was also a modification to the KBDIN routine to point to the reset routine, so that if you achieved a prompt and tried to type something, the machine would reboot.
For a more detailed description, see section 7.20 in "A Brief Description of Some Popular Copy-Protection Techniques on the Apple ][ Platform" (http://pferrie.host22.com/papers/apple2_prot.pdf).
1
That's an impressive PDF by the way. I've only just finished reading it and it brought back some fond memories of some of the games :-)
– paxdiablo
Nov 25 at 0:22
add a comment |
up vote
13
down vote
There were multiple ways of protecting the program, including:
order of line numbers could be altered to produce:
- circular listings;
- missing lines;
- out-of-order lines;
- out-of-bounds addressing;
the "resume" flag could be set such that any command could cause the program to run again;
- the start-address for the program could be altered so that another (or none) listing would show;
- line-linking could be altered to run "unreachable" lines;
- the DOS interpreter accepts special characters so that slot code can be run ("PR#6" being the most common, but "DELETE HELLO" works equally well).
This sounds like what you were seeing. - the code could be self-modifying as it ran.
There was also a modification to the KBDIN routine to point to the reset routine, so that if you achieved a prompt and tried to type something, the machine would reboot.
For a more detailed description, see section 7.20 in "A Brief Description of Some Popular Copy-Protection Techniques on the Apple ][ Platform" (http://pferrie.host22.com/papers/apple2_prot.pdf).
1
That's an impressive PDF by the way. I've only just finished reading it and it brought back some fond memories of some of the games :-)
– paxdiablo
Nov 25 at 0:22
add a comment |
up vote
13
down vote
up vote
13
down vote
There were multiple ways of protecting the program, including:
order of line numbers could be altered to produce:
- circular listings;
- missing lines;
- out-of-order lines;
- out-of-bounds addressing;
the "resume" flag could be set such that any command could cause the program to run again;
- the start-address for the program could be altered so that another (or none) listing would show;
- line-linking could be altered to run "unreachable" lines;
- the DOS interpreter accepts special characters so that slot code can be run ("PR#6" being the most common, but "DELETE HELLO" works equally well).
This sounds like what you were seeing. - the code could be self-modifying as it ran.
There was also a modification to the KBDIN routine to point to the reset routine, so that if you achieved a prompt and tried to type something, the machine would reboot.
For a more detailed description, see section 7.20 in "A Brief Description of Some Popular Copy-Protection Techniques on the Apple ][ Platform" (http://pferrie.host22.com/papers/apple2_prot.pdf).
There were multiple ways of protecting the program, including:
order of line numbers could be altered to produce:
- circular listings;
- missing lines;
- out-of-order lines;
- out-of-bounds addressing;
the "resume" flag could be set such that any command could cause the program to run again;
- the start-address for the program could be altered so that another (or none) listing would show;
- line-linking could be altered to run "unreachable" lines;
- the DOS interpreter accepts special characters so that slot code can be run ("PR#6" being the most common, but "DELETE HELLO" works equally well).
This sounds like what you were seeing. - the code could be self-modifying as it ran.
There was also a modification to the KBDIN routine to point to the reset routine, so that if you achieved a prompt and tried to type something, the machine would reboot.
For a more detailed description, see section 7.20 in "A Brief Description of Some Popular Copy-Protection Techniques on the Apple ][ Platform" (http://pferrie.host22.com/papers/apple2_prot.pdf).
answered Nov 24 at 2:52
peter ferrie
4662516
4662516
1
That's an impressive PDF by the way. I've only just finished reading it and it brought back some fond memories of some of the games :-)
– paxdiablo
Nov 25 at 0:22
add a comment |
1
That's an impressive PDF by the way. I've only just finished reading it and it brought back some fond memories of some of the games :-)
– paxdiablo
Nov 25 at 0:22
1
1
That's an impressive PDF by the way. I've only just finished reading it and it brought back some fond memories of some of the games :-)
– paxdiablo
Nov 25 at 0:22
That's an impressive PDF by the way. I've only just finished reading it and it brought back some fond memories of some of the games :-)
– paxdiablo
Nov 25 at 0:22
add a comment |
Thanks for contributing an answer to Retrocomputing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8364%2fhow-did-apple-basic-programs-protect-against-listing%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown