Re: [M100] R2.2 update for REX# and REXCPM
hello, just an FYI, I have RAM Write Protect implemented now in REX# 2.2. Seems to work well, will be testing it out. * in RAM tab in REXMGR, "W" toggles the write protect status of a RAM image * write protect ON is indicated by "!" ex. "RAMIMG !" would indicate this image is write protect * any ram image under the cursor can have write protect status toggled. * Quick menu CNTL-B: if the ACTIVE RAM image is write protected, then don't allow the backup to proceed * REXMGR: hitting ENTER over the ACTIVE RAM image prevents backup when write protected if the user attempts to refresh the ACTIVE RAM image * REXMGR: hitting ENTER over the non-ACTIVE RAM image prevents backup when write protected if the user attempts to refresh the ACTIVE RAM image On Mon, Jan 30, 2023 at 9:28 PM Stephen Adolph wrote: > >> Yah, that is the issue. I did that recently too! > > Well the change now is that you have to choose to refresh the backup. If >> not, you skip the write into the active ram , before you select and load up >> a different image. > > > There was no way directly to load up a saved ram image that was not the > active ram, without overwriting the active ram. The only work around would > be to make a copy of the active ram before you switched. Bit of a pain. > > Cntl-b and cntl-r are unchanged... but they are not the issue... ;) > > Cntl-n and cntl-k are nice adds IMHO. Nice to be able to change a > filename or kill a file from menu. > > Write protect doesn't make sense for the active ram image. But perhaps it > is just an override. So if we is on, any write attempt is skipped. > > >> >> > > >> On Monday, January 30, 2023, Josh Malone wrote: > > On Mon, Jan 30, 2023 at 9:03 PM Stephen Adolph >> wrote: > > Brian, > > Great suggestion on read only. That's a cool idea. > > >> This feature would make me throw out all my Classics immediately and >> replace them with #s. I can't tell how many times I've booted a blank M100, >> gone to restore a RAM image, and overwritten some other image with my blank >> RAM when it "switches" to the image I'm trying to load. > > > > -Josh > > >> >> >> >>
Re: [M100] R2.2 update for REX# and REXCPM
Many computers including the M100 use the unique American standard MM/DD/YY while most of the world uses DD/MM/YY; apparently a few countries like Iran, China etc. use the international (SA) standard /MM/DD. In Canada most folks use the American MM/DD/YY; just to keep it interesting my driver's licence uses /MM/DD while some banks use DD/MM/. FWIW, personally I use MM/DD/YY and agree that using the same format as the system is probably the least confusing. Assuming that international versions of the M100 also use MM/DD/YY, presumably folks in Europe and elsewhere have already gotten used to the DATE$ format. m - Original Message - From: To: Sent: Tuesday, January 31, 2023 10:35 AM Subject: Re: [M100] R2.2 update for REX# and REXCPM I agree with Brian, consistency with the system that can't be changed is probably the best. At least there is consistency (even if it is confusing to someone used to MMDD). Jonathan >Original Message >From : b.kenyo...@gmail.com >Date : 2023-01-31 - 10:41 (CEST) >To : m100@lists.bitchin100.com >Subject : Re: [M100] R2.2 update for REX# and REXCPM > >Cosistency with the rest of the system which can't be changed is >definitely a legit point. Thanks for clarifying. > >-- >bkw > >On 1/31/23 03:03, Cedric Amand wrote: >> 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 >> > >-- >bkw > >
Re: [M100] R2.2 update for REX# and REXCPM
I agree with Brian, consistency with the system that can't be changed is probably the best. At least there is consistency (even if it is confusing to someone used to MMDD). Jonathan >Original Message >From : b.kenyo...@gmail.com >Date : 2023-01-31 - 10:41 (CEST) >To : m100@lists.bitchin100.com >Subject : Re: [M100] R2.2 update for REX# and REXCPM > >Cosistency with the rest of the system which can't be changed is >definitely a legit point. Thanks for clarifying. > >-- >bkw > >On 1/31/23 03:03, Cedric Amand wrote: >> 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 >> > >-- >bkw > >
Re: [M100] R2.2 update for REX# and REXCPM
Cosistency with the rest of the system which can't be changed is definitely a legit point. Thanks for clarifying. -- bkw On 1/31/23 03:03, Cedric Amand wrote: 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 -- bkw
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] R2.2 update for REX# and REXCPM
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 https://en.wikipedia.org/wiki/ISO_8601 Jonathan >Original Message >From : b.kenyo...@gmail.com >Date : 2023-01-31 - 02:26 (CEST) >To : m100@lists.bitchin100.com >Subject : Re: [M100] R2.2 update for REX# and REXCPM > >That is a great set of updates. >Personally I prefer year-first dates so don't assume the illogical way >was was a universal preference ;) > >But it's a small thing that I also don't think it's worth making >configurable. I would have told anyone who cared enough to ask for it to >be changed, to get over it and find something more important to worry >aboiut. But likewise, I am saying that for myself now that it's the >"wrong" way. > >Auto-updating the current ram image before loading a different one >sounds like one of those tiny things that makes a big difference. >Probably very little code to do it, but it makes a whole different >convenient usage pattern like keeping a bunch of live ram banks rather >than a bunch of backups. > >And yet they can still be used as backups & references too, just answer >no to update. > >Maybe a complementary feature should go along with auto-saving backups, >which would be the ability to mark an image read-only, so that you can >protect images from accidentally being modified. It sounds like the way >the auto backup is done is probably a question that gets asked every >time rather than really automatic, but still once that convenience >exists, it trains the user to answer quickly by habit, and so the safety >lock option would complement and counter that. Or maybe instead of a >read-only flag, it's an auto-save flag. For marked images, they always >auto-save on exit, and unmarked images don't. Maybe a single flag if >it's more than one bit could indicate a few different possible states: >auto-save never/always/ask, read-only y/n. > >Just thinking out loud. > >-- >bkw > >On 1/30/23 18:19, Stephen Adolph wrote: >> I'm most of the way through testing a bug fix release for REX# and REXCPM. >> Current load is R2.1 build 19. >> >> New load is R2.2. Here's the list of changes (see below). >> I'll post the upgrade files to the wiki when I am happy it is all >> looking good! >> cheers >> Steve >> >> >> Bugs >> >>Rel 2.1: All: Fix the date display. Now it is YY/MM/DD. Request is to >> change to DD/MM/20YY. Seems reasonable. >>Maybe a date format toggle control? "D" in REXMGR menu. >>Coded R2.2 / Tested >> >>Rel 2.1: M100/T102: Make display tolerant to "hardware scrolling main >> ROM". >>Coded R2.2/ Tested >> >>Rel 2.1: Interworking with actual TPDD does not work. Fix pending. >>Coded R2.2 / Tested >> >>Rel 2.1: NEC: noticed that, with only one RAM bank installed, pressing >> TAB or BANK causes laptop to hang in MENU. >>This should not happen. Probably affects T200 as well. Yes it did. >>Coded R2.2 / Tested >> >>Rel 2.1: All: Reduce time on power up before option rom is switched, to >> prevent undesired uninstall of option rom. >>Coded R2.2 / Tested >> >>Rel 2.1: T200: UR-2 support seems like it is broken. >>Major defect discovered, coding error on my part. Fixed. >>Coded R2.2 / tested >> >> >> Feature Requests >> >>Rel 2.1: Request to put an "Overwrite?" option to allow images to be >> saved when one exists already. Great idea! >>Coded R2.2 / Tested >> >>Rel 2.1: All: when switching RAMs, give option to re-save current RAM >> or not. >>Coded R2.2 / Tested >> >>Rel 2.1: M100: add quickmenu command to reNAME or KILL a file in MENU. >> T200: add quickmenu command to NAME a file in MENU. >>Coded R2.2 / Tested >> >>Rel 2.1: All: Allow use to de-install the active ROM, leaving no ROM >> active. F6. >>Coded R2.2 / Tested >> > >-- >bkw > >
Re: [M100] R2.2 update for REX# and REXCPM
> > > Yah, that is the issue. I did that recently too! Well the change now is that you have to choose to refresh the backup. If > not, you skip the write into the active ram , before you select and load up > a different image. There was no way directly to load up a saved ram image that was not the active ram, without overwriting the active ram. The only work around would be to make a copy of the active ram before you switched. Bit of a pain. Cntl-b and cntl-r are unchanged... but they are not the issue... ;) Cntl-n and cntl-k are nice adds IMHO. Nice to be able to change a filename or kill a file from menu. Write protect doesn't make sense for the active ram image. But perhaps it is just an override. So if we is on, any write attempt is skipped. > > > On Monday, January 30, 2023, Josh Malone wrote: On Mon, Jan 30, 2023 at 9:03 PM Stephen Adolph wrote: Brian, Great suggestion on read only. That's a cool idea. > This feature would make me throw out all my Classics immediately and > replace them with #s. I can't tell how many times I've booted a blank M100, > gone to restore a RAM image, and overwritten some other image with my blank > RAM when it "switches" to the image I'm trying to load. -Josh > > > >
Re: [M100] R2.2 update for REX# and REXCPM
On Mon, Jan 30, 2023 at 9:03 PM Stephen Adolph wrote: > Brian, > Great suggestion on read only. That's a cool idea. > This feature would make me throw out all my Classics immediately and replace them with #s. I can't tell how many times I've booted a blank M100, gone to restore a RAM image, and overwritten some other image with my blank RAM when it "switches" to the image I'm trying to load. -Josh
Re: [M100] R2.2 update for REX# and REXCPM
> > > Brian, Great suggestion on read only. That's a cool idea. I'm actually daydreaming about something a step further, too. Thinking about a way to be able to save files directly into an image. Getting away from the ram image concept would allow that. To keep a ram image intact, it is really hard to deal with the file system pointers. But if you just want to store a file, much simpler. In that way an image could be read write like a "disk". If I can figure out a quick way for write protect I may include in 2.2. Cheers Steve > > On Monday, January 30, 2023, Brian K. White wrote: That is a great set of updates. Personally I prefer year-first dates so don't assume the illogical way was > was a universal preference ;) > But it's a small thing that I also don't think it's worth making > configurable. I would have told anyone who cared enough to ask for it to be > changed, to get over it and find something more important to worry aboiut. > But likewise, I am saying that for myself now that it's the "wrong" way. > Auto-updating the current ram image before loading a different one sounds > like one of those tiny things that makes a big difference. Probably very > little code to do it, but it makes a whole different convenient usage > pattern like keeping a bunch of live ram banks rather than a bunch of > backups. > And yet they can still be used as backups & references too, just answer no > to update. > Maybe a complementary feature should go along with auto-saving backups, > which would be the ability to mark an image read-only, so that you can > protect images from accidentally being modified. It sounds like the way the > auto backup is done is probably a question that gets asked every time > rather than really automatic, but still once that convenience exists, it > trains the user to answer quickly by habit, and so the safety lock option > would complement and counter that. Or maybe instead of a read-only flag, > it's an auto-save flag. For marked images, they always auto-save on exit, > and unmarked images don't. Maybe a single flag if it's more than one bit > could indicate a few different possible states: auto-save never/always/ask, > read-only y/n. > Just thinking out loud. > -- bkw > On 1/30/23 18:19, Stephen Adolph wrote: I'm most of the way through testing a bug fix release for REX# and REXCPM. Current load is R2.1 build 19. > New load is R2.2. Here's the list of changes (see below). I'll post the upgrade files to the wiki when I am happy it is all looking > good! cheers Steve > > Bugs >Rel 2.1: All: Fix the date display. Now it is YY/MM/DD. Request is to > change to DD/MM/20YY. Seems reasonable. Maybe a date format toggle control? "D" in REXMGR menu. Coded R2.2 / Tested >Rel 2.1: M100/T102: Make display tolerant to "hardware scrolling main > ROM". Coded R2.2/ Tested >Rel 2.1: Interworking with actual TPDD does not work. Fix pending. Coded R2.2 / Tested >Rel 2.1: NEC: noticed that, with only one RAM bank installed, pressing > TAB or BANK causes laptop to hang in MENU. This should not happen. Probably affects T200 as well. Yes it did. Coded R2.2 / Tested >Rel 2.1: All: Reduce time on power up before option rom is switched, to > prevent undesired uninstall of option rom. Coded R2.2 / Tested >Rel 2.1: T200: UR-2 support seems like it is broken. Major defect discovered, coding error on my part. Fixed. Coded R2.2 / tested > > Feature Requests >Rel 2.1: Request to put an "Overwrite?" option to allow images to be > saved when one exists already. Great idea! Coded R2.2 / Tested >Rel 2.1: All: when switching RAMs, give option to re-save current RAM > or not. Coded R2.2 / Tested >Rel 2.1: M100: add quickmenu command to reNAME or KILL a file in MENU. > T200: add quickmenu command to NAME a file in MENU. Coded R2.2 / Tested >Rel 2.1: All: Allow use to de-install the active ROM, leaving no ROM > active. F6. Coded R2.2 / Tested > > > bkw > > > >
Re: [M100] R2.2 update for REX# and REXCPM
That is a great set of updates. Personally I prefer year-first dates so don't assume the illogical way was was a universal preference ;) But it's a small thing that I also don't think it's worth making configurable. I would have told anyone who cared enough to ask for it to be changed, to get over it and find something more important to worry aboiut. But likewise, I am saying that for myself now that it's the "wrong" way. Auto-updating the current ram image before loading a different one sounds like one of those tiny things that makes a big difference. Probably very little code to do it, but it makes a whole different convenient usage pattern like keeping a bunch of live ram banks rather than a bunch of backups. And yet they can still be used as backups & references too, just answer no to update. Maybe a complementary feature should go along with auto-saving backups, which would be the ability to mark an image read-only, so that you can protect images from accidentally being modified. It sounds like the way the auto backup is done is probably a question that gets asked every time rather than really automatic, but still once that convenience exists, it trains the user to answer quickly by habit, and so the safety lock option would complement and counter that. Or maybe instead of a read-only flag, it's an auto-save flag. For marked images, they always auto-save on exit, and unmarked images don't. Maybe a single flag if it's more than one bit could indicate a few different possible states: auto-save never/always/ask, read-only y/n. Just thinking out loud. -- bkw On 1/30/23 18:19, Stephen Adolph wrote: I'm most of the way through testing a bug fix release for REX# and REXCPM. Current load is R2.1 build 19. New load is R2.2. Here's the list of changes (see below). I'll post the upgrade files to the wiki when I am happy it is all looking good! cheers Steve Bugs Rel 2.1: All: Fix the date display. Now it is YY/MM/DD. Request is to change to DD/MM/20YY. Seems reasonable. Maybe a date format toggle control? "D" in REXMGR menu. Coded R2.2 / Tested Rel 2.1: M100/T102: Make display tolerant to "hardware scrolling main ROM". Coded R2.2/ Tested Rel 2.1: Interworking with actual TPDD does not work. Fix pending. Coded R2.2 / Tested Rel 2.1: NEC: noticed that, with only one RAM bank installed, pressing TAB or BANK causes laptop to hang in MENU. This should not happen. Probably affects T200 as well. Yes it did. Coded R2.2 / Tested Rel 2.1: All: Reduce time on power up before option rom is switched, to prevent undesired uninstall of option rom. Coded R2.2 / Tested Rel 2.1: T200: UR-2 support seems like it is broken. Major defect discovered, coding error on my part. Fixed. Coded R2.2 / tested Feature Requests Rel 2.1: Request to put an "Overwrite?" option to allow images to be saved when one exists already. Great idea! Coded R2.2 / Tested Rel 2.1: All: when switching RAMs, give option to re-save current RAM or not. Coded R2.2 / Tested Rel 2.1: M100: add quickmenu command to reNAME or KILL a file in MENU. T200: add quickmenu command to NAME a file in MENU. Coded R2.2 / Tested Rel 2.1: All: Allow use to de-install the active ROM, leaving no ROM active. F6. Coded R2.2 / Tested -- bkw
[M100] R2.2 update for REX# and REXCPM
I'm most of the way through testing a bug fix release for REX# and REXCPM. Current load is R2.1 build 19. New load is R2.2. Here's the list of changes (see below). I'll post the upgrade files to the wiki when I am happy it is all looking good! cheers Steve Bugs Rel 2.1: All: Fix the date display. Now it is YY/MM/DD. Request is to change to DD/MM/20YY. Seems reasonable. Maybe a date format toggle control? "D" in REXMGR menu. Coded R2.2 / Tested Rel 2.1: M100/T102: Make display tolerant to "hardware scrolling main ROM". Coded R2.2/ Tested Rel 2.1: Interworking with actual TPDD does not work. Fix pending. Coded R2.2 / Tested Rel 2.1: NEC: noticed that, with only one RAM bank installed, pressing TAB or BANK causes laptop to hang in MENU. This should not happen. Probably affects T200 as well. Yes it did. Coded R2.2 / Tested Rel 2.1: All: Reduce time on power up before option rom is switched, to prevent undesired uninstall of option rom. Coded R2.2 / Tested Rel 2.1: T200: UR-2 support seems like it is broken. Major defect discovered, coding error on my part. Fixed. Coded R2.2 / tested Feature Requests Rel 2.1: Request to put an "Overwrite?" option to allow images to be saved when one exists already. Great idea! Coded R2.2 / Tested Rel 2.1: All: when switching RAMs, give option to re-save current RAM or not. Coded R2.2 / Tested Rel 2.1: M100: add quickmenu command to reNAME or KILL a file in MENU. T200: add quickmenu command to NAME a file in MENU. Coded R2.2 / Tested Rel 2.1: All: Allow use to de-install the active ROM, leaving no ROM active. F6. Coded R2.2 / Tested
