EmuTOS 0.9.9

[ThorstenOtto]

none is complete.

Well then i someone managed to compile TOS versions from incomplete sources. I must be a magician.

I have disassembled TOS 1.04

And that does mean what? Many ppl have done that before.

I seen only positive

Because you most likely used the us version. In e.g. the german version, the german umlauts will return codes of 0x84, 0x94, 0x81 etc. Other language specific versions will have other country specific characters. All that values will be misinterpreted by your code as key-releases.

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.

As you already stated: keypresses will return the ASCII code (or better to say, the translated code), while keyreleases will return the scancode, with the breakcode for keyrelease set. But you treat them all the same by just checking for negative values.

[AtariZoll]

Yep, I guess those who disassembled TOS 1.04 forgot to publish it. Sorry for I don't know about it. And that was not the point. I posted here fragments of that disasm, related with subject.
I used UK v. And nobody complained that has beep at ret. to Desktop - I guess that's because simply did not use those Umlaut keys - and why should, when settings are with usual, Latin letter keys and numbers ? So, my SW does what needs to do, and does it well. That's what matters. I did not say that I completely know all behavior of Ikbdvec 9 vectors. I talk all time about poor documentation, and that we need to discover some things self. I did some, and it is on you will use it or not, will you continue useless fight about who is smarter, who disassembled what, talking that only documented is valid. No, documents are invalid in some manner.

[BlankVector]

And there is no word in any DOC that this needs to be used this way.

I wonder if the designer of that joyvec interface deliberately put an odd pointer into a0, or if it is pure accident.

BTW, as we are supposed to speak about EmuTOS in this thread: EmuTOS supports the joyvec vector. It is especially used by the SDL library. This allows, for example, to play PmDoom with joystick on exotic hardware (such as Amiga!).

[Eero Tamminen]

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.

Yeach. Mixing VDI & Joyvec on non-AES program sounds pretty dirty. Why you don't just use an IKBD interrupt handler both for keys & joystick? It's not that many lines of assembly.

My old game here has assembly for that, which I think should be compatible with GCC gas, AHCC, VBCC Vasm + Devpac, and should work on all 680x0 variants + ColdFire (thanks to CF compatibility patches from Vincent):
http://eerott.mbnet.fi/hatari/programs.shtml#punssi

You also need to set up the IKBD handler and remove it when your program quits or starts something else, but that's only few lines more. My game does that too, I needed it to be clean as I was developing & testing it under MiNT.

EDIT: Argh. I somehow managed to misread you to talk about joy & keys, when you were talking about joy & mouse. Mouse is indeed trickier because you need to keep track of the position with movement deltas, know the screen size and there are different modes. For that I don't have IKBD handler code. I don't like mixing VDI to non-AES program, but I don't have a better proposal.

[AtariZoll]

...
Yeach. Mixing VDI & Joyvec on non-AES program sounds pretty dirty. Why you don't just use an IKBD interrupt handler both for keys & joystick? It's not that many lines of assembly.
My old game here has assembly for that, which I think should be compatible with GCC gas, AHCC, VBCC Vasm + Devpac, and should work on all 680x0 variants + ColdFire (thanks to CF compatibility patches from Vincent):
http://eerott.mbnet.fi/hatari/programs.shtml#punssi
You also need to set up the IKBD handler and remove it when your program quits or starts something else, but that's only few lines more. My game does that too, I needed it to be clean as I was developing & testing it under MiNT.
EDIT: Argh. I somehow managed to misread you to talk about joy & keys, when you were talking about joy & mouse. Mouse is indeed trickier because you need to keep track of the position with movement deltas, know the screen size and there are different modes. For that I don't have IKBD handler code. I don't like mixing VDI to non-AES program, but I don't have a better proposal.

Good post. I mean, it indicates well your approach, attitude.
You say: "Mixing VDI & Joyvec on non-AES program sounds pretty dirty." - It is not dirty at all. Truth is that myself was surprised seeing that VDI is actually part of non-GUI part of TOS - what is called often GEMDOS, but it is misleading, because there is BIOS, XBIOS ++ in it.
Little more, since this is TOS clone/replacement thread: TOS is divided in 2 clearly separated parts - mentioned non-GUI (called GEMDOS often), and AES+Desktop .
It is very easy to activate VDI in non-AES program (AUTO run or directly bootable) with DOCUMENTED call - Open Workstation (instead Open Virtual Workstation) . There is XBIOS call for activating mouse. And of course Line-A is in non-GUI part too.
I have code for direct IKBD chip read, but don't see that it is better to use in some TOS calling SW. Actually, I used it in Hard 'n' Heavy because I needed as fast as possible code in interrupt to avoid problems in scrolling of splitted screen. Rare case.
There is of course short code to restore org. Ikbdsys vector right after key release is detected.

