Double-clicking .SSD overrides VDU 14 ?!

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
Post Reply
User avatar
lurkio
Posts: 1564
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Double-clicking .SSD overrides VDU 14 ?!

Post by lurkio » Tue Feb 20, 2018 11:12 pm

Does anyone know why when you double-click the attached .SSD to launch your preferred emulator the screen is autoscrolled despite the fact that VDU 14 has been issued and the program should actually be waiting for the user to press Shift to scroll?

Even JSBeeb doesn't quite get it right!:
The program does work correctly if you press Shift-Break in emulator to boot the disc: the program loads and runs and waits for the Shift keypress before scrolling the screen. But if you double-click the .SSD to launch BeebEm (or B-Em) and boot the disc-image, the screen autoscrolls, and you can't seem to stop it!

Download attached .SSD:
:?:
Last edited by lurkio on Wed Feb 21, 2018 10:28 am, edited 1 time in total.

User avatar
ctr
Posts: 139
Joined: Wed Jul 16, 2014 2:53 pm
Contact:

Re: Double-clicking .SSD overrides VDU 14 ?!

Post by ctr » Wed Feb 21, 2018 12:21 am

The emulator is probably simulating a shift key-press to make the shift+break work. This also allows the text to scroll. The emulator may well cancel the fake key-press when you press a key.

User avatar
lurkio
Posts: 1564
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Double-clicking .SSD overrides VDU 14 ?!

Post by lurkio » Wed Feb 21, 2018 12:54 am

ctr wrote:The emulator is probably simulating a shift key-press to make the shift+break work. This also allows the text to scroll. The emulator may well cancel the fake key-press when you press a key.
Makes sense.

I have a disc-image that !BOOTs a BASIC program that prints text on screen with VDU14. So the only way to stop the emulator pressing Shift (after a double-click on the .SSD) and scrolling the screen is to change the program (or the !BOOT) to ask for user-input first?

:?:

User avatar
ctr
Posts: 139
Joined: Wed Jul 16, 2014 2:53 pm
Contact:

Re: Double-clicking .SSD overrides VDU 14 ?!

Post by ctr » Wed Feb 21, 2018 2:07 am

lurkio wrote:So the only way to stop the emulator pressing Shift (after a double-click on the .SSD) and scrolling the screen is to change the program (or the !BOOT) to ask for user-input first?
I just tried b-em and it also cancels the shift if you don't press a key for a couple of seconds. So you could use INKEY to wait a few seconds for a key press, and then just carry on if there isn't one, by which time shift should be cancelled. I haven't tried this in jsbeeb however, and it does feel a bit hacky. A better long term solution might be to fix the emulators so they cancel the fake shift as soon as they detect any disk activity, say.

User avatar
tricky
Posts: 2455
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Double-clicking .SSD overrides VDU 14 ?!

Post by tricky » Wed Feb 21, 2018 7:33 am

Locally I did reduce the time shift was simulate down for, it doesn't need to be held for long.
I was going to set the keyboard bit that makes break auto boot and then turn that off after a second or so, but never got around to it; I don't know if its state is cached at startup or checked each time.

User avatar
lurkio
Posts: 1564
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Double-clicking .SSD overrides VDU 14 ?!

Post by lurkio » Wed Feb 21, 2018 10:45 am

ctr wrote:I just tried b-em and it also cancels the shift if you don't press a key for a couple of seconds
I just updated the disc-image in my first post so that the BASIC program does a VDU14 and then prints an infinite list of numbers. When the .SSD is autobooted in B-Em, the scrolling does indeed stop after a couple of seconds, but in BeebEm it goes on indefinitely or until the user physically presses a key.
ctr wrote:A better long term solution might be to fix the emulators so they cancel the fake shift as soon as they detect any disk activity, say.
tricky wrote:I was going to set the keyboard bit that makes break auto boot and then turn that off after a second or so, but never got around to it; I don't know if its state is cached at startup or checked each time.
Either of those solutions has got to be worth exploring -- surely they can't be worse than the current simulated Shift keypress?!

:?:

User avatar
Rich Talbot-Watkins
Posts: 1280
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Double-clicking .SSD overrides VDU 14 ?!

Post by Rich Talbot-Watkins » Wed Feb 21, 2018 3:51 pm

You could just add as your first line

Code: Select all

REPEAT UNTIL NOT INKEY-1
Will delay the program a bit on an emulator which keeps Shift held for a long time, but at least it fixes the issue!

User avatar
lurkio
Posts: 1564
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Double-clicking .SSD overrides VDU 14 ?!

Post by lurkio » Wed Feb 21, 2018 4:29 pm

