New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added standalone barebones Apple ][ example #259

Closed
wants to merge 30 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@Michaelangel007

Michaelangel007 commented Jan 16, 2016

The instructions on how to create an Apple 2 binary without the C library is poorly documented.

This PR updates the README.md with these instructions and adds an apple2 directory with source files and a bash script to automatically assemble, link, and copy the binary onto a .DSK image.

Bugs with the * operators are also discussed and worked around in apple2/barebones.s

Lastly, an ASC macro is provided to markup ASCII text with the high-bet set for native Apple ][ text.

Michaelangel007 added some commits Jan 16, 2016

@oliverschmidt

This comment has been minimized.

Show comment
Hide comment
@oliverschmidt

oliverschmidt Jan 16, 2016

Collaborator

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.

  • The currently available content already allows to build "standalone barebone" Apple II programs without the C library perfectly fine.
  • Stuff like a2tools doesn't belong in this repo. Apart from that it's not the Apple II tool of choice.
  • Binaries like disk images dont belong in this repo. Apart from that it might pose IP issues.
  • In this repo all builds are driven by (GNU-) Makefiles. No shell scripts.

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.

Collaborator

oliverschmidt commented Jan 16, 2016

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.

  • The currently available content already allows to build "standalone barebone" Apple II programs without the C library perfectly fine.
  • Stuff like a2tools doesn't belong in this repo. Apart from that it's not the Apple II tool of choice.
  • Binaries like disk images dont belong in this repo. Apart from that it might pose IP issues.
  • In this repo all builds are driven by (GNU-) Makefiles. No shell scripts.

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.

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Jan 17, 2016

"cc65 library crap"

Fixed. Changed to less offensive: cc65's C library bloat.

If the Apple II support would have to be added from scratch today I'd opt for a charset with the hibit set.

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:

Can someone explain me how characters work in the apple? This is the first
time I hear something about the usage of bit 7.

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.

Stuff like a2tools doesn't belong in this repo. Apart from that it's not the Apple II tool of choice.

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.

However I don't see the benefit of having this even coming close to outweighing the compatibility issues with existing code.

My goal was to provide a single convenient location so people could easily get something assembled instead of:

  • forcing people to download several tools from half-a-dozen places across the internet,
  • read out-of-date docs

If this conflicts with cc65's goals then I understand.

Michaelangel007 commented Jan 17, 2016

"cc65 library crap"

Fixed. Changed to less offensive: cc65's C library bloat.

If the Apple II support would have to be added from scratch today I'd opt for a charset with the hibit set.

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:

Can someone explain me how characters work in the apple? This is the first
time I hear something about the usage of bit 7.

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.

Stuff like a2tools doesn't belong in this repo. Apart from that it's not the Apple II tool of choice.

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.

However I don't see the benefit of having this even coming close to outweighing the compatibility issues with existing code.

My goal was to provide a single convenient location so people could easily get something assembled instead of:

  • forcing people to download several tools from half-a-dozen places across the internet,
  • read out-of-date docs

If this conflicts with cc65's goals then I understand.

@mrdudz

This comment has been minimized.

Show comment
Hide comment
@mrdudz

mrdudz Jan 17, 2016

Contributor

the cc65 repo is not supposed to provide all and everything (it does not provide a tool to put C64 binaries into .d64 files either, for example)

besides the obvious typo in README.md i dont quite understand what problem this solves either shrug

Contributor

mrdudz commented Jan 17, 2016

the cc65 repo is not supposed to provide all and everything (it does not provide a tool to put C64 binaries into .d64 files either, for example)

besides the obvious typo in README.md i dont quite understand what problem this solves either shrug

@oliverschmidt

This comment has been minimized.

Show comment
Hide comment
@oliverschmidt

oliverschmidt Jan 17, 2016

Collaborator

what exactly is the tool of choice that others are using?

Just see http://cc65.github.io/doc/intro.html#ss6.1

My goal was to provide a single convenient location

That's not the goal of this repo.

If this conflicts with cc65's goals then I understand.

Good.

The instructions on how to create an Apple 2 binary without the C library is poorly documented.

This is true. Improvements are welcome. However

cl65 -t apple2 -C apple2-asm.cfg myfile.s produces a binary containing only the code generated.

cl65 -t apple2 -C apple2-asm.cfg -u __EXEHDR__ myfile.s produces a binary containing a four-byte DOS 3.3 header plus the code generated.

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.

Collaborator

oliverschmidt commented Jan 17, 2016

what exactly is the tool of choice that others are using?

Just see http://cc65.github.io/doc/intro.html#ss6.1

My goal was to provide a single convenient location

That's not the goal of this repo.

If this conflicts with cc65's goals then I understand.

Good.

The instructions on how to create an Apple 2 binary without the C library is poorly documented.

This is true. Improvements are welcome. However

cl65 -t apple2 -C apple2-asm.cfg myfile.s produces a binary containing only the code generated.

cl65 -t apple2 -C apple2-asm.cfg -u __EXEHDR__ myfile.s produces a binary containing a four-byte DOS 3.3 header plus the code generated.

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.

@oliverschmidt

This comment has been minimized.

Show comment
Hide comment
@oliverschmidt

oliverschmidt Jan 17, 2016

Collaborator

Macro's already do this job for those that need it without introducing potential new bugs in the codebase -- see my apple2text.inc

This can generally be merged given:

Again I suggest a separate pull request for this matter.

Collaborator

oliverschmidt commented Jan 17, 2016

Macro's already do this job for those that need it without introducing potential new bugs in the codebase -- see my apple2text.inc

This can generally be merged given:

Again I suggest a separate pull request for this matter.

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Jan 18, 2016

I don't quite understand what problem this solves either shrug

What people are failing to understand is that the problem is about the out-of-the-box experience from the user's perspective. Think local vs global. Let me explain with a concrete example:

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?

  1. Download a c/c++ compiler
  2. Download an Apple emulator (AppleWin, Jace, Virtual ][, Jace)
  3. Download & build cc65
  4. Track down instructions on how to produce a binary for the Apple 2 @ http://www.cc65.org/doc/intro-6.html
  5. Download & install Java JRE (and not the Java JDK)
  6. Download SWT
  7. Download AppleCommander 1.3.5
  8. (Optional) Download AppleWin (if you didn't already) for master.dsk
  9. Copy master.dsk to cc65.dsk
  10. Manually run AppleCommander via typing in java -jar ac.jar -cc65 cc65.dsk test B < hello
  11. Fire up the emulator (or switch back to it) & mount the disk in the emulator
  12. type BRUN TEST

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?

My apple2/barebones.sh script eliminates steps 4 .. 10 and requires one step. With 5 keystrokes at a shell, one can press s + TAB (to tab complete src2dsk.sh)+ first letter of my .s file + TAB + Enter, and they have a .DSK image to (re) load into the emulator. Want to start a new "project"? Copy barebones.s to a new file, and "rebuilding" is trivial.

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 apple2/ directory. THAT's the problem being solved. :-) I thought others might be interested in a more "turn-key" solution, hence I submitted a PR.

As Oliver said earlier cc65's goals is a local one. My fork focuses on the global one.

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. :-)

Michaelangel007 commented Jan 18, 2016

I don't quite understand what problem this solves either shrug

What people are failing to understand is that the problem is about the out-of-the-box experience from the user's perspective. Think local vs global. Let me explain with a concrete example:

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?

  1. Download a c/c++ compiler
  2. Download an Apple emulator (AppleWin, Jace, Virtual ][, Jace)
  3. Download & build cc65
  4. Track down instructions on how to produce a binary for the Apple 2 @ http://www.cc65.org/doc/intro-6.html
  5. Download & install Java JRE (and not the Java JDK)
  6. Download SWT
  7. Download AppleCommander 1.3.5
  8. (Optional) Download AppleWin (if you didn't already) for master.dsk
  9. Copy master.dsk to cc65.dsk
  10. Manually run AppleCommander via typing in java -jar ac.jar -cc65 cc65.dsk test B < hello
  11. Fire up the emulator (or switch back to it) & mount the disk in the emulator
  12. type BRUN TEST

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?

My apple2/barebones.sh script eliminates steps 4 .. 10 and requires one step. With 5 keystrokes at a shell, one can press s + TAB (to tab complete src2dsk.sh)+ first letter of my .s file + TAB + Enter, and they have a .DSK image to (re) load into the emulator. Want to start a new "project"? Copy barebones.s to a new file, and "rebuilding" is trivial.

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 apple2/ directory. THAT's the problem being solved. :-) I thought others might be interested in a more "turn-key" solution, hence I submitted a PR.

As Oliver said earlier cc65's goals is a local one. My fork focuses on the global one.

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. :-)

@oliverschmidt

This comment has been minimized.

Show comment
Hide comment
@oliverschmidt

oliverschmidt Jan 18, 2016

Collaborator

on a shiny new Windows [...] box.

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 make anyway so it makes sense to add make to the list of denpendencies in the first place and use it to create any type of work-flow.

Download a c/c++ compiler
Download & build cc65

Nope. There are pre-built binaries for Windows and two flavors or installers for Linux.

Collaborator

oliverschmidt commented Jan 18, 2016

on a shiny new Windows [...] box.

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 make anyway so it makes sense to add make to the list of denpendencies in the first place and use it to create any type of work-flow.

Download a c/c++ compiler
Download & build cc65

Nope. There are pre-built binaries for Windows and two flavors or installers for Linux.

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Jan 18, 2016

Good catch about Windows and .sh -- I always forget I have cygwin installed so I have a real shell. :-) I agree make is needed for more complex projects, but for something quick-n-dirty one-offs, it is WAY overkill.

Michaelangel007 commented Jan 18, 2016

Good catch about Windows and .sh -- I always forget I have cygwin installed so I have a real shell. :-) I agree make is needed for more complex projects, but for something quick-n-dirty one-offs, it is WAY overkill.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment