| Posted By
Andras
on 2025-03-01
09:03:28
|  graphics area problem
Hello all!
We are developing a new program. The first part of the program is a boot, which loads a graphic with 8.1 parameters.
Draws the graphics on graphic3 screen.
Then graphic0:graphic clr
In the last step, it loads (load"",8) the main program.
The main program was written in BASIC. Unfortunately, even though the graphic clr was entered in the boot program, the main program is incompletely loaded.
How to restore BASIC workspace after graphics?
Thank you for your help.
|
|
Posted By
Csabo
on 2025-03-01
09:23:23
| Re: graphics area problem
the main program is incompletely loaded.
It's not, it just appears that way. Your first variable assignment is what messes it up.
The core issue is that LOAD/DLOAD from a BASIC program doesn't set the BASIC program end pointer ($2D/$2E, etc).
Here is how you can verify this yourself, perhaps seeing it in action will make it clear. Create a new empty D64 file in YAPE (or insert a blank disk, if you're doing it on a real computer). Write the following program:
0 A=A+1:?"TEST STRING";A:GOTO0
You can run this, works fine. Save it: DSAVE"SECOND". You can RESET, load it from disk (from direct mode), still works fine.
Now let's write another program. NEW (or RESET), then
0 DLOAD"SECOND
Save it: DSAVE"FIRST". So this program just loads the SECOND program.
Try running it! It will load, then the second program will stop, and after LIST, it appears that it been cut off or not loaded completely.
However, that's now what happened. When the FIRST program is loaded, the BASIC program end pointer is set to where THAT program ends. (Obviously!) Then the DLOAD command executes. This loads the SECOND program completely, but the BASIC program end pointer has not changed. All variables are allocated after the end of your program. Therefore, as soon as you use any variables, those will be allocated and written into the memory, overwriting and ruining your code.
What's the solution? The first statement of the program you're loading should be a couple of POKE statements which set up these pointers.
Let's say the program you want to load is from $1001 to $1567. In this case, if you set the end pointer and the start of the variables from $16##, you will be safe. (In other words, you increased the high byte - $15 - by one to $16, therefore you won't have to worry about the low byte at all.) You would have to write $16 to $2E, $30 and $32. This would be POKE 46, 22 : POKE 48, 22 : POKE 50, 22. Problem solved!
Let me know if you have any questions.
|
|
Posted By
Andras
on 2025-03-01
09:39:02
| Re: graphics area problem
@csabo
Thanks for the answer. I entered the poke commands before loading the main program, but the situation did not improve much. More of the program is visible, but it crashes when running
|
|
Posted By
Csabo
on 2025-03-01
09:47:30
| Re: graphics area problem
I just want to double-check that you didn't blindly copy the example POKEs I mentioned, but rather adjusted them to what your program's length is (based on the explanation). Could you confirm that?
|
|
Posted By
Andras
on 2025-03-01
09:52:05
| Re: graphics area problem
Yes
|
|
Posted By
Csabo
on 2025-03-01
10:08:23
| Re: graphics area problem
Well, it's near impossible to guess what's in your code, and without seeing that I don't have any other immediate suggestions. You can send me your program in a PM and I'll take a look, if you like.
|
|
Posted By
MMS
on 2025-03-01
10:48:15
 | Re: graphics area problem
So, as we do not want to save the loaded program (just run and use), we can set the BASIC end very high too, like $7000?
Any possible side effects?
(BTW initially I supposed the GRAPHIC command took away the $1800-$3FFF area from BASIC, and we loaded the main program with "",8, so the gfx area kept us away from the area above $1800
But creating a program with $4000 start and "",8,1 did not solve the problem, frankly speaking it became worse. :-) That why we need a little technical support.
Thanks yof the hints!
|
|
Posted By
Andras
on 2025-03-01
11:34:36
| Re: graphics area problem
I messed up the address. It's good now. @Csabo @ MMS thank you
|
|
Posted By
Csabo
on 2025-03-01
12:51:19
| Re: graphics area problem
[...] we can set the BASIC end very high too, like $7000? Any possible side effects?
If your program is longer than $7000, then that won't work  Another thing to consider is 16K compatibility: if the program can fit under $4000, this would artificially make it 16K incompatible. Final (minor) side effect: less free memory for variables (but in practice this should not be a real issue).
|
|
Posted By
MMS
on 2025-03-02
19:15:06
| Re: graphics area problem
I just saw the compiled version, it was 80 blocks, means 20KB, so even with some upgrades it will be below $7000
(right now it almost reaches $6000)
|
|
| |
Copyright © Plus/4 World Team, 2001-2025. Support Plus/4 World on Patreon |
