Any reason to use assembly on the Amiga rather than C?

[meynaf]

Originally Posted by Thomas Richter

Forgive me if you complain about problems on the Os, yet at the same time refuse to get updates to have them fixed.

Oh yeah ? But would the problems i report really be fixed ? I don't think so.

Originally Posted by Thomas Richter

Correct - That is exactly the mentality that creates robust programs. Your approach makes me shudder. Indeed, if you do not program against interfaces, you create instable fragile code, which is exactly the problem many Amiga software has, and a approach many assembly programmers seem to follow. Junkware is the result.

I do program against interfaces. But when said interfaces fail, i address lower level interfaces.

Originally Posted by Thomas Richter

Of course it can do it - just do it right. Example: DeluxeMusic uses the audio.device and plays four channel music just fine. Ooops!

Are you sure it plays notes with audio.device ? You have source code maybe ? You disassembled it ?
Supposing it really does, are you also sure it never misses notes on accelerated machines ?

Originally Posted by Thomas Richter

All people should stop using junkware. Of course you can play protracker songs. Protracker is just a music format - just use a right player. Advantage: It would probably also play over custom audio hardware. If the protracker software bangs the hardware, then that's just junk indeed.

The problem is that if you don't bang the hardware, you won't play it correctly. Long ago Peter Kunath (author of Delitracker) tried to write an audiodev-noteplayer and it failed. This is mentioned in the docs.
If you think you know better, just write one that works.

Originally Posted by Thomas Richter

Then talk to those people that work on the interface. As simple as that. It is not *your* decision how the interface looks like.

Right, it's not *my* decision how the interface looks like. Therefore if it's done in very poor and very stupid ways, i don't use it.

Originally Posted by Thomas Richter

Of course it does not mention that "it is impossible to play protracker songs". Right simply because it isn't. The interface is not about "formats". It is about "here is my sample, play it", and the interface can do it. If you have reasons to believe that it cannot do it (I don't), then report the issue and get it fixed. That's about all.

I did not pretend it had to play protracker songs directly.
But when you use a protracker player, you have to bang the hardware. If instead you try to play notes with audio.device, it will fail. So the proper way to do this, is to reserve channels with audio.device, and then play notes with direct hw access.
Now maybe you want to do it "correctly" and surprise all of us by your great knowledge ? I have a ptk replay routine at the ready, in which audio access is well isolated. I could give it to you and you plug audio.device in.

Originally Posted by Thomas Richter

I do not know about lower limits of screen sizes, but it should gracefully fail if the parameters are improper. If it does not, that's a defect you should report to have it fixed.

It does not gracefully fail. It crashes badly. During all that time, no doc i've had access to say anything if this is improper parameters or not.
So yes perhaps i should report it to have it fixed, but where's the point ? My picture viewer had to work around it to be able to show those stupid dummy 1x1 GIFs that are (were ?) sometimes found on web sites, and i don't want to tell users they now need a much higher OS version to run it. It starts with V39 and that's already much.
Same situation as the OS not liking narrow viewports in lowres and generating bogus copperlist. This got fixed in V40 but i still had to work around it as it is not my target.

Originally Posted by Thomas Richter

It is written that OpenScreen() fails with a NULL return code if it does not like your parameters. That is all you need to know. There is an error code even that provides you with details *why* an OpenScreen failed if you care about details.

That would be fine if it just did that. But in this case it does not fail with NULL. It crashes.

Originally Posted by Thomas Richter

No, I'm against "features that are gained by bypassing or violating Os interfaces".

The correct solution would be to list them and provide new Os interfaces to give proper support. Then, retrofit them to older OSes by providing them in a separate library.

Originally Posted by Thomas Richter

And that is exactly a dangerous approach that makes me shudder. The current Os version is 3.2, BTW.

