Atari 800 cartridge for cc65?

[Harry Potter]

I am working on projects called MemXAtari and AtaDisk65.  MemXAtari provides access to the 1200XL's extra memory more directly than cc65's em drivers, and AtaDisk65 provides more direct access to the CIOV and disk access.  Both are in their alpha stages and have yet no significant functionality.  I have a project for Vic20 and C64 programmers to help create cartridge images using cc65, and I want to do the same for the Atari 800.  Is this support already available?  If so, where can I get it?  If not, where can I go for information on creating an Atari 800 cartridge image?

[Wrathchild]

Save yourself some time as cc65 caters for this already which kinda indicates that, despite being ask to, you don't read the docs.

https://cc65.github.io/doc/atari.html

Support for which would have been derived from knowing what the cartridge vectors and flags do which can be learnt from other docs you've been directed to, e.g. De Re Atari, Mapping the Atari etc.

[Harry Potter]

Sorry! 

[sanny]

Joseph,

 

please read the link in @Wrathchild's post from top to bottom. In chapter 4.1 there is one linker config file called "atari-cart.cfg", which is exactly what you want (create a cartridge image).

 

In general, considering your other posts, it appears to me that you are pursuing solutions for problems which don't exist (at least for the rest of us). And you seem to be immune against good advice.

 

I guess the best way forward would be to find a small, simple problem where you could implement a solution.

 

regards,
chris

[Harry Potter]

That is what I want, and sorry for asking stupid questions and not listening to reason.  I should have looked at cc65's docs first.   

[Harry Potter]

My projects aren't needed, but I believe my works might be useful to someone.  MemXAtari's job can be taken up by an em driver but provides more direct and easier access to the extra memory.  It provides string and memory functions to mimic the standard ones and functions to access any byte or word in the extra memory.

[sanny]

Could you explain your driver? Examples how to use it?

[Harry Potter]

I will try to explain my driver, but, considering TmpCreat, I probably will not be able to do a good job.  MemXAtari provides functions to access any byte or word in memory.  It also provides versions of the standard string and memory functions to access the extra memory.  For example, aux_memcpyto() would copy a memory block from main memory to the extra memory, while aux_memcpyfrom() will copy in the opposite direction and aux_memcpyin() will copy from one location in the extra memory to another.  Does this help?

 

BTW, What's the proper term for the Atari8's extra memory?

[sanny]

3 minutes ago, Harry Potter said:

I will try to explain my driver, but, considering TmpCreat, I probably will not be able to do a good job.  MemXAtari provides functions to access any byte or word in memory.  It also provides versions of the standard string and memory functions to access the extra memory.  For example, aux_memcpyto() would copy a memory block from main memory to the extra memory, while aux_memcpyfrom() will copy in the opposite direction and aux_memcpyin() will copy from one location in the extra memory to another.  Does this help?

 

Not really. How is it better than the existing cc65 driver?

 

3 minutes ago, Harry Potter said:

BTW, What's the proper term for the Atari8's extra memory?

 

Honestly, I don't know. Can somebody chime in?

Edited November 19, 2021 by sanny

[TGB1718]

Depends on what he means by "extra memory" is it the Banked memory at $4000 in the 130XE

or the memory that sits under the OS 

[Harry Potter]

TGB1718: The banked memory.

 

sanny: It is better in that it provides near direct access to the memory, almost as if it were regular memory.  The em drivers simply copy the memory to a buffer and copy it back.

[sanny]

15 minutes ago, Harry Potter said:

sanny: It is better in that it provides near direct access to the memory, almost as if it were regular memory.  The em drivers simply copy the memory to a buffer and copy it back.

Hmm. What is "near direct"? "Completely direct" would be "*pointer=value". "Near direct" could be something like "em_copy(void *dest, void *src, int len)". You didn't answer my question.

[Wrathchild]

Wouldn't the address space need to be 24 bit addressable (e.g. 20 for 1024K expansion) and from that the bank and offset be obtained, so a void pointer would not be enough there and so would use a 'far'.

[danwinslow]

From what I can tell, I think it's best to just help him along as we can, and not worry about whether he's doing something particularly productive or effective. That's just my 2 cents on the matter. What he's doing sounds duplicative to the em driver to me, but who cares.

 

Harry -

"Extra" memory-

1. Under the OS. Only on certain machines. This is just part of the 64k RAM address space.

2. Banked (or extended) RAM. This is any one of a variety of memory expansions, including the 130XE. 16K blocks mapped into $4000 by fiddling with PORTB. Axlon might be different, not sure, but same idea.

3. Unused memory. Regular RAM locations that are unused under certain circumstances. Printer buffer, cassette buffer, various FP bits and pieces, some ZP locations, etc., even under the stack if you are adventurous. Well documented over the years, but subject to a lot of variability depending on machine config.

 

 

[Harry Potter]

I thank you for your help.  MemXAtari has functions which take a void* and, if writing, the value to write, and, if reading, returns the memory location.  For example, aux_readbyte (void*) would read the indicated address in banked memory and return the byte there.  That's why I call it "near direct."