[Coco] using /ddr0 as default (not boot) drive

gene heskett gheskett at wdtv.com
Fri Jun 24 06:58:36 EDT 2011


On Friday, June 24, 2011 06:38:27 AM Vanderberg Family did opine:

> -----Original Message-----
> 
> >From: gene heskett
> >Sent: Jun 23, 2011 6:19 PM
> >To: coco at maltedmedia.com
> >Subject: Re: [Coco] Need help using ram drive as default drive
> >
> >On Thursday, June 23, 2011 08:50:20 PM Vanderberg Family did opine:
> >
> >[...]
> >
> >> Yes, that is a change - from my brain to my fingertips. was really
> >> Pipe Clock Clock2 i2xtot*j (module not found?)
> >
> >Chuckle. We call that PEBKAC, problem exists between keyboard and
> >chair. ;-) Or PEBCAK, interchanging chair and keyboard. It is pretty
> >common here too when I'm battling the inevitable arthritis of 76 years
> >of hard work they've done.
> 
> I call it operator error :o (spent years trying to get people to admit
> what they actually did so I could fix the problem rather than spending
> hours chasing ghosts because they were embarrassed). Worked for years
> starting up solar power generation plants and one or two times every
> startup you would hear a huge bang or see massive smoke and suddenly
> see all of the construction workers running out of electrical equipment
> rooms. Never failed - the first words were invariably "I didn't do
> anything!"
> 
> What would embarrass me is to have people on this list working on my
> problem as stated and find that I had caused AND covered up the actual
> problem.
> 
> >> Last night I started all
> >> overwith orig distrib disk -no mods
> >> Rebuilt using all stock descriptors for all hardware to eliminate any
> >> self-inflicted errors. I really thought that it would work - /ddr0
> >> SHOULD work as default drive, or why does it exist? Same results
> >> exactly.
> >> If I gen using /ddd0 as default, everything is great (no progress,
> >> but it works as it should) however if I change to /ddr0 with no
> >> other changes in my standard.bl for os9gen, the boot fails with
> >> 12xtot*j
> >
> >Well, maybe, but you are walking on and plowing dirt that hasn't been
> >plowed in this manner before, so its hard to tell what may turn up.
> 
> This I don't get? How can this be new ground? Possibly people are
> misreading my posts in thinking I am trying to BOOT to ram drive. That
> sounds hard to achieve to me. All I am trying to do is use the existing
> /ddr0 descriptor. After all. the name describes the function: /ddd0 ->
> default drive /d0 (almost everyone must use this one I would think
> unless they are booting directly to hard drive) /ddr0 -> must be
> default drive /r0 - ram drive why else would it be named so? It exists,
> therefore it would be nice to believe it has a function. I also find it
> hard to believe no one else has ever tried to have their system files
> on ram. It makes all commands as instantaneous as those loaded in ram. 
> Well, if I had a hard drive I wouldn't go to the trouble either but for
> a floppy-based system...
> 
> 
> And now he turns to the crowd and asks:  Has anyone ever had occasion to
> try any of the /ddr0 descriptors that come with NitrOS9?
> 
> >> >> In other words, I am trying to change a working standard.bl to use
> >> >> the /ddr0 descriptor from the distrib disk. So, my question is
> >> >> what needs to be done in addition to selecting the /ddr0
> >> >> descriptor in order to enable ram drive as default? If I am
> >> >> thinking correctly, that change will achieve all I have
> >> >> described. THEN I can think about /r0 as a boot device on warm
> >> >> boots - another question for another day.
> >> >
> >> >A warm boot from the ramdisk, unless you can figure out how to swap
> >> >the boot module that is in memory, cannot be done. However you can
> >> >make everything run from /r0 by editing sysgo and fixing the help
> >> >and error files I alluded to above.
> >> 
> >> Not trying to boot from ram disk - booting from /d0, just trying to
> >> establish /ddr0 as default, not boot.
> >
> >I don't believe that can be made to work. The best you can do is I
> >think, use the startup script to put you on the ramdisk after the
> >backup command has refreshed the ramdisk. The boot, or reboot, will be
> >from the /d0 floppy in all cases, so that floppy will need, in
> >addition to track 34 for the initial boot, the os9boot you os9gen'ed
> >on it with MB, probably utilpak, Sysgo, cmds/backup, and a custom
> >startup. You cannot use an edited SysGo because it runs too early,
> >before the backup. Put your backup command in the startup file, and
> >once that's done, then chx /r0/cmds, and cd /r0. The backup will then
> >be done every boot/reboot, but I don't see a way around it.
> 
> Well, I don't even bother with that.  Usually when I reboot it is either
> trying out a new boot disk or I want to do something that requires a
> diff config.  OK, usually because I just did something wrong and need
> to back up a step or two and do it right this time, dummy (that is what
> I call me - me doesn't care for it but me should have done it right the
> first time!)
> 
> 
> 
> I expect to always boot from /d0 (well I am watching Steve Bjork's
> floppy controller emulator with interest) but since /d0 is my big disk
> it is my working disk and usually doesn't contain a CMMD & SYS set.
> 
> But I restore from /d1 to /r0 whatever ram drive image is appropriate
> for what I want to do next.  Very often that is determined by the
> results of what I just did, good or bad.
> 
> So, I commonly take 30 sec and 'reimage' the 'hard' drive to another
> purpose.  This means I am not so interested in automation here, it is
> easier & quicker to reimage to suit than find the correct script to do
> it for me.  After all, it only requires:  backup /d1 /r0 and I am good
> to go.
> 
> >> >I assume we are talking about a half meg coco3 here, which will
> >> >eventually run out of /r0 to add stuff to. I have a 2 meg disto kit
> >> >in mine that I have used at 1.7 megs, but those haven't been on
> >> >fleabay anytime I know of, fleabay itself is too new.
> >> 
> >> Yes, my mother told me envy was bad so I should wish I had your 2-meg
> >> and you had a better one
> >
> >And a grin back at ya. In fact, I am somewhat amazed that Mark or Roger
> >hasn't built a new design of a 2 meg kit. IMO there is yet, a market
> >for such a kit. Somebody, way back up the log, made a one off of an 8
> >megger, but from what little I know, that would have needed some
> >pretty intrusive patches to os9/nitros9 to use it.
> >
> >The only magic in the disto kit is an added register that furnishes the
> >upper address bits missing in the gime chips registers, and another I
> >think 2 bit counter added to the refresh counter. The memory itself is
> >just a pair of the usual 30 pin simm's, 256kx16's. Running at the
> >coco's bus frequency, those simm's make zero heat, or as close as
> >never mind. Since all the power supply stuff, which is a huge heat src
> >in the coco's, has been excised for close to 20 years now, and an old
> >AT PSU in the bottom of the drive tower powers it all, so I can toss a
> >furniture blanket over the coco with a darkroom thermometer laying
> >over the ram on top of the case, leave for 2 weeks and the thermometer
> >might be 2F over room ambient when I get back. I also got my fill of
> >the finger pattern on the MPI oxidizing at 2 week intervals, sawed it
> >off and put a set of gold plated fingers on it, sawed off an old PC
> >video card with each finger connected by a dot of hard, silver bearing
> >solder. That also was nearly 20 years ago, and I've not had a bad
> >contact with the mpi crash me since. And of course it got a heart
> >transplant when the 6309 was discovered, a wee bit faster & again its
> >all cmos, so zero heat.
> >
> >Finally, all 4 MPI sockets have their pin 8's bridged together, and 3
> >of the 4 pullup resistors also connected to those pin 8's have been
> >removed, so missed interrupts are a thing of the past.
> >
> >Yeah, I'm a tinkerer and maybe a JOAT even. I've been chasing electrons
> >for a living for 62 of my 76 years. Funny thing though, that, and a
> >buck 35, will get you a 16 oz coffee to go at 7/11. ;-)
> 
> Yes, but as a hobby, how can it be beat?

