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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >> >
