I was following the example on the website. The only thing I did 
different was change the target system to apple2. The linker gives me 
this error:

Unresolved external '__STARTUP_LOAD__' referenced in:
crt0.s(12)

Any ideas? I'm using the latest cc65 snapshot, running under Windows.

- Gio

-- 
AND NOW FOR A WORD (an IF blog):

http://giomancer.wordpress.com/

Hi Gio,

>I was following the example on the website. The only thing I did 
>different was change the target system to apple2. The linker gives me 
>this error:
>
>Unresolved external '__STARTUP_LOAD__' referenced in:
>crt0.s(12)
>
>Any ideas? I'm using the latest cc65 snapshot, running under Windows.

I just tried the 'apple2' target and it generally works for me. So
please give more details. What example are you refering to? What
snapshot are you using?

Best, Oliver

Gio <giomancer@sbcglobal.net> wrote:
> I was following the example on the website. The only thing I did
> different was change the target system to apple2. The linker gives me
> this error:
>
> Unresolved external '__STARTUP_LOAD__' referenced in:
> crt0.s(12)
>
> Any ideas? I'm using the latest cc65 snapshot, running under Windows.

Is it possible that you're mixing two versions of the compiler package,
for example the snapshot version and the last "official" one? Or two
snapshot versions?

The reason why I'm asking: versions before 2008-03-16 were referencing
__STARTUP_LOAD__ in line 12 of crt0.s as the error message says. But these
versions had also a builtin linker script that defined this symbol. Later
versions were changed not to reference the symbol and not to define it in
the linker script. If you're mixing an old apple2.o startup file with a
new linker executable you get exactly the effect you're describing.

Regards


        Uz


-- 
Ullrich von Bassewitz                         uz@spamtrap.musoftware.de
 22:06:59 up 30 days,  7:58,  1 user,  load average: 0.02, 0.10, 0.12

Taking your thoughts into consideration, I did a test. Each trial but 
the last is on a clean install of the files in question.

When I compile using the official, non-snapshot version (of everything), 
I get no errors.

When I compile using the snapshot (20080414) windows release and the 
official release apple 2 library, I get the error listed above in the OP.

When I compile using the snapshot (20080414) windows release and the 
snapshot (20080414) apple 2 library, I get the following error:

ld65.exe: Error: Input file 'apple2.o' not found

When I compile using the snapshot (20080414) windows release and the 
snapshot (20080414) apple 2 library [installed on top of the official 
release library], I get a whole ream of errors, all unresolved externals.

- Gio

-- 
AND NOW FOR A WORD (an IF blog):

http://giomancer.wordpress.com/

Well, I have a new problem.

I can run my "Hello, World!" under DOS 3.3. Under ProDOS is a different 
story, though.

I'm using the loader given in the user additions section. It works fine, 
but when it tries to load the program, I get "Error #56" as a response. 
I'm not too sure what this means..

- Gio

-- 
AND NOW FOR A WORD (an IF blog):

http://giomancer.wordpress.com/

Gio <giomancer@sbcglobal.net> wrote:
> When I compile using the snapshot (20080414) windows release and the
> snapshot (20080414) apple 2 library [installed on top of the official
> release library], I get a whole ream of errors, all unresolved externals.

The snapshot 20080414 was broken which explains the errors. But I have no
idea what causes the other problems and I cannot reproduce them here.

Regards


        Uz


-- 
Ullrich von Bassewitz                         uz@spamtrap.musoftware.de
 21:39:04 up 31 days,  7:30,  2 users,  load average: 0.11, 0.17, 0.11

> The snapshot 20080414 was broken which explains the errors.

Ah, I see. I'll give 20080415 a shot, then. :) Thanks!

- Gio

-- 
AND NOW FOR A WORD (an IF blog):

http://giomancer.wordpress.com/

On Apr 15, 2:40=A0pm, u...@spamtrap.musoftware.de (U. v. Bassewitz)
wrote:
> Gio <gioman...@sbcglobal.net> wrote:
> > When I compile using the snapshot (20080414) windows release and the
> > snapshot (20080414) apple 2 library [installed on top of the official
> > release library], I get a whole ream of errors, all unresolved externals=
..
>
> The snapshot 20080414 was broken which explains the errors. But I have no
> idea what causes the other problems and I cannot reproduce them here.
>
> Regards
>
> =A0 =A0 =A0 =A0 Uz
>
> --
> Ullrich von Bassewitz =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 u...=
@spamtrap.musoftware.de
> =A021:39:04 up 31 days, =A07:30, =A02 users, =A0load average: 0.11, 0.17, =
0.11

I got a snapshot that was broken too... how does that happen?

I don't have much patience with things that don't work.

Bill

Bill Buckels <bbuckels@escape.ca> wrote:
> I got a snapshot that was broken too... how does that happen?

cc65 is actively developed and the snapshot is a daily snapshot of the
development tree. Depending on the state of development, a snapshot may
work great, may be buggy or may not even compile. If you don't like that,
you will have to go for one of the stable versions.

> I don't have much patience with things that don't work.

No one has that. But the snapshot is not stable by definition.

Regards


        Uz


-- 
Ullrich von Bassewitz                         uz@spamtrap.musoftware.de
 09:32:41 up 31 days, 19:23,  1 user,  load average: 0.28, 0.44, 0.73

On Apr 16, 2:36=A0am, u...@spamtrap.musoftware.de (U. v. Bassewitz)
wrote:
> Bill Buckels <bbuck...@escape.ca> wrote:
> > I got a snapshot that was broken too... how does that happen?
>
> cc65 is actively developed and the snapshot is a daily snapshot of the
> development tree. Depending on the state of development, a snapshot may
> work great, may be buggy or may not even compile. If you don't like that,
> you will have to go for one of the stable versions.
>
> > I don't have much patience with things that don't work.
>
> No one has that. But the snapshot is not stable by definition.
>
> Regards
>
> =A0 =A0 =A0 =A0 Uz
>
> --
> Ullrich von Bassewitz =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 u...=
@spamtrap.musoftware.de
> =A009:32:41 up 31 days, 19:23, =A01 user, =A0load average: 0.28, 0.44, 0.7=
3

Aztec C is actively developed as well Uz but since I am at this point
the only active developer perhaps it is understandable that it should
be stable and easier to configure for newbies.

=46rom my perspective the focus is not so much on changing the compiler
since that works very well and has for decades in some versions for
all the platforms it supports including the C64, Apple II, Z80, Amiga,
and of course MS-DOS. My focus is in providing good clean examples and
link libraries and an out-of-the box working environment and tools to
help include media like sound and graphics into an enriched
application production environment. The documents are complete as well
so I don't have the annoyance of hitting a moving target.

I think my goals are very different from the goals of CC65.

As I take Aztec C through the open source and the necessary rewrite to
C99 etc. I may experience some of these configuration management
problems myself, but my last 30 years in CMS tells me that I probably
won't, so I really still don't understand why a snapshot is used and
why anyone would offer broken software and not expect it to be
criticized.

These are fair questions, statements of experience (I didn't just get
here) and  I am coming from a team development environment as a
professional developer, so slings and arrows have no effect. I am not
slamming CC65. Why not use CVS and keep the snapshot to yourself? CVS,
RCS, PVCS, VSS, whatever. But CVS is configurable using password
authentication as well as ssh so there is no reason not to give
everyone access.

Why not do a weekly build and test it properly before releasing it?
Anyways, this is your thing and not mine but as far as best practices
go and my own standing as an ISO 9000 team leader and release
coordinator, the snapshot thing throws me.

Lastly if someone has a choice between something that works and is
easy to use and something that is broken and one has to search the www
to find a working version what would be the logical choice?

Regards,

Bill

PS - I notice that there are interrupt functions and reg structures
etc, in use in CC65. These are not part of standard C. What is it that
makes CC65 standard?

Bill Buckels wrote:
> On Apr 16, 2:36 am, u...@spamtrap.musoftware.de (U. v. Bassewitz)
> wrote:
> 
>>Bill Buckels <bbuck...@escape.ca> wrote:
>>
>>>I got a snapshot that was broken too... how does that happen?
>>
>>cc65 is actively developed and the snapshot is a daily snapshot of the
>>development tree. Depending on the state of development, a snapshot may
>>work great, may be buggy or may not even compile. If you don't like that,
>>you will have to go for one of the stable versions.
>>
>>
>>>I don't have much patience with things that don't work.
>>
>>No one has that. But the snapshot is not stable by definition.
>>
>>Regards
>>
>>        Uz
>>
>>--
>>Ullrich von Bassewitz                         u...@spamtrap.musoftware.de
>> 09:32:41 up 31 days, 19:23,  1 user,  load average: 0.28, 0.44, 0.73
> 
> 
> Aztec C is actively developed as well Uz but since I am at this point
> the only active developer perhaps it is understandable that it should
> be stable and easier to configure for newbies.
> 
> From my perspective the focus is not so much on changing the compiler
> since that works very well and has for decades in some versions for
> all the platforms it supports including the C64, Apple II, Z80, Amiga,
> and of course MS-DOS. My focus is in providing good clean examples and
> link libraries and an out-of-the box working environment and tools to
> help include media like sound and graphics into an enriched
> application production environment. The documents are complete as well
> so I don't have the annoyance of hitting a moving target.
> 
> I think my goals are very different from the goals of CC65.
> 
> As I take Aztec C through the open source and the necessary rewrite to
> C99 etc. I may experience some of these configuration management
> problems myself, but my last 30 years in CMS tells me that I probably
> won't, so I really still don't understand why a snapshot is used and
> why anyone would offer broken software and not expect it to be
> criticized.
> 
> These are fair questions, statements of experience (I didn't just get
> here) and  I am coming from a team development environment as a
> professional developer, so slings and arrows have no effect. I am not
> slamming CC65. Why not use CVS and keep the snapshot to yourself? CVS,
> RCS, PVCS, VSS, whatever. But CVS is configurable using password
> authentication as well as ssh so there is no reason not to give
> everyone access.
> 
> Why not do a weekly build and test it properly before releasing it?
> Anyways, this is your thing and not mine but as far as best practices
> go and my own standing as an ISO 9000 team leader and release
> coordinator, the snapshot thing throws me.

When the "development team", especially testers, is distributed
globally, it makes perfect sense to "release" the daily build to
them with full knowledge that something may have "broken" it in
some as yet undiscovered way.  That limited release is what allows
the fearless testers to find and report any problems.

It is common for a regular build process to do only limited
regression testing, so such builds are not expected to be robust,
though they are the first vehicle reflecting recent changes.

The problem arises when someone uses a snapshot thinking that it
is a "released" version--which only happens if they don't "read the
label".

> Lastly if someone has a choice between something that works and is
> easy to use and something that is broken and one has to search the www
> to find a working version what would be the logical choice?

The released versions are even easier to find than the snapshots.
You have to go looking for trouble *and not read the label* to find it.

Surely, as an experienced team developer you know this.

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Speaking in my own defense here..

> it makes perfect sense to "release" the daily build to them with full
> knowledge that something may have "broken" it in some as yet 
> undiscovered way.

Ok, yes. But the release was "broken" in that it "didn't have all the
files". What sort of snapshot is that? How am I supposed to test a
snapshot without all the files?

> The problem arises when someone uses a snapshot thinking that it is a
> "released" version--which only happens if they don't "read the 
> label".

Well, for my part, I did "read the label". But the problem I had with
snapshot 20080414 wasn't that I couldn't compile the source, it was that
I was missing whole libraries. Snapshot 20080415 had everything I would
need to test it.

> The released versions are even easier to find than the snapshots. You
> have to go looking for trouble *and not read the label* to find it.

Yeah, I did find the release. But I didn't report problems with the 
release, either. My problem was with using both versions at once (user 
error). I also did tests from clean installs which a) showed where I had 
made my mistake and b) showed that something was missing from the snapshot.

- Gio

-- 
AND NOW FOR A WORD (an IF blog):

http://giomancer.wordpress.com/

On Apr 16, 2:58=A0pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> Surely, as an experienced team developer you know this.
>
> -michael

Nope.

We don't use snapshots. Never have. Build from scratch using a
repository.

I wasn't being sarcastic either. But why wopuld you assume that some
trendy little deal that you have going is some type of standard?

Bill

Bill Buckels wrote:
> On Apr 16, 2:58 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
>> Surely, as an experienced team developer you know this.
>>
>> -michael
> 
> Nope.
> 
> We don't use snapshots. Never have. Build from scratch using a
> repository.
> 
> I wasn't being sarcastic either. But why wopuld you assume that some
> trendy little deal that you have going is some type of standard?
> 
> Bill

Interesting.  I never considered a nightly automated build procedure a 
*trendy little deal*.  I have considered it a vital tool to ensure 
quality.  Daily regression testing is an important way to keep large, 
complex projects from getting out of hand.  Keeping the snapshot of the 
daily build is simply a convenience for the developers and those wanting 
to test.  I'm sure CVS access is available for cc65 if you ask nicely.

