Jump to content

kliepatsch

Members
  • Posts

    203
  • Joined

  • Last visited

  • Days Won

    5

Community Answers

  1. kliepatsch's post in Average amount of 6502 instructions per scan line, does my calculation make sense? was marked as the answer   
    I think you are on the right track. You have got 8 million / 60 cycles per frame, that would be 133.333. When doing such estimates, I usually counted cycles, not instructions.
    As soon as you know what kind of game logic you want to do for every object, you can start prototyping the most costly algorithms that are required for these updates, and count the cycles that are required for these algorithms. Add a bit of extra, depending on how much logic you intend to have, and you have got yourself a first rough estimate of how many cycles you need to update an object.
    For example, suppose you find that you cannot get around doing two multiplications while updating an object. Start prototyping the multiplication routine. Let's say it uses 200 cycles on average, so that you have 400 cycles for the two multiplications needed for each object. Let's say you need a fair bit of extra logic/code for the object update, so let's assume 250 more cycles. So your total estimate would be 650 cycles per object.
    This lets me arrive at 133333/650 = 205 objects.
  2. kliepatsch's post in Average amount of 6502 instructions per scan line, does my calculation make sense? was marked as the answer   
    I think you are on the right track. You have got 8 million / 60 cycles per frame, that would be 133.333. When doing such estimates, I usually counted cycles, not instructions.
    As soon as you know what kind of game logic you want to do for every object, you can start prototyping the most costly algorithms that are required for these updates, and count the cycles that are required for these algorithms. Add a bit of extra, depending on how much logic you intend to have, and you have got yourself a first rough estimate of how many cycles you need to update an object.
    For example, suppose you find that you cannot get around doing two multiplications while updating an object. Start prototyping the multiplication routine. Let's say it uses 200 cycles on average, so that you have 400 cycles for the two multiplications needed for each object. Let's say you need a fair bit of extra logic/code for the object update, so let's assume 250 more cycles. So your total estimate would be 650 cycles per object.
    This lets me arrive at 133333/650 = 205 objects.
  3. kliepatsch's post in Kernal SAVE always fails was marked as the answer   
    I personally have not used the Kernal's SAVE routine, rather only sequential file writing using CHROUT into a file. And I have gotten that to work only with SD card images. Since LOAD, however, does (somewhat) work with the host filesystem, it's not obvious to me why SAVE shouldn't also work.
    What is the string that you are passing to the SAVE routine? Does the file you are trying to write to already exist?
     
    Edit: just saw it, "savegame.bin"
     
    When saving files with the CHROUT method, I pass "@0:savegame.bin,s,w"
    The @ symbol says that any existing file with that name should be overridden. The ",s" says that it's a sequential file (not sure if that applies if you are SAVEing) and ",w" to tell the drive that I intend to write to the file. I don't know if any of this is necessary when using SAVE, but hey, more options to try out 😉
    Edit 2: is the filename string residing in RAM bank 1? If so, I could imagine (according to what Ed Minchau said) that SAVE tries to read the filename but it is not there since it is reading from bank 0 instead. So you would need to put the file name into main RAM.
  4. kliepatsch's post in Loading Programs from SD Card Image was marked as the answer   
    Hmm ... I don't know which programs you are referring to. There are two different types of loading files. One, where the target address from the .BIN file (the first two bytes) is used, and another one where the program itself decides (at runtime) where the program is loaded in memory. The latter is known to be broken in the latest official emulator (R38) when trying to load from an SD card, unfortunately. It could be the case that your programs are trying to load files that way and therefore do not succeed.
     
    That red spot in the top right typically indicates disk activity. From what is known about that emulator bug I could imagine that your programs are suffering from it. The file is loaded at address 0, and depending on how large it is, the program that is running gets overridden, causing the X16 to crash. If that's the case, I'm afraid that at the moment, you cannot use those programs from the SD card.
     
×
×
  • Create New...

Important Information

Please review our Terms of Use