Re: [M100] REX problem with .DO files

[Stephen Adolph]

thanks for the excellent bug report.  I have replicated it.  I'll get it
fixed.  It is a common bug across REX Classic, REX# and REXCPM.

Steve


On Sun, Apr 5, 2020 at 10:52 PM Peter Noeth  wrote:

> Yes Stephen, I should have been more specific, but I didn't have my T102
> in front of me:
>
> 1) Start REXMGR
> 2) Press [F6] for FILE
> 3) Press [Left Arrow] to move highlight bar to the RAM list
> 4) Use the [Up] [Down] keys to highlight a file
> 5) Press [F3] to rename file.
> 6) The function key labels are cleared and "New Name ?" is displayed.
> Enter a new name.
> 7) The file is renamed, and the file list is updated with the new name.
> 8) The prompt "New Name ?" remains
> 9 ) The function keys are back to being active, but the labels have not
> been refreshed.
>
> The [F5] key restores the function key labels after the confirmation
> prompt and the file is killed. So that is working correctly. I previously
> said that it too may have errant behavior, but I was wrong.
>
> Hope this clarifies the issue.
>
> Regards,
>
> Peter
>
>>
>>

Re: [M100] REX problem with .DO files

[Peter Noeth]

Yes Stephen, I should have been more specific, but I didn't have my T102 in
front of me:

1) Start REXMGR
2) Press [F6] for FILE
3) Press [Left Arrow] to move highlight bar to the RAM list
4) Use the [Up] [Down] keys to highlight a file
5) Press [F3] to rename file.
6) The function key labels are cleared and "New Name ?" is displayed. Enter
a new name.
7) The file is renamed, and the file list is updated with the new name.
8) The prompt "New Name ?" remains
9 ) The function keys are back to being active, but the labels have not
been refreshed.

The [F5] key restores the function key labels after the confirmation prompt
and the file is killed. So that is working correctly. I previously said
that it too may have errant behavior, but I was wrong.

Hope this clarifies the issue.

Regards,

Peter

--
>
> Message: 16
> Date: Sun, 5 Apr 2020 08:01:32 -0400
> From: Stephen Adolph 
> To: m...@bitchin100.com
> Subject: Re: [M100] REX problem with .DO files
> Message-ID:
>  vcrcikwnw_acfjybozx0_tcc3mtvmpcygtwru...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> thanks Peter, I'll try to replicate your bug.  I think you are saying that
> after renaming a file, the function key name tags were not visible?
>
> You are correct that software testing is a challenge.  The biggest
> challenges are
> (1) Support for multiple models, especially mult-bank support.  This was
> very challenging to implement and required major differences between NEC
> and T200, and M100.  It is so complex that it really expanded the needed
> test cases.
> (2) lack of automation.  Testing requires me to have all the hardware,
> updated, and manually run through every scenario.  As REX got more features
> this became a lot more challenging.
>
> what I am doing about it-
> 1)  I'm capping development of REX Classic.  It does what it does now, and
> bug fixes hopefully will approach zero.
> 2)  I'm introducing a new REX variant called REX# (REX Sharp).  This
> variant is simpler, it eliminates features that are problematic to maintain
> and have little value, while keeping the best capabilities.
>
> REX#  Summary  (soon to be online at the REX wiki)
> --
> * low manufacturing cost, hence much lower price (especially when bundled
> with REXCPM)
> * increases the # of available blocks from 24 to 28
> * includes Brian's PCB2MOLEX Carrier for increased reliability and
> convenience
> * based on REXMGR Rel 4.9 (build 258)
> * All the same features as REX Classic EXCEPT
> ---> supports RAM and ROM types only; no "OS" and no "SYS"
> ---> operates in Bank 1 only (NEC and T200)  (no "multi-bank" operation -
> much simpler!)
> ---> eliminates "Main ROM Management" feature.  In my opinion this is
> problematic and unnecessary.
> ---> eliminates some functions (Date/time, Sort)
> ---> added a build number to the REX information display, so we don't have
> to memorize Checksums.
>
>
>
> On Sun, Apr 5, 2020 at 3:33 AM Peter Noeth  wrote:
>
> > Thanks Steve,
> >
> > It will take me some time to try it out. I have never re-flashed the REX
> > before, so I will need to note what files are in each image (the masters
> > are on my PC), then study the re-flash procedure and execute it, then
> > re-load all the files.
> >
> > Hopefully nothing will break and cause my REX to become a doorstop. I
> > expect that you do not have an SQA (Software Quality Assurance) Test
> Suite,
> > so hopefully the fix doesn't break anything else.
> >
> > While we are on the "bug fix" topic, I also found another one the other
> > day. I was using the REXMGR to rename a file in RAM. Once the rename was
> > successful, the label menu was not re-displayed. I think this also occurs
> > when killing a file, but I am not sure.
> >
> > Regards,
> >
> > Peter
> >
> >>
> >>
>
>

Re: [M100] REX problem with .DO files

[Tom Wilson]

I will never use the system ROM option, but I sure would like those extra
ace slots, especially on my T-200, which throws away 16K on every slot.

On Sun, Apr 5, 2020 at 7:16 AM Stephen Adolph  wrote:

