Re: [M100] REX#/REXCPM release 2.2 is on the wiki

[Stephen Adolph]

Hi Pawel,

I included a note in the instructions.

'x' is a variable: 1,2 or N - depending on your model

hope that addresses the concern.
Thanks Steve


On Sunday, November 5, 2023, Pawel Radomychelski | ExPLIT <
exp...@mailbox.org> wrote:

> Hello Steve!
>
> Thank you for the bugfix relese of REX# 22
>
> Upde went with one small issue:
>
> When i use your Instructions here:
>
> Instructions
>   
>   1.  Make sure REX# is in default state, meaning
>   a. REX# Manager is not running (use CNTL-X to remove hooks, or F7 from 
> REXMGR)
>   b. Power cycle once, to ensure the default memory blocks are selected
>   c. Optionally, cold-rebooting the laptop after a power cycle ensures a 
> clean state.
>   2.  Load RX#Ux.DO via serial transfer, or TPDD transfer.
>   3.  RUN RX#Ux.DO in BASIC.
>   RX#Ux.DO allows you to choose to LOAD a REX# application (24kB file)
>   4.  Configure RX#Ux.DO to do the following:
>   a.  indicate YES to "Load REX code:" using space bar/enter
>   b.  execute these choices by pressing Y.
>   5.  The loader will load up the machine language routine, and begin to 
> execute
>   6.  To LOAD a fresh REX# Manager application, RX#Ux.DO accesses a remote 
> TPDD server to get the binary 24k file.
>   RX#Ux.DO contains it's own TPDD access routines, and does not need a 
> DOS.
>   a. Ensure a TPDD server is ready to go with the source file as needed. 
> ex. RX#_12.BR
>   b. When asked for a NAME, Supply the correct file name (6 characters, 
> no extension, case sensitive) ex RX#_12
>   File extension is automatically set to .BR
>   7.  Let the program run
>   You should see a counter counting up from zero to 24,576 bytes
>   When complete, REX# should have a fresh software load installed.
>   The directory should be unchanged, and the saved images should be 
> intact.
>
>
>
> In the Step 6. its not clear, which file should be loaded: RX#_12.BR, 
> RX#_22.BR or RX#_N2.BR.
>
> First i choosed RX#_22.BR because i was confused with Version 22. After REX 
> was not accesable anymore, i updated it again with RX#_N2.BR
>
> Maybe the instructions should be updated to clarify on which machines, which 
> file should be used.
>
>
> Thanks!
>
>
> --
>
> Kind regards /
> Mit freundlichen Grüßen
>
> ExPLIT IT Solutions
> Pawel Radomychelski
>
>
>
> -Original Message-
> *From*: Stephen Adolph  >
> *Reply-To*: m...@bitchin100.com
> *To*: m...@bitchin100.com
> *Subject*: [M100] REX#/REXCPM release 2.2 is on the wiki
> *Date*: 11/05/23 04:23:32
>
> Sorry for the huge delay.
> I've updated the REX# wiki to post the Release 2.2 file sets for REXCPM
> and REX#.
> Let me know if anyone has any trouble.
>
> cheers
> Steve
>
> https://bitchin100.com/wiki/index.php?title=REXCPM#Software
> https://bitchin100.com/wiki/index.php?title=REXsharp#Software
>
>
>

Re: [M100] REX#/REXCPM release 2.2 is on the wiki

[Pawel Radomychelski | ExPLIT]

Hello Steve!

Thank you for the bugfix relese of REX# 22

Upde went with one small issue:

When i use your Instructions here:

Instructions
  
  1.  Make sure REX# is in default state, meaning
  a. REX# Manager is not running (use CNTL-X to remove hooks, or F7 from 
REXMGR)
  b. Power cycle once, to ensure the default memory blocks are selected
  c. Optionally, cold-rebooting the laptop after a power cycle ensures a 
clean state. 
  2.  Load RX#Ux.DO via serial transfer, or TPDD transfer.
  3.  RUN RX#Ux.DO in BASIC.
  RX#Ux.DO allows you to choose to LOAD a REX# application (24kB file)
  4.  Configure RX#Ux.DO to do the following:
  a.  indicate YES to "Load REX code:" using space bar/enter
  b.  execute these choices by pressing Y.
  5.  The loader will load up the machine language routine, and begin to execute
  6.  To LOAD a fresh REX# Manager application, RX#Ux.DO accesses a remote TPDD 
server to get the binary 24k file.
  RX#Ux.DO contains it's own TPDD access routines, and does not need a DOS.
  a. Ensure a TPDD server is ready to go with the source file as needed. 
ex. RX#_12.BR
  b. When asked for a NAME, Supply the correct file name (6 characters, no 
extension, case sensitive) ex RX#_12
  File extension is automatically set to .BR
  7.  Let the program run
  You should see a counter counting up from zero to 24,576 bytes
  When complete, REX# should have a fresh software load installed.
  The directory should be unchanged, and the saved images should be intact.


In the Step 6. its not clear, which file should be loaded: RX#_12.BR, RX#_22.BR 
or RX#_N2.BR.
First i choosed RX#_22.BR because i was confused with Version 22. After REX was 
not accesable anymore, i updated it again with RX#_N2.BR
Maybe the instructions should be updated to clarify on which machines, which 
file should be used.

Thanks!

-- 
Kind regards / 
Mit freundlichen Grüßen

ExPLIT IT Solutions
Pawel Radomychelski



-Original Message-
From: Stephen Adolph 
Reply-To: m...@bitchin100.com
To: m...@bitchin100.com
Subject: [M100] REX#/REXCPM release 2.2 is on the wiki
Date: 11/05/23 04:23:32

Sorry for the huge delay.
I've updated the REX# wiki to post the Release 2.2 file sets for REXCPM
and REX#.
Let me know if anyone has any trouble.

cheers
Steve

https://bitchin100.com/wiki/index.php?title=REXCPM#Software
https://bitchin100.com/wiki/index.php?title=REXsharp#Software




signature.asc
Description: This is a digitally signed message part

[M100] REX#/REXCPM release 2.2 is on the wiki

[Stephen Adolph]

Sorry for the huge delay.
I've updated the REX# wiki to post the Release 2.2 file sets for REXCPM and
REX#.
Let me know if anyone has any trouble.

cheers
Steve

https://bitchin100.com/wiki/index.php?title=REXCPM#Software
https://bitchin100.com/wiki/index.php?title=REXsharp#Software

Re: [M100] Rex# Crash on an M102

[Charlie Hoey]

Thanks for the updates! I tried the following:

1. Flash REX# firmware via TPDD, which appeared to work but then exhibited
the same behavior of trying to load some ghost image on start and then
crashing
2. Flash REX# with the test.do, which I realize would lose the flash images
but I've got backups. However this also crashes, though with some
old-school panache, video here: https://photos.app.goo.gl/XfT9VQaVRBXG4HHM7

@Steve Thank you for the offer but I am pretty sure I have things backed
up. If I don't have any luck doing the full reflash, I may drop you a line
directly. This 102 is occasionally flakey, so once I'm back near another
machine I will give it one more go and see if it's 102 specific or if I've
bricked my poor rex.

Thanks again,
-Charlie

On Fri, May 26, 2023 at 12:32 AM Brian K. White 
wrote:

> First thing verify the connection to all the pins in the socket. It's a
> common weak point. No weak/compressed pins, no oxidization, rex# fully
> seated etc.
>
> Otherwise what Steve said, run the install/update tool to reflash the Rex#.
>
> --
> bkw
> On 5/25/23 21:27, Charlie Hoey wrote:
> > Hello there!
> >
> > I had my first crash on a Rex# that I can't get myself out of, curious
> > if anybody has any tips.
> >
> > I was in the process of creating a clean bank for a new project, and it
> > failed somewhere near the end. I RESET and then ran `CALL 63012` to
> > reload REX, but now whenever I start REXMGR, it attempts to load/write
> > something and hangs. I've done a cold reset, pulled batteries etc, so I
> > think it's in eeprom/flash somewhere. Here's a shot of what I'm seeing:
> >
> > Screen Shot 2023-05-25 at 9.13.23 PM.jpg
> > If images don't work here, launching REXMGR shows the standard top line
> > with "REX #2.1" in the top left, and the bottom right is the progress
> > bar, which fills up most of the way and then hangs.
> >
> > Any way I might peek/poke my way back to a usable state? I don't care
> > about the in progress job that failed, so if I could clear a flag or get
> > it to just abandon it that would be fine.
> >
> > Thanks as always!
> > -Charlie
>
>
>

Re: [M100] Rex# Crash on an M102

[Brian K. White]

First thing verify the connection to all the pins in the socket. It's a 
common weak point. No weak/compressed pins, no oxidization, rex# fully 
seated etc.


Otherwise what Steve said, run the install/update tool to reflash the Rex#.

--
bkw
On 5/25/23 21:27, Charlie Hoey wrote:

Hello there!

I had my first crash on a Rex# that I can't get myself out of, curious 
if anybody has any tips.


I was in the process of creating a clean bank for a new project, and it 
failed somewhere near the end. I RESET and then ran `CALL 63012` to 
reload REX, but now whenever I start REXMGR, it attempts to load/write 
something and hangs. I've done a cold reset, pulled batteries etc, so I 
think it's in eeprom/flash somewhere. Here's a shot of what I'm seeing:


Screen Shot 2023-05-25 at 9.13.23 PM.jpg
If images don't work here, launching REXMGR shows the standard top line 
with "REX #2.1" in the top left, and the bottom right is the progress 
bar, which fills up most of the way and then hangs.


Any way I might peek/poke my way back to a usable state? I don't care 
about the in progress job that failed, so if I could clear a flag or get 
it to just abandon it that would be fine.


Thanks as always!
-Charlie

Re: [M100] Rex# Crash on an M102

[Stephen Adolph]

Charlie,
Hard to say what's wrong.
In an ideal situation, I'd like to get it back and root cause the problem.

So, yoo could send it back and I send you a replacement.

Short of that,  a rebuild would be what is needed.

Release 2.1 to do a rebuild are posted on the wiki, along with
instructions.

Option 1.  Refresh the rom.  This puts a freshness copy of rex manager in
the flash.  It preserves your saved images and directory.

If that does not work..

Option 2.  Rebuild.  This is a complete wipe and reset to original, erasing
the contents.

Your rom images are likely there and still fine.  I've never written tools
tor ecover them.  If you need those images I could probably recover them
for you if you send me the rex#.

..steve


On Thursday, May 25, 2023, Charlie Hoey  wrote:

> Hello there!
>
> I had my first crash on a Rex# that I can't get myself out of, curious if
> anybody has any tips.
>
> I was in the process of creating a clean bank for a new project, and it
> failed somewhere near the end. I RESET and then ran `CALL 63012` to reload
> REX, but now whenever I start REXMGR, it attempts to load/write something
> and hangs. I've done a cold reset, pulled batteries etc, so I think it's in
> eeprom/flash somewhere. Here's a shot of what I'm seeing:
>
> [image: Screen Shot 2023-05-25 at 9.13.23 PM.jpg]
> If images don't work here, launching REXMGR shows the standard top line
> with "REX #2.1" in the top left, and the bottom right is the progress bar,
> which fills up most of the way and then hangs.
>
> Any way I might peek/poke my way back to a usable state? I don't care
> about the in progress job that failed, so if I could clear a flag or get it
> to just abandon it that would be fine.
>
> Thanks as always!
> -Charlie
>

[M100] Rex# Crash on an M102

[Charlie Hoey]

Hello there!

