When it comes to allocating memory, most of the time, the developer doesn't really care where the memory is, just as long as it's "somewhere".

So, the "* = * + N" technique of grabbing memory leaves the minutiae of managing the actual addresses to the assembler, rather than the developer.

This is clearly most common for simple variables (1 byte, 2 bytes) rather than larger spaces, but the concept is sound. You want to have larger areas for things like terminal buffers, or disk buffers, etc.

Now, instead of statically allocating these areas within the assembly program directly, you can "dynamically" allocate them at runtime. Here, you need to simply know where your "free memory" begins. And from there, you program can gobble blocks as necessary.

Early UCSD Pascal has the simple concept of "mark" and "release". Here, it maintained a pointed to the start of the free area. When you wanted more memory, you grabbed a copy, and then bumped it up. When you were done, you simply reset the pointer back.

So:

This is distinct from more common memory managers, that work with individual blocks, and manage free space, and block chains, etc. (like C's malloc). It's obviously vastly more simpler. But it can still be effective for many use cases.

But in all of these cases, after the code is built, and at runtime, is when these addresses are decided. They're not "assigned" by the developer (i.e. I/O buffer is going to be page $0200). Rather, they're just organically scattered through the code and free memory space and referenced symbolically.

Sometime you do care exactly where a block of memory should be, but many times, you don't. You just need to know you have 64 bytes open someplace safe.

ca65 (part of the cc65 compiler) allows you to define segments, and then the linker uses a configuration file to place the segments into actual memory.

Interesting - THX

Just one of my curmudgeonly opinion, but I think you are muddying the waters here.

Why consume processing time in the firmware dynamically setting up fixed buffers that will be used in the exact same way every time? Doing such a thing makes no sense in the context of an eight bit system that has no memory management hardware and no expansion capabilities that could potentially alter the memory map in an arbitrary way.

Also, dynamically allocated buffer space means pointers to the buffers have to be set up, consuming valuable zero page space in the process. The firmware has to include functions to allocate the required RAM, and keep track of structures that are mostly immutable during run-time. Reading and writing a buffer would require indirection, since the buffer address wouldn't be known at assembly time. All this mish-mash would succeed in doing is consume precious ROM space and clock cycles to accomplish nothing that can't be readily accomplished with some assembly-time statements and absolute addressing.

As long as the firmware has control of the machine, there is no reason to allocate buffers and such on the fly. The ROM and the memory map are not going to change each time the power is turned on or the reset button is pressed, right?

Dan is a neophyte when it comes to 6502 assembly language programming and using an assembler. Until his level of understanding moves him out of the newbie realm there is no need to complicate matters in this fashion.

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

Dynamic memory has its uses, but not in a simple beginner's project.

If you're writing your own higher level language, such as Forth or BASIC, you'll need some form of dynamic memory to store the program, text strings, array variables, and such.

Progress report:

I have rudimentary I/O with the serial terminal going. Basically, I have a working command prompt, and it responds to single key presses by sending a short message to tell you what you pressed. Nothing earth shattering, but it proves I have 2 way serial communication, and that I can service interrupts.

Programming-wise, it also required indirect addressing, which was a big thing I wanted to nail down. In C/C++, I always felt a good command of pointers was a milestone in the educational journey, and indirect addressing is basically pointers.

As in C, understanding indirect addressing is not hard, but keeping the syntax straight is. In C, you have to remember when to use *, &, or nothing (or combos ). It seems in 6502 assembly, you have the same deal with pre and post indexed, and the like. I understand it all, but its gonna be awhile before I don't have to look at the book every time to make sure I'm using the right syntax. Basically keeping straight which parentheses to use, and which index register.

One question. Am I correct in understanding there is no way to do the C equivalent of a pointer to a pointer? My reading seems to suggest that only one layer of indirection is possible. I have no real need for such a thing, I'm just curious. I'm sure just about anything can be accomplished with cleverness anyway.

You can define a pointer to a pointer if you want, but you can't dereference it in a single instruction. First you have to dereference the first pointer, store the result in zeropage, and then dereference the second pointer.

.. which is what a C compiler generates code to do, on architectures which don't have indirect-indirect addressing (and many don't. Maybe very few - not even the very CISC-y mini I worked with, with its 28 addressing modes, had it).

The STM8 has a couple of Pointer Indirect addressing modes, but the pointer-to-pointer must be a constant, encoded in the instruction.

Edit: STM8 also has LDW X, (X)

Just code golfing, but if both pointers are in known to reside in zeropage, then you could store the intermediate 8-bit zeropage pointer in .X:

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Eventually indirection will become second nature to you. You use preindexing to select one pointer out of a contiguous set of pointers. The access is from/to the address stored in the selected pointer. You use postindexing to modify the address stored in the selected pointer. Hence there are two fundamentally different types of indirection. The 65C816 adds stack indirection, e.g., LDA ($04,S),Y, as well as indirect long postindexed, e.g., LDA [$80],Y, where the pointer at $80 is three bytes in length, not two.


Such an instruction would be nice, e.g., LDA ($80,X),Y. However, we can't have it too easy, otherwise there would be no challenge to writing an assembly language routine.

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

To do it on the '816 the way Forth does with the data stack in direct page and using X as the data-stack pointer, you'd do this, starting with the first pointer on the data stack (A in 16-bit mode):

It's like a treasure hunt we used to do as kids. Each "find" had the clue to the next place to look, and the team reaching the last "indirect" took the prize that was there (although the teams had different paths to the prize).

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

Just got my 4D systems uVGA III in the mail. Looks like a pretty capable little critter. I probably will initially se it as a glorified HD44780 type interface. Basically, a display adapter with built in text facilities. But it looks like when I want to do graphics, it can do a lot. The only downside is any "period purity" my project had will be out the window.

I plan to use it through a serial connection, unless someone can convince me otherwise. Seems simplest.

The documentation seems to be a bit of a treasure hunt. Lots of separate .pdfs. Finally tracked down the serial command datasheet, so that should serve my immediate needs.

Not sure how much of it's graphics capabilities are exploitable by my setup. The thing seems to be targeted at the Arduino/Pi crowd. I feel that my setup is more capable than an Arduino, but much less than a Pi, so who knows. Graphics are a pretty distant goal, so I'm not worried. I just wanted a way to interface a VGA monitor for basic text, so I can ween my setup off the PC terminal. Anything else it can do is just a bonus.

Along the same lines, I got a PS/2 keyboard and a little PS/2 jack. A cursory look at the protocol looks like it's fairly simple. Kinda similar to I2C to my eyes.

All of this is on the back burner for a bit anyway. I'm focusing on getting my monitor program going before I mess with the new hardware.

Anyone have any personal experience withe the uVGA III? I discovered it on Garth's primer.

I had one several years ago, planning on hooking it up to POC V1. I ended up giving it away. I will be building Geoff Graham's VT-100 terminal and interfacing it to POC V2 if my vision gets back to a point where I can work with small parts again.

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

Once I get the uVGA going for text, I'm gonna totally try and recreate the amber color and font of my old monochrome CRT from when I was a kid. Obviously