Why is that dangerous ? Addressing to a lower level OS layer isn't exactly a violation.
For example, as intuition.library does not provide transparent blitting, i use graphics.library instead. Missing feature that had to be fetched at another place.
Another example, even though the OS provides buffering for file i/o, it ends up faster doing buffering by hand inside of the program. OS too slow, do things yourself instead.

Originally Posted by Thomas Richter

Then write software that is.

I do.

Originally Posted by Thomas Richter

Of course, that is hard to do in assembler which does not enforce a structure, interfaces and architecture, and that brings us back to the discussion. It is an utterly bad language to express architecture. Of course what higher levels offer is "syntactical sugar", but that "sugar" is it that allows the compiler to check if you "play by the interfaces", even if it is something as simple as passing the right arguments to a function. Even such simple things an assembler cannot check.

We've had this discussion before haven't we ?
What higher levels offer isn't worth (again, in the context of Amiga programming). They remove features, give slow and big code.
Thanks but no thanks. I want to be in full control of what the program does. Only asm provides this.
I don't want your "sugar". It's bad for my teeth.

[Thorham]

Originally Posted by Karlos

I don't know about that. Python has some charm.

Significant indentation and floor integer divisions are anything but charming.

Originally Posted by Bruce Abbott

depending on who you ask

Indeed: https://spectrum.ieee.org/the-top-pr...languages-2023

[Karlos]

Originally Posted by Thorham

Significant indentation and floor integer divisions are anything but charming.

I'll take these over the bumper pack of wooly typed, non-transitive moronity and list of legacy quirks that plague JS, any day.

JS doesn't have problems with integer division for the same reason I don't have problems eating with a beak. I don't have one and likewise, it just doesn't have integers. All Number instances are only required to be IEEE floating point. Sure, there's typescript, which tries to put a veneer of type safety on it, but it's about as effective as lipstick on a pig.

How many other language runtimes can you name where sorting an array of numbers operates in "alphabetical" order of their string representation by default? And you can't even blame that on it not having integers.

[Thomas Richter]

Originally Posted by meynaf

Oh yeah ? But would the problems i report really be fixed ? I don't think so.

Er, what? Have you actually tried?

Originally Posted by meynaf

Are you sure it plays notes with audio.device ?

Yes. And that because I made bug in the audio.device in v45. Yikes. It played again with the bug fixed, and no, it does not miss notes on my 50Mhz 68060.

Originally Posted by meynaf

The problem is that if you don't bang the hardware, you won't play it correctly. Long ago Peter Kunath (author of Delitracker) tried to write an audiodev-noteplayer and it failed. This is mentioned in the docs.
If you think you know better, just write one that works.

Somebody apparently already has. DMusicII does.

Originally Posted by meynaf

Right, it's not *my* decision how the interface looks like. Therefore if it's done in very poor and very stupid ways, i don't use it.

The "don't use" is one thing, the "band the hardware" is another.

Originally Posted by meynaf

It does not gracefully fail. It crashes badly. During all that time, no doc i've had access to say anything if this is improper parameters or not.

From intuition/screens.h:

/* OpenScreen error codes, which are returned in the (optional) LONG
 * pointed to by ti_Data for the SA_ErrorCode tag item
 */
#define OSERR_NOMONITOR       (1)    /* named monitor spec not available    */
#define OSERR_NOCHIPS       (2)    /* you need newer custom chips        */
#define OSERR_NOMEM       (3)    /* couldn't get normal memory        */
#define OSERR_NOCHIPMEM       (4)    /* couldn't get chipmem            */
#define OSERR_PUBNOTUNIQUE (5)    /* public screen name already used    */
#define OSERR_UNKNOWNMODE  (6)    /* don't recognize mode asked for    */
#define OSERR_TOODEEP       (7)    /* Screen deeper than HW supports    */
#define OSERR_ATTACHFAIL   (8)    /* Failed to attach screens        */
#define OSERR_NOTAVAILABLE (9)    /* Mode not available for other reason    */