I had my first crash on a Rex# that I can't get myself out of, curious if
anybody has any tips.

I was in the process of creating a clean bank for a new project, and it
failed somewhere near the end. I RESET and then ran `CALL 63012` to reload
REX, but now whenever I start REXMGR, it attempts to load/write something
and hangs. I've done a cold reset, pulled batteries etc, so I think it's in
eeprom/flash somewhere. Here's a shot of what I'm seeing:

[image: Screen Shot 2023-05-25 at 9.13.23 PM.jpg]
If images don't work here, launching REXMGR shows the standard top line
with "REX #2.1" in the top left, and the bottom right is the progress bar,
which fills up most of the way and then hangs.

Any way I might peek/poke my way back to a usable state? I don't care about
the in progress job that failed, so if I could clear a flag or get it to
just abandon it that would be fine.

Thanks as always!
-Charlie

Re: [M100] REX# - RAM Images

[John R. Hogerhuis]

On Wed, Feb 22, 2023, 1:54 PM Joseph Colson III 
wrote:

> John - I have been reading up on tback.exe.   It would appear that you can
> backup a ram state on Virtual-T and load the backup onto a Model 100 ? How
> is this done ?
>
>
>


If you're asking what file in virtual t... it's just a file on the disk. As
long as you put your backup in the same place and name it correctly it
should work.

Looking at my virtual t directory there is a RAM.bin under subdirectories
for each model. I think that's it.

-- John.

>

Re: [M100] REX# - RAM Images

[John R. Hogerhuis]

Generally you use it to back up a real model t ram state, over the serial
port very quickly. And you could later restore that image onto the same
laptop or give it to a friend to restore on theirs.

Yes you can use that RAM image with virtual t by copying it over its RAM
image file that it keeps on disk.

Also you could take a virtual t ram file and restore it onto a real laptop
using tback.

-- John.

On Wed, Feb 22, 2023, 1:54 PM Joseph Colson III 
wrote:

> John - I have been reading up on tback.exe.   It would appear that you can
> backup a ram state on Virtual-T and load the backup onto a Model 100 ? How
> is this done ?
>
>
>
>
>
> Thanks for your hard work.
>
>
>
> Joe
>
>
>
> *From:* M100  *On Behalf Of *John R.
> Hogerhuis
> *Sent:* Wednesday, February 22, 2023 12:53 PM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] REX# - RAM Images
>
>
>
> I don't have any handy but RAM images can be useful for saving
> configurations of multiple files especially with large ML programs that are
> difficult to load, like TMPC.
>
>
>
> And even without a REX, because you can use TBACK.EXE to save or load a
> RAM image.
>
>
>
> -- John.
>

Re: [M100] REX# - RAM Images

[Joseph Colson III]

John - I have been reading up on tback.exe.   It would appear that you can 
backup a ram state on Virtual-T and load the backup onto a Model 100 ? How is 
this done ?


Thanks for your hard work.

Joe

From: M100  On Behalf Of John R. Hogerhuis
Sent: Wednesday, February 22, 2023 12:53 PM
To: m...@bitchin100.com
Subject: Re: [M100] REX# - RAM Images

I don't have any handy but RAM images can be useful for saving configurations 
of multiple files especially with large ML programs that are difficult to load, 
like TMPC.

And even without a REX, because you can use TBACK.EXE to save or load a RAM 
image.

-- John.

Re: [M100] REX# - RAM Images

[John R. Hogerhuis]

I don't have any handy but RAM images can be useful for saving
configurations of multiple files especially with large ML programs that are
difficult to load, like TMPC.

And even without a REX, because you can use TBACK.EXE to save or load a RAM
image.

-- John.

[M100] REX# - RAM Images

[Joseph Colson III]

Anyone have REX images they wish to share or can point me to a location where I 
can download them?   This seems like a real easy way to share files.

Joe

Re: [M100] Rex#..TPDD compatibility

[Stephen Adolph]

Yah I know about that ask.  It is on my list.

On Sat, Jan 14, 2023 at 4:38 PM  wrote:

> An addendum: I was just chatting with the Backpack developer about this.
> Another point he brought up is that the Backpack won’t overwrite an
> existing file. Let’s say you are using TS-DOS and you try to save a file
> with the same name as one on the disk. The Backpack (like the real TPDD?)
> will return a file exists error. TS-DOS will ask if you want to overwrite.
> When you select YES TS-DOS first deletes the existing file on the disk then
> it saves the new file.
>
> The REX seems to ignore a file exists error and then gives up/times out.
> It would be nice to have the same sort of prompt that TS-DOS provides. The
> user may not wish to overwrite a previous backup, and this will give them a
> warning that they are about to do so.
>
>
>
> Jeff Birt
>
>
>
> *From:* bir...@soigeneris.com 
> *Sent:* Saturday, January 14, 2023 1:30 PM
> *To:* 'm...@bitchin100.com' 
> *Subject:* RE: [M100] Rex#..TPDD compatibility
>
>
>
> For the Backpack, when you save a file the Backpack needs to check to see
> if the file already exists. If you have a lot of files in the directory it
> will take a while to check all of them. The timeout on the REX is rather
> short so it gives up before the Backpack (or real drive I would guess) can
> respond. The work around is to save to a directory with few files. If you
> can increase the timeout on the REX it would probably solve the issue for
> it and the real drive.
>
>
>
> Jeff Birt
>
>
>

Re: [M100] Rex#..TPDD compatibility

[birt_j]

An addendum: I was just chatting with the Backpack developer about this. 
Another point he brought up is that the Backpack won’t overwrite an existing 
file. Let’s say you are using TS-DOS and you try to save a file with the same 
name as one on the disk. The Backpack (like the real TPDD?) will return a file 
exists error. TS-DOS will ask if you want to overwrite. When you select YES 
TS-DOS first deletes the existing file on the disk then it saves the new file. 

The REX seems to ignore a file exists error and then gives up/times out. It 
would be nice to have the same sort of prompt that TS-DOS provides. The user 
may not wish to overwrite a previous backup, and this will give them a warning 
that they are about to do so.

 

Jeff Birt

 

From: bir...@soigeneris.com  
Sent: Saturday, January 14, 2023 1:30 PM
To: 'm...@bitchin100.com' 
Subject: RE: [M100] Rex#..TPDD compatibility

 

For the Backpack, when you save a file the Backpack needs to check to see if 
the file already exists. If you have a lot of files in the directory it will 
take a while to check all of them. The timeout on the REX is rather short so it 
gives up before the Backpack (or real drive I would guess) can respond. The 
work around is to save to a directory with few files. If you can increase the 
timeout on the REX it would probably solve the issue for it and the real drive.

 

Jeff Birt

 

Re: [M100] Rex#..TPDD compatibility

[birt_j]

For the Backpack, when you save a file the Backpack needs to check to see if 
the file already exists. If you have a lot of files in the directory it will 
take a while to check all of them. The timeout on the REX is rather short so it 
gives up before the Backpack (or real drive I would guess) can respond. The 
work around is to save to a directory with few files. If you can increase the 
timeout on the REX it would probably solve the issue for it and the real drive.

 

Jeff Birt

 

From: M100  On Behalf Of Stephen Adolph
Sent: Saturday, January 14, 2023 9:30 AM
To: m...@bitchin100.com
Subject: Re: [M100] Rex#..TPDD compatibility

 

Here is the current status of REX# (and REXCPM) interworking.

Better than I thought!

 



 

Dosbox is set up to run pretty slow, but my set up runs Desklink well on 
Windows 10, and also runs PDD.EXE, which is great.

 

Backpack works for general use with REX#.  Just the REX# utilities for 
rebuilding etc do not work.

I'm not sure what makes Backpack unique in that sense.  But it will probably 
work once I fix the TPDD1/TPDD2 interworking.

Pretty sure I know what that is.

 

I still rely on LaddieAlpha for building and testing REX#.

 

 

On Sat, Jan 14, 2023 at 8:54 AM Stephen Adolph mailto:twospru...@gmail.com> > wrote:

thanks Josh, I think I should be able to test mComm windows.  

I imagine I need something special to use mComm android.

 

 

On Thu, Jan 12, 2023 at 10:14 PM Josh O’Keefe mailto:maj...@nachomountain.com> > wrote:

Those I have used “for real” recently not on your list:
mComm Python 
dlplus

Those I’m aware of off the top of my head not on your list, but can’t comment 
on further due to platform constraints:
mComm Windows
mComm Android


Sent from my iPhone

> On Jan 13, 2023, at 8:38 AM, Stephen Adolph  <mailto:twospru...@gmail.com> > wrote:
> 
> 
> Thinking about a maintenance release on REX# to pick up a bunch of fixes and 
> improvements.
> 
> One of the items is to make the interface to a TPDD client more reliable.
> 
> Did I get that right Brian? ;)
> 
> What are the clients that are needed?
> 
> Real TPDD1, TPDD2
> Nadsbox
> LaddieAlpha
> Backpack
> DLPilot
> Desklink on an old PC or DOSbox
> 
> What else?
> 
> Thanks
> Steve
> 

Re: [M100] Rex#..TPDD compatibility

[Stephen Adolph]

added DLPilot to the list:

[image: image.png]


On Sat, Jan 14, 2023 at 11:09 AM Stephen Adolph 
wrote:

> not yet but that is the plan
>
> On Sat, Jan 14, 2023 at 10:35 AM Cedric Amand  wrote:
>
>> I wish to add that the patched version you sent me (with enlarged delays)
>> worked on my TPDD1
>> Was this never merged with the "main" software ?
>>
>>
>> Le 2023-01-14 16:30, Stephen Adolph  a écrit :
>>
>> Here is the current status of REX# (and REXCPM) interworking.
>> Better than I thought!
>>
>>
>>

Re: [M100] Rex#..TPDD compatibility

[Stephen Adolph]

not yet but that is the plan

On Sat, Jan 14, 2023 at 10:35 AM Cedric Amand  wrote:

> I wish to add that the patched version you sent me (with enlarged delays)
> worked on my TPDD1
> Was this never merged with the "main" software ?
>
>
> Le 2023-01-14 16:30, Stephen Adolph  a écrit :
>
> Here is the current status of REX# (and REXCPM) interworking.
> Better than I thought!
>
>
>

Re: [M100] Rex#..TPDD compatibility

[Cedric Amand]

I wish to add that the patched version you sent me (with enlarged delays) 
worked on my TPDD1 Was this never merged with the "main" software ? Le 
2023-01-14 16:30, Stephen Adolph  a écrit : > > > Here is 
the current status of REX# (and REXCPM) interworking. > > Better than I 
thought! > > > >

Re: [M100] Rex#..TPDD compatibility

[Stephen Adolph]

Here is the current status of REX# (and REXCPM) interworking.
Better than I thought!

[image: image.png]

Dosbox is set up to run pretty slow, but my set up runs Desklink well on
Windows 10, and also runs PDD.EXE, which is great.

Backpack works for general use with REX#.  Just the REX# utilities for
rebuilding etc do not work.
I'm not sure what makes Backpack unique in that sense.  But it will
probably work once I fix the TPDD1/TPDD2 interworking.
Pretty sure I know what that is.

I still rely on LaddieAlpha for building and testing REX#.


On Sat, Jan 14, 2023 at 8:54 AM Stephen Adolph  wrote:

