Got the sleep working properly now. Goes right to 3ma right from power-up or reset. One last thing that isn't great about power drain is, if the teensy is connected to the M100, and the Teensy is turned on, but the M100 is turned OFF, then it draws 19 ma! But it's good with the teensy on and not connected, or with the teensy on and the m100 on, both before and after any serial or disk activity.
Also started playing with an Adalogger 32u4 (not the adalogger M0) https://www.adafruit.com/product/2795 I don't have SD2TPDD working on it yet, but it should work. Much less horsepower than the teensy, which feels more elegant than using such a powerful beast. And the adalogger has built-in lipo battery manager. Just plug the battery in and it's automatically charged from the usb port. For the teensy you need to cut a trace on the teensy and add a separate lipo charger module (if you don't want two different usb ports on the final device). Still pretty easy, but still, you can't beat already-built-in. However... The teensy has built-in audio dacs and adc's, and the software libraries, and the cpu grunt, and ram needed to record to and play from SD. The Teensy's SD hardware is special too so it's more efficient than most (moves more data with fewer cpu cycles) That means the Teensy could both play and record cassette files. I just grabbed a few jacks this morning, including a 2.5mm one for the remote play/pause control. I kinda-sorta-almost figured out how to read the fat volume label too, which could be used to put in the top-right corner of the TS-DOS display, but the way I managed it is utterly un-usable. I haven't managed to go from that hack to something actually usable. I think I might have to look at raw read/write examples to just look at the disk ignoring the filesystem. https://forum.arduino.cc/index.php?topic=567603.0 -- bkw On Tue, Sep 4, 2018 at 7:12 AM Brian White <bw.al...@gmail.com> wrote: > Forgot to say, by adding avr/sleep.h > I think there might be other better low power libraries and examples. This > was just my first attempt. > It's not quite working right, but close. It draws 15ma on power-up until > the first command is processed, then it acts like I wanted after that. It > draws 3.3ma while idle, yet wakes up and runs whenever the M100 tries to > access it. It's amazing that it wakes up and seems to even process the same > serial event that woke it up without losing something like the first byte > or something. > > > On Tue, Sep 4, 2018 at 7:02 AM Brian White <bw.al...@gmail.com> wrote: > >> I got it idling at 3.3ma. Holy crap 3.3ma! >> This includes the rs232 module being powered from the Teensy. >> This is with all the usb-serial code ifdef'd out, and the cpu clocked at >> 2Mhz. >> I'm not using RTS/CTS any more either, since TS-DOS itself doesn't. >> https://youtu.be/_lFqsHAlLyg >> >> On Sun, Sep 2, 2018 at 1:23 PM c646581 <c646...@gmail.com> wrote: >> >>> It's possible that I may have screwed up somewhere and forgotten to pad >>> the shorter file names? I had a similar issue with short directory names >>> and just needed to add a routine to pad it out with extra spaces. It'd be >>> interesting to see what the directory reference return looks like when >>> TpddTool sends the file name reference command. >>> >>> It could also be trying to use directory reference features that I never >>> implemented, since my initial use case was strictly TS-DOS. For example, I >>> don't have any code for "seeking backwards" in the directory. TS-DOS never >>> uses it. >>> >>> Heheh, no worries. :P >>> >>> On Sun, Sep 2, 2018, 13:16 Brian White <bw.al...@gmail.com> wrote: >>> >>>> I don't see anything obvious either, but I haven't gotten methodical on >>>> it yet. >>>> >>>> What I've seen so far is: >>>> >>>> dir 0: works fine. >>>> >>>> Neither reading or writing a file works, though TpddTool thinks writes >>>> work. >>>> >>>> When reading, TpddTool generates the initial searchform that looks the >>>> same as ts-dos, except not. The debug output from sd2tpdd says Ref: >>>> TEST2.DO the same as TS-DOS, but with ts-dos the filename appears twice in >>>> the output with a newline and slash between them, and with TpddTool the >>>> name only appears once. Then for TpddTool there is no subsequent open or >>>> read. So I think there is a difference in how a string is being handled >>>> somewhere along the way, causing SD2TPDD to say there is no such file. Note >>>> this sample filename is less than 6 chars. I haven't even tried something >>>> simple like try a full 6.2 filename yet just to see. I'm out at breakfast >>>> at the moment. >>>> >>>> Well with a busted ankle, maybe you can have someone bring you your >>>> laptop from your bench and you'll have days and days with nothing else to >>>> do but tinker with a hobby project. Ok that was callous sorry. :) >>>> >>>> On Sun, Sep 2, 2018, 12:26 PM c646581 <c646...@gmail.com> wrote: >>>> >>>>> Sorry for the inactivity. I fell off of a ladder at work and broke my >>>>> ankle. I haven't been able to circle back around and catch up to the >>>>> developments in this thread. >>>>> >>>>> I really like the idea of using a teensy instead of the Mega! There is >>>>> a lot more power there for doing things like an OLED display and >>>>> networking >>>>> capabilities. I also really love the idea of having a "TPDD server" box >>>>> that multiple M100s (or PCs with serial ports) can connect to! >>>>> >>>>> I really want to try out the Teensy's hardware flow control at some >>>>> point. If I recall, there are some timing issues with SD2TPDD if it runs >>>>> at >>>>> 19200 baud and you have too much debug info active. I think I have a >>>>> Teensy >>>>> 3.2 hiding in my parts drawer somewhere... >>>>> >>>>> I looked over the TpddTool.py code and can't figure out why it won't >>>>> work with SD2TPDD. It's possible that I forgot to send the correct "normal >>>>> return" for something and it dislikes that. If I can, I'll try to dig into >>>>> the issue. I can't get to my workbench at the moment with my broken ankle. >>>>> >>>>> An idea that I have been kicking around in my head is to modify >>>>> SD2TPDD to "WiFi2TPDD" using an ESP32 as the host. The device has enough >>>>> non-volatile storage to hold the TS-DOS image, and configuration could be >>>>> done by writing a config file to the device using TS-DOS. The config file >>>>> would tell it which SSID to connect to, the password, and a list of FTP >>>>> servers to have show up in the root directory presented to TS-DOS. >>>>> >>>>> >>>>> >>>>> On Sun, Sep 2, 2018, 11:43 Brian White <bw.al...@gmail.com> wrote: >>>>> >>>>>> Well it turns out this works fine with TS-DOS, it just doesn't work >>>>>> with TpddTool.py! >>>>>> It's strange: >>>>>> * TS-DOS works with a real TPDD2 (obviously) >>>>>> * TpddTool.py works with a real TPDD2 >>>>>> * TS-DOS works with SD2TPDD >>>>>> * TpddTool.py does not work with SD2TPDD >>>>>> >>>>>> ??? whatever I'll figure t out sooner or later. Just wanted to >>>>>> correct me saying it wasn't working before. Up to now I'd just been using >>>>>> TpddTool.py on the same laptop. But just now trying TS-DOS, it works >>>>>> fine! >>>>>> >>>>>> >>>>>> On Wed, Aug 29, 2018 at 11:49 AM Brian White <bw.al...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> I just got your arduino code working on a Teensy 3.6, using the >>>>>>> built-in card reader, SdFatSdioEX, hardware flow control, and even >>>>>>> writing >>>>>>> status/progress messages out to a little oled screen. >>>>>>> https://photos.app.goo.gl/DaR7pHERsgNrGs718 >>>>>>> >>>>>>> So far, with the oled stuff enabled I can clock down to 4mhz and >>>>>>> it's still fast enough that TpddTool.py doesn't time out. Haven't tried >>>>>>> on >>>>>>> a M100 yet. Maybe without the oled or usb serial it can even manage >>>>>>> 2mhz. >>>>>>> >>>>>>> Using other code experimenting with sleep calls, I was able to get >>>>>>> it to idle at 10ma, and wake itself up from the serial rx1 pin, then go >>>>>>> back to sleep. In that code I was drawing only about 28ma while writing, >>>>>>> then back down to 10-11ma. That's including the teensy providing the >>>>>>> 3.3v >>>>>>> to power the rs232 tranceiver. >>>>>>> >>>>>>> Eventually I want to make use of the teeny's built in rtc too. >>>>>>> Should be easy enough to have the teensy recognize a special file name >>>>>>> and >>>>>>> feed back data from the rtc in place of a file. >>>>>>> >>>>>>> https://github.com/aljex/SD2TPDD/tree/bkw_teensy36 >>>>>>> >>>>>>> It's not working too well yet, but it's running and at least >>>>>>> partially working. >>>>>>> >>>>>>> TPDD-Tool>copy TEST3.DO 0:TEST3.DO >>>>>>> Copy successful >>>>>>> TPDD-Tool>dir 0: >>>>>>> TEST2 .DO 655 >>>>>>> TEST1 .DO 12 >>>>>>> 163840 bytes free >>>>>>> >>>>>>> TPDD-Tool> >>>>>>> >>>>>>> This is awesome! (I mean, a great start) Thank you! >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> bkw >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 20, 2018 at 4:31 PM c646581 <c646...@gmail.com> wrote: >>>>>>> >>>>>>>> I have a project that uses an Arduino Mega to emulate a TPDD. >>>>>>>> >>>>>>>> https://github.com/TangentDelta/SD2TPDD >>>>>>>> >>>>>>>> I have plans to eventually sell easy-to-use shields that provide >>>>>>>> the RS232 level shifting and SD card interface. >>>>>>>> >>>>>>>> On Mon, Aug 20, 2018, 16:02 Brian White <bw.al...@gmail.com> wrote: >>>>>>>> >>>>>>>>> A tpdd emulated in low level basic hardware in line with the tpdd >>>>>>>>> itself really appeals to me. >>>>>>>>> >>>>>>>>> I would love to try to make it work on a tinyduino, or maybe a >>>>>>>>> gotek. Tinyduino may not seem "basic" being so small and modern, but >>>>>>>>> it's a >>>>>>>>> microcontroller not a PC. It doesn't run linux and systemd and bash >>>>>>>>> and >>>>>>>>> getty and python and a tcp stack and ssl and X and gnome etc etc etc. >>>>>>>>> >>>>>>>>> The fact that an entire pc fits in a tiny space and uses no power >>>>>>>>> and costs $5 today thanks to the plain advancement over the passage of >>>>>>>>> time, is sort of beside the point. Sure it's practical, but it's not >>>>>>>>> *elegant*, in some intangible abstract mental way. >>>>>>>>> >>>>>>>>> You could run dlplus or laddie from an init script on an Omega2 >>>>>>>>> and stuff the entire thing inside of a db25 connector shell, and >>>>>>>>> probably >>>>>>>>> even scavenge enough power right from the usb port with charge pumps, >>>>>>>>> and >>>>>>>>> the entire thing would be small and cheap and relatively easy to do, >>>>>>>>> since >>>>>>>>> it's just sticking a few existing things together like legos. >>>>>>>>> Outwardly >>>>>>>>> this makes all the sense in the world. But it's just such a >>>>>>>>> brute-force >>>>>>>>> kind of solution. I'd rather spend all kinds of time and effort to do >>>>>>>>> the >>>>>>>>> same thing with a controller in place of the computer. >>>>>>>>> >>>>>>>>> Though, you can sure get a lot more functionality out of a >>>>>>>>> computer, like that virtual modem in mcomm. And the computer is >>>>>>>>> infinitely >>>>>>>>> more end-user hackable. It would be neat to play with hacking >>>>>>>>> together some >>>>>>>>> sort of front-end dispatcher script, kind of like inetd for serial or >>>>>>>>> I >>>>>>>>> guess that would just be an amped-up getty, maybe even with an >>>>>>>>> interactive >>>>>>>>> menu that you can access via TELCOM, and the front end runs a tpdd >>>>>>>>> server >>>>>>>>> or a dos injector or ssh client or lynx or virtual modem or something >>>>>>>>> else >>>>>>>>> and hooks it to the tty. It could stay in the loop monitoring the tty >>>>>>>>> for >>>>>>>>> special escape commands to break out into a command mode just like >>>>>>>>> modems, >>>>>>>>> telnet, ssh, cu etc all do, so you could always switch between >>>>>>>>> functions >>>>>>>>> from the M100 even after starting one. >>>>>>>>> >>>>>>>>> gahh ideas are sure easy to throw around :) >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> bkw >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> bkw >>>>>> >>>>> >> >> -- >> bkw >> > > > -- > bkw > -- bkw
