Here is a simple BASIC listing to test potentiometers attached to your C64. This is for everone who doesn't have the P64 cart on hand nor the ability to transfer .D64 images of other pot monitors to real floppy.
Derived from Ray Carlsen's C64/128 Control (joystick) Ports - Diagnostics and Repair article, it displays the four POT values in a row like this:
X1: 13 Y1: 10 X2: 255 Y2: 1
Not too fancy but doing its job
10 REM POT TESTING 20 POKE 56333,127: REM TURN OFF KBD 30 POKE 56320,64: REM SWITCH POT#1 40 PRINT TAB(1)"X1:"PEEK(54297); 50 PRINT TAB(11)"Y1:"PEEK(54298); 60 POKE 56320,128: REM SWITCH POT#2 70 PRINT TAB(21)"X2:"PEEK(54297); 80 PRINT TAB(31)"Y2:"PEEK(54298) 90 POKE 56333,129: REM TURN ON KBD 100 GOTO 20
Feel free to discard the REM comments, but keep shure to enter the semicolons in lines 40, 50, 70 or your screen output will be garbled! You'll have to RUN/STOP-RESTORE to exit the program loop.
It's working good on a real C64 but doesn't go well on my emulator (Power64 - not supposed to work with 2 sets of paddles at all. Dunno if other emulators would support four pots.).
Offline
As far as i remember you can also use your joystick port on PC with an emulator to connect paddles. But i don't know which emulators support it.
Offline
Interesting. The Commodore 64 Programmer's Reference Guide (Page 346) states:
PADDLES ARE NOT RELIABLE WHEN READ FROM BASIC ALONE!!!!
Yes, it's in all caps and with four exclamation marks in the book.
Here is their paddle-reader. Notice the FOR/NEXT with READ and POKE to enter machine language DATA from within BASIC.
I assume the method of flip-flopping the keyboard off and on is to avoid interference with the control ports. If it's accurate, sweet! Ray Carlsen beats the Commodore programmers!
10 C=12*4096:REM SET PADDLE ROUTINE START 11 REM POKE IN THE PADDLE READING ROUTINE 15 FORI=0TO63:READA:POKEC+I,A:NEXT 20 SYSC:REM CALL THE PADDLE ROUTINE 30 P1=PEEK(C+257):REM SET PADDLE ONE VALUE 40 P2=PEEK(C+258):REM SET PADDLE TWO VALUE 50 P3=PEEK(C+259):REM SET PADDLE THREE VALUE 60 P4=PEEK(C+260):REM SET PADDLE FOUR VALUE 61 REM READ FIRE BUTTON STATUS 62 S1=PEEK(C+261):S2=PEEK(C+262) 70 PRINTP1,P2,P3,P4:REM PRINT PADDLE VALUES 72 REM PRINT FIRE BUTTON STATUS 75 PRINT:PRINT"FIRE A ";S1,"FIRE B ";S2 80 FORW=1TO50:NEXT:REM WAIT A WHILE 90 PRINT"{CLEAR}":PRINT:GOTO20:REM CLEAR SCREEN AND DO AGAIN 95 REM DATA FOR MACHINE CODE ROUTINE 100 DATA162,1,120,173,2,220,141,0,193,169,192,141,2,220,169 110 DATA128,141,0,220,160,128,234,136,16,252,173,25,212,157 120 DATA1,193,173,26,212,157,3,193,173,0,220,9,128,141,5,193 130 DATA169,64,202,16,222,173,0,193,141,2,220,173,1,220,141 140 DATA6,193,88,96
Offline
fj4 wrote:
Interesting. The Commodore 64 Programmer's Reference Guide (Page 346) states:
PADDLES ARE NOT RELIABLE WHEN READ FROM BASIC ALONE!!!!
Yes, it's in all caps and with four exclamation marks in the book.
Well, depending on what tasks your program is running besides reading the POT values, a machine language routine _is_ much more reliable. The BASIC way is fine for basic applications, like my simple filter application.
Of course, there're various techniques to read the POT state, I just contibuted my listing for the sake of portability, it's short enough to quickly type in. Ray's listing (since he fixed some faulty addresses two days ago) is good for testing the port, but value display doesn't overwrite empty digits, resulting in odd numbers written on the screen.
Ray Carlsen wrote:
It was the easiest way to tell, as long as the digits are moving, that the lines are working... no matter what the values are. With the periferal unplugged, the lines should all go to their resting values. If they get "stuck", there's a problem. I'm sure there are better ways to do it, but that was the limit of my knowledge at the time.
POKEing spaces into the screen addresses where the values are displayed before printing the new ones would get rid of that problem. But the intention of my listing was to get it short, so I went for the scrolling (which Ray didn't like due to the flashing characters...).
fj4 wrote:
I assume the method of flip-flopping the keyboard off and on is to avoid interference with the control ports.
Exactly!
fj4 wrote:
If it's accurate, sweet! Ray Carlsen beats the Commodore programmers!
Well, check this out:
Ray Carlsen wrote:
I'm supposed to be some kind of guru, but I'm just a working slug that, years ago, saw the need to get technical information out there when I couldn't be around to answer questions. As I mentioned before, I'm a hardware guy. I've been a repair tech all my life. I'd rather be inside the box diddling around with the electronics than pounding the keys on the outside. Any programming "skills" I have are hard earned and are mostly used to help me learn about the hardware and to make it easier for others to fix their equipment. I'm really a novice at even so simple a language as BASIC. I wish I had the time to
go further, but you know how that goes... gotta feed my family first. :-
He really is a nice guy
Offline
Thanks for the listing ron. The components in my half-built breakout box are working OK. Just waiting for a console box to put it all in now.
It's also the first listing I've ever typed in to a C64!
Offline
Not quite; I had a BBC Micro.
Offline