[Coco] Megaread problems

[Dave Philipsen]

Ok, I gave it a try and without documentation I can't really understand 
how it could be properly used.  It is a rather large program for what it 
does ($16E3) so perhaps there is some other functionality in there.  
When I ran 'filldisk' it create a file in my working directory that did 
not fill the disk but was exactly 127,745 bytes in length filled with 
what appears to be random data.

Dave


On 3/27/2017 1:43 PM, Stephen H. Fischer wrote:
> FYI I wrote a program to create big files. It is called Filldisk and is in SHF888.dsk (zip) on my webpage.
>
> http://home.mindspring.com/~sfischer1/
>
> The source is online elsewhere. PM me if interested.
>
> SHF
>
> ----- Original Message -----
> From: "Dave Philipsen" <dave at davebiz.com>
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Sent: Monday, March 27, 2017 11:15 AM
> Subject: Re: [Coco] Megaread problems
>
>
>> Just a note.  I'm not sure if I found a bug in NitrOS9 'copy' or not.
>> But just for snicks I tried something. I have an 8MB ramdisk named '/R0'
>> and I have a 128MB SD card partition named '/SD0'. There is plenty of
>> free space on '/SD0'.  So I tried as below to 'copy /R0@
>> /SD0/ramdisk-image'.  This should copy the entire ramdisk to an image
>> file on the SD card.  The copy basically worked but it locked up the
>> shell I was in even after the file was supposedly written (which
>> shouldn't have taken much more than 30 seconds).  I hit 'BREAK' and
>> finally regained the shell but the copy process was still running.  I
>> killed it and 'procs' showed it was gone but the system was still being
>> bogged down with something.  I had to re-boot NitrOS9 to clear it.  When
>> I did a 'dir -e' of /SD0 I found the huge file in the directory and it
>> was the correct size (80 0000) but its attributes were null (--------)
>> and the owner was '8000'.  When I tried to delete the file I got a 214
>> error so I used ded and found the first sector of the file and manually
>> corrected the attributes and the owner so that when I did a 'dir' the
>> owner showed as '0' and the attributes showed as '--ewrewr' ($3F) and
>> then I was able to delete it. At first glance the filesystem on my SD
>> card is ok but I have't checked it all thoroughly yet.  Maybe I just
>> didn't allow enough time for the copy to finish.  Has anyone ever run
>> into such a problem before?  Has anyone ever manipulated files as large
>> as 8MB under NitrOS9?  I did create a file of slightly over 1MB in size
>> and everything seemed to be ok.
>>
>> I'm going to format another SD card and play around a bit and see if I
>> can re-create the problem and find out exactly what it is.
>>
>>
>> Dave
>>
>> On 3/27/2017 12:44 PM, Dave Philipsen wrote:
>>> I guess the problem has to do with the fact that the reference to
>>> '/DD' is just a reference to the root directory.  If you use '/DD@'
>>> then you will be referencing the raw device. Alternatively, you could
>>> create a file that is at least as large as the desired megaread and us
>>> it like this:  'megaread </dd/bigfile'.
>>>
>>> The error #214 is normal for trying to open/read a directory.  For
>>> instance, try 'copy /dd mydir'.  You'll get the same error.  You
>>> could, however, 'copy /DD@ mydir' in which case you'd need to make
>>> sure that the device which will hold 'mydir' is larger than the 'DD'
>>> device itself.
>>>
>>> Dave
>>>
>>>
>>> On 3/27/2017 7:35 AM, Robert Gault wrote:
>>>> Something very strange is going on with the version of megaread in
>>>> the current NitrOS-9 builds. The program works correctly for Dave
>>>> Philipsen and possibly everyone else. It fails for me on any system I
>>>> try.
>>>>
>>>> megaread 1 </DD
>>>>
>>>> The above should run the program for the minimum number of reads with
>>>> standard input changed to /DD. For MESS, VCC, and a 512K Coco3 the
>>>> result is error #214.
>>>>
>>>> megaread </DD
>>>> Same error as above for the default 1024 repeats.
>>>>
>>>> The crc for the version under test is $A5A49C, size $7A which is
>>>> identical with the nightly build version. Attr for tested drives
>>>> indicates normal values.
>>>>
>>>> Robert
>