Originally Posted by meynaf

So yes perhaps i should report it to have it fixed, but where's the point ?

So, to get it fixed? That is the point.

Originally Posted by meynaf

The correct solution would be to list them and provide new Os interfaces to give proper support. Then, retrofit them to older OSes by providing them in a separate library.

No, the proper solution is to have the patches integrated into SetPatch.

Originally Posted by meynaf

Why is that dangerous ? Addressing to a lower level OS layer isn't exactly a violation.

It is a violation if the higher level does not know anything about that. As in "using layers on an intuition screen". This will not go well if there are also windows on the screen. Or such as peeking the CIAs instead of using the IDCMP port, simply because the later is aware of the input focus whereas the former is not.

Originally Posted by meynaf

For example, as intuition.library does not provide transparent blitting, i use graphics.library instead. Missing feature that had to be fetched at another place.

But graphics rendering calls are supposed to be used on intuition windows, so there is no problem.

Originally Posted by meynaf

Another example, even though the OS provides buffering for file i/o, it ends up faster doing buffering by hand inside of the program. OS too slow, do things yourself instead.

That changed with v47, i.e. performance improved a lot.

Originally Posted by meynaf

We've had this discussion before haven't we ?
What higher levels offer isn't worth (again, in the context of Amiga programming).

At one hand, you say that a software stack creates defects, and at the same time, you refuse to use the tools that prevents such problems. Interesting. It boils down to "only primitive programs can be written with assembler", but that's also what I said in the beginning. Any sufficiently large program *will* be a software stack.

[meynaf]

Originally Posted by Thomas Richter

Er, what? Have you actually tried?

Let's be honest. If i report a bug it might eventually be fixed, but not if i submit a feature request. Especially not many feature requests.

Originally Posted by Thomas Richter

Yes. And that because I made bug in the audio.device in v45. Yikes. It played again with the bug fixed, and no, it does not miss notes on my 50Mhz 68060.

What was that bug ?
That audio.device interferes with normal playing does not imply it is actually used for said playing.
Oh, and next time you try this, also try with older OS versions. Just in case it could have been fixed in the meantime.

Originally Posted by Thomas Richter

Somebody apparently already has. DMusicII does.

What's that ?

Originally Posted by Thomas Richter

The "don't use" is one thing, the "band the hardware" is another.

The Amiga has the advantage that this is possible. Live with it or leave the platform.

Originally Posted by Thomas Richter

From intuition/screens.h:
<snip>

So nothing at alls says it is forbidden to open a 1x1 screen. Thanks for confirming it.
And again, this does not return an error.

Originally Posted by Thomas Richter

So, to get it fixed? That is the point.

That wouldn't be useful for me. My programs still have to work on pristine v39 (or lower when i can).
But if this is important for you, why not reporting it yourself ?

Originally Posted by Thomas Richter

No, the proper solution is to have the patches integrated into SetPatch.

SetPatch is to fix old things, not add new ones.

Originally Posted by Thomas Richter

It is a violation if the higher level does not know anything about that.

So there is no problem. I ask politely before using something.
Not that the higher level always have a way to ask, f.e. you don't need to ask gadtools to build gadgets without it (or layout a menu).

Originally Posted by Thomas Richter

As in "using layers on an intuition screen". This will not go well if there are also windows on the screen.

And ? You can open a screen where no window you don't control are opened. Screens don't have to be public so you can do whatever you want with them.

Originally Posted by Thomas Richter

Or such as peeking the CIAs instead of using the IDCMP port, simply because the later is aware of the input focus whereas the former is not.

Oh yeah. How to listen to joystick input events thru IDCMP already ? Oops, you can't.
Hopefully there are easy ways to know if you have input focus or not.

Originally Posted by Thomas Richter

But graphics rendering calls are supposed to be used on intuition windows, so there is no problem.

Happy to see you agree on this !

Originally Posted by Thomas Richter

