problems calibrating light pen in BASIC

[ruthven]

Ok, this is kind of late for me to bring this up as I first started a thread on this a couple years ago...  I had asked how to read a light pen in BASIC--and I thought I had gotten it to work--somewhat anyway; I didn't get to delve into it and then other things came up that made me forget about this little project for a while...  So I tried to get it fully working the other night in a simple BASIC program that constantly checks the status of the pen's X,Y coordinates and prints them on the screen.  Theoretically, the numbers that are displayed should be constantly changing as I move the pen around the screen, but it only seems to read a particular coordinate every now and then at random (i.e. most of the time the screen displays zeros for the X and Y coordinates--once in a while it quickly picks up where the pen actually is on the screen and displays a proper X,Y value but quickly goes back to zeros again).

The light pen I use is a "Madison Computer McPen"--I'm hoping someone here has some experience with this particular pen or a similar one...  it's a little different from other light pens in that the pen itself doesn't just plug directly into the joystick port; rather it plugs into it's own base (that acts as a pen holder) via a DIN-like plug, and the base plugs into the joystick port.  The base has a dial for sensitivity control and also a light that comes on when the computer is powered on.

According to the instructions on the bottom of the base, the light is supposed to come on when the computer is first powered on.  It then needs to be "calibrated" in a sense, in that the pen needs to be held 1/2 an inch from the screen with the sensitivity turned all the way down, then slowly raising the sensitivity until the light on the base goes out.  Here's where the problem lies--even setting the sensitivity at max, that light on the base never goes out.  I've even set the background color to white and turned the brightness all the way up while calibrating the sensitivity with no effect.

Occassionally the light on the base will go out briefly when I touch the pen on the screen--at this moment my program will report an actual X,Y coordinate (something other than 0,0).  But it doesn't continue to display that X,Y coordinate as I hold the pen against the screen--only for that initial moment that I first touched the pen to the screen, then quickly goes back to zeros even though I'm still holding the pen against the screen (in the same exact spot even).

Maybe this is because the sensitivity control hasn't been properly calibrated--but to aid me in this, can anyone who's familiar with the McPen just tell me: is the light on the base supposed to be on when the pen isn't touching the screen, and then go out when it is?--this seems to be the case with mine as my program displays coordinates of 0,0 as long as the base light is on (pen is not in use), and then when I touch the pen against the screen the light goes out and a coordinate is displayed.  This operation seems backwards from the way the instructions make it sound (in other words, I thought the light is supposed to go out once calibrated and only light up when the pen makes contact with the screen)...(?)

Thanks for reading.

[BigDumbDinosaur]

I've never heard of the McPen, but I can tell you that past experience taught me that getting accurate light pen coordinates from BASIC can be tricky due to the lag from the time the electron beam passes under the pen until BASIC has gotten the coordinates from the VIC or VDC and processed them.  Under the right circumstances, the coordinates returned by BASIC will be substantially incorrect.

Something else to consider is that (again from past experience) some light pens don't respond well to some colors.  High contrast combinations work best, such as cyan on a black background.  It's all trial and error.

[RobertB]

The light pen I use is a "Madison Computer McPen"--I'm hoping someone here has some experience with this particular pen...

Yes, I have that light pen.

According to the instructions on the bottom of the base, the light is supposed to come on when the computer is first powered on.  It then needs to be "calibrated" in a sense, in that the pen needs to be held 1/2 an inch from the screen with the sensitivity turned all the way down, then slowly raising the sensitivity until the light on the base goes out.

Heh, I did it the other way.  I set the sensitivity dial all the way up and then brought it down until the light flickered off.

Here's where the problem lies--even setting the sensitivity at max, that light on the base never goes out.

I do not really set any faith in the flickering LED.  If the program I'm using with the light pen (whether it is Picasso's Revenge, Koala Painter, or other) is not responding, then I turn up the dial until it responds. 

          FCUG celebrating 30 years,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

[bacon]

Are you sure the cable between the pen and the base isn't broken? That could explaing why works intermittently - sometimes all wires are connected, most of the time they aren't.

[ruthven]

Thanks guys.

Yes, I have that light pen.

I thought it was you who had said you'd used the McPen before and I was hoping you'd chime in!

Heh, I did it the other way.  I set the sensitivity dial all the way up and then brought it down until the light flickered off.

