User avatar
Grumpy Mike
Posts: 931
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

GET$ not waiting (solved)

Wed Jul 16, 2014 12:32 pm

RISC OS 12a
Some of my code uses
A$ = GET$
to pause until a user hits a key.
However, I am finding that this will work a few times and then it will not wait any more and acts as if the key was permanently held down. It is slightly better if I use a different key each time, but using the space bar it works the first time and then ever after it just goes straight through the statement.

Anyone else noticed this?

frednurk
Posts: 1
Joined: Tue Dec 11, 2012 9:25 pm

Re: GET$ not waiting

Thu Jul 17, 2014 12:43 pm

Pages 70/71 of the BBC BASIC Manual suggest that flushing the keyboard buffer, immediately before using GET$, might avoid a response to a random keypress. The suggested code would be:

FX 15,1
A$ = GET$

User avatar
Grumpy Mike
Posts: 931
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: GET$ not waiting

Thu Jul 17, 2014 1:17 pm

Thanks.
Sadly it did not make any difference.
Still the same symptoms.

jjcosgrove
Posts: 7
Joined: Thu Mar 07, 2013 2:31 pm

Re: GET$ not waiting

Tue Jul 22, 2014 4:03 pm

This is all new to me... but is this PowerBasic?

Have you tried an alternative way to wait for a keypress? such as:

Code: Select all

a$ = WAITKEY$
I wonder if the GET$ is aimed more at file reading and may be behaving strangely...

User avatar
Burngate
Posts: 6223
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: GET$ not waiting

Tue Jul 22, 2014 4:51 pm

