What was wrong with the Amiga 1000/500/2000?

[litwr]

Originally Posted by duga

No colour composite output, corrected in A600/A1200. That's about it.

Yes, I had to buy a bulky device for this. However the color composite output is rather useless for AGA graphics.

Originally Posted by roondar

Yes, you are redefining terms. You even admit to doing so in your text here. Your use of IMHO further cements this point. Note here that the Amiga is not the only pre-emptive multitasking system that has limitations when it comes to stopping/killing tasks. Which yet further shows that it's not a function of pre-emptive multitasking by itself.

BTW what was wrong in logic I have presented to you? And you again missed my point. Let me try to explain using a different approach. The lack of resource tracking is an obvious drawback. I hope you agree here. The preemptive multitasking is a part of the system. When a system with the preemptive multitasking doesn't have the ability to kill a process it indicates some flaws in the system architecture. It is obvious that some program can have an error and loop itself endlessly and it is quite natural to remove such a mess from the system. If we don't have the preemptive multitasking the process resource tracking is rather not important. So the absence of the kill-function indicates system flaws. If a whole thing is blue then its parts are blue too.

Originally Posted by roondar

There is no difference in the hardware timers between A500/A1200. They work exactly the same because they are the same chip. Timer code is fully portable between the two, it'll work without any changes.

The OS deals with interrupts slightly differently between version though, which is where your problem comes from. Like I already pointed out: if you let the OS run, don't use the hardware timer, but rather use the OS functions. This is true regardless of the system you choose to program for.

Note here that quite literally thousands of programs that use the hardware timers on the A500 just fine. I've done so myself without any issues.

Leffmann pointed out that "The ToD works fine, you're just missing something". That means he's telling you that your method is flawed. Note also that the in very thread you link to, you did end up with working HW timer code. This also shows the hardware timer works just fine and that it's interactions with the OS that you didn't quite understand that are the issue. Again: don't use HW banging code if you want the OS to run. This won't work on other systems either.

I have to agree, this little problem with timer or rather about ways of its usage under Workbench is rather an interesting quirk than anything else. However if this problem doesn't exist in the A1200 that means that it was fixed and that means that the A500 had this tiny problem. Indeed it is very-very tiny.

Originally Posted by roondar

There is no fundamental difference in difficulty between exchanging old style memory chips and exchanging a ROM chip. It's the literally the same thing (easier for KS roms in some cases as old PC's sometimes only had soldered RAM and KS roms have always been in sockets). As for compatibility, choosing to stick with an old version of the OS is certainly possible. But that doesn't mean it can't be upgraded or this OS upgrade isn't supported by the hardware. So it's not a drawback of the system itself, it's a drawback of choosing to not upgrade - i.e. it's a choice.

You have gone too far away from the initial subject. It is about the flaws in the first Amigas. It is good that people got a way to fix it later. But this serious problem was inherent to the first Amigas.

BTW Amiga books often refer to different ways of newer and older Workbench versions. So it was quite normal that some people continue to use older systems. And this is more true for ROM versions.

Originally Posted by roondar

This is still not true. The A500 manual and advertising (edit: I mean here official material by Commodore) make no claims that memory expansions make the processor run faster. The manual basically only points out that having more memory means you don't need to load as often and that this means your system will be faster overall.

More in depth technical documentation (such as the developer manuals) has always included an explanation of the differences between the various RAM types.

But there was no Slow RAM term in information from Commodore. They told us only about Fast and Chip RAM. My point is around this fact. In addition I can point you to a Commodore ad
The Amiga memory is split into Chip RAM (memory used by the custom chipset to store graphics and sound) and Fast RAM (memory which is used only by the
Processor).
The Amiga A500 can come with 512K or 1M of memory. You can increase Chip RAM up to the maximum of 2Mb and Fast RAM up to 7Mb or 8Mb (depending if you have 1Mb or 2Mb of Chip RAM) to a total of 9Mb.
You can increase RAM by adding memory via a new memory board into the expansion slot underneath the Amiga behind a trapdoor or via the Expansion Port on the left hand side, sometimes as part of another device such as the A590.

Is there anything about Slow RAM?

Originally Posted by roondar

Amiga OS 1.3 CLI does have variables. They just work slightly differently than you're used too. Now, I'll be honest and admit I didn't actually know this (like I said, I don't do much scripting on the Amiga). But on the other hand, I found the answer in about 1 minute of Google time.