Just to add here that there is big flaw (solvable with some 10 lines of code probably) in this 2 part TOS combo: initial address of free space is set too high in case of AUTO run - there is big gap then, some 15-25KB, depending on TOS version. What is intended for AES workspace - but no AES at all. So, wasted space, and only Dungeon Master was smart enough to use it.
Even extension PRG for AUTO run is nonsense - PRG means AES using SW normally. There was confusion in some DR heads in that time.

Your not liking of mixing VDI in non-AES SW is really irrational, without any ground. There is plenty of AUTO run SW using plenty of VDI calls.
The real problem is poor documentation and lack of good, established terminology.

[BlankVector]

⚠IMPORTANT⚠
There was bug in EmuTOS 0.9.9 desktop. When deleting desktop icons, it could ask you to delete a bunch of files, fortunately after confirmation dialog. As this could cause data loss, we have released a 0.9.9.1 hotfix.

Please update now: https://sourceforge.net/projects/emutos ... s/0.9.9.1/

[Eero Tamminen]

Your not liking of mixing VDI in non-AES SW is really irrational, without any ground.

There are two reason why I thought it dirty:
* VDI use in program like yours is a layering violation, and coders try to avoid those unless they're really necessary (because layer violations can have unknown side-effects). To me it seems that you don't care about such abstract things, you've tested it, and it works
* You not happening across issues with using VDI from AUTO folder just means that you haven't been using it enough (AES definitely isn't fully initialized before boot has finishes and I'm pretty sure that applies partly also to VDI, at least in some TOS versions)

Anyway, If you say that mouse querying part of VDI works fine from AUTO, I believe you, I don't have any evidence to contrary. It's probably useful information also to others.

Btw. Here's a short allegorical summary of this whole discussion, which is hopefully equally offending to everybody, but still somewhat amusing and factually correct (I've changed information order slightly for clarity).

Dictionary:
- Dog = TOS
- Law = Official Atari documentation
- Turd = ASCII code
- Step on = Use
- DZero = register D0

Code: Select all

EmuTOS user: Your dog isn't dropping a turd on DZero-street.
EmuTOS dev: That's true.  It's against the law.
EmuTOS user: I've noticed that every other dog is dropping a turd there.  Your dog should drop one too!
EmuTOS dev: It's still against the law.  Why?
EmuTOS user: I wanna step on it!
Bystander 1: Have you noticed anybody else to step on them, on purpose?
EmuTOS user: I don't really know, but I've stepped on them 500 times and I would really like to continue doing that.
Bystander 2: Although there have been some writings against turd dropping, there actually isn't a law against it (or supporting it). It should be looked more into.
Bystander 3: When one analyzes the behavior of the other dogs more closely, they don't always drop turds on DZero-street, they can e.g. just take a leak there.  This happens for example with German dogs.
EmuTOS user: I don't care.  What I do, causes the other dogs to produce turds.  Besides, I only care about English dogs.
EmuTOS dev: We have many dog variants and actually need to know *what* they should produce and in which kind of situations before making them to drop anything...  And it indeed would help knowing whether anybody else relies on these turds.
Bystander 1: Farmers have better ways to get fertilizer... They'll just ask IKBD directly instead of relying on these turds.
EmuTOS user: Why everybody's such an idiot!?!  I want TURDS!!!!


PS. The reason why I above refer to "ASCII code" as "turd", is because it appears to be a side-effect, not something specifically designed to be that way. Scratch registers can have meaningful looking values by accident, but they can disappear if it's C-code side-effect and that code gets e.g. compiled with a different compiler version. Which could happen with TOS versions for Atari clones (e.g. CT60) using legally obtained Atari TOS sources...

If given functionality is implemented directly in assembly, as seems to be the case here, then the side-effect disappearing requires deliberate code change, and is slightly more "safer" to be relied on. That is, as long as somebody verifies that all TOS versions actually have the same code, and all paths out of that code really produce the same side-effect... However, that isn't the case, according to Thorsten.

So, next step would really be finding out whether there's anything else than AtariZoll code which relies on this particular side-effect.

[Eero Tamminen]

