Sorry that I had here in the first moment your assembler in the suspicion, there you can not help it!
Your assembler works fine!
I'm sure it has other bugs that still need to be discovered.
You are about to leave Forum64 to get redirected to the following address:
Please note, that the target website is not operated by us. We are not responsible for it's content nor does our privacy policy apply there.
Sorry that I had here in the first moment your assembler in the suspicion, there you can not help it!
Your assembler works fine!
I'm sure it has other bugs that still need to be discovered.
Sorry that I had here in the first moment your assembler in the suspicion, there you can not help it!
Your assembler works fine!
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.
Only a short question:
Is it a good idea, this sofware call "Mega Assembler"? I think: no .
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 .
I see a risk of confusion ...
Bye
Werner
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.
No, you can not map the keys in xemu.
But I found ot, that CTRL+P and CTRL+V work also in your editor. So all is fine!
I see a risk of confusion ...
More confusion: There's also a GEOS for the MEGA65.
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"?
"Mega Assembler for MEGA65
Suggestion: simple call it "Mega65 Assembler" .
Bye
Werner
Maybe you can name it: "Mega Assembler for MEGA65 not to be confused with Mega Assembler for Geos"?
I'll make an acronym out of it, and call it MAFM65NTBCWMAFG. At least that's easy to remember
OK, here's what Bit Shifter said. It's simply not yet implemented. The manual describes how it should be in the future
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:
QuoteI 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.
Here is a screenshot of a slightly modified example program of your assembler. Exactly this program was compiled in bank 4 from $BF00 and increases with each Mega-R the border color:
Ich hatte noch irgendwo im Hinterkopf die Erinnerung, dass wir uns schon mal über dieses Thema hier unterhalten haben und ich habe es wider Erwarten sogar noch gefunden:
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.
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:
Interesting. But shouldn't that be the lsb (instead of msb)?
If we peek into the interrupt handler of the Mega65 ROM:
At $3F984-$3F988, the LSB of $1104 is tested. Well, it's just a mistake in the comment, so everything works fine.
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.
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.
Sooooo nice to see an assembler program in Mega Assembler that I didn't write myself 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.