> thanks Josh, I think I should be able to test mComm windows.
> I imagine I need something special to use mComm android.
>
>
> On Thu, Jan 12, 2023 at 10:14 PM Josh O’Keefe 
> wrote:
>
>> Those I have used “for real” recently not on your list:
>> mComm Python
>> dlplus
>>
>> Those I’m aware of off the top of my head not on your list, but can’t
>> comment on further due to platform constraints:
>> mComm Windows
>> mComm Android
>>
>>
>> Sent from my iPhone
>>
>> > On Jan 13, 2023, at 8:38 AM, Stephen Adolph 
>> wrote:
>> >
>> > 
>> > Thinking about a maintenance release on REX# to pick up a bunch of
>> fixes and improvements.
>> >
>> > One of the items is to make the interface to a TPDD client more
>> reliable.
>> >
>> > Did I get that right Brian? ;)
>> >
>> > What are the clients that are needed?
>> >
>> > Real TPDD1, TPDD2
>> > Nadsbox
>> > LaddieAlpha
>> > Backpack
>> > DLPilot
>> > Desklink on an old PC or DOSbox
>> >
>> > What else?
>> >
>> > Thanks
>> > Steve
>> >
>>
>

Re: [M100] Rex#..TPDD compatibility

[Stephen Adolph]

thanks Josh, I think I should be able to test mComm windows.
I imagine I need something special to use mComm android.


On Thu, Jan 12, 2023 at 10:14 PM Josh O’Keefe 
wrote:

> Those I have used “for real” recently not on your list:
> mComm Python
> dlplus
>
> Those I’m aware of off the top of my head not on your list, but can’t
> comment on further due to platform constraints:
> mComm Windows
> mComm Android
>
>
> Sent from my iPhone
>
> > On Jan 13, 2023, at 8:38 AM, Stephen Adolph 
> wrote:
> >
> > 
> > Thinking about a maintenance release on REX# to pick up a bunch of fixes
> and improvements.
> >
> > One of the items is to make the interface to a TPDD client more reliable.
> >
> > Did I get that right Brian? ;)
> >
> > What are the clients that are needed?
> >
> > Real TPDD1, TPDD2
> > Nadsbox
> > LaddieAlpha
> > Backpack
> > DLPilot
> > Desklink on an old PC or DOSbox
> >
> > What else?
> >
> > Thanks
> > Steve
> >
>

Re: [M100] Rex#..TPDD compatibility

[Brian K. White]

On 1/12/23 14:37, Stephen Adolph wrote:
Thinking about a maintenance release on REX# to pick up a bunch of fixes 
and improvements.


One of the items is to make the interface to a TPDD client more reliable.

Did I get that right Brian? ;)


No, since these are servers. ;)
The code inside rxcini and rexmgr is client code.


What are the clients that are needed?

Real TPDD1, TPDD2
Nadsbox
LaddieAlpha
Backpack
DLPilot
Desklink on an old PC or DOSbox

What else?

Thanks
Steve


I would say, for the purpose of developing and vetting tpdd client code, 
the only reference is a real drive.


It's a pain to set up the test on a real drive, and a real drive would 
be wildly inconvenient way to set up a REX, and no normal user should 
actually do that, but, only a real drive is the definitive test of 
correct tpdd client operation.


By getting it to work on a real drive, you automatically get it to work 
on all emulators. If something sometime works on a real drive and not on 
some emulator, by definition the emulator is faulty, and the emulator 
should be fixed rather than you write something that relies on a buggy 
emulator. But by now all the emulators are tested so much that it's not 
a problem. Once it works on a real drive, it *will* work on all the 
usual emulators.


But I understand it's annoying to even set up the test for that. I'm not 
trying to tell you to do it, just explaining my thinking.


--
bkw

Re: [M100] Rex#..TPDD compatibility

[Josh O’Keefe]

Those I have used “for real” recently not on your list:
mComm Python 
dlplus

Those I’m aware of off the top of my head not on your list, but can’t comment 
on further due to platform constraints:
mComm Windows
mComm Android


Sent from my iPhone

> On Jan 13, 2023, at 8:38 AM, Stephen Adolph  wrote:
> 
> 
> Thinking about a maintenance release on REX# to pick up a bunch of fixes and 
> improvements.
> 
> One of the items is to make the interface to a TPDD client more reliable.
> 
> Did I get that right Brian? ;)
> 
> What are the clients that are needed?
> 
> Real TPDD1, TPDD2
> Nadsbox
> LaddieAlpha
> Backpack
> DLPilot
> Desklink on an old PC or DOSbox
> 
> What else?
> 
> Thanks
> Steve
> 

[M100] Rex#..TPDD compatibility

[Stephen Adolph]

Thinking about a maintenance release on REX# to pick up a bunch of fixes
and improvements.

One of the items is to make the interface to a TPDD client more reliable.

Did I get that right Brian? ;)

What are the clients that are needed?

Real TPDD1, TPDD2
Nadsbox
LaddieAlpha
Backpack
DLPilot
Desklink on an old PC or DOSbox

What else?

Thanks
Steve

Re: [M100] REX availability

[Chris Kmiec]

Great! Would like REXCPM for 102 and REX for 100.

Chris

On Thu, Dec 8, 2022, 11:20 PM Stephen Adolph  wrote:

> Yes they are!  For rexcpm you need s machine specific adapter.  M100 or
> t102?
>
>
>
> On Thursday, December 8, 2022, Chris Kmiec  wrote:
>
>> I have one in my 102, and just got another 100 and 102. Would like to get
>> both REX and REXCPM. Are they still available?
>>
>> Thanks!
>>
>

Re: [M100] REX availability

[Stephen Adolph]

Yes they are!  For rexcpm you need s machine specific adapter.  M100 or
t102?



On Thursday, December 8, 2022, Chris Kmiec  wrote:

> I have one in my 102, and just got another 100 and 102. Would like to get
> both REX and REXCPM. Are they still available?
>
> Thanks!
>

[M100] REX availability

[Chris Kmiec]

I have one in my 102, and just got another 100 and 102. Would like to get
both REX and REXCPM. Are they still available?

Thanks!

Re: [M100] REX

[Stephen Adolph]

Bob, I'd be happy to help you out.
Please contact me off list.  I believe the email address should be visible.
thanks
Steve


On Sun, Nov 13, 2022 at 1:14 PM Bob Sylvester  wrote:

> To Whom It May Concern;
>
> Is the REX still available?
>
> Regards,
>
> Bob Sylvester
>
>

Re: [M100] REX

[Will Senn]

Chuckle! Anyhow, I recently got a 2MB REXCPM and it works swell!

On 11/13/22 1:41 PM, Gregory McGill wrote:

Sure is did you look at the rex page? or are you a bing user?

https://bitchin100.com/wiki/index.php?title=REX

On Sun, Nov 13, 2022, 10:14 AM Bob Sylvester  wrote:

To Whom It May Concern;

Is the REX still available?

Regards,

Bob Sylvester

Re: [M100] REX

[Gregory McGill]

Sure is did you look at the rex page? or are you a bing user?

https://bitchin100.com/wiki/index.php?title=REX

On Sun, Nov 13, 2022, 10:14 AM Bob Sylvester  wrote:

> To Whom It May Concern;
>
> Is the REX still available?
>
> Regards,
>
> Bob Sylvester
>
>

[M100] REX

[Bob Sylvester]

To Whom It May Concern;

Is the REX still available?

Regards,

Bob Sylvester

Re: [M100] REX# and Option ROMs: Qs from a noob

[John R. Hogerhuis]

On Thu, Jul 7, 2022 at 2:58 PM Charles Hudson  wrote:

> Okay, this is what I was looking for:
> http://www.club100.org/library/libdoc.html
>

Oh, good.

I went to the librom page and didn't see it. Guess I should have dug deeper.

And apparently the outliner is called THOUGHT not THINK. Memory fail...

-- John.

Re: [M100] REX# and Option ROMs: Qs from a noob

[Charles Hudson]

Okay, this is what I was looking for:
http://www.club100.org/library/libdoc.html

Re: [M100] REX# and Option ROMs: Qs from a noob

[Greg Swallow]

If I have the pdf files they are buried somewhere on my network. I’ll keep 
looking. May end up scanning. Here’s a tip buy for getting several rims working 
(from Club100):


Most option ROMs for the Model 100/102, Model 200, and NEC PC-8201A use the 
same ROM call, since you are telling the OS to look at the starting address of 
the ROM address space.  Traveling Software ROMs were a bit different, but they 
also offered some tricks. 

Option ROM   Model 100/102  Model 200  NEC PC-8201A
 -- -- ---
Traveling Software, offered by Club 100: A Model 100 User Group
  TS-DOS call 63013,1   call 61167,2   poke 63911,1:exec 62394
   CSR (1)   call 63013,0   call 921,146   poke 63911,146:exec 1124
  UR2call 63013,1   call 61167,2   poke 63911,1:exec 62394
  Sardinecall 63013,1   call 61167,2   poke 63911,1:exec 62394
  ROM2/Cleuseau  call 63012 call 61167,2   poke 63911,1:exec 62394
  Card File  call 63012 call 61167,2   poke 63911,1:exec 62394
  TS-Random  call 63013,1   call 61167,2   poke 63911,1:exec 62394

Portable Computer Support Group, offered by Tri-Mike Network East
  SuperROM   call 63012 call 61167,2   poke 63911,1:exec 62394
  Lucid  call 63012 call 61167,2   poke 63911,1:exec 62394
  Bus Analystcall 63012 call 61167,2   poke 63911,1:exec 62394
  RAMPluscall 63012 call 61167,2   poke 63911,1:exec 62394

Tandy/Radio Shack, offered by Club 100: A Model 100 User Group
  Int Solutions  call 63012 call 61167,2   poke 63911,1:exec 62394
  Multiplan  call 63012 call 61167,2   poke 63911,1:exec 62394

Others, where-is, as-is
  Logit100   call 63012 call 61167,2   poke 63911,1:exec 62394

(1)Cold Start Recovery


> On Jul 7, 2022, at 2:40 PM, Charles Hudson  wrote:
> 
> Also:  
> https://ia803208.us.archive.org/22/items/Multiplan_for_Tandy_100_1984_Microsoft/Multiplan_for_Tandy_100_1984_Microsoft.pdf
>  
> 

Re: [M100] REX# and Option ROMs: Qs from a noob

[Charles Hudson]

Also:
https://ia803208.us.archive.org/22/items/Multiplan_for_Tandy_100_1984_Microsoft/Multiplan_for_Tandy_100_1984_Microsoft.pdf

Re: [M100] REX# and Option ROMs: Qs from a noob

[Charles Hudson]

Interestingly, found this email archive while nosing around:
https://m100.bitchin100.narkive.com/yM6Z1vcJ/spreadsheet-program-for-model-100

Rick Hansons's advice:  "Download the
files as if they were .txt files to your PC, then move them over to your
Model "T" as .do files, load them into BASIC and save them as .ba files "

Re: [M100] REX# and Option ROMs: Qs from a noob

[Greg Swallow]

I'll look in my old downloads. I think I might have a set. If not, may be able 
to create a set between John & I.

Jul 7, 2022 2:14:08 PM John R. Hogerhuis :

> I have original manuals but I know PDFs are around. And in general SuperROM 
> installs the usual way, I think CALL 63012,0 or similar. The keyboard 
> commands are generally guessable at least for THINK. But, documentation would 
> be better.
> 
> Anyone have links to PDFs?
> 
> -- John.

Re: [M100] REX# and Option ROMs: Qs from a noob

[John R. Hogerhuis]

I have original manuals but I know PDFs are around. And in general SuperROM
installs the usual way, I think CALL 63012,0 or similar. The keyboard
commands are generally guessable at least for THINK. But, documentation
would be better.

