[Coco] Need help using ram drive as default drive

Wed Jun 22 21:40:29 EDT 2011

-----Original Message-----
>From: gene heskett <gheskett at wdtv.com>
>Sent: Jun 22, 2011 7:05 AM
>To: coco at maltedmedia.com
>Subject: Re: [Coco] Need help using ram drive as default drive
>
>On Wednesday, June 22, 2011 10:27:19 AM Vanderberg Family did opine:
>
>> -----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
>> 
>Because init contains the data that presets the rest of the system even 
>before the clock is running, it must be IN the bootfile.  At the point 
>where the init variables are being looked up, the system does not yet have 
>a valid description of a filesystem.
>
>> 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?
>
>This sounds like you will need, from a cold boot, two separate boots setup, 
>one on a floppy (or a HD) that sets up the ramdisk and populates it by 
>copying a different os9boot file to the ramdisk, with this os9boot file 
>containing the /dd that is /r0.  Now, this will also require that the 
>ramdisks DD.BT and DD.BSZ be updated, and that the ramdisks track 34 also 
>contains the correct 'boot' module so the rest of the bootfile will be read 
>from the ramdisk.  Then, to reboot from the ramdisk, the reboot command 
>will need to be issued.  But that leaves us without a selection method ala 
>HDBDOS that would allow the ramdisk to be selected once 'reboot' has done 
>the cold boot thing.
>
>Tapping the reset button will not get you there because that reruns the 
>original track 34 still in memory, whose boot module points at /dd which is 
>likely an alias of /d0.
>
>So I am stuck. Classic chicken and egg. Tap the reset, wrong boot module in 
>memory, use 'reboot' and there is no method to select the ramdisk.  Short 
>of re-writing the boot module in memory with one that points at /dd(/r0) 
>after the first successful boot, something that will have to be done very 
>carefully, probably by double mapping that block of memory, I have no other 
>idea how to go about that.  Or one could, as part of the first boot's 
>startup file, do a customized nitros9 "MB" on the ramdisk, then copy the 
>rest of the stuff you'd need, that would work IF we had a method of 
>selecting the ramdisk as a boot source, but we don't.

I expect to have a slightly diff routine for initial boot than the reboot for the reasons you discussed.  I am intrigued by the possibilities you mentioned but for now ...

Here you have nicely summed up my actual question

>
>However, if the ramdisk is named /dd, and that stuff is copied to the 
>ramdisk, then the /dd/sys problem is nicely solved.

Exactly what I am attempting to achieve.  Just having problems building a boot disk with default drive /dd as /r0 rather than /d0.

Fuller discussion if you care in my reply to Boisy

Thanks again

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