EmuTOS 0.9.9

[anodyne]

The EmuTOS developers are please to announce the release of EmuTOS 0.9.9. In case you didn't know, EmuTOS is a GEMDOS-compatible operating system for Atari computers and is a free and open source replacement for common TOS images for Atari emulators.

The main new features of EmuTOS 0.9.9 are:
- AES: Allow mouse cursors to be loaded at boot time
- EmuDesk: Add several dialogs, including desktop configuration, window/desktop background configuration, and desktop window file mask
- VDI: Add blitter support for horizontal line drawing, filled rectangle drawing, and raster graphics

You can easily test EmuTOS on your real Atari hardware. Get emutos-prg*.zip from the link below, extract the PRG matching your favorite language, put it on a floppy (or hard disk partition), run it on your Atari, and you're done!

You can download your preferred binary archive here:
https://sourceforge.net/projects/emutos ... tos/0.9.9/

[AtariZoll]

Nice
I tried 192K version - what did never before. In Steem and in Hatari 2.0.0 . Some extra settings are great. Running directly game - Snoopy - works well.
But I noticed problem with IKBD/ACIA/keyb/mouse in specific situation:
There is code in mine SW, what needs to assure that continue only after key is released. With EmuTOS 0.9.9 it will not continue until mouse is moved or button pressed. Did not try yet on real HW, but even if there is OK (since IKBD chip emul. may be still not perfect) it is worth to fix because emulators.
Looking my code it may be that code for Xbios #34 (Kbdvbase) is not compatible.
In my SW is:

Code: Select all

	
	move.w	#34,-(sp)   *  Kbdvbase
	trap	#14
	addq.l	#2,sp

	move.l	d0,a1
	lea	32(a1),a1   * Statvec
	move.l	a1,backSv+2

	move.l	(a1),statVec+2
	move.l	#mySv,(a1)
	
* Wait keypress some time via trap #1, #6 

	pea	$600ff
	trap	#1
	addq.l	#4,sp 
	tst.b	 d0
	
* skipping following code, not relevant here	
* .....

* Need to wait release of pressed key 

	bsr.s	  waitRel
	
	bsr.s   backSv   * back org vector
* continue start process  .......

*******
mySv

statVec	jsr	0   ***

* Need d0  negative , as release signal

	tst.b	        d0
	bmi.s 	released
	
	st	relFlag  * Key pressed flag
	rts


released	clr.b	   relFlag
	rts

backSv	
	lea	0,a1   ****
	move.l	statVec+2(pc),(a1)
	rts

relFlag	dc.b	0,0
	
	

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.

[BlankVector]

I tried 192K version - what did never before

Thanks for you interest in EmuTOS
Note that 192k version has some features stripped due to size limitations, and it is for ST/STf only. On the other hand, 256k versions (single language) and 512k version (multi-language) are full-featured.

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.

I have just looked quickly at your code, so I may have missed something.
In your statvec custom callback, you call the old statvec callback, then check the return value?
If I'm not wrong statvec is just a callback, and it is not supposed to return anything. So in case of EmuTOS, the ROM statvec callback just leaves some random value in d0.

Anyway, there is something to fix, as you hit a problem. I wonder if EmuTOS does not implement statvec correctly, according to official documentation (where?), or if you use statvec in an undocumented way which works by chance on Atari TOS.

[AtariZoll]

I just traced it with TOS 1.04 (what is TOS v. code you using for this ) .
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

[ThorstenOtto]

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.

That might be the case, but it is only by accident. The function itself is declared as void, so there is no guarantee to return some specific value. If your code relies on it, then it is buggy. Did you try to run your program with Magic for example?

[mfro]

... 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

As Thorsten already pointed out, your code relies on undocumented implementation details and only works by accident. Atari never documented the keyboard routines to return anything sensible in d0. In EmuTOS, if I'm not mistaken, you probably get a number between 1 and 7 (the action to be taken).

The documentation I have says statvec should receive a pointer to the ikbd packet received in a0 and on the stack (and this is exactly what EmuTOS does). If you change your code from "tst.b d0" to "tst.b (a0)", it will most likely work on EmuTOS as well.

[AtariZoll]

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. I know that DOCs are wrong considering STE Microwire mixer, and I fixed that HW bug. I found solution for analog joystick on STE, Falcon - another thing unsupported by Atari.
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 .

t104sv.png

a1=$FFFC00 at start. Sorry folks, you are wrong.

[mfro]

Then, I'm afraid, EmuTOS is not for you, sorry.

Coding EmuTOS along all undocumented side effects TOS might have somewhere would - once finished - just produce an exact copy of TOS. Pretty pointless.

[AtariZoll]

Ah sorry for wasting your precious time with discovering of something what you are not interested.
This is not side effect. And your DOCs are indeed wrong - it is not a0, but a1 .
I'm done here, really. I did not this because I want to use EmuTOS. It's about compatibility. And you just refuse to make it more compatible because of bad DOCs or your misreading of it.

[czietz]

I wonder if in all this minutia the important points about the release get overlooked?

For example, see the initial announcement: VDI: Add blitter support. This was one of the most highly requested features by many users. How come no one commented on that?

[AtariZoll]

I wonder if in all this minutia the important points about the release get overlooked?

