Sure, as long as it's something a real tpdd and other tpdd servrs would ignore harmlessly, like the XX YY prefixes instead of ZZ.
I think XX should really be a prefix for a whole extra set of commands, instead of using a whole potential "name space" as it were, just to do a single thing the way it does now. IE, I don't think there should be a QQ to query the time, SS to set the time, DD to install ts-dos, TT to install teeny, LL for login... Just XX-command the same as ZZ-command. Except XX and YY could be considered already burned, so it can't be litterally XX or YY, so we make up ONE more new one that gets a bunch of new commands structured similar to the ZZ commands. I was originally outputting console messages to a little oled myself just for play, and with the way CONS is a variable now (well a preprocessor constant), it's easy to put it back in. But I decided I couldn't think of any actually pressing need for a display that was worth the power draw or parts or code. The client is the display. Meanwhile I think they have tiny e-ink displays now, and that low power draw would be better. There's probably 35 cool kooky things you could add to a super-mega-tpdd I just haven't thought of. Print to server shared printer or print-to-disk? Network drive? -- bkw On Sun, Sep 22, 2019, 9:04 PM Bill Nobel <[email protected]> wrote: > I got it working flawless now Brian thanks again. I’ve started to do a > few mods to it already, I merged in a ILI9341 LCD with touch that I plan to > have a mini file explorer. Also I like the idea of the RTC in your > comments in the source. Suggestion for that, could it not have a small > basic program send a unique command over the RS-232 and process the return > data? It should be just a matter of enhancing the base TPDD driver to > include a new pre-amble for extended commands. > > Bill Nobel > [email protected] > > > > On Sep 21, 2019, at 6:34 PM, Brian K. White <[email protected]> wrote: > > On 9/21/19 4:46 PM, Bill Nobel wrote: > > Thanks for this Brian, I didn’t even think there was a Teensy version > already. I’ve reverted my base code to this version and seems to catch > packets better. Question though, is there a specific reason why it runs @ > 2mhz on the Teensy? > > > With TeensyDuino installed you can specify whatever mhz you want to run > the cpu at in the Android ide. > > I remember manually selecting different speeds to find the lowest speed > that still worked, to reduce power draw. > With low cpu speed and adding hardware interrupt wake/sleep calls to the > code, I managed to get down to 3.5ma or so while idle, depending on the sd > card. Different brands of sd card have big differences in power draw even > while idle. I got the sleep and initial power-on behavior working better > after this video, and that's where that github currently sits. It's not > *great*. I don't present it as feature complete and thoroughly tested. It's > tested about as far as that video. > > I didn't think the ide choice was recorded in the .ino file or anywhere > else within the repo, just local user settings, but maybe it is. > Because, see this comment: > > // Debug console - where shall all console messages go? > // Teensy can not use Serial (usb) below 24mhz > // But can do the the TPDD job all the way down to 2mhz, which uses the > least power. > // Usually "Serial" or undefined, but could add oled etc for output-only > display > // If undefined: > // * All Serial (built-in usb) code is #ifdeffed out so it isn't in the > microcontroller at all > // * Cpu can be underclocked all the way down to 2mhz > //#define CONS Serial > #undef CONS > > I found that the tpdd functions worked at 2mhz, but I needed 24mhz to use > the built-in serial-over-usb console. I set the code to default to no > console, which *allows* you to run as low as 2mhz, but I didn't think it > was actually somehow specifying 2mhz by recording that in a file somewhere, > except possibly some local user config file. > > Teensy has audio hardware so I was thinking ultimately it should be able > to both play and record cassette files and save them as files. And there is > an rtc so it should be possible to make a small basic app that reads a > fake/virtual file via tpdd protocol. The file wouldn't exist, merely the > tpdd server would recognize a magic filename and send back the current > date/time from the rtc in place of a file from the filesystem. > > And of course a dos-injector. dlplus already has something to do that, > which I have not yet actually gotten to work, however it does look pretty > straightforward and no reason it shouldn't work and looks simple to clone > in sd2tpdd (or PDDuino as I've apparently called a local copy on my > laptop). I've mostly just used the separate teensy installer app that comes > in the dlplus zip file because it works. I think the best would be to > duplicate the tpdd2 bootstrap procedure. That works very well and requires > very little of the user when starting from scratch with as fresh cold-reset > M100. But that's at least partly harware dependent. The tpdd2 can tell if > the m100 is "listening" or not at power-on, and decides based on that > whether to just squirt out the IPL basic code even though it didn't receive > any commands. I think it should be possible to replicate that on teensy. It > might require actually hooking up more of the serial control lines so the > teensy can read the state of dtr/dsr or something. > > Anyway, I did manually compile my copy to run at 2mhz, via Tools->CPU > Speed, but I would have thought if you just took the code and compiled it, > it would use the default 180mhz for Teensy 3.6. > And the way the code is configured as it sits on github, it can be run at > 2mhz because the built-in usb-serial console is disabled. > > https://www.youtube.com/watch?v=_lFqsHAlLyg > > -- > bkw > > Bill Nobel > [email protected] <mailto:[email protected]> > > > > On Sep 20, 2019, at 9:06 AM, Brian White <[email protected] <mailto: > [email protected]>> wrote: > > I don't remember any checksum problems with directories with this code on > teensy 3.6 > > https://github.com/aljex/SD2TPDD/tree/bkw_teensy36 > > It's not a complete implementation though so I would be interested in a > good solid re-do. > > Note specifically the bkw-teensy36 branch, not master. Master is Jimmy > Petit's original that I forked from. > > But I was reading and writing files and using sub dirs and getting good > listings in ts-dos etc. > > On Fri, Sep 20, 2019, 5:36 AM Bill Nobel <[email protected] <mailto: > [email protected]>> wrote: > > I should also note an observation I’ve had with my code. I’m > going from the Teensy to a Max3232 to the T-102. Even with power > off on the 102 I receive garbage on the port. My code seems to > catch all the preambles though to start a packet. Code is > starting to get larger so I’m going to post a Github for anybody > to look at. > > Bill > > Sent from my iPhone > > > On Sep 19, 2019, at 10:17 PM, Bill Nobel <[email protected] > <mailto:[email protected]>> wrote: > > > > Hi John, yes I receive 2 packets fine (with response) then > things go strange only on checksum. Your C# routine is different > from DLPlus for the Calc, I’ll try that in the morning and see if > that changes. > > > > Sent from my iPhone > > > >> On Sep 19, 2019, at 9:58 PM, John R. Hogerhuis > <[email protected] <mailto:[email protected]>> wrote: > >> > >> Are you sure you got a full, aligned packet? It starts with ZZ > , counted length, no missing characters? > >> > >> The DLPlus checksum is correct. More likely you're misaligned, > or somehow dropped, swapped, or corrupted a character. > >> > >> Here is the C# code too for comparison > >> > >> public byte Checksum(byte[] ary, uint ofs, uint fence) > >> { > >> uint sum = 0; > >> > >> for (var i = ofs; i < fence; i++) > >> sum += ary[i]; > >> > >> return (byte)((~sum) & 0xff); > >> } > >> > >> Welcome to the cabal of TPDD protocol initiates. > >> > >> -- John. > > > > > On Sun, Sep 22, 2019, 9:04 PM Bill Nobel <[email protected]> wrote: > I got it working flawless now Brian thanks again. I’ve started to do a > few mods to it already, I merged in a ILI9341 LCD with touch that I plan to > have a mini file explorer. Also I like the idea of the RTC in your > comments in the source. Suggestion for that, could it not have a small > basic program send a unique command over the RS-232 and process the return > data? It should be just a matter of enhancing the base TPDD driver to > include a new pre-amble for extended commands. > > Bill Nobel > [email protected] > > > > On Sep 21, 2019, at 6:34 PM, Brian K. White <[email protected]> wrote: > > On 9/21/19 4:46 PM, Bill Nobel wrote: > > Thanks for this Brian, I didn’t even think there was a Teensy version > already. I’ve reverted my base code to this version and seems to catch > packets better. Question though, is there a specific reason why it runs @ > 2mhz on the Teensy? > > > With TeensyDuino installed you can specify whatever mhz you want to run > the cpu at in the Android ide. > > I remember manually selecting different speeds to find the lowest speed > that still worked, to reduce power draw. > With low cpu speed and adding hardware interrupt wake/sleep calls to the > code, I managed to get down to 3.5ma or so while idle, depending on the sd > card. Different brands of sd card have big differences in power draw even > while idle. I got the sleep and initial power-on behavior working better > after this video, and that's where that github currently sits. It's not > *great*. I don't present it as feature complete and thoroughly tested. It's > tested about as far as that video. > > I didn't think the ide choice was recorded in the .ino file or anywhere > else within the repo, just local user settings, but maybe it is. > Because, see this comment: > > // Debug console - where shall all console messages go? > // Teensy can not use Serial (usb) below 24mhz > // But can do the the TPDD job all the way down to 2mhz, which uses the > least power. > // Usually "Serial" or undefined, but could add oled etc for output-only > display > // If undefined: > // * All Serial (built-in usb) code is #ifdeffed out so it isn't in the > microcontroller at all > // * Cpu can be underclocked all the way down to 2mhz > //#define CONS Serial > #undef CONS > > I found that the tpdd functions worked at 2mhz, but I needed 24mhz to use > the built-in serial-over-usb console. I set the code to default to no > console, which *allows* you to run as low as 2mhz, but I didn't think it > was actually somehow specifying 2mhz by recording that in a file somewhere, > except possibly some local user config file. > > Teensy has audio hardware so I was thinking ultimately it should be able > to both play and record cassette files and save them as files. And there is > an rtc so it should be possible to make a small basic app that reads a > fake/virtual file via tpdd protocol. The file wouldn't exist, merely the > tpdd server would recognize a magic filename and send back the current > date/time from the rtc in place of a file from the filesystem. > > And of course a dos-injector. dlplus already has something to do that, > which I have not yet actually gotten to work, however it does look pretty > straightforward and no reason it shouldn't work and looks simple to clone > in sd2tpdd (or PDDuino as I've apparently called a local copy on my > laptop). I've mostly just used the separate teensy installer app that comes > in the dlplus zip file because it works. I think the best would be to > duplicate the tpdd2 bootstrap procedure. That works very well and requires > very little of the user when starting from scratch with as fresh cold-reset > M100. But that's at least partly harware dependent. The tpdd2 can tell if > the m100 is "listening" or not at power-on, and decides based on that > whether to just squirt out the IPL basic code even though it didn't receive > any commands. I think it should be possible to replicate that on teensy. It > might require actually hooking up more of the serial control lines so the > teensy can read the state of dtr/dsr or something. > > Anyway, I did manually compile my copy to run at 2mhz, via Tools->CPU > Speed, but I would have thought if you just took the code and compiled it, > it would use the default 180mhz for Teensy 3.6. > And the way the code is configured as it sits on github, it can be run at > 2mhz because the built-in usb-serial console is disabled. > > https://www.youtube.com/watch?v=_lFqsHAlLyg > > -- > bkw > > Bill Nobel > [email protected] <mailto:[email protected]> > > > > On Sep 20, 2019, at 9:06 AM, Brian White <[email protected] <mailto: > [email protected]>> wrote: > > I don't remember any checksum problems with directories with this code on > teensy 3.6 > > https://github.com/aljex/SD2TPDD/tree/bkw_teensy36 > > It's not a complete implementation though so I would be interested in a > good solid re-do. > > Note specifically the bkw-teensy36 branch, not master. Master is Jimmy > Petit's original that I forked from. > > But I was reading and writing files and using sub dirs and getting good > listings in ts-dos etc. > > On Fri, Sep 20, 2019, 5:36 AM Bill Nobel <[email protected] <mailto: > [email protected]>> wrote: > > I should also note an observation I’ve had with my code. I’m > going from the Teensy to a Max3232 to the T-102. Even with power > off on the 102 I receive garbage on the port. My code seems to > catch all the preambles though to start a packet. Code is > starting to get larger so I’m going to post a Github for anybody > to look at. > > Bill > > Sent from my iPhone > > > On Sep 19, 2019, at 10:17 PM, Bill Nobel <[email protected] > <mailto:[email protected]>> wrote: > > > > Hi John, yes I receive 2 packets fine (with response) then > things go strange only on checksum. Your C# routine is different > from DLPlus for the Calc, I’ll try that in the morning and see if > that changes. > > > > Sent from my iPhone > > > >> On Sep 19, 2019, at 9:58 PM, John R. Hogerhuis > <[email protected] <mailto:[email protected]>> wrote: > >> > >> Are you sure you got a full, aligned packet? It starts with ZZ > , counted length, no missing characters? > >> > >> The DLPlus checksum is correct. More likely you're misaligned, > or somehow dropped, swapped, or corrupted a character. > >> > >> Here is the C# code too for comparison > >> > >> public byte Checksum(byte[] ary, uint ofs, uint fence) > >> { > >> uint sum = 0; > >> > >> for (var i = ofs; i < fence; i++) > >> sum += ary[i]; > >> > >> return (byte)((~sum) & 0xff); > >> } > >> > >> Welcome to the cabal of TPDD protocol initiates. > >> > >> -- John. > > > > >
