Hello, Guest the thread was viewed516 times and contains 9 replies

last post from dddaaannn at the

Finding the right basepage addresses

    Hi everybody!


    I'm struggling to find the right addresses to make some fun with the M65 editor cursor ...


    One of my C64 memory maps show the following zeropage addresses:

    BLNSW 00CC Flag: Cursor blink; $00 = Enabled, $01 = Disabled.

    BLNCT 00CD Timer: Count down for Cursor blink toggle.

    GDBLN 00CE Character under Cursor while Cursor Inverted.

    BLNON 00CF Flag: Cursor Status; $00 = Off, $01 = On.


    Now I am trying these in M65 mode, with Basic and everything else active. The state is like a just booted machine, no mapping or basepage switching going on. But the values on this addresses are not matching the description. My questions:


    - How do I do something like this in M65 mode? Some examples around? E.g. making the cursor permanent in Assembler code.

    - Is there a complete memory map for the M65 as a reference? Or which web-page do I miss? I have tons of docs, but nothing addresses such registers ...


    Thx for any help or hint!

    I remembered a conversation with Dan ( dddaaannn ) on Github, where he mentioned ...


    "A quick review of the MEGA65 ROM IRQ handler shows that there are a few uses of base page variables in the handler code, e.g. cursor blinking uses attptr ($00e0). (...)"


    ... which seems to be very close to what I need.

    Is there a commented M65 ROM listing somewhere, can't find it?


    Thanks!

    Quote from SkulleateR

    Maybe here : https://mega65.atlassian.net/w…+Memory+Map+DMA+Audio+DMA ???

    No, found nothing on the Wiki. The different VICs are documented well at many places, but can not find something on the zero/base page usage during Basic mode, or the ROM routines themselves which may show other memory addresses which are used in this case.


    Maybe there are long disassembly sessions and trial and error in front of me? 😕 Please keep on throwing ideas and links in! Thx!

    Quote from Bananzi65

    Please keep on throwing ideas and links in! Thx!

    I have made an overview of the addresses for the old, original C65-ROM 911001. You can find it here:


    65 Site - Memory Map


    Otherwise, I am not aware of such an overview for the current MEGA65 ROMs. Basically, there cannot be such a "final" overview because the team is still working on the ROM and individual addresses or even larger areas in the ROM can move/shift.

    Solution / clarification

    Here is the list of cursor adjusting screws, first the C64 ones in the zero page, then the correspondent values for the M65. Snoopy maybe you will look at my italic comments to edit your documentation?


    dddaaannn BLNSW seems to be buggy on the M65 ... when I am not missing something. Where do I report these cases?


    C64

    • BLNSW: $00CC = Flag: Cursor blink; $00 = enabled, $01 = disabled
    • BLNCT: $00CD = Timer: Count down for Cursor blink toggle
    • GDBLN: $00CE = Character under cursor while cursor is inverted
    • BLNON: $00CF = Flag: Cursor status; $00 = off, $01 = on

    M65

    BLNON: $111F

    • Cursor blink mode
    • Name should be BLNSW like on C64. Otherwise it could lead to misunderstood documentation/communication
    • Value $C0 = Cursor solid, not blinking
    • Cursor blink enabled: switches between …
      • Value $00 = cursor not visible
      • Value $80 = cursor is a filled square (inverts char)
      • …this value can be used to calc the actual screen code w/o inversion
    • Values can be written to the address to switch the cursor behavior
      • Blinking can be activated with $00 and $80
      • $80 is more immideate; $00 looks smoother

    BLNSW: $1120

    • Cursor status
    • Name should be BLNON like on C64. Otherwise it could lead to misunderstood documentation/communication
    • Not working; always $00, can not be set to other values (or is overwritten with $00 again immediately)

    BLNCT: $1121

    • Snoopys doc says: Cursor color before blink
    • But this one seems to be the correct C64 BLNCT timer, like the name says
    • A count down to the cursor blink toggle

    GDBLN: $1122

    • Screen code of the character before the cursor inverts it
    • Bidirectional: Can be used to change the char in the next blink sequence

    GDCOL: $1123

    • Color of the character toggled by the cursor
    • Bidirectional: Can be used to change the char color in the next blink sequence w/o changing the cursor color
    • Also a space can have a color ;-)

    None of those locations are documented APIs and should not be used. If you create a dependency on any of those locations, your software is likely to break in a future version of the ROM. C64 magic pokes and peeks were based on the assumption that the C64 ROM was byte frozen, as it effectively has been for decades. If they work in the MEGA65 today, they work coincidentally, and are likely to break.


    I'll say it again: None of the MEGA65 KERNAL variables are supported for software use. We are gradually firming up the KERNAL API surface with protections in code, automated tests, and documentation in the manuals. Only documented APIs are supported. We can't support every KERNAL memory location without giving up our ability to fix bugs. Jump tables and vectors are some of our only tools to offer KERNAL integrations that are future-proof.


    As of ROM 920389, the KERNAL jump table API is supported ($FF4D-$FFF3), as are certain facts about the KERNAL memory map (BASIC start address is $2001). In the near future, we will firm up and document more jump tables and integration vectors for extending the KERNAL, BASIC, and screen editor. Commodore designed some fun ones, but given the unfinished state in which they left everything, these APIs need to be tested, prioritized against other more pressing bug fix needs, and documented before we can assure that their behavior or locations won't change. I've tried experimenting with some of the C65 prototype APIs and quickly found breakage. We need to fix them before making them official, to prevent software from depending on the broken versions.


    To be honest, I'm not sure if MEGA65 KERNAL variables should ever be accessed directly by programs. I would rather wrap the most useful ones in accessor routines via the jump table, such as how the PLOT routine returns the cursor location. Once the last few problem areas of the ROM have settled (especially DOS and IEC), it'll probably be fine to allow direct access to some, but it's a poor programming practice in general. (Notably, it wasn't known to be a poor practice back in the 1980's. Platform evolution is a concept that post-dates early 1980's microcomputers.)


    I know I sound like a nag when I say this, and I'm sorry for that. :) Please be assured that I'm personally very interested in getting the ROM code, tests, and documentation into a state where more KERNAL integrations are available to programs. This is the main reason I keep working the ROM bug backlog and the manual in tandem, so we have more options for writing programs beyond pure BASIC and no-KERNAL machine code.

    Quote from dddaaannn

    (…) I know I sound like a nag when I say this, and I'm sorry for that. :) Please be assured that I'm personally very interested in getting the ROM code, tests, and documentation into a state where more KERNAL integrations are available to programs. This is the main reason I keep working the ROM bug backlog and the manual in tandem, so we have more options for writing programs beyond pure BASIC and no-KERNAL machine code.

    Hi Dannn!


    Thanks for your point of view and the warning.

    I guess, the answer to my question is no? No need to report the behavior above somewhere at official places.


    But I must say that I donˋt care so much about using unofficial soft docs / APIs which may break tomorrow. When my program breaks somewhere in the future I am happy to fix it, when I still need it. I love the docs from Snoopy because they widen my possibilities today.


    Above you missed the point, how little hunters like me can support the process you describe, or is this just for the chiefs? E.g. I need the Cursor values above for my project. How can I support that we get official APIs sometime soon? On my way I could help … thought documenting it, like above, would be good value. And now I feel it is the opposite. Leaves me confused.


    But this is the place for geek stuff, not community politics, so I take the message and stay happy about the two values I searched for two weeks. 😉


    best wishes

    I'm very interested to know what capabilities you want exposed through supported APIs! If you have a use case for integrating with the screen editor's cursor, you can file a feature request and we can discuss it there (https://github.com/MEGA65/mega65-rom-public/issues), or we can just discuss it here. We might find a better option for what you're trying to accomplish (maybe you need your own cursor blink routine?), or we might discover an important use case that we should prioritize as an official API (maybe we need a jump table routine that returns the cursor blink status?).


    I've been waving a big flag about this because I know that there are quite a few coders that are used to spelunking in the C64 ROM to find integration points, and while that's fun and interesting in its own right, it's not something we can support when we're actively developing the ROM and the smallest of changes causes internals to get pushed around. As long as everyone understands that the ROM is under active development and that we have a distinction between the public API (supported across versions) and internals (can change at any moment), anyone can do what they like. :)


    There are some KERNAL integrations that I would consider high priority. We ought to formalize the KERNAL soft IRQ vector ASAP, for example. There's currently no official way to make a clean exit to BASIC from a machine code program: the best method is to use hyppo_reset, and the next best method requires preserving and restoring all of KERNAL variable space then returning with rts. There ought to be a third way that properly resets the screen editor, IRQ handlers, base page, etc. that's just a simple jmp from the program. And there's some low-hanging fruit like the BASIC jump table that just needs to be tested and documented. Right now, the only way to change the text mode resolution that remains compatible with CHROUT et al. is to print ESC "8", ESC "4", or ESC "5". Maybe that's sufficient, but it seems worthy of a new jump table entry. Stuff like that.