Why are C64 games inconsistent with which joystick port they use?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{
margin-bottom:0;
}
The Commodore 64 has two DB-9 joystick ports. If I'm the only person that ever plays games on it, you would assume that you could just leave a joystick plugged into Port 1 and be done with it. However, there are a number of games out there which want you to have the joystick plugged into Port 2.
Why is that the case? What is the reason for this sometimes inconsistent requirement by C64 software?
commodore-64 joystick ports
add a comment
|
The Commodore 64 has two DB-9 joystick ports. If I'm the only person that ever plays games on it, you would assume that you could just leave a joystick plugged into Port 1 and be done with it. However, there are a number of games out there which want you to have the joystick plugged into Port 2.
Why is that the case? What is the reason for this sometimes inconsistent requirement by C64 software?
commodore-64 joystick ports
6
Joy port #2 tended to be more the "standard" later on. But you're right, and constantly switching the joystick port is a real detractor for the C64's usability as a pure games console. Maybe someone has a solution for this?
– Brian H
May 24 at 16:07
7
@BrianH I have a very good solution: Two joysticks. You'll need them if you want to play with a friend anyway, and in order not to have your friend accuse you of cheating, they also need to be identical.
– pipe
May 25 at 8:14
add a comment
|
The Commodore 64 has two DB-9 joystick ports. If I'm the only person that ever plays games on it, you would assume that you could just leave a joystick plugged into Port 1 and be done with it. However, there are a number of games out there which want you to have the joystick plugged into Port 2.
Why is that the case? What is the reason for this sometimes inconsistent requirement by C64 software?
commodore-64 joystick ports
The Commodore 64 has two DB-9 joystick ports. If I'm the only person that ever plays games on it, you would assume that you could just leave a joystick plugged into Port 1 and be done with it. However, there are a number of games out there which want you to have the joystick plugged into Port 2.
Why is that the case? What is the reason for this sometimes inconsistent requirement by C64 software?
commodore-64 joystick ports
commodore-64 joystick ports
asked May 24 at 13:56
bjbbjb
6,40419 silver badges77 bronze badges
6,40419 silver badges77 bronze badges
6
Joy port #2 tended to be more the "standard" later on. But you're right, and constantly switching the joystick port is a real detractor for the C64's usability as a pure games console. Maybe someone has a solution for this?
– Brian H
May 24 at 16:07
7
@BrianH I have a very good solution: Two joysticks. You'll need them if you want to play with a friend anyway, and in order not to have your friend accuse you of cheating, they also need to be identical.
– pipe
May 25 at 8:14
add a comment
|
6
Joy port #2 tended to be more the "standard" later on. But you're right, and constantly switching the joystick port is a real detractor for the C64's usability as a pure games console. Maybe someone has a solution for this?
– Brian H
May 24 at 16:07
7
@BrianH I have a very good solution: Two joysticks. You'll need them if you want to play with a friend anyway, and in order not to have your friend accuse you of cheating, they also need to be identical.
– pipe
May 25 at 8:14
6
6
Joy port #2 tended to be more the "standard" later on. But you're right, and constantly switching the joystick port is a real detractor for the C64's usability as a pure games console. Maybe someone has a solution for this?
– Brian H
May 24 at 16:07
Joy port #2 tended to be more the "standard" later on. But you're right, and constantly switching the joystick port is a real detractor for the C64's usability as a pure games console. Maybe someone has a solution for this?
– Brian H
May 24 at 16:07
7
7
@BrianH I have a very good solution: Two joysticks. You'll need them if you want to play with a friend anyway, and in order not to have your friend accuse you of cheating, they also need to be identical.
– pipe
May 25 at 8:14
@BrianH I have a very good solution: Two joysticks. You'll need them if you want to play with a friend anyway, and in order not to have your friend accuse you of cheating, they also need to be identical.
– pipe
May 25 at 8:14
add a comment
|
4 Answers
4
active
oldest
votes
As Wilson points out in his answer, it has to do with how the CIA chips interact with the keyboard and the joystick ports, and the confusion that can arise trying to determine where input is being received from.
Compute!'s Mapping the Commodore 64 has an excellent write-up here explaining how the "Complex Interface Adapter" (CIA#1) deals with scanning the keyboard matrix and how the joystick ports are caught up in the drama. Specifically, look at pages 172 to 176 for full details - but here is a brief excerpt with the relevant info:
"Since CIA #1 Data Port B is used for reading the keyboard as well as
joystick 1, some confusion can result. The routine that checks the
keyboard has no way of telling whether a particular bit was set to by
a keypress or one of the joystick switches. For example, if you plug
the joystick into Controller Port 1 and push the stick to the right,
the routine will interpret this as the 2 key being pressed, because
both set the same bit to 0. Likewise, when you read the joystick,
it will register as being pushed to the right if the 2 key is being
pressed.
The problem of mistaking the keyboard for the joystick can be solved
by turning off the keyscan momentarily when reading the stick with a
POKE 56333,127:POKE 56320,255, and restoring it after the read with a
POKE 56333,129. Sometimes you can use the simpler solution of
clearing the keyboard buffer after reading the joystick, with a
POKE 198,0.
The problem of mistaking the joystick for a keypress is much more
difficult — there is no real way to turn off the joystick. Many
commercially available games just use Controller Port 2 to avoid the
conflict. So, if you can't beat them, sit back and press your joystick
to the left in order to slow down a program listing (the keyscan
routine thinks that it is the CTRL key)."
3
This is one of the fascinating bits of C64 errata I've always loved.
– Maury Markowitz
May 24 at 17:40
2
How come that in BASIC moving the joystick didn't trigger a 2 to be printed?
– Stefano Borini
May 26 at 17:23
@StefanoBorini It would have if the joystick had been moved to the right. But it was moved to the left, which is interpreted as the CTRL key.
– Curt J. Sampson
May 27 at 6:51
@CurtJ.Sampson I had the C64, but I don't remember such behavior. I think I would remember it.
– Stefano Borini
May 27 at 17:54
1
Also, FWIW - I just tried this on my physical C64. Port 1 does indeed make all kinds of interesting keystrokes depending on how I waggle the joystick.
– Geo...
May 28 at 10:49
|
show 5 more comments
Because of the way that the joystick port 1 is mapped to the same hardware as the keyboard, from the software's point of view it's impossible to tell if you're wiggling the joystick or typing something on the keyboard. So many games used port 2 instead.
You can also generate port 2 actions/events with the keyboard, see lemon64.com/forum/viewtopic.php?p=410793 which seems to cover the same topic.
– bodgit
May 24 at 14:22
But @bodgit I don't think that moving joy2 will interfere with the keyboard routines in KERNAL
– Wilson
May 24 at 14:45
3
@Wilson: It's easy to distinguish joystick motions from keystrokes. Before and after each keyscan, set all pins to inputs and confirm that none are grounded. If any are grounded, either skip the scan (if not done yet) or reject its finding. The problem is simply that the C64 kernel didn't do that.
– supercat
May 24 at 18:12
2
@Wilson: It would have been readily apparent to anyone who studied the published schematic.
– supercat
May 24 at 19:36
1
@Wilson: Incidentally, the schematic was published in the Commodore 64 Programmer's Reference Manual which was widely available in stores for about $20, so it's hardly obscure. Anyone who wanted to write their own keyboard input routines could easily have made them ignore keypresses when joystick 1 was pushed, but Commodore routines didn't. They also, incidentally, would regard left-shift+(up-down)+(left-right) as typing a shifted A, since those three keys form three corners of a box and A is the fourth, and this caused me considerable annoyance at the time.
– supercat
May 25 at 14:19
|
show 2 more comments
In addition to what already was stated, namely:
- ... how the CIA (Complex Interface Adapter) maps JoyStick - or in general, any - input:
The signals a (digital) JoyStick delivers, come in via Pins 1 to 4 (Up, Down, Left, Right) and additionally Pins 6 and 9 for the buttons (Left, Right) - the equivalent values are represented on the charmap by e.g.: SPACE for Pin 6 aka Fire|Click and other keys, like Numbers and Arrows (can't recall which exactly, i think LEFT-ARROW was one of them). - Signals are cached in CIA #DC01.
But for the second Port the keys representing its signals are always a key-combination starting with the C= | Cequal (as in equal and as in "Key is followed by another, so it becomes a sequel") | Commodore-Key | The Key with the Commodore-Logo. - Signals are cached in CIA +DC00.
Also, the yet not mentioned pins 5 and 9 cache the position (y- and x- -axis) for analogue joystick | mouse | paddle operation-mode.
While the pins used for digital signal input are generic as in cross-platform on (purposely) identical ports like e.g. on Atari ST or Amiga, the analogue ones are not.
But regarding your question, another detail has to be mentioned:
The CIA has at an offset +2 to the direct digital signal cache registers - so for #DC00 at #DC02 and for #DC01 at #DC03 respectively - registers that state if a signal is read-only or if it is allowed to write to it.
Furthermore, the C=64 is designed to allow for a charmap-flip from alphanumeric with UPPER- and lower- -case to UPPERCASE plus GRAPHIC-SYMBOLS.
Another factor can be that a game makes use of memory-intensive bitmap-graphics and therefore has to swap-out some memory from kernel-space (Yes: KERNAL, it's okay, calm down ...), which leads to an overlap with the registers for the Joystick.
Or the game makes intense use of (especially ring-)modulation for its sound-processing, which in return contaminates the registers for the Joystick-ports, because the processing of analogue JoyStick|Mouse|etc. is handled by the SID sound-chip. It is kind of hardwired to the registers for x- and y- -axis in the #DC00|#DC01 and making use of it switches these to read-only mode. So input can not be processed simultaneosly.
Maybe the game syncs graphical representations in general and RasterBars | Z-Scrolling | interlaced colors | etc. specifically to IRQs. This can affect the handling of the registers, too; mostly due to timing- and memory-swapping- -constraints.
Maybe the software has AI built-in or simplified NPCs (Non-Playable-Characters) to provide a single-player-mode for a game that actually requires two players to be playing; like TicTacToe, Chess, etc. - In this case it would be dumb to pollute the already very limited amount of RAM for the program with a stack of extra-routines solely for that specific case; Instead the computer-players simulated interaction is using the real registers of Port 1. This can be done even in basic, by using the equivalent Characters or KeyCodes of these or by poking directly into them. For that to work the registers have to be made writable. You can cheat in these games, by having a joystick in port 1 and overwrite the actions of the computer-player.
-
Using Port 2 for the human player mostly avoids many of the problems that can arise when the software is making use of the aforementioned methods. Why exactly, can't hardly be fitted in here and would be a separate task - or question - in this case.
-
Hope it helps. Anyhow. Thanks for reading.
4
"Why exactly, can't hardly be fitted in here and would be a separate task - or question - in this case." Welcome to Retrocomputing! Please read the tour, How to Ask and How to Answer then, if you have time, have a go at posting a self-answered question explaining this. I'd really like to know it!
– wizzwizz4♦
May 25 at 10:08
@wizzwizz4 Hmmm ... I've gone through the linked infos, but have - truth be told - no idea in which manner i could provide self-answered questions on this matter; Asides camouflaging Mini-How-Tos as those. If that is what you had in mind i may give it a try in a free minute.
– Leahpar Suidualc
May 27 at 2:44
1
You said that "why […] would be a separate […] question". Ask a question "Why does this thingy happen?", add a little bit of detail about what the question is to the question body, then tick the box at the bottom for "post an answer as well" and answer the question like you would normally. The question's just there so you've got somewhere to write the answer.
– wizzwizz4♦
May 27 at 9:13
add a comment
|
The design of the C64 hardware makes it somewhat complex to properly disambiguate joystick and keyboard inputs. The routines in the ROM for scanning the keyboard and joystick don't address all of this complexity, but they do allow better disambiguation of joystick port 2 than 1, so developers who use that routine (or a similar one) can improve joystick/keyboard scanning in a single-joystick game by using port 2 instead of port 1. The quote in Geo's answer gives a little more high-level detail on this.
Though it's not clear from the other answers here (or in some cases they're just wrong), it is possible to do scanning of one or both joysticks and the keyboard that is either perfectly or highly probable to be interference-free. This is not trivial, however, since it involves not just writing and testing custom code to do the scanning, but also analysis and possibly slight redesign of gameplay details. (For example, whether there are certain keyboard-triggered actions that need be detected only if a joystick is being held in a certain direction.) This answer provides the information needed to do that, and should give you a sense of its level of complexity.
Lack of knowledge by the developers may sometimes explain the choice of the port 2 solution, with its downside that the user must figure out which port to use and probably unplug and replug his joystick stick, but likely more often it's simply a matter of cost-benefit: the time saved on designing a better solution to this problem can be spent on improving other areas of the game, such as adding a new feature or improving a level.
It is possible to unambiguously distinguish between joystick movement and arbitrary combinations of up to 3 keystrokes if joystick and keyboard are not used simultaneously. It will also be possible to read certain keys even when one or both joysticks are moved in arbitrary directions or combinations thereof, but not all directions can be accommodated.
– supercat
Aug 12 at 15:45
@supercat Well, to be more precise, for some keys (:
,@
, etc.) all directions (and the fire button) on both joysticks can be read simultaneously; for the rest, all directions can be read on either joystick simultaneously; the only hardware limitations arise when both joysticks are in use simultaneously, and only for certain keys that depend on which pair of joystick directions is being used. As I said in the answer, it's "not trivial" and I think that the details are the answer to a question different from this one.
– Curt J. Sampson
Aug 13 at 5:47
add a comment
|
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "648"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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%2f11097%2fwhy-are-c64-games-inconsistent-with-which-joystick-port-they-use%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
As Wilson points out in his answer, it has to do with how the CIA chips interact with the keyboard and the joystick ports, and the confusion that can arise trying to determine where input is being received from.
Compute!'s Mapping the Commodore 64 has an excellent write-up here explaining how the "Complex Interface Adapter" (CIA#1) deals with scanning the keyboard matrix and how the joystick ports are caught up in the drama. Specifically, look at pages 172 to 176 for full details - but here is a brief excerpt with the relevant info:
"Since CIA #1 Data Port B is used for reading the keyboard as well as
joystick 1, some confusion can result. The routine that checks the
keyboard has no way of telling whether a particular bit was set to by
a keypress or one of the joystick switches. For example, if you plug
the joystick into Controller Port 1 and push the stick to the right,
the routine will interpret this as the 2 key being pressed, because
both set the same bit to 0. Likewise, when you read the joystick,
it will register as being pushed to the right if the 2 key is being
pressed.
The problem of mistaking the keyboard for the joystick can be solved
by turning off the keyscan momentarily when reading the stick with a
POKE 56333,127:POKE 56320,255, and restoring it after the read with a
POKE 56333,129. Sometimes you can use the simpler solution of
clearing the keyboard buffer after reading the joystick, with a
POKE 198,0.
The problem of mistaking the joystick for a keypress is much more
difficult — there is no real way to turn off the joystick. Many
commercially available games just use Controller Port 2 to avoid the
conflict. So, if you can't beat them, sit back and press your joystick
to the left in order to slow down a program listing (the keyscan
routine thinks that it is the CTRL key)."
3
This is one of the fascinating bits of C64 errata I've always loved.
– Maury Markowitz
May 24 at 17:40
2
How come that in BASIC moving the joystick didn't trigger a 2 to be printed?
– Stefano Borini
May 26 at 17:23
@StefanoBorini It would have if the joystick had been moved to the right. But it was moved to the left, which is interpreted as the CTRL key.
– Curt J. Sampson
May 27 at 6:51
@CurtJ.Sampson I had the C64, but I don't remember such behavior. I think I would remember it.
– Stefano Borini
May 27 at 17:54
1
Also, FWIW - I just tried this on my physical C64. Port 1 does indeed make all kinds of interesting keystrokes depending on how I waggle the joystick.
– Geo...
May 28 at 10:49
|
show 5 more comments
As Wilson points out in his answer, it has to do with how the CIA chips interact with the keyboard and the joystick ports, and the confusion that can arise trying to determine where input is being received from.
Compute!'s Mapping the Commodore 64 has an excellent write-up here explaining how the "Complex Interface Adapter" (CIA#1) deals with scanning the keyboard matrix and how the joystick ports are caught up in the drama. Specifically, look at pages 172 to 176 for full details - but here is a brief excerpt with the relevant info:
"Since CIA #1 Data Port B is used for reading the keyboard as well as
joystick 1, some confusion can result. The routine that checks the
keyboard has no way of telling whether a particular bit was set to by
a keypress or one of the joystick switches. For example, if you plug
the joystick into Controller Port 1 and push the stick to the right,
the routine will interpret this as the 2 key being pressed, because
both set the same bit to 0. Likewise, when you read the joystick,
it will register as being pushed to the right if the 2 key is being
pressed.
The problem of mistaking the keyboard for the joystick can be solved
by turning off the keyscan momentarily when reading the stick with a
POKE 56333,127:POKE 56320,255, and restoring it after the read with a
POKE 56333,129. Sometimes you can use the simpler solution of
clearing the keyboard buffer after reading the joystick, with a
POKE 198,0.
The problem of mistaking the joystick for a keypress is much more
difficult — there is no real way to turn off the joystick. Many
commercially available games just use Controller Port 2 to avoid the
conflict. So, if you can't beat them, sit back and press your joystick
to the left in order to slow down a program listing (the keyscan
routine thinks that it is the CTRL key)."
3
This is one of the fascinating bits of C64 errata I've always loved.
– Maury Markowitz
May 24 at 17:40
2
How come that in BASIC moving the joystick didn't trigger a 2 to be printed?
– Stefano Borini
May 26 at 17:23
@StefanoBorini It would have if the joystick had been moved to the right. But it was moved to the left, which is interpreted as the CTRL key.
– Curt J. Sampson
May 27 at 6:51
@CurtJ.Sampson I had the C64, but I don't remember such behavior. I think I would remember it.
– Stefano Borini
May 27 at 17:54
1
Also, FWIW - I just tried this on my physical C64. Port 1 does indeed make all kinds of interesting keystrokes depending on how I waggle the joystick.
– Geo...
May 28 at 10:49
|
show 5 more comments
As Wilson points out in his answer, it has to do with how the CIA chips interact with the keyboard and the joystick ports, and the confusion that can arise trying to determine where input is being received from.
Compute!'s Mapping the Commodore 64 has an excellent write-up here explaining how the "Complex Interface Adapter" (CIA#1) deals with scanning the keyboard matrix and how the joystick ports are caught up in the drama. Specifically, look at pages 172 to 176 for full details - but here is a brief excerpt with the relevant info:
"Since CIA #1 Data Port B is used for reading the keyboard as well as
joystick 1, some confusion can result. The routine that checks the
keyboard has no way of telling whether a particular bit was set to by
a keypress or one of the joystick switches. For example, if you plug
the joystick into Controller Port 1 and push the stick to the right,
the routine will interpret this as the 2 key being pressed, because
both set the same bit to 0. Likewise, when you read the joystick,
it will register as being pushed to the right if the 2 key is being
pressed.
The problem of mistaking the keyboard for the joystick can be solved
by turning off the keyscan momentarily when reading the stick with a
POKE 56333,127:POKE 56320,255, and restoring it after the read with a
POKE 56333,129. Sometimes you can use the simpler solution of
clearing the keyboard buffer after reading the joystick, with a
POKE 198,0.
The problem of mistaking the joystick for a keypress is much more
difficult — there is no real way to turn off the joystick. Many
commercially available games just use Controller Port 2 to avoid the
conflict. So, if you can't beat them, sit back and press your joystick
to the left in order to slow down a program listing (the keyscan
routine thinks that it is the CTRL key)."
As Wilson points out in his answer, it has to do with how the CIA chips interact with the keyboard and the joystick ports, and the confusion that can arise trying to determine where input is being received from.
Compute!'s Mapping the Commodore 64 has an excellent write-up here explaining how the "Complex Interface Adapter" (CIA#1) deals with scanning the keyboard matrix and how the joystick ports are caught up in the drama. Specifically, look at pages 172 to 176 for full details - but here is a brief excerpt with the relevant info:
"Since CIA #1 Data Port B is used for reading the keyboard as well as
joystick 1, some confusion can result. The routine that checks the
keyboard has no way of telling whether a particular bit was set to by
a keypress or one of the joystick switches. For example, if you plug
the joystick into Controller Port 1 and push the stick to the right,
the routine will interpret this as the 2 key being pressed, because
both set the same bit to 0. Likewise, when you read the joystick,
it will register as being pushed to the right if the 2 key is being
pressed.
The problem of mistaking the keyboard for the joystick can be solved
by turning off the keyscan momentarily when reading the stick with a
POKE 56333,127:POKE 56320,255, and restoring it after the read with a
POKE 56333,129. Sometimes you can use the simpler solution of
clearing the keyboard buffer after reading the joystick, with a
POKE 198,0.
The problem of mistaking the joystick for a keypress is much more
difficult — there is no real way to turn off the joystick. Many
commercially available games just use Controller Port 2 to avoid the
conflict. So, if you can't beat them, sit back and press your joystick
to the left in order to slow down a program listing (the keyscan
routine thinks that it is the CTRL key)."
edited May 26 at 10:08
Community♦
1
1
answered May 24 at 14:24
Geo...Geo...
3,61411 silver badges34 bronze badges
3,61411 silver badges34 bronze badges
3
This is one of the fascinating bits of C64 errata I've always loved.
– Maury Markowitz
May 24 at 17:40
2
How come that in BASIC moving the joystick didn't trigger a 2 to be printed?
– Stefano Borini
May 26 at 17:23
@StefanoBorini It would have if the joystick had been moved to the right. But it was moved to the left, which is interpreted as the CTRL key.
– Curt J. Sampson
May 27 at 6:51
@CurtJ.Sampson I had the C64, but I don't remember such behavior. I think I would remember it.
– Stefano Borini
May 27 at 17:54
1
Also, FWIW - I just tried this on my physical C64. Port 1 does indeed make all kinds of interesting keystrokes depending on how I waggle the joystick.
– Geo...
May 28 at 10:49
|
show 5 more comments
3
This is one of the fascinating bits of C64 errata I've always loved.
– Maury Markowitz
May 24 at 17:40
2
How come that in BASIC moving the joystick didn't trigger a 2 to be printed?
– Stefano Borini
May 26 at 17:23
@StefanoBorini It would have if the joystick had been moved to the right. But it was moved to the left, which is interpreted as the CTRL key.
– Curt J. Sampson
May 27 at 6:51
@CurtJ.Sampson I had the C64, but I don't remember such behavior. I think I would remember it.
– Stefano Borini
May 27 at 17:54
1
Also, FWIW - I just tried this on my physical C64. Port 1 does indeed make all kinds of interesting keystrokes depending on how I waggle the joystick.
– Geo...
May 28 at 10:49
3
3
This is one of the fascinating bits of C64 errata I've always loved.
– Maury Markowitz
May 24 at 17:40
This is one of the fascinating bits of C64 errata I've always loved.
– Maury Markowitz
May 24 at 17:40
2
2
How come that in BASIC moving the joystick didn't trigger a 2 to be printed?
– Stefano Borini
May 26 at 17:23
How come that in BASIC moving the joystick didn't trigger a 2 to be printed?
– Stefano Borini
May 26 at 17:23
@StefanoBorini It would have if the joystick had been moved to the right. But it was moved to the left, which is interpreted as the CTRL key.
– Curt J. Sampson
May 27 at 6:51
@StefanoBorini It would have if the joystick had been moved to the right. But it was moved to the left, which is interpreted as the CTRL key.
– Curt J. Sampson
May 27 at 6:51
@CurtJ.Sampson I had the C64, but I don't remember such behavior. I think I would remember it.
– Stefano Borini
May 27 at 17:54
@CurtJ.Sampson I had the C64, but I don't remember such behavior. I think I would remember it.
– Stefano Borini
May 27 at 17:54
1
1
Also, FWIW - I just tried this on my physical C64. Port 1 does indeed make all kinds of interesting keystrokes depending on how I waggle the joystick.
– Geo...
May 28 at 10:49
Also, FWIW - I just tried this on my physical C64. Port 1 does indeed make all kinds of interesting keystrokes depending on how I waggle the joystick.
– Geo...
May 28 at 10:49
|
show 5 more comments
Because of the way that the joystick port 1 is mapped to the same hardware as the keyboard, from the software's point of view it's impossible to tell if you're wiggling the joystick or typing something on the keyboard. So many games used port 2 instead.
You can also generate port 2 actions/events with the keyboard, see lemon64.com/forum/viewtopic.php?p=410793 which seems to cover the same topic.
– bodgit
May 24 at 14:22
But @bodgit I don't think that moving joy2 will interfere with the keyboard routines in KERNAL
– Wilson
May 24 at 14:45
3
@Wilson: It's easy to distinguish joystick motions from keystrokes. Before and after each keyscan, set all pins to inputs and confirm that none are grounded. If any are grounded, either skip the scan (if not done yet) or reject its finding. The problem is simply that the C64 kernel didn't do that.
– supercat
May 24 at 18:12
2
@Wilson: It would have been readily apparent to anyone who studied the published schematic.
– supercat
May 24 at 19:36
1
@Wilson: Incidentally, the schematic was published in the Commodore 64 Programmer's Reference Manual which was widely available in stores for about $20, so it's hardly obscure. Anyone who wanted to write their own keyboard input routines could easily have made them ignore keypresses when joystick 1 was pushed, but Commodore routines didn't. They also, incidentally, would regard left-shift+(up-down)+(left-right) as typing a shifted A, since those three keys form three corners of a box and A is the fourth, and this caused me considerable annoyance at the time.
– supercat
May 25 at 14:19
|
show 2 more comments
Because of the way that the joystick port 1 is mapped to the same hardware as the keyboard, from the software's point of view it's impossible to tell if you're wiggling the joystick or typing something on the keyboard. So many games used port 2 instead.
You can also generate port 2 actions/events with the keyboard, see lemon64.com/forum/viewtopic.php?p=410793 which seems to cover the same topic.
– bodgit
May 24 at 14:22
But @bodgit I don't think that moving joy2 will interfere with the keyboard routines in KERNAL
– Wilson
May 24 at 14:45
3
@Wilson: It's easy to distinguish joystick motions from keystrokes. Before and after each keyscan, set all pins to inputs and confirm that none are grounded. If any are grounded, either skip the scan (if not done yet) or reject its finding. The problem is simply that the C64 kernel didn't do that.
– supercat
May 24 at 18:12
2
@Wilson: It would have been readily apparent to anyone who studied the published schematic.
– supercat
May 24 at 19:36
1
@Wilson: Incidentally, the schematic was published in the Commodore 64 Programmer's Reference Manual which was widely available in stores for about $20, so it's hardly obscure. Anyone who wanted to write their own keyboard input routines could easily have made them ignore keypresses when joystick 1 was pushed, but Commodore routines didn't. They also, incidentally, would regard left-shift+(up-down)+(left-right) as typing a shifted A, since those three keys form three corners of a box and A is the fourth, and this caused me considerable annoyance at the time.
– supercat
May 25 at 14:19
|
show 2 more comments
Because of the way that the joystick port 1 is mapped to the same hardware as the keyboard, from the software's point of view it's impossible to tell if you're wiggling the joystick or typing something on the keyboard. So many games used port 2 instead.
Because of the way that the joystick port 1 is mapped to the same hardware as the keyboard, from the software's point of view it's impossible to tell if you're wiggling the joystick or typing something on the keyboard. So many games used port 2 instead.
answered May 24 at 14:01
WilsonWilson
14.7k7 gold badges68 silver badges161 bronze badges
14.7k7 gold badges68 silver badges161 bronze badges
You can also generate port 2 actions/events with the keyboard, see lemon64.com/forum/viewtopic.php?p=410793 which seems to cover the same topic.
– bodgit
May 24 at 14:22
But @bodgit I don't think that moving joy2 will interfere with the keyboard routines in KERNAL
– Wilson
May 24 at 14:45
3
@Wilson: It's easy to distinguish joystick motions from keystrokes. Before and after each keyscan, set all pins to inputs and confirm that none are grounded. If any are grounded, either skip the scan (if not done yet) or reject its finding. The problem is simply that the C64 kernel didn't do that.
– supercat
May 24 at 18:12
2
@Wilson: It would have been readily apparent to anyone who studied the published schematic.
– supercat
May 24 at 19:36
1
@Wilson: Incidentally, the schematic was published in the Commodore 64 Programmer's Reference Manual which was widely available in stores for about $20, so it's hardly obscure. Anyone who wanted to write their own keyboard input routines could easily have made them ignore keypresses when joystick 1 was pushed, but Commodore routines didn't. They also, incidentally, would regard left-shift+(up-down)+(left-right) as typing a shifted A, since those three keys form three corners of a box and A is the fourth, and this caused me considerable annoyance at the time.
– supercat
May 25 at 14:19
|
show 2 more comments
You can also generate port 2 actions/events with the keyboard, see lemon64.com/forum/viewtopic.php?p=410793 which seems to cover the same topic.
– bodgit
May 24 at 14:22
But @bodgit I don't think that moving joy2 will interfere with the keyboard routines in KERNAL
– Wilson
May 24 at 14:45
3
@Wilson: It's easy to distinguish joystick motions from keystrokes. Before and after each keyscan, set all pins to inputs and confirm that none are grounded. If any are grounded, either skip the scan (if not done yet) or reject its finding. The problem is simply that the C64 kernel didn't do that.
– supercat
May 24 at 18:12
2
@Wilson: It would have been readily apparent to anyone who studied the published schematic.
– supercat
May 24 at 19:36
1
@Wilson: Incidentally, the schematic was published in the Commodore 64 Programmer's Reference Manual which was widely available in stores for about $20, so it's hardly obscure. Anyone who wanted to write their own keyboard input routines could easily have made them ignore keypresses when joystick 1 was pushed, but Commodore routines didn't. They also, incidentally, would regard left-shift+(up-down)+(left-right) as typing a shifted A, since those three keys form three corners of a box and A is the fourth, and this caused me considerable annoyance at the time.
– supercat
May 25 at 14:19
You can also generate port 2 actions/events with the keyboard, see lemon64.com/forum/viewtopic.php?p=410793 which seems to cover the same topic.
– bodgit
May 24 at 14:22
You can also generate port 2 actions/events with the keyboard, see lemon64.com/forum/viewtopic.php?p=410793 which seems to cover the same topic.
– bodgit
May 24 at 14:22
But @bodgit I don't think that moving joy2 will interfere with the keyboard routines in KERNAL
– Wilson
May 24 at 14:45
But @bodgit I don't think that moving joy2 will interfere with the keyboard routines in KERNAL
– Wilson
May 24 at 14:45
3
3
@Wilson: It's easy to distinguish joystick motions from keystrokes. Before and after each keyscan, set all pins to inputs and confirm that none are grounded. If any are grounded, either skip the scan (if not done yet) or reject its finding. The problem is simply that the C64 kernel didn't do that.
– supercat
May 24 at 18:12
@Wilson: It's easy to distinguish joystick motions from keystrokes. Before and after each keyscan, set all pins to inputs and confirm that none are grounded. If any are grounded, either skip the scan (if not done yet) or reject its finding. The problem is simply that the C64 kernel didn't do that.
– supercat
May 24 at 18:12
2
2
@Wilson: It would have been readily apparent to anyone who studied the published schematic.
– supercat
May 24 at 19:36
@Wilson: It would have been readily apparent to anyone who studied the published schematic.
– supercat
May 24 at 19:36
1
1
@Wilson: Incidentally, the schematic was published in the Commodore 64 Programmer's Reference Manual which was widely available in stores for about $20, so it's hardly obscure. Anyone who wanted to write their own keyboard input routines could easily have made them ignore keypresses when joystick 1 was pushed, but Commodore routines didn't. They also, incidentally, would regard left-shift+(up-down)+(left-right) as typing a shifted A, since those three keys form three corners of a box and A is the fourth, and this caused me considerable annoyance at the time.
– supercat
May 25 at 14:19
@Wilson: Incidentally, the schematic was published in the Commodore 64 Programmer's Reference Manual which was widely available in stores for about $20, so it's hardly obscure. Anyone who wanted to write their own keyboard input routines could easily have made them ignore keypresses when joystick 1 was pushed, but Commodore routines didn't. They also, incidentally, would regard left-shift+(up-down)+(left-right) as typing a shifted A, since those three keys form three corners of a box and A is the fourth, and this caused me considerable annoyance at the time.
– supercat
May 25 at 14:19
|
show 2 more comments
In addition to what already was stated, namely:
- ... how the CIA (Complex Interface Adapter) maps JoyStick - or in general, any - input:
The signals a (digital) JoyStick delivers, come in via Pins 1 to 4 (Up, Down, Left, Right) and additionally Pins 6 and 9 for the buttons (Left, Right) - the equivalent values are represented on the charmap by e.g.: SPACE for Pin 6 aka Fire|Click and other keys, like Numbers and Arrows (can't recall which exactly, i think LEFT-ARROW was one of them). - Signals are cached in CIA #DC01.
But for the second Port the keys representing its signals are always a key-combination starting with the C= | Cequal (as in equal and as in "Key is followed by another, so it becomes a sequel") | Commodore-Key | The Key with the Commodore-Logo. - Signals are cached in CIA +DC00.
Also, the yet not mentioned pins 5 and 9 cache the position (y- and x- -axis) for analogue joystick | mouse | paddle operation-mode.
While the pins used for digital signal input are generic as in cross-platform on (purposely) identical ports like e.g. on Atari ST or Amiga, the analogue ones are not.
But regarding your question, another detail has to be mentioned:
The CIA has at an offset +2 to the direct digital signal cache registers - so for #DC00 at #DC02 and for #DC01 at #DC03 respectively - registers that state if a signal is read-only or if it is allowed to write to it.
Furthermore, the C=64 is designed to allow for a charmap-flip from alphanumeric with UPPER- and lower- -case to UPPERCASE plus GRAPHIC-SYMBOLS.
Another factor can be that a game makes use of memory-intensive bitmap-graphics and therefore has to swap-out some memory from kernel-space (Yes: KERNAL, it's okay, calm down ...), which leads to an overlap with the registers for the Joystick.
Or the game makes intense use of (especially ring-)modulation for its sound-processing, which in return contaminates the registers for the Joystick-ports, because the processing of analogue JoyStick|Mouse|etc. is handled by the SID sound-chip. It is kind of hardwired to the registers for x- and y- -axis in the #DC00|#DC01 and making use of it switches these to read-only mode. So input can not be processed simultaneosly.
Maybe the game syncs graphical representations in general and RasterBars | Z-Scrolling | interlaced colors | etc. specifically to IRQs. This can affect the handling of the registers, too; mostly due to timing- and memory-swapping- -constraints.
Maybe the software has AI built-in or simplified NPCs (Non-Playable-Characters) to provide a single-player-mode for a game that actually requires two players to be playing; like TicTacToe, Chess, etc. - In this case it would be dumb to pollute the already very limited amount of RAM for the program with a stack of extra-routines solely for that specific case; Instead the computer-players simulated interaction is using the real registers of Port 1. This can be done even in basic, by using the equivalent Characters or KeyCodes of these or by poking directly into them. For that to work the registers have to be made writable. You can cheat in these games, by having a joystick in port 1 and overwrite the actions of the computer-player.
-
Using Port 2 for the human player mostly avoids many of the problems that can arise when the software is making use of the aforementioned methods. Why exactly, can't hardly be fitted in here and would be a separate task - or question - in this case.
-
Hope it helps. Anyhow. Thanks for reading.
4
"Why exactly, can't hardly be fitted in here and would be a separate task - or question - in this case." Welcome to Retrocomputing! Please read the tour, How to Ask and How to Answer then, if you have time, have a go at posting a self-answered question explaining this. I'd really like to know it!
– wizzwizz4♦
May 25 at 10:08
@wizzwizz4 Hmmm ... I've gone through the linked infos, but have - truth be told - no idea in which manner i could provide self-answered questions on this matter; Asides camouflaging Mini-How-Tos as those. If that is what you had in mind i may give it a try in a free minute.
– Leahpar Suidualc
May 27 at 2:44
1
You said that "why […] would be a separate […] question". Ask a question "Why does this thingy happen?", add a little bit of detail about what the question is to the question body, then tick the box at the bottom for "post an answer as well" and answer the question like you would normally. The question's just there so you've got somewhere to write the answer.
– wizzwizz4♦
May 27 at 9:13
add a comment
|
In addition to what already was stated, namely:
- ... how the CIA (Complex Interface Adapter) maps JoyStick - or in general, any - input:
The signals a (digital) JoyStick delivers, come in via Pins 1 to 4 (Up, Down, Left, Right) and additionally Pins 6 and 9 for the buttons (Left, Right) - the equivalent values are represented on the charmap by e.g.: SPACE for Pin 6 aka Fire|Click and other keys, like Numbers and Arrows (can't recall which exactly, i think LEFT-ARROW was one of them). - Signals are cached in CIA #DC01.
But for the second Port the keys representing its signals are always a key-combination starting with the C= | Cequal (as in equal and as in "Key is followed by another, so it becomes a sequel") | Commodore-Key | The Key with the Commodore-Logo. - Signals are cached in CIA +DC00.
Also, the yet not mentioned pins 5 and 9 cache the position (y- and x- -axis) for analogue joystick | mouse | paddle operation-mode.
While the pins used for digital signal input are generic as in cross-platform on (purposely) identical ports like e.g. on Atari ST or Amiga, the analogue ones are not.
But regarding your question, another detail has to be mentioned:
The CIA has at an offset +2 to the direct digital signal cache registers - so for #DC00 at #DC02 and for #DC01 at #DC03 respectively - registers that state if a signal is read-only or if it is allowed to write to it.
Furthermore, the C=64 is designed to allow for a charmap-flip from alphanumeric with UPPER- and lower- -case to UPPERCASE plus GRAPHIC-SYMBOLS.
Another factor can be that a game makes use of memory-intensive bitmap-graphics and therefore has to swap-out some memory from kernel-space (Yes: KERNAL, it's okay, calm down ...), which leads to an overlap with the registers for the Joystick.
Or the game makes intense use of (especially ring-)modulation for its sound-processing, which in return contaminates the registers for the Joystick-ports, because the processing of analogue JoyStick|Mouse|etc. is handled by the SID sound-chip. It is kind of hardwired to the registers for x- and y- -axis in the #DC00|#DC01 and making use of it switches these to read-only mode. So input can not be processed simultaneosly.
Maybe the game syncs graphical representations in general and RasterBars | Z-Scrolling | interlaced colors | etc. specifically to IRQs. This can affect the handling of the registers, too; mostly due to timing- and memory-swapping- -constraints.
Maybe the software has AI built-in or simplified NPCs (Non-Playable-Characters) to provide a single-player-mode for a game that actually requires two players to be playing; like TicTacToe, Chess, etc. - In this case it would be dumb to pollute the already very limited amount of RAM for the program with a stack of extra-routines solely for that specific case; Instead the computer-players simulated interaction is using the real registers of Port 1. This can be done even in basic, by using the equivalent Characters or KeyCodes of these or by poking directly into them. For that to work the registers have to be made writable. You can cheat in these games, by having a joystick in port 1 and overwrite the actions of the computer-player.
-
Using Port 2 for the human player mostly avoids many of the problems that can arise when the software is making use of the aforementioned methods. Why exactly, can't hardly be fitted in here and would be a separate task - or question - in this case.
-
Hope it helps. Anyhow. Thanks for reading.
4
"Why exactly, can't hardly be fitted in here and would be a separate task - or question - in this case." Welcome to Retrocomputing! Please read the tour, How to Ask and How to Answer then, if you have time, have a go at posting a self-answered question explaining this. I'd really like to know it!
– wizzwizz4♦
May 25 at 10:08
@wizzwizz4 Hmmm ... I've gone through the linked infos, but have - truth be told - no idea in which manner i could provide self-answered questions on this matter; Asides camouflaging Mini-How-Tos as those. If that is what you had in mind i may give it a try in a free minute.
– Leahpar Suidualc
May 27 at 2:44
1
You said that "why […] would be a separate […] question". Ask a question "Why does this thingy happen?", add a little bit of detail about what the question is to the question body, then tick the box at the bottom for "post an answer as well" and answer the question like you would normally. The question's just there so you've got somewhere to write the answer.
– wizzwizz4♦
May 27 at 9:13
add a comment
|
In addition to what already was stated, namely:
- ... how the CIA (Complex Interface Adapter) maps JoyStick - or in general, any - input:
The signals a (digital) JoyStick delivers, come in via Pins 1 to 4 (Up, Down, Left, Right) and additionally Pins 6 and 9 for the buttons (Left, Right) - the equivalent values are represented on the charmap by e.g.: SPACE for Pin 6 aka Fire|Click and other keys, like Numbers and Arrows (can't recall which exactly, i think LEFT-ARROW was one of them). - Signals are cached in CIA #DC01.
But for the second Port the keys representing its signals are always a key-combination starting with the C= | Cequal (as in equal and as in "Key is followed by another, so it becomes a sequel") | Commodore-Key | The Key with the Commodore-Logo. - Signals are cached in CIA +DC00.
Also, the yet not mentioned pins 5 and 9 cache the position (y- and x- -axis) for analogue joystick | mouse | paddle operation-mode.
While the pins used for digital signal input are generic as in cross-platform on (purposely) identical ports like e.g. on Atari ST or Amiga, the analogue ones are not.
But regarding your question, another detail has to be mentioned:
The CIA has at an offset +2 to the direct digital signal cache registers - so for #DC00 at #DC02 and for #DC01 at #DC03 respectively - registers that state if a signal is read-only or if it is allowed to write to it.
Furthermore, the C=64 is designed to allow for a charmap-flip from alphanumeric with UPPER- and lower- -case to UPPERCASE plus GRAPHIC-SYMBOLS.
Another factor can be that a game makes use of memory-intensive bitmap-graphics and therefore has to swap-out some memory from kernel-space (Yes: KERNAL, it's okay, calm down ...), which leads to an overlap with the registers for the Joystick.
Or the game makes intense use of (especially ring-)modulation for its sound-processing, which in return contaminates the registers for the Joystick-ports, because the processing of analogue JoyStick|Mouse|etc. is handled by the SID sound-chip. It is kind of hardwired to the registers for x- and y- -axis in the #DC00|#DC01 and making use of it switches these to read-only mode. So input can not be processed simultaneosly.
Maybe the game syncs graphical representations in general and RasterBars | Z-Scrolling | interlaced colors | etc. specifically to IRQs. This can affect the handling of the registers, too; mostly due to timing- and memory-swapping- -constraints.
Maybe the software has AI built-in or simplified NPCs (Non-Playable-Characters) to provide a single-player-mode for a game that actually requires two players to be playing; like TicTacToe, Chess, etc. - In this case it would be dumb to pollute the already very limited amount of RAM for the program with a stack of extra-routines solely for that specific case; Instead the computer-players simulated interaction is using the real registers of Port 1. This can be done even in basic, by using the equivalent Characters or KeyCodes of these or by poking directly into them. For that to work the registers have to be made writable. You can cheat in these games, by having a joystick in port 1 and overwrite the actions of the computer-player.
-
Using Port 2 for the human player mostly avoids many of the problems that can arise when the software is making use of the aforementioned methods. Why exactly, can't hardly be fitted in here and would be a separate task - or question - in this case.
-
Hope it helps. Anyhow. Thanks for reading.
In addition to what already was stated, namely:
- ... how the CIA (Complex Interface Adapter) maps JoyStick - or in general, any - input:
The signals a (digital) JoyStick delivers, come in via Pins 1 to 4 (Up, Down, Left, Right) and additionally Pins 6 and 9 for the buttons (Left, Right) - the equivalent values are represented on the charmap by e.g.: SPACE for Pin 6 aka Fire|Click and other keys, like Numbers and Arrows (can't recall which exactly, i think LEFT-ARROW was one of them). - Signals are cached in CIA #DC01.
But for the second Port the keys representing its signals are always a key-combination starting with the C= | Cequal (as in equal and as in "Key is followed by another, so it becomes a sequel") | Commodore-Key | The Key with the Commodore-Logo. - Signals are cached in CIA +DC00.
Also, the yet not mentioned pins 5 and 9 cache the position (y- and x- -axis) for analogue joystick | mouse | paddle operation-mode.
While the pins used for digital signal input are generic as in cross-platform on (purposely) identical ports like e.g. on Atari ST or Amiga, the analogue ones are not.
But regarding your question, another detail has to be mentioned:
The CIA has at an offset +2 to the direct digital signal cache registers - so for #DC00 at #DC02 and for #DC01 at #DC03 respectively - registers that state if a signal is read-only or if it is allowed to write to it.
Furthermore, the C=64 is designed to allow for a charmap-flip from alphanumeric with UPPER- and lower- -case to UPPERCASE plus GRAPHIC-SYMBOLS.
Another factor can be that a game makes use of memory-intensive bitmap-graphics and therefore has to swap-out some memory from kernel-space (Yes: KERNAL, it's okay, calm down ...), which leads to an overlap with the registers for the Joystick.
Or the game makes intense use of (especially ring-)modulation for its sound-processing, which in return contaminates the registers for the Joystick-ports, because the processing of analogue JoyStick|Mouse|etc. is handled by the SID sound-chip. It is kind of hardwired to the registers for x- and y- -axis in the #DC00|#DC01 and making use of it switches these to read-only mode. So input can not be processed simultaneosly.
Maybe the game syncs graphical representations in general and RasterBars | Z-Scrolling | interlaced colors | etc. specifically to IRQs. This can affect the handling of the registers, too; mostly due to timing- and memory-swapping- -constraints.
Maybe the software has AI built-in or simplified NPCs (Non-Playable-Characters) to provide a single-player-mode for a game that actually requires two players to be playing; like TicTacToe, Chess, etc. - In this case it would be dumb to pollute the already very limited amount of RAM for the program with a stack of extra-routines solely for that specific case; Instead the computer-players simulated interaction is using the real registers of Port 1. This can be done even in basic, by using the equivalent Characters or KeyCodes of these or by poking directly into them. For that to work the registers have to be made writable. You can cheat in these games, by having a joystick in port 1 and overwrite the actions of the computer-player.
-
Using Port 2 for the human player mostly avoids many of the problems that can arise when the software is making use of the aforementioned methods. Why exactly, can't hardly be fitted in here and would be a separate task - or question - in this case.
-
Hope it helps. Anyhow. Thanks for reading.
answered May 25 at 9:48
Leahpar SuidualcLeahpar Suidualc
692 bronze badges
692 bronze badges
4
"Why exactly, can't hardly be fitted in here and would be a separate task - or question - in this case." Welcome to Retrocomputing! Please read the tour, How to Ask and How to Answer then, if you have time, have a go at posting a self-answered question explaining this. I'd really like to know it!
– wizzwizz4♦
May 25 at 10:08
@wizzwizz4 Hmmm ... I've gone through the linked infos, but have - truth be told - no idea in which manner i could provide self-answered questions on this matter; Asides camouflaging Mini-How-Tos as those. If that is what you had in mind i may give it a try in a free minute.
– Leahpar Suidualc
May 27 at 2:44
1
You said that "why […] would be a separate […] question". Ask a question "Why does this thingy happen?", add a little bit of detail about what the question is to the question body, then tick the box at the bottom for "post an answer as well" and answer the question like you would normally. The question's just there so you've got somewhere to write the answer.
– wizzwizz4♦
May 27 at 9:13
add a comment
|
4
"Why exactly, can't hardly be fitted in here and would be a separate task - or question - in this case." Welcome to Retrocomputing! Please read the tour, How to Ask and How to Answer then, if you have time, have a go at posting a self-answered question explaining this. I'd really like to know it!
– wizzwizz4♦
May 25 at 10:08
@wizzwizz4 Hmmm ... I've gone through the linked infos, but have - truth be told - no idea in which manner i could provide self-answered questions on this matter; Asides camouflaging Mini-How-Tos as those. If that is what you had in mind i may give it a try in a free minute.
– Leahpar Suidualc
May 27 at 2:44
1
You said that "why […] would be a separate […] question". Ask a question "Why does this thingy happen?", add a little bit of detail about what the question is to the question body, then tick the box at the bottom for "post an answer as well" and answer the question like you would normally. The question's just there so you've got somewhere to write the answer.
– wizzwizz4♦
May 27 at 9:13
4
4
"Why exactly, can't hardly be fitted in here and would be a separate task - or question - in this case." Welcome to Retrocomputing! Please read the tour, How to Ask and How to Answer then, if you have time, have a go at posting a self-answered question explaining this. I'd really like to know it!
– wizzwizz4♦
May 25 at 10:08
"Why exactly, can't hardly be fitted in here and would be a separate task - or question - in this case." Welcome to Retrocomputing! Please read the tour, How to Ask and How to Answer then, if you have time, have a go at posting a self-answered question explaining this. I'd really like to know it!
– wizzwizz4♦
May 25 at 10:08
@wizzwizz4 Hmmm ... I've gone through the linked infos, but have - truth be told - no idea in which manner i could provide self-answered questions on this matter; Asides camouflaging Mini-How-Tos as those. If that is what you had in mind i may give it a try in a free minute.
– Leahpar Suidualc
May 27 at 2:44
@wizzwizz4 Hmmm ... I've gone through the linked infos, but have - truth be told - no idea in which manner i could provide self-answered questions on this matter; Asides camouflaging Mini-How-Tos as those. If that is what you had in mind i may give it a try in a free minute.
– Leahpar Suidualc
May 27 at 2:44
1
1
You said that "why […] would be a separate […] question". Ask a question "Why does this thingy happen?", add a little bit of detail about what the question is to the question body, then tick the box at the bottom for "post an answer as well" and answer the question like you would normally. The question's just there so you've got somewhere to write the answer.
– wizzwizz4♦
May 27 at 9:13
You said that "why […] would be a separate […] question". Ask a question "Why does this thingy happen?", add a little bit of detail about what the question is to the question body, then tick the box at the bottom for "post an answer as well" and answer the question like you would normally. The question's just there so you've got somewhere to write the answer.
– wizzwizz4♦
May 27 at 9:13
add a comment
|
The design of the C64 hardware makes it somewhat complex to properly disambiguate joystick and keyboard inputs. The routines in the ROM for scanning the keyboard and joystick don't address all of this complexity, but they do allow better disambiguation of joystick port 2 than 1, so developers who use that routine (or a similar one) can improve joystick/keyboard scanning in a single-joystick game by using port 2 instead of port 1. The quote in Geo's answer gives a little more high-level detail on this.
Though it's not clear from the other answers here (or in some cases they're just wrong), it is possible to do scanning of one or both joysticks and the keyboard that is either perfectly or highly probable to be interference-free. This is not trivial, however, since it involves not just writing and testing custom code to do the scanning, but also analysis and possibly slight redesign of gameplay details. (For example, whether there are certain keyboard-triggered actions that need be detected only if a joystick is being held in a certain direction.) This answer provides the information needed to do that, and should give you a sense of its level of complexity.
Lack of knowledge by the developers may sometimes explain the choice of the port 2 solution, with its downside that the user must figure out which port to use and probably unplug and replug his joystick stick, but likely more often it's simply a matter of cost-benefit: the time saved on designing a better solution to this problem can be spent on improving other areas of the game, such as adding a new feature or improving a level.
It is possible to unambiguously distinguish between joystick movement and arbitrary combinations of up to 3 keystrokes if joystick and keyboard are not used simultaneously. It will also be possible to read certain keys even when one or both joysticks are moved in arbitrary directions or combinations thereof, but not all directions can be accommodated.
– supercat
Aug 12 at 15:45
@supercat Well, to be more precise, for some keys (:
,@
, etc.) all directions (and the fire button) on both joysticks can be read simultaneously; for the rest, all directions can be read on either joystick simultaneously; the only hardware limitations arise when both joysticks are in use simultaneously, and only for certain keys that depend on which pair of joystick directions is being used. As I said in the answer, it's "not trivial" and I think that the details are the answer to a question different from this one.
– Curt J. Sampson
Aug 13 at 5:47
add a comment
|
The design of the C64 hardware makes it somewhat complex to properly disambiguate joystick and keyboard inputs. The routines in the ROM for scanning the keyboard and joystick don't address all of this complexity, but they do allow better disambiguation of joystick port 2 than 1, so developers who use that routine (or a similar one) can improve joystick/keyboard scanning in a single-joystick game by using port 2 instead of port 1. The quote in Geo's answer gives a little more high-level detail on this.
Though it's not clear from the other answers here (or in some cases they're just wrong), it is possible to do scanning of one or both joysticks and the keyboard that is either perfectly or highly probable to be interference-free. This is not trivial, however, since it involves not just writing and testing custom code to do the scanning, but also analysis and possibly slight redesign of gameplay details. (For example, whether there are certain keyboard-triggered actions that need be detected only if a joystick is being held in a certain direction.) This answer provides the information needed to do that, and should give you a sense of its level of complexity.
Lack of knowledge by the developers may sometimes explain the choice of the port 2 solution, with its downside that the user must figure out which port to use and probably unplug and replug his joystick stick, but likely more often it's simply a matter of cost-benefit: the time saved on designing a better solution to this problem can be spent on improving other areas of the game, such as adding a new feature or improving a level.
It is possible to unambiguously distinguish between joystick movement and arbitrary combinations of up to 3 keystrokes if joystick and keyboard are not used simultaneously. It will also be possible to read certain keys even when one or both joysticks are moved in arbitrary directions or combinations thereof, but not all directions can be accommodated.
– supercat
Aug 12 at 15:45
@supercat Well, to be more precise, for some keys (:
,@
, etc.) all directions (and the fire button) on both joysticks can be read simultaneously; for the rest, all directions can be read on either joystick simultaneously; the only hardware limitations arise when both joysticks are in use simultaneously, and only for certain keys that depend on which pair of joystick directions is being used. As I said in the answer, it's "not trivial" and I think that the details are the answer to a question different from this one.
– Curt J. Sampson
Aug 13 at 5:47
add a comment
|
The design of the C64 hardware makes it somewhat complex to properly disambiguate joystick and keyboard inputs. The routines in the ROM for scanning the keyboard and joystick don't address all of this complexity, but they do allow better disambiguation of joystick port 2 than 1, so developers who use that routine (or a similar one) can improve joystick/keyboard scanning in a single-joystick game by using port 2 instead of port 1. The quote in Geo's answer gives a little more high-level detail on this.
Though it's not clear from the other answers here (or in some cases they're just wrong), it is possible to do scanning of one or both joysticks and the keyboard that is either perfectly or highly probable to be interference-free. This is not trivial, however, since it involves not just writing and testing custom code to do the scanning, but also analysis and possibly slight redesign of gameplay details. (For example, whether there are certain keyboard-triggered actions that need be detected only if a joystick is being held in a certain direction.) This answer provides the information needed to do that, and should give you a sense of its level of complexity.
Lack of knowledge by the developers may sometimes explain the choice of the port 2 solution, with its downside that the user must figure out which port to use and probably unplug and replug his joystick stick, but likely more often it's simply a matter of cost-benefit: the time saved on designing a better solution to this problem can be spent on improving other areas of the game, such as adding a new feature or improving a level.
The design of the C64 hardware makes it somewhat complex to properly disambiguate joystick and keyboard inputs. The routines in the ROM for scanning the keyboard and joystick don't address all of this complexity, but they do allow better disambiguation of joystick port 2 than 1, so developers who use that routine (or a similar one) can improve joystick/keyboard scanning in a single-joystick game by using port 2 instead of port 1. The quote in Geo's answer gives a little more high-level detail on this.
Though it's not clear from the other answers here (or in some cases they're just wrong), it is possible to do scanning of one or both joysticks and the keyboard that is either perfectly or highly probable to be interference-free. This is not trivial, however, since it involves not just writing and testing custom code to do the scanning, but also analysis and possibly slight redesign of gameplay details. (For example, whether there are certain keyboard-triggered actions that need be detected only if a joystick is being held in a certain direction.) This answer provides the information needed to do that, and should give you a sense of its level of complexity.
Lack of knowledge by the developers may sometimes explain the choice of the port 2 solution, with its downside that the user must figure out which port to use and probably unplug and replug his joystick stick, but likely more often it's simply a matter of cost-benefit: the time saved on designing a better solution to this problem can be spent on improving other areas of the game, such as adding a new feature or improving a level.
answered Aug 11 at 7:20
Curt J. SampsonCurt J. Sampson
5,61916 silver badges48 bronze badges
5,61916 silver badges48 bronze badges
It is possible to unambiguously distinguish between joystick movement and arbitrary combinations of up to 3 keystrokes if joystick and keyboard are not used simultaneously. It will also be possible to read certain keys even when one or both joysticks are moved in arbitrary directions or combinations thereof, but not all directions can be accommodated.
– supercat
Aug 12 at 15:45
@supercat Well, to be more precise, for some keys (:
,@
, etc.) all directions (and the fire button) on both joysticks can be read simultaneously; for the rest, all directions can be read on either joystick simultaneously; the only hardware limitations arise when both joysticks are in use simultaneously, and only for certain keys that depend on which pair of joystick directions is being used. As I said in the answer, it's "not trivial" and I think that the details are the answer to a question different from this one.
– Curt J. Sampson
Aug 13 at 5:47
add a comment
|
It is possible to unambiguously distinguish between joystick movement and arbitrary combinations of up to 3 keystrokes if joystick and keyboard are not used simultaneously. It will also be possible to read certain keys even when one or both joysticks are moved in arbitrary directions or combinations thereof, but not all directions can be accommodated.
– supercat
Aug 12 at 15:45
@supercat Well, to be more precise, for some keys (:
,@
, etc.) all directions (and the fire button) on both joysticks can be read simultaneously; for the rest, all directions can be read on either joystick simultaneously; the only hardware limitations arise when both joysticks are in use simultaneously, and only for certain keys that depend on which pair of joystick directions is being used. As I said in the answer, it's "not trivial" and I think that the details are the answer to a question different from this one.
– Curt J. Sampson
Aug 13 at 5:47
It is possible to unambiguously distinguish between joystick movement and arbitrary combinations of up to 3 keystrokes if joystick and keyboard are not used simultaneously. It will also be possible to read certain keys even when one or both joysticks are moved in arbitrary directions or combinations thereof, but not all directions can be accommodated.
– supercat
Aug 12 at 15:45
It is possible to unambiguously distinguish between joystick movement and arbitrary combinations of up to 3 keystrokes if joystick and keyboard are not used simultaneously. It will also be possible to read certain keys even when one or both joysticks are moved in arbitrary directions or combinations thereof, but not all directions can be accommodated.
– supercat
Aug 12 at 15:45
@supercat Well, to be more precise, for some keys (
:
, @
, etc.) all directions (and the fire button) on both joysticks can be read simultaneously; for the rest, all directions can be read on either joystick simultaneously; the only hardware limitations arise when both joysticks are in use simultaneously, and only for certain keys that depend on which pair of joystick directions is being used. As I said in the answer, it's "not trivial" and I think that the details are the answer to a question different from this one.– Curt J. Sampson
Aug 13 at 5:47
@supercat Well, to be more precise, for some keys (
:
, @
, etc.) all directions (and the fire button) on both joysticks can be read simultaneously; for the rest, all directions can be read on either joystick simultaneously; the only hardware limitations arise when both joysticks are in use simultaneously, and only for certain keys that depend on which pair of joystick directions is being used. As I said in the answer, it's "not trivial" and I think that the details are the answer to a question different from this one.– Curt J. Sampson
Aug 13 at 5:47
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.
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%2f11097%2fwhy-are-c64-games-inconsistent-with-which-joystick-port-they-use%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
6
Joy port #2 tended to be more the "standard" later on. But you're right, and constantly switching the joystick port is a real detractor for the C64's usability as a pure games console. Maybe someone has a solution for this?
– Brian H
May 24 at 16:07
7
@BrianH I have a very good solution: Two joysticks. You'll need them if you want to play with a friend anyway, and in order not to have your friend accuse you of cheating, they also need to be identical.
– pipe
May 25 at 8:14