joska wrote: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.

Again.... I do not understand these sentences. Sorry Joska, you are a great guy, but why do you contradict yourself in your own post ?? So by REMOVING this undocumented/ exploit, so many games form the 80s will fail. That's breaking compatibility.

Again... mentioning changing code to satisfy one person's dirty programming.... and then saying many dirty tricks used in game.... don't you mean to satisfy ALL those programmers ??/ Surely more than one person is invoked.

wongck wrote:So by REMOVING this undocumented/ exploit, so many games form the 80s will fail. That's breaking compatibility....Again... mentioning changing code to satisfy one person's dirty programming.... and then saying many dirty tricks used in game.... don't you mean to satisfy ALL those programmers ??/ Surely more than one person is invoked.

Unless I miss the point here...

I guess you do.

It's not about breaking hundreds of old games that used a contemporary "undocumented-but-well-known-to-everybody trick" (EmuTOS already supports quite a few things of this kind), it's about breaking games that AtariZoll modified to use his "hey-I-recently-found-this-to-work-by-chance-super-cool-and-docs-are-for-lamers trick" (and to my understanding - at least according to one of the initial posts - they still work on EmuTOS - as you just need to move the mouse instead of releasing a key at startup).

So - as things look right now (from my personal point of view) - it's not at all about breaking old software, it's about if EmuTOS should support rather current "I know better than others since I have a disassembler"-attitude dirty coding tricks of one single person.

Anyway, I'm sure if we can make more sense of the (confusing and rather inconsistent) "side effect return value" Atari TOS shows at this specific place, if the outcome appears to show reasonably clear intent that Atari wanted it to work this way (and just "forgot" to document it) and if there is a way to implement a reasonable solution without breaking other things, a change will be seriously considered.

christos wrote: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.

We are speaking about one piece of software copied multiple times. Also nothing is removed from EmuTOS. We are talking about adding something. It is a situation similar when TOS 1.04 was released. It was better but some programs wouldn't run because they exploited bugs and undocumented "features" of earlier versions. By your logic, those bugs should have been perpetuated to infinity. When a new Windows version is released the same exact thing happens. It's OS evolution.

And again, what everyone is saying is that if it's shown that this exploit was commonly used or that this was the intended behaviour of TOS and not a side effect of bad code, it will be included in the next version. And I have an example for this. Qextract uses shel_read() to get path information and that was not correctly implemented in EmuTOS. It was immediately fixed because that was what it was supposed to do.

mfro wrote: ..... it's about breaking games that AtariZoll modified to use his "hey-I-recently-found-this-to-work-by-chance-super-cool-and-docs-are-for-lamers trick" (and to my understanding - at least according to one of the initial posts - they still work on EmuTOS - as you just need to move the mouse instead of releasing a key at startup).So - as things look right now (from my personal point of view) - it's not at all about breaking old software, it's about if EmuTOS should support rather current "I know better than others since I have a disassembler" attitude dirty coding tricks of one single person. Anyway, I'm sure if we can make more sense of the (confusing and rather inconsistent) "return value" Atari TOS shows at this specific place, if the outcome appears to show reasonably clear intent that Atari wanted it to work this way (and just "forgot" to document it) and if there is a way to implement a reasonable solution without breaking other things, a change will be seriously considered.

Yessss !!!! This shows the essence of whole this discussion: Dear Mfro, I bought Atari ST Profibuch same day when I bought my first Atari ST - another 70 DEM spent. And I used it from very beginning - for HW expansions, designing them, and much more for SW. After couple months I has some utils for own usage, written in ASM. And must say that I seen limitations of TOS already in this first months. Made special tool, named COPYACC, what was combination of RAMdisk and copy SW. I was not happy with speed of XBIOS functions for floppy access, so I did direct FDC code - and I would be not able for that without ProfiBuch. Remember - it is still 1987, no Internet, no any literature in my land, only couple magazines, which sometimes published few Atari ST related articles. Well, so much about my "docs-are-for-lamers" . And yes, I seen some errors in ProfiBuch at that time too.

