Jump to content
IGNORED

MemXAtari for cc65: unused space issue


Recommended Posts

Hi!  I perused the Mapping the Atari etext for places to put extra code and data for a project to provide support for memory expansion to cc65 programs and am wondering if the directory buffer at $1401 is used every time a file is open or only when a program requests the directory.  I found a lot of unused space in the Atari memory map that I can use.  :)

Link to comment
Share on other sites

It's a complicated topic. Sometimes things are free and sometimes they aren't, depending on what OS and DOS you're using. If you're talking about the cassette buffer, yeah its mostly free usually. The big question is - are you writing like a driver that would be available across all combinations of OS and DOS (points to pile of Thom's hair on the floor), or just a program that runs just for itself?

Link to comment
Share on other sites

I am working on Atari 8 ports of Fields, Template Creator, MadLib, a memory enhancement and a special package for C programmers among other things.  Template Creator has to write to disk for all OSes but doesn't otherwise need to run on all OSes.  Fields is an UI and doesn't read anything from disk.  MadLib is currently split into multiple modules and needs to read from disk but doesn't need any particular OS.   The memory enhancement can fill its extra memory with files from the disk but can use ANSI C file functions.  Does this help?

Link to comment
Share on other sites

7 hours ago, Harry Potter said:

I'm wondering if the section of memory I mentioned is available and when and how it's available.

No. it isn't. You need to do a _LOT_ more study.

 

If you intend for this to run on the various FMS available for the Atari, you need to respect that you're probably not going to want to go below $2000. (and some FMS actually take a bit more than that, e.g. OS/A+ and DOS XL).

 

-Thom

 

Link to comment
Share on other sites

Harry, all due respect, but you might need to learn more about the atari target before you try this. You mentioned $1401, looking at it in Mapping the Atari says it's a disk directory buffer. If you have any kind of a DOS loaded, then no, it's not available. (DOS=FMS, for my purposes). Yes, typically the DOSes can read each other's files.

 

As Thom mentioned, there is very little that is 'safe' under around $2000 unless you want to specify 'only use with this particular DOS' or 'only use with out one'. If you tried really hard, you could find probably a few pages worth of memory that you can squirrel things away in below that address, but it would be hard and not particularly useful. Believe me, it's a subject that has had much scrutiny over the years. Page 6 is famously supposed to be free, but ironically, because of that, it often isn't. There's some bytes free if you aren't using a basic cartridge, there's a small amount of zeropage stuff and I've even used the top half of the program stack. The cassette buffer is also usually free.

 

You mention 'extended memory' - the atari has 2 sources of that. One is extra bank-switched RAM provided by the 130XE or upgraded older computers, the other is obtained via switching out the OS for 10k worth of RAM, which also doesn't work on every model, as far as I know, and has to be done carefully by stealing interrupts and swapping the system back in as needed.

 

As far as I know, there are already malloc implementations for CC65 that allow usage of extended memory. I know I wrote one for my own use, using a 24 bit bank number+address convention. It works ok, kind of slow on a byte by byte basis but if you have set of buffer locations somewhere in non-extended and you are smart about how you do things, it's not too bad. Many people just use entire banks (16k) to swap in and out, with the banks each having a particular purpose. Read up on $D301 in mapping the atari : https://www.atariarchives.org/mapping/appendix12.php

 

 

Edited by danwinslow
  • Like 1
Link to comment
Share on other sites

As @danwinslow says, lots of FMS can read/write to others, the one that's probably incompatible is OS/A+ and

maybe Atari DOS 3 (although I don't think anyone uses that any more)

 

Also some DOS'es can read/write others, but the reverse is not true for example

SDX can read/write Atari DOS 2.0/2.5 but DOS 2.0/2.5 can not read SDX disks.

 

Atari DOS'es also can't read/write DD disks either.

 

There are probably other incompatibilities, but I don't know them all.

Edited by TGB1718
Link to comment
Share on other sites

20 minutes ago, TGB1718 said:

As @danwinslow says, lots of FMS can read/write to others, the one that's probably incompatible is OS/A+ and

maybe Atari DOS 3 (although I don't think anyone uses that any more)

 

 

Afaik, the Atari DOS versions DOS 3, DOS 4 and DOS XE are only compatible with themselves (also OS/A+ V4.x) - I would avoid using them.

 

If you require a DOS with a very low memlo, DOS2XL (not to be confused with DOS XL!) has a memlo of $0794 - but it uses RAM under the OS and will therefore only work with computers with a min. of 64k RAM. DOS2XL is also limited to 90k and 130k formats and I do not remember if it supports a ramdisk (I think it does not, it is compatible with the DOS 2.x format however).

 

There is also LiteDOS 2.x and 3.x by Mr. Atari. The standard versions have a memlo of $1000 and do not use RAM under the OS. There also exist some special versions named LiteDOS-XS and LiteDOS-RO that have an even lower memlo. The standard LiteDOS does support a ramdisk (via external ramdisk-driver).

 

Last not least, there are some 3-sector (bootsector) "DOS" versions like uDOS (memlo $0937), XBootDOS (memlo $0980) and others. They do have lots of restrictions and limitations, but if you only want to load a BAS or ML file, they are good enough for this purpose. They do not support a ramdisk (or XRAM) and saving is restricted to overwrite already existing files, etc.

 

The disadvantage of all these small-memlo DOS versions and files running with/under them is the fact, that those files will most likely not run under DOS 2.0/2.5, MyDOS, SpartaDOS, SDX, et. al. and/or harddisks, ultraspeed devices, etc. anymore (and this will most-likely upset some Atarians).

 

DOS2XL.zip UDOS.zip

Link to comment
Share on other sites

Template Creator Atari8 is supposed to use a lot of RAM to hold a template file.  The CBM versions use a lot of the OS memory that is not used during a cc65 program.  The Atari8 version needs to work on at least 64k and target most OSes but can run under any OS with good support.  I also want to use the Atari8's unused memory for extra code and data.  MadLib is to also use the extra memory for code and data but only needs to load a few files on start-up.  Any DOS would be fine.

 

BTW, does cc65 support DOS2XL?  I'm using mainly cc65 to program on 6502-based computers.

 

One more thing: where can I find the Atari OSes?

Link to comment
Share on other sites

The "OS" means operating system, and that is separate from DOS (Disk operating system). The OS is ROM, generally, and does not directly support writing files to disk drives like a DOS does. You need a DOS for that, there's lots of them, all with different memory usages below around $2000.

 

There are really only a few variants of the OS roms, and you can google for Atari OS roms if you want more info. It's 10k-ish of rom. As I said, you can swap it out if you want and use the memory beneath it but some of the DOS's (Disk operating Systems) already do that depending on settings. Sounds like DOS2XL does that, from this thread : 

So, a DOS loads disk device handlers to support calls. An FMS is kind of the same thing as DOS, sometimes it's a separate part but mostly it's all one and the same thing. I usually take 'FMS' to mean the user interface for the DOS and the DOS itself to be the device handlers. Anyway, nobody uses the FMS term much nowadays.

 

CC65 does not support DOS2XL in particular., as far as I know. It does not support any DOS in particular. It's up to you to arrange things so you don't stomp on memory used by the DOS. Read up on how to set your program org and so forth in CC65. If you want to do file IO in CC65, you can either use stdio.h calls, or you can write your own calls to the resident disk handler (meaning the DOS) using the IOCB's and CIO calls. If there are drivers loaded for disk (meaning you've got some kind of DOS loaded), then you should be able to call the driver with either method. I don't know a whole lot about DOS2XL, so, I can't say for sure.

 

There really isn't much 'unused memory', is what we've been trying to tell you, other than what is being used by the OS, the DOS, and your program. If you decide to use one particular DOS, then you can tailor it to that. There are maybe a k or two you can scrounge up if you work at it in low memory in non-contiguous pieces. You can find out more in this thread, which I found using search : 

So, you can educate yourself and scrounge up some stuff from low memory, or you could use extended memory, or you could swap out the OS. It all depends on what you want to do, who the intended audience is, and what the use case is. Most people writing things that need a lot of memory do things like write a custom file driver or use a very low footprint DOS, punt the OS and just take the whole machine over.

 

 

 

 

Link to comment
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...