Conference hydra::amiga_v1

I'm currently running my 1.2 WB using the ASDG recoverable ram disk and VT100
after booting with KS 1.3 on a 1000. No problems ( other than the fact that it
seems to be a lot noisier load ). What kind of hard disk are you using? 
( Don't have one myself but it might give somebody else an idea as to what is 
going on )

	Dick

    I thought the SETPATCH program was only for ROM-based Kickstart?

    
    Re: Setpatch
    
    I got the impression that this was needed for both the WCS Kickstart
    and the ROM-based kickstart.  Some time back I think Andy Finkel
    posted a program to modify the 1.2 kickstart disk.  Maybe this will
    work on the 1.3 disk?  Normally I would say no, but the changes
    were minimal so it might work...
    
    Re: Bugs
    
    I'm still working on setting up a 1.3 Workbench that I like, but
    I have been having a problem that I've never seen very often before.
    Whenever I boot my 1.2 WB with KS 1.3 and I try to Ctrl-Amiga-Amiga
    about 50% of the time I get thrown all the way back to the Kickstart
    requester.  I haven't had this problem when using 1.3 WB with 1.3 KS.
    
    - steve

    re .1
    
    I'm using C Ltd's SCSI host/controller for the A1000, with an Adaptec
    ACB-4000 controller hooked up to two drives: a Seagate ST-412 (10
    MB) and an RD52 (30 MB).  The ST-412 is the one that I reformatted
    with FFS, and it contains the executables for both comm programs.
    
    I didn't try loading a comm program from a floppy --- but since
    the problem seems to disappear if I cold start with 1.2 Kickstart,
    I don't understand why that would make a difference.
    
    I would really like to use KS 1.3, to be able to get a minimum RAD:
    bootup device...anyone have any ideas???
    
    re: setpatch: see new entry; I didn't want to change the subject
    of this entry.
    
    Thanks everyone.

    
    I was in the Software Shop on Saturday, 10/15.  Moe told me that
    he was having problems getting a C Ltd SCSI board to work with his
    last Gamma 1.3 (he hadn't yet received the released version).
    
    Moe (and myself) had no problems using earlier Gamma versions of
    1.3.
    
    During my last conversation with C Ltd, they claimed that their
    new software for FFS, called SCSIDos 3.0, would be officially released
    on October 26.  I believe they've held back til now due to some
    bugs in their current SCSI.DEVICE software.
    
    I'm personally going to wait until SCSIDos 3.0 before I make the
    formal upgrade to 1.3.
                                               
    Ed.

RE: .1.4

>   I'm using C Ltd's SCSI host/controller for the A1000, with an Adaptec
>   ACB-4000 controller hooked up to two drives: a Seagate ST-412 (10

    According  to  C-Ltd  (Chris?) a version of the C-Ltd diskdrivers
will be sent to all registered owners within 45 days of  1.3  related
release  of  SCSI  DOS - V3.0. I have not gotten mine, but they still
have a while to go.

    The  original  software is supposed to work fine under 1.3, but I
have to wonder about that. I have had problems with SCSI DOS 2.6 when
using Gamma 4 and Omega 8/9 of 1.3 with the fast file system.  Plenty
of  problems. On the final updates of WB 1.3 the fast file system was
one of the changed files.

    Finally,  have you carefully checked the mountlist section of the
1.3 manuals. There is an entry for the max  transfer  size  with  the
FFS.  There  are  also  other  related entries. Careful adjustment of
these may help.

    As you can tell I think the problem is related to the file system
and  driver. It may be aggravated by a change in the 1.3 WB but I bet
the problem is just masked and not eliminated.

	-SES

    re .6
    
    I guess a good test would be to try booting up without mounting
    any of the hard disks, then running a term program from a floppy.
    I haven't tried this combination, but I will and I'll post the results.
    
    Thanks for your very useful input.

    I picked up my 'official' 1.3 on Saturday.  I got brave and reformatted
    the my hard drive (Seagate ST277N - C Ltd SCSI 2.6) using the AmigaDOS
    1.3 FORMAT command with FFS appended.
    
    Everything went just fine.  No problems whatsoever.  I was a little
    hesitant, since I'd heard of problems with C Ltd's SCSIdos and the
    final version of 1.3.
    
    Ed.

I reformatted my SupraDrive and installed 1.3 this weekend. No problems at all
with anything. I used FFS (obviously!).

John

    RE: .8
    
    
    Ed,
    
      Why did you reformat if you were already FFS-formatted with a
    test version? I didn't bother reformatting my drive. 
    
    Paul

    
    Well, the official l:FastFileSystem was slightly larger than the
    Beta that we were using.  Just being neurotic, I guess.
    
    
    Ed.

RE: .10

    According  to  the  developer's conference on BIX the file format
changed between Gamma and Omega versions and a disk formated  with  a
Gamma  version  should  be  reformatted to operated with the released
version. This is, of course, only true for the FFS and not the SFS.

	-SES

    Through experimenting, I've further refined my problem.  Hope someone
    can help!!!
    
    Thanks!

    Guess, I'll spend the night backing up my HD!

             <<< BOMBE::DISK_NOTES$LIBRARY:[000000]AMIGA.NOTE;1 >>>
                                -< AMIGA NOTES >-
================================================================================
Note 1808.2                 Help!! GURU w/accessories                     2 of 2
VTHRAX::KIP "G.M. Landingham 293-5297"                5 lines  24-OCT-1988 21:38
                                   -< YES! >-
--------------------------------------------------------------------------------

    Dug out Volume 3, Number 3 of Amazing Computing and found Perry's
    Kivolowitz's article about grounding the daughterboard PALs.  Did
    this...problem is solved!
    
    Thanks for the help.
    

    I just found this in comp.sys.amiga and it sounded like it might
    apply?
    
    
    ============================================================= 
I just got my new copy of 1.3, loaded up my RAD: disk with all the
necessary stuff to boot my C.LTD SCSI hard disk and transfer control to
it, and rebooted.  On the first access.....crash.  Actually it says
"Recoverable Alert."  Don't believe it.  It lies.
 
The problem:  The SCSI.device driver has *hard-coded* the path
"df0:devs/" into all of the driver files!!!?!?!  *Why* do people insist
on pulling this kind of idiocy!?!?!?  That is what logical devices are
for, dammit!!
 
The solution:  Load up your favorite file zapper (e.g. newzap,
filezap...) and edit the file "SCSI.device" found in your devs:
directory.  Search for the string "df0:devs".  You really don't even
need to search, it's right at the beginning.  There are three
occurences, df0:devs/ACB-4000.driver, and a couple others.  My drive
uses the ACB-4000 driver.  Change df0:devs/ to devs:.  You'll probably
need to lengthen the name of the driver file--I don't know if you can
shorten the string safely.  I changed the whole string to
"devs:zzzzACB-4000.driver" and renamed devs:ACB-4000.driver to
devs:zzzzACB-4000.driver.  I also made the same modification to the
others, but since I don't have drives or drivers for them I don't think
that was necessary.
 
Seems to me the right way to handle this is to let you set it through
the mountlist, but I don't ever remember seeing that in the C.LTD docs.
Note that my SCSI.device driver says version 1.0.  I don't know if this
is the current version or not, but on the other hand the drive is brand
new, so it shouldn't be too old.
 
Time to go make a complete backup and try out the FFS.
 
    

    As an alternative, so you dont have to change the length of the
    path in the exe file...
    
    Change  DF0:DEVS/   to   SYS:DEVS/
    
    And in Startup.Configuration, add  ASSIGN SYS: RAD:  before you
    do any mounts.  This should do it without having to ad zzzz before
    the files.
    
    Although, adding zzzz to the file does let you know it has been
    modified and will allow both the original and modified version to
    co-exist.
    
    ah... decisions.. decisions...
    
    

Re: .16, .17

An alternative to adding the "zzzz" to the start of the driver name is to
right justify the name and pad it with nulls.  I haven't tried it, but
since the string is just going to be passed to LoadSeg(), this should
work.