Anyone have links to PDFs?

-- John.

Re: [M100] REX# and Option ROMs: Qs from a noob

[Charles Hudson]

John or Joshua,

Thus far I have only found documentation for the UR2100 ROM, and that only
an overall description.  Specifics of operation of the TEXT and BASE
programs are still a mystery, e.g. how to call up a print menu.  Apparently
there is one but ...

As for the other ROMs I haven't found any docs in the M100 sphere.  Is
there another place to look?

Thanks,

-CH-

Re: [M100] REX# and Option ROMs: Qs from a noob

[John R. Hogerhuis]

>
>
> Try out SuperROM too. "Think" outliner is my #1 favorite model t program
after TEXT.

-- John.

> <#m_7172767600747353736_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: [M100] REX# and Option ROMs: Qs from a noob

[Charles Hudson]

Thanks, Joshua,

I found out more about the Intex HEX format and also found the
pre-converted ROMS at the end of the REX# Manager documentation.  I have
successfully installed the UR2100 ROM and created a text document with it;
I'm making my way, slowly.

Thanks again for your help.

-CH-


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [M100] REX# and Option ROMs: Qs from a noob

[Joshua O'Keefe]

> On Jul 6, 2022, at 5:53 AM, Charles Hudson  wrote:
> I found the OR files at http://www.club100.org/library/librom.html and 
> inspected a few.  Immediately I was out of my depth, so pardon me for 
> inquiring:

Hi Charles,

I'd suggest you might want to start with the binary files at 
http://bitchin100.com/wiki/index.php?title=REXsharp#Option_ROM_Images_for_Download
 as that's a pretty comprehensive slice of the ROMs out there which work with 
the device.  Conveniently, they are already converted from HEX format into the 
BY format used by the REXMGR.

[M100] REX# and Option ROMs: Qs from a noob

[Charles Hudson]

Late to the party, I just got my REX# installed and have managed to
communicate with a PC running Laddie Alpha from a T102.  Reading the REX
Manager User Guide (
https://bitchin100.com/wiki/index.php?title=REX_Manager_User_Guide_for_REXsharp)
I am now interested in loading one of the option ROMs mentioned in the text.

I found the OR files at http://www.club100.org/library/librom.html and
inspected a few.  Immediately I was out of my depth, so pardon me for
inquiring:

The files are text files in a format named .HEX, which appears to be a
combination of addresses and values, but I'm not sure how much is address
and how much is memory value.  I'm also not sure what program translates
this format into something the T102 can understand or if they are intended
to be loaded as-is.  (My HEX editor misunderstands them; includes
colon-prefixed addresses as memory values)  Additionally, the file contents
themselves do not suggest what the ROM is supposed to be used for, and in
some cases I can't figure it out from the title, either.  MULTIPLAN, OK;
but BOOSTER PACK?

As it happens I have the Interactive Solutions ROM, v.1.0, in the form of
an IC currently installed in another T102.  As an exercise it might be
interesting to read this ROM.  I could create a binary or hex file from its
contents but have no idea how to put it into the Club 100's format.

Thanks for any info...

-CH-




Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [M100] REX question

[Stephen Adolph]

Teeny?

On Thursday, July 8, 2021, Tom Wilson  wrote:

> Right, you don’t need TS-DOS, but you need *something* with the ability
> to load files from a TPDD compatible device. If you have an actual TPDD,
> you can use the bootstrap function, otherwise you have to find a program
> that can be used to bootstrap the necessary files.
>
> That was the challenge - finding a program that could do the job on the
> T200.
>
> On Thu, Jul 8, 2021 at 4:05 PM Josh Malone  wrote:
>
>> I've been informed that you don't actually need TS-DOS loaded to flash
>> a REX -- just something to load the flash utility. Teeny will do.
>>
>> On Thu, Jul 8, 2021 at 6:38 PM Tom Wilson  wrote:
>> >
>> > Yes, I have flashed a Rex Classic to work on a 200. It’s a PITA, mostly
>> to get the DOS boot loader on so I can get the TS-DOS ROM loaded. The
>> problem being that with only 24K of RAM per bank, it’s hard to find a BASIC
>> loader small enough to do the job.
>> >
>> > If you need me to, I can dig through my archive and find the program I
>> used.
>> >
>> > On Thu, Jul 8, 2021 at 1:18 PM Josh Malone 
>> wrote:
>> >>
>> >> REX classic and REX# come in 2 "flavors": 100/102 and 200
>> >>
>> >> The hardware is physically identical, as is the CPLD program. However,
>> >> the FLASH load is different, owing to the different memory
>> >> configurations/maps on the 2 systems. You can "reprogram" a 100/102
>> >> into a 200 and vice-versa by following the initial programming steps
>> >> and doing a "wipe and reload". At least, you can on the REX classic.
>> >> I've never done it on REX# so check the wiki pages.
>> >>
>> >> -Josh
>> >>
>> >> On Thu, Jul 8, 2021 at 2:55 PM Bill Miranda 
>> wrote:
>> >> >
>> >> > Is REX module interchangeable between model 100 and model 102?
>> >> >
>> >> > Thanks!
>> >> >
>> >> > Bill
>> >
>> > --
>> > Tom Wilson
>> > wilso...@gmail.com
>> > (619)940-6311
>> >
>>
> --
> Tom Wilson
> wilso...@gmail.com
> (619)940-6311
>
>

Re: [M100] REX question

[Tom Wilson]

Right, you don’t need TS-DOS, but you need *something* with the ability to
load files from a TPDD compatible device. If you have an actual TPDD, you
can use the bootstrap function, otherwise you have to find a program that
can be used to bootstrap the necessary files.

That was the challenge - finding a program that could do the job on the
T200.

On Thu, Jul 8, 2021 at 4:05 PM Josh Malone  wrote:

> I've been informed that you don't actually need TS-DOS loaded to flash
> a REX -- just something to load the flash utility. Teeny will do.
>
> On Thu, Jul 8, 2021 at 6:38 PM Tom Wilson  wrote:
> >
> > Yes, I have flashed a Rex Classic to work on a 200. It’s a PITA, mostly
> to get the DOS boot loader on so I can get the TS-DOS ROM loaded. The
> problem being that with only 24K of RAM per bank, it’s hard to find a BASIC
> loader small enough to do the job.
> >
> > If you need me to, I can dig through my archive and find the program I
> used.
> >
> > On Thu, Jul 8, 2021 at 1:18 PM Josh Malone 
> wrote:
> >>
> >> REX classic and REX# come in 2 "flavors": 100/102 and 200
> >>
> >> The hardware is physically identical, as is the CPLD program. However,
> >> the FLASH load is different, owing to the different memory
> >> configurations/maps on the 2 systems. You can "reprogram" a 100/102
> >> into a 200 and vice-versa by following the initial programming steps
> >> and doing a "wipe and reload". At least, you can on the REX classic.
> >> I've never done it on REX# so check the wiki pages.
> >>
> >> -Josh
> >>
> >> On Thu, Jul 8, 2021 at 2:55 PM Bill Miranda 
> wrote:
> >> >
> >> > Is REX module interchangeable between model 100 and model 102?
> >> >
> >> > Thanks!
> >> >
> >> > Bill
> >
> > --
> > Tom Wilson
> > wilso...@gmail.com
> > (619)940-6311
> >
>
-- 
Tom Wilson
wilso...@gmail.com
(619)940-6311

Re: [M100] REX question

[Josh Malone]

I've been informed that you don't actually need TS-DOS loaded to flash
a REX -- just something to load the flash utility. Teeny will do.

On Thu, Jul 8, 2021 at 6:38 PM Tom Wilson  wrote:
>
> Yes, I have flashed a Rex Classic to work on a 200. It’s a PITA, mostly to 
> get the DOS boot loader on so I can get the TS-DOS ROM loaded. The problem 
> being that with only 24K of RAM per bank, it’s hard to find a BASIC loader 
> small enough to do the job.
>
> If you need me to, I can dig through my archive and find the program I used.
>
> On Thu, Jul 8, 2021 at 1:18 PM Josh Malone  wrote:
>>
>> REX classic and REX# come in 2 "flavors": 100/102 and 200
>>
>> The hardware is physically identical, as is the CPLD program. However,
>> the FLASH load is different, owing to the different memory
>> configurations/maps on the 2 systems. You can "reprogram" a 100/102
>> into a 200 and vice-versa by following the initial programming steps
>> and doing a "wipe and reload". At least, you can on the REX classic.
>> I've never done it on REX# so check the wiki pages.
>>
>> -Josh
>>
>> On Thu, Jul 8, 2021 at 2:55 PM Bill Miranda  wrote:
>> >
>> > Is REX module interchangeable between model 100 and model 102?
>> >
>> > Thanks!
>> >
>> > Bill
>
> --
> Tom Wilson
> wilso...@gmail.com
> (619)940-6311
>

Re: [M100] REX question

[Tom Wilson]

Yes, I have flashed a Rex Classic to work on a 200. It’s a PITA, mostly to
get the DOS boot loader on so I can get the TS-DOS ROM loaded. The problem
being that with only 24K of RAM per bank, it’s hard to find a BASIC loader
small enough to do the job.

If you need me to, I can dig through my archive and find the program I
used.

On Thu, Jul 8, 2021 at 1:18 PM Josh Malone  wrote:

> REX classic and REX# come in 2 "flavors": 100/102 and 200
>
> The hardware is physically identical, as is the CPLD program. However,
> the FLASH load is different, owing to the different memory
> configurations/maps on the 2 systems. You can "reprogram" a 100/102
> into a 200 and vice-versa by following the initial programming steps
> and doing a "wipe and reload". At least, you can on the REX classic.
> I've never done it on REX# so check the wiki pages.
>
> -Josh
>
> On Thu, Jul 8, 2021 at 2:55 PM Bill Miranda 
> wrote:
> >
> > Is REX module interchangeable between model 100 and model 102?
> >
> > Thanks!
> >
> > Bill
>
-- 
Tom Wilson
wilso...@gmail.com
(619)940-6311

Re: [M100] REX question

[Bill Miranda]

Thank you Josh and Brian

On Thu, Jul 8, 2021 at 2:25 PM Brian Brindle  wrote:

> Hi Bill,
>
> Yes, you can use the same REX in a model 100 or 102.
>
> If they are mod100/102's have the same amount of memory you will have no
> issues with stored RAM Images, but if they are different you will get a
> memory size mismatch when attempting to load them. Easy to fix using the
> file browse feature and creating a new Image though.
>
> Brian
>
>
> On Thu, Jul 8, 2021 at 2:55 PM Bill Miranda 
> wrote:
>
>> Is REX module interchangeable between model 100 and model 102?
>>
>> Thanks!
>>
>> Bill
>>
>

Re: [M100] REX question

[Brian Brindle]

Hi Bill,

Yes, you can use the same REX in a model 100 or 102.

If they are mod100/102's have the same amount of memory you will have no
issues with stored RAM Images, but if they are different you will get a
memory size mismatch when attempting to load them. Easy to fix using the
file browse feature and creating a new Image though.

Brian


On Thu, Jul 8, 2021 at 2:55 PM Bill Miranda  wrote:

> Is REX module interchangeable between model 100 and model 102?
>
> Thanks!
>
> Bill
>

Re: [M100] REX question

[Stephen Adolph]

Bill,
REX# and it's predecessor REX can be installed in either M100 or T102.
Meaning you buy an M100 version, you can use it in T102 also, and move it
between the 2 if you want.
I don't make REX anymore.  I have switched to the new design REX#.   If you
really want the old version others will make it for you, or you can roll
your own too.
cheers
Steve


On Thu, Jul 8, 2021 at 2:55 PM Bill Miranda  wrote:

> Is REX module interchangeable between model 100 and model 102?
>
> Thanks!
>
> Bill
>

Re: [M100] REX question

[Josh Malone]

REX classic and REX# come in 2 "flavors": 100/102 and 200

The hardware is physically identical, as is the CPLD program. However,
the FLASH load is different, owing to the different memory
configurations/maps on the 2 systems. You can "reprogram" a 100/102
into a 200 and vice-versa by following the initial programming steps
and doing a "wipe and reload". At least, you can on the REX classic.
I've never done it on REX# so check the wiki pages.

-Josh

On Thu, Jul 8, 2021 at 2:55 PM Bill Miranda  wrote:
>
> Is REX module interchangeable between model 100 and model 102?
>
> Thanks!
>
> Bill

[M100] REX question

[Bill Miranda]

Is REX module interchangeable between model 100 and model 102?

Thanks!

Bill

Re: [M100] REX# Version 2 software update.

[Stephen Adolph]

Folks,
A bug was found in REXCPM Version 2, that also affects REX# Version 2.

I have a fix in hand, so I will be posting an update later tonight or
tomorrow.

Summary of the bug:
* when copying a RAM image to system memory from REX#, you cannot start
BASIC or TEXT.
* work around is to press RESET and carry on.

issue resolved in build 13.

Steve

On Thu, Jan 7, 2021 at 9:47 PM Stephen Adolph  wrote:

> Many delays for this, sorry to those who've been waiting for me to get
> this done.
>
> I have posted an update to REX# at the Bitchin100 Wiki.
> Version 2 provides
> * integrated VT100 video driver (for M100/T102)
> * multi-bank (for T200 and NEC)
> * new quick menu key stroke CNTL-A to start REXMGR
> not to mention a major bug fix.
>
> Due to the *major bug* I do suggest people do the upgrade, but also I
> suggest saving off to external storage any important RAM images or other
> data!
>
> Information is posted here:
>
>
> http://bitchin100.com/wiki/index.php?title=REXsharp#Use_with_MVT100_external_Video
>
> http://bitchin100.com/wiki/index.php?title=Integrated_VT100_driver
>
> Thanks to COVID lockdown, I have been able to invest a lot of time in
> development and testing.
> I have really put in some time and I hope that upgrades go smoothly.
>
> I have created new tools that I hope are more user friendly.
>
> For those of you with REX#, just download the REX# upgrade utility, and
> the new software image.  Both are posted at the link above.
>
> My utilities are now are ASCII .DO files, and 7bit, so they can be loaded
> correctly more easily and reliably.  No need to transfer as a .CO, with
> some of the hassle that entails.
>
> I do rely on feedback when things don't work because I really can't
> possibly test everything!  So, thanks in advance for your feedback.
>
> Lastly, I will be posting the similar update for REXCPM.  So Version 2
> REXCPM software with integrated VT100 is on it's way.
>
> thanks,
> Steve
>
>
>

Re: [M100] REX# Version 2 software update.

[David Grissom]

Hi Steve,

I am looking forward to the updates on the REXCPM.

The current version has performed flawlessly for me since your last update.

Thanks for your fine work!

DG

Sent from Mail for Windows 10

From: Stephen Adolph
Sent: Thursday, January 7, 2021 8:49 PM
To: m...@bitchin100.com
Subject: Re: [M100] REX# Version 2 software update.

Oh forgot one thing.
I have updated the option rom .ZIP files posted there, to include Kurt's 
bug-fix versions of TS-DOS for M100, T200 and NEC.  
cheers, and thanks again Kurt.
Steve

Re: [M100] REX# Version 2 software update.

[Stephen Adolph]

Oh forgot one thing.
I have updated the option rom .ZIP files posted there, to include Kurt's
bug-fix versions of TS-DOS for M100, T200 and NEC.
cheers, and thanks again Kurt.
Steve


On Thu, Jan 7, 2021 at 9:47 PM Stephen Adolph  wrote:

> Many delays for this, sorry to those who've been waiting for me to get
> this done.
>
> I have posted an update to REX# at the Bitchin100 Wiki.
> Version 2 provides
> * integrated VT100 video driver (for M100/T102)
> * multi-bank (for T200 and NEC)
> * new quick menu key stroke CNTL-A to start REXMGR
> not to mention a major bug fix.
>
> Due to the *major bug* I do suggest people do the upgrade, but also I
> suggest saving off to external storage any important RAM images or other
> data!
>
> Information is posted here:
>
>
> http://bitchin100.com/wiki/index.php?title=REXsharp#Use_with_MVT100_external_Video
>
> http://bitchin100.com/wiki/index.php?title=Integrated_VT100_driver
>
> Thanks to COVID lockdown, I have been able to invest a lot of time in
> development and testing.
> I have really put in some time and I hope that upgrades go smoothly.
>
> I have created new tools that I hope are more user friendly.
>
> For those of you with REX#, just download the REX# upgrade utility, and
> the new software image.  Both are posted at the link above.
>
> My utilities are now are ASCII .DO files, and 7bit, so they can be loaded
> correctly more easily and reliably.  No need to transfer as a .CO, with
> some of the hassle that entails.
>
> I do rely on feedback when things don't work because I really can't
> possibly test everything!  So, thanks in advance for your feedback.
>
> Lastly, I will be posting the similar update for REXCPM.  So Version 2
> REXCPM software with integrated VT100 is on it's way.
>
> thanks,
> Steve
>
>
>

[M100] REX# Version 2 software update.

[Stephen Adolph]

Many delays for this, sorry to those who've been waiting for me to get this
done.

I have posted an update to REX# at the Bitchin100 Wiki.
Version 2 provides
* integrated VT100 video driver (for M100/T102)
* multi-bank (for T200 and NEC)
* new quick menu key stroke CNTL-A to start REXMGR
not to mention a major bug fix.

Due to the *major bug* I do suggest people do the upgrade, but also I
suggest saving off to external storage any important RAM images or other
data!

Information is posted here:

http://bitchin100.com/wiki/index.php?title=REXsharp#Use_with_MVT100_external_Video

http://bitchin100.com/wiki/index.php?title=Integrated_VT100_driver

Thanks to COVID lockdown, I have been able to invest a lot of time in
development and testing.
I have really put in some time and I hope that upgrades go smoothly.

I have created new tools that I hope are more user friendly.

For those of you with REX#, just download the REX# upgrade utility, and the
new software image.  Both are posted at the link above.

My utilities are now are ASCII .DO files, and 7bit, so they can be loaded
correctly more easily and reliably.  No need to transfer as a .CO, with
some of the hassle that entails.

I do rely on feedback when things don't work because I really can't
possibly test everything!  So, thanks in advance for your feedback.

Lastly, I will be posting the similar update for REXCPM.  So Version 2
REXCPM software with integrated VT100 is on it's way.

thanks,
Steve

Re: [M100] REX Classic Message

[Peter Noeth]

Stephen,

  O.K. that would make sense. I have R2C (ROM II / Cleuseau) as my OPTION
ROM but not initialized. I did initialize it a while back to test the
"extraneous space" removal function in Cleuseau and then disabled it. I am
sure that the Image I swapped into RAM never had Cleuseau running.

  Mostly I use the "re-number" function of ROM II, but that only requires a
call to 911, and then it exits back to the System ROM.

  I don't think your documentation lists the REX messages and what they
mean. The usual messages are obvious, but sometimes a message occurs so
quickly a person can't read it (even though the operation of REX is correct
and not an error).

Thanks and regards,

Peter



>
> --
>
> Message: 9
> Date: Sun, 3 Jan 2021 07:12:52 -0500
> From: Stephen Adolph 
> To: m...@bitchin100.com
> Subject: Re: [M100] REX Classic Message
> Message-ID:
> <
> camcmnv6osoajacjkbebm+cw0vzsm0btfeiasjmzfvd7e42q...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> it is a message telling you that the system software hooks changed.  This
> is just informative; Option ROMs often install their own hooks to do
> certain things, like removal of their software when the ROM is "removed".
>
> I think this sequence of events can cause the hooks to change, and display
> the message.
> 1) load up and run R2C100.
> 2) switch to TS-DOS
>
> On Sun, Jan 3, 2021 at 12:09 AM Peter Noeth  wrote:
>
> > I ran REXMGR in REX classic to swap an image into RAM today (t102), and
> > after the screen cleared, before the System Menu displayed, I got a
> message
> > that flickered quickly at the bottom of the display. It was unexpected,
> but
> > I think it started with "** System".
> >
> > I know REX Classic is not being supported anymore, but could someone tell
> > me what it said. I didn't change the System Date (year) before I ran
> > REXMGR, so I am not sure if this had anything to do with it or not. There
> > were no "High Memory" drivers loaded in the image or the current contents
> > of RAM when I swapped images.
> >
> > Regards,
> >
> > Peter
> >
> 