cc65 is built and contributed by people all over the world, so to 
accommodate everyone there are daily snapshots.  They are meant for 
developers and contributers to the codebase, not those wanting to use 
the compiler.  There are released versions for that.  Not sure why that 
is a difficult concept.  There is much documentation if you just look. 
Sample code exists.  Perhaps it isn't real newbie friendly, but it is there.

Programming the 6502 is really an exercise in embedded programming 
nowadays.  cc65 is basically (no pun intended) a powerful 
cross-compiler/assembler/linker build environment for multiple targets. 
  I actually use the assembler/linker combination extensively, as I find 
the 6502 a poor target for C.  Getting the resultant binary image to the 
target is an issue for every build tool, Aztec C included.

I am glad to see someone continuing to develop and nurture the older 
tools though.  I also didn't realize Aztec C could target CP/M.  There 
is another free compiler under active development that targets the Z-80. 
  http://sdcc.sf.net is a powerful embedded target C 
compiler/assembler/linker.  I used it to develop the firmware on 
astronomical CCD cameras from StarlightXpress 
(http://www.starlight-xpress.co.uk/products.htm) although it was for a 
8051 target.  They have nightly snapshots available as well, but I don't 
recommend them unless you are contributing to the code :-)

So, there are many options for us.  I hope Aztec C is able to join the 
list of freely available tools.  I particularly like the idea of an 
Apple II hosted compiler - I enjoy the hands-on approach.  However, 
there is no need criticize one tool over another, they all have their 
strengths and weaknesses.  The approach to developing these tools may 
not make sense to you - but it probably does to a lot of others.  An 
open mind is a wonderful thing.

Good luck with Aztec C, I look forward to another modern compiler.

Dave...

Gio wrote:
> Speaking in my own defense here..
> 
>> it makes perfect sense to "release" the daily build to them with full
>> knowledge that something may have "broken" it in some as yet 
>> undiscovered way.
> 
> 
> Ok, yes. But the release was "broken" in that it "didn't have all the
> files". What sort of snapshot is that? How am I supposed to test a
> snapshot without all the files?
> 
>> The problem arises when someone uses a snapshot thinking that it is a
>> "released" version--which only happens if they don't "read the label".
> 
> 
> Well, for my part, I did "read the label". But the problem I had with
> snapshot 20080414 wasn't that I couldn't compile the source, it was that
> I was missing whole libraries. Snapshot 20080415 had everything I would
> need to test it.
> 
>> The released versions are even easier to find than the snapshots. You
>> have to go looking for trouble *and not read the label* to find it.
> 
> 
> Yeah, I did find the release. But I didn't report problems with the 
> release, either. My problem was with using both versions at once (user 
> error). I also did tests from clean installs which a) showed where I had 
> made my mistake and b) showed that something was missing from the snapshot.

Glad you found the problem.

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Bill Buckels wrote:
> On Apr 16, 2:58 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> 
>>Surely, as an experienced team developer you know this.
>>
>>-michael
> 
> 
> Nope.
> 
> We don't use snapshots. Never have. Build from scratch using a
> repository.

Sure.

And the changes introduced may affect any files that are
included in the snapshot, or it may not include them...
In short, introducing changes on a short schedule may break
a build, but not break the build process.

I prefer that a build process include some regression testing
(just to catch the obvious), but errors can *always* occur.

And an extensive testing process that is performed by people
not all in one place is not completed in a day.  Therefore, the
partially tested build is made available for them to test.

> I wasn't being sarcastic either. But why wopuld you assume that some
> trendy little deal that you have going is some type of standard?

I've never seen a software development that didn't rely on some
such process.  The alternative is to hold back releasing new bits
until they are thoroughly tested, but then the testers don't get
them--a contradiction in terms.

Every ongoing software development process (unless all the development
and testing is done by one person) must provide *both* the "last solid
build" for production work and the "latest test build" for further
testing and validation.

Many processes allow for access to multiple "solid" builds and multiple
"test" builds to accomodate folks who don't want to switch horses in the
middle of something that takes a while.

You don't have to think this up--your users and co-developers will
force it upon you!  ;-)

User 1:  "I've got to have a version that fixes that bug I reported
           to you yesterday to meet my schedule!" (daily build)

User 2:  "Don't change *anything* until we've finished getting our
           release out!" (stable version)

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Michael J. Mahon wrote:
> 
> You don't have to think this up--your users and co-developers will
> force it upon you!  ;-)
> 
> User 1:  "I've got to have a version that fixes that bug I reported
>           to you yesterday to meet my schedule!" (daily build)
> 
> User 2:  "Don't change *anything* until we've finished getting our
>           release out!" (stable version)
>

Marketing Droid:  "Ship it!" (grabs random files from developers machine)

:-)  Dave...

> -michael
> 
> NadaPong: Network game demo for Apple II computers!
> Home page:  http://members.aol.com/MJMahon/
> 
> "The wastebasket is our most important design
> tool--and it's seriously underused."

Gio <giomancer@sbcglobal.net> wrote:
> Ok, yes. But the release was "broken" in that it "didn't have all the
> files". What sort of snapshot is that?

The snapshot reflects the exact state of the development trunk. If the
development trunk contains errors (this may happen for example, if not all
files that make up a change are commited), the nightly build won't create
some of the files. These files are then missing in the snapshot.
            
Admittedly, the build script could be improved. But having the snapshot is
better than not having it, and it's usually no problem if you know what
you get.

> Yeah, I did find the release. But I didn't report problems with the
> release, either. My problem was with using both versions at once (user
> error). I also did tests from clean installs which a) showed where I had
> made my mistake and b) showed that something was missing from the snapshot.

I'm glad for you that you're more forgiving with your own mistakes than
with mine:-)

Regards


        Uz


-- 
Ullrich von Bassewitz                         uz@spamtrap.musoftware.de
 09:52:38 up 32 days, 19:43,  2 users,  load average: 1.30, 1.11, 0.93

On Apr 17, 12:43=A0am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> I've never seen a software development that didn't rely on some
> such process.  The alternative is to hold back releasing new bits
> until they are thoroughly tested, but then the testers don't get
> them--a contradiction in terms.

If you say so. So what's your hurry? Here's some more tunnel vision
again...

I could perhaps see a complicated build process for a large project
like a portfolio management application which hosts quote services and
an order entry system. Or if a large team is required.

For a compiler project I cannot see this. Perhaps I have missed an
important understanding of what is going-on here. There is a working
compiler, assembler, linker, and library manager. Perhaps there is a
debugger and perhaps the linker allows the embedding of debug symbols,
and perhaps one can attach, detach, trace and step through in the
debugger. Perhaps not. If not this is of a relatively simple scope.

Change management starts at the top. The rationale for a change is
documented and reviewed. A risk benefit analysis is performed and if
the change is approved it is scheduled for a particular release.
That's of course part of the quality plan.

Regardless, there is no real need to provide QA with a product for
system testing and "black box" testing until the programming on a
particular unit is done, until the tracing and test harness have been
performed and until the code walkthrough has been done. In fact the
changes should not be checked-in until that is accomplished.

CVS is not ideal for this level of change control and RCS is probably
better in some ways using strict locks.

Therefore development builds from scratch and gets the latest checked-
in code which is stable and makes changes to a stable codebase.
Development does unit testing based on a test frame and test scripts.
If regression testing is required it is done at that level first. The
boundary and equivalence tests are determined in the test script and
the test frame reflects the individual sets that need to be performed.

After development have released the tested and finished latest changes
to QA by way of a release, the high level and system testing and
finally acceptance testing on behalf of the user is done. It is then
and only then after this process is completed that a release candidate
should be available for alpha or beta.

The development and testing of libraries and library routines is
completely independent of the development and testing of a binary
executable in a project like a compiler. In fact link libraries and
headers can be considered "baggage" independently from the compiler
itself and its core binaries.

Tools and utilities too can and should be considered separately.

So major achitectural changes to a compiler should not be mixed with
minor changes to link libraries.

A product lifecycle is part and parcel of all of this. So is
documentation.

Now anyone who wants to compare a properly managed change control
system and properly isolated developement, QA, and production areas
which is what I prefer, with some sales guy who walks over to a
development machine and raids it...

Well I promised Oliver I would be nice, so I'll just say this and be
on my merry way...

If anyone here doesn't think I fully tested every aspect of each of
the compilers that I made available from the Aztec C Website before
releasing them for download then they have not used what I put online.
Hey this stuff was really hard to find and put together and to write
the scripts and write and compile the pieces that weren't there and so
forth. I couldn't sluff it.

So I am not standing in a glass house throwing stones. I am not even
throwing stones except really soft ones and really just asking why are
you doing it this way???

Also if anyone thinks this Aztec C stuff that I talk about is native
mode and not cross-compiler well then they haven't looked. Suggesting
that I read your labels when you haven't looked at my work is somewhat
interesting to say the least...

The Aztec C for the Apple II, Commodore 64, and CP/M 80 (8080 and Z80)
and CP/M 86 are all available in cross-compilers and in native mode
compilers.  Download them and look.

The level of ANSI compliance is relative to the compilers of course,
but since Aztec C was until Microsoft pushed them out of existence a
leader in embedded systems and cross compilation, as well as providing
floating point support, this should not be discounted as a poorly
written or less capable development environment for 6502 based
machines nor for Z80 or 8080.

In fact this is the one to match if you are serious about meeting some
standards of excellence.

That assembly pass is really good with these. A person could reverse
engineer that back to an ANSI compiler without too much thought but it
will be easier with the source.

As far as other compilers and Z80 stuff and so forth you should see
the constant volume of my email on all of this over the years. Yes
there are lots of great compilers out there. My new favorite is
Digital Mars by Walter Bright. (The D Programming Language is
interesting too)  And speaking of great distributions...

My distributions are also a good example to follow, because one click
and good examples are always appreciated by end users who may not be
interested in how you are making the compiler. They are more
interested in how they can use it to make their own programs.

As far as reading some label or another, oh well, that is your thing
not mine. Why would an experienced developer even look at something
that doesn't work? To fix it? Got lots of my own stuff to fix... not
looking for more broken stuff. By the same token someone else migh say
why look at old stuff when I got new stuff...

Regards,

Bill  Buckels

PS - when I get the source for all this and talk to some of the guys
who moved Aztec C to ANSII I'll be doing the Apple II stuff first
because I understand because I have been told by those who were there
that it was almost already finished ANSII-able ready.

Bill Buckels wrote:
> On Apr 17, 12:43 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>> I've never seen a software development that didn't rely on some
>> such process.  The alternative is to hold back releasing new bits
>> until they are thoroughly tested, but then the testers don't get
>> them--a contradiction in terms.
> 
> If you say so. So what's your hurry? Here's some more tunnel vision
> again...
> 
> I could perhaps see a complicated build process for a large project
> like a portfolio management application which hosts quote services and
> an order entry system. Or if a large team is required.
> 

Anytime you have more than one developer on a project, uncalculated 
interdependencies arise.  Even then, outside forces can impact a project 
- upgrade to Vista lately?  Automated builds are just one of the easiest 
to implement sanity checks.  Why wouldn't it be part of the project process?

> For a compiler project I cannot see this. Perhaps I have missed an
> important understanding of what is going-on here. There is a working
> compiler, assembler, linker, and library manager. Perhaps there is a
> debugger and perhaps the linker allows the embedding of debug symbols,
> and perhaps one can attach, detach, trace and step through in the
> debugger. Perhaps not. If not this is of a relatively simple scope.
> 
> Change management starts at the top. The rationale for a change is
> documented and reviewed. A risk benefit analysis is performed and if
> the change is approved it is scheduled for a particular release.
> That's of course part of the quality plan.
> 
> Regardless, there is no real need to provide QA with a product for
> system testing and "black box" testing until the programming on a
> particular unit is done, until the tracing and test harness have been
> performed and until the code walkthrough has been done. In fact the
> changes should not be checked-in until that is accomplished.
> 

Nobody claims this process shouldn't be done.  I commend you for putting 
in place proper unit testing and management.  Still, the scope of a 
project shouldn't really affect the process by which it is developed.

> CVS is not ideal for this level of change control and RCS is probably
> better in some ways using strict locks.
> 

No source control program is ideal, but anything is better than nothing. 
  I have yet to find one that easy to use, unobtrusive, and cross platform.

> Therefore development builds from scratch and gets the latest checked-
> in code which is stable and makes changes to a stable codebase.
> Development does unit testing based on a test frame and test scripts.
> If regression testing is required it is done at that level first. The
> boundary and equivalence tests are determined in the test script and
> the test frame reflects the individual sets that need to be performed.
> 
> After development have released the tested and finished latest changes
> to QA by way of a release, the high level and system testing and
> finally acceptance testing on behalf of the user is done. It is then
> and only then after this process is completed that a release candidate
> should be available for alpha or beta.
> 

It depends on what you mean by way of a release to QA. If QA doesn't see 
something until the developers think they have a release candidate, 
there will probably be some time lost sorting out some basic issues. 
Developers are notoriously bad end-users of their product.  How many 
times have I heard "it works on *my* machine".  A simple, timely 
regression can reduce this sorting out. Just installing and launching 
the product can work out the most egregious errors quickly.


