Jump to content

danwinslow

Members
  • Content Count

    2,892
  • Joined

  • Last visited

Posts posted by danwinslow




  1. 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.


  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.


  3. 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.


  4. 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.


  5. Hmm, well, I'll have them 'speak' to your neighbor too. Anybody in flip flops, I'll say, and their little dog too. Then they will look at me in silence, and it'll feel awkward, and I'll pause a moment and then loudly say "FRIP FROPS", and they will nod excitedly amongst themselves. Then they'll trot off somewhere...burger king first most likely, then kill everyone in flip flops for a forty block radius. 

     

    All that aside, sorry you're going through this kind of irritation, and I hope it passes quickly. Be well.

    • Like 1

  6. All in all, I'd recommend MadPascal for this. Not that the other solutions are incapable, far from it, but MP is really powerful, fast, high level, and single executable. Fastbasic sounds good too, but I've no experience with it.

    • Like 1

  7. I have been working on re-assembling a Falcon recently. It worked at one point, but later when I went back to do some more it now seems to have trouble generating a video signal. Here's a picture of what I get. It has nothing in it but a known working 14MB Wizztronics board and the power supply. That's it. Keyboard, internal floppy and hd all disconnected. Any ideas? Tried a few different monitors, som esaid "out of range", some showed this same pic. For all I know, the VGA adapter plug has gone bad but I doubt it.

     

     

    20210223_202133[1].jpg


  8. You're using a much later version that I did, but just a -l on the cl65 command should do it. You have a -Wl, but I don't see just the -l. I am not familiar with --listing, they must have added that one (or I ignored it it for the shorter form). At any rate I did not have issues using mixed .c and .s files with output listings.

×
×
  • Create New...