Jump to content
Harry Potter

Why won't Low Memory work on cc65 program?

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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?

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

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 by danwinslow
  • Thanks 1

Share this post


Link to post
Share on other sites

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


 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

image.thumb.png.c441c5c2cfc0e169c4a0357e62d40ce9.png

 

Work it out?!

 

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

 

 image.thumb.png.f1abc9edbc6e18494d7cbe7cd1c98c9d.png

 

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 by Wrathchild

Share this post


Link to post
Share on other sites

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? 

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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 by Wrathchild
  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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 by ivop

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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. :D

 

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.

  • Like 1
  • Haha 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...