> good question.  Had not considered that to be honest.
> If you have a working REX today.. not sure you need REX#?
>
> On Sun, Apr 5, 2020 at 10:10 AM Tom Wilson  wrote:
>
>> Will we be able to run Rex# on current hardware, or will that require a
>> new board?
>>
>> On Sun, Apr 5, 2020 at 5:01 AM Stephen Adolph 
>> wrote:
>>
>>> thanks Peter, I'll try to replicate your bug.  I think you are saying
>>> that after renaming a file, the function key name tags were not visible?
>>>
>>> You are correct that software testing is a challenge.  The biggest
>>> challenges are
>>> (1) Support for multiple models, especially mult-bank support.  This was
>>> very challenging to implement and required major differences between NEC
>>> and T200, and M100.  It is so complex that it really expanded the needed
>>> test cases.
>>> (2) lack of automation.  Testing requires me to have all the hardware,
>>> updated, and manually run through every scenario.  As REX got more features
>>> this became a lot more challenging.
>>>
>>> what I am doing about it-
>>> 1)  I'm capping development of REX Classic.  It does what it does now,
>>> and bug fixes hopefully will approach zero.
>>> 2)  I'm introducing a new REX variant called REX# (REX Sharp).  This
>>> variant is simpler, it eliminates features that are problematic to maintain
>>> and have little value, while keeping the best capabilities.
>>>
>>> REX#  Summary  (soon to be online at the REX wiki)
>>> --
>>> * low manufacturing cost, hence much lower price (especially when
>>> bundled with REXCPM)
>>> * increases the # of available blocks from 24 to 28
>>> * includes Brian's PCB2MOLEX Carrier for increased reliability and
>>> convenience
>>> * based on REXMGR Rel 4.9 (build 258)
>>> * All the same features as REX Classic EXCEPT
>>> ---> supports RAM and ROM types only; no "OS" and no "SYS"
>>> ---> operates in Bank 1 only (NEC and T200)  (no "multi-bank" operation
>>> - much simpler!)
>>> ---> eliminates "Main ROM Management" feature.  In my opinion this is
>>> problematic and unnecessary.
>>> ---> eliminates some functions (Date/time, Sort)
>>> ---> added a build number to the REX information display, so we don't
>>> have to memorize Checksums.
>>>
>>>
>>>
>>> On Sun, Apr 5, 2020 at 3:33 AM Peter Noeth  wrote:
>>>
 Thanks Steve,

 It will take me some time to try it out. I have never re-flashed the
 REX before, so I will need to note what files are in each image (the
 masters are on my PC), then study the re-flash procedure and execute it,
 then re-load all the files.

 Hopefully nothing will break and cause my REX to become a doorstop. I
 expect that you do not have an SQA (Software Quality Assurance) Test Suite,
 so hopefully the fix doesn't break anything else.

 While we are on the "bug fix" topic, I also found another one the other
 day. I was using the REXMGR to rename a file in RAM. Once the rename was
 successful, the label menu was not re-displayed. I think this also occurs
 when killing a file, but I am not sure.

 Regards,

 Peter

>
> --
>> Tom Wilson
>> wilso...@gmail.com
>> (619)940-6311
>> K6ABZ
>>
> --
Tom Wilson
wilso...@gmail.com
(619)940-6311
K6ABZ

Re: [M100] REX problem with .DO files

[Stephen Adolph]

yes, TS-DOS is in the same default place, same block #

On Sun, Apr 5, 2020 at 2:49 PM Ken Pettit  wrote:

> Hey Steve,
>
> I downloaded it from the Wiki, but I have a question.  Is the starting
> directory image the same as 4.8, or has that changed also?  VirutalT writes
> both the REX software as well as the starting directory image.
>
> Ken
>
> On 4/5/20 10:51 AM, Stephen Adolph wrote:
>
> sure that would be great.
> Do you need an image?  or did you grab it from the wiki?  use the "full"
> image 32k that includes directories.
> thx
> Steve
>
>
> On Sun, Apr 5, 2020 at 1:23 PM Ken Pettit  wrote:
>
>> Steve,
>>
>> Since I am workingon a VirtualT 1.8 release, should I pull in REX release
>> 258 as the FW loaded for "Create Default Flash" button when choosing REX
>> memory emulation?
>>
>> Ken
>>
>> On 4/4/20 12:14 PM, Stephen Adolph wrote:
>>
>> Yes.  That's what is available now.
>> I can post an upgrade version later so long as you are on 254 now.
>>
>> A lot of people have  not upgraded to rhe new directory format hence I
>> force it with a wipe.
>>
>> On Saturday, April 4, 2020, Josh Malone  wrote:
>>
>>> So, this is also a "wipe and re-load completely" upgrade? Is that
>>> necessary? Seems like the bug is only in REXMGR which is just block 0,
>>> right? Or are the stored RAM images also corrupt and not usable on 258?
>>>
>>> -Josh
>>>
>>> On Sat, Apr 4, 2020 at 8:20 AM Stephen Adolph 
>>> wrote:
>>>
 Peter, thanks for finding this bug. It's been in the code for a long
 time!
 Found the issue.  Injection point for a new .DO file was off by 1 byte.
 Release 258 should fix this.

 It is posted at the REX wiki.

 Would appreciate people to go and give 258 a try.  It should be the
 same as 254, which was the prior posted release, with this bug fix added.

 I will say that I have not tested every model with every possible
 configuration.  So any bug reports would be useful.

 thanks
 Steve

