Hello, Guest the thread was viewed359 times and contains 6 replies

last post from vbc1 at the

Loading file from SD using hyppo

    I'm trying to load a file from hyppo in C, with llvm-mos on latest Xemu. But whatever I do, I always get 88 error code (file not found). Example:

    I also tried hyppo_findfile + hyppo_openfile + hyppo_readfile but with same results. File definitely exists and hyppo services are working as I can use hyppo_opendir + hyppo_readdir to read the contents.


    The name string starts at page boundary as expected according to documentation (though it seems setfile function can actually read string from any location and expects X to hold low byte of the address), in my case it's $3000. If I printf the string, it's correct. I tried upper case and lower case too. If I inspect dissassembled code, it also looks correct:

    looking at Xemu log hints at the issue - setname seems to set wrong name but I don't know why:

    Code
    1. HDOS: entering function #$2E (setname) A=$2E X=$00 Y=$30 Z=$00
    2. HDOS: leaving function #$2E (setname) with carry SET (A,X,Y,Z=$2E,$00,$30,$00)
    3. HDOS: setname: selected filename is [x/] from $3000
    4. HDOS: entering function #$36 (loadfile) A=$36 X=$00 Y=$00 Z=$10
    5. HDOS: leaving function #$36 (loadfile) with carry CLEAR (A,X,Y,Z=$88,$00,$00,$10)
    6. HDOS: entering function #$38 (geterrorcode) A=$38 X=$00 Y=$00 Z=$10
    7. HDOS: leaving function #$38 (geterrorcode) with carry SET (A,X,Y,Z=$88,$00,$00,$10)

    Any pointers would be appreaciated!

    I don't see an obvious error and this looks correct to me. Can you maybe add an endless loop right when you are about to jump into the hyppo_setname trap, and then use MEGA+TAB to enter the Matrix Monitor and check with M3000 that the string actually is located at $3000 at that moment in time? Please also check that the mapping is set to zero, but I guess this is already the case if you work with llvm-mos.

    If it is not available at $3000, I would check the real address of the "name" pointer. Maybe something went wrong with the alignment attribute? I thought it needs to be

    Code
    1. __attribute__((aligned(256))) const char *name = "GLLOOK.INF";

    But if the compiler is also accepting __attribute(), then maybe that is just me not knowing this alternative.

    Thanks!


    Seems like it accepts both variants, with and without double undesrcore suffix. I get same results though. The string should be present on $3000, I did a printf("%s", (char *)0x3000) at some point while investigating and it prints out correct name. map should be fine too, wasn't sure if llvm does it, so added my own asm code to set it to 0.


    I'll try with the monitor.

    Quote from tkragelj96

    I'm trying to load a file from hyppo in C, with llvm-mos on latest Xemu. But whatever I do, I always get 88 error code (file not found). Example:

    Code
    1. [...]

    Any pointers would be appreaciated!

    vbcc supports reading from SD card with stdio functions using hyppo. Its loader for large banked code uses hyppo as well. It's been quite a while since I have implemented that but you can have a look at the latest vbcc distribution for 6502 (from http://compilers.de/vbcc.html) which contains samples using hyppo to read from SD-card. Source code for the loader as well as for the Mega65-specific parts of the library is included.

    Quote from vbc1
    Quote from tkragelj96

    I'm trying to load a file from hyppo in C, with llvm-mos on latest Xemu. But whatever I do, I always get 88 error code (file not found). Example:

    Code
    1. [...]

    Any pointers would be appreaciated!

    vbcc supports reading from SD card with stdio functions using hyppo. Its loader for large banked code uses hyppo as well. It's been quite a while since I have implemented that but you can have a look at the latest vbcc distribution for 6502 (from http://compilers.de/vbcc.html) which contains samples using hyppo to read from SD-card. Source code for the loader as well as for the Mega65-specific parts of the library is included.

    That is really interesting. The last download on that page says it is from 2022. Is it still developed further and maintained?