[Coco] MyRam vs, Rammer
gheskett at shentel.net
Sun May 12 18:15:25 EDT 2019
On Sunday 12 May 2019 06:03:16 pm L. Curtis Boyle wrote:
> There are two pluses in the RAMMER column (at least in the bug fix
> version in EOU Beta 4) - since it mimics “real” drive geometry
> (number of sides, sectors per track, tracks), it works with the BACKUP
> command (so you can back up real floppies in 1 pass to either
> direction. It also supports the special /MD descriptor (“memory
> descriptor”) for debugging. This lets you both view and modify memory
> anywhere in the 2 MB while the system is running. Not for the casual
> user, but very helpful for testing special cases, error trapping, etc.
ISTR I did test it with backup, backing up a 720k floppy and going both
ways for 2 identical floppy's as a result. Maybe I did something to muck
that up in the final version? Or bit rot has set in in the copies in the
But I'm out of system ram and can't format a floppy. That makes things
like this a bit difficult to troubleshoot at this late date.
> Sent from my iPhone
> > On May 12, 2019, at 3:04 PM, Gene Heskett <gheskett at shentel.net>
> >> On Sunday 12 May 2019 03:33:08 pm coco at jechar.ca wrote:
> >> What are the pros and cons of MyRam vs Rammer for 512K and 2 Meg
> >> systems ?
> >> Charlie.
> > From the author of MyRam, not a lot for a 512k system, although
> > bringing it into existence, just access it by any handy command,
> > like a "dir /r0" and it will be formatted and ready to use in about
> > 100 milliseconds and a deiniz /r0 it when done to demolish it and
> > get every byte back for other uses may still be an advantage. See
> > my README for how to adjust its size in 8 kb chunks. I've used it
> > for c compiler scratchpad set for 1.7 megabytes on my 2 meg machine,
> > probably at least a thousand times. If you don't have a hard drive,
> > it will speed up a compile thats using a floppy for scratchpad a
> > very noticeable amount. With scsi hard drives, and probably even the
> > ide drives, it won't be noticeably faster because the drive is not
> > the speed limit, the coco is. It takes 11 seconds for the coco3 to
> > move a megabyte. Thats slow considering modern SSD's with a sata
> > interface on a slow atom cpu are doing 120+ megs/second these days.
> > example from one of my machine controller boxes, with a 1.4GHz dual
> > core atom cpu:
> > gene at shop:~$ sudo hdparm -tT /dev/sda1
> > [sudo] password for gene:
> > /dev/sda1:
> > Timing cached reads: 1808 MB in 2.00 seconds = 904.15 MB/sec
> > Timing buffered disk reads: 368 MB in 3.00 seconds = 122.58 MB/sec
> > gene at shop:~$
> > And thats slow, another machine with more butterfly's in the cpu is
> > doing 192 for that last figure.
> > Cheers, Gene Heskett
> > --
> > "There are four boxes to be used in defense of liberty:
> > soap, ballot, jury, and ammo. Please use in that order."
> > -Ed Howdershelt (Author)
> > Genes Web page <http://geneslinuxbox.net:6309/gene>
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
More information about the Coco