Re: [M100] Low battery , crashes wipe the memory of both M102/M200
I’d like to eliminate the possibility that my ram has problems ; may it be on my m200 or my m102 ; is there a small basic or ml program somewhere that would to a meaningful test ( I could probably draft a simple one but it would probably not be very thorough ) All in all my m102 is much more stable than my m200 so if there is a ram problem behind that ; it’s more on my m200 . I’d like to be sure once and for all > > > > >
Re: [M100] Low battery , crashes wipe the memory of both M102/M200
Thanks to all, I have a lot of things to investigate now. Jeff : indeed , I've never been able to reproduce the problem "on demand", but each time I remember crashing, I was doing serial communication or "saving files", so more than likely using TSDOS. So that's one area I'm gonna investigate. If I could reproduce those crashes with a TSDOS from a bootstrap (or anything else than from my REX# ROMs) that would already rule out a problem with REX. I however do remember the last crash, on my M200, was while hitting F2 (save) in TEXT, saving to... RAM. But, I had a serial device connected. But most crashes occured while doing serial - so inside TSDOS for sure. Alex ; that's very interesting too. My M200 is eating a suspiciously high amount of quality batteries for a device I'm using 30 minutes once in a while, and I think I often ear it click for no reason. I'm gonna investigate this as well. I was a bit ashamed to email about my problem but I'm happy I did. Everyone seems to imply TSDOS is not something to be trusted (to put it mildly :) )
Re: [M100] Low battery , crashes wipe the memory of both M102/M200
I'm really not convinced my problem is REX related, at least not yet Is there a process, a type of crash, or something known to basically crash the Model T and wipe it's RAM (and reset the clock !) ? All of that with a perfectly working backup ram (I can replace the batteries no problem) It's clearly the crash that wipes the ram/resets the thing, including the clock ? Is that a type of crash other people have seen ? Or am I cursed ? It's really the software is doing ctrl-break-power for me. It erases the machine WITH a perfectly working battery. And I believe this mostly happens when doing save operations,or anything involving serial - but it's super difficult to reproduce. It's mostly random. Call to the gurus :)
[M100] Low battery , crashes wipe the memory of both M102/M200
Hello, While trying to help Stephen testing new REX software, I've been investigating crashes of both my M102 and M200 (unrelated to REX) It seems that when using batteries that are "bit low" (but the red light does not turn on), together with anything using the serial port (transfers, TPDD,etc) again the light does not turn on, but I have system crashes that wipe the memory (basically equivalent to CTRL-BREAK-RESET) My systems comes back empty, date in 1900, you know the drill. Am I alone ? Is this indeed related to using serial, or maybe just to low battery ? Why doesn't the backup battery protect my work (they are brand new) ? What can I do to avoid those "memory wiping crashes" ? Could it be related to the fact both systems have a REX# ? (I doubt it - but hey, I also doubt these things wiped their memory twice a day back in the day) It's super frustrating because each time they occur I loose a bit of faith in my ModelT's, and you don't want that. If I could at least investigate a possible cause, that would help me.
Re: [M100] Model 100 BOM
This is in the technical manuals As far as international revisions ; it’s mostly about unpopulated zones Daniel L mailto:m...@scifidan.com)> 3 févr. 2023, 07:54:10 wrote: > Has anyone gone through the trouble of listing a BOM for a M100? You know, list of caps, resistors, chips, etc. For all revisions? > > How about 102 and 200? > > Daniel
Re: [M100] Backlight
The problem with such experimentation is to find a source of cheap enough m200 to tinker with … As much as I would like to do plenty of experiments ; I’m often stopped by the rarity of the devices ; or their price . More and more I’m limiting myself to repairs. Also some consider “retro mod” to be an abomination, so there is that too . Sometimes I read on forums people saying have a stack of this and that ; these are the ones who should be starting such experiments if they have access to heaps of retro hardware. Daniel L mailto:m...@scifidan.com)> 1 févr. 2023, 22:12:56 wrote: > > Has anyone explored a backlight solution for the 200? i'm going to go through the archive to see.
Re: [M100] R2.2 update for REX# and REXCPM
As I'm the one who started the date debate :) let me clarify what my feedback to Steve was In the context of my M200, there are multiple things that are confusing with dates, First of I consider that the system time, the one reported by print DATE$ , should define the date format, otherwise you end up with multiple date formats. As such, REX uses a different format than the system one (on my system, idk about everyone else's) I fully realize rex is probably written in machine language, that nobody asks for internationalisation or user settings, all my feedback was is that it's using a different date format than the system here, which is confusing ( can you tell me what the date is when system date is 21/12/22 and REX date 222112 ? ) You end up with not only one but two ambiguous date formats. I also remember an hidden part of REX (I think info on file in the tsdos part ?) uses yet another format, but I can't replicate this this morning as my tpdd is buried in a box. More than that, and this is new feedback, when saving a new RAM image or overwriting one, REX does not update the DAY of the date, only the month and the year. I've reproduced that today. I realize that out of context, this "date format" is a small problem, REX is now used internationally, and there are basically two Model T platforms (EU and US). For my M102 I switched the ROM to the US one. Quite frankly - this creates more problem than it solves. But it makes REX work. For my M200, with the help of Steve, I was able to keep my EU ROM and have REX working no problem, which is great for the international users. In short, without interfering with anyone else's REX :) if it would be possible that REX displays it's file dates then same way the system does, that'd be great :) Le 2023-01-31 08:32, jonathan.y...@telia.com a écrit : > > For what it's worth, I also like year month day dates, in part because I can easily sort them. ISO 8601 specifies year, month, date, but it looks like the years are 4 digits >
Re: [M100] Fixing a CCR 82 the proper way
Thanks Birt, I'm actually one of your subscribers :) , but in this case I watch youtube mostly on my smart tv, and it cuts the titles of the videos after 6 or 7 words, actually I think the iphone app does that too ; and so because of the title I did not realize this particular video was about ccr 82 - I must have missed it. I'll have a look. I think my belts were initially too tight when I put them in, but now - like only 1 year later - they are way too loose. Which means those cheap "assorted belts" out of Amazon are a heap of cr$$ - which probably isn't a surprise to anyone. It's not an easy device to disassemble iirc, so I'd rather do it once and for all now, with the super proper belts. Le 2023-01-14 21:45, bir...@soigeneris.com a écrit : > > > > I just made a video about the CCR-82. Link below. The belt dimensions are in the video description. In the Links section of the description are links to the company who makes the belts and the distributor I bought them from. A very unscientific specification is ‘just tight enough to do the job’. Since very little power is being transmitted little tension is needed. Belts should not be tight. This puts too much tension on the pulleys and wears things out prematurely. > > The quality of the belt is important too. I have shied away from big sets of random belts to buying belts of known length and quality. That way they should last for the rest of my lifetime at least. > > > > > > > > While I got this deck mechanically working the amplifier IC was bad. I did get a new chip but have not installed it yet. > > > > > > > > https://youtu.be/aqW6cF-4btI > > Jeff Birt > > > > > > > > > From: M100 On Behalf Of Cedric Amand > Sent: Saturday, January 14, 2023 2:30 PM > To: m...@bitchin100.com > Subject: [M100] Fixing a CCR 82 the proper way > > > > > > > > > > Hello everyone, > > > > > > > > > > > > Hi have a CCR-82 that kinda "works" but I know it's absolutely not working well. > > > > > > I initially changed the belts with a set of assorted belts out of amazon, again this "kinda works", but they quickly lost their tension, > > > > > > The tape goes way too slow. > > > > > > I ordered a 3Khz test cassette, but before using it I guess I have to be confident in my new belts. > > > > > > What would be real, actual, best belts for the ccr82 ? Exact dimensions seem to be a mystery. > > > > > > What should be the belt "tension" (tight, super tight, loose ?) > > > > > > > > > > > > The technical manual has a tuning procedure, which i'll try to follow for the parts that don't require exotic equipments like small dynamometers, but if anyone has experiences to share about rejuvenating a CCR82 (or I guess 81) that would be much appreciated > > > > > > > > > > > > thanks ! > > > >
[M100] Fixing a CCR 82 the proper way
Hello everyone, Hi have a CCR-82 that kinda "works" but I know it's absolutely not working well. I initially changed the belts with a set of assorted belts out of amazon, again this "kinda works", but they quickly lost their tension, The tape goes way too slow. I ordered a 3Khz test cassette, but before using it I guess I have to be confident in my new belts. What would be real, actual, best belts for the ccr82 ? Exact dimensions seem to be a mystery. What should be the belt "tension" (tight, super tight, loose ?) The technical manual has a tuning procedure, which i'll try to follow for the parts that don't require exotic equipments like small dynamometers, but if anyone has experiences to share about rejuvenating a CCR82 (or I guess 81) that would be much appreciated thanks !
Re: [M100] Rex#..TPDD compatibility
I wish to add that the patched version you sent me (with enlarged delays) worked on my TPDD1 Was this never merged with the "main" software ? Le 2023-01-14 16:30, Stephen Adolph a écrit : > > > Here is the current status of REX# (and REXCPM) interworking. > > Better than I thought! > > > >
Re: [M100] Romulus Chess for T200 (REX# RAM images)
Superb ! Thanks a lot, Could you also share - if you've got it - the WAV that one could record on a cassette to "re create" romulus chess as it was initially shipped (on a cassette) ? Le 2023-01-07 16:06, Stephen Adolph a écrit : > > > Hello all you T200 REX# owners! > > > > Attached is a couple of RAM images that contain the ROMULUS Chess program! > >
[M100] M200 dim display
I'm trying to avoid blindly recapping my vintage computers, but I feel like the display of my M200 is dim, and only gets readable nearly at max contrast. Are there specific caps to replace (for maybe a dc-dc converter for the display) that are known to make the LCD better ? Or maybe other tips ? PS: I know I'm sending this as html and I apologize. The fact is this is the only supported format in Synology Mailplus.
Re: [M100] Model 200 issues with Serial Wi-Fi Adapter
I'm super interested in those serial problems, but I can't fully grasp John's phrase below, would you please clarify and elaborate a bit ? > 3 wire is all the model 100 / 200 actually uses unless you're using HTERM > or you like the godlike simplicity of the cable check lockup, or you cannot disable the cable check in software. I often have lockups on my M200, I'm also under the impression (but I'm no expert yet) that in some way it's serial (in this case null modem) implementation niside TERM differs from the one of the M102. If I do a direct null modem (full cable) between a M102 and a M200, with TERM, the M200 will systematically lockup when the M102 hangs up ( EXIT/F8 ) whereas the reverse is not true. This with both ends using (or supposed to use) hardware handshake (and xon/xoff disabled) This is pure observation and might be specific to my setup, of course. However if you could please elaborate a bit about how the M10x/M200 uses the serial lines, that would be much appreciated I "think" from my hours of fiddling that null modem serial on the M10x/M200 only works reliably with xon/xoff and the hardware only handshake (at least in TERM) is flaky on the receiving end. I have yet to try HTERM. (It's for sure on my todo)
Re: [M100] Help with simple image on M100 screen?
I remember from my "demoscene era times" that bmp decoding is actually quite simple. It might be feasible to decode a BMP in plain basic on a T100/T200 imho. Le 2022-12-15 10:12, VANDEN BOSSCHE JAN a écrit : > > > > It might be difficult to code, but would a conversion to BMP not be possible? Considering the never-changing nature of the Model T's screen (240x64, monochrome) it shouldn't take too much place. Even if .BMP is a wastefull standard, it would give an easy way to interchange screendumps and logos to and from the Model T. > > > > > > >
Re: [M100] Help with simple image on M100 screen?
Can you share this code Ken ? Also where to get information about asciipixels ? Le 2022-12-14 03:13, Ken Pettit a écrit : > > The code I have is a BASIC only implementation that loads a small ML program into ALTLCD and then draws a graphic from BASIC Strings. It is not as advanced as asciipixels in the following ways: > > 1. Asciipixels can draw an image at any X,Y location. Apraw can only draw at x*8, y*8 locations. > >
Re: [M100] Better TELCOM program / ROM
Thanks, I'm glad to see I'm not alone with those M200 freezes when using serial comm, I also believe it's due to flow control, specifically xon/xoff , I may be able to exit out of the freeze with an escape code, i'll try that. It's likely CTS/RTS has been implemented as a hardware interrupt, whereas the xon/xoff support is obviously software and can leave "dead links" if they implemented that without any timeout. (It's just a hunch I did not investigate that so don't quote me on this.) The device seems less likely to "hang" with hardware flow control. The M102 also crashes less than my M200 for whatever reason. I'm probably a nerd but I like to use serial communication to make demos, or simply revive those programs and learn those techniques again. I have a serial link between M200 and M102 and you quickly hit the limitations of stock "telcom"; Also some features exist int he M200 telcom but not on the m100/102 ( like line feed CR/LF conversions ) which explains why the STAT strings are different. So communication between those two is limited. I'll have a look at HTERM Le 2022-12-08 21:05, B 9 a écrit : > > > The frozen thing is common for me with TELCOM as well when I remove the serial cable. I don't know if that's a Tandy 200 thing or if it affects the Model 100 as well. > > > > I presume it has something to do with Carrier Detect, or the like. The solution is to hit Shift-Break then F8. Every time you hit Shift-Break, TELCOM seems to process one character before it gets stuck waiting again for CD, so you might have to hit it repeatedly. > > > > I have heard that John Hogerhuis's HTERM is the consensus best terminal, but I have not used it yet. > > > > For file transfers, I use dlplus (https://github.com/bkw777/dlplus) (also originally written by John Hogerhuis, but I believe it is now maintained by Brian White). Dlplus is nicer than xmodem because it acts like a drive. It also has a nifty bootstrap mode (https://www.youtube.com/watch?v=H0xx9cOe97s) that gets a binary transfer program onto your T200. Just run this on your host side and follow the prompts: > > > > ```bash > > dlplus -b DSKMGR.200 > > ``` > > > > If you are connecting to a UNIX box via TELCOM, I humbly suggest giving my Tandy Terminfo (https://github.com/hackerb9/Tandy-Terminfo/) a try. > > > > --b9 > > > > > P.S. There are other options than DSKMGR.200 if you find it takes too much space. Use `dlplus -l` to see them. > > > > > > > > > > > On Thu, Dec 8, 2022 at 4:54 AM Cedric Amand mailto:ced...@cedric.net)> wrote: > > > > > > Hello everyone, > > > > > > > > Very simple question ; is there a more sophisticated program than TELCOM for modem or direct serial communications ? > > > > Maybe part of a ROM ? > > > > > > > > Specifically, something that would support xmodem or make file exchanges easier ? Also maybe easier settings than "stat" :) > > > > > > > > I also often find myself with the M200 "frozen" when doing serial communication (cannot F8 anymore, need to RESET), like if I hangup on one side, the receiving M200 is frozen. > > > > Am I doing something wrong ? > > > > > > > > Thanks ! > > > > > > > > >
[M100] Better TELCOM program / ROM
Hello everyone, Very simple question ; is there a more sophisticated program than TELCOM for modem or direct serial communications ? Maybe part of a ROM ? Specifically, something that would support xmodem or make file exchanges easier ? Also maybe easier settings than "stat" :) I also often find myself with the M200 "frozen" when doing serial communication (cannot F8 anymore, need to RESET), like if I hangup on one side, the receiving M200 is frozen. Am I doing something wrong ? Thanks !
Re: [M100] custom key mapping generator for Tandy 200
Currently, I've been trying to replace my main 32KB ROM with a ST M27C256A-100 This works. And I've been trying to replace the 8KB with a ST M27C64A-150 This does not work for me. The system freezes after seconds, then becomes completely unusable to the point even the power button (or a hard reset) does nothing, screen displays garbage or just all black pixels I've ordered alternative parts, in case my 27C64 is marginal in some way, but the ROM reads and re-reads fine in a TL866, and it's a copy of the original ROM. I'm continuing my experiments when new parts arrive. Le 2022-11-19 01:19, Stephen Adolph a écrit : > So, to recap, > > > 1. We have a spreadsheet to create custom key maps for Tandy 200 > > > > 2. Separately, we are trying to confirm in hardware that a single 27C64 rom can be substituted for M13, to implement the custom keymap. > > > > I would encourage the approach for dealing with different keyboards on other machines. > > > > Keep in mind.. if the actual characters themselves change, the modification is deeper. Such is the case for M10 for example. (Or just use the usa character set to make it easy). > > > > > > Thanks > > Steve > > >
Re: [M100] custom key mapping generator for Tandy 200
Interesting Georg ! On my "french" (as in from France) M200 the keyboard is stock with azerty keys. When you say you patched your ROM, did you patch the 32 or 8KB ROM for the key mappings ? Did you lose the modem functionality (I guess so)- by using virtualT's ROM ? Have you considered (or maybe you don't need it) to make a hybrid rom by copy pasting the modem block out of your original ROM ? Le 2022-11-13 18:30, Georg Käter a écrit : > Hello together, > > > > > > I own a M200 "German/EU Version" (Art.Nr. 26-3860H) w/modem, for German market it was delivered with set of keyboard > > > > caps and a data tape including driver for keyboard and printer. I tried this in VirtualT and it seems to work so far. To run REX > > > > on my M200 I replaced original ROM by ROM from VirtualT patched to serve german keyboard mapping. > > > > For your reference I´ve added original ROM files and files from tape for your reference. > > > > > > > > Regards > > > > Georg > > > > > Georg Käter > Gangolfsweg 44 > D-52076 Aachen > Tel. : +49 2408 7194987 > Fax. : +49 2408 7196758 > Mobil : +49 171 4839954 > E-Mail : > > georg.kae...@gk-engineering-services.de (mailto:georg.kae...@gk-engineering-services.de) > > == Ihre Nachricht == > > von : Cedric Amand > gesendet : Sonntag, 13. November 2022, 15:37 > an : m...@bitchin100.com > Betreff : [M100] custom key mapping generator for Tandy 200 > > __ Originalnachricht ___ > > > > > > My point exactly Brian ! > > > > How did they come up with that idea ? It makes no sense. It really prevents you from using the option rom socket. > > > > The docs does not talk about removing it. > > > > > > > > And even if you could remove it ; the installation procedure of that ROM is not easy at all, requires to type two "calls" with the freaking keyboard inverted. > > > > OK - us nerds 40 years later can do it easily, just type "CQLL", but imagine explaining that to a random journalist in 1984 ?! > > > > Especially as the french doc (which I happen to have) says to type "CALL" not CQLL. > > > > > > > > I also wonder if other markets are affected by this plague, > > > > If anyone here lives in germany and owns a qwertz (or other keyboard variant) of the M200 : do you have a "stock option ROM" as well ? > > > > > > > > I also wish to thank Stephen publicly for the time he invested into helping me, as indeed, you can't use an option ROM (and even less a REX#) in those non-qwerty M200s, and I think this research might help some other people at some stage (this hobby is booming right ? :) ) > > > > > > > > We're (and I am) in the process of replacing the main rom + 8KB rom with a 27C512 flashed with a custom "native Azerty" firmware > > > > Which should free up to option socket, for a REX# > > > > > > > > I also plan to make other modifications to that custom ROM, but we'll see if I get there. > > > > I've also been experimenting in the past with custom firmware for the my M102 for different reasons. > > > > I'm a "modem" nerd and I have all the equipment (PABX, etc) to make voice calls between my vintage laptops - so it's important for me to have my modems work. This required a custom firmware to make my M102 work, with modem, with a REX#. ( OK I think this kind of stuff is only relevant to me this time :) :) > > > > > > > > > > > > > > Le 2022-11-13 14:53, Brian White a écrit : > > > > > > > > > > > > > Nice. > > > > > > > > > > > > So the point would be to make the main rom natively azerty to match the hardware, free up the option rom slot for normal use, without otherwise changing the main rom so that it becomes incompatible with application software? I guess you might even be able to make a dvorak version and move the keycaps around? > > > > > > > > > > > > I'm just trying to imagine the sales pitch for that azerty 200 that needs the option rom, thus preventing the use of any other option rom (or at least making it pretty inconvenient by having to swap them on every reset I guess?) > > > > > > > > > > > > "Here's your new model 200. It's only half as useful as others with no modem and no option rom but you can still pay full price please." > > > > > > > > > > >
Re: [M100] custom key mapping generator for Tandy 200
My point exactly Brian ! How did they come up with that idea ? It makes no sense. It really prevents you from using the option rom socket. The docs does not talk about removing it. And even if you could remove it ; the installation procedure of that ROM is not easy at all, requires to type two "calls" with the freaking keyboard inverted. OK - us nerds 40 years later can do it easily, just type "CQLL", but imagine explaining that to a random journalist in 1984 ?! Especially as the french doc (which I happen to have) says to type "CALL" not CQLL. I also wonder if other markets are affected by this plague, If anyone here lives in germany and owns a qwertz (or other keyboard variant) of the M200 : do you have a "stock option ROM" as well ? I also wish to thank Stephen publicly for the time he invested into helping me, as indeed, you can't use an option ROM (and even less a REX#) in those non-qwerty M200s, and I think this research might help some other people at some stage (this hobby is booming right ? :) ) We're (and I am) in the process of replacing the main rom + 8KB rom with a 27C512 flashed with a custom "native Azerty" firmware Which should free up to option socket, for a REX# I also plan to make other modifications to that custom ROM, but we'll see if I get there. I've also been experimenting in the past with custom firmware for the my M102 for different reasons. I'm a "modem" nerd and I have all the equipment (PABX, etc) to make voice calls between my vintage laptops - so it's important for me to have my modems work. This required a custom firmware to make my M102 work, with modem, with a REX#. ( OK I think this kind of stuff is only relevant to me this time :) :) Le 2022-11-13 14:53, Brian White a écrit : > > > Nice. > > > > So the point would be to make the main rom natively azerty to match the hardware, free up the option rom slot for normal use, without otherwise changing the main rom so that it becomes incompatible with application software? I guess you might even be able to make a dvorak version and move the keycaps around? > > > > I'm just trying to imagine the sales pitch for that azerty 200 that needs the option rom, thus preventing the use of any other option rom (or at least making it pretty inconvenient by having to swap them on every reset I guess?) > > > > "Here's your new model 200. It's only half as useful as others with no modem and no option rom but you can still pay full price please." > > > > -- > > bkw > > > > > > On Sun, Nov 13, 2022, 8:28 AM Stephen Adolph mailto:twospru...@gmail.com)> wrote: > > > > > > > > hi folks, > > > > > > > > Thought I would share this work. It is a spreadsheet for computing the keyboard table in the T200 so you can make native custom keyboards for T200. > > > > > > > > Why? > > > > The AZERTY keyboard in Europe was accommodated using an option ROM that kinda hacked the keyboard. Keystrokes get intercepted and corrected to be AZERTY even though the main ROM is set up for QWERTY. > > > > > > > > An alternative is to have the main rom directly support AZERTY. > > > > To do this, there are 6 keyboard mapping tables that start at 9763h. Each table are 44 bytes long. > > > > > > > > This spreadsheet lets you assign the ascii codes for each of the 44 affected keys, for all 6 tables. (unshifted, shifted, GRAPH, shift GRAPH, CODE, Shift CODE). > > > > > > > > It is an excel spreadsheet that included the analysis add it so that certain needed functions are present. > > > > > > > > Once you make the correct keyboard mapping, the spreadsheet provides the 6x44 bytes in assembly compatible form, so you can compile and patch the tables with a hex editor. > > > > > > > > This approach could be used for other machines also. > > > > Note - the AZERTY keyboard did NOT modify the actual character set, so that is out of scope. Of course it is possible to patch the main ROM to change the bitmaps as well. Not handled by this spreadsheet. > > > > > > > > Comments welcome. > > > > Steve > > > > > > > > > > >
Re: [M100] Modems and the modern world
Hey I'm not alone :) I'm also a fan of telecom and I made the built in modem of my m102 (300 bauds as you said) work What I can suggest if you would like to experiment a lot with vintage modems ; is getting a home PABX (a phone exchange), or a small business PABX (even an isdn pabx works) You can find those for anywhere between 20 and 100 dollars/euros on ebay because nobody needs them anymore, like a 4 lines pabx. This allows you to have your own PSTN network for your experiments (if you're into that kind of thing that is) I made "calls" between my Model 102 and a USR56K modem with no issue. You also need a cable. That cable is so vintage that you actually have to pickup the phone to make it dial. Beware that the M100 and M102 do not support DTMF dialing, only pulse, and nowadays it's probably impossible to make a call with pulse. You can however dial the number yourself (with the above cable) - or, again, use a PABX that supports both DTMF and PULSE. From my own experience, at least over here in europe, it's impossible to make proper modem calls on land line like they worked back in the day, for gow knows what reason the quality of the line makes it impossible to negociate anything above 14,4k. I guess they filter more or the signal is so digital that it doesn't behave in the proper way an analog modem expects. Le 2022-10-06 20:27, Will Senn a écrit : > > > As you may have noticed, I'm putting my m100 through its paces and enjoying the process of treading down memory lane. Last night I finished coding up my banner program using the M100 font. Now I just need a printer (or retroprinter emulator) to try it out on... in the meantime, I'm catching up on remote communications. If I understand correctly, the m100 has a built in 300 baud modem. Am I understanding this correctly? > > > > If so, in this oh so modern era, how does one go about exercising it? I don't currently have a land line, so does it work with an iphone? (never saw that coming... can I connect 300 baud over iphone, hilarious, but there you have it). Are there BBSes still in operation? > > > > Later, > > > > Will > >
Re: [M100] is the list actually working?
Exactly, Actually DMARC just let's you know what SPF records would already do on their own, but silently. By implementing DMARC records, you know who's trying to send mail "on your behalf" and I noticed that in the DMARC reports, this mailing list's server was one of them. In my case, SPF records limit who can send mail with a "from" mydomain.com And DMARC system let's me know who's sending such emails "without my consent" (= who's ignoring my spf records). I hope I'm making sense without getting too technical, but I guess there are many tech minded people in this list anyway. Le 2022-05-03 16:42, Joshua O'Keefe a écrit : > > > > > > On May 3, 2022, at 7:09 AM, Cedric Amand wrote: > > I did not investigate this much ; but I would look at the DMARC and « from » problems > DMARC is definitely one -- potentially the main -- issue here. If someone with a strict DMARC record submits a message to the list for broadcast, many list recipients will quarantine or reject the message unless the From: header is munged. > > > > Mailman has some potential mitigation strategies against this[1], none of which are great, but DMARC fundamentally broke the way email works by pinning its mechanism on the From: header.[2] > > > > [1] https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html > > > > [2] RFC7489 §5 says, essentially: requiring trust in From: was the only way to make DMARC go. It doesn't actually justify doing so beyond saying (in §6.7) acceptance is a local decision. The RFC takes no responsibility for establishing a de facto status quo that is broken. >
Re: [M100] is the list actually working?
There are multiple things that seem to be weird with the mailing list ; I for example receive DMARC complaints that your domain is sending email with a « from » of my domain ; which is nowadays asking for problems The « reply « field is also weird with multiple times the mailing list name in it I did not investigate this much ; but I would look at the DMARC and « from » problems Stephen Adolph mailto:twospru...@gmail.com)> 3 mai 2022, 15:22:48 wrote: > > I find myself wondering if the mailing list is now becoming very unreliable. > If this message gets through please respond. > > thanks > > Steve > >
Re: [M100] M100/M102 printing
Hi Brian , I actually share some of your concerns about my choice of a (partially) metallic centronics ; but what made my decision is that the actual original Tandy cable had a metallic centronics connector so I basically made the same. The original was just grey but I went for rainbow because well it’s way cooler this way :) There are however some custom made cables I saw with a complete metallic plug ( and sometimes even metalllic case ) and this makes no sense to me for the reasons you stated https://ibb.co/511YRxy This is my cable(s) - and the centronics connector is the same that was in the original Tandy . I have strain reliefs on both sides . Brian K. White mailto:b.kenyo...@gmail.com)> 30 avr. 2022, 20:57:37 wrote: > > Small note about the centronics connector: Metal centronics is not necessarily better in this case. Since this is originally supposed to be a portable computer, the accessories also ideally want to be portable, and there are a few different features that make that a little more or less optimal. A plastic connector is better for a laptop bag for two reasons. It weighs less, and doesn't damage other objects it's banging around with. Plus, a final detail, in particular there is the shape of the bail locks. There is a style of plastic connector where the bail locks have a lower profile triangular shape vs a larger more bowtie or butterfly wing shape that sticks out more and is a little more annoying in a bag with other cables. No bail locks at all is even better for bag-annoyance, but I think having the bail locks is worth more. Ideally you want plastic, with that less-snaggy shape, and most importantly a strain-relief clip on the crimp side. The futurlec one linked on tandy.wiki is plastic and has strain relief and not the ideal wing shape, but the wings are pretty stubby so it's not bad. There are others on digikey but they either lack a strain relief or they cost a lot more for no reason. This is an example of the ideal wing shape I mean (but don't use this connector, it's the wrong kind of wire attachment, it's just to show the bail lock shape) https://www.digikey.com/short/300fczp9 This one is at least usable, the cable attaches by IDC crimp, but no strain relief, and a strain relief is more important than any of these other considerations, also notice it's $16 whopping instead of $2.50 https://www.digikey.com/short/57fnbdqw The ideal would be the futurlec one with these bail locks, but the futurlec ones are stubby enough that its good enough. It's a very minor difference at that point. The metal ones are usually the real big and pointy ones. So, 90% ideal plus only $2.50 is why that's the linked one. -- bkw On Sat, Apr 30, 2022, 10:42 AM Cedric Amand wrote: Thanks, It's indeed related to my DIP switch "SLCT IN" Now I'm able to print, the carriage return is replaced by an uppercase "angstrom" sign but it's a good start By the way, in case anyone is interested, I was forced to order stuff "5 times" for my printer cables, so I'm gonna make 4 more DIP26 -> Centronics adapter cables and put them on ebay, I would gladly sell some of them "at cost" to members of this mailing list first. (they would be shipping from belgium so probably for fellow european geeks only) I used fancy "apple rainbow" flat cable to make them extra cool and quailty centronics (metal). Email me if interested. Le 2022-04-30 16:31, Joshua O'Keefe a écrit : On Apr 30, 2022, at 6:50 AM, Cedric Amand wrote: > > 1) A switch between what they call EPSON and IBM mode (no idea what this does but looks interesting) > If anyone knows about those two modes, please share :) Epson mode will likely set the printer to use Esc-P control codes, and IBM mode will probably set it to use Esc-[ control codes and possibly map the character set to match an IBM PC's. My suspicion is that this switch, at least, won't affect your printer ready line issue.
Re: [M100] M100/M102 printing
Thanks, It's indeed related to my DIP switch "SLCT IN" Now I'm able to print, the carriage return is replaced by an uppercase "angstrom" sign but it's a good start By the way, in case anyone is interested, I was forced to order stuff "5 times" for my printer cables, so I'm gonna make 4 more DIP26 -> Centronics adapter cables and put them on ebay, I would gladly sell some of them "at cost" to members of this mailing list first. (they would be shipping from belgium so probably for fellow european geeks only) I used fancy "apple rainbow" flat cable to make them extra cool and quailty centronics (metal). Email me if interested. Le 2022-04-30 16:31, Joshua O'Keefe a écrit : > > On Apr 30, 2022, at 6:50 AM, Cedric Amand wrote: > > > > 1) A switch between what they call EPSON and IBM mode (no idea what this does but looks interesting) > > If anyone knows about those two modes, please share :) > > Epson mode will likely set the printer to use Esc-P control codes, and IBM mode will probably set it to use Esc-[ control codes and possibly map the character set to match an IBM PC's. > > My suspicion is that this switch, at least, won't affect your printer ready line issue.
[M100] M100/M102 printing
Hello everyone I just finished my IDC 26 to centronics cable trying to print from my M102 I'm printing on a 1985 Brother HL1109 so that should be period accurate Nothing happens if I hit "print", the M102 freezes and I have to "reset". I read on some TRS80 related documentation that there are POKE locations to set the baud rate of centronics Does that applyto the M100/M102 ? What are the defaults ? Where are those POKEs and settings if any ? I loked at the manual but apart from "hit PRINT" there isn't much info thanks !
[M100] serial printing
Hi everyone ! I was lucky enough to score a very vintage brother M1109 printer ( circa 1985 ) that works and has a serial input I don’t have the Model 100 cable and was wondering if the m102 is able to print with the serial port ; and how to do that Thanks !
[M100] CRC error & misc : UPDATE
Just wanted to post an update about my recent issues. As I kinda suspected, not knowing the history behind my M102 with a REX# (that I bought "as is"), has been a huge hassle. After trying to play with ROMs today, suffering from many crashes, CRC errors, and such, the M102 suddenly lost all it's RAM, including my files, the time was lost, and the REXMGR vanished. It was back in january 2000 and l lost all of my stuff. Luckily I did use REX to save a memory dump a couple of days ago. Now... Having an empty M102 ( not my doing ) I thought "ho , hell ; let's go for it" and I did a complete reset, and reinstalled the REX software from scratch, then made an update from 2.0 to 2.1/ (all of that with a DOS pc running Desklink) And I had no issue whatsoever in the whole process (apart from guessing filenames) And now : everything works properly. I think my REX# was in a semi broken state causing all kind of weird issues. Also I now have "program names" in the main menu for ROMs, so obviously I understand how to enter them now (I didn't have that!) Switching between ROMs seems to work as it should (it starts right away) and you hit F8 you're back in main menu; and then you have a "shortcut" to restart your ROM program. None of that was working properly. I really don't know in what "state" my REX# was, maybe it was corrupted in some way, but I guess I'll now have less stupid questions as the freaking thing seems to work as it should now. I'll I think spend some time creating a youtube video (if nobody did that) to explain how to install/upgrade REX# , using vintage tools ( DOS/desklink ) I'll also try to make my own ROM as I'm kinda sad that I lose my built-in modem capabilities (this is a european model with an US ROM because of REX). I'll try to overwrite the modem section of the ROM and see what this does. Thanks again to Brian, John & Stephen for their support, some of which I printed :)
Re: [M100] CRC error in 57600 Y
Thanks Brian that is perfectly clear, Just one question if I may ; what's the relationship between having the file "RX#U1.DO" loaded in my M102 (I did that with a serial link, asici upload, to test the upgrade procedure which I didn't finish yet) and the fact to use REXMGR to just load ROM files ? What's the relationship between the two ? I should maybe simply remove the RX#U1 as I don't plan to upgade just yet (I still don't feel I understand the platform enough) and gain more experience with REX# and the M102 regular ASCII uploads first. Also it is unclear why some ROM seem to "start right away" when they are loaded in REX# whereas some other do not. And last question, if I hit F8 I'm back in my M102 files and out of the ROM, but how do I get back in the ROM (like back in multiplan for example) I really apologize for my newbie questions but I'm sure there's a lurker somewhere also learning something thanks to me :-) Le 2022-04-14 04:27, Brian K. White a écrit : > > (re-sending from a different account, I sent this earlier but it never > showed up) > > > Desklink is fine, and that checksum message is probably about the > initial ascii transfer of RX#U1.DO . It's easy to get a corrupt copy > with a manual ascii transfer, and so it has a self-check that it runs > before doing anything else, to prevent running a corrupt copy. > > Expanding on that, > > The old dos desklink works perfectly well, but that doesn't neessarily > ensure it will work with rex/rex# setup, because rex setup doesn't even > work with a real tpdd1 or tpdd2. > > There is a weakness in the tpdd routines in the rex tools, which makes > "bad choice?" a complicated question to answer. It's a perfectly fine > choice for everything else, but may or may not be a good choice for this > specific task. > > Steve has a few times in the past that he only tests against Laddie > himself. If you use anything else, it may or may not work, but if it > doesn't he doesn't care. > > I use dlplus on linux and it always works also on most machines, but I > have one old laptop where it doesn't. (works for everything else but > just not for rex setup) The only thing notable about that laptop is that > it's an old netbook with an atom cpu, so it's slow. Works fine on every > other machine I have, and dlplus works fine even on that netbook for > everything but the rex or rex# setup util. So if you have an ms-dos > machine, that is probably old and slow also, although that should still > be fine for doing this because of just running dos with no other > processes at all stealing cpu and a real com port, vs a full multiuser > linux os with 500 other processes plus using a usb adapter for the com port. > > So, all in all, I'd say desklink on dos should work fine, even with the > rex utils pickiness. > > However I think that is all beside the point. Your problem is probably > not the tpdd server but the initial ascii transfer of the setup program > itself. There is an initial self-check that verifies the initial > transfer of the RX#U1.DO program itself to the 100 in the first place. > > If you're using a plain comm program to manually send the program > instead of using a dedicated bootstrapper program that nails down all > the variables and details just for exactly this reason, then it's very > easy to get a corrupt transfer. So Steve has a self-check to catch that. > > In another post which possibly hasn't posted yet or possibly went to > spam, I gave a lot of links and details to garanteed ways to do it, > which uses a dedicated bootstrapper program to send the initial RX#U1.DO > and either dlplus or laddiealpha for the tpdd server. These are known to > work. Anything else is "might work". But the bulletproof simple ways > currently need windows or linux or mac. There is no bootstrapper for > ms-dos. (Well, the original dos desklink does supposedly have a > bootstrapper function by creating a file named loader.ba and then you > can issue a command from the 100 to trigger it, but I've never got that > to actually work) > > So if you still want to use ms-dos on the host side, you'll have to do > so trial & error to figure out why you're getting a corrupt transfer of > the initial RX*.DO file. Doing it manually leaves many opportunities for > leading junk, trailing junk, bad line-endings, and dropped characters > from gpoing too fast. You'll have to say *exactly* what you did or else > there is no way to guess what might have gone wrong. > > Also if the host is not really dos but is really windows, then try with > laddiealpha for the tpdd server and tsend.ps1 for the bootstrapper. > See my other post for all the details on that. > > -- > bkw > > > On 4/13/22 18:15, Cedric Amand wrote: > > Yes, > > Bad choice ? > > Le 2022-04-14 00:14, John R. Hogerhuis a écrit : > > > > " TPDD emulator run on MSDOS" > > > > Desklink? > > -- John. > > > > > -- > bkw
Re: [M100] CRC error in 57600 Y
Yes, Bad choice ? Le 2022-04-14 00:14, John R. Hogerhuis a écrit : > > > " TPDD emulator run on MSDOS" > > Desklink? > > > > -- John. > > > > >
[M100] CRC error in 57600 Y
Hey everyone, Trying to make use of my second hand REX, I've managed to have a TPDD emulator run on MSDOS and was able to load a couple of ROMs (mforth & MP100 )/ This is REX#2.0 Each loading ends up with the message CRC error in 57600 Y which is overwritten by an "Ok" which actually gives OkC error in 57600 Y If I load the same ROM again, it starts. The programs seem to work as far as I can see. I'm pretty sure it didn't do that the first time I loaded a ROM, but now it does it all the time. TSDOS101 - which was already in my REX# , does not make this error message. Only the roms I uploaded. I'm sure I did something wrong, and hopefully this is not a FAQ, but any help appreciated :)
Re: [M100] Update & info on REX#
Hello Brian, First of all, again thanks for taking the time to answer me in so much detail. You're right about the confusion about TPDD client and emulators, I actually just did the mistake, installing on my msdos computer what is clearly an tpdd client, not an emulator. By the way here's my setup :) https://ibb.co/ccMR2Gw I have the files from the latest REX"2.1 ZIP file, a working serial link obviously I'm planning to use an MSDOS computer (here a libretto out of my collection) as with a recent Maxbook pro M1 everything becomes more complicated. What you you recommend for bootstrapping from MSDOS (6.22) (Alternatively the libretto has Win98 if needed.) Same question for the TPDD emulator ? The rest of your instructions are super clear, and I'll try that right away, maybe making a summary post myself thanks! Le 2022-04-13 22:30, Brian K. White a écrit : > > Yes. In fact a real tpdd doesn't even work for this. > > It's supposed to in theory even though it's so inconvenient to rig up > that no one would ever actually do it that way, but I had reason to > actually try it and the rex setup util doesn't work with either a real > TPDD1 or TPDD2. > > Anyway yes you just get the right kind of serial cable, download the > rex# setup files and a bootstrapper program and a tpdd server program > into a temp dir, use the bootstrapper to transfer and run the rex# setup > utiil, start the tpdd server while the setup util is waiting at it's > first prompt, and the setup util then fetches a file or two from the > tpdd server while it's running. > > After that, in day to day usage you'll use that same serial cable and > tpdd server all the time for ordinary file transfer both ways, and in > rexmgr to install option rom images. >
Re: [M100] Update & info on REX#
Okay, What's you're saying is that with the serial link still in place (for the initial serial transfer), i can simply switch software in my modern pc (on the other end of the serial) instead of going into the extra trouble to actually make a real TPDD floppy do the job :) Well actually i'll try both, I guess it's a good idea to understand the thing fully (i plan to) and running the floppy tpdd is part of the hobby :) Le 2022-04-13 16:26, Stephen Adolph a écrit : > > Hi Cedric, > > > To transfer XX.DO programs into the M100 without a DOS on the laptop, you can use a serial transfer method by connecting the M100 via serial to a PC and using a terminal program to send the text. > > > > When you are actually running the upgrade utility, you need to replace the PC-terminal end with a PC-TPDD device end (or any form of TPDD device). > > I tend to use Laddie Alpha on the PC to emulate a TPDD drive. > > > > happy to help ;) > > > > So, get the Rel 2.1 build 19 bundle RX#V21_b19.ZIP (https://bitchin100.com/wiki/images/e/ea/RXSV21_b19.ZIP) > > > > by any means, transfer RX#U1.DO into the laptop and run it. > > follow the instructions at the REX# wiki. > > > > https://bitchin100.com/wiki/index.php?title=REXsharp#REX.23_Upgrade_Utility > > > > good luck. > > Steve > > > > > On Wed, Apr 13, 2022 at 10:16 AM Cedric Amand mailto:ced...@cedric.net)> wrote: > > > > > > Thanks a lot Stephen; > > > > > > > > This is all probably easier for the original owner, having to "onboard" not knowing the history of the device is difficult. > > > > > > > > What was troubling to me is the releases notes that made me believe a version I did not have (4.x) solved the Y2K problem, or a rom patch. > > > > Given the fact I know for sure my ROM is stock US, I was wondering how the hell the Y2K worked as expected > > I understand now that's because REX#v2.0 is more recent than those v4.x release notes, thanks for the clarification ! > > > > > > the "blank" thing was also a source of concern (bug ? old ram from the old owner ?) when you don't know, well you don't know :) > > > > > > > > One thing that is yet a bit unclear to me is the loading of an updated REX software : the manual says to load the basic probram with a serial link, but if I get this right, the loading of the rex software image itself can ONLY be done with a TPDD device right (not a serial link), am I correct ? > > > > I have access to a TPDD floppy, but just want to be sure I got this part right. > > > > > > > > > > > > thanks again for taking care of your users and customers Stephen, that is much appreciated, > > > > > > > > > > > > > > Le 2022-04-13 14:32, Stephen Adolph mailto:twospru...@gmail.com)> a écrit : > > > > > > > > > > > Cedric, > > > > > > > > > see comments below. cheers Steve > > > > > > > > > > > > On Wed, Apr 13, 2022 at 8:12 AM Cedric Amand mailto:ced...@cedric.net)> wrote: > > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > > > > > As Stephen already knows, I bought a M100 from someone would did put a REX# in it, and i'm trying to get a complete understanding of it. > > > > > > > > > > > > > > > > I have many questions but let's start with a few > > > > > > > > I see versions of the rex from 4.5 to 4.9, and other versions saying V2.0 or v2.1 > > > > > > > > Do some numbers refer to hardware ? > > > > > > > > > > > > > > > > > > > REX# hardware is different from REX hardware. The software is not interchangeable. > > > > > > REX# software is on the REX# page at bitchin100, currently 2.1. > > > > > > REX software is the old 4.x stream. > > > > > > > > > > > > > > > > > > > > > > If I use the REXMGR program; the thing says REX#2.0 > > > > > > > > Where do I get that" woftare" info ( 4.5 ? 4.9 ?) i think I sasw it once but can't reproduce > > > > > > > > > > > > > > > > > > > > > press I. > > > > > > you don't want the old software, it won't work on REX#. > > > > > > > > > > > > > > > > > > > > I have a RAM image called "blank
Re: [M100] Update & info on REX#
Thanks a lot Stephen; This is all probably easier for the original owner, having to "onboard" not knowing the history of the device is difficult. What was troubling to me is the releases notes that made me believe a version I did not have (4.x) solved the Y2K problem, or a rom patch. Given the fact I know for sure my ROM is stock US, I was wondering how the hell the Y2K worked as expected I understand now that's because REX#v2.0 is more recent than those v4.x release notes, thanks for the clarification ! the "blank" thing was also a source of concern (bug ? old ram from the old owner ?) when you don't know, well you don't know :) One thing that is yet a bit unclear to me is the loading of an updated REX software : the manual says to load the basic probram with a serial link, but if I get this right, the loading of the rex software image itself can ONLY be done with a TPDD device right (not a serial link), am I correct ? I have access to a TPDD floppy, but just want to be sure I got this part right. thanks again for taking care of your users and customers Stephen, that is much appreciated, Le 2022-04-13 14:32, Stephen Adolph a écrit : > > > Cedric, > > > see comments below. cheers Steve > > > > On Wed, Apr 13, 2022 at 8:12 AM Cedric Amand mailto:ced...@cedric.net)> wrote: > > > > > > Hi everyone, > > > > > > > > As Stephen already knows, I bought a M100 from someone would did put a REX# in it, and i'm trying to get a complete understanding of it. > > > > > > > > I have many questions but let's start with a few > > > > I see versions of the rex from 4.5 to 4.9, and other versions saying V2.0 or v2.1 > > > > Do some numbers refer to hardware ? > > > > > > > REX# hardware is different from REX hardware. The software is not interchangeable. > > REX# software is on the REX# page at bitchin100, currently 2.1. > > REX software is the old 4.x stream. > > > > > > > > > > If I use the REXMGR program; the thing says REX#2.0 > > > > Where do I get that" woftare" info ( 4.5 ? 4.9 ?) i think I sasw it once but can't reproduce > > > > > > > > > press I. > > you don't want the old software, it won't work on REX#. > > > > > > > > I have a RAM image called "blank". I can't load it, it says "error ram sze mismatch" > > > > > > > that is because the image is blank, and you have not actually saved a ram image to it. > > > > > > > > Again not sure what's the history of my M100. Is that a RAM image I shoudl get rid of ? > > > > > > > > > it is the default, unsaved, ram image. > > > > > > > > It's likely my REX needs an upgrade. I have difficulties finding info about how to do that precisely. > > > > > > > you have a REX#. > > The instructions are on the REX# page at bitchin100. > > I try my best to document what you need to do. > > > > https://bitchin100.com/wiki/index.php?title=REXsharp > > > > > > > > > > > > Final question ; my M100 display Y2K correctly, and I'm pretty sure ot's NOT running a rex# version with the software fix. How could I know what the previous owner did to an Y2K working like it should ? > > > > > > > > > All REX# software fixes Y2K without needing to patch your main ROM. > > > > > > > > > > > > thanks ! > > > > > > >
[M100] Update & info on REX#
Hi everyone, As Stephen already knows, I bought a M100 from someone would did put a REX# in it, and i'm trying to get a complete understanding of it. I have many questions but let's start with a few I see versions of the rex from 4.5 to 4.9, and other versions saying V2.0 or v2.1 Do some numbers refer to hardware ? If I use the REXMGR program; the thing says REX#2.0 Where do I get that" woftare" info ( 4.5 ? 4.9 ?) i think I sasw it once but can't reproduce I have a RAM image called "blank". I can't load it, it says "error ram sze mismatch" Again not sure what's the history of my M100. Is that a RAM image I shoudl get rid of ? It's likely my REX needs an upgrade. I have difficulties finding info about how to do that precisely. Final question ; my M100 display Y2K correctly, and I'm pretty sure ot's NOT running a rex# version with the software fix. How could I know what the previous owner did to an Y2K working like it should ? thanks !
Re: [M100] Tandy Model 100/102 modem pickup line
Sure, anything that can help the community,
CAT NO 26-3803
Serial 701400021
I just wanted to know if my problem was hardware of software, it seems to
be software - clearly the US rom breaks the modem ( and interestingly, it
also adds features like F2 pulse dialing in TELCOM, which my EU ROM does
not have. (I said DMTF in my previous mail, I meant PULSE of course))
I'll probably revert to US ROM & REX# once I've documented (probably a
video) the process of reviving and making, real, proper, modem calls with
this equipment and a few others. I just find it cute to have this wok for
real again. I don't know the situation in the US but here it's becoming
close to impossible to even have a proper PSTN line (most are VOIP on top
of cable modems), obviously none of them support pulse dialing anymore, so
well, my project "to make it work again like back in the day" is a
challenge of its own.
Le ven. 4 févr. 2022 à 13:42, Stephen Adolph a
écrit :
> A snip from the notes section at the rex# wiki:
>
>
> Notes
> =
> Model 100:
> * In Europe and UK, and probably elsewhere, there are newer versions of
> M100 that have different boards.
> * Model numbers are 26-3801B and 26-3802B.
> * REX# does not function correctly in these models, due to the
> significantly different main ROM.
>
> I am recalling that the work to get REX# to support these versions of M100
> is significant. It would require identifying all the rom calls and
> correcting them, and testing them. Basically documenting this new main rom.
>
> You say this is a T102. Can you tell us the model number?
>
> It makes sense that if there is a B variant of the M100, with a different
> ROM then there is probably something similar for T102.
>
> It would be tricky and crash prone to try and switch main roms with a rex
> installed. You would have to deinstall rexmgr in order to use the original
> rom.
>
> Thanks.
>
> Steve
>
>
> On Friday, February 4, 2022, Stephen Adolph wrote:
>
>> The EU rom is really really different. Rex doesnt work with that rom.
>> Previous owner valued rex more than modem.
>> Steve
>>
>>
>> On Friday, February 4, 2022, Cedric Amand wrote:
>>
>>> Hello Steve, Hello everyone
>>>
>>> Thanks again really for taking the time... We all have lives and I
>>> really appreciate.
>>> I did some more research (isn't that what we all like in this hobby) and
>>> here is what I came up with.
>>>
>>> - I have for sure a Belgian, European, Model 102. no doubt about it.
>>> - My little homemade PABX (phone exchange) is flawless, it works with
>>> other modems of the era or plain analog phones.
>>> - With a "US" BIOS (not sure which) and the REX#, the modem part is
>>> completely broken. This is especially obvious if you hit F4 in TELCOM, the
>>> M102 start to make awful noise (without cable, just on it's own!) and the
>>> program seems crashed (needs reset/reboot).
>>>
>>> From there I tried;
>>>
>>> - Removing the REX# (which I wouldn't have done without everyone's
>>> support here) ; problem is the same
>>> - Interestingly, "TERM" (F4) in TELCOM also still crashes !
>>>
>>> Then obviously, what I tried;
>>>
>>> - The seller did gave me my original BIOS, just marked "EU" (if I can
>>> give you a version i'd gladly do it, I can also dump it if that's of any
>>> use the the community)
>>>
>>> Now... I guess I'm "stock" again.
>>>
>>> This changes a lot of things.
>>>
>>> The TELCO program changes a lot !
>>> Interestingly, is has no more F1 or F2 features, F2 was called "CALL"
>>> (it allowed me to do DTMF pulses), the feature is not there at all anymore
>>> (?!)
>>> Hitting F4 (TERM) does not make any noise now, and does not crash.
>>>
>>> I was able to make a link between my USR 56K and the M102, thru my PABX,
>>> by using the ANSW mode in the M102.
>>> I have a proper 300bps link, hows "CONNECT" on the USrobotics, and i can
>>> see the characters I type on both sides.
>>> (it's not yet a real useful communication but the basics are there, from
>>> now on I can manage !)
>>>
>>> (So I wanted to explain all that in great details first in case it ever
>>> helps someone.)
>>>
>>> Then the question remains ; *why* did my original owner change the BIOS
>>> to use REX#
>>> Is that mandatory ? Wdyt Steve ?
>>> Is there a way I could put a "name" on my BIOSes (version, revision ? is
>>> there a place or a CALL where this shows up ?)
>>> What would happen if I put back the REX# with my current ("EU") BIOS ?
>>> Does anyone have any idea why the F1/F2 (CALL) functions in TELCO
>>> disappeared when I switched bios ?
>>>
>>> That's a lot of questions I know :)
>>>
>>> Le ven. 4 févr. 2022 à 12:04, Stephen Adolph a
>>> écrit :
>>>
>>>> Cedric, who did you buy it from? I can go through my emails to find
>>>> out the history.
>>>> Thx Steve
>>>>
>>>>>
>>>>
>>>>
Re: [M100] Tandy Model 100/102 modem pickup line
Hello Steve, Hello everyone
Thanks again really for taking the time... We all have lives and I really
appreciate.
I did some more research (isn't that what we all like in this hobby) and
here is what I came up with.
- I have for sure a Belgian, European, Model 102. no doubt about it.
- My little homemade PABX (phone exchange) is flawless, it works with other
modems of the era or plain analog phones.
- With a "US" BIOS (not sure which) and the REX#, the modem part is
completely broken. This is especially obvious if you hit F4 in TELCOM, the
M102 start to make awful noise (without cable, just on it's own!) and the
program seems crashed (needs reset/reboot).
>From there I tried;
- Removing the REX# (which I wouldn't have done without everyone's support
here) ; problem is the same
- Interestingly, "TERM" (F4) in TELCOM also still crashes !
Then obviously, what I tried;
- The seller did gave me my original BIOS, just marked "EU" (if I can give
you a version i'd gladly do it, I can also dump it if that's of any use the
the community)
Now... I guess I'm "stock" again.
This changes a lot of things.
The TELCO program changes a lot !
Interestingly, is has no more F1 or F2 features, F2 was called "CALL" (it
allowed me to do DTMF pulses), the feature is not there at all anymore (?!)
Hitting F4 (TERM) does not make any noise now, and does not crash.
I was able to make a link between my USR 56K and the M102, thru my PABX, by
using the ANSW mode in the M102.
I have a proper 300bps link, hows "CONNECT" on the USrobotics, and i can
see the characters I type on both sides.
(it's not yet a real useful communication but the basics are there, from
now on I can manage !)
(So I wanted to explain all that in great details first in case it ever
helps someone.)
Then the question remains ; *why* did my original owner change the BIOS to
use REX#
Is that mandatory ? Wdyt Steve ?
Is there a way I could put a "name" on my BIOSes (version, revision ? is
there a place or a CALL where this shows up ?)
What would happen if I put back the REX# with my current ("EU") BIOS ?
Does anyone have any idea why the F1/F2 (CALL) functions in TELCO
disappeared when I switched bios ?
That's a lot of questions I know :)
Le ven. 4 févr. 2022 à 12:04, Stephen Adolph a
écrit :
> Cedric, who did you buy it from? I can go through my emails to find out
> the history.
> Thx Steve
>
>>
>
>
Re: [M100] Tandy Model 100/102 modem pickup line
Thanks, i'll try all that. I must admit I don't fully understand what the REX# does, as I've only use it to make backups of the RAM, but it's features go way beyond that, so it's unclear to me if - for example - the tsdos that comes with would be "US minded". >From what I understand, the original owner (which may even be in this list) had to replace the belgian/european ROM with another ROM, most likely a US one, to be able to use the REX# ( that's what I got from what he told me, don't quote me on this ) All these changes could, maybe, break my modem. However i've been looking at the schematics of the modem part and all of this is as simple as can be, it's really purely analog in many areas, and there is no way on earth any of this is software controller. I mean : the thing doesn't care if the dial tone is 440, 600 Hz or anything (at least looking at the hardware I see no way this would be measured, even less handled by software) So if I take for granted my M102 is a Belgian.european one (it' has the sticker of the telco!), I guess the electronics where adapted to our particular voltages. What could be a possibility if that some of these are now out of spec One final comment ; if I hit F4 (TERM) in TELCOM, the M102 starts to emit an awful noise (like if it was connected to a data line !) it does that even when the M102 is not connected to anything ( I mean, no wire connected to it at all) It is also, afaics, completely crashed (i have to reset/reboot) Is that "normal" ? That would point to a problem with ROM/REX... thanks again for taking the time to help weirdo that wants his analog modem to work :) Le jeu. 3 févr. 2022 à 23:32, Brian K. White a écrit : > I can tell you one thing for sure, the REX has no effect on the modem. > > But you can prove that to yourself by just removing it. It doesn't hurt > anything and it won't even lose it's programming. Just pop it out, and > see that it made no difference. > > Have you tested the line with a plain analog telephone? > > Have you verified the modem cable doesn't have a broken wire? > > Since you are talking about dialing vs answering, is the the ANS-ORIG > switch in the ORIG position? (Answer vs Originate) > > Measure the voltage between tip & ring when the the modem is on-hook. It > should be 48vdc > > Measure the current on either tip or ring when the modem is off-hook. It > should be about 20ma, at around 9vdc (actually a wide range from 3 to 12) >
[M100] Tandy Model 100/102 modem pickup line
Hello everyone, I'm a new member, out of Belgium, I have a dozen of vintages PCs, I especially likes laptops. I'm an electronics engineer which helpes for fixing. Thanks for welcoming me and thanks to whoever created this in the first place. I'm trying to make the internal modem of my Tandy/RS Model 102 work again. I've connected it to a small home phone exchange (pabx) so that I have real proper vintage phone lines , but the same problem occurs on my home phone line (which is not PSTN anyway, it's an emulated analog line turn into voip by a modern cable modem router) I absolutely wanted to have my own "lab" of proper PSTN lines so that's why I have my little PABX from the 90s; which gives me the possiblity to experiment with modems. My problem is ; my model 102 does not pickup the line. A regular analog phone does, a good old USRobotics Courrier 56K does, but the T102 does not. I have the proper Tandy grey/beige(rather pink now) cable It's inserted in the right way. My init string (STAT) is starting with M, for internal modem If I put a phone on the gray line, and "pink" in the PABX ; i can hear my PABX's dial tone, until I make the M102 dial, in which case the phone goes silent (which is normal). But the PABX doesnt show the line as beeing picked up (a led should turn red), I can hear the M102 pulse dialing "in the void", but to no end... The PABX supports pulse dial. I tried 10pps and 20pps. But it seems the problem is not dialing, it's the actual, i'd say "electrical" pickup of the line. It seems either the voltages are not right, or something is not working like it should. I tried BASIC with "CALL 21200" (which pickups the lines) you can hear the relay click, but again, the PABX does not see that as someone picking up a phone. I have an European M102 (could that be an issue ?) My "phone line" (vintage PABX) is a european (belgian) one. However the M102 has been "upgraded" by a REX# v2.0 rom by the previous owner, that may be an issue (this upgrade was not my doing. I can barely use REX.) I'm with TSDOS101 It's unclear if, eventually, the modem section could need a repair (recap or smth) Another possilbity would be that the tone i'm giving it (440Hz over here) is not recognized (seems to be 600Hz in the US), but I find this unlikely this would be software controlled, and my M102 is a Belgian model it even has the "RTT" (telco of the time) sticker on it I'm out of ideas. Any help greatly appreciated