Interesting... do you hold the pen a 1/2 inch away from the monitor while you're adjusting the control, or do you actually touch the screen with it?  For me, no matter how close the pen is to the screen, if it's not actually touching the screen then the light stays on--no matter what the sensitivity is set to.  Generally, as soon as I touch the screen the light will go out (and my program reports coordinates), but it does not always continuously report coordinates when I hold the pen against the screen for a period of time (in other words, the light comes back on even though I'm still holding the pen against the screen and the program goes back to displaying zeros).  This is where the sensitivity control seems to help--on just the right setting, it seems to produce a quick flickering as I hold it against the screen (rather than the light just going out completely).  On this setting the pen seems to function more accurately within my program--the coordinates are updated much more consistently, not perfect--I still see the occasional zeros, but other numbers most of the time.

So perhaps I've got it working now--the remaining imperfections are likely caused by the lag time of BASIC itself.  Also, my program uses BASIC 7's PEN command to check coordinates; I wonder if PEEKing the appropriate addresses would be quicker/more efficient... perhaps compiling the program would improve it's performance as well.

I suppose the best way to make sure the pen is working properly is to test it with a drawing program.  I have Koala Painter but I cannot figure out how to select the light pen for input.  Can someone tell me what port it needs to be plugged into/what key stroke has to be made in the program to activate it?   

On a side note, I'm sure my monitor could use a good cleaning.. I'm wondering what should be used to clean a CRT screen?  I'm sure there's special solutions on the market, but will a water-dampened rag do the trick?  (I once cleaned my CRT TV with Windex and my friend told me I shouldn't have done it--that Windex can degauss the screen)

[RobertB]

Interesting... do you hold the pen a 1/2 inch away from the monitor while you're adjusting the control, or do you actually touch the screen with it?

I actually touch the screen with it.

I suppose the best way to make sure the pen is working properly is to test it with a drawing program.

Yes, that would be best.

I have Koala Painter but I cannot figure out how to select the light pen for input.  Can someone tell me what port it needs to be plugged into/what key stroke has to be made in the program to activate it?

You have to make sure that you have Koala Painter for the Koala pen.  (I found the Koala pen to be garbage, and the McPen, Flexidraw pen, and Picasso's Revenge pen to be better or much better.)  Without digging out the package, I believe it was port 1, and the key to activate it was either the C=, Control, or 1 key.

On a side note, I'm sure my monitor could use a good cleaning.. I'm wondering what should be used to clean a CRT screen?  I'm sure there's special solutions on the market, but will a water-dampened rag do the trick?

Yes.

(I once cleaned my CRT TV with Windex and my friend told me I shouldn't have done it--that Windex can degauss the screen)

I don't see how an ammonia-based cleaner, like Windex, can affect the magnetic field on the screen.  IOW, Windex should be fine, unless your screen has an anti-glare coating on it; if that's the case, Windex could remove the coating.

          FCUG celebrating 30 years,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

[ruthven]

Thanks RobertB.  I'll have to give the screen a good cleaning when I get home.  Then I'll try to find the "Koala Pen" version of Koala Painter.  I've left the sensitivity control set to where it was working best in my program last night, so hopefully it will be good to go.

Ultimately I don't care so much about drawing lines on the screen with a light pen, however using the pen as a control device for my BASIC programs makes retro programming seem cooler than ever!

[gsteemso]

Considering we had light pens from at least the early 80s, it seems odd we had to wait for Palmpilots etc for pen-based computer interfaces to take off. :¬)


Now there’s a project… implementing a Palm-like interface on a Commodore… :¬D


PS: Ruthven, I’m pretty sure light pens will only work in port 1 regardless of other considerations, because port 2 doesn't have the connection to that detection circuit. Anyone know if I’m remembering that correctly?

[Hydrophilic]

PS: Ruthven, I’m pretty sure light pens will only work in port 1 regardless of other considerations, because port 2 doesn't have the connection to that detection circuit. Anyone know if I’m remembering that correctly?

You remember correctly.

Also, my program uses BASIC 7's PEN command to check coordinates; I wonder if PEEKing the appropriate addresses would be quicker/more efficient... perhaps compiling the program would improve it's performance as well.

You do not want to use PEEK, because you can get mixed values -- X could come from one sample and Y could come from a different sample.  The PEN command will latch both X and Y simultaneously.  There shouldn't be any lag in the PEN command itself, as it simply reads the VIC registers from the last time a value was latched.  Of course the rest of the program may be too slow, in which case compiling would help.

One strange thing about PEN, is it can tell you when new values are available for the VDC, but not for the VIC.  I think this is because the VIC can be safely polled during IRQs while the VDC can not.

Anyway, in BASIC there are two methods to determine when a new PEN value is latched.  The first is the way it was designed.  Use COLLISION to specify a BASIC subroutine to execute when a new PEN value appears.  This is equivalant to writing IRQ code in BASIC.  Anyone with IRQ code experience knows this can be tricky, and putting this method into interpretted BASIC is very questionable to me.

Another method is polling.  You can check $11EA, via PEEK(4586).  If the value is 0, then no new value has been latched since last time you used PEN(1).  Because PEN values are sprite co-ordinates, 0 would be way above the top of the screen, so you can be sure it is not a real value.  Also note the $11EA value gets reset to 0 only when you use PEN(1) to read the last value latched.

Well, I hope some of that was helpful.  More importantly, I hope I didn't confuse you!

[ruthven]

<blockquote>

PS: Ruthven, I’m pretty sure light pens will only work in port 1 regardless of other considerations, because port 2 doesn't have the connection to that detection circuit. Anyone know if I’m remembering that correctly?

You remember correctly.

</blockquote>
Good, so that explains why it wasn't working in port 2.

Well, I hope some of that was helpful.  More importantly, I hope I didn't confuse you!

Very helpful, thanks!  I'm sure I'm bound to get confused once I start actually trying to implement these routines into my program... but it's good to have this information posted so I can refer back to it.  Unfortunately I'm still unable to properly test my lightpen as I can't get Koala Painter to work.  I've downloaded 3 or 4 different copies of the lightpen version, but they all crash--they start with a loading screen, then the screen clears to blue, then goes to a white screen with a grey border and hangs there.  When it hangs, the red light on the disk drive stays on after the disk stops spinning; this makes me suspect that it errored out, but is this just the drawing screen?--I tried drawing on the screen but no effect.

I would like to get this program working just to test the lightpen and make sure it's working properly before I start some complex BASIC program with it.  I downloaded every copy of the Koala Painter for lightpen I could find on Poke Finder--I couldn't find this program anywhere else on the net; all produced the results I described.  Of course, I'm not necessarily locked down to this particular program if someone can recommend another that uses a lightpen..(?)  I couldn't find a downloadable copy of Picasso's Revenge.

[RobertB]

I downloaded every copy of the Koala Painter for lightpen I could find on Poke Finder--I couldn't find this program anywhere else on the net; all produced the results I described.  Of course, I'm not necessarily locked down to this particular program if someone can recommend another that uses a lightpen..(?)  I couldn't find a downloadable copy of Picasso's Revenge.

Hmm, the Flexidraw lightpen program does not seem to be a Pokefinder; however, Micro Illustrator is there at

http://ftp.pokefinder.org/index.php?s=micro+illustrator&m=0&h=100

          Try those with the lightpen,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

[ruthven]

Thanks, but once again it seems I can only find the joystick version.  Is there a particular key combination I need to hit to activate the pen?  Or is there a special lightpen version of Micro Illustrator as well?  None of the Micro Illustrator downloads at Poke Finder specify "lightpen".  Actually I was only able to download from 3 of the links anyway, the rest required a login.  The startup program file within the .D64 I got is actually called "micro ill.joy" leading me to believe it is the joystick version.  The other copy I downloaded is a single file, "microill.prg"--it has the same title screen as the other one, specifying to plug a joystick in port 2--so I think this is the same version.

The only other copy I was able to download from Poke Finder is a .G64 file--I'm not sure if I can access this type of file--aren't these for 1571 drives only?

[RobertB]

     Well, heck... it seems that the joystick or pad versions are not on-line (as in the case of Edumate's Peripheral Vision a.k.a. Picasso's Revenge).  O.K., try the Flexidraw link at

http://www.emuparadise.org/Commodore_64_Preservation_Project_ROMs/%5BProgram%5D_Flexidraw_5.5_(UE)/71158#Download

          FCUG celebrating 30 years,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

[ruthven]

Oh man, sorry to keep bugging you but I'm stumped again... that download is a zip file containing two .NIB files..  I'm unfamiliar with this format--can Star Commander transfer these files or can it be converted to a .D64?  Also, I notice it's size is 336K whereas the .D64s I usually deal with are 171K; is this a DS DD image that requires a 1571 to read both sides?

[Hydrophilic]

Boy you sure are having a lot of trouble finding a working program, LOL.  The G64 files are 1541 disk images in raw GCR format.  This preserves an exact copy of the disk data.  It is supported by VICE.  As for others...

   
• Star Commander documentation says it supports GCR Format (but does not list a file type, like G64) and it also says "Comming Soon... GCR support" so who knows?
• According to the project page, G64 is not supported by CBM-Command, but Payton Byrd could tell you for sure.
• According to the info page, G64 is not supported by 64HDD.
• I don't think the uIEC supports G64 either (the info page is very vague); my device does not, but I don't have the latest firmware...

I have no idea what a NIB file is, but it sounds like it might be a GCR version as well.  All the G64 disk images I have are 326 KB, which is almost what you reported (336... umm... a typo?)

FYI, the D64 images are "cooked" versions of GCR data.  This makes for smaller file size and faster transcoding, but is not good enough for all disk images (in particular, those with "extreme" copy protection), so that is the reason for the G64 format.

Sorry I don't have a link to a good light pen program for you, but maybe some of this info is usefull.

[ruthven]

Boy you sure are having a lot of trouble finding a working program, LOL.

No kidding!--Seems like I'm spending days just to find a program that I may only use once for 20 seconds just to see whether my lightpen works or not!     Hope I'm not putting anyone out of their way looking for some art program--I never imagined it would be so difficult to find an archived lightpen program with all the resources on the net--and I'm more than willing to do the leg work on the net if anyone can just list me some other titles that use a lightpen.

Thanks for the info on .G64s.  Interesting--the main program file within the .D64 image of Koala Painter is only around 75K, and there are only a few other files--all between 5 and 10K.  Yet the .G64 image I downloaded is somewhere around (if not exactly) 326K.  I wonder if there's anything extra packed into this image (perhaps a cracked copy protection) that will help me get it up and running.  I'll see if Star Commander can read that .G64 when I get home today.  If not, I'll try to find some converter program.  And if it all fails then I'll probably just give up at this point--and go straight to programming it (or attempting to anyway).

As to the .NIB files--yes, they are 336K--I was looking at the opened .zip file in WinRAR while I typed my last post.  I wasn't sure if I had run across this extension for Commodore--each old computer system has so many associated image formats--I've delved into so many old computers in such rapid succession that I often forget which ones are which!  But I do remember that .NIB is an extension used in certain Apple II archives--maybe the link for Flexidraw is actually an Apple II version.

[BigDumbDinosaur]

One strange thing about PEN, is it can tell you when new values are available for the VDC, but not for the VIC.  I think this is because the VIC can be safely polled during IRQs while the VDC can not.

Who says you can't poll the VDC during an IRQ?  As long as you first sniff the stack to verify that the screen kernel isn't in the middle of a VDC access, there's no conflict.  The part of Clock-Calendar 128 that drives the status line does so during IRQs and it does work. 

[Hydrophilic]

BDD, I thought you would mention that!  Well, you can poll the VDC during an IRQ if you know it is not in use by another thread.  If the user only access the VDC through KERNAL routines, and if you sniff the stack for relevant KENRAL address, then it is possible.  But that is to many ifs for me, and apparently, the BASIC authors.

Well, I guess you could also set up a "I am accessing the VDC" flag, but that is not made available by the KERNAL or BASIC either.

So the way the system was designed, it is not safe to poll the VDC during IRQs.  But I still wonder why they didn't make a PEN() command to tell when the VIC gets a new value.  The PEEK method I mentioned is a bit of a hack more suited to the C64 or VIC-20.

ruthven, the reason a .G64 is is normally 326K is because it has all the data of the disk, in GCR format, even if only some of them are used.  A similar thing is true with .D64 which will normally be 170K no matter if it contains only a single 1 block file.  A .D64 is about half the size of .G64 because the data is binary (not GCR), and the recording speed, sync marks, sector headers, and sector gaps are missing.

You normally only find images in .G64 format if they have copy protection that hasn't been cracked.  Once the protection is broken, it should be possible to put it on a .D64 ... this is not to say the all .D64 are cracked versions, as many lame copy protection schemes can be emulated with the .D64 "error code extensions"

[bacon]

ruthven, the reason a .G64 is is normally 326K is because it has all the data of the disk, in GCR format, even if only some of them are used.  A similar thing is true with .D64 which will normally be 170K no matter if it contains only a single 1 block file.  A .D64 is about half the size of .G64 because the data is binary (not GCR), and the recording speed, sync marks, sector headers, and sector gaps are missing.

You normally only find images in .G64 format if they have copy protection that hasn't been cracked.  Once the protection is broken, it should be possible to put it on a .D64 ... this is not to say the all .D64 are cracked versions, as many lame copy protection schemes can be emulated with the .D64 "error code extensions"

And to add some info to this, a .nib file is the raw binary data extracted from a disk with a "nibbler". This kind of file can be converted to a G64 with nibtools.