#2.04 Script File Help!
44 messages in this thread
I just installed the 2.04 ROM and system software. I am using the DKB
MultiStart II Board with both the 2.04 and 1.3 ROMs. I've set up my
startup-sequence exactly as suggested in the DKB Manual on p. 12. This
allows you to boot from either ROM and branch to the appropriate
startup-sequence.
When I boot from 2.04, everything is fine. However, when I boot from the
1.3 ROM, I have a problem. The problem is in the DKB script file, after
ELSE, when it sets up your assignments for 1.3.
The script continually aborts and I get the message, "Assign failed
returncode 20". The script attempts to make seven assignments before it
executes the 1.3 startup-sequence. I have the problem narrowed down to the
following.
The script attempts to assign: c: sys: s: l: fonts: devs: libs:, in that
order. When assigning c:, the script uses the full pathname to the 1.3 c:
directory, since you can't use the 2.0 commands with the 1.3 ROM.
Thereafter, it just uses the word "assign", since the assign command should
now be coming from the 1.3 c: directory.
Through experimentation I have ascertained that even though the script has
tried to assign c: to my WorkBench1.3/c directory, it is not successful,
but the script gives no warning of this when executing. Only when the
script executes the next line and tries to assign sys: to my WorkBench1.3
directory, does the script abort with the above error message. Apparently
the script is still using the commands from the 2.0 c: directory, since the
c: assignment to the 1.3 c: directory failed. Then the 2.0 assign command
won't work when trying to assign sys: to my 1.3 directory. However, by
troubleshooting, I discovered that the 2.0 assign command does work when
assigning s: l: fonts: devs: libs: to my 1.3 directory. So those
assignments do not terminate the script file.
I have to figure out why my first assign statement in the script doesn't
work to assign c: to my 1.3 directory. If that assignment works, then the
sys: assignment should work, and the script will be fine.
Can anyone help me with this problem? Thanks.
Dom Fontana
Dom,
A few things….
1. Make sure the 1.3/c directory exists before the assign of C:
2. Make sure the ASSIGN command in there is in fact, the 1.3
version
Don't forget, under 1.3, the FastFileSystem isn't in ROM, thus it
must be loaded in your RDB on your HD.
Don
Don,
Thanks. I'll try your suggestions.
Re the FastFileSystem, it's already in my RDB on my HD. The manual said to
delete references to it from your HD, but I called IVS, and they said that
wasn't necessary wih their GrandSlam controller. So my RDB is exactly like
it was when I operated under 1.3 exclusively.
Thanks again.
Dom Fontana
Dom,
IF you have reformatted your drives under the new 2.04 FFS, then
you should have THAT version of FFS (it's on the 2.04 disks) in your RDBs.
Don
Don,
I specifically called Sam Noonan at IVS to ask him about reformatting my
Quantum 210-meg HD and removing any references to the FastFileSystem from
the RDB, as the 2.04 manual states. He said that neither action was
necessary. The GrandSlam was intelligent enough to know when I was using
2.04 and when I was using 1.3. He also said reformatting would not result
in a speed increase. Therefore, he told me not to change anything.
Was he wrong?
Dom Fontana
Dom,
Well…if the 1.3 filesystem was already faster than the IVS card,
then yes he was right.
For 1.3, you need the filesystem in the RDB since it's not in ROM,
under 2.04, FFS is in ROM, but it's the new improved FFS that's about 10%
or so faster than the original FFS. And yes, to take advantage of it…you
must reformat.
Don
Don,
Yes, I understand everything you're saying. You're saying exactly what's
in the 2.04 manual, which I'm in the process of reading, and I understand
it.
The problem is Sam Noonan's comments from IVS and Todd Butson's comments
from TTR.
After installing the 2 ROMs into the DKB board, I read the Getting Started
2.04 manual. After reading it, I felt I had to do five things:
1) Remove any references to FastFileSystem from my MountList entries;
2) Remove any references to GlobVec from my MountList entries;
3) Make sure I was using the new DOS type in my MountList entries;
4) Remove any references to FastFileSystem from the RDB on my HD; and
5) Backup my HD, reformat my HD, and restore my HD under 2.04.
Is this correct?
I took care of my MountList entries, but Todd from TTR said not to change
the MRTape-handler, which does include a reference to GlobVec= -1. Why do
you think he told me to leave it in, when the manual said to delete it?
This is very frustrating. Should I listen to the manual or the
manufacturer?
Then Sam from IVS said not to change my RDB or reformat my HD. So I don't
know who to listen to anymore.
What do you think?
Also, does any of this have anything to do with the assign problem I'm
having with my startup-sequence?
Thanks for your help. Dom Fontana
Dom,
It might well be. IF you are going to revert to 1.3, you MUST have
the FFS in the RDB, otherwise you won't be able to access the drive…or
you'll have to have an OFS partition and have FFS available in it.
The new FFS has several improvements in it, that give it a 10% or
so speed up over the older version of FFS. To take advantage of the new
FFS, you MUST reformat the drive. You can; however, use the new FFS on a
drive that has been formatted under the old FFS and it'll work…just no
speedup.
If IVS says you don't need the new FFS, or you'll get no
improvement, then the only thing I can presume is that they were not able
to keep up with the older FFS, thus any improvements in FFS wouldn't be
seen. That is a pure guess on my part as to why they'd advise you not to
use it.
Yes, it could well have something to do with your assign problems.
Don
Don,
Thanks for your input. I'm working with Dean from DKB to try and correct
my assign problem.
Dom Fontana
When it is said that the drive 'must be reformatted' to take advantage of
the latest file-system does that just mean using the ADos format command or
does it mean that a low-level re-prep is needed? If I have to do a
low-level format then that blows the whole drive but since I have 5
partitions on my drives (each) I can do alot of simple partition to
partition shuffling and high-level formats are just inconvenient.
– via Whap!
Scott,
High level formatted (via the AmigaDOS FORMAT command) will do the
trick. I believe you need to do the full format, not the QUICK
option…but could be wrong on that…QUICK may work fine.
Don
Dominick,
I don't know why IVS told you not to change the RDB or reformat. The 2.0
FastFileSystem is much faster and more stable than the 1.3 version. The
RDB's if done correctly won't make that much difference, but the reformat
is required to get the speed increase from the 2.0 FFS.
The GlobVec=-1 for the MRTape-handler is because of the tape handler.
You should only remove the GlobVec entry for those mountlist entries that
use the FFS. Other filesystems/handlers may still need the GlobVec entry.
Unfortunatly, I can think of no reason for any of this to have any
effect on your startup-sequence problem. The only one that even comes close
is the reformat under 2.0. It's possible there is some file on your root
partition that is left over from the 1.3 system that is interfering with
the S-S, though I'd be hard pressed at this time to tell you what it could
be.
One thing that keeps popping back into my brain is that you may have a
weird virus that is causing these problems. I've seen virus's do strange
things when confronted with an OS change.
We'll be talking again I'm sure, At least until we get this problem
cleared up.
Dean
DKB Software
Dean,
I have some info that might help with the problem. I don't know why I
didn't think of it before.
Right after the S-S aborts, I use the full path to the WB1.3 c: dir, in
order to invoke the "Why" command. It responds with,
"Error Code Number 122," which means, "Invalid resident library during
load."
Apparently, there is a library in my root dir's libs dir that is causing
the problem. At least, that's how I interpret it.
What do you think?
Dom Fontana
Dominick,
Hmmm, that may not be a problem. It may be the Version commands error
code failing the library version check. I'll check into it. That error
message does sound abit strange.
Dean
DKB Software
Dominick,
I was helping two individuals installing their Multistart boards. They had
a similiar problem with trying to run the installation script. We were
baffled for a while until I took a hard look at the first line of the
script.
Have you insured that there is a SPACE after Version…like
dh0:Workbench1.3/c/Version(space)>NIL:graphics.library 37
In the installation script found within the MultiStart II manual you really
have to watch the spaces. I believe the company was looking into this small
problem.
Hope this helps. Both friends have been using their boards, on A500's since
December, with no problems.
with no problems at all
Alan,
Thanks for the reply, but unfortunately the problem is not so simple. I've
scrutinized the file and there are no typos. I even uploaded and faxed the
script to DKB and they confirmed that the script was fine. It appears to be
a DOS problem, not a problem with a faulty script or a faulty DKB board.
By the way, in the example line in your message, there should also be a
<space> after >NIL:. DKB has also updated their manual.
Thanks again.
Dom Fontana
Don,
Also, the 2.04 manual mentions that there's a hybrid fastfilesystem file
that can be used with 1.3 and 2.04. Is that what I should be using since I
have both ROMs installed?
Dom Fontana
Dom,
It's in the LIBS: directory of the 2.04 WB disk. Yes, that is what
should be used. It's the new FFS, and is there in case you wish to
reformat your drives to get the improvements, but also want to switch back
to 1.3. It does work with the older FFS formatted drives also.
To be honest, I really don't know why you're making such an effort
to have the ability to go back to 1.3…what particular piece of software
do you have that won't work under 2.04 that you "can't live without"? Just
curious.
Don
Don,
I take it that you don't believe in the ROM-switchers that many people
have purchased?
I purchased the DKB board BEFORE installing 2.04. It was
fairly cheap and was purchased as insurance, just in case I had some
software that wouldn't work under 2.04. After the ROM installation, the
very next step was to install the 2.04 software on my HD and then use the
DKB supplied startup-sequence to branch to the appropriate script depending
on what ROM I booted from. That is when I had the assign problem and when I
left my first message. It's been less than a week that I installed 2.04.
I've been reading the 2.04 manual (quite large) and setting up 2.04 as I
go along, so I haven't used much of my old software with it yet. However,
my term program, Access, has distorted gadgets, menus, and colors under
2.04. Unless the manual says how to correct this, I'll either have to get
another term program or use Access with 1.3.
I know that reading the 2.04 manual is very important. I have a friend
who's had 2.04 for many months and he didn't know until a few days ago that
you could drag down a screen by using left-Amiga and the selection button
anywhere on the screen, and not just the title bar. I read this in the
manual within half an hour of installing the ROM.
Also, I'm not quite sure why you ask why I'm going to so much trouble to
be able to use 1.3. Since I have both ROMs in my machine, are you saying
that I should forget it and never use 1.3, in which case I would have
wasted my money on the DKB board? Or are you saying I should sell the DKB
board and forget about 1.3?
Dom Fontana
Dom,
No…I have nothing at all against ROM switchers. In particular, I
think quite highly of DKB's products. My own personal opinion however, is
that for Joe Average User…they don't really provide you with much in the
way of usefulness.
That is to say, there is very little software that doesn't run
under 2.04 and what software there is…isn't a big deal to ME. To someone
else, perhaps you, it may be very important.
For someone like a developer, who has to make sure his/her software
works under both OS's…it's a whole different story. Quite useful there.
I suppose it depends on your perspective. I tend to move forward
and if I have to move backwards to use something…I'll usually not bother.
I really like a few of the old ABasiC (the *original* BASIC for the Amiga)
programs I have.
Unfortunately, ABasiC finally quit working under 2.04. One of
these days, I'll take a look at it as well as I can…and see if there's
something I can do to make it work again. If I can, fine…if I can't…oh
well…it was fun while it lasted.
But that's my view of things…yours is obviously different. I was
just curious about why it's worth it to you.
Don
Don,
I understand your point. However, you asked me why I was going to so much
trouble AFTER I had the DKB board installed. I could see your point of view
concerning the efficacy of a ROM-Switcher, if it was BEFORE I bought the
board. I obviously didn't know it would be this much trouble before I
bought the board. Now that I own the board, if I didn't go through the
trouble, then the board is useless to me and I threw my money away. Selling
the board is probably just as much trouble as curing the problem. Remember,
not curing the problem means not using 1.3 at all, and that means I
wouldn't be utilizing the DKB board. So I don't consider myself as having
an alternative. That's why I wasn't sure why you asked.
I have more info on the problem, that I should have thought of
sooner. After my S-S aborts, I execute the "Why" command and it
states, "Error Code Number 122", which means, "Invalid Resident
Library During Load." Apparently there's a library in my root dir's
Libs: dir that's causing the problem. What do you think?
Finally, the 2.04 manual says that there is a version of AmigaBasic that
works under 2.04, that's available separately. Do you know anything about
this?
Thanks.
Dom Fontana
Dominick,
If you do reprep under 2.0, be sure to install the FFS into the RDB's of
your drive. The FFS you want to use is on the 2.04 Install disk in the L:
directory. This will keep the Filesystems compatible between both versions
of the OS.
Dean
DKB Software
Dean,
IVS said that their GrandSlam controller knows if you're booting from 1.3
or 2.04. If from 1.3, it gets the Old FFS from the RDB. If from 2.04, if
gets the new FFS from ROM.
I don't know why they said not to reformat, but I'm going to do it anyone,
since I need to change the sizes of a few of my partitions. I know about
the FFS on the Install disk, the one that's compatible with both ROMs. Are
you saying I should have that FFS in my L: directory before reformatting?
Thanks.
Dom Fontana
Dominick,
The best thing to do is to boot from the 2.0 install disk when
re-prepping and reformatting your drive. Which version of the FFS you get
is important. If you have a drive formatted under 2.0 and try to use the
1.3 FFS with it, you may not be 100% compatable. This is why the new FFS is
on the Install disk.
The 2.0 FFS is much faster than the 1.3 version ONLY IF the partition
was formated using the 2.0 FFS. Otherwise the 2.0 FFS falls back to a
compatable, but slower, access method.
Dean
DKB Software
Dean,
Thanks for the HD formatting info. I still have to get my tape backup
working before I can reformat my HD.
Dom Fontana
Ugh,
Sounds like I have to do a low-level reformat after all. Damn. OK, so
is the 2.04 FFS that much better than 2.02 that I got when I bought my
3000? Why (if so)?
– via Whap!
Dean,
I am using Multistart II and MegaChip. I am mostly using 2.0. Before up
grading I used QuarterBack to back up my HD then restored these files under
1.3. Now under 2.0 when I try to find my whap directory it sometimes takes
several attempts before 2.0 will admit it is present. Is this symptomatic
of the difference in the FastFile systems? Thanks.
David
– via Whap!
David,
Are you running the release version of 2.04? If you aren't, or you
originly formatted your drive with a beta 2.0, I would strongly suggest
getting the release version and reformatting. Beta 2.0 software including
FFS had some serious problems. One of them was disapearing
files/directorys.
Dean
DKB Software
David,
You sent me the message that you intended for Dean from DKB. You might
want to repost it, to make sure he gets it.
Dom Fontana
Dean,
With all this talk of reformating under 2.04, do you mean a FULL
reformat or will a quick format give you the extra speed of the new FFS?
..Steve
Whap!ping from beautiful coastal South Carolina
Steve,
I just wanted to say hello. Do you believe the problems I'm having
upgrading to 2.04? Actually, the new OS is working fine and I like it very
much. The problem has been trying to use both 2.0 and 1.3.
Get in touch when you have the chance.
Dom Fontana
Dominick,
Your luck rns like mine :->. ried to call Tuesday around 7:00…no
answer not even answering machine. will try again tonite or tommorrow,
have been working some real long hours the past week or so. Will talk to
ya soon.
..Steve
Whap!ping from beautiful coastal South Carolina
Steve,
Actually either would work, though I tend not to trust quick formats.
All that really needs to be done is to (quick) format the drive so that the
2.04 FFS gets a clean start on the drive. Then it can place the files in
the most efficient way it knows how. It does a much better job than the 1.3
FFS does which is one reason why is is faster.
Dean
DKB Software
Dominick,
Do you know the reason why the 'DHx:Workbench1.3/c/Assign c:
DHx:Workbench1.3/c' fails? If the startup-sequence is correct, and the
directory exists, the Assign command should not be failing. What is the
device name of your default boot device? Has that been substutited for
'DHx:' in the above line? Do you have a c: directory in your Workbench1.3
directory?
After the script fails, type 'assign' at the CLI prompt and check what
c: is assigned to. If you modified the script in the manual in any way, ie
'cd c:' prior to the command that is failing, that could explain the
problem.
If all else fails, call Jerry on Monday and he'll walk you through the
procedure to get you up and running.
Dean
DKB Software
Dean,
Thanks for your reply. I believe everything is correct, yet it still
doesn't work. It's either something esoteric or a stupid blunder on my
part.
To answer your questions:
1) I entered the script verbatim, as listed in the manual.
2) Yes, I substituted my default boot device, (DH0:) in the script.
3) Yes, the c directory exists in my 1.3 directory.
4) I've already tried troubleshooting by commenting out certain lines in
the script, and everything seems to be in order. That's why I'm so baffled.
After the script terminates, the assign command does nothing, since I'm
still using the 2.04 assign command with the 1.3 ROM. At the CLI prompt, I
then assign the c dir to 1.3, using the complete path to the 1.3 c dir,
using the exact line that's in the script. Then the assign works. Now when
I type assign, it shows the c dir assigned to 1.3, but everything else
still assigned to dh0:.
I experimented by putting the c: and sys: assignments at the end of the
script, and using the complete path to the 1.3 c dir for the other
assignments. After the script aborts, a check of my assignments reveals
that the first 5 dirs are assigned properly to 1.3, but the c dir is still
assigned to dh0:, and then the script fails only when it tries to make the
sys: assignment. Apparently, the other assignments work, the c: assignment
doesn't, but does not abort the script, and ultimately, the script always
aborts on the sys: assignment.
Are you as puzzled as I am? I spent a few hours on the problem and it's
been a real nuisance.
If I can't get it working, I will call Jerry on Monday.
Thanks for your concern.
Dom Fontana
Dom,
Do you have any assignments to SYS:<whatever> before where you
attempt to reassign SYS:?
Have you tried breaking the startup-sequence (with a ^D) and then
running it step by step by hand and seeing what happens?
Don
Don,
No, I have no prior assignments to SYS:. First, I assign the c: dir, then
I assign sys:, then I make the other five assignments for L: S: Devs: Libs:
and Fonts:.
Yes, I did abort the script myself, and then entered each line by hand. It
works perfectly. It just doesn't work from within the script. As I said,
the c: assignment doesn't abort the script, but it also doesn't make the
assignment. It's only when the script tries to assign SYS: that the script
aborts.
Dom Fontana
Dom,
Just out of curiosity…try running the assign to C: twice. Same
line, just two times in your startup-sequence.
Don
Don,
That's just what I was thinking. I'll assign to c: twice and let you know
the results.
Thanks.
Dom Fontana
Dom or Dean,
you might try copying the execute command to the directory where the script
is; I'm not sure about this but reassigning c: while you're executing
"execute" might be the reason for the script failure.
.. Tim Trompeter…
Timothy,
I'm sure sure I understood what you meant about reassigning c: while I'm
executing "execute".
Could you please elaborate?
Thanks.
Dom Fontana
Dom,
My mistake; what I was referring to was trying to reassign a directory
while something else was assigned to that directory. Sorry about adding to
any confusion 🙂
.. Tim Trompeter…
Timothy,
Thanks for your input, anyway.
Dom Fontana
Tim,
I wish that were the problem, but it isn't. The script as printed in the
manual is correct and works on a good many systems. We are in the process
of tring to determine the reason for the problems Dominick is having. If I
didn't know better I'd say his system is haunted! 8^)
Dean
DKB Software