Just to add here that there is big flaw (solvable with some 10 lines of code probably) in this 2 part TOS combo: initial address of free space is set too high in case of AUTO run - there is big gap then, some 15-25KB, depending on TOS version. What is intended for AES workspace - but no AES at all. So, wasted space, and only Dungeon Master was smart enough to use it.

EmuTOS build provides emutos.map file which contains information what data is in that area. Subset of that information is included in the etos512k.sym file in the 512k version of EmuTOS:

Code: Select all

0x0001354a B _dta
0x0001354e B _linewrap
0x00013550 B _linesize
0x00013552 B _screen_rows
0x00013554 B _screen_cols
0x00013556 B _idt_value
0x000136f4 B cmdedit.o
0x00013724 B cmdexec.o
0x00013728 B cmdint.o
0x0001372c B __ebss
0x0001372c B _stkbot
0x0001372c B cmdutil.o
0x00013f2c B _stktop
0x00013f2c D __end_os_stram


Note: cmd stuff is missing on 192k ROMs as they don't include EmuCON2 (among few other features), so the addresses for that ROM version are lower.

And if one runs code from AUTO / doesn't need GUI stuff, one can use the cartridge version of EmuTOS instead, that leaves more free RAM than 192k version.

It's also possible to build a version of EmuTOS that puts things on top of RAM instead of bottom, if one is desperate to get dirty programs working with EmuTOS.

So, wasted space, and only Dungeon Master was smart enough to use it.

There are a *lot* of programs that write to fixed addresses. Many of the demos on floppies are such. As a result, with EmuTOS they can for example "cleverly" write over their own code and crash because of that, even when device has megabytes of free RAM that could have been used instead.

There is plenty of AUTO run SW using plenty of VDI calls.

I haven't seen any. Can you give an examples? (Other than your own code)

[AtariZoll]

AES is not initialized at all before TOS jumps to AES part of self - and that happens not in case of AUTO run, only if that PRG exits. It is not that AES is not fully initialized, it is not started at all. What is assumption here is that VDI is not initialized fully in case of AUTO run. Now, please disasm TOS and find where is VDI in AES part of TOS. Because I did it already.
And you again claim something what I did not say - "you say that mouse querying part of VDI works fine from AUTO" - No, I said that you can init mouse with XBIOS call. However, I'm pretty sure that it works - that VDI query, but really don't remember that I used it so, or seen in some SW - in any case so easy to check, that may take less time than replying here
For you it is side effect that asm. code for Ikbdsys reads ACIA into d0, and that value remains in it until rts ? At least in case of release. Well, you can look on it like that. What return should this function use, in which register ? All I can say that TOS is messy in many parts, there is lot of inconsistent coding, and even inefficient parts. I don't think that main problem here is do I rely on some side effect (and it is not) - question is: do we need to expect from amateur programmers to be better with using of TOS than coders who created, coded it ? TOS self is not cleanly coded.

[ThorstenOtto]

Btw. Here's a short allegorical summary of this whole discussion

ROFL

[AtariZoll]

Oh dear GOD. You talk about things what I know 1100x better (count of adapted games by me). Those programs writing to fixed addresses will fail with any TOS version if there is hard disk driver installed for instance. But even very good coders at Sublogic made error by setting video buffer under 512KB, on fixed addresses. The reason may be that it was easier so, but also that they did not understand DR policy, poor docs, did not expect that there will be TOS 2.06 with much more RAM hunger.
So, you don't believe me about VDI calls in AUTO run SW. I'm not sure that I wrote such, but I really seen it in many games. Instead looking it instead you, I go to sleep. We do not progress here at all. Better said you.

[AtariZoll]

Btw. Here's a short allegorical summary of this whole discussion

ROFL

Great. When no arguments insults coming ... Sad place is this.

[joska]

I haven't seen any. Can you give an examples? (Other than your own code)

XBoot (and several other less used boot managers) would be a very commonly used program. Geneva. Or N.AES/XaAES/MultiTOS. MagiC (on the Milan).

[AtariZoll]

Just to add something about VDI and AES function usage in AUTO run SW - although it should be clear already:
You can use VDI in such SW - just Open Workstation (not Virtual WS) .
You can not use AES in such SW - call is possible, but will do nothing. And no function to activate AES - well, I don't know about. All I know is that AES activates by simple jump to code for that, and then gives control to Desktop. If someone knows other way to activate AES - please talk about.

Now, because this talk making no progress here, and I'm almost called liar here (not believing that VDI calls are used a lot in AUTO SW), then because some other bad things. actually very bad things - this may be my last post here. Admins and moderators should make clear what is purpose of this forum.
Do we need experience, knowledge, opened discussions, or we need ego of some people and shallowness.

