Look at my code snippet above, PROMPTL and PROMPTH are consecutive page 0 memory locations that make up the 16-bit pointer. I would strongly urge you to start reading a programming manual for the 65(c)02 and get better acquainted with opcodes and addressing modes. That and reading through some existing code listings would aid your understanding of how to structure some of this stuff.

_________________
Regards, KM
https://github.com/floobydust

The '02 only handles 8 bits at once, so yes, you'll need two operations, and you'll need an address variable, whether it's in ZP or not.

The 65816 can handle both bytes at once, and then also has more cool addressing modes to do stuff with it. You could even use a single instruction to push the address of the string onto the stack, and use the added stack addressing modes to more-efficiently handle it in the subroutine. Another possibility would be to have X (in 16-bit mode) point to the address itself and do an indirect X where X holds the address, by doing LDA 0000,X, (making sure you assemble an absolute, not ZP, instruction). Each INX gets you to the next byte of the string. You'll want the index registers in 16-bit mode and the accumulator in 8-bit. See what you have to look forward to?

The Liechty & Eyes programming manual (note the new link) is outstanding for explaining all this stuff really well.

_________________
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 Garth noted, the Liechty and Eyes manual is excellent. I still have my original hardcopy and a PDF version. I still reference it for instructions and addressing modes to this day. I guess I hinted to it without a link. Here's the current link from WDC:
http://wdc65xx.com/Programming-Manual/

You're can also download a copy of my CO2Monitor 1.0 source code. It's heavily commented so the code should be fairly easy to follow. viewtopic.php?f=2&t=3523#p41861

_________________
Regards, KM
https://github.com/floobydust

I am absolutely reading books, including the Liechty and Eyes book mentioned. In fact I have a hardcopy of that one coming Monday day. It may seem like I'm not reading stuff, but I assure you I am. Things that may look obvious to you guys in these books aren't so much to folks who haven't been living this stuff for decades.

I don't come here first for the answers, but if I don't get what I need after a pass through the relevant sections of my books, I come here rather the belabor the issue. I think it's a fine strategy.

But don't don't worry, I'm reading. Honestly, I have yet to find a text who's authors are really gifted at exclaiming things. Most seen to spend pages over explaining the obvious, then spend one cryptic paragraph explaining the complicated. Stuff like spending pages on what an instruction is, but a terse paragraph on pre-indexed addressing.

Garth's stuff is ten times more readable than allot of these books. The info is in them, just often poorly exposed. Admittedly I've spent less time with Liechty and Eyes, but that will change when my hardcopy comes.

All this to say, have patience I promise I'm studying this stuff!

Ok, I noticed a detail in Garth's example that I missed on my first reading.

I had never seen that you could use the "<" and ">" operators to access the LOW and HIGH bytes of and address separately. I tried it out in the Kowalski sim, and it works great!

My difficulty was never understanding indexed addressing. It was being unsure that I knew the most efficient way to do what I wanted. Those operators change everything.

A question about them. What is happening behind the scenes here? What does the assembler do when it sees this? Is it just a short hand for doing 8 bit shifts in a row, and the assembler puts the full deal in?

Nevermind, its actually obvious when I look at the disassembly! I kinda forgot that the assembler would know at assemble time exactly what address I need to separate into its halves. Its just decoding my label. Dumb and obvious now that I actually think about it.

What did throw me for a loop at first was a whole bunch of strange instructions in my disassembly. Then it dawned on me that the disassembler wouldn't know data from instructions, so all my constants were displayed as instructions. I imagine a disassembler that also shows an ascii interpretation of the data would make it more obvious to the user what code was actually just strings.

A problem with this kind of test: suppose A0 to the RAM is disconnected, so writes to address 0 and 1 both go to the same place. If you test one byte at a time, you'll never notice.

A simple test I like is to use a pseudo random generator, fill the entire memory with random data, reset the seed, and read the entire ram back. Repeat with different seed until satisfied.

The search tools are your friend. I posted the full set of Kowalski pseudo-ops several years ago.

The alternative to .DS is *=*+<size>, where <size> is the number of locations to reserve. There is also .RMB, but should not be used unless you want to reserve storage and initialize it to some assembly-time value.

The program counter is typically set with *=<address>.

Also see here for the operators recognized by the Kowalski assembler.

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

The RAM test Dan wants is a RAM test, not a PCB test.

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

In 16 bit mode on a machine with no more than 64KB of RAM, LDA 0,X will work fine. Where absolute mode becomes necessary is if the current data bank is non-zero.

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

Problems on the board are much more likely than problems in the chip...

ok, still a little hung up on the .DS directive and its various brethren.

Does a directive like that have any use if your program is going in ROM?

I guess what still confuses me is, with my code in ROM, why would I even have to set aside any block of memory in RAM, if nothing goes anywhere in RAM that I don't specifically designate. So if I want $0200 to $02FF to be4 a buffer for instance, I could just not ever use it for anything else.

But If the program resides in RAM, i can see why it would be needed, because the code and data share address space, so the assembler would need to know where it couldn't put code.

Is that about it?

Also, I had read BDD's exposition of the Kowalski directives and operators. I didn't se mention of the use of the "<" and ">" operators being used that way. I did see the bit wise shift operators "<<" and "<<". The help is a dead link in the program too, which my searching seems reveal is due to an English version not existing. Is there a way to find the original language version, such that one could see if Google translate could make heads or tails of it? I'm really loving this software, and would like to know its details best as I can.

If everything lined up on neat boundaries and were never to change, you could assign by hand the addresses of variables and arrays. But if you commit to that, you'll probably find yourself needing to change something later on down the road, and then it will have been easier if you had let the assembler take care of the assignment of addresses of RAM-resident stuff. In the case of the RS-232 buffer, a page works out very conveniently. Most variables' sizes won't work out so conveniently; and if you try to manage the inventory of variables by hand, it will be harder to make changes later without resulting in unused spaces or the risk of one variable accidentally stepping on another one. My recommendation is to let the assembler do what it's good at.

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

Dan,

I think you haven't fully realized, that there is no operating system unless you wrote some. There is no second or third usage of an area of RAM you designate to one program - not because you did use it, but because there is no other program running!

It requires an operation system, a scheduler, a memory manager and more to get into the trouble you envisioned.

Take a C64 or an Apple: there is a ROM containing the reset vector and initial setup code. Then there is a small monitor, allowing to verify/change single memory contents. You can use the monitor to start manually say BASIC. Then BASIC is running - the monitor still resides in ROM but it is not used anymore (perhaps parts of it like character I/O, but then these are subroutines called by BASIC). Usually in these small machines there is just one program operating, having full control, no need to care about other programs.

To have a second program lurking in the background, say a printer spooler (back in that days a common background task) requires careful planning and special ways to set it up correctly. Usually the spooler was started, taking some of the memory (high end) for buffering, and sets a new "memory end" value in a location, that is referenced by BASIC during startup. This was the only protection from double use of that RAM. The spooler then initiates a timer that periodically interrupts any other program. The spooler checks the buffer do perhaps some printing and then reschedules (return from interrupt) to whatever program was actually running.

What I wish to describe is, that all and evrything that is going on on your machine, is under your control - or at least it should.
For every possible situation you have to prepare your system with adeqaute software. It is (usually) no good idea, to terminate one program, leaving valuable data in RAM, and believe that this data is "later" intact - unless you write an operating system AND cooperative software. Obviously that isn't trivial.

So far OK ?

True that. However, that would be a construction issue, which would presumably be corrected early on in the project.

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