I don't use disassembler, but Steem Debugger what is complete different category. You should know it if reading my post earlier.And another history fact: I received 6-th place in 1984 Yugoslav (the old, 'big' one) programmer competition. Program was for Sinclair Spectrum, called MC Tracer - so you should guess for what was. It was just my first serious SW ever. Of course in Z80 ASM, whole thing was short, took me some 3 months.And there is no disassembler in it at all. It displayed only machine code in HEX. I knew that it would be better with displaying mnemonics, but that was what I was able to do until deadline. And then they added another 2 months, in Winter period - I could add that disasm, something simple, but I had my work, and season of it. I guess that I could be 3-rd with 'mnemonic' v. Only one more detail: I used during development program (in current, unfinished stage) to debug self

Do I need to repeat already said here - that there is return value of Ikbdsys, and it makes pretty much sense ? Yes, I found it by tracing, and actually I don't think that I disassembled at all. This thread is first time I looked code in case of key release, and posted here. Code for keypress case is longer.

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.

I put here my old blog kind page, not linked on my site from some reason:Yes, not really on topic, but some people made me do it, and I want to show about what things I care by programming.There are some silly mistakes in - like framerate instead samplerate, but I will let it as is. I'm only human, I make mistakes.

"Making fastest possible code

This is as side result of my recent making of audio background player for Atari STE, and of course with all my long term experience with programming.

What makes code fast, or better said executing fast ? Generally: using fast instructions, and as little times as is possible. Good algorythm and concept. From first statement results usage of Assembler - then code overhead may be minimal. Compilers can not make so efficient code as experienced human. Usage of ASM is especially welcome on slow machines as Atari ST serie.

The concrete case: audio samplerate conversion on-fly : Hippy Dave on Atari forum posted his code for doing samplerate conversion with comment that final goal is audio CD playback on STE machines. He meant for sure not usual way: using CD ROM drive's audio output, but playback via STE DMA audio, using digital audio data from disk. Regular CD data rate is not too big, some 160 KB/sec. Parameters are: samplerate 44100 Hz, Stereo, 16-bit PCM, signed. But STE (and TT, Falcon) have different samplerates : 50066, 25033 etc. So, framerate conversion during playback is necessary (or in case of extracting CD audio for later playback from Atari hard disk). Quality conversion needs pretty much calculation, as framerates are not dividable. I said in that discussion that on-fly samplerate conversion is not possible, even not with 16 MHz CPU. I was wrong. It is possible, even with 8 MHz CPU (STE). But it is on limit. Uses about 80 % of CPU time, so not much left for load from disk. Concrete: over 1100 KB/sec transfer rate is required for flawless playback without breaks. UltraSatan may achieve it, but not with all SD cards. 1GB Kingston what I have can 1170 KB/sec, and it plays well. But if you move mouse intensive it will repeat part of WAV as result of too much total CPU load . To achieve this, a lot of time was spent and many things changed in original code. + it is result of little luck: I did testings with regular MS WAV file, what is same format as CDA . Luck is in fact that byte order is reversed (Intel), what saves come cycles by reading src. data. In first time as benefit I considered signed format too, as it saves also some cycles by conversion, but I think now that it is not relevant when use precalculated table - as it can be made with unsigned-signed conversion included.

