6502 with a serial port - a minimal monitor?

[8BIT]

This is the 6502 code version. No CMOS opcodes included. I also removed the upload.asm file so it sits from $FC00-$FFFF.

That's it - 1k small and simple. You can easily add commands too. Just check out the readme file. I can help if it is not clear.

[enso]

Daryl, that is great news. I will run the conversion utility on it tomorrow and post the results (and latest python code for the converter)

[8BIT]

Enso,

I revised the file in the link above... please re-download. It needed a few corrections. (I was up too late last night fixing it)

Should be good now.

Daryl

[teamtempest]

I see the code uses that useless (zp,x) address mode!

[8BIT]

teamtempest wrote:

I see the code uses that useless (zp,x) address mode!

I sure do like the 65c02 opcodes better. Did you see my hack for executing the commands?

Addresses to the commands reside in a table in ROM. I had used jmp (table, x). Since the 6502 does not have jmp (abs,x), I had to go back to loading each byte and pushing to the stack, then use RTS for the indirect jump. Had to decrement the addresses by 1 to account for RTS too.

end result - the code conversion works.

Daryl

[enso]

Kingswood assembler is not great. It does not show error line numbers in included files - just the line number of the include statement, which makes it pretty much useless. I might have to write an assembler. Python has so many nice features for writing assemblers that it should not be hard. And I've done it a couple of times before...

Kingswood is case-sensitive for labels, which makes it hard in this case. Since my conversion does not build a symbol table I don't want to convert case willy-nilly on things that may not be labels. I hand-modified a bunch of labels and references (linecnt, LineCnt,lineCnt, etc). I was hoping for an automated conversion, but no such luck.

[GARTHWILSON]

enso wrote:

Kingswood assembler is not great. It does not show error line numbers in included files - just the line number of the include statement, which makes it pretty much useless.

Yes, that would be a problem.

Although I've found bugs with every assembler and compiler I've tried, one assembler I like is Cross-32 (or C32). You buy just one assembler and it's good for for as many processors as you want to assemble for, because it has the tables to form the instructions for so many processors, and tells you how to make your own so for example we can make our own 65-family enhancement and use this assembler for the new processor.

Quote:

I might have to write an assembler. Python has so many nice features for writing assemblers that it should not be hard. And I've done it a couple of times before...

Kingswood is case-sensitive for labels, which makes it hard in this case.

I would recommend including an option to turn case-sensitivity on. I definitely like it. I would also recommend making macros nestable.

There are lots of free assemblers though if you don't want to pay for one. There's a list of them about 3/4 of the way down the software section of my links page (one of the links going to a page with lots more assemblers). Without my having tried the free ones, one that looks especially good is Bitwise's (Andrew Jacobs') at http://www.obelisk.demon.co.uk/dev65/ which has program structure capabilities built in, and teamtempest's (Anton Treuenfels') HXA at http://home.earthlink.net/~hxa/ which includes macros to do the program structures I have been promoting.

[enso]

GARTHWILSON wrote:

...
There are lots of free assemblers though if you don't want to pay for one...

It's not that paying that I have an issue with (I have no problem paying to support an infrastructure I need). Open source is pretty important to me as at this point in my life I have little desire to hope that a third party will fix my bugs, provide support or just not go bankrupt.

Then again, if I am paying for it (and can't change it to fit my needs) it better be really good!

Macros are a whole other topic. I've tried many assemblers with macros (fasm being one I've used a lot), but they are all crazy. I don't even know if there is a good way to do macros as there are many subtleties...

You've provided some good leads and I will try again to find a better assembler. Thank you. At least I have a pretty good conversion utility in the making...

[enso]

OK, the monitor is up and running!

Code: Select all

65C02 Monitor v5.1.1 (7-4-13) Ready

>FF7D
FF7D - 78
 D8 A2
>
FF80 - FF 9A 20 00 FC 58 4C 68 - FD AD 00 C0 20 01 FC 20
>FF57Q
FF57 - 6
>Q
>FF57.FF7CQ
FF57 - 65C02 Mon
FF60 - itor v5.1.1 (7-4
FF70 - -13) Ready...
>

Is this the way it should behave? A <CR> by itself, in particular continues dumping up to the next 16-byte boundary. Q by itself does nothing.

I am pretty happy - it only took a couple of hours (mostly to find a verilog issue with IO port selection logic).

The conversion utility was pretty useful (although lots of case changes were done manually). The conversion code:

Code: Select all

# make adjustments
  opcode=opcode.lower()
  if(opcode==".byte\""): #move " into operand
    opcode="db"
    operand='"'+operand
  if(opcode==".byte"):
    opcode="db"
  if(opcode==".word"):
    opcode="dw"
  if(opcode=="asl") and (operand==''):
    operand="a"
  if(opcode=="rol") and (operand==''):
    operand="a"
  if(opcode=="lsr") and (operand==''):
    operand="a"
  if(opcode=="ror") and (operand==''):
    operand="a"
  if opcode=="*=":
      opcode = "org"
  if operand.startswith("#>"):
      operand = "hi "+operand[2:]
  if operand.startswith("#<"):
      operand = "lo "+operand[2:]
  if operand.endswith(",X"):
      operand = operand[:-2]+",x"
  if operand.endswith(",Y"):
      operand = operand[:-2]+",y"

