[Coco] Megaread problems
dave at davebiz.com
Mon Mar 27 15:47:51 EDT 2017
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.
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.
> The source is online elsewhere. PM me if interested.
> ----- 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.
>> 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.
>>> 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
>>>> 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.
More information about the Coco