Hi everyone,

I decided to learn assembly and 6502 seems like a good platform to learn on. Here's my first program; I'm following the guide on http://skilldrick.github.io/easy6502. My modification to the original program is the addition of the `nextline` routine and the two accompanying lines at the start. The `STA` calls inside `firstloop` and `secondloop` that paints the pixels were also modified to use indirect indexed adressing to know which line to paint to, in addition to which horizontal pixel (which is tracked in register Y).

You can compare it to the version at http://skilldrick.github.io/easy6502/#stack (first program in that section of the page) to see the difference.

What would you seasoned 6502 developers do to make it easier to understand and follow?

Hi KLset, and welcome!

I notice you're doing a lot of pushes in one loop and a lot of pulls in another. That's unusual, but so long as you're balanced I don't see a problem with it.

As a general 6502 idiom, you'll often find loops counting down to zero, as it means you don't need to compare with a terminal value - the zero flag is set for free by the decrement.

(Just to forewarn you: because there are several syntaxes for the various assemblers in 6502 land, you might get some commentary on that. Best to let it wash over you: for any given assembler, of course you need to follow the syntax it accepts. There is no best answer.)

About the loop counters; the Y register contains the address to the pixel on the current line, and so the first loop paints the first half of the line and at the same time pushes the color for each painted pixel onto the stack. The second loop paints the second line of the line, and this time uses the color values by pulling from the stack. The result is a mirrored effect. I added a screen capture of the output to this post. Would it still still applicable what you wrote about counting down to zero and using the zero flag?

Assemblers, yes! I don't know where to start, really. I've downloaded the emulator by Michal Kowalski (http:/exifpro.com/utils.html) and the syntax is wildly different from the one used on the online editor I've used so far. Any recommendations if I eventually want to build up libraries and run applications on hardware?

Ah yes, using a stack to reverse order some data is a good tactic!

There's often - perhaps almost always - several ways to tackle a problem. The main thing, apart from being correct, is to comment in such a way that it will make sense to you several months down the line. And then, there's not running out of space, or running out of cycles. Most code isn't speed-critical although it is fun to try to improve the speed or density of code. It's worth picking up the idioms used for a particular CPU. For the 6502, getting a feel for the different uses of A, X, and Y takes a bit of experience.

Assembler choice is very much a matter of taste. If you like a command line and develop on the desktop, ca65 from cc65 is popular. If you like something like an IDE, Kowalski's simulator is good. If you want to write something quickly in the browser, there are a number of in-browser assemblers and even IDEs - easy6502 is good for small experiments. If you come from the land of Acorn and the BBC Micro, or you just like the idea, you can use the assembler built into BBC Basic. I'm sure there are many other choices!

The reference section of 6502.org is worth a look around. Perhaps in this case particularly
http://6502.org/tools/
http://6502.org/source/
http://6502.org/tutorials/

Hi KLSet,

First off, welcome and congrats on your first program. This will mostly do exactly what you have wanted it to do. There are several things going on that no not need to happen to get the desired result, but I'm not sure of your overall intent here.

First off, the only "bug" I see is you did not initialize the low byte of the address. You should have:



Otherwise, the value in $00 will be random, or the last value written. Granted, your loop ends with $00 being stored at address $00, so re-running the routine will work as long as other code does not disturb it. But, what about when the computer powers on?

Now, the basic purpose of this routine seems to fill the memory from $0200 - $05FF with value in the x register (counting up for the first 16, down for the next 16) and repeating.

There are two basic methods to consider in writing assembly:
1) optimize for speed, sacrificing memory usage
2) optimize for minimal memory usage, sacrificing speed

Using the stack can reduce memory usage, but it is a costly method in terms of speed. If you would like to explore speed or memory improvements, there are dozens of coders in this group that love a challenge. I have often learned new techniques by reading all of the different ways programmers use to arrive at the same result. You just have to ask.

I hope you find the 6502's instruction set as fun to work with as I do.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

What a great tip on ca65, it seems to be just what I am looking for. I do Python by day in a Linux environment, usually through SSH, so command line is just fine.

There's a thread here which might help:
viewtopic.php?f=2&t=2455

cc65 is quite a big idea, and so ca65 isn't quite the simple assembler one might expect: you assemble and then you link.

Aha, so the stack is slow(er). I should get some data sheets on the 6502. Now that I know that, I'll try and write another version that does not make use of the stack. (As a sidenote, I think using the stack was mostly used as an example by Nick Morgan who wrote the Easy 6502 tutorial.)

The tip on zeroing the memory was useful. The emulator on Easy 6052 zeroes the memory by default, so I didn't really think twice about it.