Re: [M100] REX Classic Message

[Stephen Adolph]

it is a message telling you that the system software hooks changed.  This
is just informative; Option ROMs often install their own hooks to do
certain things, like removal of their software when the ROM is "removed".

I think this sequence of events can cause the hooks to change, and display
the message.
1) load up and run R2C100.
2) switch to TS-DOS

On Sun, Jan 3, 2021 at 12:09 AM Peter Noeth  wrote:

> I ran REXMGR in REX classic to swap an image into RAM today (t102), and
> after the screen cleared, before the System Menu displayed, I got a message
> that flickered quickly at the bottom of the display. It was unexpected, but
> I think it started with "** System".
>
> I know REX Classic is not being supported anymore, but could someone tell
> me what it said. I didn't change the System Date (year) before I ran
> REXMGR, so I am not sure if this had anything to do with it or not. There
> were no "High Memory" drivers loaded in the image or the current contents
> of RAM when I swapped images.
>
> Regards,
>
> Peter
>
>
>

[M100] REX Classic Message

[Peter Noeth]

I ran REXMGR in REX classic to swap an image into RAM today (t102), and
after the screen cleared, before the System Menu displayed, I got a message
that flickered quickly at the bottom of the display. It was unexpected, but
I think it started with "** System".

I know REX Classic is not being supported anymore, but could someone tell
me what it said. I didn't change the System Date (year) before I ran
REXMGR, so I am not sure if this had anything to do with it or not. There
were no "High Memory" drivers loaded in the image or the current contents
of RAM when I swapped images.

Regards,

Peter

Re: [M100] REX update questions (probably only answerable by Stephen)

[Stephen Adolph]

Sure send the RAM image.  I'll check it out in Virtual T (the prototype
that I have that supports REX# and REXCPM- hopefully that will get released
at some point.  As is par for the course with me, I introduced a bug or 2
into the prototype but heck it was my first ever C programming).


On Mon, Dec 21, 2020 at 3:38 AM Jim Anderson  wrote:

> > -Original Message-
> >
> > Active block is always first, does seem to fit what is happening? I just
> > checked on my end and it seems to be working.  Active block first, then
> > sorted by date/time.
>
> Yes, it shows the active block first as always, it's the rest of the
> entries which aren't sorting.  When I applied the 43 update each image had
> a bogus date/time (something like 63/12/15, I don't remember exactly) but
> I've cycled through each of them and they all now have a date/time stamp
> from some time in the last two days, however the sort order remains exactly
> the same sequence as always regardless of the date/time attached to each
> image.
>
> If it might be helpful for you to look at, I could make a backup of the
> REX area of my REXCPM and send you a link to the backup file to try it on
> your system.
>
>
> BTW, I thought I'd mention that after rebuilding and reloading the other
> machine with the REX classic, at some point after filling up the OPTROMs
> and RAM images I noticed that the SYSTEM# entry has re-appeared in the
> OPTROM image list.  When I hit B it says it refers to block 0.  I recall
> now that the # indicates an image which is active in another bank (on my
> T200 REX) and I remember you saying you had added bank support (but I
> thought that was only in the new REX# release?)... anyhow, maybe this will
> help shed an additional clue as to what happened and/or why SYSTEM# is
> showing up in the menu now.
>
>
>
>
>
>
>
> jim
>
>

Re: [M100] REX update questions (probably only answerable by Stephen)

[Jim Anderson]

> -Original Message-
> 
> Active block is always first, does seem to fit what is happening? I just
> checked on my end and it seems to be working.  Active block first, then
> sorted by date/time.

Yes, it shows the active block first as always, it's the rest of the entries 
which aren't sorting.  When I applied the 43 update each image had a bogus 
date/time (something like 63/12/15, I don't remember exactly) but I've cycled 
through each of them and they all now have a date/time stamp from some time in 
the last two days, however the sort order remains exactly the same sequence as 
always regardless of the date/time attached to each image.

If it might be helpful for you to look at, I could make a backup of the REX 
area of my REXCPM and send you a link to the backup file to try it on your 
system.


BTW, I thought I'd mention that after rebuilding and reloading the other 
machine with the REX classic, at some point after filling up the OPTROMs and 
RAM images I noticed that the SYSTEM# entry has re-appeared in the OPTROM image 
list.  When I hit B it says it refers to block 0.  I recall now that the # 
indicates an image which is active in another bank (on my T200 REX) and I 
remember you saying you had added bank support (but I thought that was only in 
the new REX# release?)... anyhow, maybe this will help shed an additional clue 
as to what happened and/or why SYSTEM# is showing up in the menu now.







jim

Re: [M100] REX update questions (probably only answerable by Stephen)

[Stephen Adolph]

Active block is always first, does seem to fit what is happening? I just
checked on my end and it seems to be working.  Active block first, then
sorted by date/time.

Sorry about the rebuild.  Every time I think I have a robust working
solution



On Sun, Dec 20, 2020 at 4:39 PM Jim Anderson  wrote:

> > -Original Message-
> >
> > I see you understand "S" not "O".  I've checked it out on my end and it
> > was working.  If the date/time stamps are the same, sort order won't
> > change.
>
> The sort order does change with each press of S (reverse and forwards),
> it's just that the sort order is something other than by date/time and
> seems to be the same order the entries appeared in before the update.
> Images dated Dec 20th appear in the middle of the list, surrounded on
> either side by entries dated the 19th bearing various timestamps (also not
> in sequence by time).  Hopefully that's clear.
>
>
>
>
>
>
>
> jim
>
>

Re: [M100] REX update questions (probably only answerable by Stephen)

[Jim Anderson]

> -Original Message-
> 
> I see you understand "S" not "O".  I've checked it out on my end and it
> was working.  If the date/time stamps are the same, sort order won't
> change.

The sort order does change with each press of S (reverse and forwards), it's 
just that the sort order is something other than by date/time and seems to be 
the same order the entries appeared in before the update.  Images dated Dec 
20th appear in the middle of the list, surrounded on either side by entries 
dated the 19th bearing various timestamps (also not in sequence by time).  
Hopefully that's clear.







jim

Re: [M100] REX update questions (probably only answerable by Stephen)

[Jim Anderson]

> -Original Message-
> 
> Re REXclassic: sounds like your directory is corrupted at first
> glance.  I would do a full rebuild, not just the software.
> Let me know if you cannot find the tools you need.

Argh... OK, yeah, hard lesson about backup-before-trying-something-new learned 
(again).  It's hardly the first time.  :(  I was just hoping there might be 
some flag that could be flipped or reset to point back at the block containing 
the TS-DOS image or something.

Out of curiosity, is the SYSTEM# entry supposed to be visible in the OPTROM 
list when accessed via Ctrl-O from the M100's menu?  What does it do?







jim

Re: [M100] REX update questions (probably only answerable by Stephen)

[Stephen Adolph]

I see you understand "S" not "O".  I've checked it out on my end and it was
working.  If the date/time stamps are the same, sort order won't change.

Anyhow, I will check it again.
steve

On Sun, Dec 20, 2020 at 4:25 PM Stephen Adolph  wrote:

> re REXCPM  - S changes the sort order!
>
> Re REXclassic: sounds like your directory is corrupted at first glance.  I
> would do a full rebuild, not just the software.
> Let me know if you cannot find the tools you need.
> cheers, steve
>
>
>
> On Sun, Dec 20, 2020 at 3:05 PM Jim Anderson  wrote:
>
>> I recently applied the 260 update to two of my REX classics and the 43
>> update to my REXCPM.  Two questions:
>>
>> REXCPM - I see a date and time stamp on the images now, awesome!
>> However, for me the images are still being sorted by their original order
>> (I think it's the order in which the images were created) even though I've
>> cycled through all of them and they all now have an valid date/time stamp
>> (they started with garbage date/time data after the update, of course).
>> Press O to change sort order only reverses the original sort order back and
>> forth.  Is there a trick to it?  Do I have to offload, delete, and re-load
>> them?
>>
>> REX classic - I was using my T102 this morning and hit Ctrl-O from the
>> main screen to change option ROM images.  I noticed the last image in the
>> list was something I hadn't seen before, named SYSTEM#, and out of
>> curiosity I selected it.  Well, you know what they say about curiosity and
>> cats... my T102 locked up solid and the Reset button wouldn't recover it.
>> Ctrl-Break-Reset will do a cold reset, but as soon as I CALL 63012 it locks
>> up solid again.  Powering off and on doesn't help, removing and
>> reinstalling the REX doesn't help.  I guess I'll have to try doing the 260
>> update again (and if that doesn't help, the full 260 reinstall...) but I
>> wanted to find out what SYSTEM# is and why it locked REX up tight.
>> (Perhaps it's not meant to show in the list?)
>>
>>
>>
>>
>>
>>
>>
>> jim
>>
>>

Re: [M100] REX update questions (probably only answerable by Stephen)

[Stephen Adolph]

re REXCPM  - S changes the sort order!

Re REXclassic: sounds like your directory is corrupted at first glance.  I
would do a full rebuild, not just the software.
Let me know if you cannot find the tools you need.
cheers, steve



On Sun, Dec 20, 2020 at 3:05 PM Jim Anderson  wrote:

> I recently applied the 260 update to two of my REX classics and the 43
> update to my REXCPM.  Two questions:
>
> REXCPM - I see a date and time stamp on the images now, awesome!  However,
> for me the images are still being sorted by their original order (I think
> it's the order in which the images were created) even though I've cycled
> through all of them and they all now have an valid date/time stamp (they
> started with garbage date/time data after the update, of course).  Press O
> to change sort order only reverses the original sort order back and forth.
> Is there a trick to it?  Do I have to offload, delete, and re-load them?
>
> REX classic - I was using my T102 this morning and hit Ctrl-O from the
> main screen to change option ROM images.  I noticed the last image in the
> list was something I hadn't seen before, named SYSTEM#, and out of
> curiosity I selected it.  Well, you know what they say about curiosity and
> cats... my T102 locked up solid and the Reset button wouldn't recover it.
> Ctrl-Break-Reset will do a cold reset, but as soon as I CALL 63012 it locks
> up solid again.  Powering off and on doesn't help, removing and
> reinstalling the REX doesn't help.  I guess I'll have to try doing the 260
> update again (and if that doesn't help, the full 260 reinstall...) but I
> wanted to find out what SYSTEM# is and why it locked REX up tight.
> (Perhaps it's not meant to show in the list?)
>
>
>
>
>
>
>
> jim
>
>

Re: [M100] REX update questions (probably only answerable by Stephen)

[Jim Anderson]

A couple of additional notes:

> update, of course).  Press O to change sort order only reverses the

OCD self-nitpick: I meant S, not O.  :)

> and cats... my T102 locked up solid and the Reset button wouldn't

Amendment: I noticed a couple of additional things.

- Although the Reset button won't recover the machine from the state it's in, 
pressing Ctrl-Break (note: NOT Shift-Break) will immediately cold-reset the 
T102 from this state, without touching the Reset button.

- When I execute CALL 63012 after a cold reset, the first half of whatever text 
is on the first line on the LCD clears, followed about a second later by the 
second half.  After that, nothing happens (except the aforementioned Ctrl-Break 
weirdness).

- I have re-applied the 260 update and it still behaves the same way.  I would 
strongly prefer not to have to use the full-reset version of the 260 update if 
I don't have to (I have most of the images backed up, but not all are current 
of course...), I'm hoping there is some way to reset whatever flag I've 
inadvertently set in the flash by choosing that SYSTEM# entry, since it seems 
to be trying to go back to whatever that points to every time and failing.

REALLY REALLY REALLY hoping these symptoms give you an 'a-ha!' moment, Stephen. 
 :)







jim

[M100] REX update questions (probably only answerable by Stephen)

[Jim Anderson]

I recently applied the 260 update to two of my REX classics and the 43 update 
to my REXCPM.  Two questions:

REXCPM - I see a date and time stamp on the images now, awesome!  However, for 
me the images are still being sorted by their original order (I think it's the 
order in which the images were created) even though I've cycled through all of 
them and they all now have an valid date/time stamp (they started with garbage 
date/time data after the update, of course).  Press O to change sort order only 
reverses the original sort order back and forth.  Is there a trick to it?  Do I 
have to offload, delete, and re-load them?

REX classic - I was using my T102 this morning and hit Ctrl-O from the main 
screen to change option ROM images.  I noticed the last image in the list was 
something I hadn't seen before, named SYSTEM#, and out of curiosity I selected 
it.  Well, you know what they say about curiosity and cats... my T102 locked up 
solid and the Reset button wouldn't recover it.  Ctrl-Break-Reset will do a 
cold reset, but as soon as I CALL 63012 it locks up solid again.  Powering off 
and on doesn't help, removing and reinstalling the REX doesn't help.  I guess 
I'll have to try doing the 260 update again (and if that doesn't help, the full 
260 reinstall...) but I wanted to find out what SYSTEM# is and why it locked 
REX up tight.  (Perhaps it's not meant to show in the list?)







jim

[M100] REX# and REXCPM updates

[Stephen Adolph]

just an FYI,
I have a beta release of both REX# and REXCPM out there now, being verified.
The same issue that was affecting REXCPM also affected REX#.

Also, I have added "date/time" and "sort" into the code for REXCPM, since I
did get feedback that it was missed.

I plan to post those updates + revised, more robust and user friendly
utilities, at the wiki, shortly.

cheers
Steve

Re: [M100] REX# erratic behavior and data corruption

[Stephen Adolph]

David,
I'll send you the test program to run so you can confirm if your REX# has a
hardware issue.
..Steve

On Tue, Nov 10, 2020 at 8:01 AM David Kinzler  wrote:

> I'd like to first acknowledge that I'm a new Model 100 user, and I suspect
> user error is a large component of my woes.
>
> Basically, after installing my new REX#, I've been experiencing data loss
> and erratic behavior. I've played with it entirely too long, and I reliably
> experience severe corruption that even affects images that are not loaded.
> I've been in talks with Steven Adolph, and we've verified that the ROM is
> probably seated okay.
>
> I've seen all manner of things happen. Weirdest was the machine locked up
> and left the modem/cassette relay clicking. I've had BASIC lose the ability
> to use function keys. Programs have needed me to quit with the reset button
> on the back - F8 wouldn't work. I've repeatedly had my images get mixed up,
> e.g, if I have images named "work" and "play," the contents of play might
> suddenly appear in the "work" image and vice versa. In such a case,
> many/most programs will no longer run. BASIC programs will often just
> indicate "OK" when launched after such a fault. Text files seem unaffected
> corruption-wise -- a file that shows up loads into TEXT. I've also had
> spontaneous cold boots on launching an app that have not only cleared the
> active RAM but have also caused inactive images to appear empty when
> loaded. The image reassignment and corruption seems correlated with these
> cold boots. I also had the experience of using F6 in Rex Manager to copy a
> tokenized basic program to another bank. The program was around 12KB in
> size, but in the opposite pane the size showed up as around 4KB. The system
> became unusably erratic directly after I tried to launch the copied 4KB
> version.
>
> The unit was working to my expectation before installing the REX#. I think
> part of these issues is that I would only have a program or two loaded at a
> time because of RAM, and now I'm running into machine language conflicts
> between REX# and/or multiple programs with assembly routines. Is there any
> way to know whether a program needs REX# uninstalled before launching? How
> can I know which programs can co-exist without causing a cold-boot?
>
> I tried copying over just one program per image, and avoided launching any
> programs. I lost the contents of more than one image just switching from
> one of these banks to another. The banks pointed to data initially saved in
> another bank, and when I tried, I couldn't get a program to run on the
> machine.
>
> The last part suggests this isn't simply user error and a case of "It's a
> Model T! Don't do that!"
>

[M100] REX# erratic behavior and data corruption

[David Kinzler]

I'd like to first acknowledge that I'm a new Model 100 user, and I suspect
user error is a large component of my woes.

Basically, after installing my new REX#, I've been experiencing data loss
and erratic behavior. I've played with it entirely too long, and I reliably
experience severe corruption that even affects images that are not loaded.
I've been in talks with Steven Adolph, and we've verified that the ROM is
probably seated okay.

I've seen all manner of things happen. Weirdest was the machine locked up
and left the modem/cassette relay clicking. I've had BASIC lose the ability
to use function keys. Programs have needed me to quit with the reset button
on the back - F8 wouldn't work. I've repeatedly had my images get mixed up,
e.g, if I have images named "work" and "play," the contents of play might
suddenly appear in the "work" image and vice versa. In such a case,
many/most programs will no longer run. BASIC programs will often just
indicate "OK" when launched after such a fault. Text files seem unaffected
corruption-wise -- a file that shows up loads into TEXT. I've also had
spontaneous cold boots on launching an app that have not only cleared the
active RAM but have also caused inactive images to appear empty when
loaded. The image reassignment and corruption seems correlated with these
cold boots. I also had the experience of using F6 in Rex Manager to copy a
tokenized basic program to another bank. The program was around 12KB in
size, but in the opposite pane the size showed up as around 4KB. The system
became unusably erratic directly after I tried to launch the copied 4KB
version.

The unit was working to my expectation before installing the REX#. I think
part of these issues is that I would only have a program or two loaded at a
time because of RAM, and now I'm running into machine language conflicts
between REX# and/or multiple programs with assembly routines. Is there any
way to know whether a program needs REX# uninstalled before launching? How
can I know which programs can co-exist without causing a cold-boot?

I tried copying over just one program per image, and avoided launching any
programs. I lost the contents of more than one image just switching from
one of these banks to another. The banks pointed to data initially saved in
another bank, and when I tried, I couldn't get a program to run on the
machine.

The last part suggests this isn't simply user error and a case of "It's a
Model T! Don't do that!"

Re: [M100] REX Classic

[Gregory McGill]

:high five:glad it was something simple

On Fri, May 22, 2020 at 7:43 AM William McKay  wrote:

> You were correct.  I put a meter between the chip and the contacts and one
> was dead.  One of the pins in the option rom socket was not fully
> deployed.  The other rom’s I’ve used were able to connect but the REX could
> not.  After pulling the pin out to it’s correct location it work perfect.
>
>
>
> Thanks for the heads up on that issue.
>
> Framer
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Gregory McGill 
> *Sent: *Thursday, May 21, 2020 2:44 PM
> *To: *m...@bitchin100.com
> *Subject: *Re: [M100] REX Classic
>
>
>
> usually this is a contact issue..
>
>
>
>
>
> On Thu, May 21, 2020 at 10:52 AM Stephen Adolph 
> wrote:
>
> Hi,  hard to say.  what design is it?  Is it from me or other? (sorry if I
> don't recall)
>
> Steve
>
>
>
> On Thu, May 21, 2020 at 1:43 PM William McKay  wrote:
>
> I have two Model 100 USA model numbers and the same.  REX works perfect in
> one and hang when the call 63012 is issued and need a cold boot.  Both work
> perfect with other roms, Super and Lucid.
>
>
>
> Any ideas what might be causing this?
>
>
>
> Thanks
>
> framer
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
>
>

Re: [M100] REX Classic

[William McKay]

You were correct.  I put a meter between the chip and the contacts and one was 
dead.  One of the pins in the option rom socket was not fully deployed.  The 
other rom’s I’ve used were able to connect but the REX could not.  After 
pulling the pin out to it’s correct location it work perfect.

Thanks for the heads up on that issue.
Framer

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Gregory McGill<mailto:arcadeshop...@gmail.com>
Sent: Thursday, May 21, 2020 2:44 PM
To: m...@bitchin100.com<mailto:m...@bitchin100.com>
Subject: Re: [M100] REX Classic

usually this is a contact issue..


On Thu, May 21, 2020 at 10:52 AM Stephen Adolph 
mailto:twospru...@gmail.com>> wrote:
Hi,  hard to say.  what design is it?  Is it from me or other? (sorry if I 
don't recall)
Steve

On Thu, May 21, 2020 at 1:43 PM William McKay 
mailto:pfra...@outlook.com>> wrote:
I have two Model 100 USA model numbers and the same.  REX works perfect in one 
and hang when the call 63012 is issued and need a cold boot.  Both work perfect 
with other roms, Super and Lucid.

Any ideas what might be causing this?

Thanks
framer

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

Re: [M100] REX Classic

[Gregory McGill]

usually this is a contact issue..


On Thu, May 21, 2020 at 10:52 AM Stephen Adolph 
wrote:

> Hi,  hard to say.  what design is it?  Is it from me or other? (sorry if I
> don't recall)
> Steve
>
> On Thu, May 21, 2020 at 1:43 PM William McKay  wrote:
>
>> I have two Model 100 USA model numbers and the same.  REX works perfect
>> in one and hang when the call 63012 is issued and need a cold boot.  Both
>> work perfect with other roms, Super and Lucid.
>>
>>
>>
>> Any ideas what might be causing this?
>>
>>
>>
>> Thanks
>>
>> framer
>>
>>
>>
>> Sent from Mail  for
>> Windows 10
>>
>>
>>
>

Re: [M100] REX Classic

[Stephen Adolph]

Hi,  hard to say.  what design is it?  Is it from me or other? (sorry if I
don't recall)
Steve

On Thu, May 21, 2020 at 1:43 PM William McKay  wrote:

> I have two Model 100 USA model numbers and the same.  REX works perfect in
> one and hang when the call 63012 is issued and need a cold boot.  Both work
> perfect with other roms, Super and Lucid.
>
>
>
> Any ideas what might be causing this?
>
>
>
> Thanks
>
> framer
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>

[M100] REX Classic

[William McKay]

I have two Model 100 USA model numbers and the same.  REX works perfect in one 
and hang when the call 63012 is issued and need a cold boot.  Both work perfect 
with other roms, Super and Lucid.

Any ideas what might be causing this?

Thanks
framer

Sent from Mail for Windows 10

Re: [M100] REX 260 Updating

[Tom Wilson]

Awesome. Glad I could help.


On Fri, Apr 10, 2020 at 8:32 PM Peter Noeth  wrote:

> Tom,
>
>   Thanks for the instructions below. I wasn't sure about working with the
> TS-DOS in REX (I don't use TS-DOS other than the one time I loaded my
> OptROM image two years ago). The User Guide explained downloading OptROM
> images, but not firmware upgrades.
>
>   I ran the procedure below and everything worked. I also re-downloaded
> the ROMII OptROM image, and it is working.
>
>   Now I have to build the RAM images again and download the program files.
> I am doing it this way because I gathered from the discussion on the .DO
> files, that copying .DO files from old images could still be problematic
> with the new system. Maybe not, but a clean start can't hurt. Also a good
> time to do some file organization in the images.
>
> Peter
>
>
> --
>>
>> Message: 3
>> Date: Thu, 9 Apr 2020 23:21:47 -0700
>> From: Tom Wilson 
>> To: M100 Mailing List 
>> Subject: Re: [M100] REX 260 Updating
>> Message-ID:
>> <
>> calt8mqtrp6-ywlj+ij0k-pv5cu2fidpwe9pit6ztjomfb-g...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> So here's what I did...
>>
>> I started by extracting the ZIP file to the ROM100 directory under my
>> LaddieAlpha Root. (in my case, that's C:\Model 100\root\rom100)
>> So I have
>> RF149.CO
>> TSD100.BX
>> RF149.BR
>> Then I started LaddieAlpha.
>>
>> On my T102, I started RexMgr and activated TS-DOS.
>> F4 (DISK)
>> Select the ROM100 directory
>> Select RF149.CO, press F1 (Load)
>> > Here is where you'd want to back up your REX saves. I don't have
>> anything
>> worth backing up, so I'm okay with it wiping the whole module.
>>
>> You can't just launch RF149.CO... instead, start REXMGR and press F7. This
>> should kill the hook to REX.
>> Launch BASIC
>> CLEAR 0,55000
>> Exit BASIC
>> Run RF149.CO
>> You'll get a warning about wiping the REX software. Press Y to proceed.
>> At this point, the installer will start reading from your computer with
>> LaddieAlpha. It took me a minute or so to download (there is a progress
>> bar
>> in the lower right corner.)
>> After loading the new firmware, you'll end up back at the main menu. I
>> would suggest powering the machine off and back on again.
>> Start BASIC
>> CLEAR 0,MAXRAM (this releases the memory you reserved with the CLEAR
>> 0,55000 command.)
>> CALL 63012
>> After this, REXMGR should be present in the file list.
>> Refresh the default backup, then you can reload your backed-up images from
>> your PC using LaddieAlpha.
>>
>> That's it. You should have the latest REX firmware.
>>
>>
>>
>> On Thu, Apr 9, 2020 at 10:45 PM Peter Noeth  wrote:
>>
>> >   I am ready to update my REX to the latest firmware, but am not sure on
>> > how to proceed.
>> >
>> >   I read the information on the REX Wiki, and it says: "Load the rebuild
>> > tool: Load into RAM the RFx49.CO file using the TPDD device". How is
>> this
>> > done? I used LaddieAlpha to put the ROM2 option ROM image in my original
>> > REX, and I have instructions for that, but I don't use a TPDD device
>> with
>> > my T102, so am not sure what I need to get started on the T102 to be
>> able
>> > to transfer the .CO file to RAM. A step-by-step instruction would be
>> > helpful here.
>> >
>> >   I have downloaded the R49_M100T102_260_REBUILD.ZIP and extracted the
>> > files to the PC in the directory where LaddieAlpha is located. Just
>> need to
>> > know how to get the files needed into the T102 RAM to continue the REX
>> Wiki
>> > procedure.
>> >
>> > Thanks,
>> >
>> > Peter
>> >
>> 
>>
> --
Tom Wilson
wilso...@gmail.com
(619)940-6311
K6ABZ

Re: [M100] REX 260 Updating

[Peter Noeth]

Tom,

  Thanks for the instructions below. I wasn't sure about working with the
TS-DOS in REX (I don't use TS-DOS other than the one time I loaded my
OptROM image two years ago). The User Guide explained downloading OptROM
images, but not firmware upgrades.

  I ran the procedure below and everything worked. I also re-downloaded the
ROMII OptROM image, and it is working.

  Now I have to build the RAM images again and download the program files.
I am doing it this way because I gathered from the discussion on the .DO
files, that copying .DO files from old images could still be problematic
with the new system. Maybe not, but a clean start can't hurt. Also a good
time to do some file organization in the images.

Peter


--
>
> Message: 3
> Date: Thu, 9 Apr 2020 23:21:47 -0700
> From: Tom Wilson 
> To: M100 Mailing List 
> Subject: Re: [M100] REX 260 Updating
> Message-ID:
> <
> calt8mqtrp6-ywlj+ij0k-pv5cu2fidpwe9pit6ztjomfb-g...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> So here's what I did...
>
> I started by extracting the ZIP file to the ROM100 directory under my
> LaddieAlpha Root. (in my case, that's C:\Model 100\root\rom100)
> So I have
> RF149.CO
> TSD100.BX
> RF149.BR
> Then I started LaddieAlpha.
>
> On my T102, I started RexMgr and activated TS-DOS.
> F4 (DISK)
> Select the ROM100 directory
> Select RF149.CO, press F1 (Load)
> > Here is where you'd want to back up your REX saves. I don't have anything
> worth backing up, so I'm okay with it wiping the whole module.
>
> You can't just launch RF149.CO... instead, start REXMGR and press F7. This
> should kill the hook to REX.
> Launch BASIC
> CLEAR 0,55000
> Exit BASIC
> Run RF149.CO
> You'll get a warning about wiping the REX software. Press Y to proceed.
> At this point, the installer will start reading from your computer with
> LaddieAlpha. It took me a minute or so to download (there is a progress bar
> in the lower right corner.)
> After loading the new firmware, you'll end up back at the main menu. I
> would suggest powering the machine off and back on again.
> Start BASIC
> CLEAR 0,MAXRAM (this releases the memory you reserved with the CLEAR
> 0,55000 command.)
> CALL 63012
> After this, REXMGR should be present in the file list.
> Refresh the default backup, then you can reload your backed-up images from
> your PC using LaddieAlpha.
>
> That's it. You should have the latest REX firmware.
>
>
>
> On Thu, Apr 9, 2020 at 10:45 PM Peter Noeth  wrote:
>
> >   I am ready to update my REX to the latest firmware, but am not sure on
> > how to proceed.
> >
> >   I read the information on the REX Wiki, and it says: "Load the rebuild
> > tool: Load into RAM the RFx49.CO file using the TPDD device". How is this
> > done? I used LaddieAlpha to put the ROM2 option ROM image in my original
> > REX, and I have instructions for that, but I don't use a TPDD device with
> > my T102, so am not sure what I need to get started on the T102 to be able
> > to transfer the .CO file to RAM. A step-by-step instruction would be
> > helpful here.
> >
> >   I have downloaded the R49_M100T102_260_REBUILD.ZIP and extracted the
> > files to the PC in the directory where LaddieAlpha is located. Just need
> to
> > know how to get the files needed into the T102 RAM to continue the REX
> Wiki
> > procedure.
> >
> > Thanks,
> >
> > Peter
> >
> 
>

Re: [M100] REX 260 Updating

[Brian K. White]

To prove it to yourself, in REXMGR, on any screen, press "i".
4.9-260 for 100/102 is CS=DF79
Here's the last few builds for all 3 platforms:

REX versions
REXMGR info screen (press i)

4.9 build 254
  100  CS=DD90
  200  CS=0FEC
  NEC  CS=3CEC

4.9 build 258
  100  CS=E16C
  200  CS=1B0D
  NEC  CS=3C69

4.9 build 260
  100  CS=DF79
  200  CS=18BA
  NEC  CS=3B3E


On 4/10/20 2:21 AM, Tom Wilson wrote:

So here's what I did...

I started by extracting the ZIP file to the ROM100 directory under my 
LaddieAlpha Root. (in my case, that's C:\Model 100\root\rom100)

So I have
RF149.CO 
TSD100.BX
RF149.BR 
Then I started LaddieAlpha.

On my T102, I started RexMgr and activated TS-DOS.
F4 (DISK)
Select the ROM100 directory
Select RF149.CO , press F1 (Load)
 > Here is where you'd want to back up your REX saves. I don't have 
anything worth backing up, so I'm okay with it wiping the whole module.


You can't just launch RF149.CO... instead, start REXMGR and press F7. 
This should kill the hook to REX.

Launch BASIC
CLEAR 0,55000
Exit BASIC
Run RF149.CO 
You'll get a warning about wiping the REX software. Press Y to proceed.
At this point, the installer will start reading from your computer with 
LaddieAlpha. It took me a minute or so to download (there is a progress 
bar in the lower right corner.)
After loading the new firmware, you'll end up back at the main menu. I 
would suggest powering the machine off and back on again.

Start BASIC
CLEAR 0,MAXRAM (this releases the memory you reserved with the CLEAR 
0,55000 command.)

CALL 63012
After this, REXMGR should be present in the file list.
Refresh the default backup, then you can reload your backed-up images 
from your PC using LaddieAlpha.


That's it. You should have the latest REX firmware.



On Thu, Apr 9, 2020 at 10:45 PM Peter Noeth > wrote:


   I am ready to update my REX to the latest firmware, but am not
sure on how to proceed.

   I read the information on the REX Wiki, and it says: "Load the
rebuild tool: Load into RAM the RFx49.CO file using the TPDD
device". How is this done? I used LaddieAlpha to put the ROM2 option
ROM image in my original REX, and I have instructions for that, but
I don't use a TPDD device with my T102, so am not sure what I need
to get started on the T102 to be able to transfer the .CO file to
RAM. A step-by-step instruction would be helpful here.

   I have downloaded the R49_M100T102_260_REBUILD.ZIP and extracted
the files to the PC in the directory where LaddieAlpha is located.
Just need to know how to get the files needed into the T102 RAM to
continue the REX Wiki procedure.

Thanks,

Peter




--
bkw

Re: [M100] REX 260 Updating

[Tom Wilson]

So here's what I did...

I started by extracting the ZIP file to the ROM100 directory under my
LaddieAlpha Root. (in my case, that's C:\Model 100\root\rom100)
So I have
RF149.CO
TSD100.BX
RF149.BR
Then I started LaddieAlpha.

On my T102, I started RexMgr and activated TS-DOS.
F4 (DISK)
Select the ROM100 directory
Select RF149.CO, press F1 (Load)
> Here is where you'd want to back up your REX saves. I don't have anything
worth backing up, so I'm okay with it wiping the whole module.

You can't just launch RF149.CO... instead, start REXMGR and press F7. This
should kill the hook to REX.
Launch BASIC
CLEAR 0,55000
Exit BASIC
Run RF149.CO
You'll get a warning about wiping the REX software. Press Y to proceed.
At this point, the installer will start reading from your computer with
LaddieAlpha. It took me a minute or so to download (there is a progress bar
in the lower right corner.)
After loading the new firmware, you'll end up back at the main menu. I
would suggest powering the machine off and back on again.
Start BASIC
CLEAR 0,MAXRAM (this releases the memory you reserved with the CLEAR
0,55000 command.)
CALL 63012
After this, REXMGR should be present in the file list.
Refresh the default backup, then you can reload your backed-up images from
your PC using LaddieAlpha.

That's it. You should have the latest REX firmware.



On Thu, Apr 9, 2020 at 10:45 PM Peter Noeth  wrote:

>   I am ready to update my REX to the latest firmware, but am not sure on
> how to proceed.
>
>   I read the information on the REX Wiki, and it says: "Load the rebuild
> tool: Load into RAM the RFx49.CO file using the TPDD device". How is this
> done? I used LaddieAlpha to put the ROM2 option ROM image in my original
> REX, and I have instructions for that, but I don't use a TPDD device with
> my T102, so am not sure what I need to get started on the T102 to be able
> to transfer the .CO file to RAM. A step-by-step instruction would be
> helpful here.
>
>   I have downloaded the R49_M100T102_260_REBUILD.ZIP and extracted the
> files to the PC in the directory where LaddieAlpha is located. Just need to
> know how to get the files needed into the T102 RAM to continue the REX Wiki
> procedure.
>
> Thanks,
>
> Peter
>

Re: [M100] REX 260 Updating

[Tom Wilson]

If you're using LaddieAlpha, this is a TPDD device. So you just need to
back up all of your banks to your PC (through LaddieAlpha) then activate
the TSDOS ROM and use that to copy RFx49.CO to your T102.

I'm about to perform exactly the same process with my 102, so I'll try it
and get back to you once I test it.

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


On Thu, Apr 9, 2020 at 10:45 PM Peter Noeth  wrote:

>   I am ready to update my REX to the latest firmware, but am not sure on
> how to proceed.
>
>   I read the information on the REX Wiki, and it says: "Load the rebuild
> tool: Load into RAM the RFx49.CO file using the TPDD device". How is this
> done? I used LaddieAlpha to put the ROM2 option ROM image in my original
> REX, and I have instructions for that, but I don't use a TPDD device with
> my T102, so am not sure what I need to get started on the T102 to be able
> to transfer the .CO file to RAM. A step-by-step instruction would be
> helpful here.
>
>   I have downloaded the R49_M100T102_260_REBUILD.ZIP and extracted the
> files to the PC in the directory where LaddieAlpha is located. Just need to
> know how to get the files needed into the T102 RAM to continue the REX Wiki
> procedure.
>
> Thanks,
>
> Peter
>

[M100] REX 260 Updating

[Peter Noeth]

  I am ready to update my REX to the latest firmware, but am not sure on
how to proceed.

  I read the information on the REX Wiki, and it says: "Load the rebuild
tool: Load into RAM the RFx49.CO file using the TPDD device". How is this
done? I used LaddieAlpha to put the ROM2 option ROM image in my original
REX, and I have instructions for that, but I don't use a TPDD device with
my T102, so am not sure what I need to get started on the T102 to be able
to transfer the .CO file to RAM. A step-by-step instruction would be
helpful here.

  I have downloaded the R49_M100T102_260_REBUILD.ZIP and extracted the
files to the PC in the directory where LaddieAlpha is located. Just need to
know how to get the files needed into the T102 RAM to continue the REX Wiki
procedure.

Thanks,

Peter

[M100] REX NEC in PC-8300

[Brian K. White]

Is REX NEC supposed to work in a PC-8300?

On the one hand:
The REX docs only mention 8201 explicitly, and definitely the two 
machines have differences. And in my 8300 the rebuild installer locks up 
during erasing blocks, different block# each time. If use an 8201 to run 
the rebuilder and then move the working rex to the 8300, I can't load 
option rom images from disk into the rex. It starts and then crashes in 
the middle of loading the image.


On the other hand:
If use an 8201 to set up the REX and load some option roms into it, and 
then move it to the 8300, I can use it. REXMGR installs and runs, and I 
can switch between TS-DOS and UR2 option roms, and both roms work when 
selected.


--
bkw

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