> The development and testing of libraries and library routines is
> completely independent of the development and testing of a binary
> executable in a project like a compiler. In fact link libraries and
> headers can be considered "baggage" independently from the compiler
> itself and its core binaries.
>

Most link libraries *are* built by the compiler.  The interdependencies 
are high and just the reason you want daily builds for a quick sanity check.

> Tools and utilities too can and should be considered separately.
> 

The end user rarely does.

> So major achitectural changes to a compiler should not be mixed with
> minor changes to link libraries.
> 

See above.  Major architectural changes usually indicate changes to the 
link libraries.

> A product lifecycle is part and parcel of all of this. So is
> documentation.
> 
> Now anyone who wants to compare a properly managed change control
> system and properly isolated developement, QA, and production areas
> which is what I prefer, with some sales guy who walks over to a
> development machine and raids it...
> 

Sorry to hear your funnybone is broken.  But, believe it or not, it has 
happened.  A desperate PM would have to send something for customer 
review and grabs something they see working.  Customer complains that 
something doesn't work. What's the build number? Whatever was on Jim's 
machine. Aaarrrgggghhhh.

> Well I promised Oliver I would be nice, so I'll just say this and be
> on my merry way...
> 

Why would you have to promise to be nice?  Wouldn't you just want to be?

> If anyone here doesn't think I fully tested every aspect of each of
> the compilers that I made available from the Aztec C Website before
> releasing them for download then they have not used what I put online.
> Hey this stuff was really hard to find and put together and to write
> the scripts and write and compile the pieces that weren't there and so
> forth. I couldn't sluff it.
> 

I don't think anyone thought that.

> So I am not standing in a glass house throwing stones. I am not even
> throwing stones except really soft ones and really just asking why are
> you doing it this way???
> 
> Also if anyone thinks this Aztec C stuff that I talk about is native
> mode and not cross-compiler well then they haven't looked. Suggesting
> that I read your labels when you haven't looked at my work is somewhat
> interesting to say the least...
> 

Again, I don't believe there was any confusion here.  My point is that 
this is one of the few compilers that also has a native implementation. 
  That is rare, and of value to me.

> The Aztec C for the Apple II, Commodore 64, and CP/M 80 (8080 and Z80)
> and CP/M 86 are all available in cross-compilers and in native mode
> compilers.  Download them and look.
> 
> The level of ANSI compliance is relative to the compilers of course,
> but since Aztec C was until Microsoft pushed them out of existence a
> leader in embedded systems and cross compilation, as well as providing
> floating point support, this should not be discounted as a poorly
> written or less capable development environment for 6502 based
> machines nor for Z80 or 8080.
> 

I don't think anyone is discounting Aztec C.  I don't run MSDOS or 
Windows so I can't really try out the cross compiler.

> In fact this is the one to match if you are serious about meeting some
> standards of excellence.
> 
> That assembly pass is really good with these. A person could reverse
> engineer that back to an ANSI compiler without too much thought but it
> will be easier with the source.
> 
> As far as other compilers and Z80 stuff and so forth you should see
> the constant volume of my email on all of this over the years. Yes
> there are lots of great compilers out there. My new favorite is
> Digital Mars by Walter Bright. (The D Programming Language is
> interesting too)  And speaking of great distributions...
> 
> My distributions are also a good example to follow, because one click
> and good examples are always appreciated by end users who may not be
> interested in how you are making the compiler. They are more
> interested in how they can use it to make their own programs.
> 
> As far as reading some label or another, oh well, that is your thing
> not mine. Why would an experienced developer even look at something
> that doesn't work? To fix it? Got lots of my own stuff to fix... not
> looking for more broken stuff. By the same token someone else migh say
> why look at old stuff when I got new stuff...
> 

I dunno, 'cause they want to?  Why would someone want to update a 20 
year old compiler ;-)

> Regards,
> 
> Bill  Buckels
> 
> PS - when I get the source for all this and talk to some of the guys
> who moved Aztec C to ANSII I'll be doing the Apple II stuff first
> because I understand because I have been told by those who were there
> that it was almost already finished ANSII-able ready.
> 
> 

Would you know how Aztec C is built, i.e. does it compile itself? It 
would be nice to be able to build for other environments (Linux, Mac). 
Looking forward to it,

Dave...

> But having the snapshot is better than not having it, and it's 
> usually no problem if you know what you get.

True. Having the snapshot is a good thing; I have no disagreements
there. In fact, I don't have any disagreements with you at all. I
appreciate your help and quick analysis of my problem. And, like I said,
20080415 works just fine, with no missing files. I'm having no trouble
using it.

> I'm glad for you that you're more forgiving with your own mistakes
> than with mine:-)

Haha! I'm not, really, you just don't get to hear that side of it. :)

Seriously, though, I have no complaints about your "mistakes". The 
original error was mine in using a mishmash of versions anyway.

- Gio

-- 
AND NOW FOR A WORD (an IF blog):

http://giomancer.wordpress.com/

On Apr 17, 7:22=A0am, Bill Buckels <bbuck...@escape.ca> wrote:
> On Apr 17, 12:43=A0am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> > I've never seen a software development that didn't rely on some
> > such process. =A0The alternative is to hold back releasing new bits
> > until they are thoroughly tested, but then the testers don't get
> > them--a contradiction in terms.
>
> If you say so. So what's your hurry? Here's some more tunnel vision
> again...
>
> I could perhaps see a complicated build process for a large project
> like a portfolio management application which hosts quote services and
> an order entry system. Or if a large team is required.
>
> For a compiler project I cannot see this. Perhaps I have missed an
> important understanding of what is going-on here. There is a working
> compiler, assembler, linker, and library manager. Perhaps there is a
> debugger and perhaps the linker allows the embedding of debug symbols,
> and perhaps one can attach, detach, trace and step through in the
> debugger. Perhaps not. If not this is of a relatively simple scope.
>
> Change management starts at the top. The rationale for a change is
> documented and reviewed. A risk benefit analysis is performed and if
> the change is approved it is scheduled for a particular release.
> That's of course part of the quality plan.
>
> Regardless, there is no real need to provide QA with a product for
> system testing and "black box" testing until the programming on a
> particular unit is done, until the tracing and test harness have been
> performed and until the code walkthrough has been done. In fact the
> changes should not be checked-in until that is accomplished.
>
> CVS is not ideal for this level of change control and RCS is probably
> better in some ways using strict locks.
>
> Therefore development builds from scratch and gets the latest checked-
> in code which is stable and makes changes to a stable codebase.
> Development does unit testing based on a test frame and test scripts.
> If regression testing is required it is done at that level first. The
> boundary and equivalence tests are determined in the test script and
> the test frame reflects the individual sets that need to be performed.
>
> After development have released the tested and finished latest changes
> to QA by way of a release, the high level and system testing and
> finally acceptance testing on behalf of the user is done. It is then
> and only then after this process is completed that a release candidate
> should be available for alpha or beta.
>
> The development and testing of libraries and library routines is
> completely independent of the development and testing of a binary
> executable in a project like a compiler. In fact link libraries and
> headers can be considered "baggage" independently from the compiler
> itself and its core binaries.
>
> Tools and utilities too can and should be considered separately.
>
> So major achitectural changes to a compiler should not be mixed with
> minor changes to link libraries.
>
> A product lifecycle is part and parcel of all of this. So is
> documentation.
>
> Now anyone who wants to compare a properly managed change control
> system and properly isolated developement, QA, and production areas
> which is what I prefer, with some sales guy who walks over to a
> development machine and raids it...
>
> Well I promised Oliver I would be nice, so I'll just say this and be
> on my merry way...
>
> If anyone here doesn't think I fully tested every aspect of each of
> the compilers that I made available from the Aztec C Website before
> releasing them for download then they have not used what I put online.
> Hey this stuff was really hard to find and put together and to write
> the scripts and write and compile the pieces that weren't there and so
> forth. I couldn't sluff it.
>
> So I am not standing in a glass house throwing stones. I am not even
> throwing stones except really soft ones and really just asking why are
> you doing it this way???
>
> Also if anyone thinks this Aztec C stuff that I talk about is native
> mode and not cross-compiler well then they haven't looked. Suggesting
> that I read your labels when you haven't looked at my work is somewhat
> interesting to say the least...
>
> The Aztec C for the Apple II, Commodore 64, and CP/M 80 (8080 and Z80)
> and CP/M 86 are all available in cross-compilers and in native mode
> compilers. =A0Download them and look.
>
> The level of ANSI compliance is relative to the compilers of course,
> but since Aztec C was until Microsoft pushed them out of existence a
> leader in embedded systems and cross compilation, as well as providing
> floating point support, this should not be discounted as a poorly
> written or less capable development environment for 6502 based
> machines nor for Z80 or 8080.
>
> In fact this is the one to match if you are serious about meeting some
> standards of excellence.
>
> That assembly pass is really good with these. A person could reverse
> engineer that back to an ANSI compiler without too much thought but it
> will be easier with the source.
>
> As far as other compilers and Z80 stuff and so forth you should see
> the constant volume of my email on all of this over the years. Yes
> there are lots of great compilers out there. My new favorite is
> Digital Mars by Walter Bright. (The D Programming Language is
> interesting too) =A0And speaking of great distributions...
>
> My distributions are also a good example to follow, because one click
> and good examples are always appreciated by end users who may not be
> interested in how you are making the compiler. They are more
> interested in how they can use it to make their own programs.
>
> As far as reading some label or another, oh well, that is your thing
> not mine. Why would an experienced developer even look at something
> that doesn't work? To fix it? Got lots of my own stuff to fix... not
> looking for more broken stuff. By the same token someone else migh say
> why look at old stuff when I got new stuff...
>
> Regards,
>
> Bill =A0Buckels
>
> PS - when I get the source for all this and talk to some of the guys
> who moved Aztec C to ANSII I'll be doing the Apple II stuff first
> because I understand because I have been told by those who were there
> that it was almost already finished ANSII-able ready.

Bill,

It sounds to me like what you are describing  is software developed by
a team that is together in one place and working for a company. What
people here have been trying to describe to you, and you're somehow
missing the point, is that things like cc65 are developed by a group
of people located in different places around the world. Go take a look
around http://www.sourceforge.net and you'll see all kinds of similar
projects, with people volunteering time from around the world to work
together on some common software project. So there is a need for a
"nightly build" so that the different people working on it can see
what the latest progress is.

Just my two cents,
Dean

Bill Buckels wrote:
> On Apr 17, 12:43 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> 
>>I've never seen a software development that didn't rely on some
>>such process.  The alternative is to hold back releasing new bits
>>until they are thoroughly tested, but then the testers don't get
>>them--a contradiction in terms.
> 
> 
> If you say so. So what's your hurry? Here's some more tunnel vision
> again...

<formal, orderly software product development process snipped  ;-)>

In the cases I have participated in, the compiler product was
developed by an in-house team, both for shipment to customers
and for use by other in-house teams developing other software
(like the operating system, for example).

In this situation, the project manager of the compiler sits down
regularly with the project manager of the OS and talks about the
reported bugs, possible workarounds, desirable enhancements, and
the priority and schedule of all of the above.

This process is necessary so that the OS team can continue to make
progress (for critical bugs and enhancements) and is managed in
parallel with, but apart from, the process for managing customer
input on the last released product.

Product releases may occur once or twice per year, with *very*
significant testing (both in-team "white box" testing and QA
"black box" testing) and preparation of marketing materials, etc.

Internal "releases" of regressed but otherwise unexercised builds
are made much more frequently to support the urgent needs of the
other in-house teams.  Because all development is in-house, no
customer (one hopes, though there is the occasional lapse as Dave
describes ;-) ever sees the internal releases, but *very important*
internal "customers" see them if they need them to make progress.

In any development process complex enough to require tools (isn't
that all of them?) and more people than can sit around a lunch
table (more of them than I'd like) there is a web of dependency
of development teams upon the output of other teams.  Since all
are working simultaneously, unless a tool is essentially stable
(not being actively worked on) the need for a hierarchy of rigor
in testing will be felt.

If less-thoroughly tested versions are not made available to the
teams that need them for urgent fixes or enhancements, then 1)
those fixes and enhancements will not be tested (since the team
needing them is often the only known case depending on them) and
2) the dependent teams will be delayed by the absence of a prompt
tool delivery.

It's usually weeks or months later that QA creates tests for
newly fixed problems or new functionality--long after the actual
change and its validation by the team that needs it *now*.

Perhaps you've had the luxury of working in environments where
such dependencies did not exist, but lots of us have had to cope
with this in our careers, and with the onset of globally distributed
development the situation has "gone public".

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

On Apr 15, 12:18=A0pm, Gio <gioman...@sbcglobal.net> wrote:
> Well, I have a new problem.
>
> I can run my "Hello, World!" under DOS 3.3. Under ProDOS is a different
> story, though.
>
> I'm using the loader given in the user additions section. It works fine,
> but when it tries to load the program, I get "Error #56" as a response.
> I'm not too sure what this means..


Error #56...  is this a message from DOS?  I've never seen "error #"
in
ProDos....

Hm, looks like a typo. When I run the loader program, this is what shows 
up on the screen:

Loading /CC65TEST/TEST ...
.... Error $56 - Press Any Key

