Problems with FFD5 CBM LOAD API in X16

JimmyDansbo · Post by **JimmyDansbo** » Sat Feb 06, 2021 9:24 pm

I only press F11.

Keep in mind that in my test code I do no setup what so ever, I just jump directly to calling FFD5 without caring what is in any registers. I could just as well just do a SYS $FFD5 from basic, but wrote a 1-line assembler program to be able to add the .byte $DB to start the debugger.

svenvandevelde · Post by **svenvandevelde** » Sat Feb 06, 2021 9:28 pm

2 minutes ago, JimmyDansbo said:

I only press F11.

Keep in mind that in my test code I do no setup what so ever, I just jump directly to calling FFD5 without caring what is in any registers. I could just as well just do a SYS $FFD5 from basic, but wrote a 1-line assembler program to be able to add the .byte $DB to start the debugger.

Can you try this with my program pls? You'll see immediately what it does. Using F11, it does not jump into 00:d949. It seems to go over it, and shows the next statement back at

SlithyMatt · Post by **SlithyMatt** » Sun Feb 07, 2021 12:35 am

When stepping through the Kernal, it is important to understand that the emulator doesn't work exactly the same as hardware. If you are using the host file system, LOAD and SAVE will use native file I/O on the host, so data just "magically" moves between the host file system and the emulator RAM. If you use an SD card image, you will be running the actual Kernal code to transfer data byte by byte through the CPU, rather than skipping over all that.

JimmyDansbo · Post by **JimmyDansbo** » Sun Feb 07, 2021 6:57 am

9 hours ago, svenvandevelde said:

Can you try this with my program pls?

I just testet with your program and saw the same behavior that you are describing. I then tested with one of my own programs (that work just fine) and saw exactly the same behavior as in your program.

I believe that Matt is correct and what we are seeing is the emulator going off and doing weird stuff because we are not loading from an SD card image.

Just to be on the safe side, I tried modifying my VTUI example program to load the binary into banked memory at bank 4 and that also seems to work just fine.

svenvandevelde · Post by **svenvandevelde** » Sun Feb 07, 2021 7:13 am

6 hours ago, SlithyMatt said:

When stepping through the Kernal, it is important to understand that the emulator doesn't work exactly the same as hardware. If you are using the host file system, LOAD and SAVE will use native file I/O on the host, so data just "magically" moves between the host file system and the emulator RAM. If you use an SD card image, you will be running the actual Kernal code to transfer data byte by byte through the CPU, rather than skipping over all that.

After a good sleep (I'm in Europe), I've also made an annotated video, showing you exactly what I'm doing, and what the issue is ...

https://streamable.com/usd5wn

Would you have any further thoughts why this is happening?

svenvandevelde · Post by **svenvandevelde** » Sun Feb 07, 2021 7:20 am

6 hours ago, SlithyMatt said:

When stepping through the Kernal, it is important to understand that the emulator doesn't work exactly the same as hardware. If you are using the host file system, LOAD and SAVE will use native file I/O on the host, so data just "magically" moves between the host file system and the emulator RAM. If you use an SD card image, you will be running the actual Kernal code to transfer data byte by byte through the CPU, rather than skipping over all that.

So in summary, it is impossible to show the code at 00:D949?

JimmyDansbo · Post by **JimmyDansbo** » Sun Feb 07, 2021 7:38 am

13 minutes ago, svenvandevelde said:

So in summary, it is impossible to show the code at 00:D949?

No, you just need to move your program and TEXT file into an SD card image and use that instead of using the host filesystem.

However, if the LOAD function returns to your program with a file not found error, it is probably because the file is not found.

I don't know about CC65, but I know that ACME sometimes has some strange behavior in converting from ASCII to PETSCII.

Try changing

Quote

char status = cx16_LoadFileBanked(8, "TEXT", loadtext);

to

Quote

char status = cx16_LoadFileBanked(8, "text", loadtext);

Assuming that "TEXT" is the actual filename your program is trying to load.

svenvandevelde · Post by **svenvandevelde** » Sun Feb 07, 2021 7:42 am

Just now, JimmyDansbo said:

No, you just need to move your program and TEXT file into an SD card image and use that instead of using the host filesystem.

However, if the LOAD function returns to your program with a file not found error, it is probably because the file is not found.

I don't know about CC65, but I know that ACME sometimes has some strange behavior in converting from ASCII to PETSCII.

Try changing

to

Assuming that "TEXT" is the actual filename your program is trying to load.

Just note that I have my code working ... Shall we get into the real problem what I'm having and maybe we can find out what the error is?

I'm able to load the graphics into my program correctly, but I have a strange error. "sometimes it loads, and sometimes not".

The random factor is the "order of the routines" and "what routines are not commented out". Trust me, looking for weeks on this, and till today, cannot find the issue!

What I'll do, if you're okay to help me searching for the real issue, is to post the programs that I have in this thread, together with all the files.

I'll make a version that loads the files correctly, and one that does not load any file.

svenvandevelde · Post by **svenvandevelde** » Sun Feb 07, 2021 8:05 am

So, this is the working program ...

Just copy all these files to a single folder, and run the program ...

If you have all working, you should see the picture attached.

I've removed all breakpoints from the program. When a bitmap file is not found however, it will display an error on the screen.

char status = LoadFileBanked(8, FILE_SPRITES, (dword)BANK_PLAYER);