evnt_multi without wait ?

[exxos]

I'm using this to check for clicks and keypresses etc and it works fine. However as described it literally waits for a event.

http://toshyp.atari.org/en/008007.html#evnt_multi


But is there a way to check for keypresses without waiting ?

[exxos]

hmmmm

Code: Select all

repeat getkey					'use the BIOS to check if a key was pressed
	if FNbconstat(2)=-1 then exit getkey
end repeat getkey

http://toshyp.atari.org/en/About_the_BIOS.html#Bconstat

Code: Select all

Name:	Bios console status
Opcode:	1
Syntax:	int16_t Bconstat ( int16_t dev );
Description:	The BIOS routine Bconstat establishes the input status of a standard peripheral device dev. The following devices can be specified for dev:

dev	Meaning
0	prn: (Printer/Parallel port)
1	aux: (Aux device, the RS-232 port)
2	con: (Console)
3	MIDI port
4	Keyboard port
5	Screen
6	ST compatible RS-232 port (Modem 1)
7	SCC channel B (Modem 2)
8	TTMFP serial port (Modem 3)
9	SCC channel A (Modem 4)

Not sure why "2" was used to check the keyboard in the hisoft example :shrug:

EDIT

Bconstat(2) returns -1 on a keypress, Bconstat(4) just returns 16 all the time.

Oddly does not seem to be any way to actually obtain which key was pressed :shrug:

[mfro]

Mixing up bios and AES calls is usually not a good idea.

If you absolutely need to busy wait for a key (which isn't considered clean GEM programming), use an evnt_multi() call with

Code: Select all

MU_KEYBD | MU_TIMER

in the ev_mflags field (and with a small timer value only) in combination and check the return value to decide whether it returned because of a key press or the timer expired.

[exxos]

Using the time seems to make things worse so just left it without.

I think one of the problems I seem to be having now though as I check for a keypress, but the some reason in Hatari it seems to register the same keypress multiple times. I'm not sure what is screwing up.

Can evnt_multi() Trigger multiple times on a single keypress ? or does it actually buffer everything and churn the keys out one at a time or something ?

The problem I'm seeing currently is when you press "A" in GB7 , it runs all tests. But then it is like "AAA" has been pressed because it runs exactly like it has been pressed multiple times.

So I don't know if there is a way to clear the keyboard buffer.. But I did actually try simply doing

Code: Select all

while INKEY$<>"": wend

But it made no odds.

So I have no idea why or where these multiple trigger events are coming from. It does not ordinarily do this on the ST or in steem. it is something which only seems apparent in Hatari. :shrug:

EDIT

In fact I just tried to rename AUTO and simply pressing one letter comes up multiple times. So that would seem to be the trigger of it all.

But even so I really need a way to clear out the keyboard buffer somehow to stop this from actually happening...

[exxos]

Okay this problem seems to be only apparent with EMUTOS. switching back to proper TOS404 and I do not have this problem now. While the keyboard repeat is extremely fast (don't know why) general typing does not result in several of the same letters appearing on the screen all at the same time.

So I don't think this is a actual bug to be fixed (by me at least) .

[czietz]

Okay this problem seems to be only apparent with EMUTOS. switching back to proper TOS404 and I do not have this problem now. While the keyboard repeat is extremely fast (don't know why) general typing does not result in several of the same letters appearing on the screen all at the same time.

Did you perhaps have "fast forward" mode enabled in Hatari? Depending on the keyboard settings, the repeat might become so fast that briefly pressing a key can result in multiple key-presses. This is described in the manual: https://hatari.tuxfamily.org/doc/manual ... ard_Dialog

Aside from "fast forward" mode I can confirm that there are no issues whatsoever with EmuTOS on the Falcon that would cause repeated key events.

[exxos]

Did you perhaps have "fast forward" mode enabled in Hatari? Depending on the keyboard settings, the repeat might become so fast that briefly pressing a key can result in multiple key-presses. This is described in the manual: https://hatari.tuxfamily.org/doc/manual ... ard_Dialog

Aside from "fast forward" mode I can confirm that there are no issues whatsoever with EmuTOS on the Falcon that would cause repeated key events.

Yeah fast forward was turned on in the config. But it did not seem to have such a extreme effect with normal TOS. maybe EMUTOS keyboard repeat is faster than TOS or something ?

[czietz]

maybe EMUTOS keyboard repeat is faster than TOS or something ?

The default values are the same in Atari TOS vs. EmuTOS as far as I can see.

Also typing with "fast forward" activated in Hatari to me does not feel different between TOS 4 and EmuTOS ... but this test is of course subjective. In other words: I get extraneous key events with both. Perhaps in your TOS 4 configuration an ACC, CPX, etc. was setting a slower keyboard repeat?

[exxos]

Perhaps in your TOS 4 configuration an ACC, CPX, etc. was setting a slower keyboard repeat?

So are you suggesting EMUTOS doesn't work with ACC or CPX then ? As the setup is identical other than changing the ROM image. If a CPX for example caused the keyboard repeat rate to change, then why wouldn't it also do the same for EMUTOS ?

I don't generally use CPX or ACC anyway. I generally run a clean setup.

[czietz]

So are you suggesting EMUTOS doesn't work with ACC or CPX then ? As the setup is identical other than changing the ROM image. If a CPX for example caused the keyboard repeat rate to change, then why wouldn't it also do the same for EMUTOS ?

Of course, EmuTOS works with ACCs and CPXes that set keyboard repeat rate. But any specific ACC/CPX could be buggy and refuse to work under EmuTOS.

In any case, I have equal difficulties typing with Hatari's fast forward on in TOS 4 and EmuTOS. In other words: It doesn't feel different.