30 January 2021, 23:32 | #41 |
Registered User
Join Date: Aug 2014
Location: Zagreb / Croatia
Posts: 302
|
AmigaDOS wildcards: https://eab.abime.net/showthread.php?t=10065
|
31 January 2021, 12:23 | #42 | ||||||||||||
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
IMHO you like generalizations but good practical rules are rather a set of exceptional cases than just one common case. Nothing is wrong in reading a timer value, it mustn't affect the system normal functioning. Indeed if the timer is overtly used by the system it must be documented but in our case we don't have any Commodore documents (or at least I don't know such documents) where it was declared that the timer is restricted. So it was rather a quirk of WB 1.x which was fixed in KS 3 and maybe even in KS 2. Quote:
Quote:
Quote:
Quote:
Quote:
Please be more specific. IMHO your reaction has been very odd. I just make a list and we can discuss it. You, of course, can send me a private message if you need some more clarifications. Quote:
Quote:
Quote:
Let's try to think around a practical task. For example, an application program needs to have a way to handle a user input which enters some filename pattern. This program has to show the user all files matching his entered pattern. I don't know any way how to program this task in WB 1.x, but write functions which will do the pattern matching. WB 2 provides us with such functions. Quote:
Quote:
Quote:
|
||||||||||||
31 January 2021, 14:23 | #43 | |||||||||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,436
|
Quote:
Quote:
Quote:
Note here that this "rule" is not just spelled out in the official documentation. For fun, I checked out the only two remaining paper non-official books I have on Amiga programming. Those are Amiga Intern 2.0 and Amiga Machine language. As expected, both of these books tell you not to access the hardware directly in chapter 1. Now, only one of these books I have is in English, so let me just quote from that one: Quote:
Quote:
Edit: I changed the above section to be more clear. Quote:
Quote:
Be honest here: have you actually read any of these books? Edit: I have checked your sources because I found it hard to believe this. The AmigaDOS inside and out book does mention environment variables, though I'll admit they don't give a clear example (which is the book's fault and not the OS's fault). Regardless, their descriptions of GETENV/SETENV as well as IF all mention the use of variables. The linked German Amiga DOS 1.3 manual also mentions them. The description for IF for instance states: "Der Befehl IF ist in der Lage, Umgebungsvariabelen zu vergleichen. Soll eine Umgebungsvariabele angegeben werden, ist vor dem Namen der Variablen das Zeichen $ einzugeben" (page 2-21). This all further makes me doubt you actually read and/or understood these books. Quote:
Anyway, the example CheckRet actually supports what I said - if the OS doesn't support return codes other than 0,5,10 or 20 then that is a totally superfluous command to have. Also note here that the command FAILAT can accept any return code, including numbers over 20 (the example in the Amiga DOS manual with my A500 actually uses FAILAT 25). The confusion here is that you're mistaking the IF functions built in condition checks with the OS supporting only certain options. Edit: note here that the long-form Amiga DOS manual (which the short form one you and I have refers to all the time) makes it clear that the IF flags trigger if the return code >= 0,5,10 or 20 and not = 0,5,10 or 20. This means that a program that returns with a return code which is not 0,5,10 or 20 can be detected through IF. Quote:
However, normally I'd suggest using a file requester instead. These do the hard work for you. There's several options for this, ARP was probably the most popular. But if neither of those takes your fancy then you'll indeed have to write your own functions. Last edited by roondar; 31 January 2021 at 19:07. |
|||||||||
31 January 2021, 20:00 | #44 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,348
|
The return code of the last command is always in the RC variable and can be checked as any variable; or was this not in place in 1.3? Sounds unlikely.
|
01 February 2021, 16:07 | #45 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,436
|
I tested this and $rc works in KS2.0+. It can be used with the IF command to allow for any return codes to be checked. However, it does not work under 1.3.
|
06 February 2021, 11:31 | #46 | ||
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
I was confused by a fact that $ can only be used inside the IF-command. However AmigaDOS Inside & Out (1991) in Engilsh missed $'s completely. Anyway thank you but you can notice that my point had some basis too. Quote:
Thank you very much. I corrected my claim "3) no way to use program return codes, only few "standard" return codes are allowed (exactly 0, 5, 10, 20) until WB 2.0" |
||
06 February 2021, 15:31 | #47 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,302
|
Local shell variables (unlike environment variables) did not exist before Kick 2.0, so "no". They require an extension of the "process" structure Tripos did not have. The return code is instead placed in "CLI->CLI_ReturnCode" - pardon me "clip!cli_returncode" (as the CLI is in BCPL), and is available there. The CLI does check, though, whether the return code is above the critical fail level, which can be set by "FailAt" and fails if it is. So there is certainly more flexibility in the return codes than just the "if"-command.
|
06 February 2021, 15:33 | #48 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,302
|
Quote:
No, that's just blantly wrong. All return codes are allowed - nothing happens if you have any other return code - and you can certainly make use of them through "FailAt". |
|
06 February 2021, 16:06 | #49 | |||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,436
|
Apart from the documentation I extensively quoted which shows you explicitly that you're not supposed to access the hardware directly and that doing so can cause issues of course
Quote:
Quote:
This would allow your menu program example to have infinite choices, while also having the option of returning a error/warning code separate from the menu choice. Quote:
Last edited by roondar; 06 February 2021 at 16:18. |
|||
06 February 2021, 18:10 | #50 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,302
|
Concerning the '$', there are two places where it works. First, the "if"-command supports it natively, but there only provides access to environment variables. No other command expands the $. The execute command supports argument substitution, though in a patchy way. Thus, if you want to pass around arguments and make shell scripts depending on them, the only way would be through 'execute'.
The second place where $ works is within execute, but not for argument substitution, but for <$$>, i.e. it has a different meaning, in best (inconsistent) Amiga tradition. Last edited by Thomas Richter; 06 February 2021 at 19:46. |
06 February 2021, 20:44 | #51 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,348
|
|
06 February 2021, 20:51 | #52 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,054
|
|
07 February 2021, 10:21 | #53 | ||||
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
Quote:
Quote:
Quote:
Would you like to clarify your point? |
||||
07 February 2021, 10:48 | #54 | |
Registered User
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,157
|
Quote:
The principle is very simple - while the OS is running it owns the hardware. The published OS interfaces are a contract by which the OS pledges to behave in a certain way. You can make no assumptions about *how* the OS fulfils that pledge, and as you noticed, it will vary from version to version. Your end of that contract, as a programmer, is not to touch the hardware, or make any assumptions about what the OS is doing with the hardware. If you're not willing to abide by your end of the contract then you have to disable the OS. At that point you have full control over the hardware and can do whatever you want with it. If the OS does things to the hardware that you're not expecting, even if it's only one particular version of the OS, it's fine to say "This is really inconvenient" - but it's not fine to say "There's a bug in this version of the OS", because at no point did the OS ever promise not to do the thing that's annoying you! |
|
07 February 2021, 11:33 | #55 | |||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,436
|
Quote:
Your assessment that OS 2.0 'corrected' this with the idea being you can just bang the hardware to access the timer is based on nothing. OS's change all the time, but what hasn't changed is the fact that Commodore has literally told you in their documentation that you can't access hardware directly and expect that to work while the OS is running. Quote:
Not nearly for everything, but that is not needed to prove your initial point wrong. Also, if you actually read up on how EXECUTE runs scripts in the full-length Amiga DOS manual, you'll see that there are ways to have the EXECUTE command do many of the things you might want to do with variables for you. I'm not sure if this info is also in the short-form manual, but check out pages 54 onwards from the Amiga DOS manual (1986, ISBN 0-553-34294-0) to see how you can do things like replacing parameters with defaults, etc. Quote:
Last edited by roondar; 08 February 2021 at 09:47. |
|||
07 February 2021, 14:17 | #56 |
Registered User
Join Date: Nov 2010
Location: Sweden
Posts: 528
|
If you were still using a TV as your monitor in 1992 or later then you at that time probably had a RGB capable SCART input in your TV (at least in Europe).
|
08 February 2021, 01:57 | #57 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,348
|
I certainly didn’t, since the TV I was using was neither new nor fancy.
|
08 February 2021, 15:27 | #58 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,436
|
|
08 February 2021, 16:21 | #59 |
Registered User
Join Date: Dec 2019
Location: Ur, Atlantis
Posts: 2,029
|
Same here, I actually started with a green monitor @@...Amiga & no colour...*shudder* Later on my persistent begging yielded a lil' 14" colour TV, but it was some no-brand clone with composite only.
I think RGB / SCART enabled TVs got bit more popular and affordable in the second half of the Nineties. |
12 February 2021, 17:12 | #60 | ||
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Despite all minor software drawbacks the Amiga offered a great environment for programming. WB CLI was like shells of modern Linux. Arexx was like Perl or even Python. GUI was also quite good. One can only wonder why Commodore didn't follow Apple methods and didn't attack the IBM PC? Apple had worse hardware and software and was quite successful. Commodore instead made a big useless "toy" of the Amiga and offered the "serious" Commodore PC.
Quote:
Quote:
So you have eventually agreed with me. Thank you. |
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Cheap mass storage on A500/500+/1000/2000 | TroyWilkins | support.Hardware | 23 | 29 September 2020 09:07 |
AMIGA 2000 - chipram mod gone wrong. | Moklar | support.Hardware | 0 | 24 February 2020 12:43 |
ScanPlus ECS Scandoubler for Amiga 500, 500 plus, Amiga 1500 and Amiga 2000 | RetroPassionUK | MarketPlace | 0 | 04 January 2020 16:24 |
Amiga 1000 Software on 500 | Weemus | Amiga scene | 11 | 09 May 2012 04:48 |
FS/FA: ICD Flicker Free Video/Scandoubler for Amiga 500,1000,2000,Toaster | vamigan | MarketPlace | 5 | 22 September 2007 02:37 |
|
|