One line at a time, the same way you write any program.

My 6502 simulator is about 3000 lines of code. I certainly didn't set off to write 3000 lines of code, it just happens.

If you look a little deeper, my code has, roughly, 260 different routines.

At a higher level, being in Java, it's 25+ classes, each their own little container of logic and operability.

Now it's less daunting.

Any system of any complexity is best realized from the higher level down in to the lower levels. If you view the system as a tree of related components, then to understand any one thing, you don't necessarily have to understand all of the components, just the branch of related components you're interested in.

There is another approach, which is bottom up: you think about the problem, consider what facilities will be needed for a solution, construct the facilities, and then you have higher-level building blocks to work with.

Or perhaps, realistically, a bit of both.

In the case of PoP there are Mechner's development diaries:
http://www.jordanmechner.com/backstage/journals/

As others noted, by typing it in one line at a time.

The largest 6502 assembly language project I've done to date had nearly 100,000 lines of code, spread out over about 40 source files. It ran on Commodore 128Ds multiplexed to an 80 MB Lt. Kernal hard disk subsystem. Assembling the entire package took nearly two days. Revision 2.0.1 of my POC V1.1 computer's firmware (65C816 assembly language) has exactly 12,188 source lines. Its assembly takes about two seconds.

In general, the way to manage large programming projects of this sort is to develop libraries of frequently-used declarations and subroutines and INCLUDE them into your project as needed, thus avoiding the re-invention of the wheel. A large amount of re-usable code in one's library makes the creation of complex programs easier, especially when the re-usable code has previously been tested and debugged. In other words, some sweat equity early in your software development will pay dividends later on.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

This earlier topic might be of interest:

Poll - how much assembly programming do you do?

Curiosity BDD, in your source code, how much of the code was raw LDA #$01 code, and how much of it was Macros?

Simply, in the end, how "high level" was the final assembly?

Was it, in the end, 100K lines of source files, or did it generate 100K instructions of assembly?

It was about 100,000 lines of source code spread out over some 40 files. The application part of the software used some macros to do repetitive stuff, the exact number I no longer recall (we're talking 30 years ago). The low-level database engine stuff was entirely "raw" assembly language, and went through several rounds of optimization to shrink the size of the executable binary so more RAM was available for workspace.

I used the Commodore HCD65 assembler that was native to the C-128 to assemble the source. Editing was done in a homebrew text editor that was a mixture of compiled BASIC and assembly language. Since the development was done on a Lt. Kernal subsystem, I designed the editor specifically for that environment, taking advantage of a certain file type unique to the Lt. Kernal that would act like flat memory space. This allowed me to edit source files that would have been too big to fit in the C-128's memory space.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Back in the eighties when I did most of my assembly language programming it didn't feel as any kind of burden. Quite the opposite - it was something I looked forward to, after long stunts of HL programming. It was a very satisfying feeling in putting one statement after another, moving the one piece of data from here to there.
But I also think part of it was that I switched between high level language programming and assembly, so I didn't feel any burnout.

Last (honestly) question....

Can you suggest me any books (in .pdf format for free download) or web sites, that contains listings of simple games made in 6502 assembly language with explanation text for each listing?

P.S. 1 Almost a year ago I started my journey in 6502 assembly. My initial purpose as I've mentioned was to keep my brain in shape and since I liked computers and assembly seemed always (since my childhood) as something exotic, I chose 6502 as an easy introductory architecture. After a year of studying, assembly doesn't look exotic anymore. And while I can read for the rest of my life books about teaching assembly (thus keeping my brain in shape) sooner or later, that will become boring. (i.e. if I read one more time about binary arithmetic I think I will throw up.... ) So I have to move to the next level. Creating something on my own. But I'm in a point that I 've realised assembly is like any other programming language. You have to solve problems and keep in mind every single detail and most importantly organize everything. So here I am, wondering: is my mind capable of thinking as a real programmer who has that aptitude or I'm just wasting my time? I have serious doubts that my brain can think like that but.....anyway I decided to give it a try before once and for all give up 6502 assembly.

P.S. 2 Just wanted to share my thoughts with you. That's all.

There are games in The First Book of Kim
http://www.classiccmp.org/cini/pdf/Comm ... %20KIM.pdf
which can be found online at
https://github.com/jefftranter/6502/tre ... tBookOfKIM

And then there's 6502 Games by Rodnay Zaks found here (pdf link nearby)
https://archive.org/details/6502GamesRodnayZaks

As you said, assembly is just another programming language.

Each language has their quirks.

If you're interested in Computer Programming, and assembly language, while interesting, is slowing you down, they most certainly don't let it stop you. Just pick another language.

Start with a higher level language: BASIC, Python, etc.

Get some experience there, then move on to something like C.

Dabble there some more, write your own data structures.

Then you can come back to assembly language.

The beauty of modern high level languages is that you get things like data structures and algorithms for "free". Nobody write an array implementation in Python. Nobody writes a lookup table in Python, they just use one. Nobody write a sort in Python. So you get to write code the needs arrays, and lookup table, and sorts, "for free", without focusing on the details of those elements. Rather you get to focus on your application.

Move down to something like C, and, yea, there are implementations of these things available. The language directly supports fixed length arrays, for example. But lookup tables, maybe you'll need to find some code that you need to tweak to make work for you. Now is a good time to work on coding up some sorting algorithm. But at least you don't have to worry about what registers to use, etc.

Now, back to assembly, you get to dwell on all of the details, for good and bad. But the concepts are the same. You don't have to relearn what an array is, or why you would sort some data. You know why, you're just more intimately involved in the implementation.

Programming is about creating abstractions and tying them together. The various levels of languages offer more or less support to the creating and bundling of those abstractions.

So, anyway, don't let assembly language keep you from exploring computer programming. Go ahead and start at the top and work your way down. You won't "miss" anything, everything you learn in, say, Scheme (for example) is applicable to how you write assembly language.

I notice Chris from your introduction:


It just might be worth working through some Basic games programs. The act of typing in, and fixing typos, is part of learning. Then you can try tweaks. The games written in Basic are simple, so you're not trying to solve really difficult problems. And you get a reward from running the game. Any game written in Basic is not too complex to tackle in assembler, and you have the Basic source as a hint.

101 BASIC Computer Games is available online, and is a classic.
https://www.atariarchives.org/basicgames/

(If the Basic dialect is different, that's another learning experience.)

Well, on a second thought, it was a mistake to learn assembly as a first programming language. What I mean by that? One year is enough time for learning the fundamentals and the mnemonics of 6502 and how to use them. But....there is a catch in my case. I've never had any previous programming experience. Zero. Nada. That leads to my real problem: The difficult part is not how to implement flowcharts in lines of assembly code (I'm not implying that it is as easy as going for a walk in the park) but how to implement an idea (i.e. a simple snake game) into a flowchart. Famous programmers in the 70's and the 80's started their programming career in Basic. (and it sounds kinda rational....) They did that for many years (copying myriads of ready-made listings, tweaking even more and gaining experience) until they finally moved to 6502 (or Z80) assembly language. I dived into it, misguided by the "exotic" aura of assembly language and the naive statement to "train my brain") having in my knowledge backpack only the use of Windows and web browsers!

