Had a myriad of crazy issues lashing together my test unit for this..
Somehow I ended up with a tape of level converters where the first three
were good all the rest (dozens) are counterfeit..

Anyway, the serial trace is identical to what I posted before, but here is
the behavior I am seeing shown with debug info:

This is debug information captured from the PDDuino attempting to load
DOS100.CO from UR2.

PDDuino with a cold boot, fails to load DOS100.CO. After loading TS-DOS,
listing a directory (OR making any FDC requests) DOS100.CO loads.

First half of the request is identical:

0 - 5A;Z

0 - 5A;Z

0 - 7

0 - 0

0 - F8

T:7|L:0.

command_status()

return_normal()

R:Norm 0

0 - D

0 - 5A;Z

0 - 5A;Z

0 - 0

0 - 1A

0 - 44;D

1 - 4F;O

2 - 53;S

3 - 31;1

4 - 30;0

5 - 30;0

6 - 2E;.

7 - 43;C

8 - 4F;O

9 - 20

A - 20

B - 20

C - 20

D - 20

E - 20

F - 20

10 - 20

11 - 20

12 - 20

13 - 20

14 - 20

15 - 20

16 - 20

17 - 20

18 - 46;F

19 - 0

1A - 88

T:0|L:1A.

command_reference()

SF:0

Ref: DOS100.CO
--------------------------------------------------------
This is where the difference is. Left is cold boot PDDuino, right is after
a FDC command. Note the directory information, it seems to stay resident
once loaded but is not initialized on cold boot.

directoryAppend()        *directoryAppend(DOS100.CO <http://DOS100.CO>)*

directory[/]             *directory[//]*

->                       ->

directory[/]             *directory[//DOS100.CO <http://DOS100.CO>]*

directoryAppend() end    *directoryAppend(DOS100.CO <http://DOS100.CO>) end*

return_reference()       return_reference()

returnReference()        returnReference()

R:Ref                    R:Ref

upDirectory()            upDirectory()

directory[/]             *directory[//DOS100.CO <http://DOS100.CO>]*

directory[/]             directory[//]

1A - 5A;Z                1A - 5A;Z

1A - 5A;Z                1A - 5A;Z

1A - 1                   1A - 1

1A - 1                   1A - 1

0 - 3                    0 - 3

1 - FA                   1- FA

T:1|L:1.                 *T:1|L:1D*

command_open()           command_open()

directoryAppend()        *directoryAppend(DOS100.CO <http://DOS100.CO>)*

directory[/]             directory[/]

->                       ->

directory[/]             *directory[//DOS100.C0]*

directoryAppend() end    *directoryAppend(DOS100.CO <http://DOS100.CO>) end*

directoryAppend(/)       *upDirectory()*

directory[/]             *directory[//DOS100.CO <http://DOS100.CO>]*

->                       *directory[//]*

directory[//]            *return_normal()*

directoryAppend(/) end   R:Norm 0

R:Norm 0



Now to look at the code and figure out why...


Brian




On Tue, Jul 13, 2021 at 7:36 PM Brian Brindle <bbrin...@gmail.com> wrote:

>
>
> On Tue, Jul 13, 2021 at 6:18 PM Brian White <b.kenyo...@gmail.com> wrote:
>
>> Dang, TS-DOS is specifically requesting the name "ROOT", which means I
>> have to make PDDuino use that, and you can't have a real directory named
>> ROOT.
>>
>> There is a macro or const you can edit in the main .ino to change that
>> from "SD:   " to "ROOT  ".
>>
>> Probably won't affect UR2 but if it's baked into something like TS-DOS
>> since 35 years ago, then I just have to go along.
>>
>> Then again... TS-DOS is the one thing that actually works pretty well as
>> it is. So then, no I don't ???
>>
>> Anyway thanks for the captures.
>>
>
> I don't think that's the issue, in this case the capture was taken from
> the perspective of the TPDD so RX is what the TPDD is receiving and TX is
> what it is sending, so it sent ROOT - didn't ask for it and in this case it
> was actually correct.. That was the name of the dir. (Sorry,that was
> probably confusing.) Capture was done with a NADs box since it would be
> successful.
>
> What I was seeing during testing was loading DOS100.CO from the UR2
> didn't an FDC Emulation mode command (M1) and the PDDuino didn't seem to
> know how to proceed without having the dmeLabel set. If you run through
> one cycle with TS-DOS where it does check for FDC, everything works after
> that point. So I think there is something broken in the routine to allow
> for a non FDC Emulation request, although I haven't been able to nail it
> down yet and I did majorly screw everything up trying to "improve"
> debugging before..
>
> Lashing together a modular test setup now with the serial port broken out
> for capture. Should make it easier to get a full capture of the issue.
>
> Brian
>
>

Reply via email to