Re: BASIC OS for the PC

Hello,

* On Thu, Dec 22, 2016 at 09:28:39AM +0200 Marko Mäkelä wrote:
> On Wed, Dec 21, 2016 at 08:08:24PM -0500, Ethan Dicks wrote:
> >In the case of BASIC, there are no objects and no calls to malloc().  What
> >is recovered is formerly-used string space.  If you say A$="foo" and later
> >say A$="bar", the string storage just grows downward, leaving both 'foo'
> >and 'bar' in memory, but only one live pointer.
> 
> Sorry for nitpicking, but I was under the impression that when strings are
> assigned to literals in the BASIC code, the pointers would point directly to
> the BASIC program area:

You are absolutely right. As long as you use string literals, CBM BASIC
uses the literal in the program memory instead of allocating memory
space in the string area. Obviously, this is a shortcut to reduce memory
usage.

However, if you do A$="FOO"+"", then the rules change.

 
> I guess that in direct mode (entering the above without the line number),
> storage for both strings should be allocated.

Yes, it is.

 
> On a somewhat related note, I wonder if anyone else has run into the
> following:
> 
> 1. Hit the STOP key to interrupt the execution of a BASIC program.
> 2. The BASIC interpreter reports the line number where it was interrupted.
> 3. Input some invalid statement (for example, trigger a syntax error)
> 4. CONT (will be refused with an error, due to step 3)
> 5. GOTO (The line number in step 2)
> 
> The execution appears to continue just fine with the GOTO statement, with
> all variables intact. Why was the CONT refused? What would the GOTO do
> differently from the CONT if we assume that the line consists of a single
> statement?

As soon as you change a line (which can also mean that you "confirm" a
BASIC line by just pressing ENTER) or getting an error from BASIC, CBM
BASIC refuces to continue.

This is also true if the error is generated from the BASIC program
itself, not in direct mode. Why? Most probably, because CBM/MS thought
that it might be a bad idea to continue after an error. Obviously, they
did not think about ON ERROR RESUME yet. ;)


> Another fun phenomenon is the LOAD statement. When used in a program, it
> seems to preserve the variables, but it will apparently cause the equivalent
> of GOTO to the first program line, even when the LOADed program did not
> replace the currently executing one. You all probably have seen a loader
> written in BASIC that uses a status variable like this:
> 
> 10 IF A=0 THEN A=1:LOAD "PART1.PRG",8,1
> 20 IF A=1 THEN A=2:LOAD "PART2.PRG",8,1
> 30 IF A=2 THEN SYS49152
> 
> I wonder what would happen if you did some string manipulation and then
> loaded a program that would overwrite some of the string storage. In the
> best case, upon completing the LOAD statement, the BASIC interpreter would
> report ?OUT OF MEMORY  ERROR because the end of the BASIC program area would
> now exceed the start of the string space.

No, it does not report an ?OUT OF MEMORY. When progammatically using
LOAD, the BASIC start and end pointers (43 - 46 on the C64) are not
manipulated at all. You can use it to load ML code (like above in your
example), but you can also use it to generate a BASIC program that loads
some overlays.

You have to make sure that in the first part, you reserve more memory
for the program code than the biggest part uses, though, in order not to
overwrite the variable area. (POKE 45,...:POKE 46,...:CLR on the C64).
BASIC will not recognise if you overwrite the variable area, which can
result in very weird errors. Of course, you can also use it to load
"pre-programmed" variables, if you like too. ;)

Regards,
Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/

       Message was sent through the cbm-hackers mailing list