87651 30-MAY 20:42 System Modules (6809)
Ramdisk
From: WDTV5 To: ALL
I’m in the middle of doing a fresh ramdisk for the os-9′ers, based VERY
loosely on the devpack version but capable of useing ram up to the amount
in the machine even if its a 2 megger!
I started on this because the compiler chokes if /r0 isn’t iniz’ed first,
thinking that was a bug. Well it is and it isn’t. OS-9 is doing that to
us as it does its own “iniz” on the module if it hasn’t been already,
then allows the write of a file to the ramdisk without reporting any
errors. Unforch, if it self initialized it, it also de-inits it at the
end of the write! So the file is lost, and c.pass1 (ansifront) can’t
find the output from c.prep. I want to stop that, effectivly making the
ramdisk refuse to deinit if the directory isn’t empty. I’m torn between
using the regular error paths to report it, or just outputting the
phrase “the root dir isn’t empty” on stderr. If I use an error number,
then the compiler and other progs will probably choke on it anyway when
in fact they could keep on truckin! So I need some input, what do tou
all (you) want it to do. The choices are to ignore it without errors, and
let you folks learn to delete all files before deiniting, haveing an
error mesage pop up at odd times, or returning a process killing error.
What’ll it be folks?
Cheers all, Gene
87655 30-MAY 22:48 System Modules (6809)
RE: Ramdisk (Re: Msg 87651)
From: JRUPPEL To: WDTV5
For one who has run up on several problems due to lazy ramdisk etiquette, I
for one would like a ramdisk to doesn’t go away and won’t choke the process
I’m running to death if I forget to iniz or forget to empty it before I shut
it down. Also, my ramdisk is buggy running Supercomm. It goes south even if I
don’t forget to set it up before using it. Dmode returns a disk sector count
of over 13 MILLION! I’m running Powerboost, BTW, with a 2-megger.
John Ruppel
87663 31-MAY 02:26 System Modules (6809)
RE: Ramdisk (Re: Msg 87655)
From: MITHELEN To: WDTV5
The only “problem” i see with you idea, is that being able to deiniz the ram
disk, even with a bunch of file on it, is a goo way to “reformat” it, or
delete a lot of junk files that may have been left on it…
87680 31-MAY 22:08 System Modules (6809)
RE: Ramdisk (Re: Msg 87655)
From: WDTV5 To: JRUPPEL
You’re doing something I’ve not done, use the ramdisk as a dl catcher. I
always goto the default dir option I’v got programmed into SC23 here.
Which is direct to my hard drive as i figure if I don’t like it, theres
always that ‘del’ I wrote to handle bad puppies. So I can’t define by my
own experience whether or not the ramdisk is flakey when running SC.
However, I will check into that before I’m done. Right now, whats happening
to the ramdisk if you forget to Iniz it is that os9 iniz’s it just long
enough to allow an error free copy into it to take place, but as soon as
the copy operation is done, os9′s internal link count for that device goes
back to zero so os9 deinits the darned thiing. Increasing the link count
in the root directories FD sector does NOT tell os9 to leave it alone.
According to what I’m reading, and my interpretation of same, if the link
count is greater than 0, it should leave it alone. It don’t, needless to
say. I may be able to diddle os9′s own copy of that link count but so far
have not investigated that path yet, time constraints and all that.
On another tack, I did figure out how to divide my golf score by 3 legally.
Easy when you’re in a “best ball” tournament with the 2 top players around.
I guess putting up with me was their pennance for something or other, but
we did make enough to get our entry fee back! Small town golf course &
CC. Cheers John, Gene
87681 31-MAY 22:13 System Modules (6809)
RE: Ramdisk (Re: Msg 87663)
From: WDTV5 To: MITHELEN
Maybe, but thats poor housekeeping too. Yeah, I know, if forgetting to iniz
it is poor housekeeping, then I’m guilty many times. But if it refuses to
deinit from either the os9 automatic, or from the deinit command until its
empty, to me that would be much the lesser of the evils. If I do that, I
think that instead of attempting to define a new error code, I’d have it
spit out a short msg via stderr, clean up the carry and B reg and return
with no error to report. That would depend on something to display the msg
sitting on the stderr path, but we have that 90+% of the time anyway.
Not fixed yet, not even a general shape in warm butter! Still looking
for input on this. Anybody else got 2 cents worth?
Cheers Paul, Gene
87690 1-JUN 20:31 System Modules (6809)
RE: Ramdisk (Re: Msg 87680)
From: JRUPPEL To: WDTV5 (NR)
I just got a hard drive at the Fest, so I’ll probably be using that as soon as
I figure wht’s wrong with my repack. I think I have my power connected wrong,
but I’m not sure.
The last best ball tourney I got into, I shot the best round in the group…we
got the Boobie prize…a foot mashie in commemoration of the fact that our
threesome played the entire 18 holes from the rough and the sand
I’ll keep ya posted on further developements in the never-ending quest for the
ULTIMATE COCO!
John
87751 4-JUN 00:04 System Modules (6809)
RE: Ramdisk (Re: Msg 87690)
From: WDTV5 To: JRUPPEL
Somehow, I get the impression we’re playing “Can You Top This”
)
Humm, I just had a weird go-round with an Ensoniq EPS and an older ST-251n.
Absolutely nothing we could do would make tham talk to each other. In des-
peration I even went so far as to install source terminations on the termless
scsi board, some aftermarket thingy thats been orphaned for 5 years at least.
No soap. Put terms on the drive, no go. Added a foot of cable, got error out
even quicker! Finally got p!**ed and reversed the power on the terms on both
ends of the cable so the resting voltage on an open line was around 3 volts
instead of the standard (I think) 2 volts. Scsi is a law unto itself, but
(knock on wood, like my head) he’s now putnearly 250 3.5″ floppies worth of
samples and sequences on it without any errors. I recount this because it
might help someone else sometime.
Cheers, Gene
87771 4-JUN 22:56 System Modules (6809)
RE: Ramdisk (Re: Msg 87681)
From: ROYBUR To: WDTV5
don’t know if it’d be legal, but could you just have the ramdisk itself do
a second iniz upon the first iniz? maybe set a flag so that it knows not to
repeat the procedure? or is this just a silly idea? 8*)….roy (who’s not
much of an os9 programmer!)
87781 5-JUN 18:55 System Modules (6809)
RE: Ramdisk (Re: Msg 87771)
From: WDTV5 To: ROYBUR
No, we can’t do that. It has already allocated the required number of blocks
(8k each) of system ram (machine ram actually, not system) according to the
value of the var shown as “sct” in the dmode report. My real problem is os-9′s
penchant for opening a path to the device in order to use it, thereby
incrementing
the link count os-9 keeps. When the use of that path terminates, os-9 decrements
the link count, and if zero, deiniz’s the path(device in this case) which is
why the compiler executives don’t report any errors until the second step of
the compile when the file the first step wrote can’t be located. The memory
was given back into the free pool by os-9. In fact, the data is still there
mostof the time, but the re-iniz resets the root dir to $40 long and the name
of the file and its data are hidden at offset $40-$5f in the root dir. In
addition, the FAT was re-written, effectivly deallocating the area occupied
by the file. ‘sa bit of a catcch-22 that I’ve had 3 or 4 ideas on how to
fix, but the last 3 days havn’t seen the coco turned on, software compat
probs with the Amiga, graduating from the University Of Hard Knocks last
night, and a couple of other items have filled up the time. It will get
done though if I have to write some sort of a routine that lets me access
that linkn count os-9 keeps. So far, diddleing the link count in the device
sector 0, or in the root FD (I forget which at the moment) has not solved
this problem. I have faith that it is solvable, and once I figure it out,
the answer will probably embarrass me in its simplicity. Cheers all,
we’re still working on ot. it. Gene
87816 7-JUN 22:07 System Modules (6809)
RE: Ramdisk (Re: Msg 87781)
From: ROYBUR To: WDTV5
gene, i have no doubt you’ll finger it out. busy is good…right? 8*)….roy
87822 8-JUN 00:08 System Modules (6809)
RE: Ramdisk (Re: Msg 87816)
From: WDTV5 To: ROYBUR (NR)
Yes and no. I’m getting too old and lazy to go too many hrs a day/nite
anymore. And I think I’ve got it, at least the version in memory right now
is working, albeit with lots of output from os9p4 as it execs that can be
removed, no doubt along with probably another 20 bytes of useless code
here and there. The problem with my original idea of going and accessing
the device table entries while it was doing the autoinit fell flatter than
one of those Carls Road Kill Cafe offerings. On checking out why I couldn’t
find my own entry in the device table, I had to go clear back to Kevs Book,
Inside Os-9 Level Two and study the flow charts. It seems the entry in the
device table I wanted to diddle doesn’t exist until AFTER the device Init
routine has been successfully performed! So I settled for tickling a zero’d
var during the init, then any read or write, aftere checking to see if the
Init has been done comes back and lbsr’s to the new code which checks that
byte, and if its non-zero, goes and finds its entry in the device table and
increments it once only. It clears that tally byte so it only does it once
then and returns to the read/write from whence it came from. Kludgy, but
it works so far, knock on wood. I’ll clean it up now which should get it
back under $300 bytes total and submit in a few days after I “alpha” test
it some more. Cheers Roy, Gene
87922 13-JUN 21:22 System Modules (6809)
RE: Ramdisk (Re: Msg 87822)
From: ROYBUR To: WDTV5
sorry to be so late; i see your last note was 06/08/94. so wha’ hoppen’d t’the
time?! actually, i’ve been livin’ on the job, lately – thanks to a layoff, i
got shoved into a position for which i’m near-totally unqualified. ‘course,
that’s true of about _every_ job that exists!
anyway, belated congrats…KNEW you’d make it work! 8*)……….roy
87923 13-JUN 22:02 System Modules (6809)
RE: Ramdisk (Re: Msg 87922)
From: WDTV5 To: ROYBUR (NR)
Thanks, now if Paul would make it visible . . .
Cheers Roy, Gene