I'm running the loader after loading ProDOS from a second disk.

If I try to run the binary in BASIC (using BRUN) it says:

NO BUFFERS AVAILABLE

Not sure what this means either. Either way, I can't get the program to 
run under ProDOS.

:(

- Gio

-- 
AND NOW FOR A WORD (an IF blog):

h7ttp://giomancer.wordpress.com/

On Apr 18, 11:55=A0am, Gio <gioman...@sbcglobal.net> wrote:
> Hm, looks like a typo. When I run the loader program, this is what shows
> up on the screen:
>
> Loading /CC65TEST/TEST ...
> ... Error $56 - Press Any Key
>
> I'm running the loader after loading ProDOS from a second disk.
>
> If I try to run the binary in BASIC (using BRUN) it says:
>
> NO BUFFERS AVAILABLE
>
> Not sure what this means either. Either way, I can't get the program to
> run under ProDOS.
>
> :(
>
> - Gio
>
> --
> AND NOW FOR A WORD (an IF blog):
>
> h7ttp://giomancer.wordpress.com/


The documentation that I provide with Aztec C includes a list of
ProDOS error codes. It looks like whatever you have been using has a
bad buffer address.

However, I suspect that since I am using a stable development
environment I have never seen this problem...


      ProDOS Error Codes

hex code                Meaning
-------       --------------------------------
  00          No error
  01          Invalid number for system call
  04          Invalid param count for system call
  25          Interrupt vector table full
  27          I/O Error
  28          No device connected/detected
  2b          Disk write protected
  2e          Disk switched
  40          Invalid characters in pathname
  42          File control block table full
  43          Invalid reference number
  44          Directory not found
  45          Volume not found
  46          File not found
  47          Duplicate file name
  48          Volume Full
  49          Volume directory full
  4a          Incompatible file format
  4b          Unsupported storage type
  4c          End of file encountered
  4d          Position out of range
  4e          File Access error; eg, file locked
  50          File is open
  51          Directory structure damaged
  52          Not a ProDOS disk
  53          Invalid system call parameter
  55          Volume control block table full
  56          Bad buffer address
  57          Duplicate volume
  5a          Invalid address in bit map

On Apr 18, 7:54=A0pm, Bill Buckels <bbuck...@escape.ca> wrote:
>
> > Loading /CC65TEST/TEST ...
> > ... Error $56 - Press Any Key
>

What is a loader program? ProDOS loads the first  .SYSTEM program on
the disk automatically. Otherwise just arrow down and press enter and
the program should load at $2000 if it is in fact a SYS program.
Anyway...

> > If I try to run the binary in BASIC (using BRUN) it says:
>
> > NO BUFFERS AVAILABLE
>
> > Not sure what this means either. Either way, I can't get the program to
> > run under ProDOS.

Well I wonder why you are running BASIC. The whole point in writing in
C is to lose BASIC. No need for it.

I am also a little surprised that perror is ss terse in that
implementation. Ommission of more verbose and informative error
messages could account somehwat for the slightly smaller program size
of CC65. I wonder what ANSI has to say about implementaion of perror.

Here's Aztec C's...

perror.c
#include <stdio.h>
#include <errno.h>

struct errlist {
	int code;
	char *msg;
} errlist[] =3D {
	0x00, "No error",
	0x01, "Invalid number for system call",
	0x04, "Invalid param count for system call",
	0x25, "Interrupt vector table full",
	0x27, "I/O Error",
	0x28, "No device connected/detected",
	0x2b, "Disk write protected",
	0x2e, "Disk switched",
	0x40, "Invalid characters in pathname",
	0x42, "File control block table full",
	0x43, "Invalid reference number",
	0x44, "Path not found",
	0x45, "Volume directory not found",
	0x46, "File not found",
	0x47, "Duplicate file name",
	0x48, "Overrun error",
	0x49, "Volume table full",
	0x4a, "Incompatible file format",
	0x4b, "Unsupported storage type",
	0x4c, "End of file encountered",
	0x4d, "Position out of range",
	0x4e, "Access error",
	0x50, "File is open",
	0x51, "Directory count error",
	0x52, "Not a ProDOS disk",
	0x53, "Invalid parameter",
	0x55, "Volume control block table full",
	0x56, "Bad buffer address",
	0x57, "Duplicate volume",
	0x5a, "Invalid address in bit map",
	-1, "Unknown Error Code"
};

#define MAXERR 0x5a

perror (s)
char *s;
{
	register struct errlist * sp;

	if (errno < 0 || errno > MAXERR)
		return -1;
	if (s)
		fprintf (stderr, "%s: ", s);
	for (sp=3Derrlist;sp->code>=3D0;sp++)
		if (sp->code =3D=3D errno)
			break;
	fprintf (stderr, "%s\n", sp->msg);
	return 0;
}

First, I'd like to say thanks for your first post. While I haven't
solved this yet, I think you've given me a clue. :)

> However, I suspect that since I am using a stable development 
> environment I have never seen this problem...

True, I've had no problems with Aztec C programs running in ProDOS.

> What is a loader program?

It's not part of cc65; it's written by Oliver Schmidt to load BIN files
under ProDOS.

> Well I wonder why you are running BASIC. The whole point in writing
> in C is to lose BASIC. No need for it.

BASIC can load binary files. At least it says it can.

- Gio

-- 
AND NOW FOR A WORD (an IF blog):

http://giomancer.wordpress.com/

Bill Buckels wrote:

> Change management starts at the top. The rationale for a change is
> documented and reviewed. A risk benefit analysis is performed and if
> the change is approved it is scheduled for a particular release.
> That's of course part of the quality plan.

> CVS is not ideal for this level of change control and RCS is probably
> better in some ways using strict locks.
> 
> Therefore development builds from scratch and gets the latest checked-
> in code which is stable and makes changes to a stable codebase.
> Development does unit testing based on a test frame and test scripts.
> If regression testing is required it is done at that level first. The
> boundary and equivalence tests are determined in the test script and
> the test frame reflects the individual sets that need to be performed.
> 
> After development have released the tested and finished latest changes
> to QA by way of a release, the high level and system testing and
> finally acceptance testing on behalf of the user is done. It is then
> and only then after this process is completed that a release candidate
> should be available for alpha or beta.

Bill, I'm going to guess that you've not had a lot of involvement with 
opensource projects?  You describe a traditional "Cathedral" development 
philosophy.  This is fine - in it's place.  Opensource just does not tend to 
work this way.  The mantra is "..release early, release often".  The onus is 
on the community to understand what they are downloading, taking 
responsibility and ownership for problems - hopefully correcting any they find.

This is absolutely not going to work for the average consumer who desires 
simply to _use_ the program.  But, it's not supposed to.  If you follow Linus 
Torvalds' statements over the years, he really doesn't care how his work on 
Linux is perceived by non-coding users.  He's doing it "for fun" to express 
what he feels to be the correct direction.  If folks don't like it, fine. 
They are free and encouraged to package their own variants to enforce 
stability, individually desired feature sets, etc.  Thus, SuSE, RedHat, 
Ubuntu, etc. to fill this position.

I read CC65 as being an archetypal opensource project in this sense. 
Snapshots are, well, snapshots.  If they work, great.  If they break 
something, well, you have the source - fix it and submit the required changes. 
If you do not want to risk breakage, use a "blessed" stable release version.

Both the "cathedral" and "bazaar" models (see Eric Raymond's widely available 
essay on the subject) have validity, but they are targeting different audiences.

Steve

Hi Gio,

>And, like I said,
>20080415 works just fine, with no missing files. I'm having no trouble
>using it.

Great :-)

>The 
>original error was mine in using a mishmash of versions anyway.

I'm afraid I have to agree to that ;-)

Best, Oliver

Hi Gio,

>... Error $56 - Press Any Key

>NO BUFFERS AVAILABLE

>Not sure what this means either.

As already pointed out by others the most likely reason is that the
binary wasn't transfered to ProDOS correctly.

Best, Oliver

Hi Bill,

>What is a loader program? ProDOS loads the first  .SYSTEM program on
>the disk automatically. Otherwise just arrow down and press enter and
>the program should load at $2000 if it is in fact a SYS program.

I don't understand why "everybody" assumes that cc65 by default
generates SYS programs. This is _NOT_ the case - as documented. As
already pointed out rather often in this group the reason is that the
progams cc65 is intended for should rather be loaded to $803 instead
of $2000. The loader mentioned above is a SYS program used to load
binaries to arbitrary addresses. In example cc65 binaries to their
default address of $803.

Best, Oliver

On Apr 19, 9:03=A0am, ol...@web.de (Oliver Schmidt) wrote:

> I don't understand why "everybody" assumes that cc65 by default
> generates SYS programs. This is _NOT_ the case - as documented. As
> already pointed out rather often in this group the reason is that the
> progams cc65 is intended for should rather be loaded to $803 instead
> of $2000. The loader mentioned above is a SYS program used to load
> binaries to arbitrary addresses. In example cc65 binaries to their
> default address of $803.
>

On Apr 18, 10:42 pm, "BluPhoenyx" <bluphoe...@a2central.com.remove-j1b-
this> wrote:
> And always know where your program will load/end and what memory areas
> it will require for execution. Then proofread your code to ensure it
> isn't running or overwriting memory it shouldn't use.

First off Mike (and Oliver)

I never realized that it needed to be so complicated. Why should an
application programmer need to worry about all these things... some of
them I can see learning in due course... but the bit about *knowing*
sounds a little too carnal for a newbie... (please, there are small
children listening:) send them to bed.

Gio, the linker should manage your program arrangement in memory and
the use of overlays should keep things down to a manageable size.
Having said that I realize that you have decided to go a different
route than what I have recommended so on to understanding the problem
at hand... so you wanna be an expert eh:) I thought you were just
getting started.

There is a section in the Aztec C ReadMe about starting Aztec C SYS
programs from within the Aztec C shell interpreter. Now that I have
realized that Gio is using a loader dare I ask if this is a ProDOS sys
program similar to the Aztec C Shell of days gone by. Bare with me
while I have one of my now-famous brain f*rts here... here's da readme
note:

x--- snip ---x

9.  System programs

 Many ProDOS system programs created using Aztec C65 will crash
if they're started from the SHELL. There is no problem if they are
started from the Basic Interpreter or automatically upon system start-
up.

 The problem arises from the facts that
(1) the section of memory used by the SHELL's environment pages
(0xbc00-0xbf00) is still allocated when a system program is started,
and (2) a system program's pseudo stack grows down through the
SHELL's environment pages. If the ProDOS MLI is told to perform an
operation
and return information on the pseudo stack,
the MLI will not perform the operation if the information would be
placed in the SHELL's still-allocated environment pages.

x--- snip ---x

Ok and excellent reference in the CSA2 FAQ BTW. I think we have all
appreciated that...

For Gio's benefit I want to point him to a gif that made back in in
1990 or so I have placed on the Aztec C Website. This gif was made to
explain to a client who was a DOS 3.3 BASIC programmer what I was
doing with an Aztec C program. Really this applies to all SYS programs
in Appledom. Anything you load needs to Be-LOADed at such an address
that does not clobber anything else. Click here...

http://www.clipshop.ca/Aztec/apmap.gif

I am going to give-up asking folks why they want to do things that are
hard to make work and also suggesting that they try something easier.
I guess everyone needs a challenge. To me making a BIN file to run in
BASIC in PRODOS is a waste of time. Running BASIC in PRODOS is a waste
of time and disk space if you are writing in C.

Also to me, BLOADing and BRUNning BIN programs in DOS 3.3 from BASIC
and in fact using BASIC in DOS 3.3 is not a waste of time since ProDOS
wasn't invented yet and we did things differently then.

OK so back to ProDOS

Here's crt(0) from Aztec C65 ProDOS source. This'll go along with the
gif that I pointed you to. Question is are you trying to debug a
compiler or write a program or put one more card onto a house of cards
to see if you can do it without toppling the rest of the cards?

So when crt(0) fires up it calls samain which in turn loads the main()
program function. This is compiler specific mind you but if you are
using a loader this might tell you a thing or two about what needs to
happen...  on the way back-out of main saiman takes over again and
calls exit to end...


crt0.a65
*:ts=3D8
*
* Copyright (C) 1982,83,84,85 by Manx Software Systems, Inc.
*

	instxt	<zpage.h>

	global	_Top_,2
	global	_mbot_,2

	dseg
	public	MEMRY
MEMRY	rmb	2
	public	_Stksiz_
_Stksiz_
	fdb	$0800		;default stack size is 2K
	public	_End_
_End_
	fdb	$0001		;force into inited data space

	cseg
	public	_Uorg_,_Uend_,_Corg_

	public	.begin
	entry	.begin
=2Ebegin	cld
	lda	#>_Corg_
	cmp	#$20		;check system load address
	bne	notsys
	lda	#$fe
	ldx	#$be		;just below system global page
	bne	put
notsys	lda	$E000		;check basic type
	cmp	#$20		;is it integer?
	bne	chkap		;no, check applesoft
	lda	$4C		;get integer HIMEM
	ldx	$4D
	bne	put
