05/30/94: Ramdisk by Delphi, | Category: Delphi - System Modules 6809 | 12 comments - (Comments are closed)


87651 30-MAY 20:42 System Modules (6809)
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

12 comments to Ramdisk

  • pucc_unknown

    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

  • pucc_unknown

    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…

  • pucc_unknown

    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

  • pucc_unknown

    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

  • pucc_unknown

    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


  • pucc_unknown

    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

  • pucc_unknown

    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!)

  • pucc_unknown

    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
    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

  • pucc_unknown

    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

  • pucc_unknown

    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

  • pucc_unknown

    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

  • pucc_unknown

    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