tre@sdcarl.UUCP (Tom Erbe) (07/22/86)
.
The floppy disk on my ST seems to run very slow. I have seen this on
other STs, so I think it is a design flaw. If I am not imagining this, where
does the fault lie? Is it the disk, the controller, or the software? Will
there be a fix for this from Atari?
--
Tom Erbe
Computer Audio Research Lab, UCSD
Q-037
La Jolla, CA 92093
619-452-4384
{ucbvax,ihnp4,akgua,hplabs,sdcsvax}!sdcarl!trelbl@druhi.UUCP (LocklearLB) (07/24/86)
In article <332@sdcarl.UUCP>, tre@sdcarl.UUCP (Tom Erbe) writes: > > . > The floppy disk on my ST seems to run very slow. I have seen this on > other STs, so I think it is a design flaw. If I am not imagining this, where > does the fault lie? Is it the disk, the controller, or the software? Will > there be a fix for this from Atari? > -- > Tom Erbe > Computer Audio Research Lab, UCSD > Q-037 > La Jolla, CA 92093 > 619-452-4384 > {ucbvax,ihnp4,akgua,hplabs,sdcsvax}!sdcarl!tre I have read benchmarks that indicate that the ST floppies are rather slow. The most likely culprits are GEMDOS and the floppy driver code. I haven't seen GEMDOS code ( I certainly would like to!), but I have looked at the driver code. It really isn't as optimized as it could be. In fact it is far too understandable to have been optimized! :) :) But seriously, while looking at the code I discovered something I would like to pass on: If the buffer that is specified in a read or write operation is not on a word boundary, the resulting operation is going to be VVEERRYY SSLLOOWW!! The main reason for this is that the DMA buffer must be on a word boundary. If the user buffer is not on a word boundary, the driver must read a sector at a time into its own word aligned buffer and copy it to the user buffer. If the buffer IS word aligned, then it merely DMA's the requested sectors into the user buffer straight from the floppy. Needless to say, the second option is much faster. Moral: In your programs, always try to use a word aligned buffer for disk requests. Barry Locklear
braner@batcomputer.TN.CORNELL.EDU (braner) (07/24/86)
[] The ST uses a DMA chip for very fast disk reading. Notice, for example, how fast a long program loads (listen to the clicks as the tracks go by). The problem with many programs that read/write files very slowly is that they do it UNIX style, char by char. (It is buffered somewhat (sectorwise?) but not enough.) The disk spins as the data is handled, and then is not on the next sector when it's needed, meaning that everything waits till the disk goes around almost a whole circle. With 9 sectors per track this causes aprox. an 8-fold slow-down. This is NOT the way to do it! My new version of microEMACS includes a method of reading (and writing) files through a big (18K) RAM buffer (you've got a Megabyte: use it!). The speed improvment is VERY noticeable. It is almost as fast reading a long text file into the editor (from floppy) as it is copying the file to RAM disk. In the future we will all have hard disks, it seems. Then it is even MORE important to use a good buffering scheme. Personally, I believe that this should be done at the operating system level, as some sort of disk caching. The methods that worked for UNIX (with big, fast hard disks and a slow CPU managing a small (per user) block of RAM) are NOT good for us micro users (with a great CPU (for one user) and slow hard disks (or worse)). Until things get better, I do most of my work off a RAM disk (compile and link a 100-line program: 15 seconds! (using Megamax)). - Moshe Braner, Cornell Univ.
rb@cci632.UUCP (Rex Ballard) (07/26/86)
In article <332@sdcarl.UUCP> tre@sdcarl.UUCP (Tom Erbe) writes: > >. > The floppy disk on my ST seems to run very slow. I have seen this on >other STs, so I think it is a design flaw. If I am not imagining this, where >does the fault lie? Is it the disk, the controller, or the software? Will >there be a fix for this from Atari? >-- > Tom Erbe I found just the opposite. If you are comparing to the speed of the Mac drives, which are "Incredible Woz Machine" technology, then yes, the ST is a little slower. SONY actually make 3 1/2" drives in several flavors, each with different rotational speeds and Seek times. Atari went with a shorter seek time, but standard rotational speed, appearantly to allow the use of 5 1/4" inch drives (Which can be interfaced by simply buying a "replacement cable" and a little soldering/connecting). The main question is, can the existing drive be put into 2X or 4X rotational speed? Can the clock on the WD chip be multiplied as well? If you really want speed, get a Kodak "second drive" and a Supra SCSI adapter. Then you can get 3MB/disk using special "high density disk", that give you hard disk (1800 or 3600? RPM) speeds. The thing to remember is that the "floppy" (either size) should normally be used as a "download and bootstrap" device once low-cost high-speed storage is available. Considering that a hard drive could be built from "surplus" for around $350, maybe less, it makes sense to go with something "hard".
braner@batcomputer.TN.CORNELL.EDU (braner) (08/05/86)
[]
I got this on the STarter kit from John Franco, and I think it is so great
(and short) that I have to post it! It is a RAMdisk program, written by
John Harris, and done right at last! It is NOT a desk accessory. It has
no graphics. It is just an autobooting RAMdisk that will survive system
resets!!!
(It will also work with programs that have a fixed location in low memory,
e.g. Forth systems and applications written in Forth, since it installs in
high memory, as opposed to standard programs and most other RAMdisks.)
First, the doc file by John Harris:
------------------------------------------------------------------------
This program gives you a ramdisk between 64K and 768K, and will stay in
memory through screen resolution changes, and even system reset! The
ramdisk code and data is placed at the top of memory, and the screen is
moved down below it. The top of memory pointers are set below the ramdisk
driver, which should keep it safe from everything short of powering down.
The ramdisk install is actually a 2 step process. The 1st time the
program is run, it will adjust memory pointers and set-up the ramdisk
driver. It then exits through the system reset vector so that TOS can
adjust to the new memory size. The 2nd time through, the driver will
be installed and ready to use. The easiest way to accomplish this, is
simply put the ramdisk.prg into an AUTO folder. That way both passes are
automatically performed, in other words, it will auto-boot with no user
interaction. The ramdisk installs as drive D, and if you save the desktop
after you install drive D, then the boot process will be completely automatic.
The ramdisk size defaults to 192K, but can be changed by holding down key
combinations of the Right and Left Shift, Control, and Alternate keys.
Configurations are as follows:
R. Shift 64K
L. Shift 128K
R. & L. Shifts 192K
Cntl 256K
Cntl & R. Shift 320K
Cntl & L. Shift 384K
Cntl & R. & L. Shifts 448K
Alt 512K
Alt & R. Shift 576K
Alt & L. Shift 640K
Alt & R. & L. Shifts 704K
Alt & Cntl 768K
If your disk has many desk accessories on it, you should be careful to
load a small enough ramdisk so that 128K will be left at the end of the
boot.
If the system does crash, put a disk with the ramdisk program in the AUTO
folder in drive A, and push the system reset button.
Enjoy! John Harris
--------------------------------------------------------------------------
Next, a hex dump of this little gem (all 640 bytes of it!)
(you can convert this to a binary file (call it rd192.prg) by using the
"htb" program I posted a while ago):
--------------------------------------------------------------------------
60 1A 00 00 02 0A 00 00 00 14 00 00 06 50 00 00
00 00 00 00 00 00 00 00 00 00 00 00 20 7C 00 00
02 0A 61 06 4E F9 00 00 00 2E 72 04 22 7C 00 00
06 22 32 D8 51 C9 FF FC 22 3C 00 00 02 0A 70 C8
4E 42 30 39 00 00 06 4C 4E 75 2A 4F 2E 7C 00 00
08 6A 2A 6D 00 04 20 2D 00 0C D0 AD 00 14 D0 AD
00 1C D0 BC 00 00 01 00 2F 00 2F 0D 3F 00 3F 3C
00 4A 4E 41 DF FC 00 00 00 0C 42 A7 3F 3C 00 20
4E 41 5C 8F 23 C0 00 00 06 66 28 7C 00 00 04 36
2A 7C 00 00 04 2E 22 55 0C 51 02 00 67 74 3F 3C
FF FF 3F 3C 00 0B 4E 4D 58 8F C0 BC 00 00 00 0F
66 02 70 03 48 40 22 00 74 0A E4 A9 92 7C 00 14 * change the 03 - see below
33 C1 00 00 01 50 22 00 D2 B9 00 00 04 32 D2 BC
00 02 00 00 B2 94 6C 74 91 94 91 95 23 F9 00 00
04 72 00 00 01 FA 23 F9 00 00 04 76 00 00 02 06
23 F9 00 00 04 7E 00 00 02 00 20 7C 00 00 01 42
22 55 7E 7F 22 D8 51 CF FF FC 20 79 00 00 00 04
4E D0 22 15 D2 BC 00 00 00 20 23 C1 00 00 04 72
22 15 D2 BC 00 00 00 32 23 C1 00 00 04 76 22 15
D2 BC 00 00 00 12 23 C1 00 00 04 7E 30 39 00 00
04 C4 08 C0 00 03 33 C0 00 00 04 C4 2F 39 00 00
06 66 3F 3C 00 20 4E 41 5C 8F 42 67 4E 41 02 00
00 02 04 00 00 07 00 05 00 06 00 12 01 EC 00 00
0C 6F 00 03 00 04 66 00 00 A2 70 00 4E 75 0C 6F
00 03 00 04 66 00 00 8E 20 39 00 00 04 2E 4E 75
0C 6F 00 03 00 0E 66 00 00 88 20 39 00 00 04 2E
D0 BC 00 00 02 00 20 40 22 6F 00 06 70 00 32 2F
00 0C 70 09 E1 A1 D1 C1 30 2F 00 0A 24 09 08 02
00 00 66 28 08 2F 00 00 00 05 66 02 C1 49 32 3C
00 0F 20 D9 20 D9 20 D9 20 D9 20 D9 20 D9 20 D9
20 D9 51 C9 FF EE 53 80 66 E4 4E 75 08 2F 00 00
00 05 66 02 C1 49 32 3C 00 3F 10 D9 10 D9 10 D9
10 D9 10 D9 10 D9 10 D9 10 D9 51 C9 FF EE 53 80
66 E4 4E 75 4E F9 00 00 00 00 4E F9 00 00 00 00
4E F9 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 02 08 08
0C 0A 0A 38 3C 20 0A 0A 06 52 00 4B 4B 4B 4B 4B * I dont think these 4B's
4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B * are needed but...
4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B
4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B
--------------------------------------------------------------------------
To change the default size of the RAMdisk, change the "03" entry on the
marked line:
size, kbytes hex value
64 01
128 02
192 03
256 04
320 05
384 06
448 07
512 08
576 09 <-- for development work using Megamax
640 0A
704 0B
768 0C
-----------------------------------------------------------------------
- Moshe Braner
Corson Hall, Cornell University, Ithaca NY 14853
(607) 272-3487
For electronic mail, my address is:
braner@amvax.tn.cornell.edu (ARPANET)
braner%amvax.tn.cornell.edu@WISCVM.BITNET (Bitnet)
{decvax,ihnp4,cmcl2,vax135}!cornell!amvax!braner (USENET)
------------------------------------------------------------------------fischer@YALE.ARPA (Michael Fischer) (08/20/86)
I got this on the STarter kit from John Franco, and I think
it is so great (and short) that I have to post it! It is a
RAMdisk program, written by John Harris, and done right at last!
It is NOT a desk accessory. It has no graphics. It is just
an autobooting RAMdisk that will survive system resets!!!
It works as advertised, and the ability to survive system resets
is really nice. Unfortunately, I have had to stop using it ever
since I got my hard disk because both it and the hard disk use drive
D, and it seems to preempt the hard disk interrupt vectors for its
own use.
I'd like to fix it to work with the hard disk, but having the source
would make life much easier. Does anyone out there have the source
and would be willing to post it to the net? Or at least, does anyone
know who the author is so that I could contact him directly?
--Mike Fischer
Address: Fischer@Yale.ARPA
-------TPC862@ESTEC.BITNET (08/22/86)
OPTIONS: NOACK LOG SHORT NOTEBOOK ALL Date: 22 August 1986, 09:16:52 EST From: Ton van Overbeek +31 1719 83041 TPC862 at ESTEC To: FISCHER at YALE.ARPA cc: INFO-ATARI16 at SCORE.STANFORD.EDU Subject: Re: Floppy Disk Speed >I'd like to fix it to work with the hard disk, but having the source >would make life much easier. Does anyone out there have the source >and would be willing to post it to the net? Or at least, does anyone >know who the author is so that I could contact him directly? I disassembled this ramdisk posted by Braner, and the mod you need to change the ram disk drive to C or E or whatever is indicated below. Here follow three lines from the original posting of this ramdisk: D2 BC 00 00 00 12 23 C1 00 00 04 7E 30 39 00 00 04 C4 08 C0 00 03 33 C0 00 00 04 C4 2F 39 00 00 <-- change the 03 06 66 3F 3C 00 20 4E 41 5C 8F 42 67 4E 41 02 00 The C0 00 03 is the BSET #$03,D0 instruction that sets bit 3 (= drive D) D0 is moved in the next instruction to $4C4 (the drvbits word). So change the 03 to 02 if you want drive C or to 04 if you want drive E to be the ramdisk. Hope this helps. Ton van Overbeek European Space Research and Technology Centre (ESTEC) Control Systems Section P.O.Box 299 2200 AG Noordwijk, The Netherlands. Phone: +31 1719 83041 Email: TPC862%ESTEC.BITNET@WISCVM.WISC.EDU (ARPA) ...!ucbvax!tpc862@estec.bitnet (USENET/UUCP) TPC862@ESTEC (EARN/BITNET)
demillo@uwmacc.UUCP (Rob DeMillo) (08/22/86)
In article <8608201441.AA26014@Yale-Bulldog.YALE.ARPA> fischer@YALE.ARPA (Michael Fischer) writes: > [...some stuff about the RAMdisk in the starter kit...] > >It works as advertised, and the ability to survive system resets >is really nice. Unfortunately, I have had to stop using it ever >since I got my hard disk because both it and the hard disk use drive >D, and it seems to preempt the hard disk interrupt vectors for its >own use. > >--Mike Fischer > Why don't you install either the hard disk or the RAM disk as drive E ? -- --- Rob DeMillo Madison Academic Computer Center usenet: {ihnp4,harvard,seismo,topaz,decvax}!uwvax!uwmacc!demillo ARPA: demillo@unix.macc.wisc.edu (now isn't that easier?) ---------------------------------------- "I am not so sure what you want me for! 'War Games' Either your machine is a - Crosby, Stills and Nash fool, or me..."
FISCHER-MICHAEL@YALE.ARPA (08/25/86)
Date: 22 August 1986, 09:16:52 EST
From: Ton van Overbeek +31 1719 83041 TPC862 at ESTEC
>I'd like to fix it to work with the hard disk, but having the source
>would make life much easier. Does anyone out there have the source
>and would be willing to post it to the net? Or at least, does anyone
>know who the author is so that I could contact him directly?
I disassembled this ramdisk posted by Braner, and the mod you need
to change the ram disk drive to C or E or whatever is indicated below.
Thanks for the reply, but simply changing the ram disk drive number is
not enough. The ram disk program is modifying some hard disk vectors
(apparently pretending to the system that it IS a hard disk), and this
disables the real hard disk. I don't think it would be difficult to fix
with the sources, but it would require a more thorough understanding of
the code than I can get after a quick browse with SID.
Which brings up the question: Does anyone know how to get printed output
from SID? When I try to redirect standard output, it crashes, and I am
not aware of any way of printing from within SID.
--Mike Fischer
-------Pase@DOCKMASTER.ARPA (Bill Pase) (08/26/86)
The September issue of Analog has an article called Format+. It is a Basic program which patches the ram verion of gem so that the disk formater works differently. Disks which are then formated and used with the standard gem perform io at double the speed of the normal formatted disk. The transfer rate is near the theoritical maximum. I haven't actually tried it yet but will let you know what I find out. /bill