just below DL has free memory????

[+hloberg]

 

I started reverse-engineering the BASIC stock market game Millionaire. reason for redoing is that it's sloooooow. it takes 15 minutes just to initialize. and if you try running under anything but plain Atari BASIC it blows up.   But, maybe, I may now know why. it uses about 1500 bytes just below the DL list around 38740 for a high speed sort. I didn't even knew that area was even usable? I check the Compute! memory map and that area isn't even mentioned. could be maybe that area is moved abou in other BASICs? Anyone know something about this area?

 

Edited July 25, 2021 by hloberg

[Wrathchild]

Of course it is usable, assuming a 40K or 48K machine with Basic knocking 8K out of the latter, anything below $A000 is 'free' as the basic program and variables will consume memory upwards. E.g. you're not constrained to have your dlist and screen memory at the top, that is just convenient as the graphics command is taking care of that for you.

[Rybags]

Ram just below DList can be used but it's not documented because you're not really supposed to use it.  Any subsequent screen open to a mode that uses more memory can wipe it.

Growth of the program or variable/string space can wipe it.

Many other systems put strings at top of Ram then they grew downwards which avoids having to move things around when growth occurs.  We can't do that since there's variable sized screen depending on which graphics mode is used so Atari Basic puts the strings and variables after the program and just moves things if extra lines are added.

 

For something like a character set it's not a big problem if it's wiped when another graphics mode is started since the pointer is restored to default anyway.  And generally the programmer will know that in such a case a custom chset will need to be re-established.

[+hloberg]

1 hour ago, Rybags said:

Ram just below DList can be used but it's not documented because you're not really supposed to use it.  Any subsequent screen open to a mode that uses more memory can wipe it.

Growth of the program or variable/string space can wipe it.

 

which is probably why trying to run under Altirra BASIC or TBXL makes it crash as it changes the memory amount slightly.

I'm going to take it out an replace it with BASIC code since my goal is to BASIC compile the whole thing anyway.

thx for the explanation.

[phaeron]

5 hours ago, hloberg said:

which is probably why trying to run under Altirra BASIC or TBXL makes it crash as it changes the memory amount slightly.

I'm going to take it out an replace it with BASIC code since my goal is to BASIC compile the whole thing anyway.

thx for the explanation.

If you soft-load Altirra BASIC from disk, then it has to load 4K lower to avoid getting overwritten by a bug in the OS screen editor. That can cause the problems that you describe, as it sounds like the program may be hardcoding the address of the screen. However, if you run it from a cartridge ROM, then it will have the same documented memory layout as Atari BASIC, as it intentionally matches that for compatibility reasons (there are some games that are extremely tight on memory).

 

[+hloberg]

9 hours ago, phaeron said:

If you soft-load Altirra BASIC from disk, then it has to load 4K lower to avoid getting overwritten by a bug in the OS screen editor. That can cause the problems that you describe, as it sounds like the program may be hardcoding the address of the screen. However, if you run it from a cartridge ROM, then it will have the same documented memory layout as Atari BASIC, as it intentionally matches that for compatibility reasons (there are some games that are extremely tight on memory).

 

I use the disk Altirra BASIC. Bet also TBXL also works the same way.

also, Altirra is awesome! thx

Edited July 26, 2021 by hloberg

[Wrathchild]

Are you importing the listing (ENTER) or loading the tokenized basic file (LOAD)? Reason being is IIRC all the basics tokens might not align and so could causes errors.

[+hloberg]

4 hours ago, Wrathchild said:

Are you importing the listing (ENTER) or loading the tokenized basic file (LOAD)? Reason being is IIRC all the basics tokens might not align and so could causes errors.

They tried to hid the variable names by giving the names graphic chars. so I ran it through a program to rename and map all the variables that cleaned it up.

[+hloberg]

OK this is either some sort of copy protection routine, and if it is it's a dumb one, or they were just being lazy. The program checks if their sort assembler program loaded proper but if it doesn't the do a ? USR(0) which seems to just lock up the computer. A nice error "MEMORY CONFLICT, PROGRAM CAN NOT LOAD" might been better then just locking up the computer. Or are am I missing something.

Here's the line:

625 IF DL$<>"RUN" THEN ? USR(0)

DL$ is the 1st 3 bytes of their sort assembler routine which should spell RUN.

 

[phaeron]

8 hours ago, hloberg said:

OK this is either some sort of copy protection routine, and if it is it's a dumb one, or they were just being lazy. The program checks if their sort assembler program loaded proper but if it doesn't the do a ? USR(0) which seems to just lock up the computer. A nice error "MEMORY CONFLICT, PROGRAM CAN NOT LOAD" might been better then just locking up the computer. Or are am I missing something.

Here's the line:

625 IF DL$<>"RUN" THEN ? USR(0)

DL$ is the 1st 3 bytes of their sort assembler routine which should spell RUN.

AUTORUN.SYS, which sets this signature, reads sector 719 on the disk and crashes the computer if it doesn't start with $01 02 03. This sector is not marked as used in the VTOC. So it is a copy protection mechanism, though extremely weak as it practically only defeats the DOS 2 disk copier and AUTORUN.SYS sticks out as a sore thumb that's small enough to hand disassemble.

Edited July 27, 2021 by phaeron

[+hloberg]

8 hours ago, phaeron said:

AUTORUN.SYS, which sets this signature, reads sector 719 on the disk and crashes the computer if it doesn't start with $01 02 03. This sector is not marked as used in the VTOC. So it is a copy protection mechanism, though extremely weak as it practically only defeats the DOS 2 disk copier and AUTORUN.SYS sticks out as a sore thumb that's small enough to hand disassemble.

OK that makes sense. thx.

[+hloberg]

Question: wouldn't it been a lot safer to just move RAMTOP to have gave a 1k area for a sort then uses the area below DL, which was a no-no? it's been years since I did my last Atari Assembler but I do remember moving RAMTOP a thing.