I have rather eclectic interests.  In addition to the coco, I have an 
amateur sized metal lathe, a wood lathe, and an HF micromill that isn't so 
micro anymore, cnc controlled by emc.  And of course the usual collection 
of woodworking tools, and have 11 pieces of furniture either done or under 
construction.

You can see some of what keeps me out of the bars in my dotage at 
<http://gene.homelinux.net:85/gene>
That is actually this machine. :)

> In fact I started up my CoCo
> again for a few years in the late 1990's but just as in the 1980's life
> and a family conspired ... well, we won't go there.  A few years ago I
> suddenly had excess time and  could follow through with my hobby:
> robotics.  Due to a severly limited budget I couldn't get startup with
> arduino or propellor or some of the more well known micros, but I
> discovered Picaxes (PIC based, embedded basic,  free IDE, serial comms
> for programming, amazing I/O ports, i2c etc. - no, not a stockhloder or
> employee - just a fan as I am of the CoCo - something about solving
> problems with minimal hardware & Unix's appeals to me) and with a ten
> dollar bill I was reading inputs and writing outputs just like in the
> old days on $100 million Westinghouse DCS systems controlling boilers &
> turbine generators and solar fields.  I couldn't believe it.  I
> developed a "radar" style system that mapped the area with IR distance
> sensor on a ser vo that displayed on the PC and saved the data via i2c
> to eeprom.  That data was accessed by another Picaxe ((representing
> another robot) and expected it to navigate the maze totally blind based
> on the data received from the first robot.  The obvious flaw here is
> the stupid cable - really limits a robot :)  Someday I would like to
> get a wireless chips and get back to it but it was only ever a proof of
> concept project because I wanted to see how far I could take it. 
> Suddenly I wondered why I was displaying on the PC using serial comms
> when I could do it with my CoCo (sort of an excuse to do some fun
> unpacking).  I plan to use the CoCo as the display (20x4 lcd screen is
> rather limiting) and to provide disk drive capabilities along with
> floating point math.  Oh, I could already do all of that on a PC, but
> where is the fun in that?  Also, it would be trivial to add the CoCo to
> my Picaxe network (currently 4 configured as a DCS network but for a
> few less $$) and get RTC input fo r CoCo as well as any sensor input or
> control output I want to add to CoCo.  I have thought about designing
> an interface to multipak but that bitbanger port just seems tailor made
> for Picaxe serial comms.
> 
How fast is this picaxe?  Can it drive step & dir drives through a parport 
at 50 kilohertz?
> 
> Well, I certainly got off subject as well as windy, sorry
 
NP, its called defining the problem. :)