Here's part of an example script I copied from another EAB thread I found when Googling this:

IF $choice GE 7
echo "Falsche Eingabe bei der Auswahl des Quell und Ziel Laufwerks."
wait 1
SKIP BACK Question
ENDIF

The above code sets and uses the variable $choice

There is something very odd or even almost appalling about this for me. Maybe I have missed something but I am really baffled. I can't use the $-sign to get variable values on the A500 under WB 1.3. The solid book published in 1991 by Abacus (AmigaDOS Inside & Out) doesn't mention such variables at all! Another solid book - https://archive.org/details/amiga-do...nutzerhandbuch - also misses them. Maybe such variables are a part of an expansion for WB 1.3? Indeed, thank you very much but we need more information about it. These variables work fine on the stock A1200 but they don't on the A500 with KS 1.3 and WB 1.3. There is some mystery around it. I have to ask for help.
Anybody can check this issue using an emulator. Just open WB 1.3 CLI and enter

setenv test 123
echo $test

it should print 123.
I can even imagine that Commodore just published information about new features in WB 1.3 but they didn't implement them. I remember that many new shell features were claimed by Microsoft in 1995 for Windows 95 but they were actually realized only after maybe 2010.

Originally Posted by alkis

Stop trolling.

Why do you react this way? I am just seeking your help. If you know how to use return codes please help me.

Originally Posted by idrougge

What is a normal variable and in what way doesn’t AmigaShell have those?

I have written afore to roondar about the strange problem. I just cannot use $-sign in WB 1.3.

Originally Posted by a/b

Wrong and wrong. You can configure timer B to count timer A underflows, making them work together as a 32-bit timer (65536*21 minutes). On any Amiga. Furthermore, it's called a high precision timer for a reason. And being able to measure long intervals is not that reason.

I have never written that there is no ways to the proper use of timer. Just check my latest reply to roondar.

Originally Posted by a/b

Ambiguous claim, but I'll say wrong and wrong. Generally speaking, system functions don't work with wildcards. Try open(), fopen(), OpenFile(), ... with "*" on any Unix-like system or windoze and report what happens.
Examine() and ExNext() are available on any Amiga.

I can't agree. An application program must provide a user a way to use wildcards. For example, to browse a directory content.

Originally Posted by lilwshu

A2000: Case is the size of a small house yet you can only fit 2x3.5" and 1x5.25" devices in it.

Agreed, the poor expandability of most Amiga models was a real issue.

Originally Posted by alkis

Maybe you want to RTFM?
https://issuu.com/ivanguidomartucci/...ic---ebook-eng page 96

Thank you. But I wrote about a shock when a man, having 1 MB RAM computer, starts Basic and gets that he has only 25 KB free. The necessity of usage of the CLEAR-command almost every time is also annoying. However indeed it is rather a quirk than an issue.

[roondar]

Originally Posted by litwr

BTW what was wrong in logic I have presented to you? And you again missed my point. Let me try to explain using a different approach. The lack of resource tracking is an obvious drawback. I hope you agree here.

Oh, I do agree that the lack of a kill command was not handy. But I don't agree this means the pre-emptive multitasking has a problem. The OS support for resource tracking and supporting functionality for things like stopping tasks, sure. But that really is something different from what you're saying.

I have to agree, this little problem with timer or rather about ways of its usage under Workbench is rather an interesting quirk than anything else. However if this problem doesn't exist in the A1200 that means that it was fixed and that means that the A500 had this tiny problem. Indeed it is very-very tiny.

It wasn't fixed between the various OS versions, you were using the wrong method. For the last time: when you use the OS, don't bang the hardware. If you do and it causes issues, it's your (i.e. the programmer's) problem for not complying with OS guidelines and not a system problem. The system developer documentation explicitly tells you not do this kind of stuff, but instead tells you to always access the hardware through the OS. This advice did not change between OS versions.

You have gone too far away from the initial subject. It is about the flaws in the first Amigas. It is good that people got a way to fix it later. But this serious problem was inherent to the first Amigas.

All right, I accept I went off-topic here. But it wasn't really a "serious" problem. You could easily work around this limit (as pointed out by Thomas) and I never even noticed this limit, nor heard anyone complain about it until you did. To me that shows the issue isn't that big.

But there was no Slow RAM term in information from Commodore. They told us only about Fast and Chip RAM. My point is around this fact. In addition I can point you to a Commodore ad
... cut advert ...
Is there anything about Slow RAM?

