EmuTOS - incompatibility issues

News,announcements,programming,fixes,game patches & discussions.

Moderator: Petari

Post Reply
Petari
Posts: 316
Joined: Tue Nov 28, 2017 1:32 pm

EmuTOS - incompatibility issues

Post by Petari » Thu Dec 21, 2017 9:59 am

I will talk here about mine recent findings of incompatibilities of EmuTOS, latest v. 0.9.9 with some SW, and more, about why it is incompatible .

EmuTOS is open source TOS replacement project. That is actually nice idea, and indeed huge task, years of work.
It is known too as not compatible with games and some other SW, but it improved in newer versions.
Ahhh ... here I most ask that if someone from EmuTOS team or their supporters comes here, please read all written carefully, if needed 2x before getting in some unnecessary discussions, or even worse. I will simply delete posts which are clearly written without taking care to get real picture about what we talk here.

So, it happened that I decided to test little EmuTOS, 192K, latest v. - mostly to see how it works with games. And yes, first game worked well. Then tested with mine HAGA system adaptation - and what ? It continues not after key release ... Only when moving mouse - on screen what is total mouse less, no mouse pointer at all (.TOS, not .PRG) ??? That was about only 5 minutes testing overall then.
Then I made mistake, what costed me lot of stupid postings at AF, some insults and even some hidden threats. I wrote about what I seen. But I don't regret - I learned from all that mess. Question is: did other learn something ?

