> > > 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 <b.kenyo...@gmail.com> 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 > > > >
