AtariZoll wrote:Yes, you can follow incomplete DOCs, or can look what really happens

It's not only incomplete DOCs. If you look at the source code of TOS, you will see that the function does not return anything explicit. And i don't know what you loaded before your program, but in TOS 3.06 statvec just points to an rts.

2) You call the previous statvec (ROM one) using self-modified code.I have no problem with self-modifying code, it is valid when caches are off.

3) You call the ROM statvec directly with JSR. This violates the statvec contract.The doc says that the parameter is present both in a0 and on the stack. So at the beginning of your own callback, the parameter will effectively be in a0 and (sp). Then you call the ROM statvec with jsr, which pushes the return address on the stack. So that ROM statvec will have the correct value in a0, but not on (sp). If it works on some TOS, it is by chance because the ROM implementation of statvec ignores the parameter in (sp).

4) You check d0.b after calling the ROM statvec. This is a nonsense because, as it was already mentioned, the statvec callback is not supposed to return anything. So that d0.b has no real meaning, is just some garbage left by the implementation.

Points 3) and 4) are enough to say that your code is wrong, according to the documentation. Of course I admit it can work (I mean: not fail) on a particular implementation, but that's by chance. As it relies on undefined behaviour, it could fail on any other TOS-like operating system.

AtariZoll wrote:As said it works in all TOS versions 1.00-4.04 . I don't care for MagiC, Mint etc ...

No problem with that. You write code relying on undocumented (and even non-intentional) TOS features, so it will only work for those specific TOS versions. Some old games do that (STOS games...), so they need specific TOS versions. Usually, nowadays, people prefer to write clean code relying on documented behaviour. But everyone is free to code as he wants. I just say that such code will not work with EmuTOS, as, by choice, we don't implement TOS unintentional side effects.

Regarding to statvec contract: I'm surprised that statvec is called for key releases. I thought it was only called when receiving IKBD status packets, such as mouse moves or joystick events. It should be checked if EmuTOS really calls statvec on key releases, if Atari TOS does that.

Eero Tamminen wrote:As you've traced a lot of programs (mostly games I assume), can you say how much there's other Atari code (than your own game launchers) which rely on this behavior?

ThorstenOtto wrote:....You should look closer. Kbdvbase() + 32 is the address of the ikbdsys vector, not statvec. And that one does indeed return a value.

Finally someone who paying attention on details. Thanx for noticing it. How I mixed it up ? Probably bad DOCs - in older Profibuch editions there is lot of errors, so for Kbdvbase too.

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

ThorstenOtto wrote:You should look closer. Kbdvbase() + 32 is the address of the ikbdsys vector, not statvec. And that one does indeed return a value.

Oh, well spotted!I couldn't have imagined that the initial code was wrong that way.So the whole analysis in this thread is wrong. To be completely restarted from scratch.Thanks to have spotted that, Thorsten.

BlankVector wrote:For all commentators about AtariZoll's bug report: please look carefully at the code he provided in his initial post. I'm afraid that most comments missed the key point. ...

Eero Tamminen wrote:As you've traced a lot of programs (mostly games I assume), can you say how much there's other Atari code (than your own game launchers) which rely on this behavior?

I would really be interested by the answer.

And you missed it too - see post above

Answer on question about SW which rely on this behavior: No I did not see such, as I did not see PMMU code for TT and Falcon in special purposes, what I made without Atari DOCs - instead needed to use diverse sources around about 68030 PMMU.The reason for this - continue only when keys are released is to avoid autorepeat and nasty beep sounds when returning from game to Desktop. Games which have no such option. After showing cover pic in hi-color, or in 256 colors on TT and Falcon serious RAM rearrangement happens, and TOS is overwritten, but before it is saved in upper RAM. So, it is frozen in some way. And if it is saved with pressed some key, it will be restored with such system variables. While no key pressed in moment of ret. to Desktop, so can not be released, and it is not same key for Desktop return as what is pressed for starting game. If you save state of TOS workspace + system variables - when no key pressed, problem will not happen. I tried couple ways - dirty way would be to read ACIA directly. And this with Ikbdsys was selected and it worked well for some 6 years on all TOS 1.00-4.04. Of course, I needed lot of trials because poor, inaccurate DOCs .

I quote again: "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. " Or even about actually used Ikbdsys .

I hope now all is clear. We can go on something new ....

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

AtariZoll wrote:... I quote again: "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. "

This might be what TOSHYP says. Atari's own "The Hitchhiker's guide to the BIOS" (they should know what they were doing or at least what they intended to do) says otherwise: "'statvec', 'mousevec', 'clockvec' and 'jovvec' ... The packet handlers are passed a pointer to the packet received in A0, and on the stack as a LONG"....

One indication is that it obviously does. Another one is, that it is declared as long ikbdsys_handler(void) in Mint.

