Problems with FFD5 CBM LOAD API in X16

Get technical support from the community & developers with specific X16 programs if you can't find the solution elsewhere
(for general non-support related chat about programs please comment directly under the program in the software library)
User avatar
svenvandevelde
Posts: 488
Joined: Wed Dec 23, 2020 6:30 am
Location: Belgium, Antwerpen

Problems with FFD5 CBM LOAD API in X16

Post by svenvandevelde »


Hi all,

I've been struggling for a couple of weeks now with the CBM API "loadfile" located at address $FFD5 ... I got some of it working, but the API seems to do some weird things, or it's me, or it's the compiler, or it's the emulator.

So I decided to make a demo program, that you can try out, and follow the below to simulate the issue ...

The program loads a TEXT file, reads it into banked memory (A000). The file contains the words "HELLO WORLD", and a 0x00 hex to end properly the string. This file is read using the cbm_k_load routine which is implemented in assembler.

The issue that I'm having is, I cannot seem to debug the rom of the x16. In one of my more complicated programs, the load file api seems to fail with error code 4, (file not found), but only when i have a lot of code added.

So, i wanted to debug the rom and see what is the issue, but that does not seem to work properly. So who can help out?

Please find the attached files load.prg,  TEXT. Put those in a folder, and start the X16 emulator from that folder using x16emu -prg load.prg -run -debug. I've also added the source code files  for reference: load.c and load.asm.

When you run the program, it will immediately jump into the debugger of the CX16, because in the call to the 


char status = cx16_LoadFileBanked(8"TEXT"loadtext)


routine, it will call the cbm_k_load routing, which has a STP opcode has been placed that makes the assembly break and boot up the debugger. (look at the .byte $db !).


char cbm_k_load(charaddresschar verify) {



    char status;



    asm {



        //LOAD. Load or verify file. (Must call SETLFS and SETNAM beforehands.)



        // Input: A: 0 = Load, 1-255 = Verify; X/Y = Load address (if secondary address = 0).



        // Output: Carry: 0 = No errors, 1 = Error; A = KERNAL error code (if Carry = 1); X/Y = Address of last byte loaded/verified (if Carry = 0).



        .byte $db



        ldx address



        ldy address+1



        lda verify



        jsr $ffd5



        bcs error



        lda #$ff



        error:



        sta status



    }



    return status;



}


 

Anyway, so when the program executes, you get this display:

image.png.33689ad5451bd50f8442b0832c52cec1.png

As you can see, the disassembly in the x16 monitor matches the assembly statements of the cbm_k_load routine nicely! Now we will try to debug the ROM API of the CX16, that loads the file ...

Using the X16 monitor, we will walk the assembler. We use F11 only, so this will make the JSR and JMP routines to follow and "jump into" each routine. Press F11 x 3 times. Now we get the following situation:

image.png.16180aabe501671ce8751b20feb6f573.png

We are right at the verge to call the "load file" API of the CBM kernal architecture. Let's do that, and jump "into" this JSR routine. Now you get this:

image.png.b15dbcefcdad30756a09101a1d73c0f6.png

You can see, we've landed at address 00:FFD5, which contains a vector jump to the actual routine that implements this load file. So here, we would expect to jump to address $D949.

Before we do that, let's first inspect what assembly is at address $D949! This is done using the x16 monitor command d $d949. Which seems to work nicely. We get the following result, but note that the program counter (PC) is still at FFD5!

image.png.5327c28266eab518c1fb629ee09bc72c.png

This disassembly matches very nice the ROM code that is programmed in the X16 ROM, which is located here:

x16-rom/load.s at master · commanderx16/x16-rom (github.com)

The disassemly shows the statements starting from the loadsp label in the assembly source code of the x16-rom load.s routine:

image.png.5a311fcd133f5c3d3a03fa53595b43df.png

...

Now comes the weird thing!

Now, we will step "into" the JMP statement, so we will follow the disassembly to routine D949! This does strange things in the X16 monitor, don't understand... We get this:

image.png.8cefda2fe2e50bc8f3dd2e1a4a5ee02a.png

tax ???? Where's the code? Where are the routines?

So my question is: How can we debug ROM code of the X16?

Would somebody be able to try and do the same, who has a solution to allow to debug the ROM of the X16?

Sven

 

 

 

KICKC home page by Jesper Gravgaard.
My KICKC alpha with Commander X16 extensions.
User avatar
svenvandevelde
Posts: 488
Joined: Wed Dec 23, 2020 6:30 am
Location: Belgium, Antwerpen

Problems with FFD5 CBM LOAD API in X16

Post by svenvandevelde »


Another issue with the LOAD API at FFD5... It seems to skip 2 bytes when loading a file!

How to resimulate:

