Why won't Low Memory work on cc65 program?

[Harry Potter]

Hi!  I have an issue with MemXAtari, and you should already know this: stubs loaded into the Atari8's Low Memory area don't work: they crash the emulator.  I attached two files responsible for the loading, but the lines in question have been disabled.  

atarixl_memx.cfg crt0.s

[danwinslow]

People are probably going to want you to post all your code, along with the .lst and .map files, as they have mentioned in the past.

[TGB1718]

4 minutes ago, danwinslow said:

People are probably going to want you to post all your code, along with the .lst and .map files, as they have mentioned in the past.

My thoughts too, no good posting bit's and pieces as it doesn't make sense until you have it all.

[Wrathchild]

Also I get the impression you still might not get what is responsible for loading what, i.e. part of the constructed binary file being loaded or something that binary file is loading. As you are focusing on config and system sources then the presumption is the former, which tends to indicate the binary headers are wrong, so have you checked with the tools that inspect that or simply use Altirra with debugger open and launch the file.

[Harry Potter]

I'm sorry about giving only pieces of my code.  I thought that was all I needed.  Maybe I'm better off asking how to load a piece of an Atari 8 program into a specific portion of memory.

[Wrathchild]

 

You need to ask the right questions

[sanny]

6 hours ago, Harry Potter said:

I thought that was all I needed.

That's almost never all that's needed. How often did people tell you to post the complete project? Why can't you learn?

[Harry Potter]

I attached the whole project, but the lines in question have been disabled.

bank1.zip

[danwinslow]

So....which are the lines in question, and why are they disabled? When you post something, the people you are asking help from should be able to compile and run and re-create the error. Don't make them have to guess. You are asking for people's time and effort, so you should set them up to be able to re-create the error.  

Typically, you should:

 

1. Create an example that exhibits the error

2. Include information about how to compile and run

3. Post everything required to do the compile and run

Edited October 7, 2021 by danwinslow

[Harry Potter]

I reenabled the lines and attached the project here.  The problem is in the XBUF_ memory area.

bank1.zip

[Wrathchild]

Same issue as before, you first need to make a valid executable!

EXE: Loading program 0006-0196 to 2E00-2F90
EXE: Loading program 019B-019C to 02E2-02E3
EXE: Jumping to 2EA3
EXE: Loading program 01A1-03FB to 2508-2762
EXE: Loading program 0400-0401 to 02E2-02E3
EXE: Jumping to 2508
ERROR: Invalid Atari executable: bad start/end range.
EXE: Launching at 2E00
CPU: Illegal instruction hit: 6E66
(2555: 82, 32) A=40 X=20 Y=00 S=F7 P=32 (    Z )  6E65: 00                BRK

 

 

[Harry Potter]

How do I create a module header?  Maybe I'm doing that wrong.

[Wrathchild]

Homework for the reader... examine the autorun.sys in a hex file and understand the layout in relation to what the header segments are doing.

They are not complicated, just a word-pair of start and end addresses. As multiple blocks are present then a valid header needs to be at the end of the data.

[Harry Potter]

Is the end address the last used byte or one more than the last used byte?

[Wrathchild]

 

Work it out?!

 

Start is $2E00 and end is $2F90 so the difference is $190.

 

 

 

The next header is at $197. So subtracting the initial header size of 6 gives us a block length of $191.

 

So, as has already been pointed out to you in another thread, the end address is the start address + data length - 1.

 

To confirm that, the 'init segment' about to be loaded loads 2 bytes from $2E2. So the end address is $2E2 + 2 - 1 which is $2E3.

Edited October 7, 2021 by Wrathchild

[Harry Potter]

I tried that.  The screen alternates between Error 138 and garbage. 

[Wrathchild]

We aren't psychic, what changes to the code is post #10 were those?

 

What the screen does against your expectations are not a great sign of any proper tracing / diagnoses on your part?

e.g. does loading the autorun.sys manually into Altirra still show the 'Invalid Atari executable' error or is that fixed?

If you step debug through from _main, how far do you get? 

[drac030]

How it is possible that cc65 compiler/linker/whatever can produce invalid binaries without even a warning?

[Wrathchild]

because he's rolling his own, the linker doesn't know what type of binary he is producing, could be a cart, but cc65 doesn't know that should be 8K, 16K etc or plus 16 bytes if you have a header, why should it?

Edited October 7, 2021 by Wrathchild

[danwinslow]

Harry, some friendly advice :

Stop trying to do something so difficult. You do not understand the Atari well enough yet. You need to read, thoroughly, all of the available documentation and try some smaller projects first.

[drac030]

21 minutes ago, Wrathchild said:

because he's rolling his own, the linker doesn't know what type of binary he is producing, could be a cart, but cc65 doesn't know that should be 8K, 16K etc or plus 16 bytes if you have a header, why should it?

Maybe providing some switch or even a template to the linker could help it to detect errors in configuration, just as a sort of safety checks. Then you could say to the OP: "add --std-executable to the linker switches and see what it says". This would stop the whole process at the stage where the executable cannot be created, and not at the stage when it is executed and crashes the system.

 

In assemblers you are on your own too, but it actually takes effort to convince an assembler to produce a messed-up binary, as the regular executable is usually the default.

[Wrathchild]

CC65 already caters for those and you simply state which config you want. The executable one also handles the headers for you.

[ivop]

And if you don't understand the linker config, just use the default. Then paste your low-memory block in between the init/run address(es) and the previous blocks in the generated binary. To load page six, for example.

Edited October 7, 2021 by ivop

[Harry Potter]

In truth, I don't really need this memory.  I just want it to be available to other programmers to increase the RAM available to a program.  I could just load it in from the disk, but the OS should be able to load it in place.

[drac030]

37 minutes ago, Harry Potter said:

I just want it to be available to other programmers to increase the RAM available to a program.

So you basically seem to think that you are the first one to discover the cassette buffer, the LBUFF and the sixth page, and just wanted to inform us that they exist? Well, how to put it gently, we sorta already had some intuition that they are there.

 

Second, I may be wrong, but you seem to believe that there is some other treasure of free RAM at $15A4, 348 bytes long. So let us lookup the source code of DOS 2.5: "$15A4 - the binary file loader". That is the code which loads and executes programs, incluiding your program. Overwriting it in the process probably would not help.

 

Of course, you do not use DOS 2.5, the problem is, that we have many DOS-es on Atari, so going below $2000 with your binary file is basically guaranteed to stomp on some DOS in some setup. That is why people who want to use as much memory as possible and to avoid a conflict with a DOS employ relocators and other means to do not overwrite anything below the low memory pointer (aka MEMLO); and SDX, which has that pointer particularly low by default, even employs own binary format to be able to load programs at MEMLO and do relocation/fixing-up in place.

 

49 minutes ago, Harry Potter said:

the OS should be able to load it in place.

The OS is perfectly able to load a binary block at $0400-$06FF or so. Your problem seems to be that you are not able to generate a valid binary file.