1 Topic by mcleod_ideafix

  • mcleod_ideafix
  • esxDOS User
  • Offline
  • From: Jerez de la Frontera (Spain)
  • Registered: 2014-03-17
  • Posts: 19

Topic: API function: get physical sector address for current file position

Both ATA and SD devices managed with ESXDOS use 512 byte sectors. My proposal is to have a ESXDOS function call that can retrieve the address (sector number) of the last sector used in the last read (or write or seek) operation. This can be already achieved by quering the device itself on ATA devices, but SD cards don´t have (afaik) such option.

The purpose of this is for software to be able to get the list of sectors that a file uses by seeking it on 512 byte steps. That list of sectors can therefore be used to perform low level access to the actual device bypassing ESXDOS and allowing real time audio or video playing without the need for the file to be unfragmented and without the need for such program to reimplement a file system just for this.

It also opens the posibility of new hardware devices to be designed so they receive a list of sector addresses obtained this way and the hardware itself is in charge of performing read operations to the device independent of the CPU (so a TZX file player could read TZX/PZX files stored in the same card DivMMC uses instead of using a different SD card, and file selection could be made possible using ESXDOS itself, much like the current implementation of PZX file player on ZX-UNO)

2 Reply by lordcoxis

  • lordcoxis
  • Administrator
  • Offline
  • Registered: 2013-07-03
  • Posts: 101

Re: API function: get physical sector address for current file position

Hi mcleod_ideafix,

This is planned and an IOCTL for this will be in v0.9.x.

Thanks

lordcoxis's Website

3 Reply by mcleod_ideafix

  • mcleod_ideafix
  • esxDOS User
  • Offline
  • From: Jerez de la Frontera (Spain)
  • Registered: 2014-03-17
  • Posts: 19

Re: API function: get physical sector address for current file position

lordcoxis wrote:

Hi mcleod_ideafix,

This is planned and an IOCTL for this will be in v0.9.x.

Thanks

Thank you very much! smile

4 Reply by Alcoholics Anonymous

  • Alcoholics Anonymous
  • esxDOS Fan
  • Offline
  • Registered: 2014-08-30
  • Posts: 52

Re: API function: get physical sector address for current file position

NextOS extends the esxdos api with streaming functions that do exactly this.  It might be worthwhile to check out to see if it's a good idea for esxdos proper.

5 Reply by lordcoxis

  • lordcoxis
  • Administrator
  • Offline
  • Registered: 2013-07-03
  • Posts: 101

Re: API function: get physical sector address for current file position

Alcoholics Anonymous wrote:

NextOS extends the esxdos api with streaming functions that do exactly this.  It might be worthwhile to check out to see if it's a good idea for esxdos proper.

Thanks, I will have a look at it when I have some time.

lordcoxis's Website

6 Reply by mcleod_ideafix

  • mcleod_ideafix
  • esxDOS User
  • Offline
  • From: Jerez de la Frontera (Spain)
  • Registered: 2014-03-17
  • Posts: 19

Re: API function: get physical sector address for current file position

Alcoholics Anonymous wrote:

NextOS extends the esxdos api with streaming functions that do exactly this.  It might be worthwhile to check out to see if it's a good idea for esxdos proper.

Streaming functions is not what I was asking for. I just need to know the physical sector number of the last read/write/seek byte so I can, say, build a list of sector entries that I can feed to a hardware device in order to sequentially read a file without and independent from any CPU intervention.

7 Reply by Alcoholics Anonymous

  • Alcoholics Anonymous
  • esxDOS Fan
  • Offline
  • Registered: 2014-08-30
  • Posts: 52

Re: API function: get physical sector address for current file position

mcleod_ideafix wrote:

I just need to know the physical sector number of the last read/write/seek byte so I can, say, build a list of sector entries that I can feed to a hardware device in order to sequentially read a file without and independent from any CPU intervention.

That's how the streaming api works.  The first call is for creating a disk map that indicates how a particular file is distributed on disk.  Each entry is a physical location and a length where the file data is uninterrupted.  This is what you want.