chkap	lda	$73		;get applesoft HIMEM
	ldx	$74
put	sta	SP		;save in stack pointer
	sta	_End_
	stx	SP+1
	stx	_End_+1
	lda	#<_Uorg_	;clear out bss space
	sta	VAL
	lda	#>_Uorg_
	sta	VAL+1
	ldy	#0
loop	tya
	sta	(VAL),Y
	inc	VAL
	bne	skip
	inc	VAL+1
skip	lda	VAL
	cmp	#<_Uend_
	bne	loop
	lda	VAL+1
	cmp	#>_Uend_
	bne	loop
	lda	MEMRY		;set end of program for alloc routines
	sta	_Top_
	sta	_mbot_
	lda	MEMRY+1
	sta	_Top_+1
	sta	_mbot_+1
	lda	#<acc		;init pointers for floating point registers
	sta	ACC
	lda	#>acc
	sta	ACC+1
	lda	#<sec
	sta	SEC
	lda	#>sec
	sta	SEC+1
	jmp	_main_#

	dseg
	global	acc,14		;space reserved for floating point registers
	global	sec,14
*

x--- snip ---x

samain.a65
*:ts=3D8
*
* Copyright (c) 1982,83,84,85 by Manx Software Systems, Inc.
*
	instxt	<zpage.h>

	global	_dev_info_,2
	global	_devinfo_,0
	global	_fil_tab_,2
	global	_filtab_,0
	global	errno_,2
	global	_Sp_,2

	public	_main_
_main_
	lda	#<_devinfo_
	sta	_dev_info_
	lda	#>_devinfo_
	sta	_dev_info_+1
	lda	#<_filtab_
	sta	_fil_tab_
	lda	#>_filtab_
	sta	_fil_tab_+1
	sec
	lda	SP
	sbc	#6
	sta	SP
	bcs	.1
	dec	SP+1
=2E1
	ldy	#5
	lda	#0
=2E2
	sta	(SP),Y
	dey
	bpl	.2
	jsr	main_
	sec			;return from main: call exit(0)
	lda	SP
	sbc	#4
	sta	SP
	bcs	drop1
	dec	SP+1
drop1
	lda	#0
	ldy	#3
loop1
	sta	(SP),Y
	dey
	bne	loop1
	jsr	exit_
	brk
;
	public	main_
	public	exit_

x--- snip ---x

exit.c
/*	Copyright (C) 1985 by Manx Software Systems, Inc. */

#include	<prodos.h>

static
noper()
{
	return(0);
}

int (*cls_)() =3D noper;

exit(n)
int n;
{
	register unsigned i;

	(*cls_)();
	for (i=3D0;i<MAXFILES;i++)
		if (_fil_tab[i].unit)
			close(i);     /* close all remaining "unbuffered" streams */
	_exit(n);
}

x--- snip ---x


exitu.c
/*	Copyright (C) 1985 by Manx Software Systems, Inc. */

#include	<prodos.h>
#include	<sysfunc.h>

extern struct shvar {
	char			vects[6];
	int				retflg;
} *_Sp;

_exit(n)
{
	_sys_parm[0] =3D 1;
	_sys_parm[1] =3D 0;				/* close all files */
	_system(SYS_CLOSE);
	if (_Sp)						/* if called from SHELL */
		_Sp->retflg =3D n;
	(*((void (*)())0x03d0))();		/* ProDOS warm boot */
}

x--- snip ---x

So in order to be aware of what your program is doing as Poenix
suggests the above is required reading in Aztec C and I am sure CDC65
will provide you with the equivalent, and many variations thereof as
does Aztec C whether we are rumnning in and out of the Aztec C shell
since Aztec C offers an interpreted pcode mode as well as stand-alone
mode and also offers DOS 3.3 as well as ProDOS.

When it comes to loading overlays which are bits of binary with a
wrapper we use a similar but different strategy.

Now if the goal is to learn all the different ways we can load and run
code on the Apple II  that is wonderful.

Then we go back to the fundamental framework for a bit of code that is
bloaded in basic to an address then brun.

The first two bytes of the bloadable module like a hires picture is a
short int with the address that it was bsaved from or in this case may
be the address that it is bloaded to which if a prodos sys program
should be $2000. The next two bytes are the length of the module that
needs to Be-LOADed.

BRUN will then jump to the first instruction and start executing. If
you have an error in your program then of course that error will
execute.

Lastly, since I haven't seen your code, I haven't seen your makefile,
and I don't know what it is you are up to with your linker and what
libraries you have linked to I will assume that you are doing
something like the following:

# ------------------------------------------------------------------
# (C) Copyright 2008 Bill Buckels
# makefile by bill buckels 2007
#
# note: I am copying ovld.r and samain.r to the current directory
# otherwise linker commandline exceeds maximum length
# note: the libraries a listed twice on the linker line
#       this ensures that LN65 resolves routines in libraries
#       that have depencies on other libraries
# big
# note: my utility MAKEPRO2 is required to strip the BLOADable header
#       from the linker output in the root module and to embed the
#       the raw bitmap splash screen and the cursor library
#       (snail cursor and musical note) in the memory holes in the
#       root module. the xfer program provided by Aztec C strips
#       off the BLOADable header when xfering to a ProDOS xfer slave
#       if a serial cable used to transfer this to a real Apple IIe
#       We use the same linker for programs that are created for
#       for Apple DOS 3.3 in which case the load address needs to
#       be left in place and in which case the xfer program does not
#       strip the load address. I never have built DOS 3.3 programs
#       and did not much care for the tedious task of using xfer
#       to transfer files one at a time from the IBM-PC to the Apple
IIe
#       even when this was all current so wrote myself the MAKEPRO
#       and MAKEPRO2 utilitities to prepare the final output and then
#       used proper communications packages on the Apple and IBM to
#       transfer multiple files en-masse using YMODEM protocol.
#       Anyways, it is also notable that the MKBASIC utility provided
#       with the Aztec C cross-development environment for the
#       Commodore 64 took almost the opposite approach as I did and
#       appended some Commodore BASIC startup code to the beginning
of
#       programs linked with that linker. The other consideration that
Manx's
#       developers made was to support whatever version of Pcode C
#       which ran in their shell. Since they insisted on using the
#       same linker for all their programs in any given environment
#       some little process needed to be run to produce a fit
#       executable for the real world, after they produced their
#       initial output for their lowest common denominator.
#       For your purposes since you are unlikely to produce programs
#       that run in their shell, and if you are like me you won't
bother
#       with DOS 3.3 and you won't ever worry about using xfer, just
use
#       my MAKEPRO and MAKEPRO2 utilities for all your own Apple IIe
efforts.
#       Off topic, but if you do use my Aztec64 Commodore 64
#       cross-development environment for Windows XP. the makefiles
#       in that particular environment use a separate utility that
#       I wrote for embedding Splash Screens, Fonts, and Cursor
Libraries
#       into Commodore 64 executables after linking, and then Manx's
#       MKBASIC utility is always run afterwards to produce a fit
#       executable for the C64. That's all I want to say on the
subject.
#       Delve deepr if you wish.
#
#       Have Fun!
#       Bill Buckels
#       bbuckels@mts.net
#
# ------------------------------------------------------------------

time.sys: time.r cinit.r plogo.r flogo.r mainmenu.r time0.r time0a.r
time1.r time1a.r time2.r time2a.r
    copy $(CR65)ovld.r ovld.r
    copy $(CR65)samain.r samain.r
    LN65 -t -r +s +H 4000,6004 time.r +C 2800 +D 400 ovld.r samain.r -
lSYSIO -lg2 -lc -ls -lm -lSYSIO -lg2 -lc -ls -lm
    del time.r
    MAKEPRO2 time RES\OLDIES.BIN
    del time
    @echo time.sys now created!
    LN65 -t cinit.r $(CR65)ovbgn.r time.rsm -lSYSIO -lg2 -lc -ls -lm -
lSYSIO -lg2 -lc -ls -lm
    del cinit.r
    @echo cinit.ovr now created!
    LN65 -t plogo.r $(CR65)ovbgn.r time.rsm -lSYSIO -lg2 -lc -ls -lm -
lSYSIO -lg2 -lc -ls -lm
    del plogo.r
    @echo plogo.ovr now created!
    LN65 -t flogo.r $(CR65)ovbgn.r time.rsm -lSYSIO -lg2 -lc -ls -lm -
lSYSIO -lg2 -lc -ls -lm
    del flogo.r
    @echo flogo.ovr now created!
    LN65 -t mainmenu.r $(CR65)ovbgn.r time.rsm -lSYSIO -lg2 -lc -ls -
lm -lSYSIO -lg2 -lc -ls -lm
    del mainmenu.r
    @echo mainmenu.ovr now created!
    LN65 -t time0.r $(CR65)ovbgn.r time.rsm -lSYSIO -lg2 -lc -ls -lm -
lSYSIO -lg2 -lc -ls -lm
    del time0.r
    @echo time0.ovr now created!
    LN65 -t time0a.r $(CR65)ovbgn.r time.rsm -lSYSIO -lg2 -lc -ls -lm -
lSYSIO -lg2 -lc -ls -lm
    del time0a.r
    @echo time0a.ovr now created!
    LN65 -t time1.r $(CR65)ovbgn.r time.rsm -lSYSIO -lg2 -lc -ls -lm -
lSYSIO -lg2 -lc -ls -lm
    del time1.r
    @echo time1.ovr now created!
    LN65 -t time1a.r $(CR65)ovbgn.r time.rsm -lSYSIO -lg2 -lc -ls -lm -
lSYSIO -lg2 -lc -ls -lm
    del time1a.r
    @echo time1a.ovr now created!
    LN65 -t time2.r $(CR65)ovbgn.r time.rsm -lSYSIO -lg2 -lc -ls -lm -
lSYSIO -lg2 -lc -ls -lm
    del time2.r
    @echo time2.ovr now created!
    LN65 -t time2a.r $(CR65)ovbgn.r time.rsm -lSYSIO -lg2 -lc -ls -lm -
lSYSIO -lg2 -lc -ls -lm
    del time2a.r
    @echo time2a.ovr now created!
    del time.rsm
    del time.sym
    del cinit.sym
    del plogo.sym
    del flogo.sym
    del mainmenu.sym
    del time0.sym
    del time0a.sym
    del time1.sym
    del time1a.sym
    del time2.sym
    del time2a.sym
    del ovld.r
    del samain.r
    copy *.ovr ENGLISH\*.*
    copy *.ovr FRENCH\*.*
    copy flogo.ovr FRENCH\plogo.ovr
    del ENGLISH\flogo.ovr
    del FRENCH\flogo.ovr
    copy time.sys ENGLISH\TIME.SYSTEM
    copy time.sys FRENCH\TIME.SYSTEM
    del time.sys
    del *.ovr
    copy RES\*.FNT ENGLISH\*.*
    copy RES\*.FNT FRENCH\*.*
    copy RES\SNAIL.RIB ENGLISH\*.*
    copy RES\SNAIL.RIB FRENCH\*.*
    copy RES\PLOGO.RAG ENGLISH\PLOGO.RAG
    copy RES\FLOGO.RAG FRENCH\PLOGO.RAG
    copy RES\TIME.RIB ENGLISH\TIME.RIB
    copy RES\FTIME.RIB FRENCH\TIME.RIB
    cls
    @echo Done!


time.r: time.c
        c65 time.c

cinit.r: cinit.c
        c65 cinit.c

plogo.r: plogo.c
        c65 plogo.c

flogo.r: flogo.c
        c65 flogo.c

mainmenu.r: mainmenu.c
           c65 mainmenu.c

time0.r: time0.c
        c65 time0.c

time0a.r: time0a.c
        c65 time0a.c

time1.r: time1.c
        c65 time1.c

time1a.r: time1a.c
        c65 time1a.c

time2.r: time2.c
        c65 time2.c

time2a.r: time2a.c
        c65 time2a.c

x-- snip --x

Yes let's make it really complicated to get you started.

Regards,

Bill

On Apr 19, 7:53=A0am, Steven Hirsch <snhir...@gmail.com> wrote:

> Bill, I'm going to guess that you've not had a lot of involvement with
> opensource projects? =A0You describe a traditional "Cathedral" development=

> philosophy. =A0This is fine - in it's place. =A0Opensource just does not t=
end to
> work this way. =A0The mantra is "..release early, release often". =A0The o=
nus is
> on the community to understand what they are downloading, taking
> responsibility and ownership for problems - hopefully correcting any they =
find.