That changed with v47, i.e. performance improved a lot.

Nice. But too late.

Originally Posted by Thomas Richter

At one hand, you say that a software stack creates defects, and at the same time, you refuse to use the tools that prevents such problems. Interesting.

There are no tools that prevent such problems.

Originally Posted by Thomas Richter

It boils down to "only primitive programs can be written with assembler", but that's also what I said in the beginning. Any sufficiently large program *will* be a software stack.

As if being large was a quality for a program.

[No.3]

Originally Posted by meynaf

Let's be honest. If i report a bug it might eventually be fixed, but not if i submit a feature request. Especially not many feature requests.

if you place the feature request in the same disrespectful manner as you act in this thread, yes, then quite likely your feature request will be ignored...

Originally Posted by meynaf

What was that bug ?

you know the 3.2 NDK and that it contains release notes?

Originally Posted by meynaf

What's that ?

you are new to the Amiga? Or why don't you know Deluxe Music ?

Originally Posted by meynaf

The Amiga has the advantage that this is possible. Live with it or leave the platform.

it is possible, but Commodore always said not to do this. So it is you who please leaves the platform.

Originally Posted by meynaf

So nothing at alls says it is forbidden to open a 1x1 screen. Thanks for confirming it.

this is not what Thor said with intuition/screens.h

Originally Posted by meynaf

And again, this does not return an error.

I do not know what you are doing, I did a quick test using WinUAE and I could open a 1x1 screen...
You know Enforcer & Co ?

Originally Posted by meynaf

That wouldn't be useful for me. My programs still have to work on pristine v39 (or lower when i can).

if you would code Windows software, it would still run with Windows 3 ?

Originally Posted by meynaf

But if this is important for you, why not reporting it yourself ?

Trolling or what? It is not important for Thor, it is important for every Amiga user that every OS bug gets fixed!

Originally Posted by meynaf

SetPatch is to fix old things, not add new ones.

that's not what Thor said

Originally Posted by meynaf

Screens don't have to be public so you can do whatever you want with them.

I doubt that the NDK or the RKRM agree on this...

Originally Posted by meynaf

Oh yeah. How to listen to joystick input events thru IDCMP already ? Oops, you can't.

Only Commodore knows why the joystick input is available only by the CIAs and not by IDCMP. But this gap does not make all the Amiga programming guides invalid.

Originally Posted by meynaf

Happy to see you agree on this !

And again this is not what Thor said.
You want to do things which are not provided by OS functions? => perhaps you are using the wrong computer system. Even if it is possible, it is not the way Commodore intended the Amiga to be programmed.

So please leave the platform. If you don't and keep on programming the Amiga the way you like to, then please do not blame the OS when your programs don't work with a newer OS version.

Originally Posted by meynaf

Nice. But too late.

too late for what?

Originally Posted by meynaf

There are no tools that prevent such problems.

most likely you are right. Ouh, wait, you fail to open a screen and fail to figure out why the opening of the screen fails...



Thomas, don't you want to spare your time to do something productive ?

[Thorham]

Originally Posted by No.3

you are new to the Amiga?

Originally Posted by No.3

it is possible, but Commodore always said not to do this.

Maybe Commodore should've made sure hitting the hardware isn't necessary.

Originally Posted by No.3

if you would code Windows software, it would still run with Windows 3 ?

Originally Posted by No.3

it is important for every Amiga user that every OS bug gets fixed!

It's not, because not every Amiga user will upgrade the OS to the current version.

Originally Posted by No.3

You want to do things which are not provided by OS functions?

You don't have a choice, because the OS simply doesn't do every possible little thing you might need.

Originally Posted by No.3

please do not blame the OS when your programs don't work with a newer OS version

You do realize that that includes a rather large amount of existing software written several decades ago, right?

[meynaf]

Originally Posted by No.3

if you place the feature request in the same disrespectful manner as you act in this thread, yes, then quite likely your feature request will be ignored...

