Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Added standalone barebones Apple ][ example #259
The instructions on how to create an Apple 2 binary without the C library is poorly documented.
This PR updates the
First of all: Statements like "cc65 library crap" and "didn't know anything about the Apple" will keep any pull request from being merged - no matter how interesting its content might be.
Apart from that this pull request happens to have no interesting content at all.
And finally: If the Apple II support would have to be added from scratch today I'd opt for a charset with the hibit set. However I don't see the benefit of having this even coming close to outweighing the compatibility issues with existing code. Therefore I won't change that now anymore. And the author of this pull request is the last person I'll discuss this topic with.
Fixed. Changed to less offensive: cc65's C library bloat.
Why?? Macro's already do this job for those that need it without introducing potential new bugs in the codebase -- see my apple2text.inc
The fact remains Ullrich von Bassewitz didn't understand anything about how characters worked on the Apple 2 when he posted this on On Fri, May 09, 2003:
Why do you think I wrote it with the emoticon on the end? "didn't know anything about the Apple. :-/" I was lamenting this fact.
Aside from a2tools.c being a single text file, what exactly is the tool of choice that others are using? Not everyone uses the same tool as witnessed by the various version of a2tools on asimov.
My goal was to provide a single convenient location so people could easily get something assembled instead of:
If this conflicts with cc65's goals then I understand.
That's not the goal of this repo.
This is true. Improvements are welcome. However
In case you're interested in improving the documentation please do so in separate pull request not mixing that with other things like new macros or alike.
This can generally be merged given:
Again I suggest a separate pull request for this matter.
What people are failing to understand is that the problem is about the out-of-the-box experience from the user's perspective. Think
Alice wants to compile a .S to have a runnable binary on a .DSK. What does Alice need to do assuming she is on a shiny new Windows, OSX, or Linux box?
Whoa! That's a TON of hoops one has to go through just for a simple task. Obviously once you go through that pain the workflow is greatly simplified, but where is the document that explains all of these instructions?
The turn-around time for development is about 1 second since cc65 is so fast. :-)
Also, Java may not be available on systems due to their security policy, which means AppleCommander is not an option for some people. The nice thing about a2tools is that it is a self-contained single source file that doesn't require a half a dozen different dependencies in order to use. Requiring users to download half a dozen different utilities just to produce a binary is extremely frustrating, time consuming, and over complicated.
A simple and single download & work-flow is what is being provided with my
As Oliver said earlier cc65's goals is a
To use an construction analogy: cc65 provides an excellent foundation. Since cc65 maintainers are not interested in also going the next step and providing prefabs to quickly get a building constructed, ergo, I perfectly understand this PR being closed due to different perspectives, goals, and focuses.
Hope this clarifies why this PR even exists. :-)
Such a box for sure won't run your shell script ;-) And I'm in fact not just trying to make a funny point here. A more complex project needs
Nope. There are pre-built binaries for Windows and two flavors or installers for Linux.