>
>>
>

Re: [M100] REX problem with .DO files

[Ken Pettit]

Hey Steve,

I downloaded it from the Wiki, but I have a question.  Is the starting 
directory image the same as 4.8, or has that changed also? VirutalT 
writes both the REX software as well as the starting directory image.


Ken

On 4/5/20 10:51 AM, Stephen Adolph wrote:

sure that would be great.
Do you need an image?  or did you grab it from the wiki? use the 
"full" image 32k that includes directories.

thx
Steve


On Sun, Apr 5, 2020 at 1:23 PM Ken Pettit > wrote:


Steve,

Since I am workingon a VirtualT 1.8 release, should I pull in REX
release 258 as the FW loaded for "Create Default Flash" button
when choosing REX memory emulation?

Ken

On 4/4/20 12:14 PM, Stephen Adolph wrote:

Yes.  That's what is available now.
I can post an upgrade version later so long as you are on 254 now.

A lot of people have  not upgraded to rhe new directory format
hence I force it with a wipe.

On Saturday, April 4, 2020, Josh Malone mailto:josh.mal...@gmail.com>> wrote:

So, this is also a "wipe and re-load completely" upgrade? Is
that necessary? Seems like the bug is only in REXMGR which is
just block 0, right? Or are the stored RAM images also
corrupt and not usable on 258?

-Josh

On Sat, Apr 4, 2020 at 8:20 AM Stephen Adolph
mailto:twospru...@gmail.com>> wrote:

Peter, thanks for finding this bug. It's been in the code
for a long time!
Found the issue.  Injection point for a new .DO file was
off by 1 byte.
Release 258 should fix this.

It is posted at the REX wiki.

Would appreciate people to go and give 258 a try.  It
should be the same as 254, which was the prior posted
release, with this bug fix added.

I will say that I have not tested every model with every
possible configuration.  So any bug reports would be useful.

thanks
Steve

Re: [M100] REX problem with .DO files

[Stephen Adolph]

sure that would be great.
Do you need an image?  or did you grab it from the wiki?  use the "full"
image 32k that includes directories.
thx
Steve


On Sun, Apr 5, 2020 at 1:23 PM Ken Pettit  wrote:

> Steve,
>
> Since I am workingon a VirtualT 1.8 release, should I pull in REX release
> 258 as the FW loaded for "Create Default Flash" button when choosing REX
> memory emulation?
>
> Ken
>
> On 4/4/20 12:14 PM, Stephen Adolph wrote:
>
> Yes.  That's what is available now.
> I can post an upgrade version later so long as you are on 254 now.
>
> A lot of people have  not upgraded to rhe new directory format hence I
> force it with a wipe.
>
> On Saturday, April 4, 2020, Josh Malone  wrote:
>
>> So, this is also a "wipe and re-load completely" upgrade? Is that
>> necessary? Seems like the bug is only in REXMGR which is just block 0,
>> right? Or are the stored RAM images also corrupt and not usable on 258?
>>
>> -Josh
>>
>> On Sat, Apr 4, 2020 at 8:20 AM Stephen Adolph 
>> wrote:
>>
>>> Peter, thanks for finding this bug. It's been in the code for a long
>>> time!
>>> Found the issue.  Injection point for a new .DO file was off by 1 byte.
>>> Release 258 should fix this.
>>>
>>> It is posted at the REX wiki.
>>>
>>> Would appreciate people to go and give 258 a try.  It should be the same
>>> as 254, which was the prior posted release, with this bug fix added.
>>>
>>> I will say that I have not tested every model with every possible
>>> configuration.  So any bug reports would be useful.
>>>
>>> thanks
>>> Steve
>>>

>

Re: [M100] REX problem with .DO files

[Ken Pettit]

Steve,

Since I am workingon a VirtualT 1.8 release, should I pull in REX 
release 258 as the FW loaded for "Create Default Flash" button when 
choosing REX memory emulation?


Ken

On 4/4/20 12:14 PM, Stephen Adolph wrote:

Yes.  That's what is available now.
I can post an upgrade version later so long as you are on 254 now.

A lot of people have  not upgraded to rhe new directory format hence I 
force it with a wipe.


On Saturday, April 4, 2020, Josh Malone > wrote:


So, this is also a "wipe and re-load completely" upgrade? Is that
necessary? Seems like the bug is only in REXMGR which is just
block 0, right? Or are the stored RAM images also corrupt and not
usable on 258?

-Josh

On Sat, Apr 4, 2020 at 8:20 AM Stephen Adolph
mailto:twospru...@gmail.com>> wrote:

Peter, thanks for finding this bug. It's been in the code for
a long time!
Found the issue.  Injection point for a new .DO file was off
by 1 byte.
Release 258 should fix this.

It is posted at the REX wiki.

Would appreciate people to go and give 258 a try.  It should
be the same as 254, which was the prior posted release, with
this bug fix added.

I will say that I have not tested every model with every
possible configuration.  So any bug reports would be useful.

thanks
Steve

Re: [M100] REX problem with .DO files

