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

  • Sorry that I had here in the first moment your assembler in the suspicion, there you can not help it! :whistling:

    Your assembler works fine! :thumbup:

    I'm sure it has other bugs that still need to be discovered.

    It's not really a bug, but it would be really helpful if you make an additional key sequence for "page up" and "page down" in your editor. The function keys F9 and F11 can not be used in Xemu emulator because these are function keys used for the emulator itself (exit and fullscreen).


    Then using Xemu you have to scroll down your 40 billion line of codes each line after line. ;(

  • Can't you map the real Page up/down keys to the Mega's F9/F11 in Xemu?


    But of course I can put Ctrl-P/V in my editor additionally. Like, when in the latest version I switched to the real Help key for calling help, I still kept Mega-H that I used when I still worked on my Nexys board. Will do that in the next version.


    If you don't want to wait, check starting at line 1000. There you will find the key mappings, it's very simple to change them.

  • MegaAssembler exist for Geos 64 /128. It was published 1990 by Markt & Technik. It was updatet bei M. Kanet for better working :-) in Geos and MegaPatch V3 . The last update was end of May 2022 .

    Hi Werner, thanks for pointing that out. I never heard of this assembler before. Maybe in a context where there is potential for confusion, I could refer to my assembler as Mega Assembler 65. But I think for the purpose of this forum we should be fine. After all it's not a commercial product, but simply a small, quick and dirty Basic program that I wrote as a hobbyist and shared with friends ^^

  • MegaAssembler exist for Geos 64 /128. It was published 1990 by Markt & Technik. It was updatet bei M. Kanet for better working :-) in Geos and MegaPatch V3 . The last update was end of May 2022 .

    Hi Werner, thanks for pointing that out. I never heard of this assembler before. Maybe in a context where there is potential for confusion, I could refer to my assembler as Mega Assembler 65. But I think for the purpose of this forum we should be fine. After all it's not a commercial product, but simply a small, quick and dirty Basic program that I wrote as a hobbyist and shared with friends ^^

    Maybe you can name it: "Mega Assembler for MEGA65 not to be confused with Mega Assembler for Geos"? :whistling:

  • OK, here's what Bit Shifter said. It's simply not yet implemented. The manual describes how it should be in the future :rolleyes:

    There is new information from Bit Shifter regarding the Bank 4/6 $8000 issue: It is by design and can't be changed. The manual will be updated.


    Here's what Bit Shifter said on Discord:

    Quote

    I looked again at the source code and remember now, why the standard mapping for the SYS bank is done for $2000 - $7FFF.

    $0000 - $1FFF stays at bank 0, because we have here our zero page, stack page and the code, that executes SYS.
    The upper 32 K can have only one common offset, so I can only map in the selected RAM bank
    OR the kernal ROM ($E000 - $FFFF), bot not both at the same time.
    So I think, we have to live with this, but I'll update the manual.


  • Strange, as described above, it works with the BASIC 65.EX ROM.

    Is BASIC 65.EX ROM based on an earlier ROM version, where Bit Shifter hasn't updated the SYS command yet? In this case it indeed would work, but only until the first interrupt occurs - then the machine would lock up, as we've discussed in the topic you cited above. Try something that runs for more than 1/50 of a second...

  • Is BASIC 65.EX ROM based on an earlier ROM version, where Bit Shifter hasn't updated the SYS command yet? In this case it indeed would work, but only until the first interrupt occurs - then the machine would lock up, as we've discussed in the topic you cited above. Try something that runs for more than 1/50 of a second...

    The BASIC 65.EX is based on the ROM 920300, thus still shortly before Bit Shifter extended the SYS command with the ROM 920304 and/or 920306. With this old ROM one could use above $2000 still no SYS functionally at all.


    I have at that time independently with the EX-ROM at the place hand put on and extended it. Therefore I assume that we did not proceed completely identically and that there are differences here.


    I'll try out later what happens with longer runtimes. :smoke:

  • Yes, just to recap. At longer runtimes, in the past we had the problem that if RAM is mapped into the whole bank, i.e. no Kernal or Basic ROM is present, an interrupt would crash the machine because of the missing interrupt handler. But you can at least stop Basic interrupt handling by clearing bit 0 of $1104, so only the Kernal needs to remain mapped in. If you want to get rid of the Kernal as well and have RAM everywhere (maybe except for the I/O at $D000-$DFFF), you at least need to install your own IRQ handler via the Vector at $FFFE/$FFFF that, as a minimum, clears the interrupt flags in VIC register $D019 - otherwise the CPU will end up in an endless interrupt loop and no longer have time for the main program. And also, NMIs should be catched and pointed to an RTI.

  • But you can at least stop Basic interrupt handling by clearing bit 0 of $1104, so only the Kernal needs to remain mapped in.

    BTW: The SYS command always clears the BASIC IRQ before executing the called routine:

  • As you write, with assembly programs you also have to think about the interrupts and handle or disable (with SEI) them accordingly.


    I have typed now over noon times a short test program that should simply increase with 3 loops enabled a total of 16.7 million times the frame color. The program is written and started in bank 4 from $8000.



    This lasts also with 40 MHz approx. 5.8 seconds and is thus "sufficiently" long busy. ;)


    When I compile and start the Mega Assembler program "banka.asm" (also attached as D81 image) with BASIC 65.EX, I see the colored frames ...



    ... and then it goes back to the assembler.



    Made the same with the current ROM 920371 ...



    ... and I see that:



    So there must be a difference somewhere. The range from $2000 to $BFFF should be usable for programs called with SYS with banks 0,1,4 and 5. :nixwiss:


  • When I compile and start the Mega Assembler program "banka.asm" (also attached as D81 image) with BASIC 65.EX, I see the colored frames ...


    So there must be a difference somewhere. The range from $2000 to $BFFF should be usable for programs called with SYS with banks 0,1,4 and 5. :nixwiss:

    Sooooo nice to see an assembler program in Mega Assembler that I didn't write myself :thumbsup: Thank you


    Now for the $8000 issue, I really have no idea what's going on in BASIC65.EX, but I think we have resolved (i.e. understood....) the issue with the latest ROM. There simply is no RAM at $8000 when you SYS into bank 1, 4 or 5. It only works for bank 0 (but there you can't use it without assembling to disk first and loading later, because this is where the assembler itself is stored).


    The reason is the Commodore engineer's clever design of the 4510 mapping function. You can only specify different map indexes for memory at $0000-$7FFF and $8000-$FFFF. So if you use $40000 as the index for $8000-$FFFF to map in RAM from bank 4 here, you can not at the same time map in the Kernal, since it is stored in bank 5. Bit Shifter gave the Kernal priority over RAM, so when calling the program with SYS in bank 4, you only have RAM from $0000-$7FFF. That is why the program does not run.


    To run it properly, you would need to place a program in $0000-$7FFF that disables interrupts, map in the bank 4 RAM at $8000-$FFFF, then call your bordercolor-loop-program at $8000, and then restore the normal mapping with the ROM visible before returning.