Conference hydra::amiga_v1

This has me about to put my day-old copy of 1.3 up for sale.  I got the full 
disk RAD to work and autoboot by using the manual EXACTLY, then realized that
using VD0:, I typically had 1.5 disks worth of stuff in there so I figured I
had three choices:
	1. make the high cylinder > 79 for RAD:
	2. mount a second RAD: (change the mountlist to add RAD1:)
	3. have VD0: and RAD: in ram at the same time.

1 gave me not a dos disk error
2 kept asking me to put disk RAD back in any drive ( shove that expansion ram
	down its throat!!! )
3 worked marginally by getting RAD in place then rebooting with my set-up disk
	for VD0:.  By marginally, I mean that my logicals were all set to VD0:
	and badly set up for RAD along with the fact that memory was 
	disappearing at the rate of about 50K for opening up a workbench 	
	drawer and not coming back ( good thing I had 2.5 meg to get a look at
	what was killing me ).

The shell under 1.3 is not as nice as Drew Shell 2.07 as it still uses the 
#&%$@ #? wildcard instead of an *.  This may be cockpit error but I haven't
been able to change this.

Overall, 1.3 felt like a step backwards for someone like me with a 1000 and no
harddisk.  I miss ARP, MACH, RUNBACK, SNIPIT, ARC, UUDECODE, VT100, AUX, 
SHELL, ECSK and the 1.3 preferences and printer driver all on the same disk 
that boots into VD0: leaving me with 2 free floppys to run something like 
Professional Page.

	Dick ( still using 1.2 )

    
    It wasn't so difficult getting RAD to autoboot.  I'm not sure what
    my problem was the first night.  Anyhow, I seem to have RAD: and
    VD0: both working no problem.  Not having a hard disk it does seem
    strange to see the machine booting itself from memory.  Are there
    any other personal computers that are capable of this?
    
    regards,
    
    steve

Re: .2

>Not having a hard disk it does seem strange to see the machine booting
>itself from memory.  Are there any other personal computers that are
>capable of this?

Jerry Pournelle doesn't know of any other computer that can boot from
its ram disk, and he's the "expert" :-) on all personal computers.

    
    Looks like I was speaking hastily again in .2.  RAD: and VD0: do seem
    to work, but if I then try to use RAM:, the system hangs. Similarly
    RAD: and RAM: seem to work as long as I don't touch VD0:.  I've tried
    looking at the mount list and I'm not sure if there is anything I can
    change that would help.  I've got RAD: set up to be a full disk (880K)
    and VD0: set to 512K.  This is a 2.5Meg A1000. Any suggestions as to
    what might be going on? 
    
    It's amazing how much time can be accumulated trying to come up with
    a suitable workbench.
    
    - steve

Re: .4

Sounds to me like you are running out of memory.  Try running one of the
little programs that shows a continuous display of the available fast
and chip memory.  If either or both go to zero, you've found your problem.

Remember, although RAM: and VD0: only allocate enough memory to hold their
current contents, RAD: uses a fixed amount of memory (the maximum you
specified via the mountlist).

VD0: (and RAM:) can act pretty flaky if they run out of memory.

    
    re: 5
    
    I don't seem to be running out of memory.  I tried both the memory
    program on the extras 1.3 and the avail command.  Right up until
    the system hangs it seems to have plenty of both FAST and CHIP mem.
    I also tried making a boot sequence which just mounts RAD: (if
    necessary) and VD0: and then stops.  If I then copy a few files
    to RAD:, VD0:, and RAM:, the system will hang whenever I try to
    access the last one of these.  For example:

    ------------------------------------------------------------------------    
    setpatch >nil:
    mount vd0:
    copy sys:disk.info vd0:
    assign >nil: rad: exists       ; or whatever this command is...
    if warn
      mount rad:
      diskcopy FROM df0: TO rad:
    endif
    copy sys:disk.info ram:        ; system hangs here!
    ------------------------------------------------------------------------    

    Reordering these three things seems to make no difference.  It always
    hangs when I access the third type of memory.    
    
    Has anyone gotten VD0 and RAM and RAD all working simultaneously?
    
    On another note:
    
    Has anyone noticed that echo with NOLINE does not work properly
    in a startup-sequence?
    
    Try this one in your startup-sequence:
    
    echo "enter date:" NOLINE
    date >nil:
    
    Now put these two lines in a file and EXECUTE the file.  Works OK
    in the execute file, but in the startup-sequence it does not print
    the text until AFTER you enter the date.
    
    - steve mcafee

    Is it possible to have multiple, distinct, RAD: devices?
    
    I have tried everything I can think of to accomplish such a setup
    but I can't make the 2nd device be recognized as a different physical
    device as the original RAD:.
    
    What I'd like to do is have 2 floppy-sized RAD: devices. I've tried
    giving the 2 devices totally different names, and I've tried changing
    the unit of the 2nd device from 0 to 1. I've also tried copying
    the ramdisk.device (or whatever it is) to another file and using
    this new file as the device entry for the 2nd rad: device. None
    of these have produced any success.
    
    I'm open for suggestions if anyone has any.

	I currently have a Workbench V1.3 working with RAD:, VD0: and RAM:
on an A1000 with 2.5 Meg and one external drive. What I found was that
they must be mounted in the right order and if you use a startup-sequence
with them mounted in the wrong order your system won't work right until
you do a cold reboot. What I have working:

	mount RAD: 
	
	restore RAD: if required

	mount VD0:

	dir >NIL: VD0:

	makedir RAM:T

	assign T: RAM:T
    
    	
	If I reversed the order of mounting VD0: and RAD: everything worked
until I rebooted then the first reference to RAM: would hang up the system.
At that point a "good" startup-sequence wouldn't work unless a cold boot was
done ( this leads you down many a rat hole while troubleshooting ).

	One other thing I noticed is that the ASDG-RAMDISK does not seem to
deallocate memory as files are deleted from it, running CleanRamDisk forces
the deallocation. According to the docs it's supposed to deallocate memory
by itself, I never noticed this under V1.2 but I also never ran low on memory
until I added a 880K RAD:.
    
				Regards

					Glenn

    re .1
    
    Thanks for the information. I'm not having any trouble using each
    of the 3 memory resident devices (RAD:, VD0:, and RAM:) but I am
    curious as to how to set up 2 880K RAD: devices. Maybe this isn't
    possible but I've seen indications on usenet that would tend to
    indicate that it is possible. I can't figure out how to modify the
    mountlist to create 2 identically sized rad: devices. 
    
    I'd deeply appreciate any further suggestions from anyone who might
    have tried this.

Re: .8

>	One other thing I noticed is that the ASDG-RAMDISK does not seem to
>deallocate memory as files are deleted from it, running CleanRamDisk forces
>the deallocation.

The ASDG-RAMDISK deallocates memory after some number (100?) of I/O
operations go by.  The disk assumes that are going to copy more files
to the disk, and waits to see what the next I/O operations to VD0:
do before freeing the unused space.

CleanRamDisk just forces the cleanup to happen immediately instead
of being delayed.