Hello, Guest the thread was called2.5k times and contains 77 replays

last post from sundance at the

Mega Assembler is live on file host

  • ... increase with 3 loops enabled a total of 16.7 million times the frame color

    Oh, I just see, a little explanation might be useful: There are not 3 loops, but only 2, because in the inner loop I use a word $ffff that is counted down and then $ff times that. So in the sum it remains 16.7 million increments, but so much correctness should be! :saint:

  • I have no other explanation than there is really accessable RAM in bank 4 at $A000. ;)

    Yes, I totally agree on this. There is RAM, it is accessible with PEEK and POKE and in MONITOR. Just the bahaviour of SYS differs between the latest Mega65 ROM and BASIC65.EX ROM. When you do a SYS in BASIC65.EX, the RAM of bank 4 starting at $8000 is exposed, while in the "standard" ROM it is not.


    To make it work in the latest official ROM, you need to apply the RAM mapping yourself, as Bit Shifter explained. SYS won't do it for you. Here's a little expansion of your program that does exactly this:




    As you can see, now it also works in the latest official ROM. You can find the file in the included D81.

  • To make it work in the standard ROM, you need to apply the RAM mapping yourself.

    Thanks, I have tested your program. It works with both ROMs now.


    I have vowed to myself to rather hold back with criticism of the ROM ... only so much and then I leave it also well ... :whistling:


    With your method you can access from BASIC only indirectly the range $8000-$BFFF (which is after all 16 kb per bank), which becomes more complicated at the latest when one has several entry address in the range, with which one would like to access e.g. comfortably with SYS $8000, SYS $A1000 or SYS $B200 in bank 4 and 5. This can propably only be done by a detour via a weighting routine below address $8000.




    My opinion: If you work with assembler and SYS, you usually know what to look for. I think the restriction is unnecessarily complicated, but for the official ROM it is the decision of the team and that is just so. Let's go on! ;)

  • There simply is no RAM at $8000 when you SYS into bank 1, 4 or 5.

    :schreck!:


    I have shown you screenshots and even the test program that it works. You can try it yourself. Where should the program be stored in the EX ROM, if not in RAM? Voodoo? :D

    What I meant to say is, that the RAM from bank 4 (which clearly does exist!), in the case of the latest official ROM, is not mapped into the CPU's 16-Bit memory space at $8000 by the SYS command, and therefore is not visible to the CPU. So the program, which is in fact stored at $48000, is not seen by the CPU and therefore can't be executed.

  • With your method you can access from BASIC only indirectly the range $8000-$BFFF [...] This can propably only be done by a detour via a weighting routine below address $8000.

    Yes, exactly. However I want to distance myself from this being "my method" ;(, it's just how the C65/Mega65 and the ROM were designed. If you want to execute code at $8000 or above in banks other than bank 0, you have to MAP the memory in. That's just how it is.

  • I get along well with your assembler and try something with it every now and then. :loet


    Just now I noticed two things, in case you should be bored or so ... :whistling:


    First:


    With the .BYTE command it would be nice if you could write strings together and you don't have to enter each letter separately. Some assemblers can do that and I find it quite handy. :saint:


    Here is an example how it works:




    And here one, what would be great, if it would work:




    :cry:



    And the second one:


    When I have the program compiled and run it with "R", I don't see anything because it jumps right back to the assembler. So I have to run it from BASIC with SYS.


    Here I would find it good, if the assembler waits after "R" and termination of the program on a keystroke (gladly with appropriate message) and jumps only afterwards again into the assembler editor. Then I can see what I have programmed! :)


  • To make it work in the latest official ROM, you need to apply the RAM mapping yourself ...

    This also works "in the other direction". :prof:


    If you map in the kernel area with a few lines of code, then you have it also available in the EX ROM and can access e.g. kernel routines (in the example $FF7D for "immediate print").


    Of course I can use then, exactly as with the MEGA65-ROM only the range $2000-$7FFF for the program part, which needs the kernel. However, I can still use additional program code in higher ranges and also call it from BASIC with SYS if it does not need a kernel (in the example in $A000 to increase the frame color).






    While we're on the subject: The assembler works really well! :thumbup:


    It is still a bit unusual that the editor partly reacts differently than the BASIC editor. Especially after a RETURN key press. But I will get used to that. :)

  • This also works "in the other direction". :prof:

    If you map in the kernel area with a few lines of code, then you have it also available in the EX ROM and can access e.g. kernel routines (in the example $FF7D for "immediate print").

    Yeah, I think the Mega team just had to decide between those two options, they can't have both. Why they decided for having the KERNAL mapped in, I don't know. Maybe they thought that most programs are application programs which would profit from the Kernal, and if someone wantes to take over the system completely, he might be experienced and intelligent enough to do a MAP.


    While we're on the subject: The assembler works really well! :thumbup:

    I love to hear that :D can you say it again?


    It is still a bit unusual that the editor partly reacts differently than the BASIC editor. Especially after a RETURN key press. But I will get used to that. :)

    Yes, I am aware of that. Since I wrote the assembler+editor basically for myself, I took the freedom to design it in a way that I personally like, even if it is weird sometimes. Now everyone else has to suffer, sorry for that :saint:

  • First:


    With the .BYTE command it would be nice if you could write strings together and you don't have to enter each letter separately. Some assemblers can do that and I find it quite handy.

    You can do this with the .TEXT directive. Of course it's still more to type, since you need several lines now:

    Code
    1. .BYTE 147
    2. .TEXT 'HELLO'
    3. .BYTE 13,0


    And the second one:


    When I have the program compiled and run it with "R", I don't see anything because it jumps right back to the assembler. So I have to run it from BASIC with SYS.


    Here I would find it good, if the assembler waits after "R" and termination of the program on a keystroke (gladly with appropriate message) and jumps only afterwards again into the assembler editor. Then I can see what I have programmed! :)

    You can do this with the RUN Flags:


    Code
    1. .RUN WAIT

    Waits for a key after execution, so you can see the output of your program.


    Code
    1. .RUN CLEAR

    Clears the screen before execution.


    Code
    1. .RUN CLEAR,WAIT

    You guessed it, it does both.


    And finally:

    Code
    1. .RUN AUTO

    automatically executes your program after assembly, so you don't have to press the 'R' key, which saves you so much time 8o


    If you want to impress your friends, try .RUN AUTO,CLEAR,WAIT

  • ... I took the freedom to design it in a way that I personally like ...

    :thumbsup:



    Some suggestions for entertaining key assignments:


    - every third time you press SPACE, a random number of space chars ($20) were printed

    - every random time you press the "cursor left" key, the cursor jumps to an random position on the screen

    - every fifth MEGA-S would not save the file, but delete the current program in RAM and format the disc without asking


    :whistling:

  • Grubi, this is awesome work!


    And Snoopy, great job testing and troubleshooting!


    Truly guys ... I'm in awe of your collective talents.


    I'd love to develop something meaningful (if only simple to begin with) using Mega Assembler, but perhaps it's a bridge too far. I've never before coded in assembly - not for 6502 or any other platform.


    Only high level languages ... BASIC V2 in the old days, of course