BASIC 10 chapter of the MEGA65 manual finished today

Es gibt 124 Antworten in diesem Thema, welches 42.696 mal aufgerufen wurde. Der letzte Beitrag (16. Februar 2022 um 21:21) ist von adtbm.

  • Maybe try to progressively reduce the amount of free memory by allocating variables on a new rom, and see if the 24K goes down to 0, and then jumps back up to 32K. I am suspecting that FRE() in the newer ROMs might be returning only the bottom 15 bits of the value.

    I seems that it is not only an error in the the FRE command in the newest ROM. It's an general BASIC memory error in the newest ROM (911001.bin) :(

    I wrote this short BASIC program to test the free BASIC memory for variables:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Asking for "i" as a number how great the array of "A" should be, reserving the variable memory with "DIM A(I)" and showing the free memory with the FRE commands where FRE(1) shows the still free memory for variables.

    With the older ROM (910429.bin) the maximal number of "i" is about 11.000. Greater numbers produces an "?OUT OF MEMORY ERROR":

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bitte melde dich an, um diesen Anhang zu sehen.

    With the newer ROM (911001.bin) the same test program shows that there is much less BASIC memory free. The limit is here something around 4.500 for "i" and trying 11.000 shows an "?OUT OF MEMORY ERROR".

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bitte melde dich an, um diesen Anhang zu sehen.

    So using the newer ROM there is less than half of the free memory for BASIC as using the older ROM. ;(

  • Question is: is BASIC able to access more than 2 banks? Being able to move data between (ram) banks doesn't mean that basic can directly access more than 2 banks. So for access to data in expanded RAM I think you must first move the data from expansion into ram bank 0 or 1, and then access the data.

    Fre(0) and Fre(1) gives the amount in memory for BASIC, and as I read somewhere Fre(2) should give the amount of external (additional) memory banks.

  • Question is: is BASIC able to access more than 2 banks? Being able to move data between (ram) banks doesn't mean that basic can directly access more than 2 banks. So for access to data in expanded RAM I think you must first move the data from expansion into ram bank 0 or 1, and then access the data.

    Fre(0) and Fre(1) gives the amount in memory for BASIC, and as I read somewhere Fre(2) sould give the amount of external (additional) memory banks.

    FRE(0) shows the free BASIC memory for the program code

    FRE(1) shows the free BASIC memory for the variables

    The same BASIC program has about 24550 bytes free for variables with the newer ROM, but about 55270 bytes with the older ROM.

    So something had to be changed in the handle with BASIC memory or there is an error in the newer ROM. :/

  • From Manual:

    FRE -- Free byte function

    FRE (x)

    This function returns the number of available ("free") bytes in a

    specified area.

    PRINT FRE(0) Shows the amount of memory left in the program area,

    C64DX bank 0

    X = FRE(1) X= the amount of available memory in variable area

    C64DX bank 1. This causes a "garbage collect" to

    occur, a process which compacts the string area.

    X = FRE(2) X= the number of expansion RAM banks present.

  • Maybe the newer ROMs does not invoke garbage collection?

  • hmm,

    DIM A (I)

    reserves a lot of space in bank 1 oder?

    So far as I understand the C65 BASIC, all variables are stored in bank 1 and the program code in bank 0. My intention with the short program was to reserve variable memory with the DIM command and then show the free memory which is left after the DIM command. And with the older ROM there is more than twice of variable memory availiable as with the newer ROM.

  • That's why I mentioned 'garbage collection'

    X = FRE(1) X= the amount of available memory in variable area

    C64DX bank 1. This causes a "garbage collect" to

    occur, a process which compacts the string area.

    Maybe the garbage collection routine is broken in newer roms.

  • There must be two Top Of Memory vectors at least somewhere among the Basic system variables being set to $8000 (that should be set at $ff00 for bank 0 and $f800 for bank 1 normally). Hopefully that's enough to find them and manually change their values (then perform a NEW command). Now the question is just where they are...

    Maybe they are only set so for reserving some space for gfx (somewhat similarly to the C128 and Plus/4 where the Basic start is shifted upwards to $4001 when performing a GRAPHIC command by the user).

    Actually the start vectors can be changed to lower, too. For example POKE46,19:POKE4864,0:NEW sets the program start to $1301 instead of $2001 and adds almost 3K to the code space (this trick is also working on the C128).

  • Ok, I found them (it was not that hard...):

    POKE 720,255 (top of program space in bank 0)

    POKE 58,248 (top of variable space in bank 1)

    POKE 46,x (start of program)

    POKE 48,y (start of variables)

    POKE x*256,0:NEW

    PRINT FRE(0),FRE(1)

    Both x and y are =32 by default, but they can be set to lower for increasing the space (x down to 19 see my previous post... y is not sure).

  • I have patched the 911001.bin ROM, so the more free BASIC memory is available after the start and called it 911001_aa.bin.

    Bitte melde dich an, um diesen Anhang zu sehen.

    I just wanted to attach the patched rom, but I think it's not the best idea because of legal problems with distribute a copyrighted rom.

    Especially after the recently deal with Cloanto, I don't want to get the Forum64 and Mega65 team (and me) into some legal issues.

    So my question: Is there any legal possibility to share a patched original ROM to the Mega65 community (maybe a clause in the deal)? If not, would be a program which adds the patch to a original ROM a legal way or would this also conflict with copyright? :gruebel

  • So my question: Is there any legal possibility to share a patched original ROM to the Mega65 community (maybe a clause in the deal)? If not, would be a program which adds the patch to a original ROM a legal way or would this also conflict with copyright?

    I'll check this with Deft and come back to you.

    I don't think, there is much of an issue, since we have the permission now to use the c65 Kernels.

    (and the ones that are available are also in various development states (patched versions) available)

    But like i said. i'll check.

    Bitte melde dich an, um diesen Link zu sehen. <- here you can find all MEGA65 related files, games, etc.

    Bitte melde dich an, um diesen Link zu sehen. <- MEGA65 main Homepage. links to all important MEGA65 sites (links on top of the page to Files, Forum, GitHub, Manual,etc.)

    Bitte melde dich an, um diesen Link zu sehen. <-Pauls Blog - constant updates about current tasks, project status, etc.

    Bitte melde dich an, um diesen Link zu sehen.,Bitte melde dich an, um diesen Link zu sehen. <- All Open-Source information regarding MEGA65. Found Bugs ? create an issue there please!

    Bitte melde dich an, um diesen Link zu sehen. <- Join for live chat support and more --- The Future is 8-bit !!!

  • You can supply the offsets and changed bytes, or even write a little program that modifies the ROM in place. I can show you how to un-write-protect the ROM on the MEGA65, then you can make the changes, and re-protect it, and call the reset vector again, and you will be running the new ROM. This will make a nice tool for others who want to make changes to the ROM to be able to do so.

    LG

    Paul.

  • Have you also managed to remove the Basic demo application completely?

    I have forgotten that in the first patch. I have filled the area ($4000 to $6FFF) with $FF in the next patch "AB", so the demo files are gone. I test the patched ROM with the Nexys board soon, in the Xemu all works fine.

  • I have filled the area ($4000 to $6FFF) with $FF in the next patch "AB", so the demo files are gone.

    Better to fill it with $00 for at least the first 6-7 bytes. Until that code is found and disabled which copies the demo program from the ROM into the Basic RAM and tries to RUN that, it would be safer, since the zero bytes are surely harmless as meaning an empty or non-existing Basic program, but having a lot of $FF instead may lead to a ?Syntax error or some other side effects.