#using DevPac
15 messages in this thread
Any successful DevPac3 users out there?
I'm switching from Cape2.5, but having some strange problems. I get proper
results with a program segment (reads a file-name argument from the CLI) when I
run it in the debugger, but get garbage running from the editor screen (unless
I have run it already in debugger mode–then it usually works from the editor
screen too).
Typical problem?
Bart Mathias
I have used devpac3 succesfully, this sounds very tricky, maybe you are relying
on certain registers being set or you are storing a long value in word storage,
or overwritting the stack.
How long is your program, maybe you could post it here?
To read the cli is pretty simple as it is actually pointed to by a0 on startup
( which I assume you know already ) 🙂
or maybe you are using readargs? if so then I don't know if that actually works
from the editor as I have never tried readargs.
Phill
Phill,
I'm really glad to hear from you. I knew another user (in England) but he
joined a monastery last spring (no connection with computing).
I was wondering if I should try readargs, but haven't gotten around to it yet.
It didn't exist when I wrote the working version of the program.
If I give the program below (I hope it's short enough to send) a fake name
("none") in the Arguments requester, and run it in the debugger, I get a window
with the following message:
Cannot find such a file as none
If I run it from the Edit screen, I get messages (varying) like the following:
Cannot find such a file as noneba#"\ "a@#o"aa"aa"aD"aI
(I don't know how those Alt characters will come through on CompuServe, but
there are 23 characters after the "none" in this case, copied with Amiga^C into
this file. I had to run it twice. Left the copy in the Clipboard and closed
Devpac, and crashed with an 81000005. Next time I moved it into this file
before quitting Devpac. And then quit Devpac to the tune of another 81000005!)
The relevant parts of the program:
include /system use the pre-assembled header
include diskfont/diskfont.i
include diskfont/diskfont_lib.i
start: movem.l a2-a6/d2-d7,-(sp)
movea.l a0,a2
{At this point I open dos.library, intuition.library, graphics.library, and
{diskfont.library, with no problems. I also use the standard procedure {to get
and save the console handle, with branch-to-close on failure. {I delete as
irrelevant here.
move.l a2,a0 Put name ptr back in A0
lea textname,a1 Address storage space for name
move.b (a0)+,d0 First byte to D0 for examination
cmpi.b #$0a,d0
bne.s 3$
lea nofilstr,a0 {irrelevant–this part works}
bsr cliout
bra close 3$ move.b d0,(a1)+ Add character to title
addi.b #1,wrngfstr
move.b (a0)+,d0 and get the next
cmpi.b #$0a,d0
bne.s 3$ go add to title
move.b #0,(a1)+ Null to end of file name
move.b $0a,(a1) and a LF
addi.b #2,wrngfstr
bsr infile {a routine to read the requested file to a buffer}
tst.l d0
bne.s two {branches if successful file read. Not relevant}
lea wrngfstr,a0
bsr cliout
bra close {to an ordinary, problem-free close procedure}
cliout: move.l conshndl,d1
moveq #0,d3
move.b (a0)+,d3
move.l a0,d2
CALLDOS Write away: rts
{All irrelevant material deleted here}
wprngfstr: dc.b 41,$9b,'33;40mCannot find such a file as ',$9b,'31;40m'
textname: ds.b 126 ;textname must follow wrngfstr!
Ok, this one is pretty simple 🙂
When your program is called the arguments are pointed to by a0. Additionally
the length of the argument is stored in d0.
What you need to do is copy using a dbra loop and then store a zero at the end.
I don't think you will get a linefeed if you do this.
I haven't time to put a code fragment together, but basically you shouldn't
rely on there being a terminator of any sort on the argument
PHill
It's been 11 days since your response (for which I thank you), so I should
probably remind you what it was:
> When your program is called the arguments are pointed to by a0. >
Additionally the length of the argument is stored in d0.
> What you need to do is copy using a dbra loop and then store a zero at the >
end. I don't think you will get a linefeed if you do this.
It isn't quite clear to me how this relates to my problem. You also say "you
shouldn't rely on there being a terminator of any sort on the argument" but in
fact it has never happened in my experience that there was not a <LF> there.
Although I apparently once toyed with the idea of saving d0 at startup (I have
a commented out move.l d0,… statement there which I removed when I sent it to
you), I stayed with the method I learned from the sample programs that came
with the CAPE assembler. For one thing, one has to parse the command line
sooner or later anyway, if there might be more than one file listed, or
flags…
In any event, it's the way I coded the PD program JIStoJi, which I and others
have been using for a couple of years, with no reports of problems reading a
command line file.
My original question was, why does it work fine when I use Devpac's Debug, but
crash when I run it from the Devpac Edit screen? The main reason I bought
Devpac was for the debugger, but if it is going to tell me that programs that
compile with some kind of fault are OK, I'm better off going back to CAPE.
The differences between the working CAPE-compiled program and the not-working
Devpac-compiled program are 1) different include files 2) with CAPE I compile
and link, with Devpac it's a one-step operation. The bug must be a result of
one of those differences, but why won't the debugger tell me?
Bart
The reason why devpac causes a crash from the edit screen ( well in my opinion
anyway ) is that the argument passing to a cli program is defined by cbm as
being a string pointed to by a0, with d0 bytes in it. There is no defined
terminator. Now, the cli will always but a <LF> on the end of the string, this
is only because you typed the <LF> at the keyboard.
In devpac, they have followed cbm's guidelines and given you the address of the
parameters and the length. Whatever is beyond those bytes in memory is anyones
guess. In theory you could say that there was a problem with devpac, but it is
doing exactly what cbm says the cli does. That doesn't mean that it does
_exactly_what_the_cli_does. If you want your program to work on all amigas, in
all situations, from any launcher ( you can run a program from more than just
the cli of course). Then you _must_ use a0 and d0 and not rely on anything
terminating your string.
As to devpac not telling you there is anything wrong with your program, well
that's assembler for you, just because you got the syntax correct doesn't mean
that your code will work ( otherwise there would be no reason for a debugger ).
Saying this, I can't remember whether d0 is the number of bytes ( i.e. a 1
character parameter would be 1 ), or whether it is a0+d0 is the last character
or the one after. From what I remember of the a0/d0 interphase is that you also
get the first space before the argument, but again don't rely on this.
As my amiga doesn't work anymore 🙁 I can't try this, but believe me when I
say, you MUST use the value in d0 to determine how long the argument is that
has been passed to you. I am sorry to repeat myself, but it's in the cbm
documentation.
Phill
The command tail is indeed pointed to by A0, with D0 containing the number of
bytes it has. This is not your raw command tail, since redirection information
will have been removed. The value in D0 includes the trailing NewLine
character; as far as I know, that character is always in place.
A number of programs start with MOVE #0,-1(A0,D0) .. which stuffs a binary
zero over top of the NewLine. As a general rule, it's better not to mess with
anything that the system gives you .. copy it and mess with the copy; but the
technique seems to work just fine.
If a program has been launched by anything other than CLI/Shell, it had
better be ready to detect this, since there won't be a command tail to look at.
Instead, a message will be coming – perhaps from the Workbench, perhaps from a
parent process – and there needs to be a whole mess of code in place to catch
incoming message(s) and reply at the appropriate time.
The whole business of detecting whether or not you're called from CLI/Shell
or not is done with a call to FindTask() [to have the task find "itself"] and
then examining the pr_CLI item within the task structure; if it's non-zero, you
have a CLI and can use this B-pointer to find the program name as typed by the
CLI user (if you care). By this time, the original A0 and D0 values will be
long gone, so you'd better have saved them somewhere.
An oddity: some debuggers (such as MetaScope) do not give you the same
command tail that you'd get with a direct CLI program call. In the case of
MetaScope, the difference is that the tail contains a leading space (so is one
byte longer).
–Jim
That's pretty much what I said, except I don't believe that you should rely on
there being a LF at the end. I can't try it out as my amiga is very dead at the
moment 🙁
As far as I am aware the CLI gives you a leading space character as well.
Unless of course I saw it when debugging under devpac. CBM never really covered
all the important topics when parsing command parameters. But I would never
actually change the memory that was given to you ( for a start the memory way
be read only to your process anyway under Kickstart 9 ) 🙂
Phill
No, the debug packages lead you astray. The CLI/Shell A0 pointer is to the
first non-space character. (Since I couldn't trust the debuggers, had to write
a special program to test it, but it's true, at least with 3.1).
–Jim
The conclusion that I came up with was not to expect what characters were at
the beginning or end of the parameters. At least then the software should work
in all debuggers & shells.
Phill
>> the conclusion I came to was not to expect .. [any behaviour]
Good conclusion. You never know what a new release or an alternate shell
might do.
–Jim
Philip,
>> CBM never really covered all the important topics when parsing command
>> parameters.
take a look in the C= official start-up code called `startup.asm' (v 36.13).
You may determine from that code and from the supplementory text file
`UsingAmigaStartups' how the CLI arguments should be read.
– wkc – … via AP from Hamburg, Germany
I did mean they never covered them in the manuals, not everyone could get hold
of the ondisk examples and docs. I only got them this year 🙂
Phill
I recommend you use ReadArgs. It is a little more failsafe. I write all
programs on Devpac 3 with no problems like you are having.
Thanks for the tip. I'll give ReadArgs a try, although I have been using the
other approach successfully for nearly four years with CAPE2.5 (there WAS no
ReadArgs then).
It is still frustrating that it works as is in Debug, but crashes from the Edit
screen. Except that often I can re-run it OK from the Edit screen, providing I
have run it in the debugger first. Seems weird!