> >> I understand the limitations and accept
> >> them, however for my purposes the size works well. I format the /r0
> >> to match my 40tSS /d1 which allows me to flash a whole new (albeit
> >> tiny) hard drive in about 30 seconds using backup. Far better than
> >> dsave to repopulate ram drive. So I have a prebuilt image (from
> >> diskette) on ram drive to match my current purpose. #1 CMDS, SYS,
> >> etc. #2 Basic09, support files and progs #3 Games requiring diff
> >> setup or that access a drive for routines (speed) #4 Multi-Vue (just
> >> playing). My point is that withing 30 seconds I have a small
> >> "harddrive" custom tailored to my current task. This only works well
> >> as the /r0 is formatted identical to /d1 so for me, maybe only 512k
> >> is a blessing.
> >
> >Well, if /d1 was a 720k floppy, 3.5 or 5.25, the 2 meg kit would allow
> >you to add quite a bit more to that floppy image. Just saying.
> 
> And well said if I may say.  And would be welcome - a 720k ramdrive. 
> But in the few months I have been using this, I have been surprised to
> find that sometimes smaller is better.  I have had to actually think
> about each type of task I do on the system and define it's
> requirements.  I have not yet (oh, I think I can feel these words
> coming back at me already) found anything I do that doesn't fit with a
> reasonable amount of free space to save whatever else through a reboot.
>  As an example, If I have my CMD&SYS set on /r0 and my DiskMaker Disk
> in /d1 I can easily build a /d0 720k boot disk with nary a disk swap
> and no looking for files.  And surprisingly, taking 30 sec after a boot
> or when I change from creating a disk to playing a game or whatever
> turns out not to be even irritating.  Doing the same for 2 minutes
> would frustrate me totally.  I hate waiting for machines which is crazy
> since I have spent my entire life using and supporting them.  Still,
> machines MUST wait on my pleasure!!   I do NOT wait on theirs.  Which
> is why I normally have 2 systems going when I work (ha- I'll show them
> who the boss is).  Still, 720k ram drive vs 180k ram drive, hmmm, not
> really a hard choice at all, is it?
> 
> >The fact that you have a 40tSS disk to be used to populate the ramdisk
> >makes the fixing of help and error very easy. Patch those 2 files, help
> >and error, for starters so they look in /r0/sys.
> 
> And I am going to look at this.  Fine with me, but nonstandard modules
> are so ... nonstandard.  If I cannot get the /ddr0 to work I will fall
> back to this method.
> 
[...]
> Yes and I don't ever want to go back to dsave to accomplish this. Took
> So Long and Loud.

I wrote me a dd in b09, but its not all that fast.  I need to code up a 
skip=1 for it, but first I have to make some round tuit's on my milling 
machine.
 
> This is what I meant above re: small  - 30 sec backup works for me -
> longer process frustrates me
> 
> >The above dmode output actually came from my coco3 as its live in the
> >basement and I am using a terminal proggy here, connected to the deluxe
> >rs-232 pack at 9600 baud. So the coco3 is just another terminal screen
> >here.
> >
> >> And again I thank you and all others for the help.
> >> Ed
> >
> >NP, we are also refreshing my ancient wet ram as we go. Lets just say
> >it is in need of the refresh. :)
> 
> Now, if we could only backup and restore THAT.

Which reminds me of an old saying that was popular on amiga mailing list 
back in the day. "I haven't lost my mind, its backed up on tape somewhere 
around here"
 
> >Cheers, gene
> 
> And thanks to you, Ed
> 
> And I apologize to the list for the fact that I cannot seem to post to a
> thread.  I reply, but it still starts a new thread.


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)
We interrupt this fortune for an important announcement...



More information about the Coco mailing list