Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Potential bug in impl of LOAD "..." CODE
#2
(03-15-2021, 09:21 PM)georgeo Wrote: Hi everyone (probably for the attention of Boriel),

My search for the source of instability in my game continues, though I no longer think it is to do with memory management, but a possible bug in the compiler, for the implementation of LOAD "..." CODE. I have noticed that part of my program gets corrupted after I use LOAD "..." CODE to load some UDGs at the top of memory. Digging in to the implementation of the function, I found the following code (sorry, I can't copy and paste code out of the emulator I am using):

https://1drv.ms/u/s!Atca6hVb5b8Tp5JxCEWC...g?e=qGHdEg

At the end of the snippet, a call is made to 0xE6E1, which is a wrapper to the ROM loader routine (in this case, to load a tape header). IX points to the place in memory where the header should be loaded, which -- in this case -- is inside my program code. If I understand correctly what is going on, the snippet starts with a call to MEM_FREE (0xDB56, in this case) which returns a pointer to space in the heap (perhaps where the header can be stored?). However, the IX register is loaded with 2*SP and passed to the tape loader, which I think is a mistake.

Is that a possible bug?

If this is indeed a bug, it fits with my experience. As the size of my program grows, I need to raise the origin address to avoid random crashes. For example, if I have a 30kb program with origin address at 29,000, then the stack will reside somewhere near the start of the heap, so 2*SP will be around 58,000 which will be near the end of my program. However, if I up the origin to 31,000, then 2*SP will be more like 62,000, which will be just past the end of my program. As the size of my program increases, it will eventually grow past 2*SP and then will start to get corrupted and crash randomly, when I load from tape, so I again need to raise the origin address.

It all seems to fit, but maybe I've just convinced myself,
Georgeo.

To use UDG you have to do
Code:
LOAD "" CODE USR "a"

This is because USR "a" always point to the address of the "\a" UDG, which is also stored in the ROM variable UDG. PRINT PEEK(UInteger, 23675) will give you the value.

If you compile with
--sinclair
then you can use LOAD "" CODE USR "a". Otherwise you have to reserve memory for UDGs. A way to do that is to declare an empty array an declare the UDG there. For example:

Code:
DIM UDG(10 * 8) AS UByte : REM 10 UDGs * 8 Bytes each
POKE UInteger 23675, @UDG(0): REM Sets UDG var to point to 1st element

LOAD "" CODE USR "a": REM Here LOAD "" CODE @UDG(0) will also work

If you load "" CODE anywhere, it will overwrite your program as you said. A compiled program is no longer BASIC, but machine code. Rolleyes
Reply


Messages In This Thread
RE: Potential bug in impl of LOAD "..." CODE - by boriel - 03-16-2021, 07:20 AM

Forum Jump:


Users browsing this thread: 1 Guest(s)