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 <petti...@gmail.com
<mailto:petti...@gmail.com>> 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 <g...@web8201.com
<mailto:g...@web8201.com>> 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
<petti...@gmail.com <mailto:petti...@gmail.com>> 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
<twospru...@gmail.com <mailto:twospru...@gmail.com>> wrote:
I think I just made a testbed for that.
Happy to set up and capture traces
On Friday, May 21, 2021, Gary Weber
<g...@web8201.com <mailto:g...@web8201.com>> 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 <jho...@pobox.com
<mailto:jho...@pobox.com>> 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.
