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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
On 5/21/21 10:21 AM, Scott McDonnell wrote:
Brian,
I wanted to say thank you for doing this.
Scott McDonnell
Low hanging fruit, something fun to do that's just hard enough to be
satisfying vs say watching tv. ;)
I was talking to Shelby from TechTangents about a WP-2 card I sent him
and I
Brian,
I wanted to say thank you for doing this.
Scott McDonnell
---
Date: Thu, 20 May 2021 07:01:39 -0400
From: "Brian K.
26 matches
Mail list logo
