Re: [M100] R2.2 update for REX# and REXCPM

2023-01-30 Thread jonathan.y...@telia.com
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

2023-01-30 Thread Stephen Adolph
>
>
> 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

2023-01-30 Thread Josh Malone
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

2023-01-30 Thread Stephen Adolph
>
>
> 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

2023-01-30 Thread Brian K. White

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

2023-01-30 Thread Stephen Adolph
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