Rich Talbot-Watkins wrote:Will delay the program a bit on an emulator which keeps Shift held for a long time, but at least it fixes the issue!
I think that'll delay the program indefinitely in BeebEm because BeebEm doesn't release the simulated Shift keypress until the user presses an actual key.

I think the real solution, as others have said, is that the emulators themselves need their behaviour tweaked. I'll raise bugreports shortly.

Btw, I've chosen to rework my program (an instructions displayer) and eliminate scrolling altogether!

:roll:

tom_seddon
Posts: 118
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: Double-clicking .SSD overrides VDU 14 ?!

Post by tom_seddon » Wed Feb 21, 2018 5:09 pm

ctr wrote:
lurkio wrote:So the only way to stop the emulator pressing Shift (after a double-click on the .SSD) and scrolling the screen is to change the program (or the !BOOT) to ask for user-input first?
I just tried b-em and it also cancels the shift if you don't press a key for a couple of seconds. So you could use INKEY to wait a few seconds for a key press, and then just carry on if there isn't one, by which time shift should be cancelled. I haven't tried this in jsbeeb however, and it does feel a bit hacky. A better long term solution might be to fix the emulators so they cancel the fake shift as soon as they detect any disk activity, say.
My emulator cancels Shift when there's any disc access, and it seems to work OK.

(I did consider using the keyboard link autoboot bit, as Tricky suggests, but holding down Shift works on the Master too. Since they're both keys the code for either would be basically the same.)

--Tom

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Double-clicking .SSD overrides VDU 14 ?!

Post by crj » Wed Feb 21, 2018 5:20 pm

lurkio wrote:I think that'll delay the program indefinitely in BeebEm
But I thought you wanted the program delayed indefinitely? (-8

OKOK, just not at that point in the code.

If you really can't get the emulators fixed, an alternative would be to write a small assembly shim which sits on KEYV. I've not tested this, but...

Code: Select all

.entry
  SEI
  LDA KEYV : STA previous+1
  LDA KEYV+1 : STA previous+2
  LDA #our_handler DIV 256 : STA KEYV
  LDA #our_handler MOD 256 : STA KEYV+1
  CLI
  RTS
.our_handler
  BCS previous
  BVS previous
  \ C=0,V=0: enquiry for state of shift and ctrl keys
  JSR previous
  BVS shift_still_pressed
  \ Shift has been released, so detach ourselves
  PHA : PHP
  SEI
  LDA previous+1 : STA KEYV
  LDA previous+2 : STA KEYV+1
  PLP : PLA
.shift_still_pressed
  CLV \ Pretend shift is not pressed
  RTS
.previous
  JMP &0000 \ Will contain the previous KEYV claimant
That would behave as though shift wasn't pressed, until the next time the OS observed the shift key had been released. Then the routine would vanish without trace, leaving the shift key operating normally.

User avatar
Matt Godbolt
Posts: 181
Joined: Mon Jul 31, 2006 10:02 am
Location: Chicago
Contact:

Re: Double-clicking .SSD overrides VDU 14 ?!

Post by Matt Godbolt » Wed Feb 21, 2018 10:11 pm

I can do some magical breakpointing and release shift as soon as the OS has started the boot process; either disc access or tape motor.

Coeus
Posts: 777
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Double-clicking .SSD overrides VDU 14 ?!

Post by Coeus » Wed Feb 21, 2018 10:46 pm

tom_seddon wrote:My emulator cancels Shift when there's any disc access, and it seems to work OK.
That seems like an excellent idea - I have implemented this in B-Em and the change is in master on the Stardot Github.

The new technique does not completely replace the timer, the timer is still set by the -autoboot command line option but as soon as a disc access occurs the timer is cancelled and the key released. That means if you have some weird filing system that has no autoboot and doesn't access the disk at this point the key doesn't stay down forever.

Coeus
Posts: 777
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Double-clicking .SSD overrides VDU 14 ?!

Post by Coeus » Wed Feb 21, 2018 10:50 pm

Matt Godbolt wrote:I can do some magical breakpointing and release shift as soon as the OS has started the boot process; either disc access or tape motor.
Oh, so "TAPE" falls into the category of "some weird filing system" in my last post as it does no disc access. I don't remember every trying to do autoboot on tape, I had forgotten it could.

User avatar
Matt Godbolt
Posts: 181
Joined: Mon Jul 31, 2006 10:02 am
Location: Chicago
Contact:

Re: Double-clicking .SSD overrides VDU 14 ?!

Post by Matt Godbolt » Wed Feb 21, 2018 10:58 pm

In fairness my 'autoboot' for tape is to type "*TAPE" and then "*/" or similar anyway (and I have "autochain" for 'ch.""') so it's probably moot.

Post Reply