danwinslow
-
Posts
3,034 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by danwinslow
-
-
Well. Can't help with the hardware side directly, but I'd sure put some money up.
-
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.
-
Yes, CC65 supports automatic access to passed in variables. Look at the ASM keyword. RTFM, in other words
-
On 3/12/2021 at 4:15 PM, Kaj de Vos said:
I am disappointed that this out-of-control complexity has found its way into Atari 8-bit. Eventually this will need to be solved with a native Atari backend, but for now, I need to develop the cross-platform C generator.
No offense intended, but just because you don't understand what's happening does not mean there is 'out-of-control' complexity. CC65 has exactly the boilerplate it needs to generate in order to work correctly in all situations. Plus, as Wrathchild mentioned, when you use stdio.h functions you get stdio library pulled in. That is not unreasonable.
-
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
-
1
-
-
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?
-
wondering that myself, I thought Rapidus was kind of a cool device.
-
Yep, sounds like you know what you're doing. Keep us posted,
-
why wouldn't they work in byte array elements? That seems odd.
-
Yeah, moving it to FB would be a much better experience for you I think. CC65 and C language port would be a lot more technically intensive.
To answer the stack question - the parameters for a function call, generally speaking, are stored on the C memory stack, which is not the same as the system call stack. Small calls like void foo( char a,x,y ) can be made to show up in the registers...using fastcall I think? I forget exactly, but its something like that.
-
Probably missing the point, but...of course, since you commented out the close?
-
1
-
-
Rapidly looping through all of the screen modes was never a use case I tried...there may be some subtleness going on with that aspect.
-
For this particular subject, you can use a command line setting, but I highly recommend looking at the linker config file stuff.
CC65 is very config-file dependent. You won't get far unless you learn at least the basics of the linker config stuff. The payback for this is that CC65 is extremely flexible and powerful, providing full control over all aspects of memory placement and linking operations.
-
1
-
-
This sounds cool to me. Would there be general purpose slots...so for instance, for expansion? Or do I not understand...this is likely.
-
106 6A RAMTOP
RAM size, defined by powerup as passed from TRAMSZ (location
6), given in the total number of available pages (one page equals
256 bytes, so PEEK(106) * 256 will tell you where the Atari thinks
the last usable address --byte-- of RAM is). MEMIOP (741,
742; $2E5. $2E6) may not extend below this value. In a 48K Atari,
RAMTOP is initialized to 160 ($A0), which points to location
40960 ($A000). The user's highest address will be one byte less
than this value.
From https://www.atariarchives.org/mapping/memorymap.php#106
Lots of other stuff in there to look up if you wonder about peeks and pokes.
-
I have an old USB cart too. I tried looking at writing an atari-side USB client for an ethernet adapter and it made my brain explode. Complicated stuff.
-
2
-
-
Yes, I was not including the size of any compiled programs he loaded himself - that is definitely part of the equation, but also partly why I recommended he just set up his own data area in fastbasic and load into it. If you really need to store outside of fbasic, then lowering the top memory pointer by the amount you need (after screen is established, depending on how you do that), is usually what's done. That will sort of protect it from other things. You then binary load to to that address and above, taking care that you've left enough space so you don't blow you screen/dlist info, again, depending on how you've done the screen. If you let the OS do your screen via like a 'graphics 7' call, then it will be packed nicely above everything at the high end of memory, if I recall correctly.
-
The topic of free memory is complicated, generally speaking though everything between the top of the DOS you have loaded ($2000 is a safe bet) and the bottom of the screen data (depends on you and how you set up your screen)/OS code. There's a couple of memory locations that track the low memory top and one for the high memory top, although that one is somewhat flexible).
For your purposes, its probably not the right idea to think 'Now I have to squirrel away my level data somewhere safe'. I would suggest rather you make an area big enough in fast basic via an array or dim or whatever, and then just load your data to that address.
For the file you may have to take care of items such as "endianness" (which byte is most significant in a two-byte word). You would probably have to write a converter that swapped bytes, for instance. Depending on how you loaded your data in your original program (raw bytes? cr/lf terminated lines? etc.) you may need to do other things. Actually loading the data is a matter of using the fastbasic facilities for IO (if there are any, I don't know) or use the OS IO routines, which is a matter of setting up a few addresses and calling 3-4 OS routines.
-
If sheer speed is necessary, best to consider CC65 C as a very advanced macro assembler
-
Hehe, posting a technical question on this board is like waving a raw T-bone in front of a pack of hungry wolves. Smart ones.
-
1
-
-
You are all totally wrong. Discuss.
-
6
-
-
I think he means things like size, date, etc. He might also mean permissions, but of course most 8bits are anarchy in that department. It's an interestig question though - do any 8bits have anything like file ownership and individual r/w permissions?
Going OT because I can and the OP has already said he has quite enough info/
5 hours ago, ilmenit said:In CC65 there is one more intermediate layer between C functions (like fopen, fread etc) and OS routines:
#include <fcntl.h>
with functions such as open, read, write etc. - they are smaller variants of the fXXX functions.
Yep, true, and that's actually part of the base C library on any box, which is why I lumped it all in together.
-
Well, you could use the usual C suspects such as fopen, fread, fscanf, etc.. Or you could go down 1 layer to the CIO routines, which involves filling out a memory structure and calling a few OS routines. See De Re Atari and/or Mapping the Atari for more info.
-
Yes, the derail has absquatulated, if you'll pardon the anthropomorphization.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
FastBasic 4.5 - 2021 release
in Atari 5200 / 8-bit Programming
Posted · Edited by danwinslow
this is the good part of CA65's complexity