Once again, BigEd's answer was an enlightenment.

Thank you guys for all the answers!

Not counting minor Fortran IV contact in school in 1978, I started my programming with a TI programmable calculator in 1981. It turned out to be a lot like assembly and machine language in a way, and I show the similarities in a sidebar to my article "Assembly Language: Still Relevant Today (No, it won't ever be dead.)". Then I got started in 6502 assembly & machine language in a class in the spring of '82, using the AIM-65 computer (and it seemed rather natural), and concurrently took a class in Fortran IV. I never used the Fortran, but really took off with the assembly language. I had no real contact with BASIC until about 1987, and then only with the Hewlett-Packard HP-71 hand-held computer whose BASIC was light years beyond the BASICs in home computers, especially with its Math module and LEX (Language EXtension) files contributed by the Paris users' group.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Indeed, using a (simple) calculator to solve problems is good preparation, especially if it has few memories. Early programmables also had few steps, which also helps with the puzzle-solving aspect of low-level programming.

I briefly owned a Sinclair Cambridge Programmable which had all the inconvenience you might wish for, and then a little later a TI Programmable 57. Having said all that, I might have already come across Basic or Fortran or Cobol, I'm not sure: my school offered Computer Studies from the age of 14 or so. And I got a book on Fortran from the library at an early age.

Machine code—actual machine code, not a mnemonic representation—was the first "language" I learned. Everything after that was easier.

I learned 6502 assembly language in late 1976-early 1977 when my then-employer developed an event recorder for locomotives that was powered by a 6502. This recorder replaced an early design based on a Zilog Z80. The decision to abandon the Z80 design came down to cost: the 6502 was about one-fifth the price of the Z80, and had a simpler bus architecture, which also helped to reduce cost.

None of us knew the 6502 assembly language, so I volunteered (you know what they say about volunteers) to learn it and write enough code to see if the prototype would work. Programmers that were fluent in 6502 assembly language weren't exactly roaming the streets looking for work, so my willingness to take on the programming chores proved to be a wise move on my part. To get up to speed, I worked from some copies of typewritten application notes that someone had gotten from MOS Technology (I don't think MOS' programming manual was in print at the time—I didn't see it until some time in 1978, if I recall).

In those days, we cross-assembled on our IBM 370 mainframe, using an assembler that was written in Fortan. The source code had to be punched into the familiar deck of cards that the card reader liked to eat for lunch, especially when you were in a hurry to get things done. It was a major step up when an interactive editor became available, running on an actual terminal (green-screen). Now I could edit my source and run the assembler with a few keystrokes! The object code was transferred to the event recorder through an RS-232 port that ran at a screaming 300 bps.

I also learned a smattering of Fortran and COBOL in those days, but didn't do much of anything with it. Knowing some Fortran was useful in tweaking the 6502 assembler. I had experience with timesharing BASIC running on an MAI Basic IV system, but didn't do much with that until the mid-1980s. In other words, my route to programming "enlightenment" was to start at the bare metal and go up.

The problem with starting at a high level, e.g., BASIC or one of the other "hand-holding" interpreted languages is too much is automatic, making the mechanics of what is happening opaque. That's fine if your goal is to crank out a working program as quickly as possible without dealing with too many details. Trouble is, you aren't going to learn a whole lot about computers that way.

On the other hand, if you start near the bottom (symbolic assembly language, to be specific) and learn how to encode algorithms, data structures, and methods and procedures in a low-level environment, you will find doing such things in the higher level environment a piece of cake. By the time I learned K&R C (c.1980, when I had my first taste of the UNIX environment) I already had a decade of programming experience, virtually all of it machine and assembly language. It took me longer to learn the idiosyncrasies of the C compiler than it did to master the language itself.

So there is much to be said about starting with the basics (not BASIC!) and learning just what is going on when the cursor is blinking and the machine is awaiting your input. That's how I started and it caused me to develop programing styles and philosophies that are applicable to any language, be it C or abominations such as Java and Python.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!