Book: Apple II-6502 Assembly Language Tutor

[Neo Winston]

Hi friends!

This is my first post on the list, and I'm so exited that I found an active group of people who are still programing for the 6502 on the Apple II.

I'm learning Assembly Language, and I'm having a lot of fun. One of the books I've recently purchased is the wonderful "Apple II-6502 Assembly Language Tutor ", which used to have a companion floppy disc. Unfortunately it didn't come with the disc and I've asked the author (Richard Haskell) if he had one to send me a copy, but he sadly he didn't.

Any of you guys has this disc to share a copy and help me learning from this book also?

Thank you very much!
Neo

[Egan Ford]

On 12/6/12 8:30 AM, Neo Winston wrote:
> I'm so exited that I found an active group of people who are still programing for the 6502 on the Apple II.

I actually fall into the "programming for the 6502 *for* the Apple II."
I found programming *on* the Apple II to be a frustrating experience
(you can't teach an old vi-dog new tricks :-), so I switched to using
cross-assemblers. Although for learning and small codes I do like the
built-in mini-assembler and disassembler.

Anyway, I'm sure someone here can help you find that disk. If not, then
there are many other alternatives.

[Neo Winston]

Thanks for your reply! Indeed I'm reading many other books following the exercises using Merlin, Big Mac and LISA assemblers.

What cross - assembler do you use? I'd like to try that as well.

Thank you!

--------

[BLuRry]

Grep through the recent couple of months for stuff from "JaC" about "Wudsn" which allows you to use Eclipse IDE and any number of 6502 assemblers such as KickASs and (my personal fav) Acme Cross Assembler.

Other folks use CC65 or others. Here's a good list:

http://6502.org/tools/asm/

Wudsn: http://wudsn.com/

Note: There is a secret feature of Jace (ok, not secret, just not well-documented) that you can point a mass storage disk at a folder instead of a .hdv file and it will convert that directory to a read-only prodos volume! The file names have to be done specifically to indicate type and load offset (for example: myprog.bin#6000 will show up as a binary file with a load address of $6000

At any rate, if you use the virtual prodos volume you can do continuous integration testing on your program without rebooting or restarting the emulator!

-B

[Egan Ford]

On 12/6/12 1:49 PM, Neo Winston wrote:
> What cross - assembler do you use? I'd like to try that as well.

For 6502 I use ca65 (part of cc65). ca65 has powerful macro support and
can also be used for 65816/65802. Another cross assembler I like is asl
(Google for Macro Assembler AS). Although asl supports the 6502, I use
it mostly for other processors (e.g. 8008, 8080/8085, z80, 6800, 6809).

I haven't tried the IDE BLuRry just mentioned yet. But it looks
promising. I'm still suck in the '80s with vi foo.s;make;make test.

[Dagen Brock]

I'm somewhat a Merlin die-hard.

Are there any cross-compilers that can handle merlin source directly? (like the macros, local definitions like ":loop", and variables)

Otherwise, can someone recommend the best compiler for Apple-centric 65816 compilation? (.S16 support?)


@datajerk - There's nothing wrong with vi. I still build in Merlin so I don't need compiler support in my editor, but I could wire it into vi if I used something else. I much prefer vi to eclipse for most languages, and especially for non-verbose stuff like assembly. I do have some custom vi settings to help with my preferred tabbing and moving things back and forth from kegs <=> *nix. If you want to use vi, you might take a look at my 65816 syntax highlighting file (with merlin additions). It's not perfect, but I've released it here if you want to take a look:
https://github.com/digarok/asmMerlin65816.vim

[Neo Winston]

Thanks for all the hints, guys!

[Egan Ford]

On 12/6/12 3:56 PM, Dagen Brock wrote:
> I'm somewhat a Merlin die-hard.
>
> Are there any cross-compilers that can handle merlin source directly? (like the macros, local definitions like ":loop", and variables)

I can't think of any, however other cross-assemblers have similar
constructs.

> @datajerk - There's nothing wrong with vi. I still build in Merlin so I don't need compiler support in my editor, but I could wire it into vi if I used something else. I much prefer vi to eclipse for most languages, and especially for non-verbose stuff like assembly. I do have some custom vi settings to help with my preferred tabbing and moving things back and forth from kegs <=> *nix. If you want to use vi, you might take a look at my 65816 syntax highlighting file (with merlin additions). It's not perfect, but I've released it here if you want to take a look:
> https://github.com/digarok/asmMerlin65816.vim
>

Thanks! I'll see what I can do with it.

[Michael J. Mahon]

I, too, do everything in Merlin. Sometimes on my Zipped //e, sometimes
under emulation on my laptop. I keep my emulator hard drive synced with my
//e's CFFA.

I find the short time it takes to edit in changes and reassemble before
moving the file with CiderPress and testing to be a very productive delay.

I examine all anomalies in any test run, find their root causes, and fix
(or sometimes redesign) them, then return to editing, etc. I would
estimate that my average time for each
test-analyze-fix-assemble-move(-test) is about a half-hour if I'm "in the
zone" and perhaps much longer if I have other things to do or the problem
is thorny.

A good solution for a hard problem often takes a day or two of thought,
with lots of "that would fix it" bright ideas thrown in the wastebasket.
;-)

A problem with "hyper interactive" development environments is that they
make it so effortless to "cut and try" that they encourage quick fixes
instead of rewarding more thought per development cycle.

For craftsmanlike programming, the bottleneck isn't the development
environment, it's the human mind. ;-)

"Our wastebaskets are our most valuable design tools--and too seldom used."

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

[Dagen Brock]

That clinches it. If it's good enough for Mr. Mahon, then it's good enough for me!

In all seriousness, I agree wholeheartedly. When developing in my emulator, using my vi setup, it take me about 5 seconds to save on my host system, build disk image, boot the GS and build the new version under Merlin.

There's so much truth in the statement about the development environment not being the bottleneck. The more time I spend coding in my mind, and *executing* the code in my mind, the less time I waste going back and forth between writing and executing/testing my code. There's nothing quite like having an idea, programming it for an hour or two, and having it execute perfectly the first time. The more I rely on my mind than my IDE, the better I've gotten at that.

I find the Merlin editor to still be quite adequate. The main reason I've finally started using an external editor is that I find the constraint of 24 rows of text to be too great considering the vertical quality of assembly.

[Egan Ford]

On 12/7/12 7:04 AM, Dagen Brock wrote:
> The main reason I've finally started using an external editor is that I find the constraint of 24 rows of text to be too great considering the vertical quality of assembly.

That is one of my reasons as well. I got spoiled in the early '90s with
my first X Windows terminal--the days of coding at 80x24 were over (as
well as debugging with printouts).

I've been using vi since the late '80s and I still use it today (for
multiple languages), so I have stubbornly resisted using built-in
editors and IDEs. That is ultimately my beef with Merlin.

There are, IMHO, many benefits that outweigh the 5 seconds of savings by
coding and testing directly in Merlin. E.g. revision control systems
(e.g. SVN), UNIX-based CLI tools like diff, perl (used to generate ASM
code at times), faster assembly, etc... The UNIX environment has a very
rich set of development tools that I have grown very comfortable with.

To speed my testing I also created a small CLI Apple 1/II simulator with
very limited support for Apple 1/II calls (e.g. cout). This allows me
to quickly test my code logic, profile parts of the code, produce
histograms of the instruction frequency used, and produce easy to read
large memory dumps.

Example profile:

calls cycles time(s)
----- ------ -------
counter 01: 2 58698622 115.040750
counter 19: 4 2115 0.008292
counter 20: 1029 5608 5.655427
counter 21: 8 3919 0.030727
counter 22: 509 7797 3.889353
counter 23: 514 7760 3.908667
counter 24: 1612 36315 57.365493
counter 25: 675 55702 36.844430
counter 26: 4 27487358 107.742438
counter 27: 2 3703438 7.258199
counter 60: 329664 139 45.196389

For testing on the real thing my Makefiles simply create a bootable
floppy and calls "open floppy.dsk" to instantly load it up into Virtual
][--I'm testing in a second.

And yes, even with all this newfangled "hi-tech" I still spend most of
my time thinking about the problem at hand (and researching it), but
when it's time to put pen to paper I am 2-3x more efficient with vi. It
is a huge time saver for me.

[BLuRry]

I rapid-prototyped a double-hires scroller and optical illusion effect with a compile/test delay of about 5 seconds per run. The result was I was able to get my program working within a few hours of conceiving it -- and double-hires graphics are not a trivial undertaking. That combined with using an emulator for step-wise code debugging and it's a winning combination. There's no need to add the assembled program to a disk image -- Wudsn does that for you. Or, as I said, you can use the virtual prodos volume "hidden" feature of Jace to make code changes instantly available. Wudsn also provides syntax highlighting for 6502 code.

At some point I'll reach out to Jac with the Apple Game Server graphics conversion routines for anyone who wants to use Wudsn to convert pictures/sprites as well.

-B

[Dagen Brock]

So it sounds like a lot of us are using our own custom tools to do this stuff. Maybe we should pool our efforts and try to make this part of a cross-dev tool kit. I'm planning to release some of my stuff in a few weeks anyway on github, but it's pretty hacky because it's built for my own needs only.

Here are some tools I have that I'm planning to clean up and distribute if I get time:
-Graphics converters (for LoRes and DoubleLoRes) that convert gif/jpg/png to assembly code
-A utility (built on top of Apple Commander CLI) that extracts source files from *.po images and converts Merlin formatting to be used in vi
-A utility that does the opposite of the above, but I use my custom version of to_pro instead of Apple Commander and it supports filetype metadata, very much the same way as BLuRry does with Jace. (It can also write boot blocks which is another nice thing)
-Other odds and ends

Anyway, if anyone else wants to pool resources on something like that, let me know. Or if you have some helpful tools you've built, maybe we could share those and build on top of that.

Just a thought. Like I said, it sounds like a lot of us are already doing this ourselves. I know that's part of the fun (building your own tools), but I'm certain my tools are not necessarily the best under all circumstances.

[Egan Ford]

On 12/7/12 10:06 AM, Dagen Brock wrote:
> Maybe we should pool our efforts and try to make this part of a cross-dev tool kit.

Perhaps someone can setup dev.a2hq.com as a central place to document
and store such things. Assuming there isn't someplace else already.

[D Finnigan]

The new Brutal-Deluxe tools came to my mind when I was reading this thread.

[Dagen Brock]

... which are great, but largely Windows-centric.

[Michael J. Mahon]

You reminded me of something I didn't mention: I always work from a
marked-up listing. I print a new one every few cycles, depending on how
much has changed.

The annotated listing is the "screen" from which I work, and it's unbound,
so I can see multiple parts of the program simultaneously. Old listings go
into a history folder for archival purposes.

For DMS Drummer, I have about two and a half inches of old listings and
pages of handwritten code and notes. NadaNet is probably eight to ten
inches going back to the early 1990's!

Dijkstra once observed that a program listing is like the visible tip of an
iceberg--almost an order of magnitude more of supporting documentation is
required to properly explain its structure and limitations.

[Antoine Vignau]

Hello Neo,
Please find some useful 6502 tools at http://www.brutaldeluxe.fr/public/6502/

Enjoy,
antoine.6502.com

[Neo Winston]

Hi Antoine!

Thanks a bunch for the link. I'm on to it right now!

Another question for everybody...

Though I'm loving to learn the Apple II 6502 Assembly using Merlin straight on my real Apple IIe Platinum, I'm giving WUDSN a try with Eclipse, since I've developed some apps for the Android using it. The installation went well and tried setting up the ACME and the KickAss compilers for the Apple II.

Experimentally I've just copied and pasted the Forest Fire code from this link: http://hoop-la.ca/apple2/2012/forestfire/ , but without success.

I just created a Forrest.asm file and pasted the code from the above url, but right on the first line the compiler does not recognize the ORG pseudo-code giving me two errors and one warning, like so:

Description Resource Path Location Type

Program counter is unset. Forrest.asm /ForrestFire line 1 Problem
Syntax error. Forrest.asm /ForrestFire line 1 Problem
Implicit label definition not in leftmost column. Forrest.asm /ForrestFire line 1 Problem


What Am I doing wrong?

Thank you!

Neo

-----------------

[BLuRry]

There's a trick to it. You have to put a comment at the top of the file so Wudsn can determine what platform it is for. If the icon for your file is not an apple, it didn't detect it right. Paste this at the top:

; @com.wudsn.ide.asm.hardware=APPLE2

Then save your file and close it. When you open it back up it should have the proper icon. If the other Wudsn prefs are right then the compile/run option should fire off your emulator of choice.

-B

[Neo Winston]

Hi BLuRry,

Thanks for the hint that indeed solved the icon problem, putting a little green apple on the "Compile and Run" button.

But still no joy, and the icon shown on the Forrest.am is a Commodore symbol. I'm trying to use the ACME and the KickAss compilers and tried to change the Commodore symbol at the Editors Eclipse option, but I see no Apple II association.

Any ideas?

Neo

Ah... thanks again Antoine, for the link on the Visible Computer: 6502 !!!! It's a very nice book, and I'm right now on page 19!!! I think I'll buy an used copy from Amazon!!!!

----------

----------------

[Antoine Vignau]

You are welcome, Neo.
Sometimes, old books are funnier than modern ways of learning ;-)

Antoine (says the guy who keeps on programming on a real machine, more fun than on emulators)

[Neo Winston]

I agree! Programming on my real Apple IIe is great!