I agree, just one pre-amble for the whole set of commands. It could be extended further in time, but to start, use one pre-amble to add these extra features. One could really use this to a full network solution with the right Wifi integration (there are many types of this around…)
Bill Nobel b_no...@hotmail.com<mailto:b_no...@hotmail.com> On Sep 22, 2019, at 3:57 PM, Brian White <bw.al...@gmail.com<mailto:bw.al...@gmail.com>> wrote: 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 <b_no...@hotmail.com<mailto:b_no...@hotmail.com>> 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 b_no...@hotmail.com<mailto:b_no...@hotmail.com> On Sep 21, 2019, at 6:34 PM, Brian K. White <bw.al...@gmail.com<mailto:bw.al...@gmail.com>> 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 b_no...@hotmail.com<mailto:b_no...@hotmail.com> <mailto:b_no...@hotmail.com<mailto:b_no...@hotmail.com>> On Sep 20, 2019, at 9:06 AM, Brian White <bw.al...@gmail.com<mailto:bw.al...@gmail.com> <mailto:bw.al...@gmail.com<mailto:bw.al...@gmail.com>>> 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 <b_no...@hotmail.com<mailto:b_no...@hotmail.com> <mailto:b_no...@hotmail.com<mailto:b_no...@hotmail.com>>> 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 <b_no...@hotmail.com<mailto:b_no...@hotmail.com> <mailto:b_no...@hotmail.com<mailto:b_no...@hotmail.com>>> 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 <jho...@pobox.com<mailto:jho...@pobox.com> <mailto:jho...@pobox.com<mailto:jho...@pobox.com>>> 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 <b_no...@hotmail.com<mailto:b_no...@hotmail.com>> 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 b_no...@hotmail.com<mailto:b_no...@hotmail.com> On Sep 21, 2019, at 6:34 PM, Brian K. White <bw.al...@gmail.com<mailto:bw.al...@gmail.com>> 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 b_no...@hotmail.com<mailto:b_no...@hotmail.com> <mailto:b_no...@hotmail.com<mailto:b_no...@hotmail.com>> On Sep 20, 2019, at 9:06 AM, Brian White <bw.al...@gmail.com<mailto:bw.al...@gmail.com> <mailto:bw.al...@gmail.com<mailto:bw.al...@gmail.com>>> 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 <b_no...@hotmail.com<mailto:b_no...@hotmail.com> <mailto:b_no...@hotmail.com<mailto:b_no...@hotmail.com>>> 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 <b_no...@hotmail.com<mailto:b_no...@hotmail.com> <mailto:b_no...@hotmail.com<mailto:b_no...@hotmail.com>>> 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 <jho...@pobox.com<mailto:jho...@pobox.com> <mailto:jho...@pobox.com<mailto:jho...@pobox.com>>> 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.
