Conference hydra::amiga_v1

    Under v1.3 I had installed a rather old version of AREXX.  2.0 Install
    put all the standard AREXX stuff into various directories from the new
    distribution.  However, something went wrong -- during bootup, REXXmast
    crashes with error code 80000003.
    
    The two AREXX libraries on my hard drive are the same version as on the
    2.04 distribution floppy.  I have a 3 meg 2000 with a GVP II hard drive
    controller.  Does anybody have any idea what went wrong?  Where to look
    for other AREXX-related files that might not have been updated?
    
    Wes

    I have several utilities I run in my startup sequence that "enhance"
    the V2.04 package:
    
    ToolManager V1.5       This adds my tools to the tools menu. For 1.3
    			   users, this performs functionality similar to
    			   the program HandyIcons.
    
    ARQ V1.61              This is a slick animated filerequester
    			   replacement!!
    
    
    STARBURST		   This adds * (wildcard) functionality to V2.04.
    
    AWP			   This animates the busy clock with moving hands.

>    I have several utilities I run in my startup sequence that "enhance"
>    the V2.04 package:
    
>    ToolManager V1.5       This adds my tools to the tools menu. For 1.3
>    			   users, this performs functionality similar to
>    			   the program HandyIcons.

I recommend this also. I wish, however, that there was a way to add 
additional menu's. I think that it is real slick how you can just drag 
the icon of the program that you want in your tool menu into the 
toolmanager menu and it automagically puts it into the menu for you.
    
>    ARQ V1.61             This is a slick animated filerequester
>    			   replacement!!
 
I've had problems with this when you get a series of requestors in a row 
(for instance if you have a bad spot on your disk and you get 
successive read errors). The animated part of the requestor eventually 
stops and you can't get rid of the requestor. I don't know which version 
of this I was running though.   
    
>    STARBURST		   This adds * (wildcard) functionality to V2.04.

Can you upload this or point us to where we might find it.
    
>    AWP		   This animates the busy clock with moving hands.

Much better than the standard busy clock.

In addition:

	FRACBLANK	Fractal screen blanker. Excellent commodities 
			implementation. FPU version included.

    
    The files are on EOT::

    No-one appears to have done the upgrade on a (B2000) PAL Amiga.
    
    Will it be as simple an upgrade - nothing else to change etc etc etc
    My machine sports a GVP 3001 (030 with 4mb), GVPseries II (with Quantum
    40mb and 2mb ram), a C= A2320 (flicker fixer). Any problems with this
    combination???
    
    If all looks ok I will try and get the upgrade in  the next few days..
    regards
    kevin

  >>No-one appears to have done the upgrade on a (B2000) PAL Amiga.

I have installed a switch to change between PAL and NTSC.  I am 
usually running in PAL mode using PAL Hires 640X256.  I guess I need 
to go back to NTSC mode to see what it looks like.  With 1.3 it was just 
a matter or flipping a switch and rebooting.  With 2.0 you will need to 
change the display mode flip the switch and reboot.

     

>  With 2.0 you will need to change the display mode flip the switch and reboot.

Eh? Not so. With 2.04, etc. Just change the screen mode preferences to be PAL
and you should be set. No physical switch or reeboot is necessary. If you save
the change it will be remembered across reboots.

	-SES

    RE: .5   The GVP procedure is pretty easy. After installing 2.04,
             modify your mountlist as described in the 2.04 manual,
             and remove l:fastfilesystem. Reboot and debug. Now back up your 
             hard drive. Use the supplied HDbackup utility. After completing 
             the backup, go into GVPTools and run Faaastprep. Select MANUAL, and
             click on WRITE. The requester will ask if you want to use the 
             V2 fastfilesystem. Answer yes of course. The new RDB will be
             written. Exit out of Faaastprep, and use the FORMAT command
             in your new SYSTEM directory to format your drive. Now restore
             your files to the drive.
    
     

    With V2.04, it takes anywhere from 10-15 seconds my prompt to appear
    when I access a new shell. I experienced no such delay with V1.3.3.
    My shell-startup file is only about 40 lines. Is the system accessing
    the ALIAS command each time it encounters it on each line of the file?
    

    re: .8
    
    As suggested elsewhere, could we please keep this note for OS
    installation stuff, and discuss tools and applications in another new
    note?  (Not a flame, Reg, but I find digging through old notes for
    material that doesn't fit the title to be a royal pain.)
    
    Wes

    
    I did my installation of 2.04 last night.  I didn't have a chance to
    look or make any changes to my mount lists and was wondering what 
    will happen if I leave it as it is. I have a 2000 Rev6, A2091/50meg
    and a 2090 controller with a st225 drive. The 20meg is running the 
    old file system. the 2091/drive is running whatever the install disk
    set it at.  Am I going to run into some problems ? Should I make
    the 20meg work on the 2.04 FFS or just leave it on the old file sys.

    Bob

    PS.  One other thing, I tried to print a DPaint III file twice last
    night and the system crashed both times. I never had this problem
    with DPaint before I switch to 2.04.  Has anyone else had this
    problem ?  I'm using the HP II driver.  

    RE: .12 the drives you have are not running the new V2.04 FFS unless
    you do the following two things:
    
    o  Remove all references to l:fastfilesystem from your mountlist
       and make other changes as defined in the 2.04 docs
    
    o  Rewrite your RDB on the hard drives with the new FFS and reformat
       them.
    
    As the docs mention, you shoulkd see a 50% increase in hard disk
    performance over V1.3 with the new 2.04 FFS.
    

Re: .11

Don't create a new note please, the note already exists (4864.0).

Am I right in assuming that after upgrading to 2.04 with a hard disk, that
there is no going back to 1.3 while using the disk?

What I don't want is a surprise after upgrading, that something important
doesn't work right, with no easy way to go back.  I could work around a
lot, but my son wouldn't be pleased if he couldn't get his homework done
until receiving an update to something like Excellence, or to some PD thing.

I had been giving thoughts to getting one of the ROM switches in case
significant things failed to work, but I doubt I would incur the expense if
the use is limited to things running off floppy, like games.

	Paul

    One thing that _might_ work is to install WB2.0 on 1 partition,
    and then WB1.3 on another.  Then you could boot off of either a 
    1.3 or 2.0 floppy, and transfer control to the proper partition.
    Naturally the 1.3 partition would have to use the "old" FFS. 
    
    It would be a little clumsy, but should be ok.  The one thing to 
    watch is the potential problems running 1.3 using the 2.0 ROMs.
    That's when the ROM switch would be real handy.
    
    Since I made the jump from 1.2 ROMs to 2.0 ROMs, I would like to now
    autoboot from the HD.  I am going to forgoe the backup/reformat
    because I can live without the new FFS for the time being. (I'm
    planning on a new drive shortly).  Do I have to do anything special
    to my current drive, or just set the "autoboot" jumper on my
    HardFrame?  Could it really be that easy, or should I just wait until
    I get a new drive?
    
    Overall, I'm really impressed with 2.0.  The installation procedure
    was really a breeze.  I actually played around a lot with the floppy
    based version before installing it on the HD.  The install copies
    your tailored environment from the floppy to the HD, so no worry about
    losing some customization.
    
    Steve

    I am starting to notice unusual V2.04 behavior. The first was the slow
    appearance of the prompt on new shells with long shell-startup files.
    Now I notice that text scrolls extremely slowly when shells are popped
    up to full-screen size. The scroll rate decreases dramatically. Also,
    some programs do not like to be started in the startup-sequence, but
    rather in the wbstartup directory. Anyone else notice these performance
    problems?
    

Actually, I think that the V2.04 performance is better than V1.3.  At
least is "feels" that way to me.  My shell-startup is pretty long (~100
lines) and I never see a delay when starting a new shell.  Maybe
a split second, or about the time it takes to move the pointer to
the new window.  Could you have another 0 priority task thats stealing
cycles? 

Text does scroll slower in the full-size shell windows, but that's
expected since the machine may be scrolling several times as much
data (especially when interlaced).  Stick with 2 bitplanes, and the 
speed is reasonable.  I'm also using a 13 pixel font, so there are 
actually less rows to scroll than for the standard 8 pixel font.  
It's faster and easier on my eyes. :^) 

I haven't experienced any startup problems, but the docs state that
you should basically "leave s:Startup-Sequence alone", and add your
specific startup commands to "s:User-Startup".  I'm not positive how 
it searches, but it seems to go Startup-Sequence -> User-Startup ->
WBstartup.  I also use the PD 'runback' in my user-startup because 'run' 
programs won't allow their "parent" to exit, until the children all
exit.

If you've got a 020/030, and 1/2M to spare, make sure to use 
> CPU fastrom.  This is the official version of SetCPU, and can really
speed up ROM based functions. 

Steve 

I agree with Steve, 2.04 is (or at least seems) much faster. I have even been
running with an 8 color (3 plane) WB and windowing is pretty quick.

One thing I don't like is the performance of the AutoPoint commodity. It seems
to take too long to switch focus to the window with the pointer...

john

>  I also use the PD 'runback' in my user-startup because 'run' 
>  programs won't allow their "parent" to exit, until the children all
>  exit.

In V2.0? you can use "run >NIL: <NIL: program" to get the same effect
as runback.

	-SES

re. -1

>In V2.0? you can use "run >NIL: <NIL: program" to get the same effect
>as runback.

Ok, I'll give that a try.

re. -2 

The thing that I have noticed about AutoFocus, and it took me a while
to get used to it - is that the Window doesn't become focused when
you _enter_ the window, but when your mouse ptr _stops_ in a window.

Now that I'm used to it, it seems to make sense, and I like it.
It's probably more efficient to implement as well.

Steve

  The thing that I have noticed about AutoFocus, and it took me a while
  to get used to it - is that the Window doesn't become focused when
  you _enter_ the window, but when your mouse ptr _stops_ in a window.

There is also some wierd interaction with key/buttons - I believe you
have to release them all before it changes focus.

Performance was the reason for the change, though. With the new solid
borders and 3d-gadgetry, redrawing every window as you passed over it
could take a *lot* of time. At one point, CATS recommended that autopoint
not be used with unaccelerated amigas.

	<mike

ClockDJ (or is it DJclock?), supports a much better (and faster) autopoint
option and works under 2.04 (just put it in the WBstartup drawer). Since it's
small and has all my desired commodities built into it, I still use it.

    I too notice a delay when starting new shell window (my shell-startup
    is pretty huge) but I noticed the same delay in v1.3 also.  I was
    reading the AmigaDOS manual last night and they mentioned that the RUN
    >NIL: command is what you want to free up the shell.  I do not know
    about the < NIL: portion, though.
    
    mark
    

> Performance was the reason for the change, though. With the new solid
> borders and 3d-gadgetry, redrawing every window as you passed over it
> could take a *lot* of time. At one point, CATS recommended that autopoint
> not be used with unaccelerated amigas.

Interesting. I'll have to try QMouse (what I used under 1.3) to see how it
behaves. I've tried to swear off all non-2.0 conformant hacks :-)

Here's another one:

In prefs->screenmode I set up an interlace workbench. When I boot, WB comes up
as the 640x400 standard screen and I get this requestor saying "close all 
windows for changes to take effect). The requestor pops up and goes away a few
times during boot (WB is still at 640x400) until boot is finished and startup
CLI goes away. Then I close (HIDE) the little BLANKER window and click 
RETRY on the screen mode requestor and the WB resizes to 704x470 and all is
happy. 

