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

Fri Jun 24 02:10:47 EDT 2011

-----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?  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 servo 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 for 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.

Well, I certainly got off subject as well as windy, sorry

>> 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.
>
>> Has anyone actually used any of the /ddr0 default ram drive descriptors?
>
>I have not, nor could I do the backup since myram's LSN0 is a bit odd, as 
>is the descriptor, backup would see that and dive off the deep end. To 
>simplify the ram paging, a dmode /r0 looks like this:
>
>{t2|07}/DD/NITROS9/6309L2/MODULES/RBF:dmode -r0.dd
>
> nam=R0 mgr=RBF ddr=RAM
> hpn=00 hpa=0000 drv=00 stp=00 typ=00 dns=00 cyl=0000 sid=01
> vfy=00 sct=1000 t0s=0000 ilv=00 sas=04 wpc= ofs= rwc=
>
>Note, cyl=0000, this is the variable you change with dmode to change its 
>size and it uses an 8k page/block of ram for every cyl(inder) there. 
>Setting cyl=AF gives a 1,433,600 sized ramdisk. sas=04 is also too small, 
>for that size disk I'd set it to 40. It is self formatting on the first 
>access after a boot, if not in use it can be 'deiniz /r0' and returns every 
>byte to the os9 memory pool. But it wouldn't work for you for the same 
>reason I couldn't use it in this scheme. Well, I could, but doing the 
>backup with the tool I'd have to use will add a couple minutes to the boot. 
>And I would have to re-write my tool to skip lsn0 & start the copy with the 
>FAT on LSN1.

Yes and I don't ever want to go back to dsave to accomplish this. Took So Long and Loud.

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.
>
>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)
>Experiments must be reproducible; they should all fail in the same way.
>
>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.

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