1. reload the x16emu using x16emu -prg load.prg -run -debug .

2. Now we monitor the memory at bank 0, at address A000 using the x16 monitor command m A000. This displays:

image.png.6e27478037a81e8f8ac1e3394ed104cf.png

Note that the memory still contains junk.

3. Now we execute the program (use F10 a couple of times) until you see this:

image.png.91ae4d898584e2f5b4b56faa57b27994.png

 

4. The file TEXT has been loaded into memory at A000.

However... Why is the HELLO WORLD only loaded partially. The HE seems to be missing!

image.png.369829318a9299b5f53552affb66d3f4.pngStrange, because when we start the routine, the addressing seems to be populated just fine!

The A000 address seems to be correctly stored in the registers Y and X!

This seems to be a BUG in the emulator or in the X16 ROM?

 

KICKC home page by Jesper Gravgaard.
My KICKC alpha with Commander X16 extensions.
User avatar
JimmyDansbo
Posts: 476
Joined: Sun Apr 26, 2020 8:10 pm
Location: Denmark
Contact:

Problems with FFD5 CBM LOAD API in X16

Post by JimmyDansbo »


When you use the debugger in the emulator to follow kernal routines be sure to manually switch the bank number. In this case it seem like you are working on ROM bank 4, but the debugger is displaying the content of ROM bank 0.

To switch, type dBXXXX where B = bank number and XXXX is the address you want to view. I think that should make it easier to see what is happening in the debugger.

The LOAD function expects the first two bytes to be the address where the file should be loaded. Even if you specify an address when loading, LOAD still expects the first two bytes to be an address, but then just ignores those two bytes.

Visit my Github repo
or my personal site with CX16/C64/6502 related information.
Feel free to contact me regarding any of my projects or even about meeting up somewhere near Denmark
User avatar
svenvandevelde
Posts: 488
Joined: Wed Dec 23, 2020 6:30 am
Location: Belgium, Antwerpen

Problems with FFD5 CBM LOAD API in X16

Post by svenvandevelde »



5 minutes ago, JimmyDansbo said:




The LOAD function expects the first two bytes to be the address where the file should be loaded. Even if you specify an address when loading, LOAD still expects the first two bytes to be an address, but then just ignores those two bytes.



ah!!! ok! that solves at least my second question! and what about the first question, the monitor?

KICKC home page by Jesper Gravgaard.
My KICKC alpha with Commander X16 extensions.
User avatar
JimmyDansbo
Posts: 476
Joined: Sun Apr 26, 2020 8:10 pm
Location: Denmark
Contact:

Problems with FFD5 CBM LOAD API in X16

Post by JimmyDansbo »



26 minutes ago, svenvandevelde said:




what about the first question



Take a look at my edited response ?

You need to make the debugger show you the correct bank by inserting the bank number before the address

Visit my Github repo
or my personal site with CX16/C64/6502 related information.
Feel free to contact me regarding any of my projects or even about meeting up somewhere near Denmark
Ed Minchau
Posts: 503
Joined: Sat Jul 11, 2020 3:30 pm

Problems with FFD5 CBM LOAD API in X16

Post by Ed Minchau »



10 hours ago, svenvandevelde said:




Hi all,



I've been struggling for a couple of weeks now with the CBM API "loadfile" located at address $FFD5 ... I got some of it working, but the API seems to do some weird things, or it's me, or it's the compiler, or it's the emulator.

So I decided to make a demo program, that you can try out, and follow the below to simulate the issue ...



The program loads a TEXT file, reads it into banked memory (A000). The file contains the words "HELLO WORLD", and a 0x00 hex to end properly the string. This file is read using the cbm_k_load routine which is implemented in assembler.



(snikt)



The API uses bank 00 of RAM when loading or saving.  Trying to load or save files in banked memory fails because it switches to bank 0 rather than whatever bank you're trying to load or save.  My solution for loading banked RAM in the META/L editor was to copy $7000-8FFF to bank FF, load the file at 7000, then copy that to whatever bank I wanted and finally copy bank FF back down to 7000.  To save, I'd copy 7000-8FFF to bank FF, copy whatever bank I wanted to save down to 7000, save there, and then copy bank FF back down to 7000-8FFF.

User avatar
svenvandevelde
Posts: 488
Joined: Wed Dec 23, 2020 6:30 am
Location: Belgium, Antwerpen

Problems with FFD5 CBM LOAD API in X16

Post by svenvandevelde »



10 hours ago, JimmyDansbo said:




When you use the debugger in the emulator to follow kernal routines be sure to manually switch the bank number. In this case it seem like you are working on ROM bank 4, but the debugger is displaying the content of ROM bank 0.