Yes well, I actually did know that, and I have not had any involvment
with opensource projects. Some of what I have said has been quite
tongue in cheek and I am not sure how I feel about opensource in
general (this is something I have been wrestling with for about the
last 5 years or so now). Sometimes my opensource side wins but
generally my Mantra sticks in one groove ("Write in C, Write in C,
Write in C, Write in C") and doesn't go the shareware route so much
since the '90's:

See the following Link (this is one of my many Wiki Articles)

http://www.aboutus.org/ReleaseEarlyReleaseOften

Release Early Release Often

By Bill Buckels http://www.aboutus.org/User:Bill_Buckels

About Releasing

The concept of a Release was originally used in the professional
Product Engineering field. When a manufactured product is developed it
is first designed, prototyped, and then formal documents including
drawings (manufacturing details) are released by the engineering group
to the manufacturing group who then build the product for
distribution.

About Releasing Software

With the evolution of the Software Engineering field and the
prevalence of computer software in modern times, many concepts have
been borrowed from Product Engineering, and then evolved to fit
software production. These concepts include Release, and Revision, and
Quality Assurance to name a few.

Software Engineering is a little different than Product Engineering in
that a computer program can be quite usable even if it is only
partially complete, unlike a hard product (like an automobile) which
would be quite useless if only partially complete.

About Incremental Development

In Product Engineering to eliminate expensive mistakes, often
protoptypes are built and tested in the design phase, long before a
product release. This process is known as iterative design.

However since software can generally be released in a partially
functional to almost complete state, Software Engineering uses a
different approach known as Incremental Development.

About Incremental Releases

The process of Incremental Development has evolved a release
terminology that is (almost) unique to Software, and generally has
three release levels which can also have levels of their own:

Alpha - Rough and Unfinished, programs may crash and burn.
Beta - Programs Run and are Almost Finished
Early Beta - A Ways Away from Complete
Beta 2, Beta 3, Etc.
Final Beta - Release Candidate 1,2,3, Etc.
Release - Version 1.0, Etc.

About Releasing Information

To further confuse the issue, Technical Writing also follows this (or
similar) practices and because we who use computers have become so
accustomed to this programming terminology, the defacto action that
some of us consider even with our own informal documents that we
publish online is to Release them.

However, it does not stop there, because live documents like Wiki's
(and indeed any collaborative document) are really developed and not
merely written. This begs the question:

Why not release information rather than merely publish it?

The corporate culture and government have been providing the media
with news releases since any of us can remember, but now we have the
ability to provide each other with information releases.

About Releasing Often

If you suggested to a Product Engineer that a product should be
released often, you would very likely be considered deranged.

About Participation

But in Software Engineering we long ago realized that the earlier we
could get a computer program into the hands of the end user, the
better the chances for feedback and the ultimate success of the
program. It could also be said that this is really a marketing concept
and that we programmers are really just trying to sell something and
like to begin promoting as soon as possible. That is true to some
extent, but publicity aside, incremental development, unlike
prototyping or promotion, allows participation by the end user at an
almost finished stage when changes can be made more inexpensively
before mass distribution.

It is also cheaper to change a piece of Software than to retool an
entire assembly line in a manufacturing environmnet like an automobile
plant.

About Collaboration

Software aside, collaboration on documentation, especially online
documentation has been following the same approach for about 20 years
or more now, first with groups of BBS users in mail groups and forums,
and now evolving to online Wiki's.

Many examples exist of user written documentation; FAQ's Etc. and it
really makes sense to release often for the gatekeepers of these
documents just for the very fact of sharing common knowledge.

In a Wiki Releasing Often allows everyone to participate in a Quick
manner with prolific results.

And there you have it!

x--- snip ---x

Thanks for giving me the benefit of the doubt Steve. And you did guess
right that I haven't been involved in opensource projects just my own.

Bill

Well, this same binary worked in DOS. Should I have changed it somehow? 
I used CiderPress to put the binary on the ProDOS disk.

- Gio

-- 
AND NOW FOR A WORD (an IF blog):

http://giomancer.wordpress.com/

Bill Buckels wrote:
<snip>
> Then we go back to the fundamental framework for a bit of code that is
> bloaded in basic to an address then brun.
> 
> The first two bytes of the bloadable module like a hires picture is a
> short int with the address that it was bsaved from or in this case may
> be the address that it is bloaded to which if a prodos sys program
> should be $2000. The next two bytes are the length of the module that
> needs to Be-LOADed.

Actually, this is only true for DOS binary files, not ProDOS.

ProDOS stores this information in the file's directory entry.

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Gio wrote:
> Well, this same binary worked in DOS. Should I have changed it somehow? 
> I used CiderPress to put the binary on the ProDOS disk.

DOS binary files contain a 2-byte address and a 2-byte length prefixed
to the actual binary data.

ProDOS binary files have the metadata in the file's directory entry, and
do not prefix anything to the binary file.

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Gio wrote:
> Well, this same binary worked in DOS. Should I have changed it somehow? 
> I used CiderPress to put the binary on the ProDOS disk.
> 
> - Gio
> 

Gio-

I was confused about the build procedure and resultant binary as well. 
Oliver cleared up some of the questions in an earlier thread.  If I mess 
this up, perhaps Oliver will correct me.

The binary built for the Apple II can run under both DOS and ProDOS if 
it only does I/O to the console.  File I/O is only supported under 
ProDOS due to the way the standard I/O library is written.  File I/O 
under DOS was implemented using a CHR$(4) embedded in PRINT statements 
which doesn't map to the C I/O library very well.  Implementing a 
machine language interface to DOS requires quite a bit of internal DOS 
knowledge.  Nobody has stepped up to the plate to implement the C I/O 
library for DOS files.

Now, why is a separate loader required under ProDOS?  Mostly to be more 
memory efficient.  I still feel building a .SYSTEM file directly would 
be a beneficial addition to cc65.  However, a .SYSTEM file loads at 
$2000 which is where HIRES graphics starts, precluding HIRES graphics 
(page 2 at $4000) from all but the shortest programs.  Perhaps embedding 
the loader program (or just a relocator) into the resultant binary would 
be the best option.  That would require a little bit of work on someones 
part.  Welcome to open source :-)

The last item is the header at the beginning of the binary.  Under DOS, 
there is a two byte start address and a two byte length making a four 
byte header.  ProDOS keeps that information in the directory structure, 
not in the binary.  Most command line tools used to insert files into 
disk images work on DOS 3.3 images, not ProDOS (CiderPress being a 
notable exception). Then, using an emulator or real machine running 
ProDOS, the binary file would be moved from the DOS 3.3 image to ProDOS 
using a ProDOS utility.  This utility would strip off the 4 byte header 
and record the information in the directory entry.  The loader program 
could then load and run the binary.

Whew.  Clear as mud?  Certainly not the easiest to follow process.  My 
guess is most people using cc65 on the Apple II are targeting ProDOS, 
there is a good argument for making this easier.  Maybe we can convince 
Oliver to look into this if we can provide some assistance.  I have a 
generic memory copy routine lying around and some experience with 
modifying cc65 libraries.  With a little debugging help
we might get something implemented without too much hassle.

Hope that helps a little.

Dave...

On Apr 19, 1:28=A0pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> Bill Buckels wrote:
>
> <snip>
>
> > Then we go back to the fundamental framework for a bit of code that is
> > bloaded in basic to an address then brun.
>
> > The first two bytes of the bloadable module like a hires picture is a
> > short int with the address that it was bsaved from or in this case may
> > be the address that it is bloaded to which if a prodos sys program
> > should be $2000. The next two bytes are the length of the module that
> > needs to Be-LOADed.
>
> Actually, this is only true for DOS binary files, not ProDOS.
>
> ProDOS stores this information in the file's directory entry.
>

Dear Mike,

Well I knew that I needed strip that header-off for a ProDOS sys
program because my linker tags it on for DOS 3.3

So tell me this, or if I wasn't so lazy I would just do it and find-
out for myself:) It has been about 20 years since I Bsaved a HI-RES
screen in ProDOS and AppleSoft and I forget.

Does Applesoft BASIC in ProDOS add the 4 byte header so this file can
be BLOADED?  Or is this in the directory entry and I just say BLOAD
and it knows where this was saved from and where it is supposed to
load to? I know about ProDOS directories just can't remember:) what
the types are and didn't even much care at the time. Just needed to
make sure my SYSTEM program loaded properly.

Yours Sincerely,

Mr. KIA

Bill Buckels wrote:
> On Apr 19, 1:28 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
>> Bill Buckels wrote:
>>
>> <snip>
>>
>>> Then we go back to the fundamental framework for a bit of code that is
>>> bloaded in basic to an address then brun.
>>> The first two bytes of the bloadable module like a hires picture is a
>>> short int with the address that it was bsaved from or in this case may
>>> be the address that it is bloaded to which if a prodos sys program
>>> should be $2000. The next two bytes are the length of the module that
>>> needs to Be-LOADed.
>> Actually, this is only true for DOS binary files, not ProDOS.
>>
>> ProDOS stores this information in the file's directory entry.
>>
> 
> Dear Mike,
> 
> Well I knew that I needed strip that header-off for a ProDOS sys
> program because my linker tags it on for DOS 3.3
> 
> So tell me this, or if I wasn't so lazy I would just do it and find-
> out for myself:) It has been about 20 years since I Bsaved a HI-RES
> screen in ProDOS and AppleSoft and I forget.
> 
> Does Applesoft BASIC in ProDOS add the 4 byte header so this file can
> be BLOADED?  Or is this in the directory entry and I just say BLOAD
> and it knows where this was saved from and where it is supposed to
> load to? I know about ProDOS directories just can't remember:) what
> the types are and didn't even much care at the time. Just needed to
> make sure my SYSTEM program loaded properly.
> 
> Yours Sincerely,
> 
> Mr. KIA

ProDOS files have meta information, aux_type below (and as Michael 
mentioned), that goes along with the directory entry.  Different 
filetypes use the meta info for different things.  Binary (.BIN) and 
BASIC (.BAS) files use it for the load address.  I don't remember if 
..SYSTEM files use it for anything as they always load at $2000.  ProDOS 
also puts the length of every file in the directory entry.  I'm pretty 
sure BASIC under ProDOS doesn't tack on any header.  The ProDOS 
Technical Ref manual is online 
(http://linux.cis.monroeccc.edu/~paulrsm/6502/PDOS8TRM.HTM) and it is 
quite well written.  Not too long with all the info you need.

Dave...

 From ProDOS TRM

Directory File Entry:

    Field                                Entry
    Length                                Offset
           +----------------------------+
   1 byte  | storage_type | name_length | $00
           |----------------------------|
           |                            | $01
           /                            /
  15 bytes /         file_name          /
           |                            | $0F
           |----------------------------|
   1 byte  |         file_type          | $10
           |----------------------------|
           |                            | $11
   2 bytes |        key_pointer         | $12
           |----------------------------|
           |                            | $13
   2 bytes |        blocks_used         | $14
           |----------------------------|
           |                            | $15
   3 bytes |            EOF             |
           |                            | $17
           |----------------------------|
           |                            | $18
           |          creation          |
   4 bytes |        date & time         |
           |                            | $1B
           |----------------------------|
   1 byte  |          version           | $1C
           |----------------------------|
   1 byte  |        min_version         | $1D
           |----------------------------|
   1 byte  |           access           | $1E
           |----------------------------|
           |                            | $1F
   2 bytes |          aux_type          | $20
           |----------------------------|
           |                            | $21
           |                            |
   4 bytes |          last mod          |
           |                            | $24
           |----------------------------|
           |                            | $25
   2 bytes |       header_pointer       | $26
           +----------------------------+

On Apr 19, 1:54=A0pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:

> Now, why is a separate loader required under ProDOS? =A0Mostly to be more
> memory efficient. =A0I still feel building a .SYSTEM file directly would
> be a beneficial addition to cc65. =A0However, a .SYSTEM file loads at
> $2000 which is where HIRES graphics starts, precluding HIRES graphics
> (page 2 at $4000) from all but the shortest programs. =A0Perhaps embedding=

> the loader program (or just a relocator) into the resultant binary would
> be the best option. =A0That would require a little bit of work on someones=

> part. =A0Welcome to open source :-)

OK Mr. Dave, consider this if you will... the Aztec C linker allows me
to put a memory hold into my program which I use to span PAGE2. I
don't use PAGE1. ProDOS loads my SYS at $2000. I use overlays for
whatever and page them in and out above my SYS program. I hope this
will be open source soon. In the meantime its still there to try.


>
> The last item is the header at the beginning of the binary. =A0Under DOS,
> there is a two byte start address and a two byte length making a four
> byte header. =A0ProDOS keeps that information in the directory structure,
> not in the binary. =A0Most command line tools used to insert files into
> disk images work on DOS 3.3 images, not ProDOS (CiderPress being a
> notable exception). Then, using an emulator or real machine running
> ProDOS, the binary file would be moved from the DOS 3.3 image to ProDOS
> using a ProDOS utility. =A0This utility would strip off the 4 byte header
> and record the information in the directory entry. =A0The loader program
> could then load and run the binary.
>

I didn't know that everything worked that way. I just YMODEM'd my
stuff from the IBM-PC to the Apple IIe and didn't much care. I wrote
my own stripper and embedder for PRODOS SYSTEM.


> Whew. =A0Clear as mud? =A0Certainly not the easiest to follow process. =A0=
My
> guess is most people using cc65 on the Apple II are targeting ProDOS,
> there is a good argument for making this easier. =A0Maybe we can convince
> Oliver to look into this if we can provide some assistance. =A0I have a
> generic memory copy routine lying around and some experience with
> modifying cc65 libraries. =A0With a little debugging help
> we might get something implemented without too much hassle.
>
> Hope that helps a little.
>
> Dave...

