Well, it seems I can *save* a tokenized .BA from VirutalT "File" menu, it's just the load doesn't work. But I can then load it from TS-DOS.

I can see in the VirtualT "TPDD Server Log" monitor window that TS-DOS is in fact sending a CLOSE file opcode, and the C printf statement I added in VirtualT says it is closing the file.

Now I would need a large .BA file for the NEC to be able to test with.

Ken

On 5/21/21 9:49 PM, Gary Weber wrote:
Wow Ken, it's kind of you to jump on these. If you fix these, I owe you dinner. Three or four dinners, even.
Gary.


On Fri, May 21, 2021 at 9:46 PM Ken Pettit <[email protected] <mailto:[email protected]>> wrote:

    Yeah, I just tried it.  There must be some issue with the
    addresses of the system pointers or something.

    I'm looking into this now, along with why NADSBox doesn't close
    the file.

    Ken

    On 5/21/21 9:42 PM, Gary Weber wrote:
    Correct.  Here's the results of both scenarios, using NEC
    emulation mode in VirtualT:

    * When you attempt to load an ASCII BASIC program that is
    "improperly" named as a ".BA" file, the NEC emulation mode just
    hangs, and upon a Reset, you get a cold start.  But this all
    makes sense; due to lack of an NEC tokenizer, who knows what
    VirtualT is trying to do.
    * When you attempt to load a tokenized BASIC program that is
properly named as a .BA file, you get "Ill formed BASIC file". This hasn't ever made sense to me as it could be treated as a
    binary file.

    Gary.


    On Fri, May 21, 2021 at 9:16 PM Ken Pettit <[email protected]
    <mailto:[email protected]>> wrote:

Umm. Good point. I'm not sure why you couldn't actually. Have you tried it and it doesn't work?

        Ken

        On 5/21/21 9:14 PM, Gary Weber wrote:
        By the way, I actually have always been puzzled by why I
        can't directly load a tokenized .BA file.   It makes sense
        that a lack of an NEC tokenizer would prevent the loading of
        an ASCII version of a BASIC file which erroneously has the
        ".BA" extension, but I would have thought that loading a
        tokenized .BA file wouldn't be much different than loading a
        .CO file -- just a direct copy into memory.

        Please enlighten me!  :-)

        Gary



        On Fri, May 21, 2021 at 8:50 PM Gary Weber <[email protected]
        <mailto:[email protected]>> wrote:

            I can use the intrinsic Load & Save functions in the
            menu for .DO and .CO files, but I can't use the Load
            option for .BA files due to the dreaded "Ill formed
            BASIC file". (Lack of an NEC tokenizer, methinks.)

            The Save to HD option does work for .BA files, but since
            I have to jump into TS-DOS in order to load a .BA
            properly, I'm just accustomed to using one interface
            (TS-DOS) for file operations just as a matter of practice.

            Gary.

            On Fri, May 21, 2021 at 7:56 PM Ken Pettit
            <[email protected] <mailto:[email protected]>> wrote:

                Of course I need to ask the question that hasn't
                been asked yet:

                Why go to all the trouble of trying to save off a
                file from VirtualT to the host using TS-DOS and the
                virtual NADSBox emulation?  Why not just use the
                "File -> Save to HD" menu option?

                Ken

                On 5/21/21 6:28 PM, Stephen Adolph wrote:
                I cant test this.  It is entirely internal.

                From what I read you have

                Virtual T NEC, with TSDOS
                Chatting with
                Virtual Nadsbox
                Using internal connection.

                If you could show that real NEC has this issue then
                I am all set to snoop it.
                You could use laddieAlpha as a client for example.



                On Friday, May 21, 2021, Stephen Adolph
                <[email protected]
                <mailto:[email protected]>> wrote:

                    I think I just made a testbed for that.
                    Happy to set up and capture traces

                    On Friday, May 21, 2021, Gary Weber
                    <[email protected] <mailto:[email protected]>> wrote:

                        Yeah, that's interesting. Suppose we could
                        "sniff" what TS-DOS is doing, as this is
                        100% repeatable.  In my case, every test
                        I've done results in the file handle not
                        being closed, so it must never be sending
                        the opcode. That just seems very weird to
                        me, though.

                        On Fri, May 21, 2021 at 4:39 PM John R.
                        Hogerhuis <[email protected]
                        <mailto:[email protected]>> wrote:

                            Which would be a bug in TSDOS. Which
                            either would have to be fixed there or
                            we close the file after a timeout or
                            some other TPDD command can be used as
                            an indication the file is no longer
                            being written. Like if the directory
                            starts being enumerated.

                            -- John.





Reply via email to