[GARTHWILSON]

Quote:

It's not that paying that I have an issue with (I have no problem paying to support an infrastructure I need). Open source is pretty important to me as at this point in my life I have little desire to hope that a third party will fix my bugs, provide support or just not go bankrupt.

C32 has been around for at least 20 years (I got it about that long ago), although it has changed hands. The one I used in the late 1980's is from 2500AD is now being supplied by Avocet Systems who also supplied a good assembler back then as a competitor to 2500AD. Avocet has been around for 35 years. They don't appear to give any support for the assembler, but it ought to be very stable by now.

I agree that open-source is the better way to go when possible. I did find another bug last year in C32 (with INCLude files in a macro not getting included until the macro is finished) but found a way around it. The only other bug I can think of is that if there's a comma in a quoted string that is a macro parameter, it mistakes it for a parameter delimiter. This is in my version from about 20 years ago for DOS. They may have fixed those by now, and Data Sync Engineering is still selling C32 for DOS and Windows.

[enso]

GARTHWILSON wrote:

...one that looks especially good is Bitwise's (Andrew Jacobs') at http://www.obelisk.demon.co.uk/dev65/ which has program structure capabilities built in.

Unfortunately, uses java which I would rather not use if at all possible...

GARTHWILSON wrote:

... and teamtempest's (Anton Treuenfels') HXA at http://home.earthlink.net/~hxa/ which includes macros to do the program structures I have been promoting.

Unfortunately, windows or dos only...

[whartung]

enso wrote:

GARTHWILSON wrote:

...one that looks especially good is Bitwise's (Andrew Jacobs') at http://www.obelisk.demon.co.uk/dev65/ which has program structure capabilities built in.

Unfortunately, uses java which I would rather not use if at all possible...

Well, that rules mine out then.

I wrote my own mostly because I couldn't find anything that ran well on the Mac, and did what I want. I can't seem to find any that produce an assembled listing of all things.

So, mine does -- listings and Intel HEX output.

No macros though.

[enso]

It seems that every one of us is using a different assembler! You'd think that we would unite, given our numbers... I remember some threads about assemblers and macro features in the past. Don't want to go too far off-topic, but it is a sore subject.

It would seem more appropriate for the macro facility to be separate from the assembler, like the C preprocessor (but more general purpose). Too bad M4 is a nightmare.

[8BIT]

enso wrote:

OK, the monitor is up and running!

Code: Select all

65C02 Monitor v5.1.1 (7-4-13) Ready

>FF7D
FF7D - 78
 D8 A2
>
FF80 - FF 9A 20 00 FC 58 4C 68 - FD AD 00 C0 20 01 FC 20
>FF57Q
FF57 - 6
>Q
>FF57.FF7CQ
FF57 - 65C02 Mon
FF60 - itor v5.1.1 (7-4
FF70 - -13) Ready...
>

Is this the way it should behave? A <CR> by itself, in particular continues dumping up to the next 16-byte boundary. Q by itself does nothing.

Yes, the text dump was an add-on that was kind-of patched in. It does require either a single address or a range in front of it.

Glad to see it is living!

Daryl

[GARTHWILSON]

whartung wrote:

I wrote my own mostly because I couldn't find anything that ran well on the Mac, and did what I want. I can't seem to find any that produce an assembled listing of all things.

So, mine does -- listings and Intel HEX output.

Both the commercially available macro assemblers I mentioned above do. The .LST file is the list file output showing the machine language (also addresses and constants) next to the line of assembly language that produced it, including conditional assembly and macro expansion. Any error messages will also be put there immediately before or after the line that has the error. At the end of the .LST file is a list of all labels, alphabetized, along with their addresses. The .HEX file is the Intel Hex file output.

enso wrote:

It seems that every one of us is using a different assembler! You'd think that we would unite, given our numbers... I remember some threads about assemblers and macro features in the past. Don't want to go too far off-topic, but it is a sore subject.

WDC wishes we would unite under their tool chain, and apparently they are going to make it available to run under Linux as well as Windows (because a couple of us requested it). I would like to write my program-structure macros for theirs as well. I don't particularly want a "tool chain" though, only the assembler. I've worked out a system that works well, using a superior editor, and I hope I can use just their macro assembler.

Quote:

It would seem more appropriate for the macro facility to be separate from the assembler, like the C preprocessor (but more general purpose). Too bad M4 is a nightmare.

Then would conditional assembly have to be separate too? (Macros have an awful lot of conditional assembly, based on conditions in the parameter list.) I don't immediately see how that would work out.