No, because for the average user Fast RAM vs Slow RAM was a moot point (it would merely confuse people). I've tried to explain this before but my point was that Commodore never claimed that expanding RAM would speed up the CPU.

Now, Are the terms a bit confusing? Yes, maybe. Is it an actual problem, as you seem to think? No, not really - no one really expected Fast RAM to speed up their system as Commodore didn't claim it would in their consumer oriented documentation.

There is something very odd or even almost appalling about this for me. Maybe I have missed something but I am really baffled. I can't use the $-sign to get variable values on the A500 under WB 1.3.
... removed a bunch of text ...

You're doing it wrong. Under KS1.3, echo does indeed not directly support the use of $variables. Other commands however, do. To print an environment variable, 1.3 required the use of the GETENV command.

I've attached a screen shot of a script that shows that WB1.3 supports the use of $var just fine. Again, this was no more than a couple of minutes of work. I almost never write scripts, but I could get this to work very easily.

[Thomas Richter]

Originally Posted by litwr

There is something very odd or even almost appalling about this for me. Maybe I have missed something but I am really baffled. I can't use the $-sign to get variable values on the A500 under WB 1.3.

The problem with variables under 1.3 is that it is up to the commands to expand them. That is, if there is a $something as command line argument, it would be required (under 1.3) that the executing command detects the $ sign and uses this as an indicator to expand a variable. So, for example, the 1.3 "if" command does include this check, but pretty much every other command does not.


This changed under 2.04 in the sense that it is now up to the shell to expand the variables, and pass the expanded variables into the commands. This has the advantage that more or less all commands now support variable expansion transparently, though the disadvantage of the shell syntax becoming more intransparent and not fully backwards compatible - consider for example how to print a $ sign with "echo".




However, leaving all this alone, there seems to be a serious misconception about the actual hardware, and the operating system. Most of the things you listed here are related to the 1.x Os release series, not to the actual hardware.

[roondar]

Originally Posted by Thomas Richter

However, leaving all this alone, there seems to be a serious misconception about the actual hardware, and the operating system. Most of the things you listed here are related to the 1.x Os release series, not to the actual hardware.

He's not interested in discussing original hardware with OS upgrades. He pointed that out in my exchange with him about upgrading the Kickstart ROM.

I agree with you that the old Amiga's can run the newer OS just fine and that you can choose to simply upgrade them, but there it is.

[litwr]

I have made the next improved list of the Amiga drawbacks:
1) no system functions for working with wildcards - these functions was provided only in ROMs available since 1990;
2) incomplete information about types of Amiga memory: they told us only about Fast and Chip RAM but there also was Slow RAM;
3) no way to use program return codes, only few "standard" return codes are allowed (exactly 0, 5, 10, 20) until WB 2.0;
4) iconx doesn't allow SKIP, IF, LAB, ... until WB 3;
5) the absence of kill-kind command in Amiga DOS worsened impression about Amiga preemptive multitasking OS;
6) no variables in CLI until WB 1.3 and very limited variable support until WB 2;
7) poor expandability of the A1000/500/600.

