Locating blocks of memory in cc65

[danwinslow]

I want to reserve some blocks of memory in programs developed with cc65. I want 4 pages, page 6 through page 9 for instance. I am unsure what to do...any one have an idea how to lay down a block of 256 bytes at a specific location in C and have the compiler reserve space? I know how to build a pointer to an arbitrary location, but keeping the memory preserved is the issue.

[Wrathchild]

Hi Dan,

 

Are you writing in 'C' or in assembly?

I think the standard build model for the Atari assumes

that DOS is loaded, therefore all that memory is already

available to you.

 

In 'C' you'll need to define a pointer to the start of

your required memory area, and in assembler you

can either use a define, or alternatively you can

use a customer linker configuration file to declare

the blocks for you. I can probably dig up some

examples of this if required.

 

Regards,

Mark

Edited July 4, 2005 by Wrathchild

[danwinslow]

Hi Mark. Mostly C...I know how to define pointers and etc., but I am not sure how to reserve space from use at compile/link time. That is, setting up a particular page to have a particular block of memory loaded into it, that won't get written over later in the load or during runtime...I think I will be needing to investigate custom linker setups, as you mention. SO if you could post some linker examples that would be very helpful I think.

[Wrathchild]

Hi,

 

This was a little experiment I did to check that it was impractical

to write DLIs in C. VBIs could be OK, but really you're best of

using assembler for these .

 

However, it should give you an idea of how the configuration file

can be used to provide your memory blocks, segments can be

defined to reside in these memory blocks. Start with 1 per block

to keep things simple, but later you can use the .align statement to

provide addresses on boundries. It then shows how these can be

made visible to a 'C' program via a simple assembler file and

finally the C file gives examples of utilising the pointers.

 

Hope that helps, no doubt some of it could be done slightly differently.

 

Regards,

Mark

vbi_dli.zip

Edited July 4, 2005 by Wrathchild

[danwinslow]

Excellent, thanks!

 

I find it useful, when I need to use assembly, to wrap it in C with the asm() function. That way I can stick with relatively normal control of flow constructs for most stuff but still drop into asm when needed. A DLI function wouldn't be anything more than C in name only though, I would expect.

[Wrathchild]

http://www.atariage.com/forums/index.php?showtopic=67762

 

Check out also the Gauntlet ROM implementation on this Forum too.

Coding to cart is fun - but I haven't really tried doing 'C' work here yet.

I'd like too try it to see, but there may be some considerations that need

to be looked into with the way that CC65 is handling the heap/stack etc.

 

Has anyone else attempted this yet?

 

Regards,

Mark

[Shawn Jefferson]

This was a little experiment I did to check that it was impractical to write DLIs in C. VBIs could be OK, but really you're best of using assembler for these .

 

There's also the small matter that CC65 won't save any of the working zero page registers, so your interrupt routine can't use any C library routines anyway without crashing your program. At least that's my understanding.

 

You can reserve memory with CC65 in a couple of different ways (that I know of at least):

 

1. Use the heap functions (malloc and family) which adds a lot of overhead to your program.)

 

2. Reserve space with a custom linker config script (you may need to fill your exe file to get the memory layout you want at load time, or deal with the loading some other way.)

 

3. Do what I do and play fast and loose, and just declare a pointer to some portion of memory you know isn't used by your program, the C stack, the heap or screen memory.

 

Mark's way is probably the best, since the linker takes care of it all and warns you when a memory overflow occurs.

 

To the original question: the standard CC65 linker config script doesn't touch $600-900, but DOS exists in this area. There may be some issues with using CC65 programs without a DOS loaded though.

Edited July 19, 2005 by Shawn Jefferson

[danwinslow]

Well, depending on what you do, you could probably get away with a c function in an interrupt, at least as far as the ZP stuff goes. CC65 uses 23 or so locations, so you can also save/restore them and there's a call for doing so in the CC65 internals. The actual function call mechanism itself doesn't touch any ZP, but the body of most functions does.

 

1. Actually, overhead from usage of these functions is only bad if you constantly call them. Using it to get a few blocks here and there during initialization is negligible. Then again, in this environment they really don't do much for you other than keeping you from walking on your own memory...they have no knowledge of any other "reserved" areas besides their own.

 

2. Yah this is the way to go I think.

 

3. Nah........I need to be more careful than that with the app I am doing. It'll drive me crazy later if I don't.

 

page 6 is clear even with dos loaded, isn't it?

[Shawn Jefferson]

1. Actually, overhead from usage of these functions is only bad if you constantly call them. Using it to get a few blocks here and there during initialization is negligible. Then again, in this environment they really don't do much for you other than keeping you from walking on your own memory...they have no knowledge of any other "reserved" areas besides their own.

 

I meant more the overhead in size.

 

3. Nah........I need to be more careful than that with the app I am doing. It'll drive me crazy later if I don't.

 

Programming is all about the challenge!

 

page 6 is clear even with dos loaded, isn't it?

 

Yeah, but that's only 256 bytes.

 

If you load your program without DOS somehow (via flashcart, etc...) then I think you could start your program at $400 (??)

[Wrathchild]

If you load your program without DOS somehow (via flashcart, etc...) then I think you could start your program at $400 (??)

Indeed, $400->$47F being the cassette/single density disk I/O block buffer.

 

I find myself retaining its use in the replacement I/O routines for carts, e.g.

copy correct 128 bytes from cartmem (when correct bank selected) to $400

and then swap out the cart and copy from $400 to desired destination address.

Though actually easier and quicker to shift 256 byte pages around instead,

this often retains compatability with the existing I/O routines found in games.

 

I also often find that using the end of the page 1 stack (i.e. $100 upwards)

is a great little holder for code snippets. If you know the stack isn't going to

go below say $180 then there's half a page free! I've haven't really looked

at CC65's hw-stack usage to know what's safe when writing in 'C' though.

 

Regards,

Mark

[Shawn Jefferson]

I also often find that using the end of the page 1 stack (i.e. $100 upwards)

is a great little holder for code snippets. If you know the stack isn't going to

go below say $180 then there's half a page free! I've haven't really looked

at CC65's hw-stack usage to know what's safe when writing in 'C' though.

 

I don't think it uses the hw stack that much, at least, not that much more than any other typical program would. The C stack is used quite a bit, of course, but that is in upper memory (under the screen IIRC.)

[danwinslow]

Thats right, page 1 is used is a normal manner. Parameters are passed on a 2k heap at the other end of memory.