[Stephen Adolph]

good question.  Had not considered that to be honest.
If you have a working REX today.. not sure you need REX#?

On Sun, Apr 5, 2020 at 10:10 AM Tom Wilson  wrote:

> Will we be able to run Rex# on current hardware, or will that require a
> new board?
>
> On Sun, Apr 5, 2020 at 5:01 AM Stephen Adolph 
> wrote:
>
>> thanks Peter, I'll try to replicate your bug.  I think you are saying
>> that after renaming a file, the function key name tags were not visible?
>>
>> You are correct that software testing is a challenge.  The biggest
>> challenges are
>> (1) Support for multiple models, especially mult-bank support.  This was
>> very challenging to implement and required major differences between NEC
>> and T200, and M100.  It is so complex that it really expanded the needed
>> test cases.
>> (2) lack of automation.  Testing requires me to have all the hardware,
>> updated, and manually run through every scenario.  As REX got more features
>> this became a lot more challenging.
>>
>> what I am doing about it-
>> 1)  I'm capping development of REX Classic.  It does what it does now,
>> and bug fixes hopefully will approach zero.
>> 2)  I'm introducing a new REX variant called REX# (REX Sharp).  This
>> variant is simpler, it eliminates features that are problematic to maintain
>> and have little value, while keeping the best capabilities.
>>
>> REX#  Summary  (soon to be online at the REX wiki)
>> --
>> * low manufacturing cost, hence much lower price (especially when bundled
>> with REXCPM)
>> * increases the # of available blocks from 24 to 28
>> * includes Brian's PCB2MOLEX Carrier for increased reliability and
>> convenience
>> * based on REXMGR Rel 4.9 (build 258)
>> * All the same features as REX Classic EXCEPT
>> ---> supports RAM and ROM types only; no "OS" and no "SYS"
>> ---> operates in Bank 1 only (NEC and T200)  (no "multi-bank" operation -
>> much simpler!)
>> ---> eliminates "Main ROM Management" feature.  In my opinion this is
>> problematic and unnecessary.
>> ---> eliminates some functions (Date/time, Sort)
>> ---> added a build number to the REX information display, so we don't
>> have to memorize Checksums.
>>
>>
>>
>> On Sun, Apr 5, 2020 at 3:33 AM Peter Noeth  wrote:
>>
>>> Thanks Steve,
>>>
>>> It will take me some time to try it out. I have never re-flashed the REX
>>> before, so I will need to note what files are in each image (the masters
>>> are on my PC), then study the re-flash procedure and execute it, then
>>> re-load all the files.
>>>
>>> Hopefully nothing will break and cause my REX to become a doorstop. I
>>> expect that you do not have an SQA (Software Quality Assurance) Test Suite,
>>> so hopefully the fix doesn't break anything else.
>>>
>>> While we are on the "bug fix" topic, I also found another one the other
>>> day. I was using the REXMGR to rename a file in RAM. Once the rename was
>>> successful, the label menu was not re-displayed. I think this also occurs
>>> when killing a file, but I am not sure.
>>>
>>> Regards,
>>>
>>> Peter
>>>

 --
> Tom Wilson
> wilso...@gmail.com
> (619)940-6311
> K6ABZ
>

Re: [M100] REX problem with .DO files

[Tom Wilson]

Will we be able to run Rex# on current hardware, or will that require a new
board?

On Sun, Apr 5, 2020 at 5:01 AM Stephen Adolph  wrote:

> thanks Peter, I'll try to replicate your bug.  I think you are saying that
> after renaming a file, the function key name tags were not visible?
>
> You are correct that software testing is a challenge.  The biggest
> challenges are
> (1) Support for multiple models, especially mult-bank support.  This was
> very challenging to implement and required major differences between NEC
> and T200, and M100.  It is so complex that it really expanded the needed
> test cases.
> (2) lack of automation.  Testing requires me to have all the hardware,
> updated, and manually run through every scenario.  As REX got more features
> this became a lot more challenging.
>
> what I am doing about it-
> 1)  I'm capping development of REX Classic.  It does what it does now, and
> bug fixes hopefully will approach zero.
> 2)  I'm introducing a new REX variant called REX# (REX Sharp).  This
> variant is simpler, it eliminates features that are problematic to maintain
> and have little value, while keeping the best capabilities.
>
> REX#  Summary  (soon to be online at the REX wiki)
> --
> * low manufacturing cost, hence much lower price (especially when bundled
> with REXCPM)
> * increases the # of available blocks from 24 to 28
> * includes Brian's PCB2MOLEX Carrier for increased reliability and
> convenience
> * based on REXMGR Rel 4.9 (build 258)
> * All the same features as REX Classic EXCEPT
> ---> supports RAM and ROM types only; no "OS" and no "SYS"
> ---> operates in Bank 1 only (NEC and T200)  (no "multi-bank" operation -
> much simpler!)
> ---> eliminates "Main ROM Management" feature.  In my opinion this is
> problematic and unnecessary.
> ---> eliminates some functions (Date/time, Sort)
> ---> added a build number to the REX information display, so we don't have
> to memorize Checksums.
>
>
>
> On Sun, Apr 5, 2020 at 3:33 AM Peter Noeth  wrote:
>
>> Thanks Steve,
>>
>> It will take me some time to try it out. I have never re-flashed the REX
>> before, so I will need to note what files are in each image (the masters
>> are on my PC), then study the re-flash procedure and execute it, then
>> re-load all the files.
>>
>> Hopefully nothing will break and cause my REX to become a doorstop. I
>> expect that you do not have an SQA (Software Quality Assurance) Test Suite,
>> so hopefully the fix doesn't break anything else.
>>
>> While we are on the "bug fix" topic, I also found another one the other
>> day. I was using the REXMGR to rename a file in RAM. Once the rename was
>> successful, the label menu was not re-displayed. I think this also occurs
>> when killing a file, but I am not sure.
>>
>> Regards,
>>
>> Peter
>>
>>>
>>> --
Tom Wilson
wilso...@gmail.com
(619)940-6311
K6ABZ

