Hello, Guest the thread was called930 times and contains 9 replays

last post from Gurce at the

Built in ML Monitor

  • I had a play with the in-built monitor a while ago. It was nice, but I think I noticed that it didn't support the newer opcodes that Paul had introduced into the processor.

    It wasn't too big a worry for me, as the in-built monitor seemed sufficient to have a play around and tinker with the available opcodes.

    For bigger assembly projects/endeavours, probably a cross-compiler supporting this cpu (like Ophis, or there was a mention of another, ca65? cc65?) might be the way to go.

    Just as an aside, I hope I can get back into the mega65 soon, I've been a bit distract with other aspects of life lately. It sure is a fun project :)

  • @Gruce: what kind of new opcodes? As far as I know there are no new opcodes,maybe only combination of some already existing ones (like linear addressing with the NOP + Z-indexed base page, but since that's not a "new" opcode but combination of already existing ones, you can use them as-is, no problem). About a cross-platform tool-chain, ca65 is preferred (ca65 is the assembler within the cc65 project), since ca65 already supports 4510 since a while (maybe you need the git version though).

  • @LGB: Hiya, just thought I'd better mention you spelt my name wrong. I guess it was just a typo, so no worries.

    Well, it's been a while since I dabbled with the mega65, but when I was, some of my learning curve regarding the inbuilt monitor was covered in this thread:


    In there I tried to assemble a simple example but run into some trouble.

    At the time, I think I got a hint somewhere that there was a far jump opcode (JMPF?), can't recall from where, possibly from Paul's blog or elsewhere. Since the monitor wasn't aware of it, I worked around it on that occasion with a forced beq.

    As for whether that's a new opcode or not or whether I was mistaken to believe in its existence altogether, I don't know, happy to hear from you on the matter if you can confirm one way or the other.

    As for whether new opcodes exist, again, can't give you specifics, just a recollection of reading the Paul's blog from start to finish, twice, and recalling reading something about him adding more to this cpu than was there initially. I seem to also recall someone asking in the comments section whether a new opcode could be added and him saying it wasn't possible due to all possible opcode values being consumed. Again, this recollection is no guarantee that I'm right on the matter, so if you or Paul want to set the record straight here, that's fine by me :-)

  • I thought I'd try chase up what gave me the impression of a JMPF. I'm guessing it was the mention of a far-jump here:


    Although, looking more closely, it turns out that Paul mentions you need to do "SED, SED, then JMP low_word, high_word" to make this happen.

    So looks like I was mistaken, there's no JMPF, it was just my misunderstanding.

    Still, typing such a far-jump via the in-built assembler would be a bit tricky too, right? So my little example would still be a little problematic.

    A 80C000 INC $D020
    80C003 INC $D021
    80C006 SED
    80C007 SED
    80C008 JMP $C000
    80C00B how to type ".word $0080" here?
    SYS 49152

    Perhaps you could insert the $0080 value into the desired $80c00b address manually by entering the byte values there via the monitor, but again, that feels a little cumbersome. And also, when you try disassemble that region of code, it'll look garbled too, with the extra byte after the JMP interpreted as an opcode.

    Anyway, I'm sure the in-built monitor will be fine for a bit of manual tinkering, but once you really want to sink your teeth into it, and use new techniques like the far-jump, then an a cross-compiler, such as the ones mentioned before, is probably the way to go.

  • @Gurce Yes, sorry, I often exchanges letters by mistake. While programming, compilers usually complain about that :), so I can know, but it's not the case of human languages or names :) :) Ok, I see. Well, yes, so it would be some kind of "beauty work" to assign new "opcode names" which is certainly looks better but of course you can always write with the "manual way". Yes, there is some kind of far jump, but again, it's basically combination a "sequence of already existing opcodes". If I remember correctly, it was something like a double SED trick. In my emulator, I implemented the "linear addressing stuff", though not the "far jump" (it seems not so much uses it yet, even not kickstart).

  • @Gurce: OK, you have another comment here meanwhile I was lazy to send my one since hours :) You're right, it's kinda uncomfortable. However I wouldn't think too much that built-in monitor is the right tool for programming. Especially, since it's C65's own monitor written for the C65, it can't know anything about M65 stuffs of course ... The solution would be a patch of the C65 ROM for support of these, or (maybe) even better to write some kind of "light" native development environment if someone prefers that over the cross-tools things :)

  • @LGB Hehe, no probs, glad to be your spell-checker on this occasion ;)

    Yep, I hear ya regarding either patching the c65 rom or some light native dev environment.

    When I saw Paul's blog post here, he hinted at the hypervisor-mode possibly having its own monitor too, perhaps that could be a good home for it too:


    Hmm, this topic makes me wonder whether a disassembler ought to catch the "SED, SED, JMP" pattern, and display it nicely as a "JMPF", and an assembler take "JMPF $0080C0000" and break it down into "SED, SED, JMP...".

    Anyway, maybe a nice dream for later :)