# kliepatsch

Members

203

• #### Days Won

5

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.