What ? Cleanup your own backyard before saying this. You're the one disrespectful here, not me.

Originally Posted by No.3

you know the 3.2 NDK and that it contains release notes?

I don't care much about 3.2.

Originally Posted by No.3

you are new to the Amiga?

Yes. Since 1991.

Originally Posted by No.3

Or why don't you know Deluxe Music ?

I tell about Delitracker and this brings back Deluxe Music ? Moot, to say the least.

Originally Posted by No.3

it is possible, but Commodore always said not to do this. So it is you who please leaves the platform.

Many other people must then leave too.
A significant part of the success of the Amiga, even today, is that ability.

Originally Posted by No.3

this is not what Thor said with intuition/screens.h

No doc says it is forbidden, not even the one he's shown.

Originally Posted by No.3

I do not know what you are doing, I did a quick test using WinUAE and I could open a 1x1 screen...
You know Enforcer & Co ?

With what did you open that screen ?
Which software, which OS version ?
Existing software of course avoids doing so, and it might have been fixed after V40.

Originally Posted by No.3

if you would code Windows software, it would still run with Windows 3 ?

No, but Windows 8 probably yes.

Originally Posted by No.3

Trolling or what? It is not important for Thor, it is important for every Amiga user that every OS bug gets fixed!

Most Amiga users won't use the fix. They just keep what they have.

Originally Posted by No.3

that's not what Thor said

But this is what I said. If Thor didn't reply to it, this was OT or a strawman attempt.

Originally Posted by No.3

I doubt that the NDK or the RKRM agree on this...

Then find the parts that say otherwise.
There is a good reason why public screens and private screens both exist.

Originally Posted by No.3

Only Commodore knows why the joystick input is available only by the CIAs and not by IDCMP. But this gap does not make all the Amiga programming guides invalid.

Do not have me written something i didn't write. I never wrote the Amiga programming guides were invalid. Just that sometimes there are "gaps" like you call them here.

Originally Posted by No.3

And again this is not what Thor said.
You want to do things which are not provided by OS functions? => perhaps you are using the wrong computer system. Even if it is possible, it is not the way Commodore intended the Amiga to be programmed.

So many things have been made possible by not using the OS. And now you want to kill all that ?

Originally Posted by No.3

So please leave the platform. If you don't and keep on programming the Amiga the way you like to, then please do not blame the OS when your programs don't work with a newer OS version.

Why are you so aggressive ? What's wrong with you ? You're coming here, inserting yourself in a discussion to troll or what ?

Originally Posted by No.3

too late for what?

Too late for users to switch to newer OS versions. Accept it or not, most of them will just keep what they have.

Originally Posted by No.3

most likely you are right. Ouh, wait, you fail to open a screen and fail to figure out why the opening of the screen fails...

Try to open a screen that's 1x1 under pristine V39 or V40.
Try the average picture viewer targeting those and show such an image, then grab the screen - it won't be 1x1, try to guess why.
And, more important, do not speak about things you know zilch about - and do not be contemptuous like you are currently, or this may well call some moderator in.

Originally Posted by No.3

Thomas, don't you want to spare your time to do something productive ?

No, he prefers spitting on asm.

[Thomas Richter]

Originally Posted by meynaf

What was that bug ?

The bug I did or the original defect? The problem is that the audio.device (due to some Paula idocracies) had to use in some rare conditions a busy-wait-loop to wait for the next horizontal blank to re-initialize the audio state machine. Unfortunately, a busy-waiting loop waits for a variable amount of time given the type of the CPU. One way how to fix that is to access a custom chip address as this synchronizes the CPU to the custom chip clock which is indepenend of th CPU clock. Unfortunately, I read IRQSTAT, and that did not go well with the paula logic. I'm not sure how the fix looks nowadays, but in any event, some hardware register needs to be read there to gain synchronization and get the timing CPU-clock independent.