Re: [M100] REX problem with .DO files

[Stephen Adolph]

thanks Peter, I'll try to replicate your bug.  I think you are saying that
after renaming a file, the function key name tags were not visible?

You are correct that software testing is a challenge.  The biggest
challenges are
(1) Support for multiple models, especially mult-bank support.  This was
very challenging to implement and required major differences between NEC
and T200, and M100.  It is so complex that it really expanded the needed
test cases.
(2) lack of automation.  Testing requires me to have all the hardware,
updated, and manually run through every scenario.  As REX got more features
this became a lot more challenging.

what I am doing about it-
1)  I'm capping development of REX Classic.  It does what it does now, and
bug fixes hopefully will approach zero.
2)  I'm introducing a new REX variant called REX# (REX Sharp).  This
variant is simpler, it eliminates features that are problematic to maintain
and have little value, while keeping the best capabilities.

REX#  Summary  (soon to be online at the REX wiki)
--
* low manufacturing cost, hence much lower price (especially when bundled
with REXCPM)
* increases the # of available blocks from 24 to 28
* includes Brian's PCB2MOLEX Carrier for increased reliability and
convenience
* based on REXMGR Rel 4.9 (build 258)
* All the same features as REX Classic EXCEPT
---> supports RAM and ROM types only; no "OS" and no "SYS"
---> operates in Bank 1 only (NEC and T200)  (no "multi-bank" operation -
much simpler!)
---> eliminates "Main ROM Management" feature.  In my opinion this is
problematic and unnecessary.
---> eliminates some functions (Date/time, Sort)
---> added a build number to the REX information display, so we don't have
to memorize Checksums.



On Sun, Apr 5, 2020 at 3:33 AM Peter Noeth  wrote:

> Thanks Steve,
>
> It will take me some time to try it out. I have never re-flashed the REX
> before, so I will need to note what files are in each image (the masters
> are on my PC), then study the re-flash procedure and execute it, then
> re-load all the files.
>
> Hopefully nothing will break and cause my REX to become a doorstop. I
> expect that you do not have an SQA (Software Quality Assurance) Test Suite,
> so hopefully the fix doesn't break anything else.
>
> While we are on the "bug fix" topic, I also found another one the other
> day. I was using the REXMGR to rename a file in RAM. Once the rename was
> successful, the label menu was not re-displayed. I think this also occurs
> when killing a file, but I am not sure.
>
> Regards,
>
> Peter
>
>>
>>

Re: [M100] REX problem with .DO files

[Peter Noeth]

Thanks Steve,

It will take me some time to try it out. I have never re-flashed the REX
before, so I will need to note what files are in each image (the masters
are on my PC), then study the re-flash procedure and execute it, then
re-load all the files.

Hopefully nothing will break and cause my REX to become a doorstop. I
expect that you do not have an SQA (Software Quality Assurance) Test Suite,
so hopefully the fix doesn't break anything else.

While we are on the "bug fix" topic, I also found another one the other
day. I was using the REXMGR to rename a file in RAM. Once the rename was
successful, the label menu was not re-displayed. I think this also occurs
when killing a file, but I am not sure.

Regards,

Peter
--

>
> Message: 1
> Date: Sat, 4 Apr 2020 08:20:04 -0400
> From: Stephen Adolph 
> To: m...@bitchin100.com
> Subject: Re: [M100] REX problem with .DO files
> Message-ID:
> <
> camcmnv5abvuwonucxftb+ixcmh_vhjzpm9wxvaqqk0gcwrw...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Peter, thanks for finding this bug. It's been in the code for a long time!
> Found the issue.  Injection point for a new .DO file was off by 1 byte.
> Release 258 should fix this.
>
> It is posted at the REX wiki.
>
> Would appreciate people to go and give 258 a try.  It should be the same as
> 254, which was the prior posted release, with this bug fix added.
>
> I will say that I have not tested every model with every possible
> configuration.  So any bug reports would be useful.
>
> thanks
> Steve
>
>
> On Mon, Mar 23, 2020 at 1:33 AM Peter Noeth  wrote:
>
> > Currently discovered this. Firstly I have a T102, 32K and a REX, Software
> > 4.9 (CS=5E09)/Firmware 6(1).
> >
> >   I copied a small .DO file (47 bytes) to RAM from another REX image. I
> > then ran TEXT on the file and found that highlighting a section with F7
> and
> > pressing F5 to copy it to the paste buffer, caused the computer to lock
> up
> > and had to be cold booted. This behavior occurs whether the REX hook is
> > active or disabled after the file has been copied.
> >
> >   I tried this with several .DO files, just to see if it was repeatable,
> > which it was. The file content was correct when viewed in the TEXT
> editor.
> > Maybe something in the FCB (file control block) in the directory is not
> > correct?
> >
> >   Any ideas Steve? Maybe you could look into this since you are doing
> > current development to REXCPM.
> >
> > Regards,
> >
> > Peter
> >
> 
>
>

