Re: [M100] Low battery , crashes wipe the memory of both M102/M200
I have never experienced anything other than a corrupted file. I deleted and that was that. After finding out what caused it, I did not do it again. I suppose that depending on which point in a line it is not able to keep up with on-the-fly tokenization some interesting things might happen. The symptoms described by the OP, don’t match my experience with trying to load a .DO as a .BA. Other might have a different experience with this failure. Jeff Birt From: M100 On Behalf Of John R. Hogerhuis Sent: Monday, February 6, 2023 5:44 PM To: m...@bitchin100.com Subject: Re: [M100] Low battery , crashes wipe the memory of both M102/M200 On Mon, Feb 6, 2023 at 3:38 PM mailto:bir...@soigeneris.com> > wrote: Loading a .DO file which has been incorrectly named .BA won’t work correctly but it won’t hard reset the machine either. Not sure what you mean by "won't work correctly." Attempting to inload a BA named file that is not properly tokenized will corrupt the RAM filesystem pointers so it can absolutely result in a cold start. Not reliably which is in a way worse... because you can limp along not realizing that your file system is broken. Eventually it will either cold start or you will have to cold start it yourself to cure the dysfunction. -- John.
Re: [M100] Low battery , crashes wipe the memory of both M102/M200
The internal battery always preserves the ram contents as long as it's a working battery. Reset can happen fairly easily from crashing software, but it requires some sort of software error, IE either a bug in the software or a corrupt copy of the software from a bad serial transfer. Merely using the serial port, even with dead batteries that die right in the middle still doesn't cause a reset or lost data. Old caps can do it though because they make the entire machine generally unstable, resulting in random corrupt activity inside itself just for normally ordinary operations like just accessing rom or ram on the bus. That affects all things and could cause a reset at any random time not just during serial port usage, but one thing I think the serial port does different from most other things is draw a little from the negative power rail, so maybe VEE is weak and marginal, good enough to keep the machine running most of the time but the serial port just pushes it over the edge? But it's definitely a thing that happens from software and not normally, just from a bug or corrupt copy, so suspect all software that hasn't been proven by decades of use already, and that does include REXMGR if it's not an old proven version. I believe REXMGR installs timer interrupt code that runs all the time even when you aren't in REXMGR. I might be wrong about that, Steve would have to say. To diagnose, just remove the REX# entirely, reset, load a known-good copy of TS-DOS in ram and just do a bunch of transfers. Or even better do a bunch of plain TELCOM traffic with no other software at all installed. Normally, even trying to overload the machine by using too-high of baud rate that it can't keep up with, and pasting a 100K text file into the terminal on the pc side etc, doesn't cause it to crash or reset reset, you just collect a bunch of corrupt data until ram fills up, but still no crash or reset. Then only proceed from there. If that still crashes, then you have a hardware problem. If it doesn't then add one variable back in, like install the REX# physically but don't install it's software yet (don't call 63012), and test again like that. Then install REXMGR and test again. If it doesn't fail until after installing REXMGR, try flashing the REX# back to an older version of it's firmware. If it never fails again, only *then* try using whatever other software you were trying to use originally (whatever that was, since you didn't say, ts-dos? telcom? rexmgr loading rom images or backups? some other unknown serial-port-using app?) But you'll have to go methodically from the ground up like that if you ever want to figure it out. Start with nothing but the stock machine, and then add a single variable at a time back into the mix. -- bkw On 2/6/23 12:38, Cedric Amand wrote: 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. -- bkw
Re: [M100] Odd NEC PC-8201A 'ROM"
Ah, it is interesting to know how the dongle was used. I have never seen a cartridge for the NEC machines, is it basically a box with a connector and ROM? Jeff Birt From: M100 On Behalf Of Gary Weber Sent: Sunday, February 5, 2023 6:10 PM To: m...@bitchin100.com Subject: Re: [M100] Odd NEC PC-8201A 'ROM" Hi Jeff, At some point in the past I ended up with an NEC PC-8201A that had that same Met Life dongle as well as a plug-in cartridge which actually had their insurance agent software on it. It takes over the machine entirely when you have that cartridge plugged in, you don't have any access to the NEC operating system itself. I'd never taken apart that EPROM-looking dongle thing myself, so thanks for solving that mystery. At this point I'm left to assume that there's a value that is read from it in some way due to that diode, and that if the dongle is missing, the cartridge refuses to run. Probably a means of "security" although if someone had access to a Met Life insurance agent's NEC computer back in the day you would think they'd also unscrew the bottom panel and take the dongle if they were "in the know". Security by obfuscation? Anyway I still have the dongle and the cartridge somewhere... Gary Weber Web 8201 On Sun, Jan 22, 2023 at 1:09 PM mailto:bir...@soigeneris.com> > wrote: Hi all, I forgot to post this here yesterday. I did a video covering a NEC PC-8201A refurb I did after letting the machine sit partially disassembled for two years. The most interesting thing though was an odd option ROM. I won’t spoil the surprise but so far nobody has seen one like it. https://youtu.be/KFTDzwjdYMI Jeff Birt (Hey Birt!)
Re: [M100] Low battery , crashes wipe the memory of both M102/M200
In my case, the driver transistor for the relay actually failed short. I replaced it and the problem went away. On a diode test the failed part was happily conductive regardless of what I put on the gate, lol. On Mon, Feb 6, 2023, 18:40 wrote: > The click you hear is the telco relay. The flux around the driver > transistor can turn conductive enough to trigger the transistor and thus > the relay. I have also seen this cause reset issues and other oddities on > the M100. > > > > Jeff Birt > > > > *From:* M100 *On Behalf Of *Alex ... > *Sent:* Monday, February 6, 2023 2:39 PM > *To:* m...@bitchin100.com > *Subject:* Re: [M100] Low battery , crashes wipe the memory of both > M102/M200 > > > > A particularly nasty crash can make it do that cold-reset thing. I ran > into that countless times while trying my hand at assembly development > while using ROM2 and MFORTH. in that case the problem isn't that the memory > is totally erased but that some important part gets corrupted and the stock > ROM starts over from scratch. I couldn't tell you for sure what or how it > happens, but it can. > > Not necessarily the same as what you saw but I had an issue with my T102 > that caused low voltages and battery drain due to the cassette remote being > stuck on. The give-away for that case was if I carefully put the batteries > in, I could hear the relay click on and stay on, regardless of the state of > the on/off switch. It might be worth putting the machine on an ammeter and > see if it's pulling some excess current if your batteries seem to not last > as long as they should. > > >
[M100] Mcomm and bbs
I've been asleep at the wheel.. I totally missed that Mcomm provides a very good serial to IP modem function! Once I realized this, I was online in an instant with my T102 at Greg's the keep.net BBS. Even more fun I was in 80x25 mode with the MVT100 adapter. It was so quick and easy! Worked great! ..Steve
Re: [M100] Low battery , crashes wipe the memory of both M102/M200
On Mon, Feb 6, 2023 at 3:38 PM wrote: > Loading a .DO file which has been incorrectly named .BA won’t work > correctly but it won’t hard reset the machine either. > > > > > Not sure what you mean by "won't work correctly." Attempting to inload a BA named file that is not properly tokenized will corrupt the RAM filesystem pointers so it can absolutely result in a cold start. Not reliably which is in a way worse... because you can limp along not realizing that your file system is broken. Eventually it will either cold start or you will have to cold start it yourself to cure the dysfunction. -- John.
Re: [M100] Low battery , crashes wipe the memory of both M102/M200
The click you hear is the telco relay. The flux around the driver transistor can turn conductive enough to trigger the transistor and thus the relay. I have also seen this cause reset issues and other oddities on the M100. Jeff Birt From: M100 On Behalf Of Alex ... Sent: Monday, February 6, 2023 2:39 PM To: m...@bitchin100.com Subject: Re: [M100] Low battery , crashes wipe the memory of both M102/M200 A particularly nasty crash can make it do that cold-reset thing. I ran into that countless times while trying my hand at assembly development while using ROM2 and MFORTH. in that case the problem isn't that the memory is totally erased but that some important part gets corrupted and the stock ROM starts over from scratch. I couldn't tell you for sure what or how it happens, but it can. Not necessarily the same as what you saw but I had an issue with my T102 that caused low voltages and battery drain due to the cassette remote being stuck on. The give-away for that case was if I carefully put the batteries in, I could hear the relay click on and stay on, regardless of the state of the on/off switch. It might be worth putting the machine on an ammeter and see if it's pulling some excess current if your batteries seem to not last as long as they should.
Re: [M100] Low battery , crashes wipe the memory of both M102/M200
Loading a .DO file which has been incorrectly named .BA won’t work correctly but it won’t hard reset the machine either. Jeff Birt From: M100 On Behalf Of John R. Hogerhuis Sent: Monday, February 6, 2023 3:21 PM To: m...@bitchin100.com Subject: Re: [M100] Low battery , crashes wipe the memory of both M102/M200 TS-DOS? The only problem I know that causes corruption with TS-DOS is mistakenly trying to inload a file named with a BA extension that's not really a tokenized BASIC file. You should always rename ASCII BASIC files as .DO before inloading. You can inload a .BA file, but it must actually be tokenized BASIC. What file service software or device are you using? LaddieAlpha doesn't have this sharp edge but all others do. -- John.
Re: [M100] Recommendation for T200 clip on led light?
Thanks Peter, I was noticing that a lot of those clip on lights may not be able to grab the T200 Properly.. >> On Monday, February 6, 2023, Peter Noeth wrote: > > Steve, > > >> I purchased a clip-on book light at Barnes & Noble (Mighty Bright >> https://mightybright.com) for use on my Nook eBook which worked well for >> that. It is similar to the current ""WonderFlex rechargeable" clip on >> light, but mine uses 2 CR2032 coin cells. > > >> Some months year later I thought it would work nicely for my T102 when >> using it in dim indoor lighting, but the built-in spring clip would only >> attach well to something no thicker than 1/4". So I took it apart and >> dispensed with the original clip/battery holder and attached the goose neck >> to the top face of a 25pin D-sub connector shell and put the batteries >> inside. The shell also has a 25pin connector that doesn't connect to >> anything, but facilitates connecting the unit to the T102. The single LED >> is not so bright to get a lot of annoying reflection from the computer's >> display, but lights up the keyboard nicely. > > >> I preserved the light's original external power connection (which is >> accessed through the D-sub shell's cable exit hole, so it could be powered >> externally, or in the case of a rechargeable light, re-charged. Just >> precludes any other use of the serial port. I suppose one could use a 9pin >> D-sub connector, and connect to the barcode jack and get power from the >> computer as well, but I think that could hamper "touch typing" more being >> so close to the left hand. > > >> Some starting point idea, nice and compact to go in your computer bag >> when not being used. > > >> Regards, > > >> PeterN > > -- > > >> Message: 3 > > Date: Mon, 6 Feb 2023 12:22:21 -0500 > > From: Stephen Adolph > > To: m...@bitchin100.com > > Subject: [M100] Recommendation for T200 clip on led light? > > Message-ID: > > > uimntz5f6-ormejfwxr7pmr...@mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > >> Hi, does anyone have a good recommendation for a clip on T200 LED? > > Thanks Steve > > >> >> >>
Re: [M100] M100 LCD repair video and alternative use for unused screen RAM
" I am still alive and well, not that anyone seemed overly concerned there" Great to hear that you're well George! For my part I don't automatically raise the alarm bells when a member goes quiet for a while... people do come and go and sometimes gafiate. It happens. Glad to see some updates to Text Sweeper, I still play it now and then. It's a great program (with or without asciipixels integration) and I'll definitely check out your new version. -- John.
Re: [M100] M100 LCD repair video and alternative use for unused screen RAM
Hi all, I did just see this thread, and I want to provide a few updates. 1. I am still alive and well, not that anyone seemed overly concerned there :D 2. My website is down because I accidentally kicked out the network cable for my raspberry pi, and I didn't notice. I will be fixing this shortly. 3. I have been diligently working on Text Sweeper for the last week, and I have some updates to share. Updates coming soon. 1. I started managing the codebase through a Private git repository. I will opt to just make this Public for posterity's sake when I release the next updated version. 2. I have removed the AsciiPixels integration. While it was nifty, I think it went against the spirit of the game, which was intended to be an entirely text-based Minesweeper clone. 3. I have modified a significant amount of the codebase. I have rewritten a large portion of the mine generation, and some of the other common subroutines. 1. Mine generation algorithms used to be naive. I would pick a spot to put the mine, check if it isn't within the initial 3x3 area of the first click, and check if it wasn't already a mine. 1. This has a theoretically infinite upper bound, as RND could generate invalid spaces forever. This is noticeably slow when running denser minefields 2. I replaced it with an algorithm that will always select a space that is valid. 1. Accomplished by generating the array of all spaces upfront.(done in ML for performance reasons) And then removing the 4-9 invalid spaces around X,Y 2. After selecting a space, it's value will be set to -1 in the initial array 3. Next, I use RND to generate a value(I%) between 0 and 256-SpacedAlreadySelected 4. Finally, I loop over the spaces in the array, and increment the array index(I%) for each -1 in the array. This yields a new I%, which is the Nth non-negative position in the array. (done in ML for performance) 3. This means that each loop in BASIC generates a valid position, and the loop runs MN% number of times, where MN% is the number of mines we have to generate. Previously, it would run anywhere from MN% to infinity. 2. Mine adjacency counts were done at the time of checking the cell. I moved this to happen immediately after the generation of the minefield. I also have an ML routine that generates the upper and lower bounds for checking a cell. 3. Using that same ML routine as above, to generate the bounds when checking the mines. 1. So far there is about a 20-30% measured improvement on the mine checking of the first move. (benchmarked using a 100 count minefield) 4. I replaced most of the GOTOs with FOR loops where applicable. 5. Refactored a lot of the code to just remove duplication where unneeded. 6. The way I inserted ML into the program. 1. I dimensioned INT arrays for each subroutine. 2. I poked in my code from Data Statements. 3. I limited absolute addressing and jumps as much as possible. 1. In the case where I need to do JMP operations, I have BASIC modify the ML addresses prior to execution. 4. I'm not an expert, but as I understand it, this should mean that the ML code won't conflict with any other programs in memory, as long as you have the free space for BASIC to DIM the arrays. If not, it will fail safely. 4. Flagged mines must be unflagged before selecting them. Prevents accidentally setting off a flagged mine. 5. Other features I want to add: 1. Selecting a space where the Number in the cell == Flags in surrounding cells will open all adjacent cells. This is a common feature in other versions. 2. Additional controls for L/R/U/D. I developed this mostly using VirtualT to test. The arrow keys kind of stink as the interface on an actual M100. 3. Rewrite some additional pieces in ML if possible, to improve the speed at which means are revealed. This part is slow and makes the game less fun. 4. Add some instructions into the game itself. After all this is complete, I will make the github public, which will include the assembly code as well. Please let me know your feedback on any of the above, and if you have any suggestions. Please bear with me, I just taught myself assembly over the weekend so it's been a bit of a trial by fire. :D Best, George On Wed, Jul 6, 2022 at 7:17 PM Ken Pettit wrote: > Hi All, > > Sorry, didn't reply to this for quite some time ... the family caught > Covid-19 last week and I was still recovering (I was taking care of > everyone and then was the last to get it). > > I will look into my T200 AciiPixels implementation to see if I ever (or > can still) get
Re: [M100] Recommendation for T200 clip on led light?
Steve, I purchased a clip-on book light at Barnes & Noble (Mighty Bright https://mightybright.com) for use on my Nook eBook which worked well for that. It is similar to the current ""WonderFlex rechargeable" clip on light, but mine uses 2 CR2032 coin cells. Some months year later I thought it would work nicely for my T102 when using it in dim indoor lighting, but the built-in spring clip would only attach well to something no thicker than 1/4". So I took it apart and dispensed with the original clip/battery holder and attached the goose neck to the top face of a 25pin D-sub connector shell and put the batteries inside. The shell also has a 25pin connector that doesn't connect to anything, but facilitates connecting the unit to the T102. The single LED is not so bright to get a lot of annoying reflection from the computer's display, but lights up the keyboard nicely. I preserved the light's original external power connection (which is accessed through the D-sub shell's cable exit hole, so it could be powered externally, or in the case of a rechargeable light, re-charged. Just precludes any other use of the serial port. I suppose one could use a 9pin D-sub connector, and connect to the barcode jack and get power from the computer as well, but I think that could hamper "touch typing" more being so close to the left hand. Some starting point idea, nice and compact to go in your computer bag when not being used. Regards, PeterN > -- > > Message: 3 > Date: Mon, 6 Feb 2023 12:22:21 -0500 > From: Stephen Adolph > To: m...@bitchin100.com > Subject: [M100] Recommendation for T200 clip on led light? > Message-ID: > uimntz5f6-ormejfwxr7pmr...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, does anyone have a good recommendation for a clip on T200 LED? > Thanks Steve > >
Re: [M100] surface
LaddieAlpha is uses the .NET framework runtime so I assume it works. But confirmation would be good. -- John. On Mon, Feb 6, 2023, 1:30 PM Peter Vollan wrote: > Can I emulate a TPDD with my Microsoft Surface Pro? > >
Re: [M100] surface
would assume it would run mcomm or the python tpdd On Mon, Feb 6, 2023 at 1:30 PM Peter Vollan wrote: > Can I emulate a TPDD with my Microsoft Surface Pro? > >
[M100] Beta testers for R2.2 for REX# and REXCPM?
If anyone is interested in testing out R2.2 prior to release, let me know please. I can send the files needed to upgrade the software. Suitable for REX# and REXCPM. Thanks Steve
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
Although not having seen this ever crash my T102, I did notice that having my Seiko DP-414 printer connected, but turned off, causes an increase in current draw on the T102 (likely on the M100 as well). Several 10s of milliamps if I recall correctly. Does cause the red LED to come on if batteries are low. If the printer is powered on, then no increase in current draw is noticed. This might vary depending on the brand of printer used. Regards, PeterN > >
[M100] surface
Can I emulate a TPDD with my Microsoft Surface Pro?
Re: [M100] Low battery , crashes wipe the memory of both M102/M200
TS-DOS? The only problem I know that causes corruption with TS-DOS is mistakenly trying to inload a file named with a BA extension that's not really a tokenized BASIC file. You should always rename ASCII BASIC files as .DO before inloading. You can inload a .BA file, but it must actually be tokenized BASIC. What file service software or device are you using? LaddieAlpha doesn't have this sharp edge but all others do. -- John. On Mon, Feb 6, 2023 at 1:15 PM Cedric Amand wrote: > 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
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
A particularly nasty crash can make it do that cold-reset thing. I ran into that countless times while trying my hand at assembly development while using ROM2 and MFORTH. in that case the problem isn't that the memory is totally erased but that some important part gets corrupted and the stock ROM starts over from scratch. I couldn't tell you for sure what or how it happens, but it can. Not necessarily the same as what you saw but I had an issue with my T102 that caused low voltages and battery drain due to the cassette remote being stuck on. The give-away for that case was if I carefully put the batteries in, I could hear the relay click on and stay on, regardless of the state of the on/off switch. It might be worth putting the machine on an ammeter and see if it's pulling some excess current if your batteries seem to not last as long as they should. On Mon, Feb 6, 2023 at 2:30 PM Cedric Amand wrote: > 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 :) > > -- Disclaimer: Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is non-deterministic. The question of the existence of views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal, non-integral polytheism is beyond the scope of this article.) Thanks /usr/games/fortune
Re: [M100] Low battery , crashes wipe the memory of both M102/M200
> > > When you say a Save operation, do you mean write to laptop ram or write to external? You are getting a cold restart for sure. That is the result. What causes a cold restart? Memory corruption, specific bytes in upper ram. When the computer does a restart from instruction , it will eventually look at a specific byte to decide.. warm reboot or cold reboot? So something is causing the machine to reboot and when it does, it is a cold reboot. What software is in use? TELCOM? TSDOS? If you could describe a sequence of failure that would help. > > On Monday, February 6, 2023, Cedric Amand wrote: 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 :) >
Re: [M100] Low battery , crashes wipe the memory of both M102/M200
One other thought I just had. Then testing Backpacks I use a REX Classic mainly for TS-DOS. I have noticed that if I’m typing along too quickly in the TS-DOS menus it will lock up as you describe. To prevent this, I wait until the screen is finished rendering before pressing the next button. For example, if I just pressed F4 to switch from DISK to RAM view I need to wait until the screen is done rendering. It seems if you press a key at just the right time while TS-DOS is redrawing the menu something odd happens. Sometimes is seems like a key code is caught in the input buffer and keeps getting acted on over and over and over. I have attributed this to an oddity of TS-DOS that most people won’t come across as they are not trying to test a bunch of TPDD type drives in one setting. If you are just using it to load or save a file on occasion, I would guess you will never see it. Jeff Birt From: M100 On Behalf Of Cedric Amand Sent: Monday, February 6, 2023 11:39 AM To: m...@bitchin100.com Subject: [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] Low battery , crashes wipe the memory of both M102/M200
I suspect the RAM is not wiped. The machine is just hard reset, and all relevant pointers set back to defaults. Your data is likely still in RAM you just can’t see it. Jeff Birt From: M100 On Behalf Of Cedric Amand Sent: Monday, February 6, 2023 12:50 PM To: m...@bitchin100.com Subject: 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 :)
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 :)
Re: [M100] Low battery , crashes wipe the memory of both M102/M200
> > Hi Cedric, If you can, please try to replicate the problem without a REX# involved. Maybe I missed something with R2.2. Rs232 does load up the lower supply a bit. There could be a problem with that aspect, but it should be the same with or without rex. Thanks Steve > On Monday, February 6, 2023, Cedric Amand wrote: 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] Low battery , crashes wipe the memory of both M102/M200
It's not normal at all. The backup battery should absolutely protect the RAM even if the main batteries are dead. Do you know if the backup battery is getting charged? And I guess the memory power switch must be on since I don't think it works with it off. I guess you would need to remove main batteries, all cables and see if the RAM is still getting sufficient power. As to the serial port, yes when it's active it does cause additional power drain. -- John. >
[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.
[M100] Recommendation for T200 clip on led light?
Hi, does anyone have a good recommendation for a clip on T200 LED? Thanks Steve