I think that you need a linker that will put memory holes into areas
that you don't want to run code, the same way that MANX did it, and
that's the end of it.So your linker just checks for the best fit
around the hole and stays away from that area. It's like shoving a
bunch of files into disk-span archives... you put the big rocks in
first. then play with the space optimization once you know the worst
case scenario.

So what did you think of that memory map then?

Bill

Bill Buckels wrote:
> On Apr 19, 1:54 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
> 
>> Now, why is a separate loader required under ProDOS?  Mostly to be more
>> memory efficient.  I still feel building a .SYSTEM file directly would
>> be a beneficial addition to cc65.  However, a .SYSTEM file loads at
>> $2000 which is where HIRES graphics starts, precluding HIRES graphics
>> (page 2 at $4000) from all but the shortest programs.  Perhaps embedding
>> the loader program (or just a relocator) into the resultant binary would
>> be the best option.  That would require a little bit of work on someones
>> part.  Welcome to open source :-)
> 
> OK Mr. Dave, consider this if you will... the Aztec C linker allows me
> to put a memory hold into my program which I use to span PAGE2. I
> don't use PAGE1. ProDOS loads my SYS at $2000. I use overlays for
> whatever and page them in and out above my SYS program. I hope this
> will be open source soon. In the meantime its still there to try.
> 

Having a linker able to block out specific chunks of memory is certainly 
useful.  There are a number of embedded systems with discontinuous 
memory spaces.  One thing don't understand is why Apple chose $2000 to 
load SYSTEM programs.  It seems like the worst possible place, in my 
opinion.  Right in the middle of everything.

> 
>> The last item is the header at the beginning of the binary.  Under DOS,
>> there is a two byte start address and a two byte length making a four
>> byte header.  ProDOS keeps that information in the directory structure,
>> not in the binary.  Most command line tools used to insert files into
>> disk images work on DOS 3.3 images, not ProDOS (CiderPress being a
>> notable exception). Then, using an emulator or real machine running
>> ProDOS, the binary file would be moved from the DOS 3.3 image to ProDOS
>> using a ProDOS utility.  This utility would strip off the 4 byte header
>> and record the information in the directory entry.  The loader program
>> could then load and run the binary.
>>
> 
> I didn't know that everything worked that way. I just YMODEM'd my
> stuff from the IBM-PC to the Apple IIe and didn't much care. I wrote
> my own stripper and embedder for PRODOS SYSTEM.
> 

That's probably the most direct way to do it. At one point, I had a Rube 
Goldberg contraption involving a IIgs connected to a Mac SE/30 running 
A/UX, AppleShare Server, and NFS mounted to my Linux server.

> 
>> Whew.  Clear as mud?  Certainly not the easiest to follow process.  My
>> guess is most people using cc65 on the Apple II are targeting ProDOS,
>> there is a good argument for making this easier.  Maybe we can convince
>> Oliver to look into this if we can provide some assistance.  I have a
>> generic memory copy routine lying around and some experience with
>> modifying cc65 libraries.  With a little debugging help
>> we might get something implemented without too much hassle.
>>
>> Hope that helps a little.
>>
>> Dave...
> 
> I think that you need a linker that will put memory holes into areas
> that you don't want to run code, the same way that MANX did it, and
> that's the end of it.So your linker just checks for the best fit
> around the hole and stays away from that area. It's like shoving a
> bunch of files into disk-span archives... you put the big rocks in
> first. then play with the space optimization once you know the worst
> case scenario.
> 
> So what did you think of that memory map then?
> 
> Bill

To make efficient use of the Apple II memory map is definitely a 
challenge.  Being able to set aside memory holes is a nice feature.  The 
linker for cc65 is pretty much a standard linker as far as I know.  It 
is able to define multiple segments and place them wherever you'd like. 
  To get around the HiRes page 2 could be done, but not without some 
work.  Maybe someone how knows the ways of ld65 better than me can chime in.

cc65 wasn't developed specifically for the Apple II.  Aztec C really 
focused on the Apple, and probably shows in its ability to take 
advantage of Apple features.  That in particular is why we're all hoping 
you make progress getting it open sourced.  A real asset.

Dave...

Bill Buckels wrote:
> On Apr 19, 1:28 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> 
>>Bill Buckels wrote:
>>
>><snip>
>>
>>>Then we go back to the fundamental framework for a bit of code that is
>>>bloaded in basic to an address then brun.
>>
>>>The first two bytes of the bloadable module like a hires picture is a
>>>short int with the address that it was bsaved from or in this case may
>>>be the address that it is bloaded to which if a prodos sys program
>>>should be $2000. The next two bytes are the length of the module that
>>>needs to Be-LOADed.
>>
>>Actually, this is only true for DOS binary files, not ProDOS.
>>
>>ProDOS stores this information in the file's directory entry.
>>
> 
> 
> Dear Mike,
> 
> Well I knew that I needed strip that header-off for a ProDOS sys
> program because my linker tags it on for DOS 3.3
> 
> So tell me this, or if I wasn't so lazy I would just do it and find-
> out for myself:) It has been about 20 years since I Bsaved a HI-RES
> screen in ProDOS and AppleSoft and I forget.
> 
> Does Applesoft BASIC in ProDOS add the 4 byte header so this file can
> be BLOADED?  Or is this in the directory entry and I just say BLOAD
> and it knows where this was saved from and where it is supposed to
> load to? I know about ProDOS directories just can't remember:) what
> the types are and didn't even much care at the time. Just needed to
> make sure my SYSTEM program loaded properly.

BASIC.SYSTEM will not add any header to the file--the attributes of
load address and length are stored in the ProDOS directory entry.

This is the "conversion" that is done when a binary file is copied
from DOS to ProDOS or vice versa by file utilities.

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

On Apr 19, 7:21=A0pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>
> That's probably the most direct way to do it. At one point, I had a Rube
> Goldberg contraption involving a IIgs connected to a Mac SE/30 running
> A/UX, AppleShare Server, and NFS mounted to my Linux server.
>

You are a lucky man to have all those toys. I once had a GS and a IICI
and an Apple IIe with a 5MGHZ ZIP Chip. They all got given back or
given away but lately I traded some catfish for a IIe and my son
passed my C64 back to me... these AMD 64/3000's that my wife and I
have are fun but they are not toys.

> cc65 wasn't developed specifically for the Apple II. =A0Aztec C really
> focused on the Apple, and probably shows in its ability to take
> advantage of Apple features. =A0That in particular is why we're all hoping=

> you make progress getting it open sourced. =A0A real asset.
>
> Dave...

Did you just call me an Ass-et:) I sometimes am but not on purpose.

Aztec C was written by some very special people. It is almost perfect
and was without doubt the best C compiler of the 80's and perhaps of
all time for a number of platforms.

I think it might be open-sourced pretty quickly at least for the Apple
II. I talked to Harry Suckow, the Boss over at Manx Software Systems
for about 2 hours today, and I talked to Jim Goodnow last night, and
also to Tom Fenwick's "better half" last night, and I expect Tom to
call back perhaps tomorrow when he gets back to town. Everything looks
very promising.

I don't much like the idea of a GPL. Harry like me has mixed feelings
on this. We both still believe that one good compiler programmer is
worth 100 ordinary ones or thereabouts. I have half a thought that
perhaps Jim Goodnow and Tom Fenwick could help me in getting this
ansified and ported. Open source is one thing but allowing everyone to
partcipate in development is quite another. I would like to release
the source as part of a pre-compiled version for a numberof of distros
and of course the Mac Plus as well as for the new CBM machines.

Aztec C should have an IDE as well, probably Eclipse as suggested by
Oliver.

It is important to me to have the history of Manx and Aztec C told
properly. The history of the 6502 and some of Harry's stories are
amazing. He has been cutting code since around 1964 right until now,
but then he's only 63 years old so you wouldn't expect him to have
stopped yet. Harry once had an Aztec C user back in the 80's who was
cutting C code in his 80's so there is lots of time.

Bill

Hi Bill,

>I never realized that it needed to be so complicated.

> The problem arises from the facts that
>(1) the section of memory used by the SHELL's environment pages
>(0xbc00-0xbf00) is still allocated when a system program is started,
>and (2) a system program's pseudo stack grows down through the
>SHELL's environment pages. If the ProDOS MLI is told to perform an
>operation
>and return information on the pseudo stack,
>the MLI will not perform the operation if the information would be
>placed in the SHELL's still-allocated environment pages.

That's what I'd call complicated ;-)

My ProDOS loader sets up the system bitmap to allow for ProDOS I/O
from $800-$BF00.

Best, Oliver

Hi David,

>I was confused about the build procedure and resultant binary as well. 
>Oliver cleared up some of the questions in an earlier thread.  If I mess 
>this up, perhaps Oliver will correct me.

Thanks for stepping in :-)

>The binary built for the Apple II can run under both DOS and ProDOS if 
>it only does I/O to the console.  File I/O is only supported under 
>ProDOS due to the way the standard I/O library is written.  File I/O 
>under DOS was implemented using a CHR$(4) embedded in PRINT statements 
>which doesn't map to the C I/O library very well.  Implementing a 
>machine language interface to DOS requires quite a bit of internal DOS 
>knowledge.  Nobody has stepped up to the plate to implement the C I/O 
>library for DOS files.

Full ACK.

>Now, why is a separate loader required under ProDOS?  Mostly to be more 
>memory efficient.  I still feel building a .SYSTEM file directly would 
>be a beneficial addition to cc65.

It nearly works out-of-the-box: Just use the --start-addr linker
option to have the binary loaded at $2000. The only issue is that the
program will try to exit through $3D0 - which doesn't point to
something useful for a SYS program. So you'd need to explictily call
ProDOS quit instead to exit your program...

>$2000 which is where HIRES graphics starts, precluding HIRES graphics 
>(page 2 at $4000) from all but the shortest programs.  Perhaps embedding 
>the loader program (or just a relocator) into the resultant binary would 
>be the best option.  That would require a little bit of work on someones 
>part.  Welcome to open source :-)

It's MUCH faster to have a sapling sized (smaller than 512 byte -> 1
ProDOS block) loader that directly loads the binary from disk right to
the final destination than to load the whole binary to the wrong
address an relocate it later ! Not even mentioning that programs with
large code and data segments but a small bss segment and a small heap
most likely just won't load at $2000 in the first place ! When looking
at large ProDOS programs (i.e. from Apple) they all come as several
binaries. The ProDOS SYS program interface is designed to be used that
way. Therefore the load address of $2000 - Apple presumed hires
graphics programs to be most memory consuming. Those programs might
want to load code and data everywhere but not into the hires screen.
Therefore thats the best place for the loader ;-)

>The last item is the header at the beginning of the binary.  Under DOS, 
>there is a two byte start address and a two byte length making a four 
>byte header.  ProDOS keeps that information in the directory structure, 
>not in the binary.  Most command line tools used to insert files into 
>disk images work on DOS 3.3 images, not ProDOS (CiderPress being a 
>notable exception). Then, using an emulator or real machine running 
>ProDOS, the binary file would be moved from the DOS 3.3 image to ProDOS 
>using a ProDOS utility.  This utility would strip off the 4 byte header 
>and record the information in the directory entry.  The loader program 
>could then load and run the binary.

Full ACK.

>Whew.  Clear as mud?  Certainly not the easiest to follow process.  My 
>guess is most people using cc65 on the Apple II are targeting ProDOS, 
>there is a good argument for making this easier.  Maybe we can convince 
>Oliver to look into this if we can provide some assistance.  I have a 
>generic memory copy routine lying around and some experience with 
>modifying cc65 libraries.  With a little debugging help
>we might get something implemented without too much hassle.

As I pointed out above I'm absolutely convinced that the loader/binary
approach is correct. However I didn't notice until recently that
CiderPress is free now. Before doing anything else I'd like to work on
improving the interoperability between cc65 and CiderPress one way or
the other. My goal is to allow users to move both the loader and the
cc65-generated binary directly from the Windows filesystem to a ProDOS
image without thinking on headers at all.

Best, Oliver

Hi David,

>To make efficient use of the Apple II memory map is definitely a 
>challenge.  Being able to set aside memory holes is a nice feature.  The 
>linker for cc65 is pretty much a standard linker as far as I know.  It 
>is able to define multiple segments and place them wherever you'd like. 
>To get around the HiRes page 2 could be done, but not without some 
>work.  Maybe someone how knows the ways of ld65 better than me can chime in.

From http://www.cc65.org/snapshot-doc/apple2enh-5.html:

==========

Note that programs using this driver will have to be linked with
--start-addr $4000 to reserve the first hires page or with
--start-addr $6000 to reserve both hires pages.

In memory constrained situations the memory from $803 to $1FFF can be
made available to a program by executing _heapadd ((void *) 0x0803,
0x17FD); at the beginning of main(). Doing so is beneficial even if
the program doesn't use the the heap explicitly because loading the
driver (and in fact already opening the driver file) uses the heap
implicitly.

==========