Re: [M100] REX problem with .DO files

[Stephen Adolph]

great!  cheers.  I think calling 258 a beta is a little funny.   But as we
have seen there are always bugs to fix.

On Sat, Apr 4, 2020 at 7:58 PM Josh Malone  wrote:

> Seems to work perfectly! Upgraded my 4.9 REX on 102 to the latest version.
> Was able to cold-start, load REXMGR, and restore a saved RAM image.
> Starblaze still runs after the memory restore so I'd say all is in order.
> Checksum E16C
>
> -Josh
>
> On Sat, Apr 4, 2020 at 7:43 PM Stephen Adolph 
> wrote:
>
>> Hi,
>> I posted upgrade only.  Hopefully they work without an issue.
>>
>> Josh, maybe give this a whirl and let me know?
>> thx
>> Steve
>>
>>>

Re: [M100] REX problem with .DO files

[Josh Malone]

Seems to work perfectly! Upgraded my 4.9 REX on 102 to the latest version.
Was able to cold-start, load REXMGR, and restore a saved RAM image.
Starblaze still runs after the memory restore so I'd say all is in order.
Checksum E16C

-Josh

On Sat, Apr 4, 2020 at 7:43 PM Stephen Adolph  wrote:

> Hi,
> I posted upgrade only.  Hopefully they work without an issue.
>
> Josh, maybe give this a whirl and let me know?
> thx
> Steve
>
>>

Re: [M100] REX problem with .DO files

[Stephen Adolph]

Hi,
I posted upgrade only.  Hopefully they work without an issue.

Josh, maybe give this a whirl and let me know?
thx
Steve



On Sat, Apr 4, 2020 at 1:12 PM Josh Malone  wrote:

> So, this is also a "wipe and re-load completely" upgrade? Is that
> necessary? Seems like the bug is only in REXMGR which is just block 0,
> right? Or are the stored RAM images also corrupt and not usable on 258?
>
> -Josh
>
> On Sat, Apr 4, 2020 at 8:20 AM Stephen Adolph 
> wrote:
>
>> Peter, thanks for finding this bug. It's been in the code for a long time!
>> Found the issue.  Injection point for a new .DO file was off by 1 byte.
>> Release 258 should fix this.
>>
>> It is posted at the REX wiki.
>>
>> Would appreciate people to go and give 258 a try.  It should be the same
>> as 254, which was the prior posted release, with this bug fix added.
>>
>> I will say that I have not tested every model with every possible
>> configuration.  So any bug reports would be useful.
>>
>> thanks
>> Steve
>>
>>>

Re: [M100] REX problem with .DO files

[Brian K. White]

On 4/4/20 6:20 PM, John R. Hogerhuis wrote:



On Sat, Apr 4, 2020 at 2:56 PM Brian K. White > wrote:



Along the way I discovered that my current version of dlplus is broken
for normal tpdd usage with ts-dos. Probably the same mystery commands
that have been mentioned recently. I was dinking around with that a
while ago. The bootstrap works and tpdd works with teeny. So I have
something to do for a while now locked up indoors.


I have been working with Ken. If you're using NEWDOS 5.05, there are 
significant issues.


Whatever comes in build 254.

By "my current version" I mean a copy I've been hacking on. 
https://github.com/bkw777/dlplus
I definitely messed with the main command recognition & processing loop. 
I never had the original version lock up ts-dos like that, and I used it 
a lot, so it's me.


--
bkw


In other words, it's probably not DLPlus. NEWDOS is broken.

-- John.



--
bkw

Re: [M100] REX problem with .DO files

[Ken Pettit]

On 4/4/20 3:20 PM, John R. Hogerhuis wrote:


I have been working with Ken. If you're using NEWDOS 5.05, there are 
significant issues.


In other words, it's probably not DLPlus. NEWDOS is broken.



Yep, and that's what *I* am working on while locked indoors.  :)

Ken

Re: [M100] REX problem with .DO files

[John R. Hogerhuis]

On Sat, Apr 4, 2020 at 2:56 PM Brian K. White  wrote:

>
> Along the way I discovered that my current version of dlplus is broken
> for normal tpdd usage with ts-dos. Probably the same mystery commands
> that have been mentioned recently. I was dinking around with that a
> while ago. The bootstrap works and tpdd works with teeny. So I have
> something to do for a while now locked up indoors.
>
>
I have been working with Ken. If you're using NEWDOS 5.05, there are
significant issues.

In other words, it's probably not DLPlus. NEWDOS is broken.

-- John.

Re: [M100] REX problem with .DO files

[Brian K. White]

On 4/4/20 8:20 AM, Stephen Adolph wrote:

Peter, thanks for finding this bug. It's been in the code for a long time!
Found the issue.  Injection point for a new .DO file was off by 1 byte.
Release 258 should fix this.

It is posted at the REX wiki.

Would appreciate people to go and give 258 a try.  It should be the same 
as 254, which was the prior posted release, with this bug fix added.


Thank you much.

I have applied this update to a couple 100s, 200, and 8201, with no 
problem so far. I haven't done any real testing other than running the 
installer and verifying that the CS= number (checksum?) on the info 
screen changed between before & after.


Along the way I discovered that my current version of dlplus is broken 
for normal tpdd usage with ts-dos. Probably the same mystery commands 
that have been mentioned recently. I was dinking around with that a 
while ago. The bootstrap works and tpdd works with teeny. So I have 
something to do for a while now locked up indoors.




I will say that I have not tested every model with every possible 
configuration.  So any bug reports would be useful.


thanks
Steve


On Mon, Mar 23, 2020 at 1:33 AM Peter Noeth > wrote:


Currently discovered this. Firstly I have a T102, 32K and a REX,
Software 4.9 (CS=5E09)/Firmware 6(1).

   I copied a small .DO file (47 bytes) to RAM from another REX
image. I then ran TEXT on the file and found that highlighting a
section with F7 and pressing F5 to copy it to the paste buffer,
caused the computer to lock up and had to be cold booted. This
behavior occurs whether the REX hook is active or disabled after the
file has been copied.

   I tried this with several .DO files, just to see if it was
repeatable, which it was. The file content was correct when viewed
in the TEXT editor. Maybe something in the FCB (file control block)
in the directory is not correct?

   Any ideas Steve? Maybe you could look into this since you are
doing current development to REXCPM.

Regards,

Peter




--
bkw

Re: [M100] REX problem with .DO files

[Stephen Adolph]

Yes.  That's what is available now.
I can post an upgrade version later so long as you are on 254 now.

A lot of people have  not upgraded to rhe new directory format hence I
force it with a wipe.

On Saturday, April 4, 2020, Josh Malone  wrote:

> So, this is also a "wipe and re-load completely" upgrade? Is that
> necessary? Seems like the bug is only in REXMGR which is just block 0,
> right? Or are the stored RAM images also corrupt and not usable on 258?
>
> -Josh
>
> On Sat, Apr 4, 2020 at 8:20 AM Stephen Adolph 
> wrote:
>
>> Peter, thanks for finding this bug. It's been in the code for a long time!
>> Found the issue.  Injection point for a new .DO file was off by 1 byte.
>> Release 258 should fix this.
>>
>> It is posted at the REX wiki.
>>
>> Would appreciate people to go and give 258 a try.  It should be the same
>> as 254, which was the prior posted release, with this bug fix added.
>>
>> I will say that I have not tested every model with every possible
>> configuration.  So any bug reports would be useful.
>>
>> thanks
>> Steve
>>
>>>

Re: [M100] REX problem with .DO files

[Josh Malone]

So, this is also a "wipe and re-load completely" upgrade? Is that
necessary? Seems like the bug is only in REXMGR which is just block 0,
right? Or are the stored RAM images also corrupt and not usable on 258?

-Josh

On Sat, Apr 4, 2020 at 8:20 AM Stephen Adolph  wrote:

> Peter, thanks for finding this bug. It's been in the code for a long time!
> Found the issue.  Injection point for a new .DO file was off by 1 byte.
> Release 258 should fix this.
>
> It is posted at the REX wiki.
>
> Would appreciate people to go and give 258 a try.  It should be the same
> as 254, which was the prior posted release, with this bug fix added.
>
> I will say that I have not tested every model with every possible
> configuration.  So any bug reports would be useful.
>
> thanks
> Steve
>
>>

Re: [M100] REX problem with .DO files

[Stephen Adolph]

Peter, thanks for finding this bug. It's been in the code for a long time!
Found the issue.  Injection point for a new .DO file was off by 1 byte.
Release 258 should fix this.

It is posted at the REX wiki.

Would appreciate people to go and give 258 a try.  It should be the same as
254, which was the prior posted release, with this bug fix added.

I will say that I have not tested every model with every possible
configuration.  So any bug reports would be useful.

thanks
Steve


On Mon, Mar 23, 2020 at 1:33 AM Peter Noeth  wrote:

> Currently discovered this. Firstly I have a T102, 32K and a REX, Software
> 4.9 (CS=5E09)/Firmware 6(1).
>
>   I copied a small .DO file (47 bytes) to RAM from another REX image. I
> then ran TEXT on the file and found that highlighting a section with F7 and
> pressing F5 to copy it to the paste buffer, caused the computer to lock up
> and had to be cold booted. This behavior occurs whether the REX hook is
> active or disabled after the file has been copied.
>
>   I tried this with several .DO files, just to see if it was repeatable,
> which it was. The file content was correct when viewed in the TEXT editor.
> Maybe something in the FCB (file control block) in the directory is not
> correct?
>
>   Any ideas Steve? Maybe you could look into this since you are doing
> current development to REXCPM.
>
> Regards,
>
> Peter
>

Re: [M100] REX problem with .DO files

[John R. Hogerhuis]

Seems like the file table or the memory file region pointers not being
updated. Or maybe an unterminated file.

