[M100] update- build 260

[Stephen Adolph]

build 260 for REX is on the wiki.  Let me know of any problems.
* Peter's recent bug is fixed
* found a bug in 258 that was serious, on T200

Regarding the last bug.  T200 has different treatment of .DO files in RAM
compared to other models.  Pointers are used differently.

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] Video adapter.

[james . zeun]

This is very interesting Steve! I’ve never used CP/M on my M100. But I was 
intrigued when you said your eventual hope, was to have it work natively.

I certainly would be interested in that if and when it came along!

Wishing you the best of luck on this!



Sent from my iPad

> On 5 Apr 2020, at 3:04 pm, Randy Kindig  wrote:
> 
> That’s fabulous Steve!  Count me in on one of those devices!
> 
> Randy Kindig
> 
> Sent from my iPhone
> 
>>> On Apr 5, 2020, at 8:41 AM, Stephen Adolph  wrote:
>>> 
>> 
>> As some of you may recall, it is fairly straightforward to access an 80x24 
>> screen in CP/M through the use of the M100 serial port, and an external 
>> VT100 emulator.
>> 
>> This device:
>> http://geoffg.net/terminal.html
>> 
>> is a great example of how to connect a modern VGA flat screen display to the 
>> M100.  However, this exact design isn't really convenient, as the serial 
>> data has to be connected with a custom cable.  (see the little white 4 pin 
>> header).
>> 
>> I've decided to make a variant of this design that has a DB-9 connector on 
>> it, for serial data, so that it can be easily connected to the M100.
>> 
>> I'll be making kits available for this design, and the price will be 30$ US. 
>>  Hopefully by making this affordable and easier to connect, this can become 
>> the defacto solution to 80x24 display!
>> 
>> This solution will work with CP/M right away, but the next task will be - 
>> how to use this solution with Model T natively.  This will take some 
>> software work.  A port of the "DVI software" to leverage serial 
>> communication to the VT100 adapter is one way to do this. 
>> 
>> This solution is also compatible with the "BCR serial port" modification 
>> which allows for serial data transmission at up to 120kbits/sec.   A nice 
>> solution to exernal video that frees up the real RS-232 port of the laptop 
>> for comms.
>> 
>> I'll be updating the REX wiki with some information on this.  Kits aren't 
>> ready just yet.  I'm waiting for my boards to arrive.
>> 
>> cheers
>> Steve
>> 
>> 

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] Video adapter.

[Lee Kelley]

Awesome.  One step closer to a M/T lecture machine for connecting to a
projector and not need a modern computer in the mix.

On Sun, Apr 5, 2020, 09:04 Randy Kindig  wrote:

> That’s fabulous Steve!  Count me in on one of those devices!
>
> Randy Kindig
>
> Sent from my iPhone
>
> On Apr 5, 2020, at 8:41 AM, Stephen Adolph  wrote:
>
> 
> As some of you may recall, it is fairly straightforward to access an 80x24
> screen in CP/M through the use of the M100 serial port, and an external
> VT100 emulator.
>
> This device:
> http://geoffg.net/terminal.html
>
> is a great example of how to connect a modern VGA flat screen display to
> the M100.  However, this exact design isn't really convenient, as the
> serial data has to be connected with a custom cable.  (see the little white
> 4 pin header).
>
> I've decided to make a variant of this design that has a DB-9 connector on
> it, for serial data, so that it can be easily connected to the M100.
>
> I'll be making kits available for this design, and the price will be 30$
> US.  Hopefully by making this affordable and easier to connect, this can
> become the defacto solution to 80x24 display!
>
> This solution will work with CP/M right away, but the next task will be -
> how to use this solution with Model T natively.  This will take some
> software work.  A port of the "DVI software" to leverage serial
> communication to the VT100 adapter is one way to do this.
>
> This solution is also compatible with the "BCR serial port" modification
> which allows for serial data transmission at up to 120kbits/sec.   A nice
> solution to exernal video that frees up the real RS-232 port of the laptop
> for comms.
>
> I'll be updating the REX wiki with some information on this.  Kits aren't
> ready just yet.  I'm waiting for my boards to arrive.
>
> cheers
> 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

[M100] Video adapter.

[Stephen Adolph]

As some of you may recall, it is fairly straightforward to access an 80x24
screen in CP/M through the use of the M100 serial port, and an external
VT100 emulator.

This device:
http://geoffg.net/terminal.html

is a great example of how to connect a modern VGA flat screen display to
the M100.  However, this exact design isn't really convenient, as the
serial data has to be connected with a custom cable.  (see the little white
4 pin header).

I've decided to make a variant of this design that has a DB-9 connector on
it, for serial data, so that it can be easily connected to the M100.

I'll be making kits available for this design, and the price will be 30$
US.  Hopefully by making this affordable and easier to connect, this can
become the defacto solution to 80x24 display!

This solution will work with CP/M right away, but the next task will be -
how to use this solution with Model T natively.  This will take some
software work.  A port of the "DVI software" to leverage serial
communication to the VT100 adapter is one way to do this.

This solution is also compatible with the "BCR serial port" modification
which allows for serial data transmission at up to 120kbits/sec.   A nice
solution to exernal video that frees up the real RS-232 port of the laptop
for comms.

I'll be updating the REX wiki with some information on this.  Kits aren't
ready just yet.  I'm waiting for my boards to arrive.

cheers
Steve

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] The T community

[Tom Wilson]

There is a Facebook group. I see some of the same people over there.

https://www.facebook.com/groups/Model.T.Computers/?ref=share



On Sun, Apr 5, 2020 at 1:11 AM me  wrote:

> Are there any newsgroups, IRC channels, or BBS's this community frequents
> other than this list?
> On 4/4/20 4: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
>
>
>
> 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
>>>
 --
Tom Wilson
wilso...@gmail.com
(619)940-6311
K6ABZ

[M100] The T community

[me]

Are there any newsgroups, IRC channels, or BBS's this community 
frequents other than this list?


On 4/4/20 4: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



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
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

[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
> >
> 
>
>