With more rows on 1.3 the WB came up in the right size at boot.

john

  In prefs->screenmode I set up an interlace workbench. When I boot, WB comes up
  as the 640x400 standard screen and I get this requestor saying "close all 
  windows for changes to take effect). The requestor pops up and goes away a few
  times during boot (WB is still at 640x400) until boot is finished and startup
  CLI goes away. Then I close (HIDE) the little BLANKER window and click 
  RETRY on the screen mode requestor and the WB resizes to 704x470 and all is
  happy. 

Did you futz with s:startup-sequence? It sounds like it. Or maybe you are
booting a floppy installed with 1.3 and not 2.0?

2.0 tries to keep the WB screen closed until something outputs to it. This
allows Iprefs (I believe I've got the name right) to set the WB screen
mode while it is still closed. The standard s:startup-sequence makes that
all work right. If you have something that causes a window to open on the
WB screen (i.e. - it opens it itself, or triggers the auto-open of the
default shell window) before iprefs runs, then you get the default screen,
and iprefs will cause the WB to try and change to the mode you selected.

This behavior goes away if you have a 1.3 boot disk. In that case, WB opens
like it did with 1.3. This allows programs that used the WB bitmaps on boot
to keep working on 2.0. It also causes 2.0 disks to look like they have a
virus, and could cause the behavior you see (I've never tried it).

You can get the blanker window to never open by setting the tooltype
CX_POPUP=NO (double check the manuals, though). BTW, I prefer the commodites
to ClockDJ; the exchange program provides a simple and convenient interface
for dealing with all of them at once. It does cost more memory, though.

	<mike

> Did you futz with s:startup-sequence? It sounds like it. Or maybe you are
> booting a floppy installed with 1.3 and not 2.0?

That's it. Thanks Mike. 

I had to modify s:startup-sequence to add Hurricane 030 non-autoconfig memory
support. Will redirecting the output of anything that runs before iprefs
to NIL: be sufficient?

I hated to invade the new sanctity of s:startup-sequence, but it was necessary.

john

Way back when it was rumored that 2.0 would allow you to change the device
for the PRT: from Parralel.device to what ever device you needed.  I cannot 
find anything in the docs.  But then it could have been a unfounded rumor.

I would like to use device 0 of my Eightbit.device as my default PRT:

Am I dreaming?

Alan

Re: >nil: and s:startup-sequence.

Yes, that should do the trick. You might redirection input while you're at
it.

Re: PRT: and Eightbit.device.

PRT: has always been able to use either parallel.device or serial.device,
unit 0. With 2.0, the serial device allows you to chose which serial
port will be unit 0. This is probably what was referred to. The 2.0
RKM: Devices doesn't mention any such magic for the parallel.device,
so alternative parallel devices are out of luck.

	<mike

Thanks Mike

Thats what I was afraid of.  Thats the nice thing about rumors (even documented 
rumors).  They do not have to really happen when the real product comes out.

I picked up a MultiKick II yesterday and installed it last night. It allows
you to very easily switch between 2 (or 3) ROMs. You can select which ROM
you want to use by default, and to switch to the other you just hold down
ctrl-A-A for more than 5 seconds when you reboot. I works really great.
For me its a must, since I have found a number of games and other goodies
that don't like 2.0.

Now, the fun part is setting up your hard disk so that it will use the
appropriate software based upon which ROM version you booted with. They
gave some examples in the book that came with the ROM switch, but they
didn't work too well. I finally (after much work) got it to work (sort of).

Has anyone else done this, and if so, how did you set things up? I ended
up making a small partition with the 1.3 stuff in it. 2.0 is the default.

I have a modified startup-sequence that checks the ROM version on boot,
and if its 1.3, redefines the system logicals to the 1.3 partition.
It then transfers to the appropriate startup-sequence for the OS being
booted. The problems I ran into was that I could not use any 2.0 progs in the
startup-sequence because they would not run under the 1.3 rom. So, I copied
the ones I needed from 1.3 into s: and used them. Also, if I am booting
1.3, the system uses the 2.0 preferences settings (since I assume that
those are being set earlier on in the boot sequence). I have a random
setprefs program that I run to set than to the correct system-configuration.
I also run an interlaced workbench on 2.0, but not on 1.3, and 1.3 comes
up interlaced, so again I need to run a program to turn off interlace.
Unfortunatly, workbench still thinks its running with a 640 x 400 screen
size. Sigh.

Anyone got any better ideas on how to do all this?

Frank

    I tried this and it doesn't seem to work:
    
    From:	com%"[email protected]"  4-NOV-1991
    17:31:55.47
    To:	[email protected]
    CC:	
    Subj:	RE: 386 clones vs. A3000 -- and hint to Cmdre
     
    Received: From RUTVM1(MAILER) by UDCVAX with Jnet id 2114
              for JGRAHAM@UDCVAX; Mon,  4 Nov 91 17:31 EST
    Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.08) with BSMTP
    id 0907;
     Mon, 04 Nov 91 13:07:14 EST
    Received: from rutgers.edu by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX)
    with
     TCP; Mon, 04 Nov 91 13:07:13 EST
    Received: from cbmvax.UUCP by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) with
    UUCP
    	id AA02946; Mon, 4 Nov 91 12:19:07 EST
    Received: by cbmvax.cbm.commodore.com (5.57/UUCP-Project/Commodore
    2/8/91)
    	id AA21724; Mon, 4 Nov 91 12:12:06 EST
    Date: Mon, 4 Nov 91 12:12:06 EST
    From: [email protected] (Dave Haynie)
    Message-Id: <[email protected]>
    To: [email protected]
    Subject: RE: 386 clones vs. A3000 -- and hint to Cmdre
     
    Rev 6 ROMs have been available as a replacement part for around six
    months to
    a year, last I heard.  How does that equate to "no Rev6 roms to be
    had".  Your
    dealer may not necessarily stock them next to the 2.0 upgrade kit, but
    that's
    not to say they're hard to get.  It's unfortunate that previous ROMs
    had this
    bug, but that's the way things go.  Unless you have a Rev 6 or later
    ROM, you
    can't boot 2.0 from ROM with an A26x0, plain and simple.  With a
    kickstart
    image on hard disk, SetCPU V1.6 will boot your 2.  ROM.
     
    Without the kickstart disk provided, I guess you'd have to download
    kickstart
    from the ROM into a disk file and boot from there.  Since the A26x0 do
    boot
    in 68000 mode, this is possible.  Install the ROM in the system, boot
    with the
    two mouse buttons down, select 68000 mode.  Since all A26x0 resources
    go away
    with 68000 mode, you should properly boot into 2.0.  From here, run a
    program
    that downloads 2.0 to a file, something like this would work in C:
     
    #include <stdio.h>
     
    void main(int argc, char *argv) {
       FILE *f = fopen("sys:kickstart2.04","w");
       char *r = (char *)0x00f80000L;
     
       if (!f) {
          printf("Can't get file or RAM\n");
          exit(10);
       }
     
       fwrite(r, 0x80000L, 1L, f);
       fclose(f);
    }
     
    Now, you need SetCPU and some changes to your Startup-Sequence.  What
    you
    end up with are two startups, the boot startup that gets you into 2.0,
    and
    the real 2.0 startup.  It goes something like this:
     
     
    version >NIL: exec.library 37
    IF WARN
       SetCPU KICKROM sys:kickstart2.04
       ; should never get here...
    ELSE
       execute s:Startup-2.0
    ENDIF
     
    Anyway, you get the idea.  With this in place, and 2.0 installed on
    your
    boot disk, you should be able to reset and boot straight into 2.0 under
    '030
    control.  It's not as fast a reboot as straight from ROM, but that's
    still
    the way I yun 2.0 on my office A2500, as I've been too lazy to update
    the
    A26x0 and kickstart ROMs.  I actually have 1.3 on the boot partition,
    2.0 on a
    different partition; an artifact of the 2.0 testing days, I never use
    1.3 any
    more.  My "ELSE" clause above uses my BindNames program to push the 2.0
    environment over to a different partition before calling the
    Startup-Sequence
     or 2.0, and it used to have an "Ask" command that let me choose
    whether to
    boot 2.0 or not.
     
    Anyway, that's my workaround, and it's proven.  Still, I recommend the
    ROMs if
    you're doing much rebooting, since they'll be faster.
     
    					-Dave Haynie
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    