>
-- John.

Re: [M100] REX problem with .DO files

[Stephen Adolph]

thanks, I'll look into this.  I think it probably relates to the use of the
buffers by REX, but I don't know for sure.

On Mon, Mar 23, 2020 at 3:15 AM Tom Wilson  wrote:

> I reproduced it on the 200.
>
>1. Cold booted (I turned the 200's memory switch off before I put it
>away.)
>2. Started Rex with CALL 61167,2
>3. Create a text file TEST.DO
>   - This is a test
>   - This is line 2
>   - This is line 3
>4. Created a new backup called "TEST"
>5. loaded a previous backup "BAK1"
>6. Launched REXMGR and copied TEST.DO
>7. exited REXMGR and opened TEST.DO
>8. The file contents appeared correct.
>9. F7, selected line 2, F5 (copy)
>10. The word "Test" appeared in place of the highlight. When I pressed
>Paste, the program locked up.
>11. I used the reset button to restart the computer. The file now says
>"This is a←"
>
> It seems to behave differently with TS-DOS and with Cleauseau/ROM2
> installed, but the end result is the same - using the clipboard on that
> file leads to the file getting mangled.
> I also tried this with a BASIC file, and it did not have this problem. I
> did the same thing, but before step 9, I typed Edit and then followed the
> same procedure. No lockups.
> So either the BASIC open/save process fixes whatever file pointers are
> bugged, or the problem only happens with DO files.
>
>
>
>
> On Sun, Mar 22, 2020 at 10:33 PM Peter Noeth  wrote:
>
>> Currently discovered this. Firstly I have a T102, 32K and a REX, Software
>> 4.9 (CS=5E09)/Firmware 6(1).
>>
>>   I copied a small .DO file (47 bytes) to RAM from another REX image. I
>> then ran TEXT on the file and found that highlighting a section with F7 and
>> pressing F5 to copy it to the paste buffer, caused the computer to lock up
>> and had to be cold booted. This behavior occurs whether the REX hook is
>> active or disabled after the file has been copied.
>>
>>   I tried this with several .DO files, just to see if it was repeatable,
>> which it was. The file content was correct when viewed in the TEXT editor.
>> Maybe something in the FCB (file control block) in the directory is not
>> correct?
>>
>>   Any ideas Steve? Maybe you could look into this since you are doing
>> current development to REXCPM.
>>
>> Regards,
>>
>> Peter
>>
>

Re: [M100] REX problem with .DO files

[Tom Wilson]

I reproduced it on the 200.

   1. Cold booted (I turned the 200's memory switch off before I put it
   away.)
   2. Started Rex with CALL 61167,2
   3. Create a text file TEST.DO
  - This is a test
  - This is line 2
  - This is line 3
   4. Created a new backup called "TEST"
   5. loaded a previous backup "BAK1"
   6. Launched REXMGR and copied TEST.DO
   7. exited REXMGR and opened TEST.DO
   8. The file contents appeared correct.
   9. F7, selected line 2, F5 (copy)
   10. The word "Test" appeared in place of the highlight. When I pressed
   Paste, the program locked up.
   11. I used the reset button to restart the computer. The file now says
   "This is a←"

It seems to behave differently with TS-DOS and with Cleauseau/ROM2
installed, but the end result is the same - using the clipboard on that
file leads to the file getting mangled.
I also tried this with a BASIC file, and it did not have this problem. I
did the same thing, but before step 9, I typed Edit and then followed the
same procedure. No lockups.
So either the BASIC open/save process fixes whatever file pointers are
bugged, or the problem only happens with DO files.




On Sun, Mar 22, 2020 at 10:33 PM Peter Noeth  wrote:

> Currently discovered this. Firstly I have a T102, 32K and a REX, Software
> 4.9 (CS=5E09)/Firmware 6(1).
>
>   I copied a small .DO file (47 bytes) to RAM from another REX image. I
> then ran TEXT on the file and found that highlighting a section with F7 and
> pressing F5 to copy it to the paste buffer, caused the computer to lock up
> and had to be cold booted. This behavior occurs whether the REX hook is
> active or disabled after the file has been copied.
>
>   I tried this with several .DO files, just to see if it was repeatable,
> which it was. The file content was correct when viewed in the TEXT editor.
> Maybe something in the FCB (file control block) in the directory is not
> correct?
>
>   Any ideas Steve? Maybe you could look into this since you are doing
> current development to REXCPM.
>
> Regards,
>
> Peter
>

[M100] REX problem with .DO files

[Peter Noeth]

Currently discovered this. Firstly I have a T102, 32K and a REX, Software
4.9 (CS=5E09)/Firmware 6(1).

  I copied a small .DO file (47 bytes) to RAM from another REX image. I
then ran TEXT on the file and found that highlighting a section with F7 and
pressing F5 to copy it to the paste buffer, caused the computer to lock up
and had to be cold booted. This behavior occurs whether the REX hook is
active or disabled after the file has been copied.

  I tried this with several .DO files, just to see if it was repeatable,
which it was. The file content was correct when viewed in the TEXT editor.
Maybe something in the FCB (file control block) in the directory is not
correct?

  Any ideas Steve? Maybe you could look into this since you are doing
current development to REXCPM.

Regards,

Peter