[simonsunnyboy]

Btw. Here's a short allegorical summary of this whole discussion

ROFL

I fully agree, couldn't stop laughing for 2 mins.

[BlankVector]

I fully agree, couldn't stop laughing for 2 mins.

I read it again and indeed, couldn't stop laughing
"take a leak" killed me

[christos]

I liked the parabole too. It was actually pretty accurate and funny! I really liked the part where the Emutos User wants to step more times on the turd.

Seriously though, the way I understand Emutos' scope is that it is not trying to recreate TOS but rather it tries to be a better TOS compatible OS for our Atari systems. It's not there yet, even though it's better in many respects there are features missing and bugs to be ironed out. But there's the luxury of time, there are no release dates, no pressure from management and no products ready to launch.

With that in mind, the Emutos team needs to aim at better compatibility but at the same time, that should not include turning bugs into features. So unless this is demonstrated to be by design or a common use case (more than one developers use it) then it should not be included in Emutos.

[AtariZoll]

This is not about is that behavior of Ikbdsys such by design, or is some side effect. It is just about who is smarter, who knows TOS better. That's so clear if you read Otto's latest posts carefully. He just lost in discussion, almost called me a liar, and then came with some turd crap, what I did not read at all. Not in mood for jokes or whatever, while we are so low in communication. Typical behav. - no arguments anymore - change subject, pull out something new.

And what is most pathetic in all this - adding that support in form to return same d0, as all TOS versions do is so little work, that it could be done already 10x since we talk about issue. That would not harm anything. But no, we will not do it, because AtariZoll would like it. I don't care in fact. As said, this was not because I plan to use EmuTOS, or even include it in supported TOS list. I learned my part - no more error/bug reports to Hatari and EmuTOS folks. I have better things to do.

[wongck]

Seriously though, the way I understand Emutos' scope is that it is not trying to recreate TOS but rather it tries to be a better TOS compatible OS for our Atari systems.

With that in mind, the Emutos team needs to aim at better compatibility but at the same time, that should not include turning bugs into features.

I do not get these sentences... ok before someone flame me... English is not my 1st language.
Removing something being used is not being more compatible.

[christos]

Seriously though, the way I understand Emutos' scope is that it is not trying to recreate TOS but rather it tries to be a better TOS compatible OS for our Atari systems.

With that in mind, the Emutos team needs to aim at better compatibility but at the same time, that should not include turning bugs into features.

I do not get these sentences... ok before someone flame me... English is not my 1st language.
Removing something being used is not being more compatible.

Neither is mine, i am just translating. In short Emutos is not TOS and TOS bugs should be included only if many people used them as features. If it is just one developer...

[troed]

I know 100% that I'm 100% right.

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.

This is not about is that behavior of Ikbdsys such by design, or is some side effect. It is just about who is smarter, who knows TOS better.

...

Thanx for noticing it. How I mixed it up ? Probably bad DOCs

infallible
adjective in·fal·li·ble \ (ˌ)in-ˈfa-lə-bəl \
: incapable of error : unerring


(... although I would agree with other commenters that if there exists other software, written "back then", making use of the same unintended use of the internal variable - maybe Emutos should happen to leave the same value there as well)

[joska]

Removing something being used is not being more compatible.

It is not about removing something, but changing EmuTOS code to satisfy one person's dirty (yes, dirty. Disassembling TOS to find undocumented vectors/hooks/variables to exploit is *not* clean) code. There are so many dirty tricks used, especially in games from the 80's, that it's virtually impossible to create a TOS clone that will work with all of them. An alarming amount of "professional" made games for the ST was made by programmers stuck in the 8-bit world, where poking into undocumented system variables and vectors was a necessity. The result was that software stopped working as soon as new hardware was available. In the case of the C64 even something trivial like a revised floppy drive was enough to break games.

While it's perfectly possible to program this way on machines like the ST and Amiga you'll still run into problems when new hardware (like the 1040 with 1Mb! Or STE.) or software (TOS 1.04, EmuTOS...) came out. Of course, the problem here is that TOS is not suitable for action games. E.g. there is no system function at all for reading the joystick, except for hooking into the IKBD handler. You *have* to circumvent the OS to be able to make games. Today we know just about everything about these machines so it's possible to write clean software that works across different OS-versions and even different OS's.

AtariZoll does of course know more about this than most, considering that he has patched/fixed hundreds of games for the ST. In light of that I find it odd that he chose the implementation he did, but that's his choice. He's the programmer, he decides the code.