>    I tried this and it doesn't seem to work:

What happens?

    Well, first of all, running SETCPU16 KICKROM KICKSTART2.04 does nothing
    more than tell me I am in 68000 mode. It doesn't load anything. If I
    read the docs correctly on SETCPU, KICKROM only works when run from
    68020/30 mode.

    re: .32
    
    System Eyes ordered the updated A2620/A2630 ROMs along with the 2.0
    update kits.  System Eyes is still waiting for the new ROMs.
        John Sauter 

>    Well, first of all, running SETCPU16 KICKROM KICKSTART2.04 does nothing
>    more than tell me I am in 68000 mode. It doesn't load anything. If I
>    read the docs correctly on SETCPU, KICKROM only works when run from
>    68020/30 mode.

You *are* booting in 030 mode (dumb question, I know) right?

What does SETCPU16 by itself output?  Are you running enforcer? I think
it steels the MMU...

john

Re: .34

I think that you have to install the 2.0 ROM, boot the machine in 68000
mode, make the Kickstart image file, remove the 2.0 ROM, install the 1.3 ROM.

After that, let the machine boot normally in 68020 or 68030 mode under
under 1.3.  Your startup-sequence runs SetCPU and reboots you under 2.0.

I am having a real strange problem with 2.04. I cannot get either the
click to front or autopoint commodities to work. I start them up
(commodities exchange shows they are running and enabled) but nothing
happens. I can double click in a window and it becomes active, but does
not come to the front. And moving the pointer into a window does not
make it active? I have no idea whats going on here? Is there some
magic incantation I need to do over my 2000 in order for this to work?
I have read other notes in here that others have had these work fine for
them so I guess it must be me. The other commodities work fine.

Any ideas?