Originally Posted by meynaf

SetPatch is to fix old things, not add new ones.

These are *old* bugs. Current versions of SetPatch has all bug fixes in there from v37 onwards.

Originally Posted by meynaf

And ? You can open a screen where no window you don't control are opened. Screens don't have to be public so you can do whatever you want with them.

Not "whatever". Only things intuition supports.

Originally Posted by meynaf

Oh yeah. How to listen to joystick input events thru IDCMP already ? Oops, you can't.

No, the joystick does not have an input focus, so IDCMP is not the right tool. The right way to get access to the joystick in a system-conforming way is through the gameport.device. Thus its name.

Originally Posted by meynaf

Hopefully there are easy ways to know if you have input focus or not.

Sure, if you receive messages through the IDCMP, you have focus. There is also ACTIVEWINDOW to check.

Originally Posted by meynaf

Nice. But too late.

So, Os updates are worthless? Oh how sweet.

Originally Posted by meynaf

As if being large was a quality for a program.

Large? No. Fewer bugs. Yes.

[Thomas Richter]

Originally Posted by Thorham

Maybe Commodore should've made sure hitting the hardware isn't necessary.

They did. That some people ignore them is not CBMs fault.

[meynaf]

Originally Posted by Thomas Richter

The bug I did or the original defect? The problem is that the audio.device (due to some Paula idocracies) had to use in some rare conditions a busy-wait-loop to wait for the next horizontal blank to re-initialize the audio state machine. Unfortunately, a busy-waiting loop waits for a variable amount of time given the type of the CPU. One way how to fix that is to access a custom chip address as this synchronizes the CPU to the custom chip clock which is indepenend of th CPU clock. Unfortunately, I read IRQSTAT, and that did not go well with the paula logic. I'm not sure how the fix looks nowadays, but in any event, some hardware register needs to be read there to gain synchronization and get the timing CPU-clock independent.

This is the usual DMA wait issue. Nothing new. And even if it has apparently been fixed in current audio.device, it originally prevented using the OS for any decent audio (and still does if you target these versions).

Originally Posted by Thomas Richter

These are *old* bugs. Current versions of SetPatch has all bug fixes in there from v37 onwards.

By new things, i meant added features, not new bugs.

Originally Posted by Thomas Richter

Not "whatever". Only things intuition supports.

Whatever things intuition supports, if you prefer.

Originally Posted by Thomas Richter

No, the joystick does not have an input focus, so IDCMP is not the right tool. The right way to get access to the joystick in a system-conforming way is through the gameport.device. Thus its name.

Nevertheless in my apps the joystick is ignored when they do not have input focus.

Originally Posted by Thomas Richter

So, Os updates are worthless? Oh how sweet.

Yes the platform is more or less locked in its current state.
It may seem sad, but at least it's not a moving target.

Originally Posted by Thomas Richter

Large? No. Fewer bugs. Yes.

And said "fewer bugs" is better achieved by making things simple rather than making them complex.

Originally Posted by Thomas Richter

They did. That some people ignore them is not CBMs fault.

Emitting guidelines isn't enough if there isn't a set of APIs able to do everything the hardware can.

[Thomas Richter]

Originally Posted by meynaf

I don't care much about 3.2.

If you do not want to use the Os, and neither fixes for Os bugs...

I prefer to keep bugs fixed at their source.

Originally Posted by meynaf

I tell about Delitracker and this brings back Deluxe Music ? Moot, to say the least.

DMusicII, actually. However, you asked whether it is possible - there you go, it is possible to do things right.

Originally Posted by meynaf

Many other people must then leave too.
A significant part of the success of the Amiga, even today, is that ability.

I would rather call that the reason for the demise of the Amiga, namely people not taking it serious.

Originally Posted by meynaf

So many things have been made possible by not using the OS. And now you want to kill all that ?

That, to some end, would be an advantage if people would learn the Os actually works...

