rouaix@inria.UUCP (Francois Rouaix) (05/18/87)
Disassembling and/or printa-ing usual DOS commands such as run/execute/list/.. I made the assumption that there is a bcpl-startup hidden somewhere. The latter would be the equivalent for lstartup.asm or astartup.asm well known in the C-programmers community. Feeling this piece of code could give us light on many interesting features of AmigaDOS and dos.library, I will *really* appreciate the source for what I call bcpl-startup. Could somebody at C-A/Metacomco do something for me ? Thanks in advance. rouaix@inria.inria.fr
andy@cbmvax.cbm.UUCP (Andy Finkel) (05/23/87)
In article <461@inria.UUCP> rouaix@inria.UUCP (Francois Rouaix) writes: >Disassembling and/or printa-ing usual DOS commands such as run/execute/list/.. >I made the assumption that there is a bcpl-startup hidden somewhere. >The latter would be the equivalent for lstartup.asm or astartup.asm well known >in the C-programmers community. BCPL programs get an entire BCPL environment when they start up, with various things in various registers, their own backwards stack, and access to a bunch of BCPL routines in the DOS. This world is hidden from C and assembly programmers. For the time being, its best it were to remain so. Having too many people playing around with the internals of the DOS might prevent us from changing it in any meaningful way. One of our goals is to change the environment into a C style world, and continue the task of 'less BCPL' in the Amiga OS. It would be *really* bad if suddenly a lot of programs started counting on the BCPL world being there. Sorry 'bout that folks... andy finkel -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore/Amiga "An end is always a new beginning." - Captain Cloud Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
hamilton@uxc.cso.uiuc.edu (05/24/87)
andy@cbmvax says: > BCPL programs get an entire BCPL environment when they start up, with > various things in various registers, their own backwards stack, > and access to a bunch of BCPL routines in the DOS. > > This world is hidden from C and assembly programmers. i agree with andy that it's best to pretend the BCPL environment doesn't exist, in the hope that it will go away :-). however, just to clarify, the BCPL environment is there for ALL programs (there's no magic "i'm-a-BCPL-program"-bit somewhere). BCPL programs have a "BCPLstartup.o" in their first hunk to integrate themselves into the environment provided by dos. the only "hiding" going on is the absence of documentation. if you *really* wanted to, you could integrate your C or (more likely) asm code into the BCPL environment. you might do this to save a few bytes of ram, using the BCPL equivalents (in WCS) of printf(), sendpacket(), etc. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,seismo,pur-ee,convex}!uiucuxc!hamilton ARPA: hamilton@uxc.cso.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton
scotty@l5comp.UUCP (05/25/87)
In article <1920@cbmvax.cbmvax.cbm.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >it in any meaningful way. One of our goals is to change >the environment into a C style world, and continue the task of >'less BCPL' in the Amiga OS. > >It would be *really* bad if suddenly a lot of programs started counting >on the BCPL world being there. > >Sorry 'bout that folks... > > andy finkel But what about all that BCPL code we're already using?!? I don't want my MCC shell and assembler to go bye bye! C-A has ALREADY shown me it has almost ZERO interest in upgrading anything except the operating system (and at times I barely beleive that ;) If you guys shoot the BCPL links fine, but I better have some way of getting inexpensive replacements THAT WORK THE SAME as the tools I already have. Suggesting that I go buy the Manx C package so I can use their non-100% compatible assembler wouldn't cut it for example. And that PD assembler from back east doesn't cut it either. And what about my new ram-handler? You guys going to bust it too? :) Fine, but I better be able to relabel with the new one... I'm all for ridding the world of BCPL, but it seems to late to do so now. BCPL isn't the real problem, its those damn BPTRs! And yall can't change them without busting nearly every program written for the Amiga. Granted BCPL code has more problems that this (BIG understatement :) but these other problems are isolated inside the BCPL code itself. Hmmm, except for that idiot "grab 1500 bytes of stack right off the top" in the dog.library interface. But BCPL doesn't use that anyway that I've ever seen. (BCPL seems to have a hot line into the dog) So that means that's just a bad dream that should be made to go away. Hmm but that 1500 bytes is needed so you can call the BCPL isn't it? In any case, it would seem to do the world more good to leave the BCPL hooks alone and just cleanup the dog's act about using the disk.devices. After all, everyone has already dealt with the BCPL BS in their code. If yall remove the BS WE will either have to write our code so that it has the BS version and the non-BS version of how to do things, or REQUIRE that the users of the software get the non-BS OS. And as soon as rumors start floating that this is indeed going to happen we'll see the same thing happen that happened with 1.2. People will stop releasing software! They'll have to because who wants to re-release their software to work with the new version? Why not just wait till it shows up then release? We saw it before, we'll see it again. Heck we saw it with 1.1 too! Almost nobody released software for 1.0. But if we're going to rid the Amiga of BCPL how about we bag some other stuff too? :) I've got a shopping list a foot long of architectural things it would be nice to change but can't because they'd bust software. And right now the last thing we want to do is bust what little software we have. Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)
andy@cbmvax.cbm.UUCP (Andy Finkel) (05/27/87)
In article <147@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes:
Scotty:
I've noticed in your last 6 or 8 postings your flame content is rather
high. I wonder if you are aware just how high ? Since I don't want to
become involved in a flaming match, I will ignore the flames for the most
part, and just answer you this time.
Re: buffers...it works the way it does because the AmigaDOS default file
handler isn't designed for a track oriented system. Fortunately, as you
seem to have noticed, a programmer is not limited to the default handler.
He/she can write one (even a compatible one that can read/write the same disks)
and use it in place ofthe default one. We are doing this very thing for
hard disks, as a matter of fact.
And, the comments from you about us doing work are a bit uncalled for.
Concerning ROM Kickstart...the Amiga has the ability to replace entire
libraries if necessary. ROM Kickstart owners are not left out in the cold.
(And you could write a new dos.library if you wanted. Not, of course
disassemble and assemble ours.)
Concerning refering to AmigaDOS as Amigadog, well it its legality you are
concerned with, why not adopt the more mature method some people use
when speaking of UN*X ?
Re: Install
I'm sorry the note confused you. I said a number of things in that note.
Take the 'install' position as official; the rest 'calming' unofficial
statements were intended to give us some time to work out a solution.
(I think I even mentioned that in the posting)
Re: Install saving more out to disk than it should..we call this a bug.
If we'd found it earlier, or it had been reported by anyone, it would
have been fixed. Since we now know about it, it will be fixed in the
next release.
And, yes, alternate programs let authors make their disks say anything they
want. That isn't the point. (Appendix L of the white Rom Kernal manual Vol. 2
tells you about the boot process; it isn't secret)
Re: BCPL code
It is our intention that real BCPL code go on working. Your MCC assembler
is probably written in C, btw. (it depends on what version you have, they did
both BCPL and C versions).
Compatibility is a prime goal. So is improving system performance.
Re: your ram handler
I have no idea about your RAM handler. If you count on using global vector
routines, or in last error being in D3 on startup you may be in for a
surprise. However, if you followed the examples that Phil Lindsey posted
for writing DOS handlers you'll have no problems.
(if you just patched the old one, it will probably still work, provided
you understood what you were doing)
The 1500 bytes off the top are space for building autorequesters.
Re: rewriting code...if you've been counting on the undocumented BCPL
interface, you might have to rewrite your code. That's the big reason
it is undocumented...so we were are locked into it. If I'd come out
with an "Internals of AmigaDOS" article we'd be locked in forever.
Re: programs breaking
There was about a 3 month gap between V1.0 and V1.1. The reason there was
so little software for V1.0 is the same reason that there is little software for
any new computer when it is first introduced.
I don't think the jump from V1.1 to V1.2 broke many correct programs.
Most programs that had to be re-released were upgraded for reasons
like not working with fast memory, assuming that a program that used
487 bytes of stack would continue to use 487 bytes of stack (another
undocumented on purpose area), or had bugs that managed not to crash
under V1.1 (like releasing locks that didn't belong to the program,
or using location 0) But this is beside the point. As long as we are
working on V1.3, backwards compatibility is important.
Re: your shopping list. If you can manage to put it into words that
don't set the paper on fire, please, send it along. I've been saving
all the suggestions, comments, etc. that have come by on the net,
and many will be adressed in the next release.
Here's hoping your next posting doesn't come across like we injured
your gold fish...
andy finkel
--
andy finkel {ihnp4|seismo|allegra}!cbmvax!andy
Commodore/Amiga
"An end is always a new beginning." - Captain Cloud
Any expressed opinions are mine; but feel free to share.
I disclaim all responsibilities, all shapes, all sizes, all colors.richard@pnet02.UUCP (05/28/87)
"Stuff we are doing with hard disks" ?? Care to elaborate Andy?
UUCP: {akgua!crash, hplabs!hp-sdd!crash}!gryphon!pnet02!richard
INET: richard@pnet02.CTS.COMjesup@steinmetz.steinmetz.UUCP (Randell Jesup) (05/29/87)
In article <147@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: >In article <1920@cbmvax.cbmvax.cbm.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >>It would be *really* bad if suddenly a lot of programs started counting >>on the BCPL world being there. >> >> andy finkel >But what about all that BCPL code we're already using?!? I don't want my MCC >shell and assembler to go bye bye! Then get a real shell :-) [no offense intended] Really, if the MCC people used the undocumented BCPL interfaces, because they happened to know exactly what they did, they deserve whatever they get. They have an unfair advantage over the rest of us to whom those internals are taboo [even if you know how they work, you can't use them because they aren't guarenteed to continue to work the way they appear to now. ] > >C-A has ALREADY shown me it has almost ZERO interest in upgrading anything >except the operating system (and at times I barely beleive that ;) If you >guys shoot the BCPL links fine, but I better have some way of getting >inexpensive replacements THAT WORK THE SAME as the tools I already have. If you want an EXACT replacement, talk to MCC. If you want something better, it's coming (and it would be better yet if it wasn't for BCPL). >And what about my new ram-handler? You guys going to bust it too? :) Fine, >but I better be able to relabel with the new one... If you wrote it using the BCPL interface, you may lose. If you did it in the supported way (non-BCPL, GlobVec = 1 in the Mountlist) it should work fine. >BCPL isn't >the real problem, its those damn BPTRs! And yall can't change them without >busting nearly every program written for the Amiga. You're right. But the BPTRS hurt you worse inside the DOS than outside (performance wise). >Hmmm, except for that idiot "grab 1500 bytes of >stack right off the top" in the dog.library interface. But BCPL doesn't use >that anyway that I've ever seen. (BCPL seems to have a hot line into the dog) It does use up to that amount, from the bottom of the stack up. Simple calls use only a little, but some can use quite a bit (this is the upside-down stack referenced off of A1). >So that means that's just a bad dream that should be made to go away. Hmm but >that 1500 bytes is needed so you can call the BCPL isn't it? Right. >In any case, it would seem to do the world more good to leave the BCPL hooks >alone and just cleanup the dog's act about using the disk.devices. After all, >everyone has already dealt with the BCPL BS in their code. If yall remove the >BS WE will either have to write our code so that it has the BS version andthe >non-BS version of how to do things, or REQUIRE that the users of the software >get the non-BS OS. NO! You're right that the filing system needs improvement, but there are MANY other areas that are brain-dead, only available via the undocumented BCPL calls or just plain missing. >And right now the last thing we want to do is bust what little software we >have. Very little depends on the internal BCPL calls now anyway. The only thing really required is for the structures to remain the same (complete with BPTRs). At best you can provide alternitive calls for those that use BPTRS, but you must keep the originals around. >Scott Turner Randell Jesup jesup@steinmetz.uucp jesup@ge-crd.arpa
andy@cbmvax.cbm.UUCP (Andy Finkel) (06/02/87)
In article <559@gryphon.CTS.COM> richard@pnet02.CTS.COM (Richard Sexton) writes: >"Stuff we are doing with hard disks" ?? Care to elaborate Andy? > I can tell you what, but not when... As some people have noticed, the default AmigaDOS file handler doesn't seem to have a real good idea of the actual structure of disk drives. To improve hard disk performance, we and Tim King have been working on a file handler for hard disk drives, which does things like sort the seeks before doing them in an attempt to have only 1 pass over the disk, better use of the already existing AmigaDOS structures (ie improved exnext()), depending on the harddisk hardware for error checking (hard disk hardware does more in this)...you know...the suggestions people have been making on this very net :-) The appropriate improvements will make their way into the default file handler in a future release. Currently the thing is in testing. We want it *reliable* before it gets out there. I'll let everyone know when its ready (when & how to get it) andy -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore/Amiga "An end is always a new beginning." - Captain Cloud Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
garyo@masscomp.UUCP (Gary Oberbrunner) (06/03/87)
In article <1959@cbmvax.cbmvax.cbm.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes:
)... To improve hard disk performance, we and Tim
)King have been working on a file handler for hard disk drives,
)which does things like sort the seeks before doing them in
)an attempt to have only 1 pass over the disk, better use of
)the already existing AmigaDOS structures (ie improved exnext())...
)
)--
)andy finkel {ihnp4|seismo|allegra}!cbmvax!andy
)Commodore/Amiga
Will this speed up floppy access a la speeddir, eless etc? Or is it only a
hard disk handler?
- Gary Oberbrunner
--
Remember, -Truth is not beauty;
Information is not knowledge; / Beauty is not love; Gary Oberbrunner
Knowledge is not wisdom; / Love is not music; ...!masscomp!garyo
Wisdom is not truth; ----/ Music is the best. - FZscotty@l5comp.UUCP (Scott Turner) (06/04/87)
In article <6083@steinmetz.steinmetz.UUCP> jesup@kbsvax.steinmetz.UUCP (Randell Jesup) writes: > Then get a real shell :-) [no offense intended] Really, if the >MCC people used the undocumented BCPL interfaces, because they happened to >know exactly what they did, they deserve whatever they get. They have an >unfair advantage over the rest of us to whom those internals are taboo >[even if you know how they work, you can't use them because they aren't > guarenteed to continue to work the way they appear to now. ] I at one time thought as you do, that MCC has an unfair advantage over the rest of us. But then I realized that I was focusing blame in the wrong corner. It isn't MCC's fault that it has an unfair advantage over the rest of us. It isn't MCC's place to document the Amiga to us, that falls to the CATS crew. They have been slow to document pieces of the system that the rest of us could find useful. This gives MCC an advantage over the rest of us. But again, that isn't MCC's fault! Any advantage MCC has, has been given to them by CATS. And this doesn't apply to just the "taboo" BCPL support routines built into the ROM. MCC had the jump on other things that we only later were let in on. Like those nifty packets to make console.handler dance etc. > If you want an EXACT replacement, talk to MCC. If you want something >better, it's coming (and it would be better yet if it wasn't for BCPL). As soon as something better than the MCC shell shows up I'll slap plastic, modem, or whatever real fast. But that's true of ANY of the tools I use. I think it's also important to realize that BCPL the LANGUAGE isn't the real problem here. It's the BCPL environment that someone at MCC has come up with that is the problem. Frankly BCPL could shift it's pointers by 42 and push it's stack sideways so long as I DON'T have to do it too. Both Lattice and Manx generate code and use environments I don't really like. Fine. I don't use either, and neither has had the kind of impact that the BCPL environment has had on my coding. Hence no quaint remarks about Lattice or Manx in my signature. And the slowness of the operation of amigadog can't be laid at the feet of BCPL the language either. Some very poor decisions were made as to how amigadog operates. I doubt these decisions were the result of using BCPL to code it. I see more evidence of "If disks didn't rotate and 68000 programmers had only used push UP stacks" ie "utopian" thinking than any "Well BCPL forced us to.." kind of thinking. (BCPL forced us to read the disk a block at a time, yeah! That's the ticket! :) It seems to me that a few hours with the BCPL source code and most of the problems with disk I/O speed could be cured right up. No need for new handlers, just fix what's there. No need to recode into another language either. > You're right. But the BPTRS hurt you worse inside the DOS than >outside (performance wise). I'm torn over that. Amigadog certainly suffers from BPTR mainge but I don't know who suffers more at times. :-) > It does use up to that amount, from the bottom of the stack up. >Simple calls use only a little, but some can use quite a bit (this is the >upside-down stack referenced off of A1). It doesn't matter if most calls only use a small part of this space. They use it from the bottom, which has the effect of making the fact that they only use a few bytes mute. > NO! You're right that the filing system needs improvement, but there >are MANY other areas that are brain-dead, only available via the undocumented >BCPL calls or just plain missing. The Amiga has been around for nearly TWO YEARS now. That's a long time in this day and age. The Amiga's OS DOES have it's problems. And I'm sure that if given the chance to do it all over again MCC and C-A would do certain things differently. But they DON'T have it to do all over again. The second they released the Amiga's OS it became a standard. Every last bug and blown concept. C-A has kept certain parts of the OS "dark", evidently in the hopes of doing something about them. Almost two years later there has been LITTLE evidence that anything is being done. In fact two new computers are set to be released with the SAME "What ever it is they don't want us to see" code burned into ROM. Granted the WCS would have enabled C-A to fix anything they wanted to easily and thus we should keep out mitts off. But things are different now. And not just now now, but for several months. If this 1.3, that every one keeps dropping hints about, is so close then why are the new machines coming out with 1.2? But it's evident, from what I can gleen from Andy's messages, that 1.3 is going to be a WORKBENCH disk release and not a new ROM release. This dovetails nicely with my comments about things getting cast into ROM and not being easily changed. C-A can change the WB disk all they want without touching the ROM. But if they aren't going to be touching the ROM then what's in the ROM becomes fair game for us to use. Anyone for a bcpl.library? We could cook this up as an interface to the hidden BCPL routines. Then if they change then we would have this library as a buffer between us and the changes. ie it could be re-written rather than our code. This seems like a "safe and sane" answer to the question of getting at the BCPL library in the ROM. Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)
phillip@cbmvax.cbm.UUCP (Phillip Lindsay CATS) (06/08/87)
in article <283@l5comp.UUCP>, scotty@l5comp.UUCP (Scott Turner) says: > Summary: MCC isn't the total villian in this drama folks. > > And this doesn't apply to just the "taboo" BCPL support routines built into the > ROM. MCC had the jump on other things that we only later were let in on. Like > those nifty packets to make console.handler dance etc. If you HAD read your Dos Technical Reference Manual you would have seen that on pages 3-8 to 3-14 packets are described. Specifically on page 3-12 where I quote part of the first paragraph: "This packet can also be sent to a console handler process, in which case the Volume field in the ParameterBlock contains the window pointer for the window opened on your behalf by the console handler." The newer features of the console handler were documented in the 1.2 release notes. -phil ============================================================================== Phillip (Flip) Lindsay - Commodore Business Machines - Amiga Technical Support UUCP: {ihnp4|seismo|caip}!cbmvax!phillip - Phone: (215) 431-9180 No warranty is implied or otherwise given in the form of suggestion or example. Any opinions found here are of my making.
ewhac@well.UUCP (06/10/87)
In article <1984@cbmvax.cbmvax.cbm.UUCP> phillip@cbmvax.cbm.UUCP (Phillip Lindsay CATS) writes: >in article <283@l5comp.UUCP>, scotty@l5comp.UUCP (Scott Turner) says: >> Summary: MCC isn't the total villian in this drama folks. >> >> And this doesn't apply to just the "taboo" BCPL support routines built into the >> ROM. MCC had the jump on other things that we only later were let in on. Like >> those nifty packets to make console.handler dance etc. >If you HAD read your Dos Technical Reference Manual you would have seen that >on pages 3-8 to 3-14 packets are described. [ ... ] FUSION_FURNACE_ON Oh, PUH-LEEEEZZ!! Get real. You call that documentation? The Commodore 1541 disk manual was better than that! You got more information out of the libraries/#? include files than you did out of the MetaComCo docs. The DOS manuals constantly referred to "pointers." What they never told you was that they were REALLY referring to BPTRs. This was casually mentioned on an obscure page in the developer's manual I think, and was described in a manner that suggested that, "Obviously you know this already." Despite MetaComCo's efforts to the contrary, I've managed to figure out how a lot of the DOS works (or rather, operates; I hesitate to say that it *works*), and can program it effectively. However, whenever I get a chance, I avoid the DOS like the plague and go straight to the Exec. I mean, all this wouldn't be so bad if things were *DOCUMENTED*. The Exec, graphics, Intuition, and hardware manuals are gorgeous. But someone feebed out of the DOS manuals. If all this stuff were written down somewhere, we'd all know about it, and would deal with it as we needed to. We may not like it, but *at least* we could deal with it. As it turns out, you have to be a Philadelphia Lawyer to understand what the DOS manuals are trying to hide from you, and this is probably what has got a lot of us steamed. This is also probably the primary reason everyone wants to dump the DOS (apart from the BPTR stuff, but that's really the fault of whoever wrote the BCPL compiler (hence my new acronym: British Compiler Programmers are Lousy)). The clearest part of the DOS documentation is the bit that describes the filesystem format, and that's only because they drew pictures. I'm running out of steam now, but I just wanted to say that anyone who suggests that the manuals will clear DOS issues up has, in my view, not actually tried to read them. "RTFM" doesn't work too well with the DOS. FUSION_FURNACE_OFF Sorry to fly off the handle like that, but the fact that I had to read the DOS manual three times cover to cover before I understood what was going on still has me irked. Maybe I'm just not as smart as I think I am. Sidenote: A very competent friend of mine, who is a C guru in all aspects (writes device drivers using 'cat >'), claims that he could totally re-write AmigaDOS into C in three months. Further, he claims that he could remove a lot of the braindamage currently in the DOS if he wanted to. I believe him. Anyone want to pay him to do this? _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
tenney@well.UUCP (06/10/87)
In article <1984@cbmvax.cbmvax.cbm.UUCP> phillip@cbmvax.cbm.UUCP (Phillip Lindsay CATS) writes: >If you HAD read your Dos Technical Reference Manual you would have seen that >on pages 3-8 to 3-14 packets are described. Specifically on page 3-12 where >I quote part of the first paragraph: > "This packet can also be sent to a console handler process, in > which case the Volume field in the ParameterBlock contains the > window pointer for the window opened on your behalf by the > console handler." Except that that packet wasn't working until 1.2. I kept trying it at various releases and reporting that it didn't work, but... -- Glenn Tenney UUCP: {hplabs,glacier,lll-crg,ihnp4!ptsfa}!well!tenney ARPA: well!tenney@LLL-CRG.ARPA Delphi and MCI Mail: TENNEY As Alphonso Bodoya would say... (tnx boulton) Disclaimers? DISCLAIMERS!? I don' gotta show you no stinking DISCLAIMERS!
phillip@cbmvax.cbm.UUCP (Phillip Lindsay CATS) (06/10/87)
[] >in article <3262@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) says: > Keywords: flame, blowtorch, incendiary device, firestorm, nuclear blast > Summary: --> Flame on AmigaDOS documentation. Hit 'n' now if you like. <-- > > In article <1984@cbmvax.cbmvax.cbm.UUCP> phillip@cbmvax.cbm.UUCP (Phillip Lindsay CATS) writes: >>in article <283@l5comp.UUCP>, scotty@l5comp.UUCP (Scott Turner) says: >>> Summary: MCC isn't the total villian in this drama folks. >>> >>> And this doesn't apply to just the "taboo" BCPL support routines built into the >>> ROM. MCC had the jump on other things that we only later were let in on. Like >>> those nifty packets to make console.handler dance etc. >>If you HAD read your Dos Technical Reference Manual you would have seen that >>on pages 3-8 to 3-14 packets are described. [ ... ] > > FUSION_FURNACE_ON > > Oh, PUH-LEEEEZZ!! Get real. You call that documentation? The > [ ... a pisst off Amiga Hacker ... ] I never said the documentation was PERFECT! I struggled with the documentation as much as anyone. I was able to figure out AmigaDOS packets from the "AmigaDOS Technical Reference Manual" and the include files. Granted knowing a little bit about Exec helped...but the book was atleast helpful in understanding packets. We do need MORE documentation in light of DOS and device drivers. CATS with little time and resources try and fill the holes... We are working on improving documentation and hopefully by working some deals with publishers we will see changes soon. -phil ============================================================================== Phillip (Flip) Lindsay - Commodore Business Machines - Amiga Technical Support UUCP: {ihnp4|seismo|caip}!cbmvax!phillip - Phone: (215) 431-9180 No warranty is implied or otherwise given in the form of suggestion or example. Any opinions found here are of my making.
phillip@cbmvax.UUCP (06/10/87)
in article <3268@well.UUCP>, tenney@well.UUCP (Glenn S. Tenney) says: > > In article <1984@cbmvax.cbmvax.cbm.UUCP> phillip@cbmvax.cbm.UUCP (Phillip Lindsay CATS) writes: >>If you HAD read your Dos Technical Reference Manual you would have seen that >>on pages 3-8 to 3-14 packets are described. Specifically on page 3-12 where >>I quote part of the first paragraph: >> "This packet can also be sent to a console handler process, in >> which case the Volume field in the ParameterBlock contains the >> window pointer for the window opened on your behalf by the >> console handler." > > Except that that packet wasn't working until 1.2. I kept trying it > at various releases and reporting that it didn't work, but... Uhhh. I think you better try again. The 1.1 AmigaDOS console handler DID support the Action.Diskinfo (25) packet. Just as described on page 3-12 of the AmigaDOS Technical Reference Manual. ============================================================================== Phillip (Flip) Lindsay - Commodore Business Machines - Amiga Technical Support UUCP: {ihnp4|seismo|caip}!cbmvax!phillip - Phone: (215) 431-9180 No warranty is implied or otherwise given in the form of suggestion or example. Any opinions found here are of my making.