#VD0: Broke?
13 messages in this thread
Hi,
Has anyone had success in using VD0: with ADOS 2.04? I used VD0: under
1.3 for years with no problems but it just doesn't seem to work with the
upgraded DOS. I downloaded the version that supposedly works with the new
DOS ( driver length of 2724 bytes ) and installed it as directed. The VD0:
disk appears as it did under DOS 1.3 – reporting X% of 1.5 megabytes in
use. When I copy a simple text file to VD0: and do a warm boot, the text
file is lost. I am using the same mountlist as before and the same 4 lines
to mount and label VD0: in my startup-sequence. They are listed below.
MountList entry
VD0: Device = vdisk.device
Unit = 1
Flags = 0
Surfaces = 1
BlocksPerTrack = 16
Priority = 5
Reserved = 2
Interleave = 0
LowCyl = 0
HighCyl = 191
Buffers = 5
BufMemType = 5 #
Startup-Sequence entry
mount VD0:
cd VD0:
Relabel VD0: RAM
DiskChange VD0:
Any Ideas where I have gone wrong? I REALLY like VD0: and would hate to
have to live without it. Any Help would really be appreciated. Thanks!
***** GSC *****
Gary:
I'm using VD0: under 2.04 w/o problems. The only difference (besides the
size of the vdisk…mine is larger) that in the first line of your
mountlist entry you have DEVICE = vdisk.device and mine has the full path,
ie: Device = devs:vdisk.device
Also, why are you relabling VD0: to RAM? I have a regular ram disk and a
separate vdisk. My startup seq looks like this:
mount vd0:
copy vd0Disk.inf vd0:Disk.info
The copy vd0disk.inf line just lets me put the VD0: icon where I want it on
the screen (and at the same time, since I'm accessing VD0:, displays the
icon on the Workbench screen.
Hope this is useful info to you. (I'd hate to have to work without VD0:!)
Michael
….from the north coast
Michael,
Thanks! I tried the full path specification and that seems of of done
the trick. The altitude must be getting to me for me to of missed
something as straight forward as that one! By the way, how big a VD0: are
you running? I'm upgrading to 2 meg chip / 6 meg Fast soon and I wonder if
there are any limits to the size of VD0:?
Gary:
Glad you got it working. My vd0: is 384 cylinders (what's that, 2 meg?).
I've got 2 meg chip & 4 meg fast ram, with another 4 meg of chips ready to
be installed as soon as I get up the enregy to disconnect everything open
the box up <g>.
No, there are no size limits of which I am aware… but the docs do warn to
make your vd0: allocation smaller than the actual ram limit so as to avoid
a crash.
Michael
….from the north coast
I regularly run a 6meg VD0, so that (at least) isn't the limit! Are you
using PathMan or some other multi-directory-assign utility? That may
explain why your path spec wasn't working?
–jp–seattle–
I relabel my VD0 to RAM in the SS too. It's great! That way all the progs
that have RAM: in their file gadgets, etc just use VD0: instead. Why use
regular RAM, when you have VD0 avail?
–jp–seattle–
"Why use regular RAM, when you have VD0 avail?"
jp-
well, I guess it's just the way I've done things for so long. One good
reason i can think of, is the very subject of this thread… ram: releases
memory immediately, while vd0: apparently doeasn't.
Michael
….from the north coast
Good point. 🙂
–jp–seattle–
Why not assign vd0: ram: ?
Rodger
– via Whap!
You've got it backward. If you do as you suggest, ASSIGN VD0: RAM:, then
any access to either will go the amiga system RAMdisk. That is *not* what
I want. I want any access to either to do to my VD0: disk. My SS reads:
MOUNT VD0:
RELABLE VD0: RAM
DISKCHANGE VD0:
This allows all those hard-coded file requestors, etc to use VD0:
transparently. That gives me the recoverable ram drive I want. Make sense?
Yeh! My only excuse is exhaustion. I guess I'll keep my trap shut a while!
Rodger
– via Whap!
I've got a q…..
I want to boot from my VD0:. The LHZ file that I got didn't have any docs.
Can this be done?
I don't know of a way to boot from VD0: directly, like RAD: can. Sorry. If
there is a way I hope someone else will point it out.
You can certainly speed up the boot process by copying system stuff to VD0:
in your cold-boot startup-sequence, and then on subsequent reboots you just
xfer control to VD0: as early as possible. That way only a couple commands
would get carried out from disk.
–jp–seattle–