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. -- bkw On Tue, Jul 13, 2021, 4:21 AM Brian Brindle <bbrin...@gmail.com> wrote: > >> That is strange. Remember, UR2 works with a real tpdd which has no such > thing as a current directory label, and as well, the whole point of the UR2 > stub on-demand loader is that you don't have TS-DOS installed, either ram > or rom. > > I'm probably not articulating what I'm trying to say right, it's > sometimes impossible for me to talk without a whiteboard. I'd explain why, > but we'd need a whiteboard. > > Here is the behavior I have observed: > > TS-DOS seems to always use M1, or at least does when loading a directory > anyway. UR2 does not when asking for DOS100.CO. > > (Working Dev) > UR2: > RX: 5A 5A 07 00 F8 0D - ZZ > TX: 12 01 00 EC 0D 0A 3E 20 - > > > RX: 5A 5A 00 1A 44 4F 53 31 30 30 2E 43 4F 20 20 20 20 20 20 20 20 20 20 > 20 20 20 20 20 46 00 - ZZ..DOS100.CO F > TX: 11 1C 44 4F 53 31 30 30 2E 43 4F 20 20 20 20 20 20 20 20 20 20 20 20 > 20 20 20 46 FF FF 9D - DOS100.CO F > RX: 5A 5A 01 01 03 FA - ZZ > TX: 12 01 00 EC > RX: 5A 5A 03 00 FC - <THE FILE> > > TS-DOS: > RX: 4D 31 0D 5A 5A 08 00 F7 0D - M1 ZZ > TX: 12 0B 00 52 4F 4F 54 20 20 2E 3C 3E 20 96 - ROOT <> > RX: 0D 4D 31 0D 5A 5A 07 00 F8 - M1 ZZ > TX: 12 01 00 EC > RX: 4D 31 0D 5A 5A 08 00 F7 0D - M1 ZZ > TX: 12 0B 00 52 4F 4F 54 20 20 2E 3C 3E 20 96 - ROOT <> > RX: 0D 4D 31 0D 5A 5A 07 00 F8 - M1 ZZ > TX: 12 01 00 EC > RX: 5A 5A 08 00 F7 - ZZ > TX: 12 0B 00 52 4F 4F 54 20 20 2E 3C 3E 20 96 - ROOT <> > RX: 5A 5A 00 1A 44 4F 53 31 30 30 2E 43 4F 20 20 20 20 20 20 20 20 20 20 > 20 20 20 20 20 46 00 - ZZ DOS100.CO F > TX: 11 1C 44 4F 53 31 30 30 2E 43 4F 20 20 20 20 20 20 20 20 20 20 20 20 > 20 20 20 46 FF FF 9D - DOS100.C0 F > > So, in my playing it looks like when you swap back to TS-DOS, load a > directory it runs the PDDuino through the M1 routine, sets the dmeLabel then > when you flip to the UR2, do the load DOS it takes the ZZ DOS100.CO F > without any issue. Do just the ZZ DOS100.CO F without dmeLabel set it > just looks at you. > > - Brian > > > > On Mon, Jul 12, 2021 at 11:26 PM Brian White <b.kenyo...@gmail.com> wrote: > >> >> >> bkw >> >> On Mon, Jul 12, 2021, 9:48 PM Brian Brindle <bbrin...@gmail.com> wrote: >> >>> >>> >>> On Mon, Jul 12, 2021 at 5:34 PM Brian K. White <b.kenyo...@gmail.com> >>> wrote: >>> >>>> >>>> >>>> master actually? or latest default branch which is not master but 0.4.1? >>>> I didn't have master marked as default currently because I thought I >>>> had >>>> made it worse, you know like the partly-broken point mid-way in a >>>> refactor, so I made the last-known at least basically-minimally-working >>>> version default. >>>> >>>> But if you're actually using the master branch that's great and I'll >>>> switch that to default. That is where I started porting Jim's main loop. >>>> >>> >>> I'm using the Master. I had a lot of issues with the current default. >>> Granted I didn't improve my situation by mucking with it, but I stumbled on >>> the Master, saw the changes you made and liked them so went with it. It's >>> been working pretty well since. >>> >>> Biggest thing I saw was the PDDuino would wander off looking for >>> >>>> > label information and not respond to drive commands. Like when trying >>>> to >>>> > load TS-DOS from the UR2 it would fail unless you could force the >>>> > PDDuino to get a disk label, IE: swap to TS-DOS rom, list a >>>> directory, >>>> > then it would happily go on to the load step. It is somewhat working >>>> now >>>> > so I took a break from it, although my M0 still doesn't work and I'm >>>> not >>>> > 100% sure why but I think it's the guy from SdFats fault.. >>>> >>>> I'd love to know the fix for that. I wrote a whole paragraph in the >>>> front page readme about it just as a bug description to be figured out >>>> sometime. >>>> >>> >>> I did a lot of debugging on this, both with a serial monitor and with >>> the debug options on the pdduino. I came to the conclusion that it had >>> something to do with dmeLabel not getting set. When watching the >>> interactions it looked like the UR2 just does a ZZ - ZZ DOS100.CO and >>> that's it. TS-DOS did a little dance that gave it the root dir first and >>> set dmeLabel. >>> >> >> >> That is strange. Remember, UR2 works with a real tpdd which has no such >> thing as a current directory label, and as well, the whole point of the UR2 >> stub on-demand loader is that you don't have TS-DOS installed, either ram >> or rom. >> >> Ken Pettit has a TS-DOS disassembly in his directory on club100 that we >> can consult too when it comes to nailing down a real mystery. >> >> Maybe it's something where IF the server says it supports directory >> extensions (by acknowledging one of the commands that should be unknown to >> a real tpdd), THEN the label must actually be supplied at various times, >> and I'm missing some. >> >> We had discussed here not too long ago the idea of having a tpdd server >> at least have an option to treat some filenames specially, like having >> DOS100.CO always work regardless of current directory. It sounds pretty >> sensible to me, but if the UR2 loader always cds to root first, then that >> means there is no point. >> >> That would also mean the root label is not free to be whatever I think it >> should be, but has to be whatever UR2 cds to or looks for (or else we hack >> UR2, or else we recognize UR2 requests and fake whatever makes it happy.) I >> don't like "ROOT" as the root dir label. I will not use it unless forced to >> by something like ur2 just requires it or something. Similarly for "PARENT". >> >> I always had the idea that there could be a whole raft of virtual files >> that don't actually exist but that could be used to issue commands or >> return data like RTC time etc, like /proc /sys etc. They could even be in >> their own virtual sub dir. The dir could even be invisible where it isn't >> listed in the root directory listing, but never the less works if you >> request the right dir and filenames. >> >> I like the idea that, at least for some things, you might be able go use >> them by just opening the "file" in TEXT. Or sched or addr for that matter. >> You could have a 2 MB address book for real, but a virtual addr.do that >> only sees a 5k window of it at any given time. >> >> I don't actually know what all the useful uses might be but it just seems >> obvious to provide the facility simply because you can, and maybe someone >> else comes up with functions that are made possible by using the facility. >> >> >> I mucked with this quite a bit but stupidly went down the route of trying >>> to make DOS100.CO found no matter what the current directory was but >>> regretted that after I started thinking it was short-sighted for other >>> things not DOS100.CO. I'll have some more time here soon to keep >>> playing. >>> >>> >>>> >>>> So far, actually the lowly 32u4 feather board is actually my favorite. >>>> The teensy's have gobs more power obviously, but for this task the 32u4 >>>> does the job so the extra power doesn't matter until we start adding >>>> features beyond straight tpdd. Either feather is better than the teensy >>>> (until you start needing the horsepower) for the sake of: >>>> * asymmetrical pin headers for polarity enforcement, >>>> * built-in lipo manager >>>> * card detect switch, >>>> * ...which an interrupt can be assigned to >>>> * extra on-board led for the card slot >>>> >>>> I'm with you on the 32u4's now. Very impressed with what they have and >>>> can do. I hadn't really touched them much before. The form factor of all of >>>> this is my favorite, the feather mount boards totally make it all work. >>>> Great job on those. >>> >>> >>> Brian >>> >>>