Originally Posted by meynaf

No, he prefers spitting on asm.

No, I prefer to spit on people that try to sell asm to me as only useful language. If you read carefully, I *do* use assembler, but only when it's worth doing, and that's not often the case.

[Thomas Richter]

Originally Posted by meynaf

This is the usual DMA wait issue. Nothing new. And even if it has apparently been fixed in current audio.device, it originally prevented using the OS for any decent audio (and still does if you target these versions).

No, it does not. It only prevented the audio.device from getting used on CPUs that did not exist when it was written. That is something "slightly" different. That CPUs evolved is quite natural, and that the Os did not evolve with the CPUs is due to the death of CBM. Hardly the fault of the Os.


There is a similar "delay-loop defect" in the trackdisk.device, which will also not work correctly once the CPU gets fast enough...

Originally Posted by meynaf

Yes the platform is more or less locked in its current state.
It may seem sad, but at least it's not a moving target.

Then move it out of the "sad" state by writing programs for new Os versions. As simple as that.

Originally Posted by meynaf

And said "fewer bugs" is better achieved by making things simple rather than making them complex.

Using proper interfaces and information hiding through a higher language is making things simple. That is exactly the reason for higher programming languages - simplify things.

Originally Posted by meynaf

Emitting guidelines isn't enough if there isn't a set of APIs able to do everything the hardware can.

Oh, and that would be what? Reading the joysticks is *not* an example, and playing audio is *neither* an example.

[meynaf]

Originally Posted by Thomas Richter

If you do not want to use the Os, and neither fixes for Os bugs...

I haven't said i didn't want to use the Os.

Originally Posted by Thomas Richter

I prefer to keep bugs fixed at their source.

Me too, but in this case it's not very useful.

Originally Posted by Thomas Richter

DMusicII, actually. However, you asked whether it is possible - there you go, it is possible to do things right.

That's not the same thing. What i asked for is not some random software playing basic music. It's full noteplayer that can in turn be used to play many formats.

Originally Posted by Thomas Richter

I would rather call that the reason for the demise of the Amiga, namely people not taking it serious.

By the time of the demise of the Amiga, other platforms - even 'serious' ones - were doing the same. Or maybe you think Ms-Dos was enough as an OS ?

Originally Posted by Thomas Richter

That, to some end, would be an advantage if people would learn the Os actually works...

Not using the Os does not mean not knowing it, just that it wasn't able to do the job.

Originally Posted by Thomas Richter

No, I prefer to spit on people that try to sell asm to me as only useful language. If you read carefully, I *do* use assembler, but only when it's worth doing, and that's not often the case.

Nobody asks you to use asm if you don't want to.

Originally Posted by Thomas Richter

No, it does not. It only prevented the audio.device from getting used on CPUs that did not exist when it was written. That is something "slightly" different. That CPUs evolved is quite natural, and that the Os did not evolve with the CPUs is due to the death of CBM. Hardly the fault of the Os.

There is a similar "delay-loop defect" in the trackdisk.device, which will also not work correctly once the CPU gets fast enough...

Something makes me think the trackdisk.device defect was fixed a lot earlier than the one in audio.device...

Originally Posted by Thomas Richter

Then move it out of the "sad" state by writing programs for new Os versions. As simple as that.

Do you realistically think people would move on ?

Originally Posted by Thomas Richter

Using proper interfaces and information hiding through a higher language is making things simple. That is exactly the reason for higher programming languages - simplify things.

Don't be confused - attempting to hide complexity under the carpet isn't the same as actually removing it.

Originally Posted by Thomas Richter

Oh, and that would be what? Reading the joysticks is *not* an example, and playing audio is *neither* an example.

Oh, just 80-90% of games and demos that worked on unexpanded A500. Excuse of the few.

[Karlos]

Don't be confused - attempting to hide complexity under the carpet isn't the same as actually removing it.

