Category Archives: Programming

Software Factory Dealer Demo

This is a 13-sector DOS 3.2 format disk image for The Software Factory Dealer Demo diskette, containing brief program demonstrations for Beneath Apple Manor, AstroApple (48K version), and Babble. The main menu is dated August 25, 1979.

Get the disk here.

I’m fairly certain some file corruption happened in the FC5025 transfer, even though my notes don’t indicate that any errors were encountered:



Source code for Don Worth’s Zap, FixCat and Linker

This archive contains disk images of Don Worth’s Zap, Fixcat and Linker.  Zap is a sector editor loaded with great features. FixCat is a tool designed to repair damaged disk CATALOGs. Both programs are part of “Bag of Tricks”. I included the Linker image with this archive because, as Don explains:

Zap and FixCat source files were set up to run through my Linker program. So there were a lot of little source files that hooked together on both sides of the source diskette.

Don also gives us a little background on Linker:

I was a systems programmer at UCLA and was used to doing development with an assembler and a linkage editor. We had source code in small pieces – each “module” was an independent subroutine with its source stored in a separate text file. When we wanted to change something, all we had to do was edit one little file and reassemble it, the run it through the linkage editor which would combine it with all the other previously assembled modules to create the final product. This is similar in concept to a “build” in more modern terms. Some of my programs on the Apple were pretty large, and I didn’t want to be always having to reassemble the whole thing just to make tiny changes. And, I wanted to be able to reuse subroutines (such as disk and file access) in more than one program. That’s why I wrote Linker.

You would set up a jump table in your code for all the subroutines you wanted linked to your program, and put a special binary code there so Linker could find it in your assembled binary file. Then you would store all the binary files on a diskette with their file names matching the names of the subroutines. You ran Linker and put in the top-most calling program (your main program) and Linker would find the jump table and start looking on the disk for the subroutine binaries. As it found them it assembled a bigger jump table, combining all their calls as well, and resolving the addresses in the resulting conglomerate of modules recursively. If you needed to, you could switch diskettes (or flip one over) to access more binary subroutine files until you had all of them included. It was an automated process. When you were done, you could bsave the memory locations where the resulting “build” had been created for a runnable binary.

I was always more proud of Linker than Zap or any of my other programs.

Here’s the .zip archive.

Try and try and…

Wherein, I outline my intention to present completely biased and unfair reviews of a few books designed to teach readers how to program in 6502 machine language, and perhaps learn a thing or two along the way.

I’ve complained at length in the past (don’t go looking for the posts here – I never bothered to restore any blog entries after that extended period of downtime) about the tendency of most 6502 assembly tutorial authors to simply throw the reader face-first at the brick wall of learning binary maths, usually within the first five to ten pages.

These “introductions” usually kick off with dire warnings in bold font of failure, destruction, and the promise of the fiery overturning of buses full of nuns and kittens, if the lessons are skipped without fully understanding them.  Following these proclamations of imminent doom, the reader is presented a paragraph or two of brief explanation and a couple of exercises one can use to show off their new-found prowess to friends.

But what if you didn’t understand something?  What if the answers you come up with to the exercises don’t match what’s in the book?  You could try to read the lesson again, but without a corrective guide, you’re probably going to end up at the same conclusions.

You could plunge ahead, but… Well, you *do* remember those warnings, don’t you?

And so over the years, I’ve accumulated a pile of books, all of which have fifteen to twenty pages of well-worn material, and are retail-shelf new that point.  As I look through them again, one thing is clear above all else: the information is presented in a nearly-identical and uniform manner: learn this binary math stuff before you proceed.  There’s a reason for this, and it’s a simple one: it works.  Or it works well enough to get budding assembly language programmers on their way to greater coding fame.  Countless Apple II programmers have followed these well-trodden paths before me and have emerged at the other end, wiser, smarter and with optimized code flowing forth from them like a river.

The inevitable conclusion is the problem must be with me.  This is a challenge I’ve been unable to overcome.  I haven’t been able to make the connection between the lesson and the problems.  The data seems to make perfect sense as I read through it, but my answers to the exercises are invariably wrong and I can’t tell you how I got there, or where the error was made.  Whether it’s that I’m not processing the lessons logically, or that this is a thing I’m simply not smart enough to learn, one of the flyrods is going out of skew on the treadle between the page and how my brain processes what I’m seeing.

One solution then is to try again, this time taking care to analyze the lessons and try to divine how I absorb what I think is being taught, and see if a single point of failure emerges.

These are the books I’ve got on my shelf and I’ll be trying each one, documenting as I go.  And who knows?  Maybe I’ll get lucky and it will just click on one day like a light-switch…  Nah, nothing is ever that easy.

  • Apple Machine Language for Beginners, Mansfield
  • Assembly Lines: The Book, Wagner
  • Programming the 6502, Zacks
  • Apple Machine Language, Inman & Inman
  • How to Program the Apple II Using 6502 Assembly Language, Hyde
  • 6502 Assembly Language Programming, Fernandez, Tabler & Ashley
  • The Visible Computer: 6502

And a few other online resources and guides, such as Nick Morgan’s Easy6502 guide. I’m going to have a go at Wagner’s book tonight, since someone recommended it in the comments of the my previous post about this topic.  I expect I’ll have more to say tomorrow.

No awesome Retrochallenge 2014WW prizes for me

Sadly, another year has slipped by and I wasn’t able to get to my intended 2014WW project.  This is partly because January is always a crazily busy month for me – work picks up, and an entire weekend and most of the preceding week is lost to an anniversary getaway with my wife – and partly because I wasn’t able to locate the Apple /// BOS disk that I’d pre-configured to work with my CFFA card and I didn’t adequately organize my time to devote the necessary 90 uninterrupted minutes (give or take) to start over.  So there it is… My dreams of Retrochallenge glory lie in ruins.  We’ll get ’em next year.

One last dance with 6502 assembly language

Way back when (2012 or something?) I posted my intention to learn 6502 assembly language, and explained that my roadblock to this point has been an inability to get my head around binary math-by-hand.  Life, site hacks and other stuff got in the way, but I’m back to this again.  I still do think it’s possible to do without being able to multiply 1101011101011101 by 101010111110110111 without the aid of a calculator.  Someone pointed out to me that it helps to have a goal, in this case an “end-product” program that I want to write, so I’ve come up with an idea that I want to make real, or as “real” as any program code can be, I suppose.

Some people want to run a marathon before they die, or climb Everest.  I want to learn 6502 assembly language.