Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Gary Weber]

Yes, that's the same as my experience.  I've always been able to save a
tokenized .BA file from the VirtualT 'File' menu, as I mentioned earlier.
The fact that I can't load one, though, has always just meant I've
generally used TS-DOS for all operations.

A large NEC flavored .BA file will be in your inbox shortly!

On Fri, May 21, 2021 at 10:27 PM Ken Pettit  wrote:

> 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  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  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  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  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  wrote:
>
>> I think I just made a testbed for that.
>> Happy to set up and capture traces
>>
>> On Friday, May 21, 2021, Gary Weber  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 
>>> 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.

>>>
>
>>>
>>
>

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Ken Pettit]

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

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Gary Weber]

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

> I think I just made a testbed for that.
> Happy to set up and capture traces
>
> On Friday, May 21, 2021, Gary Weber  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 
>> 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.
>>>
>>

>>
>

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Ken Pettit]

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

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Gary Weber]

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  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  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  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  wrote:
>>>
 I think I just made a testbed for that.
 Happy to set up and capture traces

 On Friday, May 21, 2021, Gary Weber  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 
> 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.
>>
>
>>>
>

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[John R. Hogerhuis]

On Fri, May 21, 2021 at 9:15 PM Ken Pettit  wrote:

> Ahh, right.
>
> And I suppose it's too big to save as a .DO and then save that off.
>
>
I know you're talking about creating a DO and using the Saveto HD.

But back on TS-DOS-Virtual T TPDD: I'm pretty sure with DOS-ON you can save
a .DO straight to TPDD. But that might have the same bug as saving a .BA?

-- John.

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Ken Pettit]

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

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Gary Weber]

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  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  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  wrote:
>>
>>> I think I just made a testbed for that.
>>> Happy to set up and capture traces
>>>
>>> On Friday, May 21, 2021, Gary Weber  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 
 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.
>

>>

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Ken Pettit]

Ahh, right.

And I suppose it's too big to save as a .DO and then save that off.

The other option is to "Print" it to a file if you are interested in 
trying that option.  :)  But again, you still end up with a text file, 
not a tokenized .BA file.


Ken

On 5/21/21 8:50 PM, Gary Weber 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 > 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 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 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
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.

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Gary Weber]

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  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  wrote:
>
>> I think I just made a testbed for that.
>> Happy to set up and capture traces
>>
>> On Friday, May 21, 2021, Gary Weber  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 
>>> 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.

>>>
>

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Ken Pettit]

VirtualT has a "line snooper" on the COM Peripheral Tab that, when 
enabled, show all traffic on the emulated serial port.  This would 
include any TPDD traffic to the virtual NADSBox.


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


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

On Friday, May 21, 2021, Gary Weber 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
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.

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Ken Pettit]

I can, assuming I remember my SourceForge password that is

Ken

On 5/21/21 4:09 PM, Tom Wilson wrote:
I just looked at the TPDD server source, and the Close opcode does 
call fclose() in line 2235.


I think the first step is to download and compile the latest source 
code; I've seen a few other fixes that are not in the latest released 
code.


Is there anyone here with authority to compile and issue an official 
release on SourceForge?



Tom Wilson
wilso...@gmail.com 
(619)940-6311



On Fri, May 21, 2021 at 4:02 PM John R. Hogerhuis > wrote:


Sounds like the file handle didn't get closed.

When the process is terminated all open handles are closed
automatically.

I think there is a file close tpdd command maybe it's not wired
through to a physical file close.

-- John.

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Stephen Adolph]

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

> I think I just made a testbed for that.
> Happy to set up and capture traces
>
> On Friday, May 21, 2021, Gary Weber  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 
>> 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.
>>>
>>

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Gary Weber]

Thanks Steve.  I'm curious if you'd experience the same exact issue.  I
suspect everyone would, and the confirmation that it isn't unique to my
setup would be great.

One scenario would be to a DOS-ON based "Load 0:" of a .DO form of a huge
basic program from BASIC which will tokenize it on the way in, and then try
to do a "Save 0:FILE.BA" from there, and see that only 20480 bytes are
present on disk in your ROOT folder on the host machine.  And then if you
can confirm that the Close opcode isn't getting sent when the Save
completes, then we have our culprit.


On Fri, May 21, 2021 at 5:02 PM Stephen Adolph  wrote:

> I think I just made a testbed for that.
> Happy to set up and capture traces
>
> On Friday, May 21, 2021, Gary Weber  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 
>> 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.
>>>
>>

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Stephen Adolph]

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

On Friday, May 21, 2021, Gary Weber  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 
> 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.
>>
>

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Gary Weber]

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

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[John R. Hogerhuis]

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.

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Tom Wilson]

I agree, John - it's exactly what you'd see if the file wasn't being
closed. My theory is that some non-obvious quirk of the TPDD protocol means
the close opcode doesn't always get sent, or at all, maybe.


Tom Wilson
wilso...@gmail.com
(619)940-6311



On Fri, May 21, 2021 at 4:22 PM John R. Hogerhuis  wrote:

