We have blocked out in MOS a bunch of API calls to expose fatfs functionality. The jump table for fatfs API calls can be found in mos_api.asm at the label mos_api_block2_start:. Many of these API calls however currently return a "not implemented" result.
The following API calls are defined in our API, but not yet implemented:
[ ] ffs_api_fsync
[ ] ffs_api_fforward
[ ] ffs_api_fexpand
[ ] ffs_api_fgets
[ ] ffs_api_fputc
[ ] ffs_api_fputs
[ ] ffs_api_fprintf
[ ] ffs_api_ftell
[ ] ffs_api_fsize
[ ] ffs_api_ferror
[ ] ffs_api_dfindfirst
[ ] ffs_api_dfindnext
[ ] ffs_api_unlink
[ ] ffs_api_rename
[ ] ffs_api_chmod
[ ] ffs_api_utime
[ ] ffs_api_mkdir
[ ] ffs_api_chdir
[ ] ffs_api_chdrive
[ ] ffs_api_mount
[ ] ffs_api_mkfs
[ ] ffs_api_fdisk
[ ] ffs_api_getfree
[ ] ffs_api_getlabel
[ ] ffs_api_setlabel
[ ] ffs_api_setcp
NB is may not be appropriate to implement all of these calls. Some such as ffs_api_fputc essentially replicate functionality of existing mos_ APIs, and therefore would be low priority to implement. Some refer to fatfs functionality that our configuration on the Agon does not use, and therefore are already correctly returning "not implemented". Additionally some calls may require more arguments than we can readily accept with the eZ80's limited register set. We may/probably need to define a standard ABI for such calls requiring extra arguments.
We have blocked out in MOS a bunch of API calls to expose fatfs functionality. The jump table for fatfs API calls can be found in
mos_api.asmat the labelmos_api_block2_start:. Many of these API calls however currently return a "not implemented" result.The following API calls are defined in our API, but not yet implemented:
NB is may not be appropriate to implement all of these calls. Some such as
ffs_api_fputcessentially replicate functionality of existingmos_APIs, and therefore would be low priority to implement. Some refer to fatfs functionality that our configuration on the Agon does not use, and therefore are already correctly returning "not implemented". Additionally some calls may require more arguments than we can readily accept with the eZ80's limited register set. We may/probably need to define a standard ABI for such calls requiring extra arguments.