I also made I list of some Amiga quirks:
1) Amiga OS periodically reset its timer which doesn't allow its direct use for longer than 21 minutes. This was fixed in KS 3 (maybe even in KS 2);
2) standard utility `ask' provides only two return codes and there is no any other standard utility to get information from a user even in WB 3;
3) Basic has only 25 KB free when it starts while even the Commodore 128 has 120K, Commodore +4 has 60K, and Commodore 64 has 38K for Basic. Of course, it is possible to ask for more memory later but the initial low number could shock.

Originally Posted by Thomas Richter

The problem with variables under 1.3 is that it is up to the commands to expand them. That is, if there is a $something as command line argument, it would be required (under 1.3) that the executing command detects the $ sign and uses this as an indicator to expand a variable. So, for example, the 1.3 "if" command does include this check, but pretty much every other command does not.

Thank you very much! You have saved my sanity.

Originally Posted by roondar

It wasn't fixed between the various OS versions, you were using the wrong method. For the last time: when you use the OS, don't bang the hardware.

Do you deny a fact that direct reading of timer works on the A1200? There is a fact that it is problematic in the A500 with KS 1.3. Indeed it is not the best way to use the timer, it is rather a bad way. So this matter is rather not an error in KS 1.3. However if we want to be completely right we need to know why KS 1.3 resets the timer and KS 3.0 doesn't do it.

Originally Posted by roondar

I've tried to explain this before but my point was that Commodore never claimed that expanding RAM would speed up the CPU.

The term Fast RAM implies that it makes a system faster. When you buy a RAM card which is not Chip RAM you assume that it is Fast RAM because Commodore declared that there were only two types of RAM.

Originally Posted by roondar

You're doing it wrong. Under KS1.3, echo does indeed not directly support the use of $variables. Other commands however, do. To print an environment variable, 1.3 required the use of the GETENV command.

I've attached a screen shot of a script that shows that WB1.3 supports the use of $var just fine. Again, this was no more than a couple of minutes of work. I almost never write scripts, but I could get this to work very easily.

Thank you. Thomas has explained these things very well. However this matter was really confusing because authors or very good books about Amiga DOS evaded it.

[roondar]

Originally Posted by litwr

Do you deny a fact that direct reading of timer works on the A1200?

Why would I? It works on the A500 too. But then, I don't try to read from restricted hardware resources while the OS is up.

There is a fact that it is problematic in the A500 with KS 1.3. Indeed it is not the best way to use the timer, it is rather a bad way. So this matter is rather not an error in KS 1.3. However if we want to be completely right we need to know why KS 1.3 resets the timer and KS 3.0 doesn't do it.

No, we don't need to know that. What we need to know if why you feel that programming a computer with a real multitasking operating system as if it's really just a souped up C64 (i.e. pretending there is no OS) constitutes a "quirk" of the system. As opposed to it being something you decide to do that doesn't work properly on any multitasking operating system. You can keep pretending that it's a problem with the Amiga, but the only problem here is your refusal to use the system as intended. Either kill of the OS and access the hardware directly, or use the OS. There are no valid other options.

Sheesh. What's next, a quirk of the OS is that accessing the Blitter directly will likely crash the system? Because that's the exact same thing as what you're doing, just a different hardware resource. By this standard Windows 10/Linux are horrible systems, you can't directly access any hardware on them without running into problems.

Thank you. Thomas has explained these things very well. However this matter was really confusing because authors or very good books about Amiga DOS evaded it.

AFAIK it's in the Amiga DOS manual, but it's been long time since I read that so I could be misremembering. Besides, it took me all of five minutes to figure it out. This happens a lot with your problems with the Amiga on this forum: you do things the way you expect them to be (such as with the timer) and then complain that it's different from what you expect. Often seemingly without doing any research or even just asking questions ahead of time whatsoever. This really sounds more like a problem on your side rather than any system issue.

Note here that at least two of the problems/quirks on your list are issues I've never heard anyone else complain about - and I've been reading mailing lists/news groups/magazines and forums about the Amiga for around 30 years now. Also note that at least one of them has been denied to be true by several other users, but you keep claiming it's a thing anyway (the return code stuff).

[a/b]

What do you expect...
He doesn't understand the difference between system calls/functions and shell commands.
Complains that the car doesn't do what he wants it to do and is therefore broken, while both he and passenger are using the steering wheel at the same time (had to put it this way so he hopefully undestands).
Complains about the lack of modern features in 30+ years old software, instead to comparing it to what was available at the time and trying to understand the context and concepts.
Makes uneducated and bogus claims and then fabricates conslusions.

Either trolling or lacking... in some human aspects.

[alkis]

Originally Posted by a/b

What do you expect...
He doesn't understand the difference between system calls/functions and shell commands.
Complains that the car doesn't do what he wants it to do and is therefore broken, while both he and passenger are using the steering wheel at the same time (had to put it this way so he hopefully undestands).
Complains about the lack of modern features in 30+ years old software, instead to comparing it to what was available at the time and trying to understand the context and concepts.
Makes uneducated and bogus claims and then fabricates conslusions.

Either trolling or lacking... in some human aspects.

+1

I am leaning towards trolling, but yeah it can be both.

[idrougge]

You should keep in mind that from AmigaOS 2.0 onwards, ARexx is part of the system.

Shell scripts are awful on all operating systems, and AmigaOS has avoided going down the ill-advised path of implementing a really bad programming language in its shell, like Bash, by integrating a proper programming language instead.

That also means that the primitive Ask command can be left as is, since if you need more features than that, you have ARexx at your disposal.

[Bruce Abbott]

Originally Posted by lilwshu

A2000: Case is the size of a small house yet you can only fit 2x3.5" and 1x5.25" devices in it.

But it was just the right height to put a monitor on top, and 3 drive bays was enough for most users (Hard drive controller cards generally had room on board for a drive, so you didn't have to waste a drive bay).

If there was one thing 'wrong' with the A2000 that made it bigger it was those PC bus slots, but then I used them to run a PC hard drive controller so...

Originally Posted by litwr

A change of ROM chips is not that easy that memory expansion in the open IBM PC architecture. I know that some people might not change ROM chips because it could make their Amiga less compatible with old software. The IBM PC architecture has been constantly improving but a Commodore 64 made in 1993 was almost the same as a Commodore 64 fabricated in 1982.

That's an advantage not a drawback.

The PC's 'open' architecture resulted in massive compatibility problems, particularly with games. If you bought a game for a C64 you knew it would run on it no matter when it was made, whereas with a PC it was hit and miss.

the color composite output is rather useless for AGA graphics.

I run my A1200 into a TV through the composite output and it's fine. I use it for everything from web browsing to programming to playing games (even Doom!). Ham8 images are awesome in composite!

[roondar]

Originally Posted by a/b

What do you expect...
He doesn't understand the difference between system calls/functions and shell commands.

This one also confused me quite a bit. I actually coded directory trawling code on a number of different systems (Linux, Unix, Windows NT/2000/XP) and last time I still did that (circa 2005-2006), I don't recall even single one of them that allowed the use of wildcards in their system functions. They all expected you to loop through with some sort of examine/get next to examine loop. Through the shell/command line, sure you could use wildcards. But not through the OS functions.

It's possible that has changed by now, but it was the normal state of affairs back in the day.

[Thomas Richter]

Originally Posted by roondar

I don't recall even single one of them that allowed the use of wildcards in their system functions. They all expected you to loop through with some sort of examine/get next to examine loop. Through the shell/command line, sure you could use wildcards. But not through the OS functions.

On today's unixoid systems, wild card expansion is part of the shell, and the command gets the expanded patterns passed in. This has the drawback that the command line of a command could get very large (if many files match), and that commands need to use some sort of convention for its arguments such as to assign the expanded arguments to the right slot. This certainly has some drawbacks in generic argument parsing.


There were also older system (Atari Dos) that expanded arguments as part of the file system functionality.


On the amiga, it is up to the called command to do so. On Kick 1.3 and below, command were written in BCPL, the pattern matching was compiled into each command that needed it ,though it came from the same source ("PATTERN"). Then came "arp", which provided C versions of what was PATTERN, and then came Kick 2.0 which integrated arp functions into the dos.library.


So pattern matching was not really system supplied, but the patterns were just a convention a subset of commands followed.

[redblade]

Originally Posted by litwr

I can point the next drawbacks:
9) only limited preemptive multitasking supported because there is no kill-command in Amiga DOS.

There was the status and break command in AmigaDOS. Commodore should have supplied some well commented examples in Assembler and C.

I think the break command works around the Wait() call, so if the program is looking to receive a Wait() with a SIGF_BREAK_CTRL_C then the break command will stop it.

I would like to see what the other OS's for 16bit processors and a 256K ROM is like.

MS-DOS by then had about 4 years development and no GUI, Atari TOS has less then 1 year in development (CPM was longer), Unix V7 was released in 1979 so BSD and SYS V had more experience.

But the main problem with those models is that they did not sell enough. I still love my A500 had great fun with it

[T_hairy_bootson]

Originally Posted by duga

No colour composite output, corrected in A600/A1200. That's about it.

A1000 had colour composite output.

[AmigaHope]

What's weird here is listing OS issues as tied to a hardware model. From an operating system standpoint the A500 and A1200 are near identical. The only difference is due to driver issues you can't really run AmigaOS 1.x effectively on the A1200 since drivers are missing for stuff like the IDE controller.

Nothing ties you to 1.x on the A500. AmigaOS 3.x runs just fine on it.

[Thomas Richter]

Originally Posted by redblade

There was the status and break command in AmigaDOS. Commodore should have supplied some well commented examples in Assembler and C.

Both were originally in BCPL (in the 1.x series). What break does is that it just sends a signal (^C through ^F, i.e. signal bit 12 to 15) to an indicated process, so that is not much. If programs don't react on ^C, they cannot be aborted. There is no automatic "kill" as on unix if a program does not install a signal handler.


However, both commands only operate on processes in the Tripos "process table", which is the "list of all CLIs" in the sense of AmigaOs. If a program was run from workbench, the Tripos subsystem (aka "AmigaDOS" aka "dos.library") does not notice, and does not have that in the process table, so the comamnds do not see them and do not operate on them.



It is just another part where Tripos duplicates AmigaOs structures. For AmigaOs, we have the exec task list. For dos, we have the process table "status" lists. Actually, this table is a mostly useless legacy. It would be considerably more useful if all processes (not just shells) would populate it, or if that table would be removed completely and the dos.library would operate on the exec lists instead.

[idrougge]

Originally Posted by Thomas Richter

On today's unixoid systems, wild card expansion is part of the shell, and the command gets the expanded patterns passed in. This has the drawback that the command line of a command could get very large (if many files match), and that commands need to use some sort of convention for its arguments such as to assign the expanded arguments to the right slot.

This is IMHO an anti-pattern. You can't, as you would otherwise expect, call "unzip *.zip ." in a Unix shell, since the shell will pass a long list of filenames to the unzip binary, which expects the archive name to be followed by the files to extract, not a flat list of zip files. The shell does this wildcard expansion without being asked to, meaning that the unzip binary has no chance to handle wildcards as it would self prefer.

[Thomas Richter]

Nothing is perfect, and indeed, "unzip *.zip" will do exactly that on Linux - multiple zip files passed in as arguments. The shell cannot know the conventions of the called program.

The AmigaOs method has other drawbacks. You cannot safely pass a filename into an unknown command since you do not know whether it takes wildcards or not. If it does take wildcards, you need to escape the characters: *,?,#,... and anything else the wildcard pattern matcher takes with an apostroph, i.e. a file with the (admittedly wild) file name # would then become '#. If it does not take wildcards, you must not do that or otherwise the file names will be wrong.

The output of a "list LFORMAT=..:" is thus not generally usable in case you have files with file names that re-essemble pattern wildcards. There will be some improvements in 3.2 on this as there will be a difference between %s and %S: One escapes wildcards, the other not.

[redblade]

Originally Posted by Thomas Richter

Both were originally in BCPL (in the 1.x series). What break does is that it just sends a signal (^C through ^F, i.e. signal bit 12 to 15) to an indicated process, so that is not much. If programs don't react on ^C, they cannot be aborted. There is no automatic "kill" as on unix if a program does not install a signal handler.


However, both commands only operate on processes in the Tripos "process table", which is the "list of all CLIs" in the sense of AmigaOs. If a program was run from workbench, the Tripos subsystem (aka "AmigaDOS" aka "dos.library") does not notice, and does not have that in the process table, so the comamnds do not see them and do not operate on them.



It is just another part where Tripos duplicates AmigaOs structures. For AmigaOs, we have the exec task list. For dos, we have the process table "status" lists. Actually, this table is a mostly useless legacy. It would be considerably more useful if all processes (not just shells) would populate it, or if that table would be removed completely and the dos.library would operate on the exec lists instead.

So I have to be looking for a CTRL_C - CTRL_F signal on each loop. Got it. I think DICE and NorthC had that linked in with their startup code.

Thank you for the answer Thomas

[Bruce Abbott]

Originally Posted by redblade

So I have to be looking for a CTRL_C - CTRL_F signal on each loop. Got it. I think DICE and NorthC had that linked in with their startup code.

Thank you for the answer Thomas

SASC too.

void chkabort(void) ; 
void Chk-Abort(void) ; 

These functions force immediate checking for the Control-C and Control-D 
break characters. Normally, this check only occurs when level 1 I/O is 
performed. The chkabort function provides a mechanism for detecting 
the break characters at other times, an important function for programs 
that do little or no I/O processing. 

If the break key is detected, the break trap is executed. The break trap 
is simply a function that gets called whenever the user enters Control-C. 

If the break trap returns a zero value, control returns to the calling 
function; otherwise, the program terminates. If the program is invoked 
from the Workbench, the default handler displays a requester allowing 
the user to abort the program; otherwise, the default handler prints a 
message to the Command Line Interpreter (CLI) and aborts. 

The chkabort function ignores the break characters Control-E and 
Control-F. The chkabort function may be replaced with calls to the 
onbreak or signal functions. 

To turn off Control-C checking, you can compile with the nochk abort 
option, or you can include the following prototype and function definition 
in your code: 

void regargs — chkabort (void) ; 

void regargs — chkabort (void) 

{ 


This code replaces the function normally called for a Control-C with a 
function that does nothing.