It is a necessary first step though. Once the complexity is hidden, you can change the implementation independently of the interface. That allows you to remove the complexity without upsetting any code that only uses the interface.

[meynaf]

Originally Posted by Karlos

It is a necessary first step though. Once the complexity is hidden, you can change the implementation independently of the interface. That allows you to remove the complexity without upsetting any code that only uses the interface.

Right but this is independent of the language.

[Karlos]

Originally Posted by meynaf

Right but this is independent of the language.

Yes. You can use whatever language you want, provided it knows how to talk to the interface.

[Thorham]

Originally Posted by Thomas Richter

They did. That some people ignore them is not CBMs fault.

What about writing directly to screen memory for performance (games)?

[No.3]

Originally Posted by Thorham

It's not, because not every Amiga user will upgrade the OS to the current version.

for historical reasons it is absolutely okay to use AOS 1.0, 1.1, 1.2, 1.3 ..... 3.1.4, 3.2.2. But don't complain about missing features or existing bugs in one of the older versions.

Originally Posted by Thorham

You do realize that that includes a rather large amount of existing software written several decades ago, right?

if you keep to the programming guidelines it is very unlikely that your program will fail with a newer OS version or with new hardware.

[No.3]

Originally Posted by meynaf

What ? Cleanup your own backyard before saying this. You're the one disrespectful here, not me.

Actually it is you who is complaining for over 50 posts how bad the AOS is, how many features are missing, how many bugs there are and how all the missing features force you to bang the hardware, furtherandsoon

As well you are ignoring, carefree wiping away, Thomas well meant advices regarding proper programming of the Amiga.


This comment

Originally Posted by meynaf

I don't care much about 3.2.

is emblematic of your ignorance and resistance to advice.

NDK 3.2 does not mean that it is only for AOS 3.2. It just states that it is the most recent version of the NDK which also covers AOS 3.2 features.
Afterall the NDK 3.2 is also valid and the most recent version for all AOS versions!


e.g. from exec/types.h

/* For compatibility with Kickstart/Workbench 1.x (1985) only!
 * Do not use these in newer code!
 */
typedef short		SHORT;		/* signed 16-bit quantity (use WORD) */
typedef unsigned short	USHORT;		/* unsigned 16-bit quantity (use UWORD) */
typedef short		COUNT;
typedef unsigned short	UCOUNT;
typedef ULONG		CPTR;

or from exec.doc

   NAME
	OldOpenLibrary -- obsolete OpenLibrary

   SYNOPSIS
	library = OldOpenLibrary(libName)
	D0			 A1

	struct Library *OldOpenLibrary(APTR);

   FUNCTION
	The 1.0 release of the Amiga system had an incorrect version of
	OpenLibrary that did not check the version number during the
	library open.  This obsolete function is provided so that object
	code compiled using a 1.0 system will still run.

and there is also valuable information for middle aged to very new OS versions e.g. from dos.doc

   NAME
	ExAll -- Examine an entire directory (V36)

   BUGS
	In V36, there were problems with ExAll (particularily with
	eac_MatchString, and ed_Next with the ramdisk and the emulation
	of it in Dos for handlers that do not support the packet.  It is
	advised you only use this under V37 and later.
	The V39 DirCache variant of the FFS had a bug in ExAll that
	required to first Examine() the lock before passing it to ExAll.
	This was fixed in V40, with a patch in SetPatch.
	The V40 version passed an invalid argument to the dos.library
	error report handler in case of trouble, potentially causing
	crashes or other mischiefs. This was fixed in V47, with a patch
	in SetPatch V45.

Your OpenScreen(1x1) crashes ? Perhaps this helps:

#define AN_OpenScreen	0x84010007	/* open screen, no memory */
#define AN_OpenScrnRast 0x84010008	/* open screen, raster alloc, no memory */
#define AN_SysScrnType	0x84000009	/* open sys screen, unknown type */