Announcement

Collapse
No announcement yet.

Redirecting output stream to MDA

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Redirecting output stream to MDA

    I am trying to redirect the output stream to media (SD card). The manual describes the command to(MDA), which should do this operation, but I can't make it work.
    My idea is to redirect the output of the file_Dir function to SD card and then read it back, one filename after the other. This is useful, if there are a lot of filenames and redirecting to a memory buffer would require a very large buffer. I was able to redirect the output to a file:

    #platform "uLCD-32PT_GFX2"
    func main()
    var hFile;
    while(!file_Mount()) putstr("SD?");
    hFile:=file_Open("DIRRESUL.TXT",'w');
    to(DSK);file_Dir("*.LOG");
    file_Close(hFile);
    endfunc

    Redirecting to file works as expected, but it is rather slow and cumbersome. I tried redirecting to RAW:

    #platform "uLCD-32PT_GFX2"
    func main()
    media_Init();
    while(!file_Mount()) putstr("SD?");
    media_SetSector(40,0);
    to(MDA);file_Dir("*.LOG");
    media_Flush();
    repeat forever
    endfunc

    It appear that to(MDA) is simply ignored, as the output from file_Dir is displayed on the screen. The sector on SD card is unchanged. I have also tried the example for the to() function. The example correctly stores the data using media_WriteByte, but ignores the to(MDA);putstr().

    Is to(MDA) redirection functional?

  • #2


    Warning - MDA redirection is for RAW mode only (NOT FAT16)
    If you use this mode, the current sector as last set by media_SetAdd or media_SetSector will be written to.
    This may be exactly what you want if your making some kind of disk doctor, or are writing to a partitioned area,
    but not what you want here and may damage the boot sector, FAT, or goodness knows what cluster links etc links..

    You can use DSK though as you have here, DSK outputs to the 'most recent file handle'
    and as you have found works in this example.

    The reason it is slow is that it is transferring one character at a time.

    The other alternative is to buffer the directory output in some RAM first using mem_Alloc,
    output it to the file, then release the RAM with mem_Free.

    something like this bit of abstract untested code:-

    var requiredMem;

    requiredMem :- file_Count("*.*") * 14;
    if(requiredMem < mem_Heap();
    temp := mem_Alloc(requiredMem);
    to(temp); file_Dir("*.*");
    ... transfer temp to file
    else
    ... not enough mem, do it the slow way
    endif





    Oh, and I suggest you re-format any disks that you have tried this code with to be on the safe side.
    Regards,
    Dave

    Comment


    • #3
      Hi Dave,

      I have used the RMPET tool to partition my 2GB SD card to 1 GB Fat16 and 1 GB RAW, so using the SectorHi above 32 is safe and will write to RAW area. My application is very memory intensive, so I am often using the RAW partition as a kind of secondary RAM, and so far I had no particular problems. I am a bit concerned about wear endurance of the SD card, but so far it proved to be quite reliable.

      Regarding the MDA redirection, I think there might be a bug. The bug is not limited only to the file_Dir() function, because the putstr function has the same symptoms. It appears as that the to(MDA) command does nothing and the output is simple redirected to screen.
      I have noticed that there is some ambiguity in the value of the MDA pointer. The value produced by the compiler is 0xF840, the Internal functions manual states 0xFF40 and the bubble help for to() function states 0xFF10, however none of these values seems to work.

      I have prepared a code example to demonstrate this bug candidate:

      #platform "uLCD-32PT_GFX2"
      var SDBuffer[256];
      func main()
      gfx_ScreenMode(4);
      media_Init();
      media_SetSector(44,0);
      media_WriteByte('H');
      media_WriteByte('e');
      media_WriteByte('l');
      media_WriteByte('l');
      media_WriteByte('o');
      media_WriteByte(' ');
      media_WriteByte('w');
      media_WriteByte('o');
      media_WriteByte('r');
      media_WriteByte('l');
      media_WriteByte('d');
      media_WriteByte('1');
      media_WriteByte('\n');
      media_WriteByte(0);
      media_Flush();
      media_SetSector(44,0);
      media_RdSector(SDBuffer);
      print("storing data using media_WriteByte\n");
      print("string length: ",strlen(SDBuffer),"\n");
      putstr(SDBuffer);
      media_SetSector(44,1);
      mem_Set(SDBuffer,0,512);
      to(SDBuffer);putstr("Hello world2\n");
      media_WrSector(SDBuffer);
      mem_Set(SDBuffer,0,512);
      media_SetSector(44,1);
      media_RdSector(SDBuffer);
      print("\nstoring data indirectly using buffer\n");
      print("string length: ",strlen(SDBuffer),"\n");
      putstr(SDBuffer);
      media_SetSector(44,2);
      to(MDA);putstr("Hello world3\n");
      media_Flush();
      mem_Set(SDBuffer,0,512);
      media_SetSector(44,2);
      media_RdSector(SDBuffer);
      print("\nstoring data using MDA redirection\n");
      print("string length: ",strlen(SDBuffer),"\n");
      putstr(SDBuffer);
      repeat forever
      endfunc

      The function first writes the "Hello world1" to SD card using the media_WriteByte function and reads it back and displays it on screen. This works OK.
      The function then uses redirection to put the string to a memory buffer, stores the entire buffer to SD, reads the sector back to buffer and displays it. This also works.
      The function then redirects the output to MDA and sends the string to redirected output, but the string is immediately displayed on the screen and the SD card is unchanged. Checking the length of the reloaded string returns 0.



      Can you please confirm that this is a bug, or explain what I am doing wrong?

      Regards,
      Valentin

      Comment


      • #4


        Hi Valentin,

        Yes it is a bug, it is fixed now just in time for v2.8 release.

        v2.8 will be available before the end of the week.
        Regards,
        Dave

        Comment

        Working...
        X