[Coco] Need help using ram drive as default drive

[Vanderberg Family]

-----Original Message-----
>From: gene heskett <gheskett at wdtv.com>
>Sent: Jun 21, 2011 8:13 PM
>To: coco at maltedmedia.com
>Subject: Re: [Coco] Need help using ram drive as default drive
>
>On Tuesday, June 21, 2011 11:27:49 PM Vanderberg Family did opine:
>
>> yes, sysgo is in both /d0 which is /dd and /r0 just in case something
>> works & it looks there.
>> 
>> I saw some of your posts about modifying init & tried changing /dd to
>> /d0 in both init and sysgo where I also found it.  I attempted to boot
>> with each single change with all else the same and also with both files
>> modded.  As far as I could tell, there was no diff in behavior or boot
>> failure regardless of the permutation.  Both files are back to orig. 
>> Any hints for the next step?
>> 
>> Understand I am way beyond my knowledge level here, but that just makes
>> it more fun.
>> 
>1. I would delete SysGo from the /d0 disk just to make sure it is getting 
>Sysgo from /ddr0. Or alternatively, rename the startup file on the ramdisk, 
>and edit that SysGo to use the new name.  Then the message as to which it 
>is actually running can be incorporated into /d0/startup and /dd/stertup.
>
>Actually, one could rename SysGo on the ramdisk, then change init to use 
>the new name.  The idea is to be able to differentiate.  Init however is 
>part of the os9boot file.
>
>Humm, if you are seeing SysGo and then the init tracing string, then you 
>obviously have sysgo in the boot file, which is not required and wastes 
>system ram.  Take it out of the bootfile and put customized copies in the 
>root of /d0 and /dd.
>
>The boot device assignment is first done in init, then a few seconds later, 
>when SysGo runs, then it can also change the default device.  I boot from 
>/d0, and let the init module put me on /dd, so it is the SysGo on /dd that 
>I use.
>
>If your ramdisk is truly non-volatile, much as a compact flash is, then it 
>should Just Work(TM).
>
>However, this is dirt I've not walked on before because the ramdisk I use 
>is myram, which I wrote, but its 100% volatile as it is using some of the 2 
>megs in my coco3.  Theoretically I could re-write that to recover what was 
>copied there before, but I would need some method of detecting if this boot 
>was the result of a reset tap, or if its a fresh powerup.  As is, the first 
>access of any kind actually formats myram (takes just a few milliseconds) 
>and any previous data stored there is thrown away.  
>
>But I haven't done that as a long tap on the reset messes with the dram 
>refresh & the data is lost anyway. :-(
>

In trying to ask a very specific question I seem to have caused some confusion.  But your response and Roberts have given me an idea for later.  But I'll start over.

CoCo 3, 512k Ram (Performance Peripherals), CM-8  monitor
/d0 3 1/2" 80T 720k, /d1 5 1/4" 40TSS (late FD-500) Performance Peripherals floppy controller
/r0 ram disk formatted same as /d1
NitrOS9 3.2.8
Trying to enable /ddr0_192k.dd
I boot to NitOS9 from /d0
Format /r0 and then backup /d1 to /r0from a prebuilt ram disk image with CMDS, SYS, sysgo, startup, etc.
chx /r0/cmds

OK no magic here - but when I reboot to test a new boot disk or run a game with diff config (or one of the millions of reasons that always require me to reboot IMMEDIATELY after I finish all of the work setting up just what I need...) then i do truly see magic.  As soon as I boot I already have my fully populated ram disk.  It even works through a failed boot!  Of course the instant response of CMDS in ram is normal for you on hard drives or drive wire, etc. but on a floppy based system all of this magic built into NitrOS9 really makes the CoCo responsive and saves me a ton of time setting things up (~30sec after OS9 boot vs 3-4 min).

OK all of this works great but the system still stubbornly looks for helpmsg and errmsg on /dd.  SLOW.  So, I tried a new boot disk with /ddr0_192k.dd but that is when my boot fails.  As I had dmoded my /r0 to match /d1 for quick backup as mentined above I expected that when I booted with the unmodified /ddr0_192.dd the boot would have a problem with the unmodified /ddr0 since the still existing ram drive parameters didn't match, but I hoped I could get far enough through the errors to dmode /ddr0 and cobbler a new boot, boot, redo ram drive, boot & test /ddr0 against the still existing /r0.  Boot Fails. Hence the post.

Also, the sysgo is in the root of /r0 and not (normally) in the boot.  I will have to go back and check my bootlist.  Probably part of one of my tests with changing /DD references in sysgo and init to try to force the boot to look at /d0 rather than /dd to get past the /dd problem above so I could try to dmode /ddr0 and eliminate that part from the problem.  Sysgo will go... but that makes me wonder why I did not see init as I did in otehre examples.  And as to that, why does the init need to stay resident?  Just curious

So my real question is how do you enable a default /ddr0 when you do not already have an /r0 for init & sysgo to access during the initial boot process?  Question 2, failing that, how can you cause help and error to access SYS on the ram drive?

I thank you all for your time.
Ed

________________________________________
PeoplePC Online
A better way to Internet
http://www.peoplepc.com