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 yo
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 Virt
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 int
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
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 a
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 straigh
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 woul
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 tokeni
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 c
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 o
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 wro
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 yo
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 ot
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,
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
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
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 Joh
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.
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. Hoger
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.
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.
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 a
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...@g
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.
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.
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
26 matches
Mail list logo