Re: [M100] 19.2Kbps on the Tandy 102
> Also T200 not working with hardware flow control? It used to. Steve ported HTERM to it. I do recall we had issues with the > 19200bps baud rates on the T200. Well, know how part of the theme of this thread is things not happening the way we remember them? I had this flagged as a flow control issue, guess it sort of is but what I was remembering is the T200 using the DTR signal for chip select on the tone generator. On the M100/102 if you disable hardware flow control they will ignore DTR as expected. The T200, regardless of how you set flow control, wanders off and doesn't come back until you present it with DTR. So in this case, my setup will not work unless you loop back DTR with a jumper. Brian On Tue, Dec 12, 2023 at 9:25 PM Daryl Tester < dt-m...@handcraftedcomputers.com.au> wrote: > On 13/12/23 09:39, John R. Hogerhuis wrote: > > > But what I recollect and what happened are not always the same thing. > > Oh man, I hear you there, especially the more ... "seasoned" I get. > > Cheers, >--dt >
Re: [M100] 19.2Kbps on the Tandy 102
Hello, I know it is starting to be off-topic, but some details about how you did the pi (I assume a zero-w) and the case with the level-shifter would be nice. I've done this with other components, but I've never gotten anything nearly so small. I have a pi-hat with a level shifter, and it basically doubled the size of pi zero. Something this small and that would plug right into the serial port of the m100 would be great. Jonathan >Original Message >From : run@rin.run >Date : 2023-12-13 - 02:11 (CEST) >To : m...@bitchin100.com >Subject : Re: [M100] 19.2Kbps on the Tandy 102 > >Wow Brian! > >This setup with the Pi attached to the back looks amazing. It's attached >so cleanly as well. I appreciate you doing the `stty' at the end, >hopefully mirroring your setup will help me get things working better on >my end. > >I do wonder if the fact that you are using the Pi's GPIO pins to do >serial instead of a USB adapter is part of why your system is working so >well. If you have a USB adapter floating around, I'd be really curious >if you got the same results with that connected to the PI instead of >connecting it directly. > >Thanks again for sharing your experience getting this working. > >On Tue, Dec 12, 2023 at 05:42:28PM -0500, Brian Brindle wrote: >>This has come up in discussion a few times so I wanted to show that >>19.2Kbps on the Tandy 100 is possible with only software flow control. >> >>Here is a video of me creating a 500 line 40 col file that is 20KB, >>transferring it to the M102 and back again using the 19.2Kbps serial >>connection. It gets slowed down due to the screen being so slow making >>it absolutely of no value to be running at those speeds but does >>demonstrate that flow control can be used on a Linux device in this >>situation. >> >>Hardware flow control would work best and is what I would recommend but >>I wanted a device that would work on a stock M100/102 and on a M200 >>where the flow control lines do not work properly. >> >>It's apparently really hard to film, type and remember what to say so I >>apologize for that.. >> >>[1]https://youtu.be/BGxx__Zr1O4 >> >>Brian >> >> References >> >>1. https://youtu.be/BGxx__Zr1O4 >
Re: [M100] 19.2Kbps on the Tandy 102
Hi Jonathan, My whole setup is a total kludge / hack that I never expected to use long term. I was just doing a POC and built the whole thing in about 10 minutes with stuff I had laying around but here we are almost five years later... One day I'll get off my butt and make a proper 3d printed case etc. I'll provide some amazon links to similar stuff I used but shop around I'm sure you'll find better prices. I was building contact tracing devices during Covid so had a surplus of Pi Zero's and these cases: https://www.amazon.com/Vilros-Raspberry-Zero-Compatible-Transparent/dp/B08ZDPNM4H I cut a hole in it with a file, drilled two holes for the screw mounts. I used a standard bulk-head mount DB-25 Pin male connector, cut all the pins off the backside so they were flush, used some small gage wire to connect to a Mini RS232 to TTL MAX232 Convert board like these: https://www.amazon.com/KOOBOOK-MAX3232-Converter-Adaptor-Transfer/dp/B07VNLVJ57 Wired up TX/RX to the RIN1 and ROUT1 of the converter board, then wired the DIN1 / DOUT1 to the proper GPIO ports on the PI soldering directly to the pads. Grabbed 3V off the Rpi to power the converter. (3V ran cooler than trying to run off 5V. 5V got super hot.) Here are some photos of the unit including a bonus photo of me on the bus being all cyber-punk with my M102 and my heads up display. It was pandemic times so forgive the mask. https://niedobry.com/mod100/tanpi/ On Wed, Dec 13, 2023 at 7:06 AM jonathan.y...@telia.com < jonathan.y...@telia.com> wrote: > Hello, > > I know it is starting to be off-topic, but some details about how you did > the pi (I assume a zero-w) and the case with the level-shifter would be > nice. I've done this with other components, but I've never gotten anything > nearly so small. I have a pi-hat with a level shifter, and it basically > doubled the size of pi zero. Something this small and that would plug > right into the serial port of the m100 would be great. > > Jonathan > > >Original Message > >From : run@rin.run > >Date : 2023-12-13 - 02:11 (CEST) > >To : m...@bitchin100.com > >Subject : Re: [M100] 19.2Kbps on the Tandy 102 > > > >Wow Brian! > > > >This setup with the Pi attached to the back looks amazing. It's attached > >so cleanly as well. I appreciate you doing the `stty' at the end, > >hopefully mirroring your setup will help me get things working better on > >my end. > > > >I do wonder if the fact that you are using the Pi's GPIO pins to do > >serial instead of a USB adapter is part of why your system is working so > >well. If you have a USB adapter floating around, I'd be really curious > >if you got the same results with that connected to the PI instead of > >connecting it directly. > > > >Thanks again for sharing your experience getting this working. > > > >On Tue, Dec 12, 2023 at 05:42:28PM -0500, Brian Brindle wrote: > >>This has come up in discussion a few times so I wanted to show that > >>19.2Kbps on the Tandy 100 is possible with only software flow > control. > >> > >>Here is a video of me creating a 500 line 40 col file that is 20KB, > >>transferring it to the M102 and back again using the 19.2Kbps serial > >>connection. It gets slowed down due to the screen being so slow > making > >>it absolutely of no value to be running at those speeds but does > >>demonstrate that flow control can be used on a Linux device in this > >>situation. > >> > >>Hardware flow control would work best and is what I would recommend > but > >>I wanted a device that would work on a stock M100/102 and on a M200 > >>where the flow control lines do not work properly. > >> > >>It's apparently really hard to film, type and remember what to say > so I > >>apologize for that.. > >> > >>[1]https://youtu.be/BGxx__Zr1O4 > >> > >>Brian > >> > >> References > >> > >>1. https://youtu.be/BGxx__Zr1O4 > > >
Re: [M100] 19.2Kbps on the Tandy 102
> On Dec 13, 2023, at 6:22 AM, Brian Brindle wrote: > My whole setup is a total kludge / hack that I never expected to use long > term. I was just doing a POC and built the whole thing in about 10 minutes > with stuff I had laying around but here we are almost five years later... Brian, you may consider this rig a kludge, but I'm jealous and think it's gorgeous. Using the T as a portable terminal with a perfectly capable tiny Linux box cleverly attached is a great hack. I wish I had one of these! A 9-pin WP-2 version—what with the 80-column display—would be amazing. Now that I think about it, have you tried using either one of the 80-column software setups, like ROM-View 80 or Ultrascreen100? It might make for an even more pleasant terminal experience. Gosh, I'm tempted to ask if you'd slap another one together in your copious free time!
Re: [M100] 19.2Kbps on the Tandy 102
On Wed, Dec 13, 2023 at 3:30 AM Brian Brindle wrote: > I had this flagged as a flow control issue, guess it sort of is but what I > was remembering is the T200 using the DTR signal for chip select on the > tone generator. > Hmm, now that rings a bell. (Ba-dump-TI). Maybe that's why it was working for us... I doubt we care about DTR in HTERM other than to turn on DSR and then ignore it. But then there's no "enabling" hardware flow control on the Model 100 either. It's just a signal you can check with an I/O instruction. Other than DTR which is more of connection/peer check than flow control. -- John.
Re: [M100] Question about TPDD/FB100
I should write up some steps to verify things, both for the cable and for pdd.sh. It's one thing to say "do this to make this" but then when it doesn't work, then what? Is something broken or did you get a step wrong or are the directions wrong? One thing is with the solder blob in place, you should tell pdd.sh to run at 9600, which is not the default. ```$ BAUD=9600 pdd``` or issue "baud 9600" command after starting pdd. Since it's not the default, if you hadn't used the baud command or variable then it wouldn't have worked before you removed the solder blob. With all jumpers open, the drive is at 19200 and the default in pdd.sh is 19200 so you're good to go now. I have a FB100 with the blob still in place. So I can at least confirm that with a good cable and drive and usb serial adapter, no disk inserted, door opened or closed, "ready" and "ls" do work and the access light only blinks for a split second and the motor never starts at all. Getting no reaction at all sounds like no communication. I have a Purple Computing drive that doesn't work, and just looks dead in a normal tpdd client, but with pdd.sh I can tell that the controller is up and running fine, accepting commands and returning results and communicating just fine, and even reading the door-open, disk-inserted, & write-protect sensors, merely it can't actually read or write media. On that drive, "ready" and "ls" still work, at least in so far as they accept the command and return a result, all sensibly. The "ls" just says there was a disk error, but the point is the drive responds and SAYS disk error, because communication is working. You could try the verbose setting to see if you can tell if the drive is responding at all, not at all, or with unexpected data that pdd.sh doesn't understand. Here is a capture of a short verbose session with a working FB100 with the door open and no disk inserted. You will omit the BAUD=9600. I wanted to do this on an actual FB100 just to be sure we're both testing the same things, and mine still has the solder blob. What we're looking for is, did the stty command at the beginning seem to work? Some other problem like a permissions problem with my gimmicky sleep() function that uses a trick with a fifo file to get a sleep function without having to execute the external /bin/sleep? Did the drive ever return even a single byte of anything? The verbosity shows every byte of traffic in either direction, so, even if the data is unrecognized and not handled, you can still see that there was data, or not. bkw@fw:~$ bkw@fw:~$ BAUD=9600 VERBOSE=9 pdd ready get_tpdd_port() Using port "/dev/ttyUSB0" open_com() set_stty() speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 1; -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc do_cmd(ready) _init() fonzie_smack() tpdd_drain() tpdd_check() tpdd_write(4D 31 0D) tpdd_drain() tpdd_check() pdd2_unk23() ocmd_send_req(23) calc_cksum(23 00):DC ocmd_send_req: fmt="23" len="00" dat="" chk="DC" tpdd_write(5A 5A 23 00 DC) ocmd_read_ret(100) ocmd_read_ret: reading 2 bytes (fmt & len) tpdd_read(2 100) tpdd_wait(100) tpdd_check() tpdd_check() Detected TPDD1 ocmd_ready() ocmd_send_req(07) calc_cksum(07 00):F8 ocmd_send_req: fmt="07" len="00" dat="" chk="F8" tpdd_write(5A 5A 07 00 F8) ocmd_read_ret() ocmd_read_ret: reading 2 bytes (fmt & len) tpdd_read(2) tpdd_wait() tpdd_check() tpdd_wait: :0 tpdd_read: l=2 12 01 ocmd_read_ret: reading 2 bytes (data & checksum) tpdd_read(2) tpdd_wait() tpdd_check() tpdd_wait: :0 tpdd_read: l=2 71 7B ocmd_read_ret: fmt=12 len=01 dat=(71) chk=7B verify_checksum(12 01 71 7B) calc_cksum(12 01 71):7B verify_checksum: given:7B calc:7B ocmd_check_err() ocmd_check_err: ret_fmt=12 ret_len=01 ret_dat=(71) read_err="0" ocmd_check_err: 71:Disk Not Inserted or Disk Change Error Not Ready ready: Disk Not Inserted or Disk Change Error bkw@fw:~$ -- I'll break down some of that to explain what you're looking at: tpdd_write(5A 5A 23 00 DC) ocmd_read_ret(100) ocmd_read_ret: reading 2 bytes (fmt & len) tpdd_read(2 100) tpdd_wait(100) tpdd_check() tpdd_check() Detected TPDD1 This looks like we aren't displaying something because we sent 5A 5A 23 00 DC to the drive, and then just declared "detected tpdd1" without seeing the response from the drive. In this case, that is actually how we detect tpdd1 is by the lack of response to that command. ocmd_ready() ocmd_send_req(07) calc_cksum(07 00):F8 ocmd_send_req: fm
Re: [M100] Question about TPDD/FB100
OK! I think there might be a problem with my PC cable. With a standard 25 pin to 9 pin adapter and a gender changer on my M100 cable, I'm getting some output, but there may be some other issues with the drive or cable. I will paste my results below. `ready' without a disk: % VERBOSE=9 ./pdd.sh ready get_tpdd_port() Using port "/dev/ttyUSB0" open_com() set_stty() speed 19200 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 1; -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc do_cmd(ready) _init() fonzie_smack() tpdd_drain() tpdd_check() tpdd_write(4D 31 0D) tpdd_drain() tpdd_check() pdd2_unk23() ocmd_send_req(23) calc_cksum(23 00):DC ocmd_send_req: fmt="23" len="00" dat="" chk="DC" tpdd_write(5A 5A 23 00 DC) ocmd_read_ret(100) ocmd_read_ret: reading 2 bytes (fmt & len) tpdd_read(2 100) tpdd_wait(100) tpdd_check() tpdd_check() Detected TPDD1 ocmd_ready() ocmd_send_req(07) calc_cksum(07 00):F8 ocmd_send_req: fmt="07" len="00" dat="" chk="F8" tpdd_write(5A 5A 07 00 F8) ocmd_read_ret() ocmd_read_ret: reading 2 bytes (fmt & len) tpdd_read(2) tpdd_wait() tpdd_check() tpdd_wait: :0 tpdd_read: l=2 12 01 ocmd_read_ret: reading 2 bytes (data & checksum) tpdd_read(2) tpdd_wait() tpdd_check() tpdd_wait: :0 tpdd_read: l=2 71 7B ocmd_read_ret: fmt=12 len=01 dat=(71) chk=7B verify_checksum(12 01 71 7B) calc_cksum(12 01 71):7B verify_checksum: given:7B calc:7B ocmd_check_err() ocmd_check_err: ret_fmt=12 ret_len=01 ret_dat=(71) read_err="0" ocmd_check_err: 71:Disk Not Inserted or Disk Change Error Not Ready ready: Disk Not Inserted or Disk Change Error ready with a disk in: % VERBOSE=9 ./pdd.sh ready get_tpdd_port() Using port "/dev/ttyUSB0" open_com() set_stty() speed 19200 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 1; -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc do_cmd(ready) _init() fonzie_smack() tpdd_drain() tpdd_check() tpdd_write(4D 31 0D) tpdd_drain() tpdd_check() pdd2_unk23() ocmd_send_req(23) calc_cksum(23 00):DC ocmd_send_req: fmt="23" len="00" dat="" chk="DC" tpdd_write(5A 5A 23 00 DC) ocmd_read_ret(100) ocmd_read_ret: reading 2 bytes (fmt & len) tpdd_read(2 100) tpdd_wait(100) tpdd_check() tpdd_check() Detected TPDD1 ocmd_ready() ocmd_send_req(07) calc_cksum(07 00):F8 ocmd_send_req: fmt="07" len="00" dat="" chk="F8" tpdd_write(5A 5A 07 00 F8) ocmd_read_ret() ocmd_read_ret: reading 2 bytes (fmt & len) tpdd_read(2) tpdd_wait() tpdd_check() tpdd_wait: :0 tpdd_read: l=2 12 01 ocmd_read_ret: reading 2 bytes (data & checksum) tpdd_read(2) tpdd_wait() tpdd_check() tpdd_wait: :0 tpdd_read: l=2 00 EC ocmd_read_ret: fmt=12 len=01 dat=(00) chk=EC verify_checksum(12 01 00 EC) calc_cksum(12 01 00):EC verify_checksum: given:EC calc:EC ocmd_check_err() ocmd_check_err: ret_fmt=12 ret_len=01 ret_dat=(00) read_err="0" ocmd_check_err: 00:OK Ready `ls' without a disk: VERBOSE=9 ./pdd.sh ls get_tpdd_port() Using port "/dev/ttyUSB0" open_com() set_stty() speed 19200 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 1; -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc do_cmd(ls) _init() fonzie_smack() tpdd_drain
Re: [M100] Question about TPDD/FB100
Communication all looks good actually. Cabling and serial port are solid. The problem is only when it issues the initial dirent() as part of the directory listing process, and gets a hardware fault error code from the drive. The drive firmware tried to run the disk and read the media, and failed, and said so. It may possibly just be that the disk is not formatted. The disk needs to be formatted by the drive, it can not use the normal PC formatting the disk already has. So verify: * The drive has a good belt. * The disk is DD not HD, aka 720K not 1.4M, aka has only one hole in one corner. * The write-protect door in that one hole is closed (open=write-protect). * The disk contains no data you care about. Then in pdd.sh issue the "format" command. Wait approximately one solar flare cycle. Ok 100 seconds but feels like 11 years because there is no data on the wire all during that time and no way to monitor progress. Even in verbose mode the percent-done animation is just counting down the expected time which is known. And you can't do any better. You can not send any data to the drive during this time or it will just crash it. The client must just sit and wait for data from the drive, or abort if no data comes after some max possible time. Maybe your drive has the same problem my Purple Computing drive has. Everything works except actually accessing the media. So like, something wrong with the drive head or it's signal amplifier maybe? I have not figured out what's actually wrong with mine yet. That level of problem may be just a bit beyond me, figuring out how the head read circuit actaully works and where to probe with a scope and what to expect there etc. Though, I have a scope and haven't actually tried yet so who knows. -- bkw On 12/13/23 15:22, runrin wrote: OK! I think there might be a problem with my PC cable. With a standard 25 pin to 9 pin adapter and a gender changer on my M100 cable, I'm getting some output, but there may be some other issues with the drive or cable. I will paste my results below. `ready' without a disk: % VERBOSE=9 ./pdd.sh ready get_tpdd_port() Using port "/dev/ttyUSB0" open_com() set_stty() speed 19200 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 1; -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc do_cmd(ready) _init() fonzie_smack() tpdd_drain() tpdd_check() tpdd_write(4D 31 0D) tpdd_drain() tpdd_check() pdd2_unk23() ocmd_send_req(23) calc_cksum(23 00):DC ocmd_send_req: fmt="23" len="00" dat="" chk="DC" tpdd_write(5A 5A 23 00 DC) ocmd_read_ret(100) ocmd_read_ret: reading 2 bytes (fmt & len) tpdd_read(2 100) tpdd_wait(100) tpdd_check() tpdd_check() Detected TPDD1 ocmd_ready() ocmd_send_req(07) calc_cksum(07 00):F8 ocmd_send_req: fmt="07" len="00" dat="" chk="F8" tpdd_write(5A 5A 07 00 F8) ocmd_read_ret() ocmd_read_ret: reading 2 bytes (fmt & len) tpdd_read(2) tpdd_wait() tpdd_check() tpdd_wait: :0 tpdd_read: l=2 12 01 ocmd_read_ret: reading 2 bytes (data & checksum) tpdd_read(2) tpdd_wait() tpdd_check() tpdd_wait: :0 tpdd_read: l=2 71 7B ocmd_read_ret: fmt=12 len=01 dat=(71) chk=7B verify_checksum(12 01 71 7B) calc_cksum(12 01 71):7B verify_checksum: given:7B calc:7B ocmd_check_err() ocmd_check_err: ret_fmt=12 ret_len=01 ret_dat=(71) read_err="0" ocmd_check_err: 71:Disk Not Inserted or Disk Change Error Not Ready ready: Disk Not Inserted or Disk Change Error ready with a disk in: % VERBOSE=9 ./pdd.sh ready get_tpdd_port() Using port "/dev/ttyUSB0" open_com() set_stty() speed 19200 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 1; -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc do_cmd(ready) _init() fonzie_smack() tpdd_drain() tpdd_check() tpdd_write(4D 31 0D) t
Re: [M100] 19.2Kbps on the Tandy 102
Haha - Glad you like it Joshua if I do happen to make more or improve on
this one I'll let you know. I don't exactly have ADD but what I do seem to
have is the inability to control what my current interests are and recently
it's been playing with CP/M on the M100, PX-8 and building up a CP/M
emulation environment on the TanPi. That was going great till I managed to
get my hands on one of the MiniNDPs Brian K White made and now I'm all
about his recent 512K upgrade. Never thought I'd get to play with an NDP so
this is exciting stuff.
I have a WP-2 and have tried to use the TanPi on it, but usually ended up
frustrated with the lack of needed keys. When doing unixy stuff having
pipes, curly braces, back ticks etc are handy. The M100 seems to have
everything I need, although you do have to know to hit shift GRPH - to do a
pipe and GRPH ( for { etc.
I like ROM-View 80 but for me it's not enough of a payoff to have to
reconfigure the local terminal settings to accommodate the new layout. The
way I use the TanPi is primarily for content creation and syncing. I will
write documents either with a real editor or just by typing cat > file.txt
and typing away with CTRL-C to stop. Then sync the files with my local
storage or the cloud when I have WiFi. If I need to do something really
heavy I'll use an external screen or my VNC session with my phone.
A lot of times when I'm at home I will ssh into my TanPi from my desktop
and can drag/drop files over SSH, use the real keyboard and monitor for
stuff and it's quite handy.
It's a fun toy.
Brian
On Wed, Dec 13, 2023 at 1:29 PM Joshua O'Keefe
wrote:
> > On Dec 13, 2023, at 6:22 AM, Brian Brindle wrote:
> > My whole setup is a total kludge / hack that I never expected to use
> long term. I was just doing a POC and built the whole thing in about 10
> minutes with stuff I had laying around but here we are almost five years
> later...
>
> Brian, you may consider this rig a kludge, but I'm jealous and think it's
> gorgeous. Using the T as a portable terminal with a perfectly capable tiny
> Linux box cleverly attached is a great hack. I wish I had one of these! A
> 9-pin WP-2 version—what with the 80-column display—would be amazing.
>
> Now that I think about it, have you tried using either one of the
> 80-column software setups, like ROM-View 80 or Ultrascreen100? It might
> make for an even more pleasant terminal experience.
>
> Gosh, I'm tempted to ask if you'd slap another one together in your
> copious free time!
Re: [M100] Question about TPDD/FB100
unfortunately format fails with the same error. i'll try tearing the thing open later and see if i can find anything obviously wrong with it. here's what i got: % VERBOSE=9 ./pdd.sh format get_tpdd_port() Using port "/dev/ttyUSB0" open_com() set_stty() speed 19200 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 1; -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc do_cmd(format) _init() fonzie_smack() tpdd_drain() tpdd_check() tpdd_write(4D 31 0D) tpdd_drain() tpdd_check() pdd2_unk23() ocmd_send_req(23) calc_cksum(23 00):DC ocmd_send_req: fmt="23" len="00" dat="" chk="DC" tpdd_write(5A 5A 23 00 DC) ocmd_read_ret(100) ocmd_read_ret: reading 2 bytes (fmt & len) tpdd_read(2 100) tpdd_wait(100) tpdd_check() tpdd_check() Detected TPDD1 ocmd_format() Formatting Disk, TPDD1 filesystem : Are you sure? (y/N) y ocmd_send_req(06) calc_cksum(06 00):F9 ocmd_send_req: fmt="06" len="00" dat="" chk="F9" tpdd_write(5A 5A 06 00 F9) ocmd_read_ret(105000 2) ocmd_read_ret: reading 2 bytes (fmt & len) tpdd_read(2 105000 2) tpdd_wait(105000 2) tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_wait: 105000 2:2500 tpdd_read: l=2 12 01 ocmd_read_ret: reading 2 bytes (data & checksum) tpdd_read(2) tpdd_wait() tpdd_check() tpdd_wait: :0 tpdd_read: l=2 80 6C ocmd_read_ret: fmt=12 len=01 dat=(80) chk=6C verify_checksum(12 01 80 6C) calc_cksum(12 01 80):6C verify_checksum: given:6C calc:6C ocmd_check_err() ocmd_check_err: ret_fmt=12 ret_len=01 ret_dat=(80) read_err="0" ocmd_check_err: 80:Hardware Fault 0 format: Hardware Fault 0 On Wed, Dec 13, 2023 at 04:23:11PM -0500, Brian K. White wrote: > Communication all looks good actually. Cabling and serial port are solid. > The problem is only when it issues the initial dirent() as part of the > directory listing process, and gets a hardware fault error code from the > drive. > > The drive firmware tried to run the disk and read the media, and failed, and > said so. > > It may possibly just be that the disk is not formatted. The disk needs to be > formatted by the drive, it can not use the normal PC formatting the disk > already has. > > So verify: > * The drive has a good belt. > * The disk is DD not HD, aka 720K not 1.4M, aka has only one hole in one > corner. > * The write-protect door in that one hole is closed (open=write-protect). > * The disk contains no data you care about. > > Then in pdd.sh issue the "format" command. > Wait approximately one solar flare cycle. > > Ok 100 seconds but feels like 11 years because there is no data on the wire > all during that time and no way to monitor progress. Even in verbose mode > the percent-done animation is just counting down the expected time which is > known. And you can't do any better. You can not send any data to the drive > during this time or it will just crash it. The client must just sit and wait > for data from the drive, or abort if no data comes after some max possible > time. > > Maybe your drive has the same problem my Purple Computing drive has. > Everything works except actually accessing the media. > So like, something wrong with the drive head or it's signal amplifier maybe? > I have not figured out what's actually wrong with mine yet. That level of > problem may be just a bit beyond me, figuring out how the head read circuit > actaully works and where to probe with a scope and what to expect there etc. > Though, I have a scope and haven't actually tried yet so who knows. > > -- > bkw > > > On 12/13/23 15:22, runrin wrote: > > OK! I think there might be a problem with my PC cable. > > > > With a standard 25 pin to 9 pin adapter and a gender changer on my M100 > > cable, I'm getting some output, but there may be some other issues with > > the drive or cable. > > > > I will paste my results below. > > > > > > `ready' without a disk: > > > > > > % VERBOSE=9 ./pdd.sh ready > > get_tpdd_port() > > Using port "/dev/ttyUSB0" > > open_com() > > set_stty() > > speed 19200 baud; rows 0; columns 0; line = 0; > > intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; > > eol2 = ; swtch = ;
Re: [M100] 19.2Kbps on the Tandy 102
> On Dec 13, 2023, at 1:34 PM, Brian Brindle wrote: > > building up a CP/M emulation environment on the TanPi Feel free to reach out about this off-list. I've done a fair bit of fooling around with the various CP/M emulation environments and have found RunCPM to work *really* well as a daily driver CP/M subsystem. Happy to talk about that.
Re: [M100] 19.2Kbps on the Tandy 102
Is it worth trying to come up with some surgery bodge procedure to
upgrade a 256K unit to 512?
It's a very small change and although there is an added part and it's
tiny and not easy to solder wires to, it's probably actually possible to
cut a few traces and add the new part with fine wire-wrap wire and glue
it all down.
I think the new part (LVC1G79) can even be soldered to the board pretty
much right where it is on the new board instead of dead-bug, because two
of the pins are VBUS & GND, and they are on opposite corners of the
package, and both are available on the pcb in the right spots already
just by scratching the soldermask pretty much right where the part goes
on the now board. Angled a little but hey whatever. So that not only
connects 2 of the 5 pins, it mounts the part as if there were a footprint.
Two more pins have short easy bodge wire runs to nearby exposed pins
with no need to cut any traces or anything. Those are /BLOCK and
BUS_A10. Pin 1 goes over to connector pin 16 and pin 2 goes over to U4
pin 14. Just add the wires to existing exposed legs, no cutting traces
or lifting legs.
That just leaves pin 4 A18, which needs a trace cut on the back side of
the board, and a wire run from pin 4 to sram pin 6. The trace to cut is
the one that ends with a via right in the D in NODE on the back side,
it's a thin trace that runs down towards the connector, and transitions
to a fat trace before going under the connector. Break the thin section,
do not break the fat section.
And actually since we're not soldering to a footprint, you can buy a
larger package version of the part so the lags are a easy to solder
wires to. It's available in SOT-23-5/SOT-753/SC-74A which should be dead
easy.
Ok well I guess I just did the thing I was asking if it was worth doing.
But, it's probably not much worse or maybe even easier to just
transplant all the parts from a built 256k to a new 512k board. That's
what I did. I didn't bother with the caps or resistors but all the chips
I desoldered with chipquick, cleaned the low-melt off with wick, and
soldered to the new board.
In one sense it's silly to spend that much time on parts that add up to
a couple bucks, your time is worth more, but on the other hand if you
didn't buy 100 of each part and you've built a few along the way
developing... it's hard to look at a board full of parts and just toss
it rather than scavenge the parts. The math does not justify it at all
since I'm not broke, plus the chipquick and kimwipes and flux-off isn't
free, but I just can not make myself not scavenge those parts!
My REX Classic is on revision 30 or so by now, and I have 3 or 4 rexs
that have had their chips transplanted like 10 times, and so far
everything has seemed to survive all that accumulated solder hot time
and ultrasonic cleaner time. Everything is still working anyway.
--
bkw
On 12/13/23 16:34, Brian Brindle wrote:
Haha - Glad you like it Joshua if I do happen to make more or improve on
this one I'll let you know. I don't exactly have ADD but what I do seem
to have is the inability to control what my current interests are and
recently it's been playing with CP/M on the M100, PX-8 and building up a
CP/M emulation environment on the TanPi. That was going great till I
managed to get my hands on one of the MiniNDPs Brian K White made and
now I'm all about his recent 512K upgrade. Never thought I'd get to play
with an NDP so this is exciting stuff.
I have a WP-2 and have tried to use the TanPi on it, but usually ended
up frustrated with the lack of needed keys. When doing unixy stuff
having pipes, curly braces, back ticks etc are handy. The M100 seems to
have everything I need, although you do have to know to hit shift GRPH -
to do a pipe and GRPH ( for { etc.
I like ROM-View 80 but for me it's not enough of a payoff to have to
reconfigure the local terminal settings to accommodate the new layout.
The way I use the TanPi is primarily for content creation and syncing. I
will write documents either with a real editor or just by typing cat >
file.txt and typing away with CTRL-C to stop. Then sync the files with
my local storage or the cloud when I have WiFi. If I need to do
something really heavy I'll use an external screen or my VNC session
with my phone.
A lot of times when I'm at home I will ssh into my TanPi from my desktop
and can drag/drop files over SSH, use the real keyboard and monitor for
stuff and it's quite handy.
It's a fun toy.
Brian
On Wed, Dec 13, 2023 at 1:29 PM Joshua O'Keefe > wrote:
> On Dec 13, 2023, at 6:22 AM, Brian Brindle mailto:bbrin...@gmail.com>> wrote:
> My whole setup is a total kludge / hack that I never expected to
use long term. I was just doing a POC and built the whole thing in
about 10 minutes with stuff I had laying around but here we are
almost five years later...
Brian, you may consider this rig a
Re: [M100] Question about TPDD/FB100
it's also very possible that i made a mistake when i initially reassembled the thing. it was very fiddly to get everything back together. i'll let you know if i find anything interesting. On Wed, Dec 13, 2023 at 02:36:18PM -0800, runrin wrote: > unfortunately format fails with the same error. i'll try tearing the > thing open later and see if i can find anything obviously wrong with it. > > here's what i got: > > % VERBOSE=9 ./pdd.sh format > get_tpdd_port() > Using port "/dev/ttyUSB0" > open_com() > set_stty() > speed 19200 baud; rows 0; columns 0; line = 0; > intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; > eol2 = ; swtch = ; start = ^Q; stop = ^S; > susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; > time = 1; > -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts > -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl > -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 > -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 > vt0 ff0 > -isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop > -echoprt echoctl echoke -flusho -extproc > do_cmd(format) > _init() > fonzie_smack() > tpdd_drain() > tpdd_check() > tpdd_write(4D 31 0D) > tpdd_drain() > tpdd_check() > pdd2_unk23() > ocmd_send_req(23) > calc_cksum(23 00):DC > ocmd_send_req: fmt="23" len="00" dat="" chk="DC" > tpdd_write(5A 5A 23 00 DC) > ocmd_read_ret(100) > ocmd_read_ret: reading 2 bytes (fmt & len) > tpdd_read(2 100) > tpdd_wait(100) > tpdd_check() > tpdd_check() > Detected TPDD1 > ocmd_format() > Formatting Disk, TPDD1 filesystem > : Are you sure? (y/N) y > ocmd_send_req(06) > calc_cksum(06 00):F9 > ocmd_send_req: fmt="06" len="00" dat="" chk="F9" > tpdd_write(5A 5A 06 00 F9) > ocmd_read_ret(105000 2) > ocmd_read_ret: reading 2 bytes (fmt & len) > tpdd_read(2 105000 2) > tpdd_wait(105000 2) > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > > tpdd_wait: 105000 2:2500 > tpdd_read: l=2 12 01 > ocmd_read_ret: reading 2 bytes (data & checksum) > tpdd_read(2) > tpdd_wait() > tpdd_check() > tpdd_wait: :0 > tpdd_read: l=2 80 6C > ocmd_read_ret: fmt=12 len=01 dat=(80) chk=6C > verify_checksum(12 01 80 6C) > calc_cksum(12 01 80):6C > verify_checksum: given:6C calc:6C > ocmd_check_err() > ocmd_check_err: ret_fmt=12 ret_len=01 ret_dat=(80) read_err="0" > ocmd_check_err: 80:Hardware Fault 0 > > format: Hardware Fault 0 > > On Wed, Dec 13, 2023 at 04:23:11PM -0500, Brian K. White wrote: > > Communication all looks good actually. Cabling and serial port are solid. > > The problem is only when it issues the initial dirent() as part of the > > directory listing process, and gets a hardware fault error code from the > > drive. > > > > The drive firmware tried to run the disk and read the media, and failed, and > > said so. > > > > It may possibly just be that the disk is not formatted. The disk needs to be > > formatted by the drive, it can not use the normal PC formatting the disk > > already has. > > > > So verify: > > * The drive has a good belt. > > * The disk is DD not HD, aka 720K not 1.4M, aka has only one hole in one > > corner. > > * The write-protect door in that one hole is closed (open=write-protect). > > * The disk contains no data you care about. > > > > Then in pdd.sh issue the "format" command. > > Wait approximately one solar flare cycle. > > > > Ok 100 seconds but feels like 11 years because there is no data on the wire > > all during that time and no way to monitor progress. Even in verbose mode > > the percent-done animation is just counting down the expected time which is > > known. And you can't do any better. You can not send any data to the drive > > during this time or it will just crash it. The client must just sit and wait > > for data from the drive, or abort if no data comes after some max possible > > time. > > > > Maybe your drive has the same problem my Purple Computing drive has. > > Everything works except actually accessing the media. > > So like, something wrong with the drive head or it's signal amplifier maybe? > > I have not figured out what's actually wrong with mine yet. That level of > > problem may be just a bit beyond me, figuring out how the head read circuit > > actaully works and where to probe with a scope and what to expect there etc. > > Though, I have a scope and haven't actually tried yet so who knows. > > > > -- > > bkw > > > > > > On 12/13/23 15:22, runrin wrote: > > > OK! I think there might be a problem with my PC cable. > > > > > > With a standard 25 pin to 9 pin adapter and a gender changer on my M100 > > > cable, I'm getting some output, but there may be some other
