The comments you provided made it much easier to make it print 2 ASCII char's per 16bit memory location. I've updated your corrections too. I'll update the Software for 65Org16 DevBoard thread soon after I add the 'e'xit command. Thanks again.

EDIT: I've made the WIDTH and HEIGHT values actual registers, so they can be changed by C'mon itself to adjust for different operating conditions, i.e. different character sizes.

You might want to call the 'e'xit command Quit, since E is a hex digit. And you might want to have Q be uppercase only, so that it's harder to do it accidentally.

I've uploaded a single step (copy-and-paste) "plug-in" for C'mon, for anyone interested. Works similar to the step/trace commands for the "old" monitor ROM on the earliest Apple II.

That's a great debugging tool, especially with a 'scope checking outputs. I'll have the opportunity to try it out tomorrow.

Thanks for the effort you continue to put into the 65Org16 development. I also try to continue development of the 65Org16.b Core with the help of others.

Thanks Bruce, that should be really useful. I'll have to get over my jetlag before I try to do anything with my brain.

Hmmm, I know I said "tomorrow", but I was finally able to try it out today.

The address I type in isn't correct when using the Step function. As a check, since I am using an updated version of the 65Org16.b (which is intended to be backward compatible with the original), I tried the Go command. C'mon receives a good address then...

A few things to keep in mind.

• Unlike G or X you need to set the address with @ (or use Go+BREAK) before using $
• The address (and registers and flags) output is AFTER the instruction has been executed (e.g. a NOP at $1000 will output 00001001 not 00001000)
• The single step doesn't know about any instructions other than those from the NMOS 6502. To correctly single step new instructions GETLEN must be updated to return the correct length-1 (0,1, or 2) for the new instructions (in some cases it may already return the correct value), and any new instructions that jump or branch must be handled specially (the way BCC, JSR, etc. are now).

Hi Bruce
I've been away from the 65Org16 for a bit, but I did pick up your compact monitor for my 6502-on-ARM project and so backported it to 6502.

Just one interesting change: I think there's a need to jump back to the top after the indirect jump, if a return from 'g' is going to work:


There are some uninteresting changes to do with branch distances too, and I changed some constants to negative numbers to make them byte-size agnostic. Source here. (I believe you're OK with the copyright statement)

A very minor and aesthetic point: I'd be inclined to report the registers in the order A,X,Y,S,P

Cheers
Ed

In my experience, it's rare that the sort of routine you would usually call with G would set the decimal flag and return without clearing it. Your change will handle that scenario correctly, though. Other than that you get a CRLF and a fresh prompt, which (like the register order) is one of those minor matters of personal preference that's easy to change if you would rather things be different. I just picked something that I could live with, but I certainly don't expect everyone to have the same preferences.

If people want to extend C'mon little by little, then go for it. The reason I released the single stepper as a plug in is because I want to keep C'mon itself minimal, since it's intended as something you can install on hardware that you're trying out for the first time. It's often very difficult to figure out why something's not working (or where the problem even is) if you're trying to debug a large piece of software and hardware simultaneously. It's supposed to be the software equivalent of getting that first light blinking. If there's interest in cranking out a version of C'mon with lots of features, I'm happy to answer questions or offer my thoughts, even if I don't wind up contributing much code.

And I'll make a confession here. I wrote the single step plug in to give a head start for outputting useful information when what works on my simulator doesn't work on someone else's system. That way I could just say single step from such-and-such an address, and usually have some idea of where to go from there depending on the result. If it's useful beyond that, then that's a nice bonus.

Oops - sorry Bruce, I thought the JMP MON was a necessary and helpful bugfix on your code, but on investigation you had a JMP M2 in there which I'd removed thinking it was one of my own put in there to help overcome branch-distance limitations. So I'd merely fixed a bug which I'd put in myself.

I've reverted that to how it should be, and also made the single-stepping code conditional, so that the default build would be the minimal monitor as you intended. Which also shows up the nature of the plug-in, as a kind of howto.

(I have committed the AXYS change though.)

Thanks for the monitor - minimal though it may be, I can see it being very useful.

Cheers
Ed

I've updated the single step plug-in to allow the use of JSR for breakpoints instead of (or even in addition to) BRK. The only changes are to the BREAK routine at the very end. Everything up to and including the GETLEN routine are exactly the same.

As Bruce's site is down, here's a mirror of the Compact Monitor source:
https://github.com/BigEd/a6502/blob/mas ... s/cmon.a65

Thanks for making this available. I've borrowed it for my 6502 on iCE40 FPGA system and it's handy to have.

Sounds good! I suppose that's this project and thread:

Small 6502 systems on Lattice ice40

(github link within)

Yes! Thanks for linking - I should have done that myself. That thread actually has links to three different github repos for 6502 projects and C'mon is used in this one:

up5k_basic - A small 6502 system with MS BASIC in ROM

One thing I added to mine is a little intro help that lists the crucial command syntax when starting up as that took me a bit of searching to figure out.