Re: [M100] New zebra strips for M100 display ? any interest?
I would be interested in four pairs if this ever gets rolling. Best, CAM -- C.A. Magaret Sent from my newfangled mobile technogizmo. Please forgive any typos, inelegant brevity, or nonsensical auto-corrections. > On Jul 7, 2021, at 14:39, Jamie Nichol wrote: > > Peter, > > Looks like a pair of new zebra strips will cost $6 with usps shipping to > contiguous USA. > > Manufacturer is fujipoly. Better quality supplier. > > I’d love to sign you up for a dozen, once testing looks good. > > Anyone else interested at this price? > > —Jamie >
Re: [M100] A decent replacement for M100 "Feet"
bkw On Mon, Jul 12, 2021, 9:48 PM Brian Brindle wrote: > > > On Mon, Jul 12, 2021 at 5:34 PM Brian K. White > wrote: > >> >> >> master actually? or latest default branch which is not master but 0.4.1? >> I didn't have master marked as default currently because I thought I had >> made it worse, you know like the partly-broken point mid-way in a >> refactor, so I made the last-known at least basically-minimally-working >> version default. >> >> But if you're actually using the master branch that's great and I'll >> switch that to default. That is where I started porting Jim's main loop. >> > > I'm using the Master. I had a lot of issues with the current default. > Granted I didn't improve my situation by mucking with it, but I stumbled on > the Master, saw the changes you made and liked them so went with it. It's > been working pretty well since. > > Biggest thing I saw was the PDDuino would wander off looking for > >> > label information and not respond to drive commands. Like when trying >> to >> > load TS-DOS from the UR2 it would fail unless you could force the >> > PDDuino to get a disk label, IE: swap to TS-DOS rom, list a directory, >> > then it would happily go on to the load step. It is somewhat working >> now >> > so I took a break from it, although my M0 still doesn't work and I'm >> not >> > 100% sure why but I think it's the guy from SdFats fault.. >> >> I'd love to know the fix for that. I wrote a whole paragraph in the >> front page readme about it just as a bug description to be figured out >> sometime. >> > > I did a lot of debugging on this, both with a serial monitor and with the > debug options on the pdduino. I came to the conclusion that it had > something to do with dmeLabel not getting set. When watching the > interactions it looked like the UR2 just does a ZZ - ZZ DOS100.CO and > that's it. TS-DOS did a little dance that gave it the root dir first and > set dmeLabel. > That is strange. Remember, UR2 works with a real tpdd which has no such thing as a current directory label, and as well, the whole point of the UR2 stub on-demand loader is that you don't have TS-DOS installed, either ram or rom. Ken Pettit has a TS-DOS disassembly in his directory on club100 that we can consult too when it comes to nailing down a real mystery. Maybe it's something where IF the server says it supports directory extensions (by acknowledging one of the commands that should be unknown to a real tpdd), THEN the label must actually be supplied at various times, and I'm missing some. We had discussed here not too long ago the idea of having a tpdd server at least have an option to treat some filenames specially, like having DOS100.CO always work regardless of current directory. It sounds pretty sensible to me, but if the UR2 loader always cds to root first, then that means there is no point. That would also mean the root label is not free to be whatever I think it should be, but has to be whatever UR2 cds to or looks for (or else we hack UR2, or else we recognize UR2 requests and fake whatever makes it happy.) I don't like "ROOT" as the root dir label. I will not use it unless forced to by something like ur2 just requires it or something. Similarly for "PARENT". I always had the idea that there could be a whole raft of virtual files that don't actually exist but that could be used to issue commands or return data like RTC time etc, like /proc /sys etc. They could even be in their own virtual sub dir. The dir could even be invisible where it isn't listed in the root directory listing, but never the less works if you request the right dir and filenames. I like the idea that, at least for some things, you might be able go use them by just opening the "file" in TEXT. Or sched or addr for that matter. You could have a 2 MB address book for real, but a virtual addr.do that only sees a 5k window of it at any given time. I don't actually know what all the useful uses might be but it just seems obvious to provide the facility simply because you can, and maybe someone else comes up with functions that are made possible by using the facility. I mucked with this quite a bit but stupidly went down the route of trying > to make DOS100.CO found no matter what the current directory was but > regretted that after I started thinking it was short-sighted for other > things not DOS100.CO. I'll have some more time here soon to keep playing. > > >> >> So far, actually the lowly 32u4 feather board is actually my favorite. >> The teensy's have gobs more power obviously, but for this task the 32u4 >> does the job so the extra power doesn't matter until we start adding >> features beyond straight tpdd. Either feather is better than the teensy >> (until you start needing the horsepower) for the sake of: >> * asymmetrical pin headers for polarity enforcement, >> * built-in lipo manager >> * card detect switch, >> * ...which an interrupt can be assigned to >> * extra on-board led for the card slot >> >> I'm with you
Re: [M100] A decent replacement for M100 "Feet"
On Mon, Jul 12, 2021 at 5:34 PM Brian K. White wrote: > > > master actually? or latest default branch which is not master but 0.4.1? > I didn't have master marked as default currently because I thought I had > made it worse, you know like the partly-broken point mid-way in a > refactor, so I made the last-known at least basically-minimally-working > version default. > > But if you're actually using the master branch that's great and I'll > switch that to default. That is where I started porting Jim's main loop. > I'm using the Master. I had a lot of issues with the current default. Granted I didn't improve my situation by mucking with it, but I stumbled on the Master, saw the changes you made and liked them so went with it. It's been working pretty well since. Biggest thing I saw was the PDDuino would wander off looking for > > label information and not respond to drive commands. Like when trying to > > load TS-DOS from the UR2 it would fail unless you could force the > > PDDuino to get a disk label, IE: swap to TS-DOS rom, list a directory, > > then it would happily go on to the load step. It is somewhat working now > > so I took a break from it, although my M0 still doesn't work and I'm not > > 100% sure why but I think it's the guy from SdFats fault.. > > I'd love to know the fix for that. I wrote a whole paragraph in the > front page readme about it just as a bug description to be figured out > sometime. > I did a lot of debugging on this, both with a serial monitor and with the debug options on the pdduino. I came to the conclusion that it had something to do with dmeLabel not getting set. When watching the interactions it looked like the UR2 just does a ZZ - ZZ DOS100.CO and that's it. TS-DOS did a little dance that gave it the root dir first and set dmeLabel. I mucked with this quite a bit but stupidly went down the route of trying to make DOS100.CO found no matter what the current directory was but regretted that after I started thinking it was short-sighted for other things not DOS100.CO. I'll have some more time here soon to keep playing. > > So far, actually the lowly 32u4 feather board is actually my favorite. > The teensy's have gobs more power obviously, but for this task the 32u4 > does the job so the extra power doesn't matter until we start adding > features beyond straight tpdd. Either feather is better than the teensy > (until you start needing the horsepower) for the sake of: > * asymmetrical pin headers for polarity enforcement, > * built-in lipo manager > * card detect switch, > * ...which an interrupt can be assigned to > * extra on-board led for the card slot > > I'm with you on the 32u4's now. Very impressed with what they have and can > do. I hadn't really touched them much before. The form factor of all of > this is my favorite, the feather mount boards totally make it all work. > Great job on those. Brian
Re: [M100] A decent replacement for M100 "Feet"
On 7/12/2021 4:34 PM, Brian K. White wrote: On 7/12/21 7:23 AM, Brian Brindle wrote: I agree on the risk with the USB ports, you wouldn't typically design something like this. But I appreciate the out of the box thinking that got me past that. The current limiting etc can easily be done in the end device, and that's what I choose to do. In reality, only one person is likely ever going to use this thing and we are already plugging USB ports into DB9s so.. Brian did at least consider the M100 user group and instructed everyone to use plastic DB9s so I think that is sufficient. Jim - congrats on the new gig. Hope you find some time to play soon. I used both your code and Brian W's to get my PDDuino going. Found the re-org of the code very helpful in figuring things out and appreciated all the documentation. I was chasing a few bugs that it looks like you guys both sorted out, or moved, in the latest master branch. master actually? or latest default branch which is not master but 0.4.1? Maybe it's my master he's describing I didn't have master marked as default currently because I thought I had made it worse, you know like the partly-broken point mid-way in a refactor, so I made the last-known at least basically-minimally-working version default. But if you're actually using the master branch that's great and I'll switch that to default. That is where I started porting Jim's main loop. I didn't simply merge Jim's whole version because I don't know if I agree with all of it (mostly just in some details not in the essence), and I'd rather merge in a bunch of smaller more incremental changes that each express a specific job or idea, even if it means I have to do it manually, even if it means in the end I do end up in the same state as if I just merged the whole thing. If nothing else it makes me understand everything better. Since the code in master is stable, I think I can go back and try to split up. I think I tried once, and some of the mods are simple: Add in UNO defines:https://github.com/go4retro/PDDuino/commit/b1bea588ee80824be37d42a3b26005cd657ff035 Skip hidden files (I think you are I might disagree on this, but it could be made a compile time compile option):https://github.com/go4retro/PDDuino/commit/7a2d746b11e340e221ee85f62414fd5f86cca851 Text alignment cleanup:https://github.com/go4retro/PDDuino/commit/ab35a7d98772697b1a6150c644e296dd03d6728a Switch magic numbers with an enum for the commands:https://github.com/go4retro/PDDuino/commit/b009a60a9b1f73784905a287b4c35b0466eb53fa Switch reference returns to generic function: https://github.com/go4retro/PDDuino/commit/11e2fa3742f446692d20bcb931a3f52f24bf4a3a Magic number removals: (I think this is a smaller patch, but it looks like git just replaced the whole file.): https://github.com/go4retro/PDDuino/commit/11e2fa3742f446692d20bcb931a3f52f24bf4a3a But, then the ring buffer removal was just a huge patch, and I don't know there is a way to split it up into little pieces: https://github.com/go4retro/PDDuino/commit/3737026de5302702af9fda69d39303d92ed0b760 Jim
Re: [M100] A decent replacement for M100 "Feet"
On 7/11/21 8:13 AM, Brian Brindle wrote: Then you go and pop a USB jack on the BC port I missed my que, what I meant to say was "THERE ARE NO RULES. ELECTRONICS IS THE PURGE." -- bkw
Re: [M100] A decent replacement for M100 "Feet"
On 7/12/21 7:23 AM, Brian Brindle wrote: I agree on the risk with the USB ports, you wouldn't typically design something like this. But I appreciate the out of the box thinking that got me past that. The current limiting etc can easily be done in the end device, and that's what I choose to do. In reality, only one person is likely ever going to use this thing and we are already plugging USB ports into DB9s so.. Brian did at least consider the M100 user group and instructed everyone to use plastic DB9s so I think that is sufficient. Jim - congrats on the new gig. Hope you find some time to play soon. I used both your code and Brian W's to get my PDDuino going. Found the re-org of the code very helpful in figuring things out and appreciated all the documentation. I was chasing a few bugs that it looks like you guys both sorted out, or moved, in the latest master branch. master actually? or latest default branch which is not master but 0.4.1? I didn't have master marked as default currently because I thought I had made it worse, you know like the partly-broken point mid-way in a refactor, so I made the last-known at least basically-minimally-working version default. But if you're actually using the master branch that's great and I'll switch that to default. That is where I started porting Jim's main loop. I didn't simply merge Jim's whole version because I don't know if I agree with all of it (mostly just in some details not in the essence), and I'd rather merge in a bunch of smaller more incremental changes that each express a specific job or idea, even if it means I have to do it manually, even if it means in the end I do end up in the same state as if I just merged the whole thing. If nothing else it makes me understand everything better. Biggest thing I saw was the PDDuino would wander off looking for label information and not respond to drive commands. Like when trying to load TS-DOS from the UR2 it would fail unless you could force the PDDuino to get a disk label, IE: swap to TS-DOS rom, list a directory, then it would happily go on to the load step. It is somewhat working now so I took a break from it, although my M0 still doesn't work and I'm not 100% sure why but I think it's the guy from SdFats fault.. I'd love to know the fix for that. I wrote a whole paragraph in the front page readme about it just as a bug description to be figured out sometime. Bill Greiman says the M0 problem is Adafruit's fault and I think I agree with him. You can build it for the Adafruit M0 board without the Adafruit board support libraries just generic M0 support. Based on what both Bill and Adafruit said in different support forums, I thought I had a working fix that addressed the Adafruit libs wrongness while otherwise still using them, but I think it turned out not to fully fix it, so I was probably going to give up on the Adafruit libs and just change the code and the directions to specifically avoid building with the Adafruit board support files. So far, actually the lowly 32u4 feather board is actually my favorite. The teensy's have gobs more power obviously, but for this task the 32u4 does the job so the extra power doesn't matter until we start adding features beyond straight tpdd. Either feather is better than the teensy (until you start needing the horsepower) for the sake of: * asymmetrical pin headers for polarity enforcement, * built-in lipo manager * card detect switch, * ...which an interrupt can be assigned to * extra on-board led for the card slot And between the two feather boards the 32u4 feather works more reliably than the M0 version at least until we fix it, like maybe with different board support libs or some sort of surgical override within the code like I tried to do with the SPI clock parameter. -- bkw
Re: [M100] Super ROM for NEC
I've disassembled and taken a quick look. it is quite different than "MO" would have done, but the trampoline is clear. (using DASMX140, which seems to be a really good disassembler!) On Mon, Jul 12, 2021 at 1:30 PM John R. Hogerhuis wrote: > I think it very doable. It comes down to the completeness and quality of > the disassembly and identifying all jumps into the BASIC ROM including > indirect or computed jumps and mapping them from M100 to NEC. > > The option ROM skeleton and trampoline stuff is probably the best > understood and easiest part. > > Definitely worth it given SuperROM being the best ROM :-) > > -- John. >
Re: [M100] Super ROM for NEC
On Mon, Jul 12, 2021 at 11:02 AM Brian K. White wrote: > On 7/12/21 1:30 PM, John R. Hogerhuis wrote: > > > Definitely worth it given SuperROM being the best ROM :-) > > > > -- John. > > > I wish you wouldn't be so coy and cryptic about your stance on what the > best option rom ever released was. > > -- > bkw > Oops.. my opinion escaped again -- John.
Re: [M100] Super ROM for NEC
On 7/12/21 1:30 PM, John R. Hogerhuis wrote: I think it very doable. It comes down to the completeness and quality of the disassembly and identifying all jumps into the BASIC ROM including indirect or computed jumps and mapping them from M100 to NEC. The option ROM skeleton and trampoline stuff is probably the best understood and easiest part. Definitely worth it given SuperROM being the best ROM :-) -- John. I wish you wouldn't be so coy and cryptic about your stance on what the best option rom ever released was. -- bkw
Re: [M100] Super ROM for NEC
I think it very doable. It comes down to the completeness and quality of the disassembly and identifying all jumps into the BASIC ROM including indirect or computed jumps and mapping them from M100 to NEC. The option ROM skeleton and trampoline stuff is probably the best understood and easiest part. Definitely worth it given SuperROM being the best ROM :-) -- John.
Re: [M100] Super ROM for NEC
I can only say that if you think you can do it, then I think you can do it. It certainly would be cool. -- bkw On 7/12/21 8:30 AM, Stephen Adolph wrote: Noting that SuperROM has never been found (or never released?) for NEC, it seems to me given what I know about making applications run on both platforms, that it should be very straightforward to translate the M100 SuperROM into an NEC variant. After all, the NEC and M100 are so similar. Does anyone have any thoughts on this? Process could be: - Disassemble - find the trampoline, and adjust for NEC memory map - look for "trampoline" calls to the main ROM, and convert to NEC addresses - look for upper RAM addresses, and convert to NEC addresses ---> this could be a bit tricky I admit, because it may not always be apparent that a register pair value is being used as an upper RAM pointer - adjust the hardware interrupt if needed cheers Steve
Re: [M100] M100 as Terminal to Raspberry Pi
Brian your response was much appreciated. I am still having a problem with my Pi. I got it working at home but then I took it to the office and plugged it in but I thought I would be able to change the wifi from the terminal connection. No joy. I guess I need to change the wpa supplicant file at home. When I got to the office, the M100 can log into the Pi but I get a bash error with every command, even something simple like "ls". On Mon, Jul 12, 2021 at 9:43 AM Brian Brindle wrote: > Hi Bill, > > I totally missed that you actually had your console working, sorry the > systemd changes make me blind with rage. > > If you are primarily using BBSes X-modem works pretty well, if you have an > X-Modem capable term on your M100. You can also send files to/from the M100 > via the Linux command line with the sx (send x-modem) command. > > Brian > > > On Mon, Jul 12, 2021 at 8:15 AM Bill Miranda > wrote: > >> Thank you so much! Embarrassingly I discovered my problem was that that I >> had to go into raspi-config and designate my country so the WiFi would >> work. The packages I was trying to install on my raspberry pi weren’t >> installing because no internet. Once I got that sorted and made a couple >> changes to configure I was good to go and successfully contacted a BBS with >> the setup. Now I need to sort out out to exchange files. Thanks again for >> your response. >> >> Regards, >> Bill Miranda >> bill.mira...@gmail.com >> >> On Jul 12, 2021, at 6:18 AM, Brian Brindle wrote: >> >> >> HI Bill, >> >> The divergence from systemd is frustrating but at last current versions >> of Raspian still have ifconfig... >> >> I'm using Raspian 10 here are my quick and dirty hints: >> >> Get your termcap sorted: >> https://zork.net/~octal/mod100.xhtml >> >> You will note that termcap doesn't exist like it should though, so save >> the cap to a file and install it like so: >> >> tic >> >> I assume you are going to to the easy route and use a USB to serial >> adapter. You can use the onboard UART with some level conversion as I have >> done, but you have to get creative with the hardware. Check out the photos >> of my M100 hooked to my pi zero here: http://niedobry.com/mod100/tanpi/ >> >> Copy the template file */lib/systemd/system/**serial-getty@.service* to* >> /etc/systemd/system/serial-getty@ttyUSB0.service*(Provided you are >> using ttyUSB0) >> >> In [Service] modify the ExecStart line to say the following: (Adjust your >> baud as you like.) >> ExecStart=-/sbin/agetty -o '-p -- \\u' 19200 %I trs100 >> >> Issue *systemctl enable serial-getty@ttyUSB0.service* >> >> Do a ps -ax | grep getty and you should now see a getty process running >> on the USB port. >> >> Connect your Model-T with a null modem cable to the serial port, set your >> TERM to STAT 98N1E and you should be good to go. Lots and lots of >> customization needed for it to be useful, I'm working on getting my notes >> together on this and hope to have it somewhere for reference soon. >> >> Hope this helps, >> Brian >> >> >> On Sun, Jul 11, 2021 at 11:09 PM Bill Miranda >> wrote: >> >>> Can anyone point me to current instructions on how to configure a >>> Raspberry Pi so that I can connect my M100 as a serial console? I found >>> numerous websites with instructions for older versions of Raspian which >>> were pre-systemd. I was able to get the M100 to connect to the Pi after a >>> lot of experimenting but I once I login I can’t get anything to work. >>> >>> Regards, >>> Bill Miranda >>> bill.mira...@gmail.com >>> >>
Re: [M100] M100 as Terminal to Raspberry Pi
Hi Bill, I totally missed that you actually had your console working, sorry the systemd changes make me blind with rage. If you are primarily using BBSes X-modem works pretty well, if you have an X-Modem capable term on your M100. You can also send files to/from the M100 via the Linux command line with the sx (send x-modem) command. Brian On Mon, Jul 12, 2021 at 8:15 AM Bill Miranda wrote: > Thank you so much! Embarrassingly I discovered my problem was that that I > had to go into raspi-config and designate my country so the WiFi would > work. The packages I was trying to install on my raspberry pi weren’t > installing because no internet. Once I got that sorted and made a couple > changes to configure I was good to go and successfully contacted a BBS with > the setup. Now I need to sort out out to exchange files. Thanks again for > your response. > > Regards, > Bill Miranda > bill.mira...@gmail.com > > On Jul 12, 2021, at 6:18 AM, Brian Brindle wrote: > > > HI Bill, > > The divergence from systemd is frustrating but at last current versions of > Raspian still have ifconfig... > > I'm using Raspian 10 here are my quick and dirty hints: > > Get your termcap sorted: > https://zork.net/~octal/mod100.xhtml > > You will note that termcap doesn't exist like it should though, so save > the cap to a file and install it like so: > > tic > > I assume you are going to to the easy route and use a USB to serial > adapter. You can use the onboard UART with some level conversion as I have > done, but you have to get creative with the hardware. Check out the photos > of my M100 hooked to my pi zero here: http://niedobry.com/mod100/tanpi/ > > Copy the template file */lib/systemd/system/**serial-getty@.service* to* > /etc/systemd/system/serial-getty@ttyUSB0.service*(Provided you are > using ttyUSB0) > > In [Service] modify the ExecStart line to say the following: (Adjust your > baud as you like.) > ExecStart=-/sbin/agetty -o '-p -- \\u' 19200 %I trs100 > > Issue *systemctl enable serial-getty@ttyUSB0.service* > > Do a ps -ax | grep getty and you should now see a getty process running > on the USB port. > > Connect your Model-T with a null modem cable to the serial port, set your > TERM to STAT 98N1E and you should be good to go. Lots and lots of > customization needed for it to be useful, I'm working on getting my notes > together on this and hope to have it somewhere for reference soon. > > Hope this helps, > Brian > > > On Sun, Jul 11, 2021 at 11:09 PM Bill Miranda > wrote: > >> Can anyone point me to current instructions on how to configure a >> Raspberry Pi so that I can connect my M100 as a serial console? I found >> numerous websites with instructions for older versions of Raspian which >> were pre-systemd. I was able to get the M100 to connect to the Pi after a >> lot of experimenting but I once I login I can’t get anything to work. >> >> Regards, >> Bill Miranda >> bill.mira...@gmail.com >> >
Re: [M100] Super ROM for NEC
Interesting! Was discussing the availability of a SuperRom image for NEC just this past weekend on Discord with @Fezzler and I was wondering how difficult it would be to convert. Your description of the process is somewhat 'greek' to me so I'm guessing that I'd need to level up a bit to be able to contribute any useful assistance - though I'd be happy to help, if I can :) --Brad On Mon, Jul 12, 2021 at 6:30 AM Stephen Adolph wrote: > Noting that SuperROM has never been found (or never released?) for NEC, it > seems to me given what I know about making applications run on both > platforms, that it should be very straightforward to translate the M100 > SuperROM into an NEC variant. After all, the NEC and M100 are so similar. > > Does anyone have any thoughts on this? > > Process could be: > - Disassemble > - find the trampoline, and adjust for NEC memory map > - look for "trampoline" calls to the main ROM, and convert to NEC addresses > - look for upper RAM addresses, and convert to NEC addresses > ---> this could be a bit tricky I admit, because it may not always be > apparent that a register pair value is being used as an upper RAM pointer > - adjust the hardware interrupt if needed > > > cheers > Steve > > > > -- -- Brad Grier
Re: [M100] A decent replacement for M100 "Feet"
I agree on the risk with the USB ports, you wouldn't typically design something like this. But I appreciate the out of the box thinking that got me past that. The current limiting etc can easily be done in the end device, and that's what I choose to do. In reality, only one person is likely ever going to use this thing and we are already plugging USB ports into DB9s so.. Brian did at least consider the M100 user group and instructed everyone to use plastic DB9s so I think that is sufficient. Jim - congrats on the new gig. Hope you find some time to play soon. I used both your code and Brian W's to get my PDDuino going. Found the re-org of the code very helpful in figuring things out and appreciated all the documentation. I was chasing a few bugs that it looks like you guys both sorted out, or moved, in the latest master branch. Biggest thing I saw was the PDDuino would wander off looking for label information and not respond to drive commands. Like when trying to load TS-DOS from the UR2 it would fail unless you could force the PDDuino to get a disk label, IE: swap to TS-DOS rom, list a directory, then it would happily go on to the load step. It is somewhat working now so I took a break from it, although my M0 still doesn't work and I'm not 100% sure why but I think it's the guy from SdFats fault.. Brian On Mon, Jul 12, 2021 at 4:04 AM Scott McDonnell wrote: > “That IS a bit risky. Ideally there should be some sort of current limit > to avoid drawing more than 50 or 60 ma. But I don't know how to do that in > a small practical way.” > > > > Wouldn’t a 82 (or 100 for 50ma) ohm resistor in series do the trick? > > > > Scott M. > > > > *From: *Brian White > *Sent: *Sunday, July 11, 2021 2:33 PM > *To: *m...@bitchin100.com > *Subject: *Re: [M100] A decent replacement for M100 "Feet" > > > > > > > > On Sun, Jul 11, 2021, 8:14 AM Brian Brindle wrote: > > > I didn't think anyone else was actually trying them out. > > > > BKW - I just assumed the MountT was wildly popular based on how simple and > awesome it was. I'm genuinely jealous that I didn't think of it.. I'll be > honest, there is something in my training/experience that was like DO NOT > HOOK THINGS UP WITHOUT BUFFERING/PROTECTION/ETC! > > > > You are not wrong of course. But little diy toys like this have to be > compromises to make them doable. > > > > > > Then you go and pop a USB jack on the BC port and the world didn't end and > it's worked great. > > > > > > That IS a bit risky. Ideally there should be some sort of current limit to > avoid drawing more than 50 or 60 ma. But I don't know how to do that in a > small practical way. > > > > At least I made sure the BOM has a plastic plug and stressed in the docs > why this is important even though that plug is uncommon and expensive while > normal metal shell plugs are dirt cheap. > > > > (the metal shell of normal de9f shorts the power and ground pins, you > should never use a metal shell de9f in the bcr port) > > > > > > > > > > > > I'm a daily carrier of my Model-T, I write a lot but 90% of what I do with > it is useless tinkering to make it do stuff similar to what my phone and > readily available laptop can do. In fact, in most instances my laptop is > hooked up and running to debug the thing that isn't working right on the > M100. That being said, the PDDuino provided weeks of endless debugging > entertainment. > > > > Yes that does still need a lot of debugging sorry ;) > > > > Jim Brain did some work on it and the idea didn't work out, but there is a > lot he did that are good ideas that I'd been meaning to cherry pick. > Actually I already did some of that. > > > > It's still not quite all the way there yet. It still doesn't work with > other clients like WP-2. I think it's still limited to TS-DOS. > > > > My problem last time I was working on it was I think enabling debugging is > screwing it up. Things work without debugging, and break with debugging, > well great now what? haha > > > > > > I checked out your latest code for it recently with the new main loop and > it works very well now and is my "daily-driver" for storage. > > > > I very much respect all of you guys who can not only do this stuff but > document it where others can play along. I seem to fail miserably at that. > I do have a current project in the works that I hope to change that with.. > We will see. > > > > After 20+ years of using M100s I stumbled on an M102 cheap and snatched it > up. I worked at Radio Shack back in the 90s as a teen and remember lusting > after the discontinued M102 but hadn't touched one since then. I much > prefer the size/weight and keyboard to my M100. I also like the system bus > being accessible like it is so built a little jig for my project. I > followed your example and added a USB port to it to power my PDDuino, once > I get a real board made for it I'll get the right length USB cord and it > will look as awesome as the M100 does with the MountT, but here it is: > > > >
Re: [M100] M100 as Terminal to Raspberry Pi
HI Bill, The divergence from systemd is frustrating but at last current versions of Raspian still have ifconfig... I'm using Raspian 10 here are my quick and dirty hints: Get your termcap sorted: https://zork.net/~octal/mod100.xhtml You will note that termcap doesn't exist like it should though, so save the cap to a file and install it like so: tic I assume you are going to to the easy route and use a USB to serial adapter. You can use the onboard UART with some level conversion as I have done, but you have to get creative with the hardware. Check out the photos of my M100 hooked to my pi zero here: http://niedobry.com/mod100/tanpi/ Copy the template file */lib/systemd/system/**serial-getty@.service* to* /etc/systemd/system/serial-getty@ttyUSB0.service*(Provided you are using ttyUSB0) In [Service] modify the ExecStart line to say the following: (Adjust your baud as you like.) ExecStart=-/sbin/agetty -o '-p -- \\u' 19200 %I trs100 Issue *systemctl enable serial-getty@ttyUSB0.service* Do a ps -ax | grep getty and you should now see a getty process running on the USB port. Connect your Model-T with a null modem cable to the serial port, set your TERM to STAT 98N1E and you should be good to go. Lots and lots of customization needed for it to be useful, I'm working on getting my notes together on this and hope to have it somewhere for reference soon. Hope this helps, Brian On Sun, Jul 11, 2021 at 11:09 PM Bill Miranda wrote: > Can anyone point me to current instructions on how to configure a > Raspberry Pi so that I can connect my M100 as a serial console? I found > numerous websites with instructions for older versions of Raspian which > were pre-systemd. I was able to get the M100 to connect to the Pi after a > lot of experimenting but I once I login I can’t get anything to work. > > Regards, > Bill Miranda > bill.mira...@gmail.com >
Re: [M100] A decent replacement for M100 "Feet"
“That IS a bit risky. Ideally there should be some sort of current limit to avoid drawing more than 50 or 60 ma. But I don't know how to do that in a small practical way.” Wouldn’t a 82 (or 100 for 50ma) ohm resistor in series do the trick? Scott M. From: Brian White Sent: Sunday, July 11, 2021 2:33 PM To: m...@bitchin100.com Subject: Re: [M100] A decent replacement for M100 "Feet" On Sun, Jul 11, 2021, 8:14 AM Brian Brindle wrote: > I didn't think anyone else was actually trying them out. BKW - I just assumed the MountT was wildly popular based on how simple and awesome it was. I'm genuinely jealous that I didn't think of it.. I'll be honest, there is something in my training/experience that was like DO NOT HOOK THINGS UP WITHOUT BUFFERING/PROTECTION/ETC! You are not wrong of course. But little diy toys like this have to be compromises to make them doable. Then you go and pop a USB jack on the BC port and the world didn't end and it's worked great. That IS a bit risky. Ideally there should be some sort of current limit to avoid drawing more than 50 or 60 ma. But I don't know how to do that in a small practical way. At least I made sure the BOM has a plastic plug and stressed in the docs why this is important even though that plug is uncommon and expensive while normal metal shell plugs are dirt cheap. (the metal shell of normal de9f shorts the power and ground pins, you should never use a metal shell de9f in the bcr port) I'm a daily carrier of my Model-T, I write a lot but 90% of what I do with it is useless tinkering to make it do stuff similar to what my phone and readily available laptop can do. In fact, in most instances my laptop is hooked up and running to debug the thing that isn't working right on the M100. That being said, the PDDuino provided weeks of endless debugging entertainment. Yes that does still need a lot of debugging sorry ;) Jim Brain did some work on it and the idea didn't work out, but there is a lot he did that are good ideas that I'd been meaning to cherry pick. Actually I already did some of that. It's still not quite all the way there yet. It still doesn't work with other clients like WP-2. I think it's still limited to TS-DOS. My problem last time I was working on it was I think enabling debugging is screwing it up. Things work without debugging, and break with debugging, well great now what? haha I checked out your latest code for it recently with the new main loop and it works very well now and is my "daily-driver" for storage. I very much respect all of you guys who can not only do this stuff but document it where others can play along. I seem to fail miserably at that. I do have a current project in the works that I hope to change that with.. We will see. After 20+ years of using M100s I stumbled on an M102 cheap and snatched it up. I worked at Radio Shack back in the 90s as a teen and remember lusting after the discontinued M102 but hadn't touched one since then. I much prefer the size/weight and keyboard to my M100. I also like the system bus being accessible like it is so built a little jig for my project. I followed your example and added a USB port to it to power my PDDuino, once I get a real board made for it I'll get the right length USB cord and it will look as awesome as the M100 does with the MountT, but here it is: http://niedobry.com/mod100/images/bus_jig.jpg Brian Nice. Yeah The upside down ports on 102 are annoying. IOlivetti is the same. For those I just decided to rely on right-angle usb cables rather than multiple versions of the pcb. Half the point was to remove all the ways to get things wrong like with the wrong serial wiring etc. Though, at least for the Feather boards, since they have asymetrical pins, you could safely have two sets of holes on the same board. For teensy boards, you can already plug them in wrong now, but at least with only a single set of holes, you can have a single silkscreen showing the single correct way. For that bus board, if you use a vertical usb port, it can be moved below or above the system bus so that it doesn't block the printer port, and you can include a pass through pin header so the system bus is still usable for DVI. Though the port would stick out then. Maybe a horizontal port could still be used just in some other position. Well thank you for the kind words. I think everything I've done so far has actually been pretty low hanging fruit. I could not have designed REX for instance. And I have yet to manage even a hello world in machine language. I didn't write either dlplus or pdduino just picked them up and did a little work on them, etc. On Sat, Jul 10, 2021 at 4:08 AM Brian K. White wrote: On 7/9/21 4:21 PM, Peter Vollan wrote: > You'll have to explain what that is past the printer and serial ports. https://github.com/bkw777/MounT https://github.com/bkw777/BCR_Breakout https://github.com/bkw777/PDDuino I didn't think