However, we must be careful here with whatever is written in some Profibuch, TOS.HYP, header files or whatever. Due to their very specific nature, none of these function is actually directly callable from C, so any prototype does not mean very much. That is most likely the reason why the function pointers are declared as void in most headers i found.

Fact is, that the implementation in TOS will return the input value from the ACIA in D0 upon return from this function... at least most of the time. Ikbdsys is a dispatching function, that will call other functions, depending on wether the received byte is a plain keypress, or some other byte belonging to some multi-byte packet, like mouse button presses or joystick events. In that case, you can't count on it being a keycode. And it might also get modified by the alt-keypad functionality of newer TOS versions.

Fact is also, that the function that calls it, does not use the return value.

So the reason that it worked for AtariZoll is mainly because that function wasn't changed much in different TOS versions.

So if he decides to rely on undocumented behaviour, that is his choice. But he shouldn't blame EmuTOS for not being compatible. The only question is wether it is worth to mimic that behaviour in EmuTOS, do be more compatible with Demos/Games that (as we all know) are not written very cleanly most of the time, and already require specific TOS versions to work.

BlankVector wrote:...Ok, the whole issue is about ikbdsys implementation. There are no parameters, as that callback directly reads data from the ACIA.Where do you see that it should return a value?

It not should, it returns a value. And I talked about it in my second post in this thread. The fact that it is not documented means not that it is some side effect - as some of EmuTOS folks said.If EmuTOS team wants to make compatible as much possible TOS replacement, they should do more than talking about what stays in DOCs. Lot of details is missing. There is lot of games with crappy IKBD code - mostly because lack of proper DOCs in 80-es. Those who did it well certainly discovered many things self.Most of DOCs is copy/paste - correct couple things, while most of errors just drag over and over until someone does something not so usual, and problem pops up. And even then, in most cases it's getting forgotten, ignored. Maybe I need new thread about silly DOC errors

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

ThorstenOtto wrote:Fact is, that the implementation in TOS will return the input value from the ACIA in D0 upon return from this function... at least most of the time. Ikbdsys is a dispatching function, that will call other functions, depending on wether the received byte is a plain keypress, or some other byte belonging to some multi-byte packet, like mouse button presses or joystick events. In that case, you can't count on it being a keycode. And it might also get modified by the alt-keypad functionality of newer TOS versions.Fact is also, that the function that calls it, does not use the return value.So the reason that it worked for AtariZoll is mainly because that function wasn't changed much in different TOS versions.So if he decides to rely on undocumented behaviour, that is his choice. But he shouldn't blame EmuTOS for not being compatible. The only question is wether it is worth to mimic that behaviour in EmuTOS, do be more compatible with Demos/Games that (as we all know) are not written very cleanly most of the time, and already require specific TOS versions to work.

It is irrelevant that function in TOS what calls does not use d0 ret value. It is function with ret value, since is not void. Only that details about ret. value missing in DOCs. I decided to make efficient code, if possible using TOS functions to save code, space. This - detecting key release is something what should be in some BIOS and/or GEMDOS call. I don't blame EmuTOS - I'm not in court. I blame your attitude and defending self with 'not documented' . I'm actually who made most of games compatible with diverse TOS versions, and you talk about work only on specific TOS versions. That's really not nice. I solved that Tracker works under any TOS 1.00-4.04 - original only on 1.00, and that costed me plenty of time. So, I fix not cleanly written SW. Although, I would say rather that it was dumbly written, partially because lack of good DOCs. If you just read carefully first couple posts, whole this thread could be shorter, and without all hassle.To repeat, main problem is not unclean coding, but that programmers were forced often on it because some bureaucrats did not well their job.

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

AtariZoll wrote:It is irrelevant that function in TOS what calls does not use d0 ret value.

Oh really?

It is function with ret value, since is not void.

And thats a fact, because you say it? You should have read my post more thoroughly. And you should look at the disassembly of TOS more closely. It *does not* always return a keyboard scan code in D0, not even in TOS.

I blame your attitude and defending self with 'not documented' .

I'm not defending anything here. I just explain what happens.

It's not documented, because it does not behave that way. And its's not documented, because Atari decided to not document it, so that people won't rely on some specific return code, like you do.

To repeat, main problem is not unclean coding

Disassembling existing TOS versions because of lack of documentation, then implementing something that relies on what you found out, does not make that code more clean. Especially not if you apparently did not understand all the code.

As said - it returns ASCII code when key is pressed, and scan code when is released (negative for release). That's what I know for sure, and I don't need more. EmuTOS just acts not like all known TOS versions in it. Over. Those vectors are there in purpose, to make coding easier and TOS version independant.

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