So, back to real topic:
I will give here instead my incompatibility list (what I don't have, and will not make it) their incompatibility list:
https://github.com/emutos/emutos/blob/m ... atible.txt

2 items took my attention in that list:
STVidPlay - this is mine SW. It uses read of file not via filesystem, but with low level direct disk access - for max speed.
First thing is to find exact pos of video file on disk. And that is what fails in EmuTOS. Of course, they blame my code, after obviously shallow and quick trace. I traced it in Steem Debugger, and then realized that EmuTOS does not use installed autoboot driver on disk, but has own hard disk driver, which only takes parameters from MBR. Usual hard disk vectors in TOS are not changed, as it is case with all TOS versions and driver SW.
In short, that way is not usual, regular way used in regular TOS versions and hard disk driver SW. And while it does good job with basic tasks, like file access, it fails in some special cases. And is slower than regular TOS versions - Info for some larger partition can take over 1 minute.
I said - it will not work well with some disk utilities too - and tests confirmed it - CHKDSK3 absolute disk sector access fails. What is worse, such incompatibility may cause data losses in unlucky case. Btw. I wrote e-mail to EmuTOS project leader 3 days ago about all it - no reply until now.

Spectrum 512: really ? EmuTOS will not support that famous SW, just because it using some trick, undocumented behavior. No words.

And I tested my recent little demo proggie viewtopic.php?f=39&t=437 (3KB of mostly AES call code) with EmuTOS too. It worked well mostly. 2 problems:
bad color of sliding ball and no mouse movement during slide.

And it may be the best example of why their attitude is not good:
Obviously, they changed default color scheme of TOS in low res. For what it is good ? - Hmm - maybe color scheme is OK, but icon color implementations is bad ? - see lover.
No mouse movement is caused by bad implementation of AES funtion Appl_Tplay . It works only from TOS 1.02, and is not something really needed in some OS, I think - just plays some actions from recorded seq. Like mouse actions. I used it with Appl_Trecord for automatic mouse actions in demo.
Of course, record is done during program creation, not in final version, where only playback happens.
And here we are with bad documentation of Atari TOS, what plays big rule in all this.
It is really bad, incomplete, many errors. Appl_Tplay and Trecord have not 6-byte records, as stays in ProfiBuch, but 8 byte records. That is what I discovered, better said traced down many years ago, when used it first time. So, very likely that mouse movement failed with EmuTOS just because they used bad docs, and more important - they tested it not enough.
For the end of this first post: 2 days ago I noticed another error (30 years after buying) in ProfiBuch - in description of ICONBLK structure - color of icon related. Maybe I even seen it earlier, but was no correction in Buch (there is many handwriting at errors in my copy) . But I used icons barely.
Conclusion: should we relay blindly on docs, or rather relay on how SW/OS behaves in practice ?

BlankVector
Posts: 19
Joined: Fri Sep 15, 2017 10:51 pm

Re: EmuTOS - incompatibility issues

Post by BlankVector » Thu Dec 21, 2017 1:43 pm

Thank you for those bug reports.
Let's check them one by one.
Petari wrote:
Thu Dec 21, 2017 9:59 am
Then tested with mine HAGA system adaptation - and what ? It continues not after key release ... Only when moving mous
We already discussed that question ad nauseam on Atari-Forum. In your ikbdsys hook, you call the ROM ikbdsys, then you look at d0. You consider that d0 contains meaningful value, put there intentionally by TOS developers. On the other hand, EmuTOS people consider that ikbdsys does not have to return anything in d0, so after calling EmuTOS ikbdsys, d0 contains random bytes.
That's a difference of point of view, there is no more to say.

Anyway, the purpose of EmuTOS is to provide an implementation of the TOS API, not of its unintentional side effects. If we consider that some some software don't use the OS the right way, then that software will not work with EmuTOS. This is intentional. And incompatible.txt keeps track of such software.
Petari wrote:
Thu Dec 21, 2017 9:59 am
on screen what is total mouse less, no mouse pointer at all
This may be an EmuTOS bug (bug means: will be fixed). But without more details, I can't say.
Petari wrote:
Thu Dec 21, 2017 9:59 am
STVidPlay - this is mine SW.
Quoted from incompatible.txt:
Program: STVidPlay
------------------
Error: "Error in getting file location"

Bug analysis:
Program looks for a specific 2-byte sequence in the hard disk driver
code pointed to by hdv_rw ($476). If it doesn't find that sequence
within bytes 6-48 (or thereabouts) of the start of the driver, it
gives the error message.
No one can argue that such implementation details are part of the TOS API, or any known interface. So EmuTOS will not try to be compatible with that.
Petari wrote:
Thu Dec 21, 2017 9:59 am
EmuTOS does not use installed autoboot driver on disk, but has own hard disk driver
Indeed, by default EmuTOS does not execute the boot sector of hard disks. This is an intentional limitation. Reason is that such boot sectors are usually used to load autoboot hard disk drivers, which are useless in that case as EmuTOS provides its own driver.
Petari wrote:
Thu Dec 21, 2017 9:59 am
CHKDSK3 absolute disk sector access fails.
It should be investigated why it fails.
Petari wrote:
Thu Dec 21, 2017 9:59 am
Spectrum 512: really ? EmuTOS will not support that famous SW, just because it using some trick, undocumented behavior. No words.
EmuTOS only supports clean software. And obviously (as detailed in incompatible.txt), Spectrum 512 is not clean. Whether or not it is popular software, that will not change that fact.
Petari wrote:
Thu Dec 21, 2017 9:59 am
And I tested my recent little demo proggie viewtopic.php?f=39&t=437 (3KB of mostly AES call code) with EmuTOS too. It worked well mostly. 2 problems:
bad color of sliding ball and no mouse movement during slide.
This could be EmuTOS bugs. Without further analysis, I can't say.
Petari wrote:
Thu Dec 21, 2017 9:59 am
Obviously, they changed default color scheme of TOS in low res.
Really?? Well, I'm not aware of that. Details will be welcome.
Petari wrote:
Thu Dec 21, 2017 9:59 am
icon color implementations is bad ? - see lover.
Where? What is expected, what is wrong?
Petari wrote:
Thu Dec 21, 2017 9:59 am
No mouse movement is caused by bad implementation of AES funtion Appl_Tplay
appl_tplay() has only been implemented recently in EmuTOS, and there are not many programs using it. Maybe there is still a bug in EmuTOS implementation, to be investigated. Testcases for appl_tplay() are not so common.

Petari
Posts: 316
Joined: Tue Nov 28, 2017 1:32 pm

Re: EmuTOS - incompatibility issues

Post by Petari » Thu Dec 21, 2017 1:57 pm

I attached concrete TOS code seq. , where is clearly visible that d0 in ret. has sense - it was IKBD chip scancode.

You can ask me that I put together what errors I found in documentation, and I will do it and post somewhere. Then you can use it to make EmuTOS better. I sent similar error report at Github today. So, I think that I do everything what man can do.

Petari
Posts: 316
Joined: Tue Nov 28, 2017 1:32 pm

Re: EmuTOS - incompatibility issues

Post by Petari » Thu Dec 21, 2017 2:33 pm

OK, there is now thread about issues at Github, with EmuTOS team - what is better place for error reports, so I think that here we should rather see some user opinions.

Petari
Posts: 316
Joined: Tue Nov 28, 2017 1:32 pm

Re: EmuTOS - incompatibility issues

Post by Petari » Sun Dec 24, 2017 6:32 pm

My last message at Github:
"Something very interesting: looked A Hitchiker's Guide to the BIOS Rev 1.1 1990 .
There is example of DMA bus boot code (same is in ProfiBuch 1987).
Why it is interesting - because Hatari and EmuTOS people called my hard disk driver buggy. Yes, there was 'bug' in older versions - they actually worked well with only 1 attached ACSI device. With 2 not.
I said then that I followed what was in ProfiBuch. And ProfiBuch followed what was in Hitchhiker's Guide :-) So, my 'bug' was because crappy Atari DOC, actually main DOC for Atari ST. And what it has with EmuTOS ? A lot - it means that following crappy docs leads to problems in SW.
I hope that above was useful for someone. Look at it as Xmas gift.
Merry XMAS :-) "
:yay:

