Hmm. github is for open source projects. This is a disassembly of a Microsoft Copyrighted binary (granted it is 34 year old). I don't think that would work.

Ken

On 6/7/17 12:52 PM, Josh Malone wrote:
github anybody?

On Wed, Jun 7, 2017 at 1:00 PM, Ken Pettit <[email protected] <mailto:[email protected]>> wrote:

    Hey Guys,

    Well, I actually had already posted a copy to my Personal
    Libraries section, though I have added a bit more since then.  I
    think the copy in my Personal Libraries section is 700K and the
    newest version is 820K.  I'll get the newest vesion posted.

    Ken


    On 6/7/17 9:49 AM, Bert Put wrote:
    How about posting it in the wiki or in your personal folder so
    the folks who are interested can download?  Just a thought... :-)

    Cheers,    Bert



    -------- Original message --------
    From: Ken Pettit <[email protected]> <mailto:[email protected]>
    Date: 6/7/17 09:58 (GMT-06:00)
    To: [email protected] <mailto:[email protected]>
    Subject: Re: [M100] M100 lib for Small C 85 0.0.3 release

    Willard,

    I should send you a copy of the partial M100 ROM disassembly I
    did. It
    has *many* more functions documented than what are covered in the
    Covington maps and might be useful.  I would send it on-list, but
    it is
    over 500K in size.

    Ken


    On 6/6/17 10:52 PM, Willard Goosey wrote:
    > On Tue, 06 Jun 2017 16:56:51 +0000
    > "John R. Hogerhuis" <[email protected]>
    <mailto:[email protected]> wrote:
    >
    >> RAM directory support? That's good news, haven't seen any general
    >> purpose file system access librararies.
    > I've got wrapper functions for all the ROM file calls (PRSNAM,
    MAKTXT,
    > etc) and they're there, in the library, they just haven't been
    *tested*
    > yet... ;-)
    >
    > As I do so, I'm getting a better understanding of what exactly
    the ROM
    > calls do, and that's working its way back into m100.def. For
    instance,
    > there was a function that I *thought* took a filename and
    returned the
    > starting address of the file. Actually it takes a RAM directory
    entry.
    > Lots of annoying little ambiguities like that.
    >
    > But yes, we now have struct dir {...} just like the big boys! :-)
    >
    > Willard




Reply via email to