Code: Select all
move.w #34,-(sp) * Kbdvbase
lea 32(a1),a1 * Statvec
* Wait keypress some time via trap #1, #6
* skipping following code, not relevant here
* Need to wait release of pressed key
bsr.s backSv * back org vector
* continue start process .......
statVec jsr 0 ***
* Need d0 negative , as release signal
st relFlag * Key pressed flag
released clr.b relFlag
lea 0,a1 ****
relFlag dc.b 0,0
AtariZoll wrote:I tried 192K version - what did never before
AtariZoll wrote:It seems that calling original IkbdStat at statVec returns not negative d0 when key is released , only when mouse action is performed. And it should return IKBD chip scancode - of course negative byte by any key release.
AtariZoll wrote:Statvec returns ASCII code when key is pressed - so $20 for space. And returns not exactly proper release code, but it is negative byte, it seems always.
AtariZoll wrote:... Statvec returns ASCII code when key is pressed - so $20 for space. And returns not exactly proper release code, but it is negative byte, it seems always.
For instance $B9 for space (is it scancode ? - YES). Since mine code works well in TOS 1.00-4.04, that means it is probably same in all of them, and that only matters.
In EmuTOS mouse movement will result with $FF at some moment, and then my code continues.
This is case where probably no detailed doc about TOS function available, so we need to trace it, and even accept some unexpected, seemingly illogical behavior. Health, pardon, compatibility is most important
czietz wrote:I wonder if in all this minutia the important points about the release get overlooked?
AtariZoll wrote:As said it works in all TOS versions 1.00-4.04 . I don't care for MagiC, Mint etc ... It is not first case that I used TOS function without proper docs, but instead it traced it - what was common practice in past too by programmers.
Now, if you think that what stays in DOCs is more important than what happens in practice, it is your thing.
Well, I will not change just like that code in 500 game launchers. Will rather recompile EmuTOS with fix - to behave like all known TOS versions
Did tracing, and it is not (a0) what goes in d0 in TOS 1.04 . It is exactly scancode what goes there
ijor wrote:Pera/AtariZoll is, as usual, extremely unfriendly and aggressive, speaking like he is is always right and everybody else is always right ...
TheNameOfTheGame wrote:If TOS has always acted a certain way even if unspecified then shouldn't EmuTOS emulate that way?
Frank B wrote:If this behaviour is undocumented and there's a documented way to do it, relying on it is stupid IMHO.
Has this function always been documented this way?
Anyone expecting a void function to return something deserves to have their code broken.
AtariZoll wrote:In TOSHYP says: "For the elements kb_clockvec and kb_joyvec one should note that the address of the packet is passed in register A0 and on the stack;" - So, nothing about Statvec
Code: Select all
void (*kb_midivec)(); /* MIDI interrupt vector */
void (*kb_vkbderr)(); /* Keyboard error vector */
void (*kb_vmiderr)(); /* MIDI error vector */
void (*kb_statvec)(); /* Keyboard status */
void (*kb_mousevec)(); /* Keyboard mouse status */
void (*kb_clockvec)(); /* Keyboard clock */
void (*kb_joyvec)(); /* Keyboard joystick status */
void (*kb_midisys)(); /* System Midi vector */
void (*kb_kbdsys)(); /* Keyboard vector */
int8_t drvstat; /* Keyboard driver status */
TheNameOfTheGame wrote:Eh why fight back and forth guys? AtariZoll makes a logical point about TOS behavior which should be considered beyond emotional reactions.
AtariZoll wrote:Who works, makes mistakes. Pointing on them may help in doing work better, and to understand appearing problems with SW.
Users browsing this forum: No registered users and 3 guests