[AtariZoll]

Yes, you can blame programmers for crappy code - in many cases - there is lot of it indicating that coder was on Z80 or similar CPU - doing test on data reg after moving in it (where 68000 already set flags). And many other ... But part of problems is clearly to blame DR for. Poor documentation, Trap calls are not organized well.
There is unused space in sys. variable area, some 100 bytes, + area $600-$700 is not used at all, not even on TT and Falcon. And yet, they did not place all those variables for reading kb. , mouse, joystick in that, well defined area, but elsewhere in low RAM, different locations in every TOS version. Instead it, they introduced those 9 IKBD vectors, which basically just read variable and copy in (a0). Combine it with poor docs, missing detailed explanation - and we are at SW coders forced to do dirty coding - using those sys. vars at not globally defined addresses (STOS - made by very good programmer) .
Note about that 1MB RAM machines were problem is little over top, failing on it is really crappy coding of programmers - and there are variables to see real RAM amount very easy - PhyStop. Even if it is forged, you can read Mem control shadows in sysvar. area.
TOS is not best for action games, but it is not true that is not suitable. There are plenty of very quality games using TOS calls: Starglider, almost all Silmarils games ... at least 200 top quality. Not true that no function for joystick read - and I showed in this thread how easy is to use it. Only that programmers missed it somehow in 80-es. Of course, it would be peace of cake if they put joystick read results in regular sysvar. area.
Then, something really unexpected changed, as result of bad planning: moving TOS ROM address in STE higher.
Starting to use Timer C in TOS 2.06 for Trap #1 file access calls. If Timer C is changed, it will freeze or whatever when trying disk access. Who to blame for that sudden change ? Was Timer-C reserved for future usage ? I did not see anything about it. Even if it was, programmers seen that it is unused in TOS 1.00-1.04, so they grabbed it for better work of SW. Why should not ? Because some misty future plans. Not to mention that is easy to add patch, what will restore regular Timer-C before disk access.

We can talk here for months. You can't convince me that TOS self is cleanly made. Right this mess with IKBD read is good bad example
Doing clean SW what works on all TOS versions is possible. Until it is not much complex, and does not need some special things. Then you need some direct HW access, what is not that clean, and is problem for many programmers.
Anyone remember DR Basic, supplied with early Atari STs ? Shiny example of poorly made SW.

[Eero Tamminen]

Now, because this talk making no progress here, and I'm almost called liar here (not believing that VDI calls are used a lot in AUTO SW), then because some other bad things.

Please read my post again. I said that I haven't seen such calls myself, not that I wouldn't believe you.

Why I haven't seen them, might be because:
* Early Hatari versions supported VDI tracing only for extended VDI modes. Most demos don't work with such modes, and games could have problems with them too, so using Hatari VDI tracing for them wasn't possible
* As I haven't even thought that more professional non-GEM programs would use VDI calls, I normally don't do VDI tracing for them. When looking into problems that games have with EmuTOS, I normally start from tracing GEMDOS calls, and if that doesn't help, also BIOS & XBIOS calls. And if even those don't show what goes wrong, only then I trace rest of stuff (rest of OS calls, IO register calls etc). If the VDI calls aren't a problem, I might also miss them from the trace output
* I trace most programs when running them from Hatari GEMDOS HD / C: root, if they just work from there. This is because programs load much faster that way (than if they were started by some AUTO-loader from emulated floppy). I don't / haven't considered programs that work also when started directly from C: root, as AUTO-programs

If you happen to remember any commercial (non-GEM) games that would do VDI calls, I'd appreciate if you could mention them. I'm very curious to find more about them!

(Reason for my curiosity is that I've maintained EmuTOS games/application compatibility list, and debugged what problems many of them have had. I think most of older EmuTOS releases bugs.txt file content actually came from my bug reports to EmuTOS devs.)

Note: I wouldn't be surprised if some PD / hobby games compiled with one of the Basic variants available for Atari would mix VDI and lower level stuff, many of them aren't programmed very cleanly. Those aren't something that need to be started from AUTO though.

PS. thanks for taking so civilly my attempt at trying to tweak your nose / making a bit of fun out of the thing you were complaining about!

[wongck]

Neither is mine, i am just translating. In short Emutos is not TOS and TOS bugs should be included only if many people used them as features. If it is just one developer...

you speak of one developer, but one developer can be better than a whole bunch.... because one developer may have created more programs than the whole bunch put together.... so it is utter nonsense by saying only one developer.... it should be how many software uses it.