The Atari ABI specifies that return codes to functions will be returned in d0 IMHO. For a void function that will be pot luck... IE anything which just happens to be in d0 when the function returns if the registers aren't preserved. If a function is marked (void) you can't expect a sane return code. Why would you want to rely on the implementation details like that? It's hidden behind an interface. As a c developer that makes me shudder. If there's a clean way to do what you want please do that instead.

We are talking about the 192K version, at least the OP is talking about that version. AFAIK, the only official documentation for those versions of TOS is in "Hitchiker's Guide to the BIOS". All other documentation is either unofficial, or it is much later to be applied properly in this case. In that doc the routines are really not specifically declared. The structure returned by kbdvbase is declared as an array of LONGS !

So, yeah, it is not declaring as returning any value, but it is not declared as NOT returning either.

ThorstenOtto wrote:It's not documented, because it does not behave that way. And its's not documented, because Atari decided to not document it, so that people won't rely on some specific return code, like you do.

I think this is an overstatement. I doubt very much that Atari made a conscious decision about exactly what to document in this specific case. I think BIOS at that time was simply poorly documented, in some cases even wrongly documented.

Atari did admit faults and missing in the documentation. In some cases they released semi official notes. In some cases they published extended documentation. In others they just made informal posts at ... (Edit: Just checked, the semi official online channel back then was at Genie or at Compuserve).

As a matter of fact, TOS was so poorly documented at the time that is difficult to blame developers for using some "not really documented features". Yes, there were many extreme cases, I agree, such as unnecessarily using absolute locations. But in many cases it was difficult, if possible at all, to rely only on explicitly documented features.

This doesn't change the main point too much. The main point, IMHO, is:

BlankVector wrote:But everyone is free to code as he wants. I just say that such code will not work with EmuTOS, as, by choice, we don't implement TOS unintentional side effects.

Not sure I can understand the philosophy here. I can understand that you might decide to avoid it in specific cases. But just as a general, absolute, rule? Seems like you won't gain anything except loosing some compatibility. More than punishing developers (that mostly wrote the code decades ago), you are punishing the users.

ijor wrote:The Atari Compendium is not an official Atari documentation, is it?

It most certainly was official documentation. It was produced in cooperation with Atari I believe.

Of course it wasn't an official documentation. Where do you see anything that remotely indicates that? Do you see any kind of Atari copyright? It is pretty obvious from the introduction that this is a very third party work. You can see at the bibliography that it was based on many third party books. How come that could have been done with an official documentation.

It might have been done with some cooperation with Atari. I don't know. That doesn't make it an official documentation by any means.

ThorstenOtto wrote:If you don't consider 2.06 & 3.06 to be relevant, you are right.

I don't. I am aware about your work on those versions. Again, we are talking here about a 192K version of TOS. Relevant for me it should be TOS version 1.0 to versions 1.04 only. There is an older partial bios source available. I guess you are aware. Seems to be some kind of 0.9X version ??? Just looked up and the Kbdvbase structure is not even complete !?

Lot of posts .I think that Ijor has the point here. Atari ST documentation is just poor.I know some C and even some Asm part sources for some TOS versions, but none is complete. Furthermore, I have on my hard drives it.And even better, I have disassembled TOS 1.04 - so I can list here all those IKBD vector functions - which seem to be written in ASM.

"Where "ASCII" means any value from the keyboard tables, which can also be negative...." - yep, what an useful info. I seen only positive, and you should know it because you read my txt about when there is ASCII code - what is read via kb. tables and when is scancode.

I was on that official TOS.HYP site. There should be much more about all those Kbdvbase vectors, how to call, what returns, when, etc.

As someone mentioned STOS here as SW not compatible with diverse TOS versions - right. That is one good example of SW having problems with reading mouse, joystick, kb. They use something really undocumented, and to avoid: system variables of all mentioned input reads. Which differ in any TOS version. Usual STOS fixers add new tables for later TOS versions. I solved it different: mouse read is via VDI, joystick read is via Joyvec - and code what works on all TOS versions is really short - total some 40 bytes. Why good programmer(s) of STOS were not aware of that way ? I can think only 1 reason - lack of good documentation.

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

Now, some explanation of how it is planned to be useful:You see only rts at Joystick vector - so may think that coder needs to put there own joystick read, low level code. No, you need there only to replace rts with short code, what will just write joystick input to desired addresses - for both joysticks. Like:

moni * Joystick monitoring, very simple: * it is at joyvec address set with XBIOS 34 addq.l #1,a0 *a0 is odd move.w (a0),joyc * first byte is for joy 0, second for joy 1 rts

That's code for reading both joy ports. TOS will jump at some moment to address at Joyvec, and will supply data in (a0) . If it is not needed, it will just rts - when no vector changed. And there is no word in any DOC that this needs to be used this way. No wonder that is barely used in SW.

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.