How it went: First step is usually establishing algorythm. For quality samplerate conversion. I thinkered following method (don't know is it used by some SW) : Making time-scale, where we have sample points of src. and sample points of dest. , which are of course on different positions. In first variant I choosed 16-bit time scale for better quality. Then , as in our case dest rate is bigger we will have src. sample points on every 65536th pos. Dest on every src/dest rate x 65536th pos.It means that we need only one multiplication in calculation, and instead even slower division we can use fast swap command (as division is by 65536). The dest sample value will be weighted average of 2 adjacent src. sample points. Of course closer to value of closer point, in proper ratio. I think that it is pretty good method, and not too much CPU demanding. May be not accurate with very high frequencies , but whole digital sampling with 44100 is not accurate too with high freqs.

This worked faster some 30 %. Quality was same, I guess. In any case, by using 8-bit time base, tempo error is still less than 0.5 %. And samples are max. 8-bit in dest. Next, logical step was usage of table with precalculated output values. Required table size is 64KB, as result of 2 x 8-bit variables: sample point and value (diff. in fact). It made most of speed gain.

It was almost good for on-fly. And code had still place for improving :The 'slow' parts: 1. Reading src twice . 2. beq.s ch1Same takes too many cycles., while in most cases is not same . 3. move.b 0(a3,d1.l),d2 ; add.b d3,d2 seq can be replaced with one add. only . 4. Buffer end testings take too much CPU time, as doing them after every 2 written dest. bytes, while buffers are much bigger (64KB). Latest was hardest to solve - main problem was that src and dest are asynchron.

Phases are intruduced, and end test goes only after 8-bytes of dest. written. Code for sync. buffer loadings is now pretty long, but it executes very rare. Speed is gained by decreasing instruction count in often repeating parts. No more mono-stereo test, as it takes too much time too. Code only for stereo. For mono needs just slighty different one. But size of code is almost 3 x bigger. Still, not too much - conversion part about 1KB.

Further things affecting speed: The way how GEMDOS loads data from hard disks: it tends to do it as fast as possible, but must care that supply only so much data as is asked - to prevent overwriting user program's space where code, data may be. If SW asks only 123 bytes, GEMDOS will write only so much to dest. But loading from hard disks goes different - only complete sectors can be readen. So, GEMDOS uses sector buffers for cases of less data needed. Then driver loads not to dest, but in sector buffers, and GEMDOS copies from it to dest as many bytes as asked. All it is slower than direct reading from disk to dest. And we need max possible speed here. Solution is to load always data chunks of size multiple of sector sizes. Even better, multiple of cluster sizes. Start position of data inside file must be also on such pos - multiple of cluster size. Then always, data will go direct to dest, what is fastest possible. In practice it was so: There is 44 byte long header in regular WAV files. When I was made player with on-fly conversion, table variant 1, player loaded 44 bytes to get parameters, and after that started palyback from pos 44. With UltraSatan used, close to limit there was 2-3 case of break during 3 minute song. After correcting code in smart way - replacing header data in buffer with silence and therefore having perfect audio data align at pos 0 practically: playback was flawless on STE with UltraSatan. It was with 48000 Hz source btw. Probably with 44100 src. it would play well even with 'bad' align. But we solved it for 48000 too, thanx to smart programming, and knowledge about how system works.

Well, first 3 does not seems too attractive: using CD drive's audio output is better way, I guess. Storing 16-bit WAV files on Atari drives takes 2 x more space than in STE format. Maybe CDA grabbing is something really useful - as it can go really fast, together with conversion in proper, space saving format. But it needs fast CD ROM and fast driver SW. In case of interest, I will do necessary program variant for that purpose - with direct playback option, together with necessary speed test tools. But very likely there will be problem with byte order - what means less speed.

Download test version Usage: this will work correct only with CDA format audio : 44100 Hz, Stereo, 16-bit signed. Such files are with CDA, BIN or RAW extension - then no header. Or MS WAV with same params - then there is a header too. MS WAV may be 48000 Hz too. Name file TEST.WAV or TEST.RAW (later for RAW or CDA). If both names are present in DIR, WAV will play - as long it is, then just exit. If only TEST.RAW present, then it will play, of course. This works not together with background player - deinstall ACC before run . Needs 256KB free RAM and no any background process active (full CPU time). Will start playback after some 2 sec pause - table building is slow. In later versions table will be just loaded from disk. By me it worked without any slowdowns, repeats on 8 MHz STE, from UltraSatan and fast 1GB Kingston SD. From CF cards attached via CATA and ACSI-CF adapters. But as already mentioned it is very demanding considering hard disk and driver speed. May check what your system can with: hard disk performance tester . Sound quality is good, although I have some clicks on STE, while no on Mega STE (where sounds better btw. - at 8 or 16MHz) or in emulators. Very likely some HW problem in STE- age related.

P. Putnik, Latest update: March 2011. "

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.

[... ignoring song of own praises, all of us have some history, some need to talk about, some don't. Know this: nobody is challenging your ability as coder, no need to proof or self defense, the only thing that's doubtful is your attitude ...]

AtariZoll wrote:... that there is return value of Ikbdsys, and it makes pretty much sense ...

I might be wrong (all of us are at times), but according to my personal observations so far, it's not (if it would, it probably would be a no-brainer).

The value appears to be something intermediate, something half-chewed, half eaten (move the mouse while pressing a key on the numeric keypad with ALT and you might see what I mean) and it seems to be inconsistent across TOS versions (other than you, EmuTOS cares about later TOS versions). And it still requires some more investigation.

Last edited by mfro on Sat Dec 16, 2017 9:25 am, edited 1 time in total.

I said at least 4x here that it is same in all TOS 1.00-4.04 - release is negative, pressing is positive. Yep, not always. Forgive me Atari people that I did not see that some non-English key press will return negative value, in SW in English language.Ah, and that changes not the whole thing - EmuTOS acts not like TOS 1.00-4.04 in something. If it would be acting in better way, that would be OK. But it acts worse. Amen. Really don't see why we should continue this ...

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 said at least 4x here that it is same in all TOS 1.00-4.04 - release is negative, pressing is positive.

That's just not the case. It is only true if a keypress/keyrelease was handled, and even then there are cases where that assumption is wrong (already explained that pressing some non-ascii key will also return a negative value; releasing the ALT key while you were entering an explicit ASCII code using the NUMPAD will "return" that ascii code etc.). And what's even more important, if you get something else than a key event, the "return" value will be something completely different.

Nothing new is said, again. If on screen says that user needs to press some key to continue, why should my SW care about some special cases ?It does not continue when mouse is moved, only in case when you hold some key pressed. Who will do such thing ? As said, nobody complained that it works not well. There will be nothing else in normal usage. You should instead this useless talk to decide what to do: ignoring that undocumented Ikbdsys, or do something heretic: disassemble, trace, etc. Then do own code what acting same, with same d0 at ret.

Considering VDI call in AUTO run SW: one of it is game Pengy .Better example is Swiftar: http://atari.8bitchip.info/ASTGA/S/swiftar.phpIn Swiftar you may see how joystick work for all TOS versions is solved and some other 'dirty' things. Just don't ask me why it is as is. Please trace it self.But I can post you source (ASM) of floppy version launcher (where joy. support is visible too), if you need it.

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.

No! You must read more carefully. It's not a case of REMOVING anything. It's a case of ADDING code to support a hack.

ADDING code to EmuTOS means that EmuTOS grows in size. Remember, EmuTOS has to fit in ROM. There's already very limited space left, especially in the 192kb version which has lot of functionality left out. Now, what should one spend the remaining bytes on? Features/actual bugfixes, or a workaround for a hack that so far only seems to be used by one single developer?

joska wrote:No! You must read more carefully. It's not a case of REMOVING anything. It's a case of ADDING code to support a hack.ADDING code to EmuTOS means that EmuTOS grows in size. Remember, EmuTOS has to fit in ROM. There's already very limited space left, especially in the 192kb version which has lot of functionality left out. Now, what should one spend the remaining bytes on? Features/actual bugfixes, or a workaround for a hack that so far only seems to be used by one single developer?

Funny that you say "read more carefully" - really, really should read some posts back before great conclusions.

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.

"or a workaround for a hack" - It is not hack. Ikbdsys is function with return in d0 (as usual). It acts same in TOS 1.00-4.04 . Well, at least acts mostly like. I did not test for all user actions, and I will not. If EmuTOS emulates for instance TOS 3.06 (what is almost same as 2.06) then it would be good compromise.And is not true that it needs lot of space. Actually, all those functions are chained in TOS. So, EmuTOS should follow that concept. But maybe it is too dirty for their taste ? Not that I care at all will it be implemented or not. I reported something incompatible, not because I need EmuTOS. And I noticed error after only 5 minutes of test. Now, I will not spend here 5 months with trivial thing discussions.

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.

IT IS A HACK! No, the fact that there is something in D0 does not mean that it's a part of the API. You seem to conclude that it is, simply because this value makes sense under certain circumstances. The fact that it's not documented anywhere does not matter, according to you that's because the docs are wrong.

AtariZoll wrote: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.

Your understanding of Schrödinger's cat is on level with your understanding of clean programming. Or maybe there is a joke in there that I don't understand.

Thanx for commenting my signature Can you elaborate why is it on level .... ?

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:Do I need to repeat already said here - that there is return value of Ikbdsys, and it makes pretty much sense ?

- EmuTOS ikbdsys does not return anything meaningful, because it considers this is not necessary to be compatible with TOS.- AtariZoll's game adaptations expect that ikbdsys returns a negative byte in d0, in case of key release.

So we are stuck.

Here is a solution. This is a TSR named FIXPP.PRG. It reimplements ikbdsys to fit AtariZoll's expectations Run it before the game (from desktop or AUTO), then run the game.

PS: This is very alpha stuff, just a proof of concept.

You do not have the required permissions to view the files attached to this post.

AtariZoll wrote: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.

Your understanding of Schrödinger's cat is on level with your understanding of clean programming. Or maybe there is a joke in there that I don't understand.

Yeah I've kept my tongue about that one so far. I guess the irony is obvious to anyone but the "I know 100% that I'm 100% right" infallible AtariZoll.

(Can a moderator please clean the whole AtariZoll-discussion from this thread and move to its own? I like the thread for the discussion on why hacks aren't APIs, but it's unnecessarily polluting the great work that is Emutos)

AtariZoll wrote:Thanx for commenting my signature Can you elaborate why is it on level .... ?

Because your signature shows that you don't understand it. The Schrödringer's cat thought experiment is not about a cat at all. It's a paradox that exemplifies Erwin Schrödinger's objections against quantum physics. When applying quantum physic logic to this thought experiment, the cat must be both dead AND alive until you open the box and check it, which - as you correctly point out - is not possible. The "better logic" you demand is the very essence of this thought experiment.

BlankVector wrote:...Here is a solution. This is a TSR named FIXPP.PRG. It reimplements ikbdsys to fit AtariZoll's expectations Run it before the game (from desktop or AUTO), then run the game.PS: This is very alpha stuff, just a proof of concept.

You mean, those who want to play my adapts, later 600 ones under EmuTOS to use it . Isn't simpler to just move mouse ?

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.

joska wrote:... The Schrödringer's cat thought experiment is not about a cat at all. It's a paradox that exemplifies Erwin Schrödinger's objections against quantum physics. When applying quantum physic logic to this thought experiment, the cat must be both dead AND alive until you open the box and check it, which - as you correctly point out - is not possible. The "better logic" you demand is the very essence of this thought experiment.https://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat(Edit: Quote missing.)

Yes, I saw that wikipedia article. Things are that there are different explanations about whole 'lets kill poor cat in name of science' . What I wanted to say is that some state is always defined. No it is here or there. We may be not able to follow it, see it, but it is always is some defined state, position. Maybe I should talk about quantum physics nonsense, but this looked more attractive. Yep, another case for Joska, to be happy how stupid I'm

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.

No! You must read more carefully. It's not a case of REMOVING anything. It's a case of ADDING code to support a hack.

Ah yes, thank you for clarification.This just means that NEWTOS or what you call EMUTOS is not compatible because new stuff is needed to support an hack that was working in old TOS.

joska wrote:ADDING code to EmuTOS means that EmuTOS grows in size. Remember, EmuTOS has to fit in ROM. There's already very limited space left, especially in the 192kb version which has lot of functionality left out. Now, what should one spend the remaining bytes on? Features/actual bugfixes, or a workaround for a hack that so far only seems to be used by one single developer?