[Coco] Need help using ram drive as default drive

[gene heskett]

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.

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

Am I seeing it correctly Robert, or do I have an error, -ENOTENOUGHCOFFEE?

Roger, is this something your coconet kit _can_ do?

I am reminded of rebooting my old amiga, which was actually a series of 
warm reboots, with a warm reboot being done after every extra bit of 
hardware was discovered until it was finally running on the PP&S 68040 card 
with its 64 megs of ram.  A bit over 2 minutes worth of disk hammering to 
finally get it all configured and usable.

Cheers, gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
WHOA!!  Ken and Barbie are having TOO MUCH FUN!!  It must be the
NEGATIVE IONS!!