Jump to content

Search the Community

Showing results for tags 'file io'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Commander X16 Forums
    • Introductions
    • X16 Discussion Lounge
    • X16 Help & Support Lounge
    • The Lounge
    • Hobbies and Interests

Categories

  • Official Software
  • Official Docs
  • Community Downloads
    • Games
    • Productivity Apps
    • Graphics Apps
    • Audio Apps
    • Demos
    • Networking Apps
    • Dev Tools
    • Tutorial Apps
    • Misc Apps

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 3 results

  1. I have a file that exceeds the size of the memory of the system, so I can't load it all in at once. What is the way I could specify which part of it I load into memory? I've been looking at routines like MACPTR, but I can't seem to tell if there is any way to load the file in, not from the beginning of the file, but from a specific point in the middle of it. My only other thought is to use MACPTR and read until I get to my desired section and then finally copy that, but that solution seems clunky. Thanks for any ideas.
  2. Hello I am hoping that a genius can provide me with a simpleton’s guide to file seeking in C on the CommanderX16. I am porting the Meka Sierra AGI interpreter. I need to seek into the resource files by an index. I already have the indexes, now I just need to seek into the resource files. I must admit that I am very confused. I read this post here: https://www.commanderx16.com/forum/index.php?/topic/3330-adventures-in-file-io-and-commander-x16/#comment-20462 The author defined a method of signature int8_t cx16_fseek(uint8_t channel, uint32_t offset) However here are the problems that I have: 1. I don’t know how to correctly provide a first argument 2. As the files I need to seek into are up to 200kb in size I am worried that the function may not correctly handle RAM bank switching as the authors note Here is the Meka code I need to port, note the use of ‘fseek’ which I know is not supported. if ((fp = fopen(location->fileName, "rb")) == NULL) { … } fseek(fp, location->filePos, SEEK_SET); fread(&sig, 2, 1, fp); … volNum = fgetc(fp); byte1 = fgetc(fp); byte2 = fgetc(fp); AGIData->size = (unsigned int)(byte1) + (unsigned int)(byte2 << 8); AGIData->data = (char *)malloc(AGIData->size);
  3. I think I'm trying to learn on too many fronts at once here, and I'm starting to go blind on the information I'm trying to absorb - lol.... So reading a file into RAM,VRAM,HIRAM is relatively straightforward using kernal calls. However, I'm a stubborn guy and I don't like the idea of having to pad my files with 2 dummy bytes because of the assumed PRG header, especially when the Kernal easily ignores these and loads the file wherever you tell it to. So I'm trying to write my own loadbin() function that will actually read the first two bytes of the file by using OPEN, CHKIN, and CHRIN. My code is as follows: However, the data I get back seems like some random byte repeated however many times I do cbm_k_getin(); The values returned by cbm_k_open() and chkin(0) are 172, and 3. I'm trying to track down what those return values mean, but just in case I'm doing something dumb and one of the wizards here can easily point out my folly, I thought I'd post here while I keep digging on my own... My understanding is that the first zero in setlfs is just the "file handle ID" - I could make it be 7 or 3 or whatever, so long as it isn't already in use elsewhere, and I'm consistent in chkin() and close(). I also think the second zero in setlfs() "extra address" that gets all the nuance of what the kernal will do.... and this is still kind of opaque to me - ... so, is this a fool's errand? Will CHRIN also skip the first two bytes of a PRG file, or does this seem like the way to achieve my goal? (edited to add: I'm using the host FS and not SDcard images)
×
×
  • Create New...

Important Information

Please review our Terms of Use