> I'm a member but I leave the official builds to Ken who wrote most of the
> code.
>
>>
> I can make a test build though depending on his availability.
>
> Somehow I still think the file is not being closed.
>
> -- John.
>

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Ken Pettit]

I'll take a look.

Ken

On 5/21/21 4:22 PM, John R. Hogerhuis wrote:
I'm a member but I leave the official builds to Ken who wrote most of 
the code.



I can make a test build though depending on his availability.

Somehow I still think the file is not being closed.

-- John.

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[John R. Hogerhuis]

I'm a member but I leave the official builds to Ken who wrote most of the
code.

>
I can make a test build though depending on his availability.

Somehow I still think the file is not being closed.

-- John.

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Tom Wilson]

I just looked at the TPDD server source, and the Close opcode does call
fclose() in line 2235.

I think the first step is to download and compile the latest source code;
I've seen a few other fixes that are not in the latest released code.

Is there anyone here with authority to compile and issue an official
release on SourceForge?


Tom Wilson
wilso...@gmail.com
(619)940-6311



On Fri, May 21, 2021 at 4:02 PM John R. Hogerhuis  wrote:

> Sounds like the file handle didn't get closed.
>
> When the process is terminated all open handles are closed automatically.
>
> I think there is a file close tpdd command maybe it's not wired through to
> a physical file close.
>
> -- John.
>

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Tom Wilson]

That doesn't seem like a hard ask. If you have any C/C++ experience, the
emulator compiles cleanly from source (or it did the last time I tried).

Here's the project on SourceForge (which is overdue for a release...)

https://sourceforge.net/p/virtualt/code/ci/master/tree/




Tom Wilson
wilso...@gmail.com
(619)940-6311



On Fri, May 21, 2021 at 3:49 PM Gary Weber  wrote:

> FYI - I think I've identified the issue.  You apparently have to close
> VirtualT to get the rest of a file uploaded into the emulated NADSbox
> beyond the first 20k.   As soon as I did that, the rest of the file showed
> up on disk.  Guessing this is entirely an issue within the NADSbox emulator
> code.
>
> Well, I suppose this would be a feature request then?  I'd love for
> VirtualT to flush the write-to-disk buffer after receiving a file so that
> closing out VirtualT wasn't a requirement. :)
>
>
> On Fri, May 21, 2021 at 3:07 PM Gary Weber  wrote:
>
>> Hey folks,
>>
>> I'm just curious if anyone else has experienced this.
>>
>> Here's the scenario:
>> * Using VirtualT V1.7, emulating the 8201.
>> * NADSBox emulator is on
>> * Option ROM loaded that gives me TS-DOS.  I've tried both SARDOS 1.72
>> and TS-DOS 4.1 option rooms.
>> * Attempted to save a giant .BA file (23630 bytes) that is in the 8201's
>> memory into the emulated NADSBox.  Only 20480 bytes (exactly 20k) makes it.
>>
>> TS-DOS believes it's done, and gives me back control.  But only 20K (to
>> the byte!) makes it.  Sounds like it might be overrunning some buffer,
>> perhaps?
>> Has anyone else experienced this?
>>
>> I haven't yet tried it with other giant .BA files and that's next on my
>> list.  But I wanted to bounce this off of people here just to see if
>> anyone's seen this before.
>>
>>
>> --
>> Gary Weber
>> g...@web8201.com
>>
>

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[John R. Hogerhuis]

Sounds like the file handle didn't get closed.

When the process is terminated all open handles are closed automatically.

I think there is a file close tpdd command maybe it's not wired through to
a physical file close.

-- John.

Re: [M100] TPDD Emulator in VirtualT - 20k save limit?

[Gary Weber]

FYI - I think I've identified the issue.  You apparently have to close
VirtualT to get the rest of a file uploaded into the emulated NADSbox
beyond the first 20k.   As soon as I did that, the rest of the file showed
up on disk.  Guessing this is entirely an issue within the NADSbox emulator
code.

Well, I suppose this would be a feature request then?  I'd love for
VirtualT to flush the write-to-disk buffer after receiving a file so that
closing out VirtualT wasn't a requirement. :)


On Fri, May 21, 2021 at 3:07 PM Gary Weber  wrote:

> Hey folks,
>
> I'm just curious if anyone else has experienced this.
>
> Here's the scenario:
> * Using VirtualT V1.7, emulating the 8201.
> * NADSBox emulator is on
> * Option ROM loaded that gives me TS-DOS.  I've tried both SARDOS 1.72 and
> TS-DOS 4.1 option rooms.
> * Attempted to save a giant .BA file (23630 bytes) that is in the 8201's
> memory into the emulated NADSBox.  Only 20480 bytes (exactly 20k) makes it.
>
> TS-DOS believes it's done, and gives me back control.  But only 20K (to
> the byte!) makes it.  Sounds like it might be overrunning some buffer,
> perhaps?
> Has anyone else experienced this?
>
> I haven't yet tried it with other giant .BA files and that's next on my
> list.  But I wanted to bounce this off of people here just to see if
> anyone's seen this before.
>
>
> --
> Gary Weber
> g...@web8201.com
>