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