| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 293.1 |  | BAGELS::BRANNON | Dave Brannon | Mon Feb 02 1987 19:05 | 14 | 
|  |     GEM uses an almost ibm pc disk format...the directory info is stored
    in sequential sectors a few sectors from the start of the disk.
    
    The hashing Amigados uses means you don't have limits on the disk
    data structures.  That overhead can slow things down for lots of
    small files.  But then you don't have a max limit on how may you can
    have.
    
    If i recall correctly, the ST has a default icon to display for
    files without icons.  That might account for some of the apparent
    speed.  How many of the files had different icons?
    
    -dave
    
 | 
| 293.2 | Gem slows stuff down. | NEXUS::MORGAN | Heaven's died and gone to Hell | Mon Feb 02 1987 19:35 | 37 | 
|  |     I think this is a good topic for both parties.
    
    There are only two icons supplied with the Atari.  An executable box
    and a non executable data file in the form of pages of paper. Although
    custom icons exist I haven't seen any. 
    
    I didn't know that the Atari was faster than the Amiga at getting the
    icons on the screen (is that what you are talking about?), but still
    think that the Atari is way too _slow_ getting information on the
    screen. 
    
    My little ][c could really zip information on the screen from a 2k page
    so when I got the Atari I was disappointed somewhat.  If memory serves
    me correctly the Apple uses a 2k video page and the Atari uses a 32k
    video page.  So even if the Atari was half as fast as the Apple it was
    doing 16 times the work.  What does the Amiga use for a video page.  It
    should be bigger than the Atari shouldn't it??  More colors at
    generally the same resolution should mean more work, but that is what
    the Bit Blts are for, aren't they? 
                                       
    Perhaps the Atari Bliter will spead Gem up somewhat.
    
    Now I have another item to add to this discussion.  Do any of you
    folks get pissed at the vender claims and the actual performance
    of these machines.
    
    Take for instance the claim that Atari makes for their DMA port.
    1.3 megabyte isn't it??  Well in actuality the SH204 only transfers
    50k per second.  I found that out by transfering a 110k file in
    just about 2 seconds.  I also allowed a little start up time for
    putting the info on the screen.
    
    I know for a fact that GEM slows stuff down, probably for error
    checking, which is ok by me, but I still want a fast interface for
    the user.
    
      Mikie?
 | 
| 293.3 |  | LEDS::ACCIARDI |  | Mon Feb 02 1987 20:04 | 14 | 
|  |     Re: .2
    
    The default Amiga Workbench screen is 64K (640 x 200 x 2 bit planes),
    but can be as little as 8K or as much as 128K (640 x 400 x 4 bit
    planes).
    
    The problem with Icons filling up windows seems to me to be an AmigaDOS
    problem, not a graphics/blitter/speed problem.  Once the drive is
    thru thrashing around the disk, windows can be moved at warp speed
    without any huffing and puffing and jitter, as seems to be the case
    with the ST.  In fact, entire screens can be pulled up and down
    at speeds that boggle the mind.  Once the window is filled with
    Icons, a file will load quite quickly.
    
 | 
| 293.4 | Seek Time Slows Things Down | TLE::RMEYERS | Randy Meyers | Tue Feb 03 1987 04:41 | 39 | 
|  | The slowness in opening a workbench menu and doing a CLI dir commands is
caused by the way AmigaDOS stores directories and files on the disk.
A lot (most) operating systems store all the directory information in
one file on the disk.
AmigaDOS uses hashed file lookups and scatters directory information all
over the disk.  The directory entries are linked together so that you
can get to all the directory entries by walking the list pointers.
Disks drives (for any system) have the property that they can send a
great deal of data all at once once the read/write head is positioned,
however physical movement of the head to the proper track on the disk
takes a lot of time (in comparison).
So, if your operating system stores all the directory entries in one
file, it positions the head to the proper track (the slow part), and
then gets about 11k of directory information in one gulp.  However,
AmigaDOS positions the head (the slow part), gets maybe 500 bytes of directory
information (the fast part), and then needs to position the head to some
other track on the disk to get the next 500 bytes.  It repeats this
process until it reads all the directory entries.  Thus, when getting
a directory listing, the heads on a Amiga disk drive are in constant
motion.
This pathological case only exists when doing a directory listing.  Simply
opening a file runs as fast or faster than a system that uses a non-hashed
directory.
You may have noticed that disks created under 1.2 display icons faster.
The reason is that Commodore changed the disk block allocation so that
the icon files are in general stored on the same track as their directory
entries.  Then means that less head movement needs to be done.
The difference between burst data speed and head seek time also probably
explains why the ST disk doesn't seem to live up to its rated speed.  I
believe that it does transfer data at 5 megabits/second.  However, you
can't fix 5mb on on track, and moving the head to the next track to get
the more data means it cannot read 5mb of file in one second.
 | 
| 293.6 | Disk Optimizer | TARKIN::SWONGER | What, me worry? | Tue Feb 03 1987 09:29 | 7 | 
|  |     These speed-of-directory issues have me wondering if there might
    be a way to optimize the file stucture of a floppy. (Like the programs
    that exist for doing the same thing for hard disks.) Now THAT would
    be a much-appreciated utility.
    
    Roy_who_wishes_he_had_an_amiga
    
 | 
| 293.7 | improving speed | HYSTER::DEARBORN | Trouvez Mieux | Tue Feb 03 1987 09:37 | 9 | 
|  |     You can always "clean up" old disks by copying them using the COPY
    ALL command.  This helps speed up icon display time.
    
    The only problem is that it also loses the file comments in the
    process (at least as far as I can tell.  I copied my OnLine! disk
    this way, and lost the file comments in my OnLine.trm file)
    
    Randy
    
 | 
| 293.8 | Workbench Screen Always 640 Across | TLE::RMEYERS | Randy Meyers | Tue Feb 03 1987 15:26 | 9 | 
|  | Re: .5
I believe you made a slight mistake:  The workbench screen is always
640 pixels across.  The 60 versus 80 columns merely selects which font
is used as the default font on the screen.  The 60 column font is just
an extra pixel or two across compared to the 80 column font.
Remember, the icons do not get stretched out if you select 60 column
text.  Thus, the horizontal resolution must not change.
 | 
| 293.9 | corrected, bit more on screen resolution | BAGELS::BRANNON | Dave Brannon | Wed Feb 04 1987 12:22 | 24 | 
|  |     re:.-1 
    Oops, forgot about the fonts.  Thanks.
    note 293.5 reposted (corrected re: comments in .-1)
    re: .3
    
    the Amiga Workbench screen has 4 colors (2 bit planes) at
    640x200 resolution.  The default as shipped from Amiga uses a
    60 column font.  That default can be changed to an 80 column
    font using Preferences.  With the Workbench V1.2 you can also 
    set the default workbench screen to 640x400.
    
    screen memory usage:
        640x200= 16K bytes per bit plane, thus 32K
        640x400= 32K bytes per bit plane, thus 64K
        for a 4 color (2 bit planes) workbench screen.
    
    The Amiga uses 32K to display the 3 ST resolutions/colors, same
    as the ST.
    
    -dave
 |