Re: [vcf-midatlantic] Known-good IBM joystick?
Bob/All, In IBM systems one typically needs the drivers, controller card, and joystick to all be designed to work together. Also, the software often expects one of a few model joystick to be available. So, in Evan's case he needs to look at the software and documentation of the program that will use the joystick to see what kind of joystick it's looking for. It may be that the original IBM PC "Game Control Adapter" is an option, in which case you'd need something compatible with that. May be easy and you can get away with a serial port joystick. And so on. From there, find something compatible, install the drivers into autoexec.bat and config.sys and go from there. Newer machines often pair a soundcard like SoundBlaster with a Microsoft joystick. Evan may have working joysticks that "don't work" because the drivers are not yet loaded. Bill On Tue, Jul 10, 2018 at 8:38 AM Bob Aviles via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
Hi, I have an IBM joystick, look at the picture and tell me if it works on your systems.
Bobby On Tuesday, July 10, 2018, 1:20:45 AM EDT, Evan Koblentz via vcf-midatlantic <vcf-midatlantic@lists.vcfed.org> wrote:
I'm having issues with the VCF supply of Kraft joysticks, and there is no time to fix them before HOPE. Does anyone have a tested and fully-working / known-good IBM (or other non-Kraft) joystick which I could borrow? I need it by Friday in order to test it at the museum this weekend. Dean said he may have one, but in case he doesn't....
My backup plan is to program for keyboard control instead of joystick control, but that's not nearly as much fun.
Most older "PC Game Port" joysticks require no drivers, for a standard 2-axis analog, up-to-4 button stick. Anything like that should "just work". Evan wouldn't want a flight stick/racing wheel/etc. that would need drivers, for the extra buttons and axes. Thanks! - Alex On Tue, Jul 10, 2018 at 9:36 AM Bill Degnan via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
Bob/All, In IBM systems one typically needs the drivers, controller card, and joystick to all be designed to work together. Also, the software often expects one of a few model joystick to be available. So, in Evan's case he needs to look at the software and documentation of the program that will use the joystick to see what kind of joystick it's looking for. It may be that the original IBM PC "Game Control Adapter" is an option, in which case you'd need something compatible with that. May be easy and you can get away with a serial port joystick. And so on. From there, find something compatible, install the drivers into autoexec.bat and config.sys and go from there. Newer machines often pair a soundcard like SoundBlaster with a Microsoft joystick.
Evan may have working joysticks that "don't work" because the drivers are not yet loaded.
Bill
On Tue, Jul 10, 2018 at 8:38 AM Bob Aviles via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
Hi, I have an IBM joystick, look at the picture and tell me if it works on your systems.
Bobby On Tuesday, July 10, 2018, 1:20:45 AM EDT, Evan Koblentz via vcf-midatlantic <vcf-midatlantic@lists.vcfed.org> wrote:
I'm having issues with the VCF supply of Kraft joysticks, and there is no time to fix them before HOPE. Does anyone have a tested and fully-working / known-good IBM (or other non-Kraft) joystick which I could borrow? I need it by Friday in order to test it at the museum this weekend. Dean said he may have one, but in case he doesn't....
My backup plan is to program for keyboard control instead of joystick control, but that's not nearly as much fun.
Anyway, I can only guess here, but since no drivers are involved, yeah, its probably the joysticks. Especially if some known good code is being used to test. In either case, yeah, Evan, it would be good to test with a known good joystick too as you requested.
OK. For some reason I thought Evan was attempting to use a newer machine. b
On 7/10/2018 11:34 AM, Bill Degnan via vcf-midatlantic wrote:
Anyway, I can only guess here, but since no drivers are involved, yeah, its probably the joysticks. Especially if some known good code is being used to test. In either case, yeah, Evan, it would be good to test with a known good joystick too as you requested.
OK. For some reason I thought Evan was attempting to use a newer machine. b Yeah, no worries, I had insider information helping with another part of this.
I'm using a Compaq Portable III (286). I forgot the card brand but I vaguely recall it might also be Kraft. I'm programming in the BASICA from the correct Compaq-branded boot disk. I use the STICK command; not PEEK/POKE. I can test the same joystick against the Apple side tomorrow. In a test program, I was only getting a range of about 5 to 195, vs. 0-255. To "port" the code from Apple to IBM platform, I replaced the Applesoft PDL(0) and PDL(1) commands with STICK. The way my code works is, when I move the stick beyond a neutral range (say, within 75 of either end), then it turns on the robot motors on the correct directions. The logic is fine: works with the Apple joystick on the Laser 128, and as I said I'll test that again with the Kraft tomorrow on the Laser. But when I tried it on the Compaq, only two of the directions work correctly. It was something like left and forward; I forget exactly. One other direction turns on the wrong bits (1 and 4, same as its opposite direction, rather than 2 and 3 which it should be), even though I'm a million percent certain the code is right. Another direction works (bits 2 and 4) if I move the stick to its extreme edge, but while en route it turns on bit 3 for a second. That makes no sense! That's why I think the stick might be funky or somehow misadjusted even if it does work on the Apple side. On Tue, Jul 10, 2018, 9:36 AM Bill Degnan via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
Bob/All, In IBM systems one typically needs the drivers, controller card, and joystick to all be designed to work together. Also, the software often expects one of a few model joystick to be available. So, in Evan's case he needs to look at the software and documentation of the program that will use the joystick to see what kind of joystick it's looking for. It may be that the original IBM PC "Game Control Adapter" is an option, in which case you'd need something compatible with that. May be easy and you can get away with a serial port joystick. And so on. From there, find something compatible, install the drivers into autoexec.bat and config.sys and go from there. Newer machines often pair a soundcard like SoundBlaster with a Microsoft joystick.
Evan may have working joysticks that "don't work" because the drivers are not yet loaded.
Bill
On Tue, Jul 10, 2018 at 8:38 AM Bob Aviles via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
Hi, I have an IBM joystick, look at the picture and tell me if it works on your systems.
Bobby On Tuesday, July 10, 2018, 1:20:45 AM EDT, Evan Koblentz via vcf-midatlantic <vcf-midatlantic@lists.vcfed.org> wrote:
I'm having issues with the VCF supply of Kraft joysticks, and there is no time to fix them before HOPE. Does anyone have a tested and fully-working / known-good IBM (or other non-Kraft) joystick which I could borrow? I need it by Friday in order to test it at the museum this weekend. Dean said he may have one, but in case he doesn't....
My backup plan is to program for keyboard control instead of joystick control, but that's not nearly as much fun.
On Tue, Jul 10, 2018 at 11:53 AM Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
I'm using a Compaq Portable III (286). I forgot the card brand but I vaguely recall it might also be Kraft. I'm programming in the BASICA from the correct Compaq-branded boot disk. I use the STICK command; not PEEK/POKE.
I can test the same joystick against the Apple side tomorrow.
In a test program, I was only getting a range of about 5 to 195, vs. 0-255.
To "port" the code from Apple to IBM platform, I replaced the Applesoft PDL(0) and PDL(1) commands with STICK.
The way my code works is, when I move the stick beyond a neutral range (say, within 75 of either end), then it turns on the robot motors on the correct directions.
The logic is fine: works with the Apple joystick on the Laser 128, and as I said I'll test that again with the Kraft tomorrow on the Laser.
But when I tried it on the Compaq, only two of the directions work correctly. It was something like left and forward; I forget exactly. One other direction turns on the wrong bits (1 and 4, same as its opposite direction, rather than 2 and 3 which it should be), even though I'm a million percent certain the code is right. Another direction works (bits 2 and 4) if I move the stick to its extreme edge, but while en route it turns on bit 3 for a second. That makes no sense! That's why I think the stick might be funky or somehow misadjusted even if it does work on the Apple side.
The BASICs are 100% compatible? You just had one change and it works on the IBM? b
The BASICs are 100% compatible? You just had one change and it works on the IBM?
Pretty much! I also changed the joystick button code. Applesoft uses a PEEK to check for button presses, BASICA uses the STRIG command. Everything else is the same. On Tue, Jul 10, 2018, 12:32 PM Bill Degnan via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
On Tue, Jul 10, 2018 at 11:53 AM Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
I'm using a Compaq Portable III (286). I forgot the card brand but I vaguely recall it might also be Kraft. I'm programming in the BASICA from the correct Compaq-branded boot disk. I use the STICK command; not PEEK/POKE.
I can test the same joystick against the Apple side tomorrow.
In a test program, I was only getting a range of about 5 to 195, vs. 0-255.
To "port" the code from Apple to IBM platform, I replaced the Applesoft PDL(0) and PDL(1) commands with STICK.
The way my code works is, when I move the stick beyond a neutral range (say, within 75 of either end), then it turns on the robot motors on the correct directions.
The logic is fine: works with the Apple joystick on the Laser 128, and as I said I'll test that again with the Kraft tomorrow on the Laser.
But when I tried it on the Compaq, only two of the directions work correctly. It was something like left and forward; I forget exactly. One other direction turns on the wrong bits (1 and 4, same as its opposite direction, rather than 2 and 3 which it should be), even though I'm a million percent certain the code is right. Another direction works (bits 2 and 4) if I move the stick to its extreme edge, but while en route it turns on bit 3 for a second. That makes no sense! That's why I think the stick might be funky or somehow misadjusted even if it does work on the Apple side.
The BASICs are 100% compatible? You just had one change and it works on the IBM? b
Question, what you need is an Apple joystick? because I have some. Bobby On Tuesday, July 10, 2018, 12:40:07 PM EDT, Evan Koblentz via vcf-midatlantic <vcf-midatlantic@lists.vcfed.org> wrote:
The BASICs are 100% compatible? You just had one change and it works on the IBM?
Pretty much! I also changed the joystick button code. Applesoft uses a PEEK to check for button presses, BASICA uses the STRIG command. Everything else is the same. On Tue, Jul 10, 2018, 12:32 PM Bill Degnan via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
On Tue, Jul 10, 2018 at 11:53 AM Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
I'm using a Compaq Portable III (286). I forgot the card brand but I vaguely recall it might also be Kraft. I'm programming in the BASICA from the correct Compaq-branded boot disk. I use the STICK command; not PEEK/POKE.
I can test the same joystick against the Apple side tomorrow.
In a test program, I was only getting a range of about 5 to 195, vs. 0-255.
To "port" the code from Apple to IBM platform, I replaced the Applesoft PDL(0) and PDL(1) commands with STICK.
The way my code works is, when I move the stick beyond a neutral range (say, within 75 of either end), then it turns on the robot motors on the correct directions.
The logic is fine: works with the Apple joystick on the Laser 128, and as I said I'll test that again with the Kraft tomorrow on the Laser.
But when I tried it on the Compaq, only two of the directions work correctly. It was something like left and forward; I forget exactly. One other direction turns on the wrong bits (1 and 4, same as its opposite direction, rather than 2 and 3 which it should be), even though I'm a million percent certain the code is right. Another direction works (bits 2 and 4) if I move the stick to its extreme edge, but while en route it turns on bit 3 for a second. That makes no sense! That's why I think the stick might be funky or somehow misadjusted even if it does work on the Apple side.
The BASICs are 100% compatible? You just had one change and it works on the IBM? b
On Tue, Jul 10, 2018 at 12:49 PM Douglas Crawford via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
If you are getting the same behavior from multiple joysticks, I'd fault the card or the code. (Unless of course these somehow aren't joysticks compatible with the card...)
The bits talked about here I assume are part of your logic, not the related to the stick command.
"But when I tried it on the Compaq, only two of the directions work correctly. It was something like left and forward; I forget exactly. One other direction turns on the wrong bits (1 and 4, same as its opposite direction, rather than 2 and 3 which it should be), even though I'm a million percent certain the code is right. Another direction works (bits 2 and 4) if I move the stick to its extreme edge, but while en route it turns on bit 3 for a second. That makes no sense! That's why I think the stick might be funky or somehow misadjusted even if it does work on the Apple side."
This sounds vaguely like the variable clobbering you had last year with the first lego code you were working on last year when you thought there was a bug in BASIC. Can you post the code?
Have you tried a simple test program for the joystick by itself to prove in fact the joystick is working right or not?
Having taught a class that included the differences in BASIC between different systems did they provide in their code samples a comparison chart of "if IBM do this" , "if Apple do that"? I assume you know and found all platform-centric code. I may have in my slide presentation a chart with common differences, but there are subtle little things. b
On 7/10/2018 1:06 PM, Bill Degnan via vcf-midatlantic wrote:
On Tue, Jul 10, 2018 at 12:49 PM Douglas Crawford via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
If you are getting the same behavior from multiple joysticks, I'd fault the card or the code. (Unless of course these somehow aren't joysticks compatible with the card...)
The bits talked about here I assume are part of your logic, not the related to the stick command.
"But when I tried it on the Compaq, only two of the directions work correctly. It was something like left and forward; I forget exactly. One other direction turns on the wrong bits (1 and 4, same as its opposite direction, rather than 2 and 3 which it should be), even though I'm a million percent certain the code is right. Another direction works (bits 2 and 4) if I move the stick to its extreme edge, but while en route it turns on bit 3 for a second. That makes no sense! That's why I think the stick might be funky or somehow misadjusted even if it does work on the Apple side."
This sounds vaguely like the variable clobbering you had last year with the first lego code you were working on last year when you thought there was a bug in BASIC. Can you post the code?
Have you tried a simple test program for the joystick by itself to prove in fact the joystick is working right or not?
Having taught a class that included the differences in BASIC between different systems did they provide in their code samples a comparison chart of "if IBM do this" , "if Apple do that"? I assume you know and found all platform-centric code. I may have in my slide presentation a chart with common differences, but there are subtle little things. b
Its a good point. A review by someone who could spot such likely problem areas would be a good idea..
I know anyone can make mistakes, but .... I am VERY confident in my code this time around. :) Alas, I don't have the actual IBM code here at home. The joystick routine in my (perfectly working) Applesoft code is: -------------------------- 3000 REM NAVIGATION 3010 FB = PDL (1):LR = PDL (0):M = 0: REM SET VARIABLES 3020 IF FB < 75 THEN M = 5 3030 IF FB > 180 THEN M = 10 3040 IF LR < 75 THEN M = 9 3050 IF LR > 180 THEN M = 6 3060 POKE L,M: REM SEND COMMANDS 3070 IF M = 10 THEN CALL - 198: FOR W = 1 TO 500: NEXT W: REM BACKUP ALERT 3080 RETURN -------------------------- I made two changes for the IBM side: 3010 FB=STICK(1):LR=STICK(0):M=0: REM SET VARIABLES 3060 OUT P,M: REM SEND COMMANDS Both lines are correct. No room for gray area there. I omitted line 3070 for now. It makes the backup beep when the robot goes in reverse. :) I'll add an IBM version back in after I get the navigation working again. I don't have time now to explain to everyone how the Lego system works, but anyone who's interested is welcome to examine the relevant pages of my under-construction web site about this subject. :) http://www.snarc.net/mbts/applebasic.htm http://www.snarc.net/mbts/direct.htm
Retrieve STICK(0) first. STICK(0) will sample all the joystick values and return the x-coordinate of joystick A. STICK(1) returns the y-coordinate of joystick A that it found last time STICK(0) was called. https://archive.org/stream/IBMBASICAV1.10Manual/IBM%20BASICA%20v1.10%20Manua... Also, are you sure the values go from 0-255 like they do on the Apple? In particular, if it's only, say, returning 0-100, then it's never going to be more than 180, and it's likely to go the other way when in an auto-entered resting state. -Paul
On Jul 10, 2018, at 1:34 PM, Evan Koblentz via vcf-midatlantic <vcf-midatlantic@lists.vcfed.org> wrote:
I know anyone can make mistakes, but .... I am VERY confident in my code this time around. :)
Alas, I don't have the actual IBM code here at home.
The joystick routine in my (perfectly working) Applesoft code is:
--------------------------
3000 REM NAVIGATION 3010 FB = PDL (1):LR = PDL (0):M = 0: REM SET VARIABLES 3020 IF FB < 75 THEN M = 5 3030 IF FB > 180 THEN M = 10 3040 IF LR < 75 THEN M = 9 3050 IF LR > 180 THEN M = 6 3060 POKE L,M: REM SEND COMMANDS 3070 IF M = 10 THEN CALL - 198: FOR W = 1 TO 500: NEXT W: REM BACKUP ALERT 3080 RETURN
--------------------------
I made two changes for the IBM side:
3010 FB=STICK(1):LR=STICK(0):M=0: REM SET VARIABLES
3060 OUT P,M: REM SEND COMMANDS
Both lines are correct. No room for gray area there.
I omitted line 3070 for now. It makes the backup beep when the robot goes in reverse. :) I'll add an IBM version back in after I get the navigation working again.
I don't have time now to explain to everyone how the Lego system works, but anyone who's interested is welcome to examine the relevant pages of my under-construction web site about this subject. :)
http://www.snarc.net/mbts/applebasic.htm http://www.snarc.net/mbts/direct.htm
Retrieve STICK(0) first. STICK(0) will sample all the joystick values and return the x-coordinate of joystick A. STICK(1) returns the y-coordinate of joystick A that it found last time STICK(0) was called.
I'll check tomorrow (when I am back at the museum) to see the order I used. If it's not 0 first then I will change it.
Well that is mighty simple. So if you speak the truth, your PC subroutine becomes: 3000 REM NAVIGATION 3010 FB=STICK(1):LR=STICK(0):M=0: REM SET VARIABLES 3020 IF FB < 75 THEN M = 5 3030 IF FB > 180 THEN M = 10 3040 IF LR < 75 THEN M = 9 3050 IF LR > 180 THEN M = 6 3060 OUT P,M: REM SEND COMMANDS 3070 REM IF M = 10 THEN CALL - 198: FOR W = 1 TO 500: NEXT W: REM BACKUP ALERT 3080 RETURN Is P set somewhere? It should be the port number of the interface... and is it definitely not being clobbered somewhere? That would be a difference you would not notice on the Apple side since it uses L instead of P. And this is obviously a subroutine, so there could be other areas of the code that are not portable between the PC and Apple. For instance, all the pokes shown on the web page won't work: These poke into Apple memory space where the card is mapped; not the same on the PC. 1000 REM Activate the Lego interface card 1010 S = 7:L = 49280 + S * 16 1020 POKE L + 3,1: POKE L + 2,63: POKE L + 1,0 1030 POKE L,0: REM CLEAR ALL PORTS 1040 RETURN You may know this, I'm only saying because you indicated in some words that the code "was the same". Maybe you meant the "algorithm" is the same, and maybe the variable names are the same... I can't be sure, but this code won't work as is on the PC. On 7/10/2018 1:34 PM, Evan Koblentz via vcf-midatlantic wrote:
I know anyone can make mistakes, but .... I am VERY confident in my code this time around. :)
Alas, I don't have the actual IBM code here at home.
The joystick routine in my (perfectly working) Applesoft code is:
--------------------------
3000 REM NAVIGATION 3010 FB = PDL (1):LR = PDL (0):M = 0: REM SET VARIABLES 3020 IF FB < 75 THEN M = 5 3030 IF FB > 180 THEN M = 10 3040 IF LR < 75 THEN M = 9 3050 IF LR > 180 THEN M = 6 3060 POKE L,M: REM SEND COMMANDS 3070 IF M = 10 THEN CALL - 198: FOR W = 1 TO 500: NEXT W: REM BACKUP ALERT 3080 RETURN
--------------------------
I made two changes for the IBM side:
3010 FB=STICK(1):LR=STICK(0):M=0: REM SET VARIABLES
3060 OUT P,M: REM SEND COMMANDS
Both lines are correct. No room for gray area there.
I omitted line 3070 for now. It makes the backup beep when the robot goes in reverse. :) I'll add an IBM version back in after I get the navigation working again.
I don't have time now to explain to everyone how the Lego system works, but anyone who's interested is welcome to examine the relevant pages of my under-construction web site about this subject. :)
http://www.snarc.net/mbts/applebasic.htm http://www.snarc.net/mbts/direct.htm
Well that is mighty simple. So if you speak the truth, your PC subroutine becomes:
3000 REM NAVIGATION 3010 FB=STICK(1):LR=STICK(0):M=0: REM SET VARIABLES 3020 IF FB < 75 THEN M = 5 3030 IF FB > 180 THEN M = 10 3040 IF LR < 75 THEN M = 9 3050 IF LR > 180 THEN M = 6 3060 OUT P,M: REM SEND COMMANDS 3070 REM IF M = 10 THEN CALL - 198: FOR W = 1 TO 500: NEXT W: REM BACKUP ALERT 3080 RETURN
Yep.
Is P set somewhere?
Yes, it's set at the start of the program in the card initialization routine.
and is it definitely not being clobbered somewhere? That would be a difference you would not notice on the Apple side since it uses L instead of P.
Nope it's all good.
And this is obviously a subroutine, so there could be other areas of the code that are not portable between the PC and Apple. For instance, all the pokes shown on the web page won't work: These poke into Apple memory space where the card is mapped; not the same on the PC.
1000 REM Activate the Lego interface card 1010 S = 7:L = 49280 + S * 16 1020 POKE L + 3,1: POKE L + 2,63: POKE L + 1,0 1030 POKE L,0: REM CLEAR ALL PORTS 1040 RETURN
That's the Apple code. The IBM init code is here: http://www.snarc.net/mbts/ibmbasic.htm ... I am on top of all this. :)
Today's updates on the joystick saga: - I confirmed that the same joystick I was using works fine on an Apple II. - VCFed owns about a half-dozen combo Apple/IBM joysticks, but they're all the same kind. - I tried Paul's suggestion of checking STICK(0) first. Unfortunately it did not help. - I temporarily programmed the robot to move based on keyboard input (I, J, K, M). I'll program the buttons next time; already know how. Will probably use U and O. - The way the logic works, if you keep the joystick held in one position, the robot keeps moving until you release it. The same logic does not work for the keyboard control: I can tell because the interface box LEDs flash rather than stay solid. That would lead to the motors stuttering. No time to diagnose that, so I removed the opening M=0 which put the robot in a state of constant movement (press a key, the motors stay on, rather than having to hold down the key) -- and thus I had to add the space bar as a brake (pressing it resets M to zero). So now I have a working demo. It works the opposite of the Apple control method. I could tell people that's by design to show two different ways :) but I think what I really need is a known-good IBM-only joystick to test it with my preferred (original) way. Somebody on this list has to have one!! Does anybody have one they can loan me? I would need it ASAP in order to test it by next Wednesday (my final time at the museum before HOPE).
I think what I really need is a known-good IBM-only joystick to test it with my preferred (original) way. Somebody on this list has to have one!! Does anybody have one they can loan me? I would need it ASAP in order to test it by next Wednesday (my final time at the museum before HOPE).
Hmmm .... I'm reluctant to buy one, but they are extremely cheap on eBay.
On 7/10/2018 11:53 AM, Evan Koblentz via vcf-midatlantic wrote:
In a test program, I was only getting a range of about 5 to 195, vs. 0-255.
Unless you have a really, REALLY good joystick, you probably won't get the full 0-255 range for either X or Y no matter what, and depending on how the joystick's motion is restricted, you won't be able to even hit the corners fully. This is why many dos games had an option to calibrate the joystick, to set its center postion and the lower left/upper right positions which would roughly correspond to min x min y and max x max y, then take those value and scale them to the desired range with some math. It is also not a bad idea to compensate for the joystick having a 'dead zone' near the center where putting no significant force on the joystick makes it move within a small range, software should compensate and consider the joystick centered unless it leaves that 'dead zone' -- Jonathan Gevaryahu jgevaryahu@gmail.com jgevaryahu@hotmail.com
participants (7)
-
Bill Degnan -
Bob Aviles -
Douglas Crawford -
Evan Koblentz -
Hagstrom, Paul -
J. Alexander Jacocks -
Jonathan Gevaryahu