Is there a reason for using
A$=GET$
instead of
A%=GET
(which is what I've always used, for no reason I can think of at the moment)?

I'm not doing anything with my Pis, since the weather is far to good to stay indoors.
When it starts raining again, I'll put the kayak away and get the Pi out. Then I'll suck it and see.

svrsig
Posts: 136
Joined: Thu Nov 03, 2011 9:45 am
Contact: Website

Re: GET$ not waiting

Tue Jul 22, 2014 5:12 pm

Grumpy Mike wrote:RISC OS 12a
Some of my code uses
A$ = GET$
to pause until a user hits a key.
What does A$ get set to?

There is an alternative - try the following:

REM to wait until (either) SHIFT key is pressed
REPEAT:UNTIL INKEY(-1)
REM Now wait for it to be released
REPEAT:UNTIL INKEY(-1)=0

This method tests to see whether the SHIFT key is being held down (rather than whether a key press is in the key buffer). Each key has a different code, -99 is the Space bar, -1 is either SHIFT key.

User avatar
Grumpy Mike
Posts: 931
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: GET$ not waiting

Tue Jul 22, 2014 5:15 pm

Thanks for the replies.
but is this PowerBasic?
No it is Acorn BasicV
Is there a reason for using
A$=GET$
instead of
A%=GET
Well using $ means that any key can be pressed without generating an error. I have always used it for things like "Press any key to continue"
What does A$ get set to?
It gets set to the key you pressed.
Doesn't INKEY look for a specific key like INKEY(-99) is the space bar.

User avatar
Burngate
Posts: 6223
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: GET$ not waiting

Tue Jul 22, 2014 5:30 pm

Grumpy Mike wrote:Well using $ means that any key can be pressed without generating an error. I have always used it for things like "Press any key to continue"
That's essentially what I use GET for, only it returns the ASCII code of the key, rather than a string. I've forgotten what happens if I press an F key - yet another thing to try when it's raining.

neilf
Posts: 72
Joined: Sun Nov 11, 2012 8:14 am

Re: GET$ not waiting

Tue Jul 22, 2014 9:21 pm

Are you sure your program isn't messing with the keyboard auto repeat rates? *FX11 and *FX12 are the usual commands I think. The rate is often altered in a program using keys for continuous actions - perhaps in a game - or to cut out the initial pause before a key is repeated.

User avatar
Grumpy Mike
Posts: 931
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: GET$ not waiting

Tue Jul 22, 2014 9:26 pm

neilf wrote:Are you sure your program isn't messing with the keyboard auto repeat rates? *FX11 and *FX12 are the usual commands I think. The rate is often altered in a program using keys for continuous actions - perhaps in a game - or to cut out the initial pause before a key is repeated.
Thanks for the reply.

Yes I am sure, I wrote the program. It does it on every program I have written on the Pi so far, I am beginning to think there is something wrong with the the actual RISC OS port. It never used to do it on the original Acorn hardware.

If it were the repeat rate then I would expect to see the same thing in an edit window, which I don't and I am just dabing at the keyboard's space bar.

User avatar
Burngate
Posts: 6223
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: GET$ not waiting

Wed Jul 23, 2014 9:12 am

Okay, it's got me so irritated, I've powered up the Pi to try something - never mind it's glorious out there, the ducks are quacking, the cows are mooing, the mozzies are biting, .... did you know the Wey navigation dates back to 1640?

Code: Select all

REM
PRINT
FOR i%=0 TO 100
  A%=GET
  PRINT i%,A%
NEXT
PRINT "wait ..."
t%=TIME:REPEAT:UNTIL TIME>t%+100
FOR i%=0 TO 1000
  A$=GET$
  PRINT i%," ",A$
NEXT
PRINT "wait ..."
t%=TIME:REPEAT:UNTIL TIME>t%+500
END
I wrote it on VirtualRPC - both bits work perfectly.
Transferred it to the Pi - again, both bits worked perfectly.

Limitations - this is on a B, with an old image - seems to be about July 2013, but it's not connected to the internet, so the dates are well wrong.
As you can see, it's set to maximum 1000 gets - I got bored about then.

User avatar
Burngate
Posts: 6223
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: GET$ not waiting

Wed Jul 23, 2014 12:08 pm

So the canoe was on the car, I was dresssed and ready to go, when the postman arrived. Small package - B+!
Plans aborted; set up NOOBs, into RISC OS, quick try - same result!

So is there something else going on for you?
Can't think what.

Is my PRINT initialising A$ in some way - and without that, A$ is growing, until it reaches the 256-character limit?
Is there somewhere else in your code that is doing something untoward?
The book from which I learned WIMP programming had a glaring (once you'd seen it) mistake. I can't remember all the ins & outs, but every time it went round one loop, it created a new copy of a local variable. Since it didn't go there often, it wasn't noticable, but it used up memory, until eventually it complained.

svrsig
Posts: 136
Joined: Thu Nov 03, 2011 9:45 am
Contact: Website

Re: GET$ not waiting

Wed Jul 23, 2014 6:31 pm

If the user presses the key, in response to you saying 'Press any key' or whatever, and holds the key down until your programme responds, it is likely that the keyboard buffer will be filled with repeat presses. Next time your programme says 'press any key' the GET$ statement simply gets the next key press from the buffer and therefore appears to continue immediately without waiting.
After accepting a key press, you need to wait until the key is released and then clear the keyboard buffer. Or use INKEY and test for key down, then key up before moving on. Simples.

User avatar
Grumpy Mike
Posts: 931
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: GET$ not waiting

Thu Jul 24, 2014 10:00 am

svrsig wrote:it is likely that the keyboard buffer will be filled with repeat presses. Next time your programme says 'press any key' the GET$ statement simply gets the next key press from the buffer and therefore appears to continue immediately without waiting.
True but I am not holding down the key and even a buffer flush before the read produced the same results. See reply #1
Burngate wrote:Okay, it's got me so irritated, .............
I wrote it on VirtualRPC - both bits work perfectly.
Thanks very much for that, it allowed me to solve the problem. Your code did not work on my machine so I investigated a bit.

What it turned out to be was the power lead. It was dropping just a tad too much voltage for the keyboard. The keyboard worked normally but for some reason not in the GET$ statement. This is why flushing the buffer before going into it had no effect.
I suspect a slight increase in current due to something in that routine tipped it over the edge as far as the keyboard operation is concerned and it started repeating, a known symptom of too lower a voltage.
However, in all other respects, like in the editor the keyboard behaved perfectly.
When I changed the power cable the voltage on the test points went up from 3.8V to 4.3V and now GET$ works like it always did.

Thanks very much for all your input.

User avatar
Burngate
Posts: 6223
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: GET$ not waiting

Thu Jul 24, 2014 10:47 am

Yahey :D So I can go on the river now! And the sun's still shining!

Glad you found it. Funny how a power problem can still bite unexpectedly - and no-one here suspected it.

User avatar
jojopi
Posts: 3142
Joined: Tue Oct 11, 2011 8:38 pm

Re: GET$ not waiting

Thu Jul 24, 2014 11:11 am

Now that we have fixed the actual problem.
Burngate wrote:Is there a reason for using
A$=GET$
instead of
A%=GET
There is no difference in the keys that can be detected. GET$ is equivalent to CHR$(GET) and GET is equivalent to ASC(GET$). A% is more efficient because it is a resident integer variable, whereas A$ is allocating completely unnecessary string storage.

My preferred method in Basic II/IV was:

Code: Select all

IFGET
Two bytes less code and no run time storage at all. I believe it is still valid in Basic V/VI.

User avatar
Grumpy Mike
Posts: 931
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: GET$ not waiting

Thu Jul 24, 2014 12:02 pm

Two bytes less code and no run time storage at all.
Yes but on the almost infinite memory you have on the Raspberry Pi as compared to a RISC PC, I am willing to live with that. ;)
Thanks

svrsig
Posts: 136
Joined: Thu Nov 03, 2011 9:45 am
Contact: Website

Re: GET$ not waiting

Fri Jul 25, 2014 9:34 am

What it turned out to be was the power lead. It was dropping just a tad too much voltage for the keyboard.
Hardware 'bugs' are always elusive. Despite using the manufacturer's recommended clock circuit for the Z80, the shape of the clock pulse on an unmodified Nascom 2 caused a small number of machine code instructions to go predictably wrong. This was called the 'string bug' as it caused a string error in BASIC. It was solved by overloading the clock circuit with a capacitor (I think) but must have been a swine to fault find.

Must remember to say 'check power supply' for all Raspberry Pi- related problems as a first step.

Return to “RISCOS”