You know what ? I tested it about 5 minutes, intentionally with games - and then that flaw appeared. I spent another 10 minutes to examine it, then another 10 to post reply with asm src. And another 10 minutes to trace down what exactly happens with that call. Most funny is that programmers deny that d0 is what holds return code, while whole TOS does exactly that. So, I will not spend here another 10 hours in useless discussions. I know 100% that I'm 100% right. Is it gaming related or whatever matters not. VDI is supported by blitter at TOS 1.04 (or even 1.02), so I don't think that I should be impressed with it in 2017. Still, EmuTOS is slower in draw than TOS 1.04.
2(a1) is it - not really - reading ACIA for second time will cause side effects and bad value ...

[1st1]

About blitter feedback: no message is a good message...

[TheNameOfTheGame]

Thanks for the new EmuTOS! I'm trying to get it into BeePi to try out!

[AtariZoll]

I checked in Atari ST Profibuch .
There says: "Die Adresse des 'packets' wird in A0 und auf dem Stack übergeben."
In English: 'Address of packets will be moved into A0 and on Stack' .
There is nothing of it in real code in TOS 1.04 - and for sure no in other versions.
Whom to believe now ?

[Eero Tamminen]

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

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?

If there's compelling evidence that it's a common practice to rely on this in Atari programs, also for things intended for newer Atari TOS versions, I think things like TOSHYP could document it.

[AtariZoll]

You misinterpreting DOCs.
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. How about that Statvec using common way, and returns status in d0 ?

Just same as thread about Hatari YM sample playback bug. Ignoring facts, logic, not reading what is written.
My answer is simple: I don't care for other code what rely. I know how TOS really handles it, and that matters, not some DOCs .
EmuTOS can continue this attitude. I will not bother to report more errors. This is too painful.

[TheNameOfTheGame]

If TOS has always acted a certain way even if unspecified then shouldn't EmuTOS emulate that way?

[ijor]

Pera/AtariZoll is, as usual, extremely unfriendly and aggressive, speaking like he is is always right and everybody else is always wrong ...

But in this case, I'm not sure he is THAT wrong. I think that emulating even undocumented behavior is not bad, unless of course there is a good reason not to. So may be he made a mistake and may be he should try to avoid undocumented behavior next time. That doesn't change the fact that, if possible, it might be not a bad idea to adapt EmuTOS. IMHO, the more compatible with Atari TOS, again, unless it has some significant cost, the better.

Regardless, it is a rather minor thing. The debate should be moved probably to a separate thread. Overall, it is a great release. Kudos to the team, great job!

Edit: corrected typo

[AtariZoll]

Pera/AtariZoll is, as usual, extremely unfriendly and aggressive, speaking like he is is always right and everybody else is always right ...

Extremely shallow observation. You are unfriendly - what aggression I did here ? Of course that I'm right here - not because I'm so smart, but because some people even did not try to check the whole issue. May be minor issue - but I care for true or false, not for majority of.
Ah, was it friendly when you called all of us stupid, including Atarimania people just because we said that image is incomplete ? Sorry, first check, then judge - that's what I do always - and that's why I'm usually in right. Now you turned thread in personal fight
I guess that you think that praising will make some SW better more than fixing flaws .... Wait, who was here first with that ?
Ahh, what is that quoted first sentence Ijor ? I missed that it ends with I 'speaking like everybody else is always right ...'

[TheNameOfTheGame]

Eh why fight back and forth guys? AtariZoll makes a logical point about TOS behavior which should be considered beyond emotional reactions.

ijor's post offered a tentative olive branch although without the preface of personal "comment", and although I ignore such things, I don't see the productive point with that.

Shouldn't EmuTOS be as compatible as possible? Undocumentated behavior is always exploited and actual documentation is prone to human error. Let's endeavor to get it right. Simple as that.

If TOS has always acted a certain way even if unspecified then shouldn't EmuTOS emulate that way?

[Frank B]

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.
BTW initial Blitter support is awesome. Text blitting next?

[AtariZoll]

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.

And where it stays that Statvec is void ? Actually, there is no DOC what says what kind call is it, and what should return. You need to read whole thread mister. I gave even concrete code what Statvec does in case of key release. What should I do more to convince some people here ? We know how poor Atari ST DOCs were at time, and there are still gray areas.
Problem is in not listening. And yes, that is not friendly behavior in discussion.

[mikro]

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

typedef struct
{
   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   */
} KBDVBASE;

I'm not sure what is discussed here, it's void, period.

[AtariZoll]

Yes, you can follow incomplete DOCs, or can look what really happens . Honestly, I even did not notice all those voids. Why - because it is utter nonsense that calling Statvec returns nothing - then why is it there at all ?
And that would be enough from me. Question is: what is more important - life of bureaucracy ?

[AnthonyJ]

Eh why fight back and forth guys? AtariZoll makes a logical point about TOS behavior which should be considered beyond emotional reactions.

Unless there is a big impact surely it's a good thing to know about another "undocumented feature" of TOS. I'm curious to know if this is a regression - ie, by luck did previous versions of EmuTOS work this way?

Who works, makes mistakes. Pointing on them may help in doing work better, and to understand appearing problems with SW.

(from http://www.atari-forum.com/viewtopic.ph ... 05#p264157)

AtariZoll - perhaps a better response would be "my bad, maybe I've made a mistake assuming that a void function returns something - but please try to keep EmuTOS compatible since I may not be the only one to have this made this mistake as the docs are poor in this area"