Petari
Posts: 316
Joined: Tue Nov 28, 2017 1:32 pm

Re: EmuTOS - incompatibility issues

Post by Petari » Sun May 27, 2018 1:46 pm

And spotted this blah by Eero Tamminen "If demos and floppy-only games (*) aren't important, one could also consider eprom and flashing EmuTOS. Its disk accesses and especially booting is much faster than with normal TOS, and you don't need the extra patch programs. EmuTOS text output is somewhat slower than with real Atari TOS, but that can be fixed with NVDI."
Seriously, is it worth to talk with such people at all ? Completely ignorant, not only for what people says, but simple facts.
All tests I made indicate that EmuTOS is much slower with disks than any regular TOS version. Not to mention huge incompatibility level.
Sad, but it is just another case of "mine is best" type behavior. They should change profession, and go in advertising - or they are in it already ? :lol:

User avatar
exxos
Site Admin
Posts: 2407
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: EmuTOS - incompatibility issues

Post by exxos » Sun May 27, 2018 1:55 pm

I did benchmark emutos and like you say it was slower than TOS. I mention this and they just said use NVDI. So I don't think it be fixed anytime soon :(
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
arf
Posts: 52
Joined: Sun Oct 29, 2017 9:30 am

Re: EmuTOS - incompatibility issues

Post by arf » Sun May 27, 2018 3:00 pm

Petari wrote:
Sun May 27, 2018 1:46 pm
[…] Seriously, is it worth to talk with such people at all ? Completely ignorant, not only for what people says, but simple facts.
All tests I made indicate that EmuTOS is much slower with disks than any regular TOS version. Not to mention huge incompatibility level.
Sad, but it is just another case of "mine is best" type behavior. They should change profession, and go in advertising - or they are in it already ? :lol:
Do you really expect others to follow your advice, hints and descriptions when you laugh about _them_ personally? This isn’t the open mindset that you request from them.
--
Against signature spam!

Petari
Posts: 316
Joined: Tue Nov 28, 2017 1:32 pm

Re: EmuTOS - incompatibility issues

Post by Petari » Sun May 27, 2018 4:31 pm

I don't request anything from them. Actually, never requested anything. I just made some error reports, which were received very unpolite, even with some mocking. The reason to write what I wrote is exactly the opposite - I don't expect that they will change attitude.
And actually, things are that I will likely just stop to write about it, here or elsewhere. Not worth of time, especially when have much better things to solve.

Post Reply