6502.org

I thought I'd share one of my favorites for command line processing: full screen editing.

If the system has video display capability, the screen memory itself can be used as the command line buffer. This give full screen edit for commands.
1) Until a carriage return is hit, just echo keyboard characters to the screen. Allow cursor up, cursor down, whatever.
2) On carriage return, identify the screen line based on the current cursor row.
3) Parse the line determined in 2 above directly from the screen memory

Drawback is that parameters may need to be copied to another buffer to zero terminate them. But for an M/L monitor this often isn't necessary.

I like that idea. At the moment, I'm still using a terminal window on my laptop for I/O, but I have plans for VGA video. Your idea seems efficient and elegant.

Cooler maybe, but when you throw your new program on the machine, it doesn't work and you get into a marathon debugging session you'll value short commands and the reduced amount of typing they require. Been there many times and done that many times. It's why Supermon 816 uses single letter commands. It's also why the most frequently used UNIX commands are two- and three-character ones instead of words.

I'm having a difficulty I'm hoping someone can help with.

I'm trying to display individually the arguments in a command line string I've stored in a location labeled ACIA_RXBUF. I have a list if indices into the command line string stored in a block of memory called ARG_INDEX. So basically, i want to display substrings within a string.

I tried this:
As is probably obvious to the seasoned 6502 programmer, I got an invalid addressing error from the compiler.

I can sort of see why my version failed. What I'm having trouble conjuring is a simple way to accomplish what I hope is obvious that I'm attempting.

I think the address you want is ACIA_RXBUF + Y, where ACIA_RXBUF is a two-byte value. So, I think you need to put that two-byte value into zero page, then add Y to it. But you don't need to add Y if there's an appropriate addressing mode, like
LDA (STRING_PTR),Y
so therefore you just need to prepare by storing the two constant bytes of ACIA_RXBUF:
LDA #<ACIA_RXBUF
STA STRING_PTR
LDA #>ACIA_RXBUF
STA STRING_PTR+1

Yeah, that makes sense.
Thanks!

Yep! That's basically it.

Hmm, actually it's might be even less work than this, as it seems ACIA_RXBUF is known at assembly time:
LDA (STRING_PTR),Y
TAY
LDA ACIA_RXBUF,Y
That is, absolute indexed may be the addressing mode you need.

Things to note:
- which values are known at assembly time and which are only known at run time
- there aren't enough registers to regard any of them as permanently having some meaning - sometimes you have to move values around into a register which is more convenient, and sometimes save values in memory or on the stack while you use a register for something else.

Ok, bit of weirdness.

So I was working on my code for separating arguments out of an input string. Had it working well. I could put an index into the the string where each argument started, and I switched the spaces into NULLS to separate them. I then would display each argument individually as a sanity test that all had worked.

At this point I was successful.

Ok, I next wanted a routine that took n ASCII representation of a 16 bit HEX address, and converted it into the actual numeric value it represented. I did this in a separate .asm file so I could test it using the Kowalski sim on its own.

At this point I was successful. It converts beautifully, and just for the hell of it, I even designed it so you could enter A-F in either uppercase or lower and have it work either way. Worked great.

Ok, I next simply cut and pasted my new hex converter routine into the code for my monitor (that had been working great) I strippede a couple things out that were specifically for the benefit of the sim, but that's it. A couple zero page variables that the converter uses were added too.

Ok, at this point no code calls the converter. Its just there. I decide to test things to makes sure I haven't screwed something up. All works perfectly except for one wierd detail. My argument display routine behaved strangely. It would display a partially correct argument list, but always at the same byte in the string, it would turn to garbage.

I tried many things, but finally I cut the HEX converter code THAT NEVER GETS CALLED out.

That solved it!

Ok, I next put it back, but at a different spot (near the end).

It still works!

What the heck!?!?!? Why would the position of an uncalled block of code effect operation? My only guess is that somehow I screwed with the some address that a local branch uses. I kinda have a blurry memory of reading that starnge things happen if a B** instruction tries to cross a memory page, but I could be imagining that.

Anyone know what happened here? I like that it works, I hate that I don't know why it broke.

Bcc should cross a page boundary fine (just takes 1 more cycle).

When your routine fails, does one of your string buffers straddle a page boundary? Does the garbage start there?

There's no bug with branches crossing a page boundary; but if you were trying to branch around your uncalled code and it was too far for a relative short branch, that would land you in the wrong spot. (Most assemblers will give you an error message though.)

Please post the source file and I'll load it into the Kowalski simulator and se what I can see (in a manner of speaking).

Bah, I've long since gotten it working. And I've added enough code since that its probably not worth it to send it to you. I'm just gonna figure I must have missed something that didn't survive the cut and paste operation.

All's well that ends well I guess.

I now have the ability to use a command line to inspect memory locations, albeit a single byte at a time. Currently working on letting the user set a range of locations or a larger dump. Right now its just a hex, and an ascii representation of the memory location that I display.

After that, I will code my routine to write to memory from the command line.

After that, I plan to make it so a user can run code they put in memory from the command line. Some sort of break interrupt system for getting back into a known state will be needed I'm sure.

Finally, after those software milestones are met, I plan to ween myself off the terminal connection to my laptop. I have a uVGA-III that I plan to use for video, and I also plan to use a PS/2 keyboard interface.

Things are coming along! I'm much faster at hardware than coding, so things have slowed down. Once I get to it, I'm fine, but for some reason convincing myself to sit down and do it takes some will. Strange because its always more pleasant an experience than I think it will be. I'm definitely not regretting my decision to roll my own monitor. It has been much easier than I first thought, and has forced me to learn 6502 assembly in ways I might not have otherwise.

As a side note, the more I use it, the more I love the Kowalski assembler/sim. Best tool I've found in awhile.

Also, I have been very pleasantly surprised at how not scary assembly language turned out to be. Its kinda weird. High level languages are meant to have us thinking more about the algorithm than the machine, but I'm finding that since 6502 assembly has so few opcodes, I pretty much forget about the language and think only about the algorithm. I'm really curious what it will be like when I do my next C or C++ project. I feel the way I think of code has changed.

Have you read the documentation on the µVGA? You may change your mind about using it as a console device upon discovering that it doesn't have a cursor, and the interface is not as simple as writing a character to the screen as you have now. I had one several years ago for the purpose of weening POC V1.1 away from use of a dumb terminal. I ended up giving it away when I realized that text display is not its strong suit.
So few opcodes? How many do you want? You get 255 of them with the 65C816.
I started out in computers some 47 years ago by working at the bare metal. It was only later that I learned any high level languages, which were Cobol (ugh!), C and Business BASIC. I already had a certain mindset when it came to writing software and I found it much easier to write efficient programs in those languages by using assembly language thinking.

Going in the other direction, I would think, would be hard for most who are not accustomed to thinking in terms of what is going on inside the hardware. In theory, you don't need to give the hardware any thought in Cobol and BASIC, and only a modicum of thought in C if you are writing a device driver or an operating system.

All I really want from the uVGA is a bridge to the monitor. Any other features are just gravy. I actually plan to roll my own font.

I'm curious as to which uVGA version you used? I have the III, and the documentation seems to imply it does a lot. Much more than I plan to use.