Welcome!

Let me take the opportunity to recommend David Eyes' and Ron Lichty's excellent programming manual at http://wdc65xx.com/Programming-Manual/, the best 65xx programming manual available, and a must-have for every 65xx programmer. It starts with the basics, followed by architecture, the CMOS 65c02's many improvements over the original NMOS 6502 including added instructions and addressing modes and fixing the NMOS's bugs and quirks, and then the natural progression to the 65816; a thorough tutorial, writing applications, then very detailed and diagrammed information on all 34 addressing modes, at least a page of very detailed description for each instruction, with info on every addressing mode available for that instruction, then instruction lists, tables, and groups, of all 255 active op codes, plus more. 469 pages.

_________________
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?

Kowalski's simulator (not emulator) is really an integrated development package, consisting of editor, assembler and simulator, the latter which has an optional I/O window that acts like a generic terminal. The object code generated by the assembler can be written into a raw binary file or into a loader file in Motorola S-record or Intel hex format.

The Kowalski assembler conforms to the MOS Technology 6502 assembly language syntax standard with some minor exceptions—it sounds as though the on-line tool you were using is decidedly non-standard. Kowalski's binary radix is non-standard, being @ instead of the MOS Technology standard %. Accumulator addressing does not use the A symbol per the MOS Technology standard; for example, you would write ROL instead of ROL A to left-rotate the accumulator.

The assembler has a powerful macro language that I have extensively used to make it possible to assemble 16 bit 65C816 code, with macros and conditional assembly handling the 65C816-unique instructions. I also use the macro functions to generate stack frames for subroutine calls, which could potentially be a tedious and error-prone task in raw assembly language. Macros can also be used to give the feel of a higher level language without sacrificing the succinctness and speed of assembly language. Garth Wilson describes how to do it on his website.

Where Kowalski's simulator really has an advantage is the built-in simulation of a 6502 environment, making it easy to edit your source code, assemble it and after you fix the errors, run it and see what happens, all in one program. Note that the simulator models the NMOS 6502 or the Rockwell 65C02, not the WDC 65C02 that is in current production. The differences between the WDC and Rockwell versions can be effaced with simple macros.

I developed the firmware for my POC computers, which are 65C816 powered, in the Kowalski simulator. POC V1.1's firmware has over 12,000 lines of source code, which assembles on my PC in about two seconds. Incidentally, the most up-to-date version of the Kowalski simulator is right here, and is newer than what you downloaded.

Assembler directives are summarized in the attached file. Documentation on the simulator is thin, most of it having been written in Polish. If you decide continue using the simulator ask for help if needed.

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

BigDumbDinosaur, thanks for the info on the Kowalski SIMulator. I looked up the difference between a simulator and an emulator. From what I understand, operating on the stack as is done in the program I posted should be slower in the simulator compared to other methods, as hinted by 8BIT (perhaps using zero page memory instead?). In an emulator, such a detail would be less likely to be implemented. Am I on the right track here?

Good tip! It would be a lot nicer to have a comprehensive book on the 6502 family rather than a collection of PDF files.

_________________
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?

As long as I know what the simulator/emulator I'm using does, the terminology matters less for me.



Meaning Kowalski's simulator (as he calls it) is not cycle-accurate?

Speaking of cycle-accuracy: In one of the YouTube videos by the guy behind http://www.apple2.gs in which he teaches 6502 assembly, he writes a program for the Apple IIGS that is very hardware specific. He mentions in a later video that a few of his viewers wrote back saying that when they ran the same program but in a semulator, they didn't see the same output on the screen. He then explained how these semulators don't replicate the whole thing. I'm guessing that has to do with cycle-accuracy, like timing instructions right to get a certain effect on the screen.

Best not to get sucked into terminology disputes: my view is that different people speak different dialects, and with a minimum of effort we can all understand each other. Some software models (call them what you will) are cycle-accurate, or offer cycle-counting, and others are not (and don't) - so you can either have a go on one which does offer cycle counting information, or have a look at a suitably annotated table of instructions. There's a lot of regularity in 6502, so there's not nearly so much to digest as it might appear.
See for example
http://www.obelisk.me.uk/6502/reference.html
http://www.6502.org/tutorials/6502opcodes.html
http://www.masswerk.at/6502/6502_instruction_set.html

The actual cycle-by-cycle behaviour of a 6502 computer can become really involved: the Apple II's CPU clock is not quite regular, for video reasons, and the Acorn BBC Micro clock runs at 2MHz except for those accesses where it slows down to 1MHz to access slower peripherals. The C64's video circuits stall the CPU in certain situations, IIRC.