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