JS ROM on Q-emuLator 1.1 at full speed on a quad core i7 MBP, OSX 10.7.4, 16GB, 1.5TB
Is there a limit on the size of a value that can be handled by DIV?
Example:
tempsecs=999999 --- no problem
days=tempsecs DIV 86400 --- overflows if tempsecs>=32768
Another oddity I discovered:
If I create a REPeat loop thus:
100 Frame=0 : Keypress=0
110 REPEAT loop
120 a$=INKEY$
130 Frame=Frame+1
140 IF a$<>"" THEN Keypress=Keypress+1
150 AT 0,0 : PRINT Frame, Keypress
160 END REPeat loop
...I reasonably expect that when a key is pressed, the Keypress value
will increase in step with the Frame value (every time the loop
repeats, a keypress is detected) but no. I can type run, and hold down
the enter key, and Frame will increment 55 times for each detected
Keypress. It seems INKEY$ is limited to approx 15 keyboard scans/sec.
On my original QL, with or without GC, they increment together, 1:1.
Q-EmuLator 1.1, JS ROM
QL, JSU ROM
*grins*
Now, tell me what an idiot I am
Q-Emulator Oddities :)
Re: Q-Emulator Oddities :)
Limits are 16-bit signed values on QDOS systems, 32 bit signed with SBASIC (SMSQE) systems.
Dilwyn
Dilwyn
--
All things QL - https://dilwyn.qlforum.co.uk/index.html
All things QL - https://dilwyn.qlforum.co.uk/index.html
Re: Q-Emulator Oddities :)
Thanks to the info of you and others, I have grasped/resolved that issue...
Any thoughts on the INKEY$ oddity?
I suspect Daniele deliberately slowed the keyboard scan rate to a sane level, but that's just a wild guess.
Any thoughts on the INKEY$ oddity?
I suspect Daniele deliberately slowed the keyboard scan rate to a sane level, but that's just a wild guess.
Re: Q-Emulator Oddities :)
Dave,
for your INKEY$ issue, I don't quite understand what you're expecting (or why you assume when you press and hold a key that INKEY$ would be able to supply a character instantly):
INKEY$ without an argument will not wait until a character is available, it will just return with "" if not. The Keyboard will have a character ready with the frequency of the autorepeat rate (which is set to 15 * 1/50s on my system, probably different to the standard QL).
On your standard QL I guess the "looping around" might very well take longer than the autorepeat time, so every time the loop comes around a character is there.
On Q-Emulator, I guess the loop might be faster, so there are cases where INKEY$ does not deliver a character.
Dave, you have built a simple speed tester for your QL. What you see on the standard QL is just that the looping around takes longer than the autorepeat - That's why you get a character for each iteration (Or, more negatively expressed: On a standard QL SuperBasic is just too slow to digest characters as fast as the keyboard can produce tham )
So, absolutely nothing "odd" in my opinion here.
Cheers,
Tobias
for your INKEY$ issue, I don't quite understand what you're expecting (or why you assume when you press and hold a key that INKEY$ would be able to supply a character instantly):
INKEY$ without an argument will not wait until a character is available, it will just return with "" if not. The Keyboard will have a character ready with the frequency of the autorepeat rate (which is set to 15 * 1/50s on my system, probably different to the standard QL).
On your standard QL I guess the "looping around" might very well take longer than the autorepeat time, so every time the loop comes around a character is there.
On Q-Emulator, I guess the loop might be faster, so there are cases where INKEY$ does not deliver a character.
Dave, you have built a simple speed tester for your QL. What you see on the standard QL is just that the looping around takes longer than the autorepeat - That's why you get a character for each iteration (Or, more negatively expressed: On a standard QL SuperBasic is just too slow to digest characters as fast as the keyboard can produce tham )
So, absolutely nothing "odd" in my opinion here.
Cheers,
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: Q-Emulator Oddities :)
Dave,
thought about this a bit more - I think your basic mis-understanding is on what INKEY$ does:
No, it does _not_ scan the keyboard. It looks into the keyboard queue and returns the next character or "", if none is there. If you press and hold a key, the "producing end" will put characters into that queue with the speed set by the keyboard auto-repeat frequency. And if you drain the queue faster than the "production rate", it will become empty at times.
Hope this is easier to understand than the above.
BR,
Tobias
thought about this a bit more - I think your basic mis-understanding is on what INKEY$ does:
No, it does _not_ scan the keyboard. It looks into the keyboard queue and returns the next character or "", if none is there. If you press and hold a key, the "producing end" will put characters into that queue with the speed set by the keyboard auto-repeat frequency. And if you drain the queue faster than the "production rate", it will become empty at times.
Hope this is easier to understand than the above.
BR,
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: Q-Emulator Oddities :)
Your explanation matches what I'm seeing.
I hope you can also see that there's an "appearance of impropriety" even though everything is as it should be. It's good to be reminded that just because the OS is running at 3800x speed doesn't mean the emulated keyboard is too
Thanks for the explanation.
I hope you can also see that there's an "appearance of impropriety" even though everything is as it should be. It's good to be reminded that just because the OS is running at 3800x speed doesn't mean the emulated keyboard is too
Thanks for the explanation.
Re: Q-Emulator Oddities :)
how about using "KEYROW" instead ?
Paul
Paul
May the FORTH be with you !
POLKa
POLKa
Re: Q-Emulator Oddities :)
I would, but the loop is small and tight, and using KEYROW and then parsing the results would slow everything down.
I do a lot of indie film work, and often am called upon to reproduce retro 80s displays, like in Wargames... Whenever I'm asked todo this, I always resort to either BBC Basic or SBASIC. Over time, my preference has shifted even further to SBASIC due to the way I can access the screen memory.
Right now, I am working on a feature length sci-fi project set in a spacecraft with a very 80s feel, and I need to provide data on two screens.
The loop does math about location, acceleration, vector, then updates the screen, whilst allowing the crew to twiddle knobs and etc.
In this case, an emulator beats the pants off a real QL< as I can simply open up a USB keyboard, and connect certain key contacts to physical switches in the control panels on the set. It's really very neat to see in action.
I took the leap and bought the two keys for $55 option so one screen can be run by a mac and the other by a PC.
I bet Daniele would make a fair bit of extra money if he just sold additional licenses for $10 to existing customers - it bugs me that I installed the Windows version on a USB drive but I can't just plug it into a different windows machine without re-registering - don't really want to do that.
When the Raspberry Pi QL emulator comes together, that will be a HUGE help to this type of work.
All I need to do now is play with the TCP functionality in Q-Emulator and see if I can get the two emulators talking to each other... Must find/read manuals!
Having fun!
I do a lot of indie film work, and often am called upon to reproduce retro 80s displays, like in Wargames... Whenever I'm asked todo this, I always resort to either BBC Basic or SBASIC. Over time, my preference has shifted even further to SBASIC due to the way I can access the screen memory.
Right now, I am working on a feature length sci-fi project set in a spacecraft with a very 80s feel, and I need to provide data on two screens.
The loop does math about location, acceleration, vector, then updates the screen, whilst allowing the crew to twiddle knobs and etc.
In this case, an emulator beats the pants off a real QL< as I can simply open up a USB keyboard, and connect certain key contacts to physical switches in the control panels on the set. It's really very neat to see in action.
I took the leap and bought the two keys for $55 option so one screen can be run by a mac and the other by a PC.
I bet Daniele would make a fair bit of extra money if he just sold additional licenses for $10 to existing customers - it bugs me that I installed the Windows version on a USB drive but I can't just plug it into a different windows machine without re-registering - don't really want to do that.
When the Raspberry Pi QL emulator comes together, that will be a HUGE help to this type of work.
All I need to do now is play with the TCP functionality in Q-Emulator and see if I can get the two emulators talking to each other... Must find/read manuals!
Having fun!