To switch, type dBXXXX where B = bank number and XXXX is the address you want to view. I think that should make it easier to see what is happening in the debugger.



The LOAD function expects the first two bytes to be the address where the file should be loaded. Even if you specify an address when loading, LOAD still expects the first two bytes to be an address, but then just ignores those two bytes.



I tried that also. That also fails. Try for yourself .... Try to step into the JSR  load API at FFD5 using the F11 key. And indeed, before you do that, type B ROM 0.

The next instruction is the jump statement. But then .... press F11 again....

Now it will just execute the load procedure, and it will NOT jump into the routine :(. Unless I'm doing something wrong.

KICKC home page by Jesper Gravgaard.
My KICKC alpha with Commander X16 extensions.
User avatar
svenvandevelde
Posts: 488
Joined: Wed Dec 23, 2020 6:30 am
Location: Belgium, Antwerpen

Problems with FFD5 CBM LOAD API in X16

Post by svenvandevelde »



25 minutes ago, Ed Minchau said:




The API uses bank 00 of RAM when loading or saving.  Trying to load or save files in banked memory fails because it switches to bank 0 rather than whatever bank you're trying to load or save.  My solution for loading banked RAM in the META/L editor was to copy $7000-8FFF to bank FF, load the file at 7000, then copy that to whatever bank I wanted and finally copy bank FF back down to 7000.  To save, I'd copy 7000-8FFF to bank FF, copy whatever bank I wanted to save down to 7000, save there, and then copy bank FF back down to 7000-8FFF.



I think this answer is not answering my question :). But thanks for your explanation. It brings additional knowledge.

KICKC home page by Jesper Gravgaard.
My KICKC alpha with Commander X16 extensions.
User avatar
JimmyDansbo
Posts: 476
Joined: Sun Apr 26, 2020 8:10 pm
Location: Denmark
Contact:

Problems with FFD5 CBM LOAD API in X16

Post by JimmyDansbo »


It seems to be working for me. F11 is indeed the key you want to ensure that you enter subroutines.

As you see here, I am ready to JSR into FFD5, but notice that BKO is 04 which means the ROM bank is currently set 4

image.png.30d2738231ed4342ed4c74eee01a0411.png

When I then F11 to follow the JSR, I get this:

image.png.94f84b21e152b6cc0a510896b6616edd.png

I have jumped to $FFD5, but as you see, it says 00:FFD5 so it is showing me the contents of ROM bank 0.

image.png.2152e38ab0641c45ca2f862cfac90519.png

By typing d4ffd5 I get the debugger to show me the contents of ROM bank 4

image.png.419d06e6a244caf5dc7e6986f4f6ecd6.png

and I can follow the instructions. 

Just be sure that you manually follow the BKO value.

btw, you can also get the debugger do show you the content of VERA memory by typing: vBXXXX where B=bank or high part of address (0 or 1) and XXXX is the low 16 bits of the address.

 

Visit my Github repo
or my personal site with CX16/C64/6502 related information.
Feel free to contact me regarding any of my projects or even about meeting up somewhere near Denmark
User avatar
svenvandevelde
Posts: 488
Joined: Wed Dec 23, 2020 6:30 am
Location: Belgium, Antwerpen

Problems with FFD5 CBM LOAD API in X16

Post by svenvandevelde »



19 minutes ago, JimmyDansbo said:




It seems to be working for me. F11 is indeed the key you want to ensure that you enter subroutines.



As you see here, I am ready to JSR into FFD5, but notice that BKO is 04 which means the ROM bank is currently set 4



image.png.30d2738231ed4342ed4c74eee01a0411.png



When I then F11 to follow the JSR, I get this:



image.png.94f84b21e152b6cc0a510896b6616edd.png



I have jumped to $FFD5, but as you see, it says 00:FFD5 so it is showing me the contents of ROM bank 0.



image.png.2152e38ab0641c45ca2f862cfac90519.png



By typing d4ffd5 I get the debugger to show me the contents of ROM bank 4



image.png.419d06e6a244caf5dc7e6986f4f6ecd6.png



and I can follow the instructions. 



Just be sure that you manually follow the BKO value.



btw, you can also get the debugger do show you the content of VERA memory by typing: vBXXXX where B=bank or high part of address (0 or 1) and XXXX is the low 16 bits of the address.



 



The problem is deeper. Try to show me these instructions in a direct screenshot of the monitor where the PC is in this routine: (the routine is the ROM routine). I can also display the routine, but I want to walk the routine step by step in the ROM.

 

 


image.png.5327c28266eab518c1fb629ee09bc72c.png
image.png.5a311fcd133f5c3d3a03fa53595b43df.png
KICKC home page by Jesper Gravgaard.
My KICKC alpha with Commander X16 extensions.
Post Reply