Frank

    
    Frank,
    
    I don't have the docs here but I ran into the same problem.
    I think the problem with click window to front is that the default
    setting has a qualifier attached to it (I think it's the alt key
    but don't remeber for sure.  You can also remove the qualifier 
    (I also can't remember of hand) what magic does that but it's
    an option in one of the requesters having to do with the commodity.
    
    Not sure about autopoint.  I don't use it but it seemed to work for
    me.  I think the button is a toggle, perhaps you did an on/off by
    accident.
    
    Frank
    

Does anyone know what the WBConfig program is? It's mentioned in the docs 
(I think  around the section on the shell in the AmigaDOS chapter). Seems
like a feature that was in the docs, but removed from final release?

Maybe it's functionality is now in other places. The one thing I recall it
doind was to allow the "double click to front" feature, which the ClickToFront
commodity does...

john

A little later in the manual it mentions that the WBConfig function was
moved into the commodities exchange.

I spent a little time poking around for it to.

Has any one opened the directory Utilities/test on the W2.0install floppie.

Interesting ICON to be found there.

Absolutely right - check the icon for click-to-front; there should be a
tooltype that sets the qualifier. If you don't want a qualifier, either
delete the tooltype, or change it so it isn't recognized.

Remember that autopoint doesn't activate a window until the mouse has
stopped moving. This means you don't get window borders flashing at you
(and the moving intolerably slow on 68000 machines) as you cross a
bunch of windows.

	<mike

> Remember that autopoint doesn't activate a window until the mouse has
> stopped moving. This means you don't get window borders flashing at you
> (and the moving intolerably slow on 68000 machines) as you cross a
> bunch of windows.

But I *liked* the flashing. And I liked the performance of zipping the 
mouse to a window and typing, not having to wait.

john

I guess I should have said that I did remove the qualifier on click-to-front.
You change the tooltype to qualifier=NONE. It still did not work. Also, as I
stated before, autopoint does not work either, even after I stop moving the
mouse. Commodities exchange shows both commodities active and enabled, but
they do nothing! I am beginning to wonder if I have something bad in my kit.
I have booted from the 2.0 workbench floppy and they still don't work. Sigh.
I want my click-to-front!

Frank

re .41:

> Has any one opened the directory Utilities/test on the W2.0install floppie.
> 
> Interesting ICON to be found there.

I looked on my Install floppy, and found no Utilities/test directory...

Are there different 2.0 distribution kits???

    I was running from memory again.  Its in the Tools directory of the
    WB2.0 install floppy.  the Full path is 2.0install:Tools/test
    
    There is no Test.info so you need show all to open the drawer.
    
    

    I just installed V2.04.  I had asked Paragon the dealer if there were
    any problems reported with Wordperfect and 2.04, he said no.  Well I
    now have one upset son.  
    
    When I try to boot up Wordperfect this is what happens
    
    It starts to boot and brings up the header
    
    WORDPERFECT
    V4.1 JAN 5 1988
    COPYWRIGHT 1987 WORDPERFECT CORP
    
    wp:file is not executable
    WP failed return code 10
    >1
    
    That is as far as it goes.  I can type in at the >1 prompt.
    
    Does anyone have any idea how to get WORDPERFECT RUNNING or has anyone
    else seen this problem or used WORDPERFECT after upgrading to 2.04?
    My son has a report due in a couple of days, if I can't get this
    working I will have to put 1.2 rom back in.
    
    Thanks.

If there is some sort of startup file (of its own startup-sequence) you may
have to edit it. As stated in the 2.04 documentation, some of the commands
that used to be in the c: directory are now resident commands. If you have
scripts that reference these commands as c:mumble then they will fail since
the file will not be found. You fix it by removing the c: and just using
mumble. I can't remember if there were some other gotchas as well. Check
it out.

Frank

                       -< Switching between 1.3 and 2.0 >-

I installed a MultiKick II in my 2000, in anticipation of getting my 2.0 ROM
and it seems to be causing some problems. 

With it installed I get random gurus, B.somethingorother, on the order of
every few minutes, once even before it got through a warm reboot from the last
guru.-(   I replaced the original ROM and all seemed well.

Looking at the board, there is no ground plane, no extra wide etch for power 
or ground, no apparent bypass caps for the ROM, so I'm thinking it might be 
the added couple of inches of bare wire on all the leads.  (I installed the 
1.3 ROM in the "middle" socket, apparently that's standard procedure.)

I'm running with a GVP 030 33Mhz series 1 exhilerator, didn't try it in 
vanilla mode.

I'm planning on adding some bypass caps to the bottom of the board right at 
the ROM socket to see if that clears it up (Thanks, CA for providing 
schematics!)  Has anyone else experienced this and maybe solved the problem?

Thanks, 

Jim

p.s.  I also got the DKB 2Meg chip RAM add on.  Works okay, though things seem 
maybe just a tad touchier.  The dangerous thing about this is that the bottom 
of the board mounts scarcely 1/16 inch from the bottom of the power supply, 
and as the *only* mounting support is the Agnus socket at one end of the 
cantilevered board, there is a great risk of shorting to the chassis.  I'd 
recommend affixing a sheet of mylar or kapton or similar to the bottom of the 
board.  I also had to reroute a cable that wants to pass that way as it kept 
disloging the board and giving me green screen.

Cheers!

re: Note 5164.49 by TFH::KIRK "a simple song" 

>I'm planning on adding some bypass caps to the bottom of the board right at 
>the ROM socket to see if that clears it up 

That the ROM socket on the Multi-Kick board, btw.

Jim

> p.s.  I also got the DKB 2Meg chip RAM add on.  Works okay, though things
> seem  maybe just a tad touchier.

Can you be more specific?  What do you mean by touchier?

I am interested in this, but was told by Roy at Memory Location that Don
had tried one and had trouble with Excellence.  In general the idea seems
good but perhaps the execution of it isn't.

I read something somewhere which lead me to believe that a competitive
product is on the way.  Also, with Commodore releasing the 500+, I wonder
if they have their own solution for the 2000 coming.

> The dangerous thing about this is that the
> bottom  of the board mounts scarcely 1/16 inch from the bottom of the power supply,
  ^^^^^^^^^^^^^^^^^^^^                                    ^^^^^^^^^^^^^^^^^^^^^

I haven't seen the setup, but this doesn't make sense to me.  Do you mean
bottom to top, top to bottom, or what?

This sounds like it might not be the best thing for installation by someone
with no hardware knowledge.  Is this a reasonable inference from your
remarks?

	Paul

	I have a question about the new features in 2.0. There are some new
gadgets, such as scrolling lists and radio buttons. The question is: if one were
to use these gadgets, is there any provision to make the application work
under 1.3? Perhaps a new library for 1.3 users.

	The style guide encourages developers to use the new features, but I
don't see how a developer could survive if (s|%)he excluded the 1.3 installed 
base. The prospect of distributing 2 versions or writing to the least common
denominator is not very appealing.

There's a commercial library you can use to get much of the 2.0 functionality
in 1.3. There are people using it.

I've seen people take all the approaches you mention for 2.0 vs. 1.3. There
was a 2.0-only backup system before the 2.0 roms were released. I believe
they decided that they couldn't deal with that, and converted it to 1.3
and sell two versions. Distant Suns 4 is 1.3 only; after you get it you
can order the 2.0 version. I believe most people are still writing for 1.3,
with lots hooks to use the 2.0 stuff if they're on 2.0.

	<mike

	Do you happen to know the name of the commercial library? I am very
enthused about the style guide. It's really good. If all future applications
followed it, the state of Amiga software would be elevated several notches.
Without a clean solution to the 1.3 compatibility problem, this is considerably
less likely.

re: Note 5164.51 by Paul Kyzivat

Hi Paul,

By touchier I meant that my Amiga *seems* to guru or act up a little more 
often: 

sometimes the DPaint3 file requester doesn't list my DH0: disk, (it's there,
there's just not a button for it in the requester, there'a a "PAR:" button
instead), re-boot and "DH0:" is back... 

or I'll get "memory smashed" errors, after playing an anim in DPaint, which
I'd never seen before adding the chip RAM.

or some random streaks on my workbench screen, which go away if I move windows
around so it has to repaint them, (but by the time that happens, it's sure to
guru after a bit more use...) 

None of this happens real often, and I'm not sure the added chip RAM caused
it, but I started noticing that after installation.  (I'm probably doing more
multitasking things with it, since I have the added space, so maybe something
isn't behaving well.  I try to use reputable software, but nothing's
guarenteed 100%. 

>I haven't seen the setup, but this doesn't make sense to me.  Do you mean
>bottom to top, top to bottom, or what?

The board is mounted chip side down:

|                                          |
|                                          | <- power supply chassis
|__________________________________________| 
      ==|=========|====|===|=====|===|==     <- board with IC leads pointing up 
        |         |    `[_]'     `[_]'       <- added meg of chip RAM
        |         |
========'         `==============================  <-  mother board
       Agnus socket

The installation is "simple", once you remove the old Agnus chip (keep it as a 
spare) you just plug this square plastic block that's mounted on the board
into the empty socket and attach a clip lead to a pin (on the Dennis chip, I 
think).  There's a bunch of leads that go up the sides of the black plastic
block that solder into the board making the connection to the mother board.

The real problem is that the socket is the only mechanical support that this 
board gets, and it is physically very close to the metal chassis, so any 
jarring or shifting and it's short-city.  When I installed mine, I took one 
look and figured there was danger of a short, so yes, if someone does not 
understand what can happen when you inadvertantly ground things, I'd caution 
against installing it yourself.

Alas, even if it is professionally done according to the directions, one is 
left in the same predicament.  You really need to add some insulating material 
between the lead side of the board and the power supply!

And, last night, after many more frustrating green screens, I think I'm going 
to try to add some more mounting support for the board.  The concept is nice, 
but the execution just isn't up to snuff.  (I didn't even get a chance to try 
adding some bypassing to the Multi-start board.  I have to go to Wellseley 
thins Monday anyway, so I think I'll stop by the Memory Location and hear what 
they have to say.

Hope this clears things up.

Cheers,

Jim

> The concept is nice,  but the execution just isn't up to snuff.

I get the idea.  I think I will wait for something executed a bit better,
and just go for the 1meg Agnus now.

Thanks for the review.

	Paul

    >The concept is nice, but hte execution just isn't up to snuff.
    
    Maybe this doesn't belong here, since I don't run it with 2.04, but I
    bought a 2MB Chipram last May and it's one of the best investments for
    heavy graphics and multitasking I have made.  Significantly less gurus
    than ever before.  I have found no software which misbehaves (with 1.3
    ROM).  Installation was a breeze.  See my notes 4389.12 & .19 for more
    details.  DpaintIII is a lot more fun with lots of chipram.
    
    Terry
    

    Solution to reply .1
    
    REXXmast crashed on my system during bootup with error 80000003.  Turns
    out that my older Bill Hawes AREXX distribution put this program in the
    c: directory, while the new 2.04 puts it into sys:system.  Deleting the
    version in c: cured the problem.
    
    Wes

    There are 3 or 4 associated programs (c:RX*) which should be removed as
    well.  Current versions reside in RexxC.

    
    
    
    For those looking for the rev -06 roms for their A2620/30...
    
    
    I found a source for -06 roms that actually have them in stock!  I have
    2 sets on the way and will only need one set (I ordered 2 since I am 
    paranoid and don't want to wait if one set is bad).
    
    Software Hut  (Philly)
    1-800-848-0079
    
    
    
    

Amiga 2000 ICD Advantage 2000 Hard Disk controller. WB2.04

I really did it this weekend.  I was attempting to mount a ST225/Adaptec4000 
under CrossDos and To do this I needed to keep the drive from Automouining. 
I was unsuccessful.  But to make things worse when I attempted to reboot my 
Amiga crashed 8100 000C.  I am assuming C is the Fast File system in ROM. My
Guru guide (1.2 Vintage) only goes to B.  

If I were to boot a Standalone floppy while keeping the Hard disk turned off
(left mouse button down) it would boot I then could use the Formatter (v2.10)
software to mount the patritions.  I restored the 1.3 system and selected the 
1.3 boot rom every thing runs.  Amiga Dos 2.0 would boot (Part way) with the 
1.3 rom.  2.0 would not boot with the hard disk.

I dialed into the ICD Bullitan board and they had the Answer.

I needed to delete the ICDDIsk.device from the formatter floppy and then do 
a SAVE for the disk drives.  This is their methed of removing referances to 
L:Fastfilesystem (my guess).

About three weeks ago I realized that my hardisk did not have the 
ICDDISK.device so I copied it over.  Talk about induced time bombs.    

Does any one know of a Harddisk controller (with RDB) that works with 
Cross Dos.  And has any owner of the ICD advantege gotten a disk marked as SKIP 
to mount with the amiga DOs Mount command.  I get an error cannot obtain disk 
information when I try any access after a mount.  The Format command fails
writing the first Cyl.

Cross Dos MFormat fails with a -3 error (not supported). 

    Re .61:
    
>   Does any one know of a Harddisk controller (with RDB) that works with 
>   Cross Dos.  And has any owner of the ICD advantege gotten a disk marked
>   as SKIP to mount with the amiga DOs Mount command.  I get an error
>   cannot obtain disk information when I try any access after a mount. 
>   The Format command fails writing the first Cyl.
    
    My A590 (equivalent to the A2091) supports RDB and APPEARS to get my
    MS-DOS partitions mounted.  Unfortunately, MS-DOS V5 (under ATonce) and
    CrossDOS V4 don't agree about the validity of the partitions thus
    mounted.  I can format the partition under CrossDOS, but MS-DOS doesn't
    like it, and conversely.
    
    I've fallen back to mounting the partitions from the startup-sequence
    (allowing me to fiddle with the mountlist).  I still have some serious
    debugging to do before I'll be able to share them between environments.

The RDB has a bit in it to tell it not to automount. This can be set using the
Microbotics RDPrep program.

My original note is .38

I am still having problems getting CLICKTOFRONT and AUTOPOINT to work. I posted
a note to usenet to see if I am the only one, and appearantly I am NOT! Here
is my posting and the first reply:

----------------------------------------------
Article: 11808
From: [email protected] (Frank W. Ries Jr.)
Newsgroups: comp.sys.amiga.misc,comp.sys.amiga.hardware,comp.sys.amiga.programmer
Subject: Problems with ClickToFront and Autopoint - Commadore...please help!
Date: 5 Dec 91 00:05:44 GMT
Sender: [email protected]
Organization: Digital Equipment Corporation
 
I have been unable to get the CLICK TO FRONT and AUTOPOINT commodities
to work under 2.04.
 
I posted a note on this subject a couple of weeks ago and did get direct
mail responses from a few folks. I'd like to thank them for taking the
time to respond. Our newserver was down for awhile, so I may have missed
some replies here.
 
However, I have still not been able to figure out why they do not work.
I can run them, and they show up as enabled under commodities exchange,
but they do absolutely nothing!!!!!!!!!!!!!!!!!!!
 
I know that I am doing the right things to both start, and activate them.
It doesn't matter what I have set the qualifier to in CLICK TO FRONT. I
even set it to NONE and still, double clicking in the window does NOT
bring the window to the front. Starting AUTOPOINT and moving the pointer
over a window DOES NOT active it.
 
Now I know that these commodities seem to be working fine for others,
so the question is, why don't they work for me?
 
I am running on a A2500/30 with a 2091 disk controller and a number
of other option cards, and a 1MB Agnus. Nothing odd here.
 
I have tried everything I can think of. I have tried removing all
the option modules, booting from the 68000, and booting directly
from the 2.04 distribution floppies, and still they do not work.
 
As a last resort, I took my distribution floppies to my local
dealer, and booted them on their A3000 (unfortunatly they do
not have a 2000 with 2.04), and surprise, both commodities
worked fine! So, either they don't like the "2.04" in my ROMs,
or they don't like my rev 4.2 A2000. I didn't check, but I'm
sure that the A3000 was not running 2.04, but some earlier
version of 2.0.
 
Unfortunatly, my dealer had no words of wisdom on this matter,
and did not act in the least bit interested in helping (as is
the normal case). So my question still remains, WHAT IS THE
PROBLEM HERE! Is there anyone else out there in netland who
has had the same problem?
 
Commadore, if you are listening, can you please help me?
 
I don't even know who to try and contact within Commadore about
this, my dealer just chuckles when I ask him. He doesn't seem
to have much confidance in them. (What's worst is he just
started to carry PC's, and they ain't made by Commadore).
 
Frank Ries

Article: 11866
From: [email protected] (Chris Peck)
Newsgroups: comp.sys.amiga.misc
Subject: Re: Problems with ClickToFront and Autopoint - Commadore...please help!
Date: 5 Dec 91 15:42:36 GMT
Sender: chris@zork (Chris Peck)
Organization: State University of New York at Binghamton
 
In article <[email protected]>, [email protected] (Frank W. Ries Jr.) writes:
|> 
|> I have been unable to get the CLICK TO FRONT and AUTOPOINT commodities
|> to work under 2.04.
 
Well - you're not alone - there are 4 of us here at work who cannot get
Click-to front to work either.  I installed tofront&back (from ab20) and a
friend uses Dmouse to do this.  Perhaps there were some changes in the "final"
code of the 2.04 ROMs just before burn-in????  Or perhaps, none of us know
what we're doing....
-- 
 
[email protected]      Chris Peck
[email protected]  SUNY Binghamton, NY
--"Any opinions expressed above are mine, ALL MINE!"--

-------------------------------------------------------------------------

By the way, I have had problems with a couple of other utilities under 2.04
as well.

ICONX will not always close its window after an application exits. In fact,
most of the time it will not close its window. I can click on the close
button, pound control-c, nothing. Also, the documentation (which is almost
a clone of the 1.3 doc) for iconx says that DELAY= is used to specify a
time in SECONDS to wait after the app. exists before closing the window.
In 2.0, as well as 1.3, this time seems to be in ticks! It says setting
DELAY=0 will keep the window open till you enter control-c, wrong, it
waits 0 seconds! I copied the ICONX from 1.3 and use it instead. It works
fine.

CPU (aka SETCPU) which is included with 2.0 will give you grief if you
have AMAX and an accelerator. I CPU FASTROM under 2.0 (I used to
SETCPU FASTROM under 1.3), and AMAX will not boot. Even if you
CPU NOFASTROM before you start AMAX, AMAX will still not boot. If
I don't run CPU FASTROM at all after booting, AMAX will boot fine!
So, I run SETCPU V1.6 instead of CPU under 2.0, and it works fine.
The FASTROM option works, and so does AMAX with FASTROM enabled.
Now this may be a problem with AMAX and not CPU, but it seems strange
that using SETCPU instead makes everything work fine.

I don't know sport fans. 2.04 looks nice, but given how long its spent
being "tested" I think a number of obvious problems exist. There have
also been a number of other bug reports flying around usenet as well.

My other gripe is that although the workbench looks nice, the new
colors make the vast majarity of apps that open on the workbench
screen look awful (my opinion of course). Unfortunatly, if I play
with the colors enough to make the apps look nice, the workbench
looks awful. Sigh. Why couldn't they have at least used the same
color registers for black and white under 2.0 as they did under 1.3!!

Also, has anyone noticed how much SLOWER 2.04 is when running from
a stock 68000! I have an 030 accelerator, and performance with it
is fine (although noticably slower than 1.3), but with the 68000
its very slow. In fact, I really don't get great performace on the
68030 unless I move the ROM code to RAM using SETCPU. Some if this
reduced performace is obviously due to the greater complexity of
2.0, and could be expectd, but I think more of it may be due to
them moving more of the code into ROM, which is slower access than
RAM. I don't agree with putting so much code in ROM anyway. It makes
upgrades more difficult and expensive. You don't have to upgrade
ROMs in a PC or MAC to upgrade to a newer OS version!

Sigh.

I like the Amiga, but sometimes Commodore doesn't make it easy to like.

    Since reading -.1 I booted up in 68000 mode and noticed a significant
    slowing of all aspects of the OS as compared to v1.3.  I couldn't
    imagine using v2.04 on a floppy system, but then maybe I am just
    spoiled after using an accelerated amiga for so long.  The most
    noticable thing is how slow the window redraw/refresh is when using
    just the 68000.  It is very, very, very slow.  Look before you leap.
    
    mark
    

    I believe, Mark, you have a 2500?  That's why you say 68k mode?  Well,
    you're bound to notice slowdown going from a 1.3 ROM 68020/030 to a
    2.04 ROM 68000.
    
    Assuming that's not what you meant (;-D), I wholly disagree.  I've had
    my 500 since 1988 with a 1.3 ROM, and then two months ago went to the
    2.04 ROM (this was all on floppy, no hard drive, as yes two months ago: 
    I worked at Paragon so I got them the second day after they shipped).
    
    I noticed nothing but improvements with how fast my machine ran. 
    Generally, I'd have to say I got a 5-10% increase in all disk
    operations.
    
    Of course, now I have the A500HD+ and things really fly...
    
    Mike

    Frank,
    I've now tried several machines, a 4.3 board, 4.4 board, 6.0 board and
    A3000 board.  I have not been able to make either of the commodities
    fail on these boards.  Question: have you put in the upgrades to force
    the board to rev 6.?  Very few and fairly cheap.  Did you remove the
    comment from the clicktofront commodity?  Could you give a complete
    system set up.  Boards, memory, Agnus chip, etc.  Also do you have the
    cherry keyboard?  When the new keyboards are plugged into your machine
    do you miss the first character?  Send me mail at SDOGUS and we'll see
    what we can see.  I'm really sort of interested in this problem.
    
    Thanks
    Clark

My experience matches .66.

My system under 2.04 runs, if anything, slightly faster than it did under
1.3 and the 68000 or 68020.

My boot up time is lots faster that 1.3.  I attribute this to the fact
I don't have to make any commands resident since they are built into
the shell.

re <<< Note 5164.64 by AMIGA::RIES "MACINTOSH = Machine Always Crashes If Not The Operating System H" >>>
>                             -< More 2.04 "bugs" >-

> My original note is .38

> I am still having problems getting CLICKTOFRONT and AUTOPOINT to work. I posted
> a note to usenet to see if I am the only one, and appearantly I am NOT! Here
> is my posting and the first reply:

	Frank, for what its worth..... they both work for me.

	Config is a rev 4.4 motherboard, memory was basic 1 meg plus 4 
meg of dips on an 8-up board at the time of installation, GVP Series 
II HC+8 with 100Mbyte Conner drive and no memory.  {dull, eh ?}
I've since sold the 8-up board and put 2 Meg of Simms on the HC+8, 
they both still work.

	We could try check-summing both kits, or my distribution kit
in your machine, your distribution kit in my machine, etc. ?  If 
there's been any  "creeping updates"  or  "undocumented fixes"  I'd 
like to help you try to find them.

	Reg

    I installed 2.0 in a friend's Amiga 2000/2630 last night. He has an
    older Microway Flicker Fixer in it and I told him that he would
    probably have problems with the new super hires modes. The installation
    of the Denise required the moving of a jumper (j300 301?) if you have
    a de-interlacer installed. Well, after reassembling the system, I
    rebooted and went throught the list of graphics modes. There was NOT a
    productivity mode listed (I moved "multisync" from monitor store to monitor
    drawer), also the super hires and super hires interlaced modes work fine.
    My question is what is the function of the jumper, and why was
    productivity mode missing from the list of graphic modes?
    
    Roger_who_gets_his_2.0_tonight.
    
    Bye the way, I've located another retail outlet which carries the Amiga
    and hardware/software accessories. It's in Woonsocket RI and if
    anyone's interested I'll post the name and number here.
    
    
    
    

    
    Roger,
    
    Please post the name of the dealer in Woonsocket.  I visit that area
    quite often.
    
    Thanks,
    Frank
    

    re: .70
    You need the ECS to use (or even get) productivity mode.  This means
    the "NEW" Denise chip as well as the Agnus, etc.  You've done
    everything correctly, you just can't have productivity until you do
    MORE!
    
    Clark

    Most people discussing installation of 2.04 seem to have purchased an
    upgrade kit.  My situation is slightly different.  I have replaced a
    1.3 A500 with a 500 Plus which comes with v2 ROMs and 2.04 Amigados.
    
    As I was using an A590 hard disk, I had to backup the Workbench
    partition (using Quarterback) while running with the 1.3 system.  I
    then connected the 500 plus, formatted the Workbench partition from the
    2.04 diskette and copied on the Workbench, Extras and Fonts.  I then
    restored any files that I wanted to migrate from the 1.3 system.
    
    I had thought that reformatting the partition would give me the new FFS
    but I'm not sure that this is the case.  If I try Version DH0: I get:
    
    		fs 37.26
    
    but I also get this if I try Version DH1: or DH2: or even RAD:
    
    How do I get the new FFS?
    
    Next question ...
    
    I understand that Arexx is part of the new system but there is no
    reference to it in any of the manuals.  How do I find out how to use
    it?
    
    Apart from the above V2.04 is a major step forward for mankind.
    
    Peter

    I'm not quite understanding the ARexx part.  The entire ARexx manual
    and function library is right after section 9 "Editors," in a manual
    partition of its own.  Did you get a copy of the 2.04 manual?  It says
    "Using the System Software" on the front.
    
    Version 37.26 is the latest version of the FFS.  That is the FFS on
    Workbench 2.04.  So you're ok on your hard drives.  But I think the
    manual strongly discourages restores from backups created by 1.3
    programs using the old FFS.  I guess it must have worked properly, but
    the manual clearly indicates that 1.3 hard drive users must first
    install the new ROM, boot up with 2.04 on floppy, format a bunch of
    floppies for FFS 37.26, and then backup your drive.  This is because
    2.04 (actually the FFS) recognizes both formats, and when presented
    with a choice, will choose the latter to retain compatability across
    all machines.  Therefore, you need to backup onto the new FFS-type
    disks to notice the difference, or it will choose to make the old FFS
    when you restore.
    
    Of course, when you re-low-level format the hard drive, and then
    install the 37.26 FFS onto it, I guess there should'nt be a problem;
    the AmigaDOS should translate the old file into the new when it writes
    it.
    
    Mike

    They must distribute a different set of manuals with the A500 Plus in
    the UK.  The manual that I got was Using AmigaDos and not Using System
    Software.  There is a chapter on EMACS but not on ARexx.  Does anyone
    know where I can get the ARexx info?
    
    As regards the filesystem: how could all the partitions be 37.26 if I
    only formatted DH0:?  I didn't touch DH1: and DH2: since before the
    upgrade.  Basically I don't believe the version program.
    
    Confused...
    Peter

    I'd do a save, format,and restore under 2.0 of all the partitions. If
    I go into QuarterBack Tools and select information about my GVP drives
    it says I'm using the "New Filesystem". As for ARexx I don't have a
    clue. You should call CBM, and ask why this is the case. Here in the
    USA we haven't seen a 500+ yet. I kept my old manual on ARexx as a 
    reference. The new one is nice, but the original manual is easy to
    carry, and I like that. Maybe CBM doesen't think the 500 would get
    a lot of ARexx use! Strange mindset for sure.
    							bill 

    Re: US vs non-US upgrades

    There have been recent postings on usenet about this very problem. US
    users were saying "it's right there in the manual", while UK users with
    new 500+'s were scratching their heads saying "Where?". Evidently, the
    2.04 doc set was too big to fit in the 500+ box, so they got a different/
    modified doc set and for some reason 3 disks rather than 4 as US users
    get (I think the install disk is missing). If I get a chance, I'll poke
    thru the recent postings and see if I can find the official article (from
    Dr. Peter Kittel from CBM Germany).

    -Dom

    re .72
    
    	I did install the NEW Denise so the system has the complete ECS.
    
    re .71
    	
    	The name of the store is;
    
    		Computer Place Inc.	
    		1500 Diamond Hill Rd
    		Woonsocket RI 02895
    		(401) 762-0550
    
    		It's in the Walnut Hill Plaza.
    
    		(by the way, there are still 4 2.0 kits sitting on the 
    		 shelf as of yesterday)
    

Oops - I was somewhat confused about "filesystem" there.

There are two things to the "filesystem" - the software, and the format of the
drive. Doing "version DRIVE:" tells you what softeware is handling the device.
Under 2.0, that is normally the same thing for all file systems.

The format of the drive is set by the format command. If you formatted it
as FFS and are using 37.26, then everything is set on the hard drive.

Since new-FFS is backwards compatable (modulo links) with old-FFS (at
least, CBM employees said so at regular intervals on BIX), there shouldn't
be any oddness with FFS doing "the wrong thing". However, I'm willing to
believe that the restore program will produce inferior results when
restoring from old-FFS floppies as compared to new-FFS floppies.

	<mike

    Can't understand how the restore program can affect the type of
    filesystem on the partition.  The workbenck partition was set up by
    booting under v2 from diskette, formatting under v2, copying files to
    dh0: under v2 and only adding additional files using Quarterback.
    
    Is there no way for me to tell which file system I have?
    
    Regards
    Peter

    RE: -.1,.2
    
    I think Commodore was referring to THEIR backup/reinstall program.  In
    the HDTools drawer.  I think if it sees the floppies (backup) is old
    FFS formatted, it will keep them old FFS when installing on the HD.
    
    Third party software (GVP, QB) may solve this problem.
    
    Mike

re .-2

You can check on both things that can change in a filesystem: the file
system software (with version), and whether it was formatted with
the old or fast file system (that's OFS vs. FFS, not new-FFS vs. old-FFS)
with the hdtoolbox (should be on the extras disk, or possible provided
with the A590).

If the restore program formats the file system when doing a full restore,
it can obviously control what format you get. Likewise, if it's crass
enough to work underneath the file system, it can create problems.

Finally, the changes in FFS from 1.3 to 2.0 that improve performance
are related to the way blocks are allocated amongst the files in a directory.
If the restore program copies the files to the disk in an order tuned for
1.3, you probably get less performance than you do if you optimize the
order for the 2.0 FFS.

Personally, I also question the format on the floppies changing performance
on the restored FS. I'm conjecturing as to *what* could cause that.

	<mike

Re: last few

I don't think that using a 1.3 backup program to save/restore your hard
disk should matter.  If you look at the Commodore docs, they don't tell
you not to use a 1.3 backup program, they tell you not to use an image
backup program.

An image backup program is one that does not save files from the hard
disk.  Instead, it copies all of the blocks blocks on your hard disk to
the backup medium.  A restore makes every block on your hard disk contain
exactly what it contained at the time you made the backup.

Such a program would not give the new file system a chance to reorganize
the disk.

I suspect that the only reason why they tell you to do the backup under
2.0 is that the fancy user interface to the Commodore backup program
requires the gadtools library in 2.0 to run.

It is possible that using a different backup program instead of the
Commodore one could prevent some improvement, but I doubt it.  There
was a problem of this type under the old file system.  Taking directory
listing under the old file system worked faster if all of the files in
the directory had been created in hash table order.  This is also the
normal order that AmigaDOS would list the files when doing a wildcard
expansion.  (Hash table are tables that allow you to quickly look up
an entry, like a filename, by turning the entry in to an integer in a
specified range.  Names are hashed different ways; an example of hashing
a name is to add all of its characters together and take the remainder
with respect to 63.)

So, under the old file system, you could get a modest improvement in
directory speed if you copied all of the files to a freshly formatted
floppy as in:

	copy dh0: dh1: all

The new floppy had a better organized directory because all of the files
were created in the right order.

However, the above didn't work if you used the ARP version of copy
rather than the AmigaDOS version.  The reason was that the ARP wildcard
expander functions would make a list of all of the files, sort it,
and then return the list in sorted order.  Since this was not hash table
order, the new disk's directory would be no better organized than the
first.  In fact, it frequently was poorer organized.

One of the features of the 1.3 version of the fast file system is that
the hash table order preference wasn't supposed to exist: directory blocks
are linked together in allocation order, not in hash table order.

Mostly, I suspect that any backup program that saves and restores files
is OK to use when reformatting your hard disk under 2.0.

    When I read the notice about backing up the drive under 2.0 before
    reformatting to the new-FFS, I was a bit suprised that this should be
    required.  After thinking about, I believe it is to be sure that the
    backup utility functions under 2.0.  It would be a nasty surprise if
    something like MRbackup works fine on 1.3 but crashes on 2.0.

    I have poked at my disks using QuarterBack Tools. What I see tends to
    tell me that much of the speed is gained thru a cleaner FS. 1.3 always
    had major file fregmentation, even on a clean copy. I have seen very
    few cases of file fragmentation with 2.0. I do see the free space
    broken up into a few chunks, but not much file fragmentation .
    	I backed up DH0: this weekend did a quick format under 2.0, and
    when I went to restore I put in floppy 1 of the save set, turned to
    talk to my wife, turned back to the computer, and promptly clicked
    backup in quarterback. Well I guess you just have to pay attention.
    I used quarterBack tools to undelete most of the critical files on
    DH0:(fast format helped here), and saved these. I then rebuilt dh0:
    
    							bill

I had this problem on my A3000. I even tried re-installing from scratch to
figure out what was wrong!

What it turned out to be was the A2000 keyboard wierded out the commodities 
programs so ones that used keyboard qualifiers in conjunction with the mouse
would my work. 

Now, I was using my A2000 keyboard on my A3000. I like the feel of the A2000
keyboard better than my A3000 keyboard. They would begin working if I unplugged
the A2000 keyboard while after cold boot and then re-plugged it in. I don't
know what was happening, but this is what I saw. 

Perhaps something similar may be happening on your A2000 - a problem with
a particular rev of the keyboard with particular revs of the A2000/A3000.

Hope this is helpful. Click to front is wicked good! I don't care for autopoint
though.

	Thanks,
		-SES

>However, the above didn't work if you used the ARP version of copy
>rather than the AmigaDOS version. 

Just curious - are 2.0 converts generally abandoning the arp commands?

    I got rid of the ARP commands.  I just use the library.  When I
    initially installed and booted up 2.04 my machine promptly crashed. 
    After troubleshooting I found that Ashell was the culprit; while
    deleting it I deleted all the other ARP binaries.  Anyone using Conman
    with v2.0x?  I like CNN: but the shell window acts 'strange' when using
    it.  It doesn't seem to draw itself fully and I have been unable to get
    a close gadget when using Conman.
    
    md

There are some patches to WShell for use under 2.0 floating around. Those
may include a patch for conman to help with these problems. I've never looked
at the patch, so I can't say for sure. Can someone else?

BTW, WShell 2.0 replaces conman with displayhander. Much nicer - scroll bars
and menus that insert text into the buffer are just the most obvious new
features.

	<mike

I installed a Grand Slam/120M SCSI a week ago & then upgraded to
WB2.04 this past weekend. It took a while to reread the paragraph in
the IVS manual to hold the Left mouse button down while booting
Install2.0 to see the harddrive. I read the section in the WB2.04 docs
about reformatting the drive under 2.0 (backup-format-restore), but
didn't have 87 floppies! I called IVS today to check & they said it
wasn't necessary to reformat, that the controller knew which OS was
there & would do the right thing. So, i won't reformat.

    mark

    
    RE: using 2.0 for backup/restore
    
    I looked through the manual, too, and I couldn't find the reference;
    therefore I assume I must have talked to one of the Commodore techs.  I
    suppose it really doesn't make any difference.
    
    Mike

    Got a call from Tim at Ampex Systems in Norcross, GA. last Saturday. 
    He said they had the 2.04 _ROMS_.  So I took mine in yesterday and they
    said it would take about 15 minutes.  When he got in there, he said it
    was a different mother board than he'd encountered anywhere else.  So
    far, he's kept it overnight and is trying to call CBM hotlines for
    resolution.  It did NOT work with the new ROMs.
    
    I'll keep you posted.
    
    Tony

    
    
    Well, I finally installed 2.0 last night and ran into some problems.
    My configuration is B2000/A2630/A2091. After installing the rom, I
    power up the system, all's fine. I then put in the A2091, all's fine.
    I then put in the A2630, all's fine. I then connected up the tape
    drive, system can't see the 2091 anymore. This system ran flawless
    before the installation. After a couple of hours of head scratching and
    try this/try that, I seems that the system runs ok without the A2630
    and with the tape. The system will also run when the A2630 is in and
    the tape drive is powered but not connected to the SCSI cable, or the
    tape drive is connected to the SCSI cable but not powered. My guess is
    that the power supply is getting tired and with the tape powered up
    and connected to the SCSI cable things die. I measured the voltage at
    the power connector of the tape drive and the 5v was ~4.94, which I
    think may be too low for some of the logic. I'm confident it's not a 
    termination problem.
    
    	Has anyone ever played around with thier power supply? There's a 
    couple of potentiometers in there, perhaps they are voltage level 
    tweaks or maybe a current limit? 
    

    re .92
    
    Is this for a 3000?  The ROMS didn't work in mine either (self
    installed). 
    
    Please post the resolution asap if you could.
    
    Ken
    

    Re: .94
    
    Yes, it is a 3000/16 bought during the original powerup program.  (Late
    June '91).  They have not received a return call from CBM as of 12:45
    EST, 17-Dec-1991.

    RE .94 .95
    Which upgrade are you using?  The Kickstart chip for the A3000 is NOT
    the same as the the kickstart chip for the A2000!  There is a separate
    enhancer kit for the A3000.  Different part number, etc!  Are you using
    the correct part?
    
    Clark

    > I measured the voltage at the power connector of the tape drive and the 5v
    > was ~4.94, which I think may be too low for some of the logic. I'm
    > confident it's not a termination problem.
    
    4.94 is so close to 5v that you are certainly in the epsilon/delta. 
    In other words, you are at 5V.  Now if you had 4.094 volts, you could
    have a problem.  You should never see 5V actually, because the load on
    the supply, the tolerances of the components, etc.
    
    This sounds suspicously like a problem with unit numbers on the
    devices.  What device number is the tape drive set to, and what device
    number is the disk set to, etc.  What exactly is on the 2091?  What
    driver are you using for the SCSI tape?  What tape drive are you using?
    
    Clark

    

    Yea, I just looked in a ttl data manual and the spec is +/- 10% (I'm
    used to ECL which has closer tolerances) The disk drive is at unit
    6 and the tape drive is unit 4. The driver is scsi.device which is the
    standard driver for the A2091. I called TTR Development (MRBackup)
    because I knew they were running all sorts of hardware with tape
    configs. They told me they recently dropped the Tandberg line because
    of firmware problems. There must be something in the 2.0 rom for tapes
    because I removed the accelerator and without a tape entry in the
    mountlist, I was able to retension and rewind the tape drive using the
    new AmigaDOS "magtape" command. I'm still not satisfied with TTR's
    answer because the tape drive functions under 2.0 without the A2630
    in the system. 
    
    Roger
    

    re .96
    
    Well, it  *should* be an A3000 chip.  That's what the package says,	
    and the directions are for a 3000 and the chip numbers match what the
    directions say.  It acts like they didn't program the chip as the
    screen is totally blank, no disk activity, no messages or screens of
    any kind appear on boot.
    
    The dealer said he would take the chip back so I will probably return
    it later this week. 
    
    Ken
    

    re: the 3000 chip upgrade...
    
    The dealer (Ampex Systems) tried all Tuesday to contact CBM to no
    avail.  Since I an not returning to Atlanta until after the first of
    the year, I am taking the machine back to Birmingham.  We will try
    again after January 1 unless I go ahead and register for the Gold Plan
    service.  Then the local Birmingham dealer will come to the house and
    change it out.  (I finally got a reason to register!)
    
    Tony

The A3000 upgrade should have 2 rom chips since it wants a 32 bit wide path
to the rom. This is certainly true of my early A3000 model.

	-SES

re tape drives (.98)..

As far as I know, there isn't anything in the 2.0 ROMs that knows anything
about tapes. MagTape uses the SCSI direct facilities (which should be
in all SCSI devices, which only the A3000 2.0 ROM would have) to send SCSI
commands to the tape drive.

	<mike

    The A3000 upgrade DOES have two ROM chips!!!!  Are you sure that you
    have an A3000 UPGRADE kit.  I've seen several and they ALL have 2 rom
    chips.  Which are inserted into the two ROM sockets.  If you have the
    tower, the tower MUST be removed for the chips to work.
    
    Clark

    Well, I picked up another ROM set and installed it.  No difference! I
    am greeted with an absolutely blank screen, no disk activity, no
    nothin'!
    
    Yes, I am absolutely positive this is a A3000 chip set, the
    instructions are for a 3000 and the part numbers in the instructions
    match those on the chips.  The dealer said they have installed these
    chips in a couple of 3000's and they work fine.
    
    I am convinced this is yet another "mother board revision" problem. 
    Any information is welcomed.  The revision of my board is 7.3.  (I did
    remove the tower).
    
    For the near future, I am going to forget about the ROM's.  I can load
    the new kickstart with the present ROMS off of hard disk so there isn't
    a lot of advantage to the ROM set anyway.  I really don't need the
    extra memory as I still have 2.7 meg free as it is.
    
    Ken
    

The dealer was completely confused because he found "too many" sockets on the 	
board.

Tony

    Mine also has 4 ROM sockets, U180, U181 (where the new chips go), U182
    and U183.  The PCB ROM tower plugs into U182, U183 but the chips on the
    tower are marked U180 and U181.  I tried the new chips in U182 and U184
    (obviously on the same data bus) just in case, but no luck.
    
    Do you have yours back yet?
    
    Ken
    

    I took mine back to Birmingham for the holidays (so Santa can install a
    Quantum 105LPS 8^).  I'll try again after when I'm sure they've contacted
    CBM and gotten the correct information.  At worst case, CBM will have
    to change the motherboard, since it is still under warranty.
    
    Tony

    Is there any way to get CONCLIP to work like this:
    
    CUT    Left-Amiga + Left-Mouse-Button
    PASTE  Left-Amiga + Right-Mouse-Button
    
    

    
    I just wanted to add a note saying I installed AmigaDOS V2.04 last week
    on my Amiga 2000 w/ A2090A (159Mb CDC Wren III SCSI) with no problems!
    Not meaning to gloat on those who have problems more just a general
    congratulations to C-A on a great job!
    
    Now, I am trying to stick to using as much standard OS stuff as I can
    so I was wondering if there is anyway to get the Fkeys commodity to
    bring up a NewShell window WITHOUT having to have a shell opened in the
    first place (ala QMouse).  If not, should I be using a
    QMouse/DMouse/etc and, if so, which one is best for V2?
    
    George
    

    Well, I'm not having as much luck. A few replys back I mentioned, in
    this note (I think), that I was having troubles with a SCSI tape unit.
    Well, while it's out of the machine, I replaced it with a 65M drive I
    have. Well, the symptom is now the following. On a cold boot, the
    second device is not seen. On a subsequent warm boot, the device is
    seen and I can access it and even boot from it. The system
    configuration is ;
    
    B2000 Rev 4.3 (ECO's installed to make it 6.?)
    A2630 Accellerator
    A2091 SCSI Controller/2M memory
    
    The primary drive is at SCSI address 0
    The second drive is at SCSI address 2
    
    The 2630 and 2091 both have the latest Roms ( 7.0 and 6.6 respectively)
    
    I'm sure the bus termination is ok. 
    
    Any clues as to what is different between a cold and warm boot with
    regards to the SCSI controller?
    
	
    Roger
    
    
    

    Well, I've made more progress. On power up, I went into the 2630 boot
    menu to kill some time, and sure enough, the problem was the drive
    wasn't ready before the boot started. It had spun up but apparently
    wasn't ready for the software to recognize it. There is a jumper on the
    A2091 to enable "long timeout" and with this jumper enabled, the system
    boots fine. I also replaced the tape drive and before the jumper, I
    still could not boot from the disk but after the jumper, the system
    boots fine. I'm surprised no one else has run into the same problem.
    
    Roger

I am now happily up on 2.04.  I have just a couple of minor unresolved
issues that I could use some suggestions on.  As background info, I am
using a floppy controller (Pacific Peripherals) with no boot capability, so
I initiate booting from a floppy and then switch to the hard disk after
mounting it.

The Startup-sequence on the floppy is adapted from that provided in 2.04 (I
think it was called S-SBoot.dh0.)  I modified it to mount DH0:.  It does a
few odds and ends, assigns all the standard logicals to directories on DH0,
and then does an EXECUTE DH0:S/Startup-sequence.  The startup-sequence on
DH0 is vanilla from the 2.04 installation - I managed to cram everything I
need into User-startup and WBStartup.

My first problem is that when the startup is complete, the volume on my
boot floppy is still active - I can remove the floppy and the volume
remains.  Yet I cannot find any residual references to it.  It isn't
referenced from anything in the assign list.

The second problem is that I get a copy of DH0:S/Startup-sequence left in
RAM:TR by EXECUTE even though there is no substitution involved.  I know
this used to be a problem in 1.2/1.3 for first level nested executes, but
it generally seems to be fixed in 2.04, except for here.

The only thing I can see which might be causing one or both of these
problems is that DH0:S/Startup-sequence ends with ENDCLI >NIL:.  I am
wondering if doing this in a nested execute might bypass some required
cleanup.

These are not major problems, but especially the first is an annoyance.

	Paul

    re: .112
    Try putting "CD RAM:" early in your startup procedure.  I suspect your
    boot floppy isn't being released because background tasks inherited
    the default directory reference to that volume.

    You might also try using "NEWSHELL FROM" instead of EXECUTE, to see
    if that eliminates the temp file.

I got the up-grade, booted off the installation disk as per instructed, 
answered the key-map question, then kept getting system requests to please 
insert volume "ENV:" in any drive.

Went through the script, found lots of references to env-#? in the RAM: 
device, but no disk volumes by that name.

Since much of the script seemed to be concerned with adding files and deleting
them very carefully, (like if it doesn't exist, don't bother trying to delete
it), I decided to just copy all my old 1.3 directories (devs, libs, c, s, l,
etc.) into a spare directory on my system disk and copy all the files from my
2.04 Workbench and Extras floppies over to my hard drive.  (Backed everything 
up before hand.)

Also set up most of the #?-startup stuff to eventually take advantage of the
DKB MultiKick (the 1.3 side of that doesn't work yet, but that's another
story). 

So now I have 2.04 *mostly* working very nicely, but every time I move an icon 
from one drawer to another (move, copy, trash...) I get a system request to 
insert volume ^WB^ into any drive (the circumflexes are part of the volume 
name).  I click on the cancel button and it goes away, but if I move 100 files 
from a directory, that gets very tedious.

Any help on getting rid of that would be appreciated.  I feel like I'm playing 
an InfoCom game!

I've got a 2000 with a GVP 33Mhz '030 series 1 exhilerator with a 40Meg IDE
drive as my system disk, plus a 105 Meg SCSI drive on a Microbotic (?)
controller.  I've been doing the installation on the 40 Meg drive. 

Thanks,

Jim

>    Try putting "CD RAM:" early in your startup procedure.  I suspect your
>    boot floppy isn't being released because background tasks inherited
>    the default directory reference to that volume.

Right on!  That fixed one problem.

>    You might also try using "NEWSHELL FROM" instead of EXECUTE, to see
>    if that eliminates the temp file.

This is what I used to do before 2.04, but it now presents more of a
problem than it solves.  The newshell writes an initial message to its
output, which pops a window on the screen before IPREFS has been run.  As a
result, I get a non-interlaced wb screen.  Then, when IPREFS runs I get a
requestor to close everything so it can change the wb screen to interlace.

I tried every variation I could think of of newshell, run execute, etc.,
with different kinds of output specifications.  There seems to be no way to
start a new shell without something writing to it immediately.

I also tried just deleting the stupid file after the execute completes, but
unfortunately nothing after the execute is processed, because the target
script itself contains an EndCLI.

The next thing I may do is put a script in WBStartup with an IconX icon.  I
can at least put my delete command there, and probably a good deal of what
is now in User-startup.

	I hate kludges,
	Paul

Re: .115

>The newshell writes an initial message to its output, which pops a window
>on the screen before IPREFS has been run...

>There seems to be no way to start a new shell without something writing to
>it immediately.

Redirect the output of the newshell command to NIL:.  This will prevent it
from writing out the message about "Starting a new shell."

Also, specify a window argument to the newshell command, and include in
the window specification the new keyword that causes the window not to
open until input or output needs to be done to it.  (I don't remember
the new keyword off hand, but I think it is /AUTO.  It is documented
in the AmigaDOS portion of the 2.04 manual.)

Your command should look something like this (check this against the
manual):

	newshell >nil: con:0/0/640/200/My-Startup/AUTO from s:My-Startup

> Redirect the output of the newshell command to NIL:.  This will prevent it
> from writing out the message about "Starting a new shell."
>
> Also, specify a window argument to the newshell command, and include in
> the window specification the new keyword that causes the window not to
> open until input or output needs to be done to it.  (I don't remember
> the new keyword off hand, but I think it is /AUTO.  It is documented
> in the AmigaDOS portion of the 2.04 manual.)
>
> Your command should look something like this (check this against the
> manual):
>
>	newshell >nil: con:0/0/640/200/My-Startup/AUTO from s:My-Startup

I am quite sure I tried this.  I don't see how it would work anyway:

Newshell is wedged between two shells - the one it is invoked from and the
one it is starting.  According to my understanding, the >nil: will affect
any output it might generate to the shell it was invoked from.  That is not
my problem.  The con:... defines where output from the new shell will go. 
Some rubbish is always sent there, which renders the /AUTO irrelevant.

For the moment, I am deleting the stupid file from a script in WBStartup -
a kludge, but effective.  I still don't understand why the file is being
created - there is no argument substitution, so it is not needed.

	Paul

Please point me to the right location.

I simply want to know the deifferences between 2.0 and 2.04.

I own an A3000 with 2.0 on it's HD. No ROMs.
(or 2.01? I don't remember)

Thanks in advance
Gerald

    Select the "About" itme from the Workbench menu.  That should show you
    the version numbers of your Kickstart and Workbench software.  If yours
    are less than 37.something, you should install an updated version.  All
    of the 36.* versions were essentially "field test" software, containing
    known bugs, etc.
    
    Mine shows:
    	Kickstart 37.175
    	Workbench 37.67
    

    Depending on its newness, you probably received 2.03 or later.  Look at
    the diskettes that came with it.  It specifies the version.
    

re: last two

My KS and WB are version 36.somewhat

Should I wait for the ROMs?
I think they're not avilable in Germany yet.

Gerald

36.something is 2.03 or earlier; you should upgrade.

What's in the ROMs is exactly the same as what you get on disk with the 2.04
version. You can upgrade to the ROM set (required if you want to use
an '040), or just the disk set. I wouldn't bother with both.

Running the disk set lets you continue to drop back to 1.3. Running the
ROM lets you run kickstart out of ROM,which is slightly slower, but
gets you back 1/2 meg of FAST. 1/2 meg of ram is probably cheaper than the ROM
upgrade (unless you have to upgrade from 4meg of 256xs).

	<mike

    
    re:.122
    	Are you saying that the kit contains both the Kickstart rom and 
    a floppy disk version (so you can use ZKICK or KICKIT) ??
    
    	Steve G