What is an âunusedâ memory address?
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
Reading this page on Commodore 64 memory structure and usage I stumbled across a cell where the table claims that this memory is unused. What exactly does this entail?
Does this mean that if you wanted to put something in that address you can put whatever you want? Confused, and would appreciate all answers.
assembly commodore
New contributor
add a comment |Â
up vote
2
down vote
favorite
Reading this page on Commodore 64 memory structure and usage I stumbled across a cell where the table claims that this memory is unused. What exactly does this entail?
Does this mean that if you wanted to put something in that address you can put whatever you want? Confused, and would appreciate all answers.
assembly commodore
New contributor
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Reading this page on Commodore 64 memory structure and usage I stumbled across a cell where the table claims that this memory is unused. What exactly does this entail?
Does this mean that if you wanted to put something in that address you can put whatever you want? Confused, and would appreciate all answers.
assembly commodore
New contributor
Reading this page on Commodore 64 memory structure and usage I stumbled across a cell where the table claims that this memory is unused. What exactly does this entail?
Does this mean that if you wanted to put something in that address you can put whatever you want? Confused, and would appreciate all answers.
assembly commodore
assembly commodore
New contributor
New contributor
edited 52 mins ago
Raffzahn
37.4k483149
37.4k483149
New contributor
asked 1 hour ago
wardialer
132
132
New contributor
New contributor
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
3
down vote
accepted
Back in the day, it meant that present versions of the Commodore BASIC and Kernel did not use those locations, but Commodore said nothing about whether future versions of the ROM might do so. Addresses 251-254, by contrast, were specifically marked as available for user programs and Commodore guaranteed that nothing in present nor future versions of the BASIC nor Kernel would do anything to conflict with such usage.
Of course, every version of the BASIC and Kernel ROMs that will ever be produced by Commodore, has been produced by now, and any locations which haven't been used by any versions released to date won't be used by any future versions, ever. Back in the day, however, programmers would have had no way of knowing that.
In official documentation, storage locations which aren't currently used, but which might be used in future, will often be marked "reserved". I don't remember whether Commodore documented the indicated addresses that way. Third-party documentation, especially written after the C64 was discontinued, will be more likely to regard unused locations as "unused" for the reasons indicated above.
It might be worth noting that today the word "reserved" is more commonly used for this purpose than "unused". +1
â Dr Sheldon
35 mins ago
add a comment |Â
up vote
2
down vote
I stumbled across a cell in the table that claims that the memory address is unused. What exactly does this entail?
Well, exactly as it's described, it's not used by any of the ROM routines.
Does this mean that if you wanted to put something in that address you can put whatever you want?
Exactly - it's one ZP address that can be used in yout programs without causing any conflict with KERNEL or BASIC ROM
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
Back in the day, it meant that present versions of the Commodore BASIC and Kernel did not use those locations, but Commodore said nothing about whether future versions of the ROM might do so. Addresses 251-254, by contrast, were specifically marked as available for user programs and Commodore guaranteed that nothing in present nor future versions of the BASIC nor Kernel would do anything to conflict with such usage.
Of course, every version of the BASIC and Kernel ROMs that will ever be produced by Commodore, has been produced by now, and any locations which haven't been used by any versions released to date won't be used by any future versions, ever. Back in the day, however, programmers would have had no way of knowing that.
In official documentation, storage locations which aren't currently used, but which might be used in future, will often be marked "reserved". I don't remember whether Commodore documented the indicated addresses that way. Third-party documentation, especially written after the C64 was discontinued, will be more likely to regard unused locations as "unused" for the reasons indicated above.
It might be worth noting that today the word "reserved" is more commonly used for this purpose than "unused". +1
â Dr Sheldon
35 mins ago
add a comment |Â
up vote
3
down vote
accepted
Back in the day, it meant that present versions of the Commodore BASIC and Kernel did not use those locations, but Commodore said nothing about whether future versions of the ROM might do so. Addresses 251-254, by contrast, were specifically marked as available for user programs and Commodore guaranteed that nothing in present nor future versions of the BASIC nor Kernel would do anything to conflict with such usage.
Of course, every version of the BASIC and Kernel ROMs that will ever be produced by Commodore, has been produced by now, and any locations which haven't been used by any versions released to date won't be used by any future versions, ever. Back in the day, however, programmers would have had no way of knowing that.
In official documentation, storage locations which aren't currently used, but which might be used in future, will often be marked "reserved". I don't remember whether Commodore documented the indicated addresses that way. Third-party documentation, especially written after the C64 was discontinued, will be more likely to regard unused locations as "unused" for the reasons indicated above.
It might be worth noting that today the word "reserved" is more commonly used for this purpose than "unused". +1
â Dr Sheldon
35 mins ago
add a comment |Â
up vote
3
down vote
accepted
up vote
3
down vote
accepted
Back in the day, it meant that present versions of the Commodore BASIC and Kernel did not use those locations, but Commodore said nothing about whether future versions of the ROM might do so. Addresses 251-254, by contrast, were specifically marked as available for user programs and Commodore guaranteed that nothing in present nor future versions of the BASIC nor Kernel would do anything to conflict with such usage.
Of course, every version of the BASIC and Kernel ROMs that will ever be produced by Commodore, has been produced by now, and any locations which haven't been used by any versions released to date won't be used by any future versions, ever. Back in the day, however, programmers would have had no way of knowing that.
In official documentation, storage locations which aren't currently used, but which might be used in future, will often be marked "reserved". I don't remember whether Commodore documented the indicated addresses that way. Third-party documentation, especially written after the C64 was discontinued, will be more likely to regard unused locations as "unused" for the reasons indicated above.
Back in the day, it meant that present versions of the Commodore BASIC and Kernel did not use those locations, but Commodore said nothing about whether future versions of the ROM might do so. Addresses 251-254, by contrast, were specifically marked as available for user programs and Commodore guaranteed that nothing in present nor future versions of the BASIC nor Kernel would do anything to conflict with such usage.
Of course, every version of the BASIC and Kernel ROMs that will ever be produced by Commodore, has been produced by now, and any locations which haven't been used by any versions released to date won't be used by any future versions, ever. Back in the day, however, programmers would have had no way of knowing that.
In official documentation, storage locations which aren't currently used, but which might be used in future, will often be marked "reserved". I don't remember whether Commodore documented the indicated addresses that way. Third-party documentation, especially written after the C64 was discontinued, will be more likely to regard unused locations as "unused" for the reasons indicated above.
edited 5 mins ago
answered 41 mins ago
supercat
5,859633
5,859633
It might be worth noting that today the word "reserved" is more commonly used for this purpose than "unused". +1
â Dr Sheldon
35 mins ago
add a comment |Â
It might be worth noting that today the word "reserved" is more commonly used for this purpose than "unused". +1
â Dr Sheldon
35 mins ago
It might be worth noting that today the word "reserved" is more commonly used for this purpose than "unused". +1
â Dr Sheldon
35 mins ago
It might be worth noting that today the word "reserved" is more commonly used for this purpose than "unused". +1
â Dr Sheldon
35 mins ago
add a comment |Â
up vote
2
down vote
I stumbled across a cell in the table that claims that the memory address is unused. What exactly does this entail?
Well, exactly as it's described, it's not used by any of the ROM routines.
Does this mean that if you wanted to put something in that address you can put whatever you want?
Exactly - it's one ZP address that can be used in yout programs without causing any conflict with KERNEL or BASIC ROM
add a comment |Â
up vote
2
down vote
I stumbled across a cell in the table that claims that the memory address is unused. What exactly does this entail?
Well, exactly as it's described, it's not used by any of the ROM routines.
Does this mean that if you wanted to put something in that address you can put whatever you want?
Exactly - it's one ZP address that can be used in yout programs without causing any conflict with KERNEL or BASIC ROM
add a comment |Â
up vote
2
down vote
up vote
2
down vote
I stumbled across a cell in the table that claims that the memory address is unused. What exactly does this entail?
Well, exactly as it's described, it's not used by any of the ROM routines.
Does this mean that if you wanted to put something in that address you can put whatever you want?
Exactly - it's one ZP address that can be used in yout programs without causing any conflict with KERNEL or BASIC ROM
I stumbled across a cell in the table that claims that the memory address is unused. What exactly does this entail?
Well, exactly as it's described, it's not used by any of the ROM routines.
Does this mean that if you wanted to put something in that address you can put whatever you want?
Exactly - it's one ZP address that can be used in yout programs without causing any conflict with KERNEL or BASIC ROM
answered 54 mins ago
Raffzahn
37.4k483149
37.4k483149
add a comment |Â
add a comment |Â
wardialer is a new contributor. Be nice, and check out our Code of Conduct.
wardialer is a new contributor. Be nice, and check out our Code of Conduct.
wardialer is a new contributor. Be nice, and check out our Code of Conduct.
wardialer is a new contributor. Be nice, and check out our Code of Conduct.
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f7949%2fwhat-is-an-unused-memory-address%23new-answer', 'question_page');
);
Post as a guest
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
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
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