Doing so will have the C-Library allocate the 1024 byte ProDOS I/O
buffer at $900. Then the graphics driver will be loaded at $D00. I'm
not perfectly sure but it'll use memory up to something like $1C00. So
I think that the current cc65 setup already makes quite good use of
the Apple2 memory (and further ProDOS file I/O would reuse the
$900-$D00 area if the program doesn't use the heap itself).

Apart from that it's not that hard to have cc65 create programs which
use both $800-$2000 _AND_ $4000-$... for compiler-generated segments:
The linker allows to specify several output files and allows arbitrary
distribution of memory areas to those files. The only thing _NOT_
available are segments using several memory areas. So you'd need to
hand tune what goes where - which seems from my little knowledge to be
basically the same with the Aztec-C overlays. If you do that clever
you can load the second file from the first from within main() using
the C-library.

Best, Oliver

Bill Buckels wrote:
> On Apr 19, 7:21 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>> That's probably the most direct way to do it. At one point, I had a Rube
>> Goldberg contraption involving a IIgs connected to a Mac SE/30 running
>> A/UX, AppleShare Server, and NFS mounted to my Linux server.
>>
> 
> You are a lucky man to have all those toys. I once had a GS and a IICI
> and an Apple IIe with a 5MGHZ ZIP Chip. They all got given back or
> given away but lately I traded some catfish for a IIe and my son
> passed my C64 back to me... these AMD 64/3000's that my wife and I
> have are fun but they are not toys.
> 

Slow, temperamental, high maintenance toys :-)

>> cc65 wasn't developed specifically for the Apple II.  Aztec C really
>> focused on the Apple, and probably shows in its ability to take
>> advantage of Apple features.  That in particular is why we're all hoping
>> you make progress getting it open sourced.  A real asset.
>>
>> Dave...
> 
> Did you just call me an Ass-et:) I sometimes am but not on purpose.
> 
> Aztec C was written by some very special people. It is almost perfect
> and was without doubt the best C compiler of the 80's and perhaps of
> all time for a number of platforms.
> 
> I think it might be open-sourced pretty quickly at least for the Apple
> II. I talked to Harry Suckow, the Boss over at Manx Software Systems
> for about 2 hours today, and I talked to Jim Goodnow last night, and
> also to Tom Fenwick's "better half" last night, and I expect Tom to
> call back perhaps tomorrow when he gets back to town. Everything looks
> very promising.
> 
> I don't much like the idea of a GPL. Harry like me has mixed feelings
> on this. We both still believe that one good compiler programmer is
> worth 100 ordinary ones or thereabouts. I have half a thought that
> perhaps Jim Goodnow and Tom Fenwick could help me in getting this
> ansified and ported. Open source is one thing but allowing everyone to
> partcipate in development is quite another. I would like to release
> the source as part of a pre-compiled version for a numberof of distros
> and of course the Mac Plus as well as for the new CBM machines.
> 
> Aztec C should have an IDE as well, probably Eclipse as suggested by
> Oliver.
> 
> It is important to me to have the history of Manx and Aztec C told
> properly. The history of the 6502 and some of Harry's stories are
> amazing. He has been cutting code since around 1964 right until now,
> but then he's only 63 years old so you wouldn't expect him to have
> stopped yet. Harry once had an Aztec C user back in the 80's who was
> cutting C code in his 80's so there is lots of time.
> 
> Bill

Sounds like great stuff.  Taking a project open source is not a trivial 
process.  You have certainly done the hard work to contact the original 
copyright owners.  Picking a license that satisfies everyone is near 
impossible.  However, the GPL might be one that gives you more control 
than you think.  Other licenses, such as the MIT/BSD/X Consortium type 
licenses, give away a great deal of control.  These licenses actually 
allow others to take the code private, make their own changes, and 
release.  The GPL requires others to make available any changes they 
made to the source, if they redistribute.  It is still quite easy to 
retain control over the project, regardless of which license you choose. 
  Being in control of the source repository kind of gives you the keys 
to the kingdom.  Keeping the number of commiters
small will allow greater control of submitions, and your confidence higher.

Only if you piss off the users and developers would you face a revolt. 
They could then take the code and start their own, parallel project. 
This happened not too long ago with the XFree86 X server project.

I usually pick different licenses for different projects, and even 
different parts of the same project.  Hardware specific projects I 
usually release as a BSD type license, allowing others to incorporate 
the hardware support into free or commercial products (working for the 
hardware manufacturer makes this a good deal for all).  I release 
software only projects under GPL, as I want to ensure nobody gets to 
redistribute modified versions without disclosure.

It's worth reading the different license agreements.  Note that the 
copyright holders remain the copyright holders.  The licenses only 
pertain to modification and redistribution.  The copyright holders can 
even decide to have a private commercial product and an open project 
based on the same source.  The ghostscript project, a PostScript clone, 
is a successful implementation of this concept.

Good luck,

Dave...

Oliver Schmidt wrote:
> Hi David,
> 

<snip>

>> Now, why is a separate loader required under ProDOS?  Mostly to be more 
>> memory efficient.  I still feel building a .SYSTEM file directly would 
>> be a beneficial addition to cc65.
> 
> It nearly works out-of-the-box: Just use the --start-addr linker
> option to have the binary loaded at $2000. The only issue is that the
> program will try to exit through $3D0 - which doesn't point to
> something useful for a SYS program. So you'd need to explictily call
> ProDOS quit instead to exit your program...
> 

OK, that's easy.

>> $2000 which is where HIRES graphics starts, precluding HIRES graphics 
>> (page 2 at $4000) from all but the shortest programs.  Perhaps embedding 
>> the loader program (or just a relocator) into the resultant binary would 
>> be the best option.  That would require a little bit of work on someones 
>> part.  Welcome to open source :-)
> 
> It's MUCH faster to have a sapling sized (smaller than 512 byte -> 1
> ProDOS block) loader that directly loads the binary from disk right to
> the final destination than to load the whole binary to the wrong
> address an relocate it later ! 


I'm not sure this is an easy assumption.  Opening and loading two files 
vs one w/ relocation would certainly depend of many factors.  File size 
and disk layout would affect load time a lot.  However, even with a 
tenth of a second difference either way, the simplification of a one 
binary seems beneficial.  At least to me, maybe not others.

> Not even mentioning that programs with
> large code and data segments but a small bss segment and a small heap
> most likely just won't load at $2000 in the first place ! When looking
> at large ProDOS programs (i.e. from Apple) they all come as several
> binaries. The ProDOS SYS program interface is designed to be used that
> way. Therefore the load address of $2000 - Apple presumed hires
> graphics programs to be most memory consuming. Those programs might
> want to load code and data everywhere but not into the hires screen.
> Therefore thats the best place for the loader ;-)
> 

Well, that certainly is a good argument for loading at $2000.

<snip>

> As I pointed out above I'm absolutely convinced that the loader/binary
> approach is correct. However I didn't notice until recently that
> CiderPress is free now. Before doing anything else I'd like to work on
> improving the interoperability between cc65 and CiderPress one way or
> the other. My goal is to allow users to move both the loader and the
> cc65-generated binary directly from the Windows filesystem to a ProDOS
> image without thinking on headers at all.
> 
> Best, Oliver

That is absolutely the best thing to do right away.  Any mechanism to 
improve the process of getting cross-built binaries to the emulator or 
real hardware would be a great step forward.  I would like the single 
file transfer simplicity of doing Bill's YMODEM transfer on the Apple 
side with the slickness of ADTPro/CiderPress on the server side.  Hmmm.

Dave...

On Apr 20, 7:31=A0pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>
> Well, that certainly is a good argument for loading at $2000.
>
> <snip>

If I undertand correctly the point here is to avoid startup code and
therefore create a binary that will run in both DOS 3.3 and ProDOS...

Is that right or are you guys just debating the merits of standalone
SYS programs .vs. using Oliver's loader?

Bill

Bill Buckels wrote:
> On Apr 20, 7:31 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>> Well, that certainly is a good argument for loading at $2000.
>>
>> <snip>
> 
> If I undertand correctly the point here is to avoid startup code and
> therefore create a binary that will run in both DOS 3.3 and ProDOS...
> 
> Is that right or are you guys just debating the merits of standalone
> SYS programs .vs. using Oliver's loader?
> 
> Bill


I was just venting a little about my displeasure with SYS files loading 
at $2000.  Oliver pointed out valid reasons for it, and why it makes 
sense for applications to have loader programs.  I personally like the 
simplicity of building a standalone SYS program (that relocates itself) 
from C code, but since I don't generally write C code for the Apple II, 
my opinion on the matter is a bit moot.


As for a binary that runs under DOS 3.3 and ProDOS, my feelings are that 
  DOS 3.3 is a bit dead for new projects.  ProDOS offers so much more 
than DOS to the developer.  And I never used ProDOS until a few years ago.

You and Oliver have probably written as much C code on the Apple as 
anyone.  Perhaps that should be your discussion :-)

Dave...

On Apr 21, 7:01=A0pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
> I was just venting a little about my displeasure with SYS files loading
> at $2000.
After spending some time with SOS on an Apple ///, $2000 makes all the
sense in the world to me now... as a matter of fact, lots and lots of
things about ProDOS make more sense to me now. :-)

schmidtd wrote:
> On Apr 21, 7:01 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>> I was just venting a little about my displeasure with SYS files loading
>> at $2000.
> After spending some time with SOS on an Apple ///, $2000 makes all the
> sense in the world to me now... as a matter of fact, lots and lots of
> things about ProDOS make more sense to me now. :-)

Hi Dave-

What tools are you using to build with?  I definitely want to pick your 
brain in the near future.

Dave...

On Apr 21, 8:36=A0pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
> schmidtd wrote:
> > On Apr 21, 7:01 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
> >> I was just venting a little about my displeasure with SYS files loading=

> >> at $2000.
> > After spending some time with SOS on an Apple ///, $2000 makes all the
> > sense in the world to me now... as a matter of fact, lots and lots of
> > things about ProDOS make more sense to me now. :-)
>
> Hi Dave-
>
> What tools are you using to build with? =A0I definitely want to pick your
> brain in the near future.
ca65. ;-)  I'm so excited there is one other human on the planet that
cares about the ///!  Such an elegant architecture.  You need to read
this immediately:
http://groups.google.com/group/comp.sys.apple2/msg/34b9b48df9af9231

schmidtd wrote:
> On Apr 21, 8:36 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>> schmidtd wrote:
>>> On Apr 21, 7:01 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>>>> I was just venting a little about my displeasure with SYS files loading
>>>> at $2000.
>>> After spending some time with SOS on an Apple ///, $2000 makes all the
>>> sense in the world to me now... as a matter of fact, lots and lots of
>>> things about ProDOS make more sense to me now. :-)
>> Hi Dave-
>>
>> What tools are you using to build with?  I definitely want to pick your
>> brain in the near future.
> ca65. ;-)  I'm so excited there is one other human on the planet that
> cares about the ///!  Such an elegant architecture.  You need to read
> this immediately:
> http://groups.google.com/group/comp.sys.apple2/msg/34b9b48df9af9231

Wow.  That answered so many questions and I only skimmed it.  I have 
slowly been building up my Apple /// technical library.  Information has 
been scarce so I bought the WAP Apple III DVD to try and quickly fill in 
some gaps.  It's full of stuff, but takes some time to sift through all 
of the files.

I wouldn't have even got into the Apple III but I found one at the local 
elementary that they were throwing out.  5 MB Profile and all.  I 
salvaged a ton of software packages that were sitting out in the rain. 
They even had Cobol.  Still in the wrapper.  Our tax dollars at work.

If you don't have one yet, get a CFFA for your ///.  I modified Dale 
Jackson's driver for better performance.  He said he had problems, but 
he is also using an older hardware rev.  I copied the entire Profile a 
few times without issue.

Do you have any particular development plans for the /// that you care 
to divulge?

Dave...

Hi,

On Sun, 20 Apr 2008 19:19:25 GMT, ol.sc@web.de (Oliver Schmidt) wrote:

>As I pointed out above I'm absolutely convinced that the loader/binary
>approach is correct. However I didn't notice until recently that
>CiderPress is free now. Before doing anything else I'd like to work on
>improving the interoperability between cc65 and CiderPress one way or
>the other. My goal is to allow users to move both the loader and the
>cc65-generated binary directly from the Windows filesystem to a ProDOS
>image without thinking on headers at all.

Although CiderPress is certainly a great tool I realized in the
meanwhile that it has one shortcomming from the perspective of a
companion tool for cc65 users - it's only available on Windows :-(

Therefore I was looking for an alternative and found AppleCommander.
Being written in Java it's available on all cc65 support host
platforms. Being just an executable jar it's yet simple to install and
use.

Luckily one of the AppleCommander authors (John B. Matthews) was
extremely openminded regarding my proposals for extending
AppleCommander to support the DOS 3.3 header as "inband carrier" of
the start address attribute !

Now the result is publicly available on
http://applecommander.sourceforge.net/

See the thread 'AppleCommander, v1.3.5' is this group started on
6/5/2008 for more details...

I'm really happy to see that there's now a straightforward as
imaginable way to get from a cc65 generated Apple2 binary to a ProDOS
8 SYS file behaviour :-)

Best, Oliver