Re: [M100] REXCPM and DVI

[Stephen Adolph]

however, what could work is to use an M100+DVI as a terminal, connected to
the REXCPM enabled M100, which is generating the video.  If you had 2 M100
computers that is.

On Mon, Aug 12, 2024 at 12:36 AM Stephen Adolph 
wrote:

> No, I don't think so.  Not quite sure what you are envisioning?  M100CPM
> uses serial for video.
> Dvi only works with BASIC, TEXT, TELCOM I think.
>
> Cheers
> Steve
>
> On Sunday, August 11, 2024, Tom Blum  wrote:
>
>> Hello,  can the DVI be used with REXCPM for 80x25 video out?
>>
>

Re: [M100] REXCPM and DVI

[Stephen Adolph]

No, I don't think so.  Not quite sure what you are envisioning?  M100CPM
uses serial for video.
Dvi only works with BASIC, TEXT, TELCOM I think.

Cheers
Steve

On Sunday, August 11, 2024, Tom Blum  wrote:

> Hello,  can the DVI be used with REXCPM for 80x25 video out?
>

[M100] REXCPM and DVI

[Tom Blum]

Hello,  can the DVI be used with REXCPM for 80x25 video out?

Re: [M100] REXCPM battery

[Brian K. White]

On 9/22/23 18:09, Brian White wrote:
> Took some measurements
>
> This is with the BAT54C diodes.
>
>
> While not installed in 100:
> BATT  2.99v
> RAM_RST  2.91v 7uA
> SRAM VCC  2.76v
>
>
> While installed in 100, power on, wall power, original tandy 6v adapter:
> RAM_RST  4.85v
> BATT, installed  3.0v
> BATT, not installed  3.65v 0.5uA
>



That was sent from my phone just to get the numbers down.

What I GET from it is,

> While not installed in 100:
> BATT  2.99v
> RAM_RST  2.91v 7uA
> SRAM VCC  2.76v

* Draws 7uA while being powered from the batteries alone.
* Almost no voltage drop from the battery to RAM_RST.
* Still very low voltage drop all the way to the actual vcc pin on the 
sram (vs just at the cap), so a simple battery life estimate based on 
just nominal mAh capacity and uA drain is correct with no unaccounted 
further drops.


> While installed in 100, power on, wall power, original tandy 6v adapter:
> RAM_RST  4.85v
> BATT+, batts installed  3.0v
> BATT+, batts not installed  3.65v 0.5uA

* 0.5uA reverse leakage through the BAT54C
* trying to pull the cells up not only over their nominal 3.0v but even 
over their actual measured brand new initial 3.2v.


And the datasheet for a CR1025 cell says "Max Rev Charg: 1 microampere"

So, in nice cool under 25c conditions there isn't a problem, but that 
0.5uA goes up over 1uA in temperatures that are still possible human 
environment ambient.
The risk is only while powered on, not while say, sitting in a hot car 
not being used.
Then again, unattended running 24/7 has always been a use case for these 
machines, like famously the EME Online Weather Logger setup. So it could 
actually be on and running in a pretty hot environment.


So I guess stick with the plan to call for BAV170 or other low reverse 
leakage diode.


Another thing I looked at, which also in the end resulted in no change: 
I read that tantalum caps have leakage current and maybe not ideal for 
long term battery standby applications.
So I removed the tantalum cap and still measured 7.4uA when powered from 
the battery.

So the drain is not from tantalum leakage current.

I was hoping for a possible hack to replace the tantalum with a ceramic 
to trade away some minutes of battery-change time for some more years of 
battery standby time.
But if it's still drawing over 7uA with no cap installed at all, then 
it's not going to get any better.


I can't believe the sram chip is drawing 7uA itself.
My REXCPM originally came with a CY62177EV30 whose datasheet says has a 
standby current of 3uA typical, max 25uA, so IT might possibly draw 
7-8uA, but I replaced that with a RMLV3216AGSA to upgrade it from 2M to 
4M, and that datasheet says the typical standby current is only 0.6uA, 
though when you look at the tables vs the summary in both sheets, they 
actually look like pretty similar min max range. They may both actually 
only draw about 1uA normally or up to 24-25 in worst case high temp.


There is at least a 3.3v voltage regulator and who knows what else 
besides just the sram being powered while on standby.


I thought maybe the 4 batteries was a little unnecessary overkill but I 
guess it's worth it after all, since even with all 4, the estimated life 
is still only about 2 years.
It would have been nice to go back to 2 cells and use the original big 
standard header pins (4 big pins still fits where the 3 pins were on the 
first version). Actually no reason I can't still just make an option for 
that.


So I think this is pretty much it, as good as it's gonna get without 
picking apart the rexcpm itself to identify some possible improvement to 
the standby mode, like cutting out the voltage regulator and switching 
over to a direct connection on standby, or maybe just replacing the 
regulator with some other model, maybe finding pullups/downs that could 
be replaced with higher value resistors, etc.


But 2 years is good enough to be worth doing I think, and the default 
hookup method without hacking a qwiic connector onto the rexcpm is easy 
enough.


bkw

[M100] REXCPM battery

[Brian White]

Took some measurements

This is with the BAT54C diodes.

While not installed in 100:
BATT  2.99v
RAM_RST  2.91v 7uA
SRAM VCC  2.76v


While installed in 100, power on, wall power, original tandy 6v adapter:
RAM_RST  4.85v
BATT, installed  3.0v
BATT, not installed  3.65v 0.5uA



bkw

Re: [M100] rexcpm battery

[Ken St. Cyr]

Yeah, that's one of the disadvantages of using schottkys - they do tend to leak 
more reverse current. I appreciate the offer to send me a BAV170. I regularly 
put in orders at Mouser, so I'll just add some to my cart when I do my next 
order. Very kind to offer, though 🙂

//Ken

From: M100  on behalf of Brian K. White 

Sent: Thursday, September 21, 2023 10:53 PM
To: m100@lists.bitchin100.com 
Subject: Re: [M100] rexcpm battery

I've been reading about charging protection for lithium coin cells, and
I think we might want to swap out the BAT54C for something with as
little reverse leakage as possible.

I thought a few uA wouldn't really matter, especially if only during
on/active time, and didn't worry about it, but I guess even that causes
the cells to die early and only last a few months instead of years.

So I think you should not use the BAT54C from the original BOM and use
maybe BAV170 instead:
https://www.digikey.com/en/products/detail/diodes-incorporated/BAV170-7-F/822819

or any of these:
https://www.digikey.com/short/q9bfjch5

This was my other pick:
https://www.digikey.com/en/products/detail/central-semiconductor-corp/CMPD6001C-TR-PBFREE/5325257
Lowest reverse leakage but a little higher forward voltage drop and also
more expensive.
Probably neither difference actually matters much at the voltages and
currents involved.

Maybe the BAT54C is actually fine as long as the computer isn't turned
on for long periods in 90F heat.

The reverse leakage graph for the BAT54C at 2v (difference between 5v
from the computer and 3v from the battery) at 25C (77F) is only 0.3uA,
but could go up around 5uA for 3v (say the batts are almost dead at 2v,
so 5-2) at 40C (104F).

So... maybe not really a problem 99% of the time. But still.

I'm ordering some for myself and if you mail me your address I'll mail
you some so you don't have to make a whole digikey order and shipping
just for that.

No change to the PCB other than the silkscreen. The new part drops in
the same place.

Sorry about that.

--
bkw

On 9/20/23 14:19, Ken St. Cyr wrote:
> It turned out nice and looks pretty solid (at least in the pictures). I
> ordered boards and parts the other day, so I'm just waiting for those to
> arrive now. I'll report back and share my experience after getting one
> together -
>
> //Ken
> 
> *From:* M100  on behalf of Brian K.
> White 
> *Sent:* Tuesday, September 19, 2023 10:18 PM
> *To:* m100@lists.bitchin100.com 
> *Subject:* Re: [M100] rexcpm battery
> I have repaired my REXCPM and now the github readme includes pics that
> show a good way to mount a qwiic connector and where to connect bodge
> wires if you want to take on the challenge of such small loose wires
> going to such small places. All 4 solder points are at least a
> reasonable chip leg, no soldering directly to delicate traces. So the
> wires are reasonably robust in the end. You can install & remove the
> rexcpm module without straining the wires. I will probably further
> secure them with glue sometime later but haven't yet.
>
> I don't think it's worth it just to get the connector if your original
> pins are still intact, even though the connector is more convenient in
> the end, but since my original pins rotated and broke their traces
> anyway, I had to do a bodge wire repair anyway. And mounting the
> connector seems to be solid enough by super-glueing it to the top of a
> chip, and by using one of the black versions of the connector which I
> think is a material that the glue can stick to easier. The natural
> colored ones look like they might be something no glue will stick to.
> The black ones feel like they have some glass filler, and can be scuffed
> to a rough texture. Seems to be pretty solid so far though I'm not
> testing-to-destruction just to find out. :)
> single https://www.sparkfun.com/products/14417
> <https://www.sparkfun.com/products/14417>
> 10 pack https://www.adafruit.com/product/4208
> <https://www.adafruit.com/product/4208>
>
> My rexcpm is running and working so I can resume testing battery life.
>
> I think it's safe to order pcbs if you want now. The dupont breakout
> cable is a good solution for keeping the REXCPM side of things simple
> and stock, and adding the single wire for gnd is easy, reasonably safe
> against blunders, and leaves the REXCPM still compatible with it's
> original bus board and cable.  So the bus board can keep the qwiic
> connector.
>
> I have tested the 102/200 board now too. good to go. I don't have a
> pcbway or gerbers up for that yet but will shortly.
>
> --
> bkw
>
>
> On 9/19/23 04:29, Brian K. White wrote:
>> My boards came

Re: [M100] rexcpm battery

[Brian K. White]

I've been reading about charging protection for lithium coin cells, and 
I think we might want to swap out the BAT54C for something with as 
little reverse leakage as possible.


I thought a few uA wouldn't really matter, especially if only during 
on/active time, and didn't worry about it, but I guess even that causes 
the cells to die early and only last a few months instead of years.


So I think you should not use the BAT54C from the original BOM and use 
maybe BAV170 instead:

https://www.digikey.com/en/products/detail/diodes-incorporated/BAV170-7-F/822819

or any of these:
https://www.digikey.com/short/q9bfjch5

This was my other pick:
https://www.digikey.com/en/products/detail/central-semiconductor-corp/CMPD6001C-TR-PBFREE/5325257
Lowest reverse leakage but a little higher forward voltage drop and also 
more expensive.
Probably neither difference actually matters much at the voltages and 
currents involved.


Maybe the BAT54C is actually fine as long as the computer isn't turned 
on for long periods in 90F heat.


The reverse leakage graph for the BAT54C at 2v (difference between 5v 
from the computer and 3v from the battery) at 25C (77F) is only 0.3uA, 
but could go up around 5uA for 3v (say the batts are almost dead at 2v, 
so 5-2) at 40C (104F).


So... maybe not really a problem 99% of the time. But still.

I'm ordering some for myself and if you mail me your address I'll mail 
you some so you don't have to make a whole digikey order and shipping 
just for that.


No change to the PCB other than the silkscreen. The new part drops in 
the same place.


Sorry about that.

--
bkw

On 9/20/23 14:19, Ken St. Cyr wrote:
It turned out nice and looks pretty solid (at least in the pictures). I 
ordered boards and parts the other day, so I'm just waiting for those to 
arrive now. I'll report back and share my experience after getting one 
together -


//Ken

*From:* M100  on behalf of Brian K. 
White 

*Sent:* Tuesday, September 19, 2023 10:18 PM
*To:* m100@lists.bitchin100.com 
*Subject:* Re: [M100] rexcpm battery
I have repaired my REXCPM and now the github readme includes pics that
show a good way to mount a qwiic connector and where to connect bodge
wires if you want to take on the challenge of such small loose wires
going to such small places. All 4 solder points are at least a
reasonable chip leg, no soldering directly to delicate traces. So the
wires are reasonably robust in the end. You can install & remove the
rexcpm module without straining the wires. I will probably further
secure them with glue sometime later but haven't yet.

I don't think it's worth it just to get the connector if your original
pins are still intact, even though the connector is more convenient in
the end, but since my original pins rotated and broke their traces
anyway, I had to do a bodge wire repair anyway. And mounting the
connector seems to be solid enough by super-glueing it to the top of a
chip, and by using one of the black versions of the connector which I
think is a material that the glue can stick to easier. The natural
colored ones look like they might be something no glue will stick to.
The black ones feel like they have some glass filler, and can be scuffed
to a rough texture. Seems to be pretty solid so far though I'm not
testing-to-destruction just to find out. :)
single https://www.sparkfun.com/products/14417 
<https://www.sparkfun.com/products/14417>
10 pack https://www.adafruit.com/product/4208 
<https://www.adafruit.com/product/4208>


My rexcpm is running and working so I can resume testing battery life.

I think it's safe to order pcbs if you want now. The dupont breakout
cable is a good solution for keeping the REXCPM side of things simple
and stock, and adding the single wire for gnd is easy, reasonably safe
against blunders, and leaves the REXCPM still compatible with it's
original bus board and cable.  So the bus board can keep the qwiic
connector.

I have tested the 102/200 board now too. good to go. I don't have a
pcbway or gerbers up for that yet but will shortly.

--
bkw


On 9/19/23 04:29, Brian K. White wrote:

My boards came in and at least the model 100 one works fine.

There's room, but no good way to solder the qwiic connector to the 
REXCPM, so the most practical way to handle the REXCPM side is just 
use the pre-made adapter cable that has female dupont sockets, and 
stick them right onto the original pins.


For the GND wire, you can treat it as optional and leave that wire 
unconnected, or add a single solid-core wire to the big cap for the 
gnd connection. If you use 23 gauge solid core wire, or maybe a size 
or so thicker, the wire is stiff enough to hold it's shape and thick 
enough for a female dupont socket to stick onto it and not fall off. I 
used 23 gauge wire from some solid core ethernet cable and 

Re: [M100] rexcpm battery

[Brian K. White]

On 9/20/23 15:25, Stephen Adolph wrote:

Hi,
I only want to comment that I think this is very clever and useful!  
Looks like great work indeed!


A point of clarification though.  Brian, rexcpm is not usable in Tandy 200.


Hah, well ah ok then... ok I just updated everything to remove all 
mention of model 200.


Thank you




Cheers  Steve

On Wednesday, September 20, 2023, Ken St. Cyr <mailto:k...@stcyrfamily.net>> wrote:


It turned out nice and looks pretty solid (at least in the
pictures). I ordered boards and parts the other day, so I'm just
waiting for those to arrive now. I'll report back and share my
experience after getting one together -

//Ken

*From:* M100 mailto:m100-boun...@lists.bitchin100.com>> on behalf of Brian K.
White mailto:bw.al...@gmail.com>>
*Sent:* Tuesday, September 19, 2023 10:18 PM
*To:* m100@lists.bitchin100.com <mailto:m100@lists.bitchin100.com>
mailto:m100@lists.bitchin100.com>>
*Subject:* Re: [M100] rexcpm battery
I have repaired my REXCPM and now the github readme includes pics that
show a good way to mount a qwiic connector and where to connect bodge
wires if you want to take on the challenge of such small loose wires
going to such small places. All 4 solder points are at least a
reasonable chip leg, no soldering directly to delicate traces. So the
wires are reasonably robust in the end. You can install & remove the
rexcpm module without straining the wires. I will probably further
secure them with glue sometime later but haven't yet.

I don't think it's worth it just to get the connector if your original
pins are still intact, even though the connector is more convenient in
the end, but since my original pins rotated and broke their traces
anyway, I had to do a bodge wire repair anyway. And mounting the
connector seems to be solid enough by super-glueing it to the top of a
chip, and by using one of the black versions of the connector which I
think is a material that the glue can stick to easier. The natural
colored ones look like they might be something no glue will stick to.
The black ones feel like they have some glass filler, and can be
scuffed
to a rough texture. Seems to be pretty solid so far though I'm not
testing-to-destruction just to find out. :)
single https://www.sparkfun.com/products/14417
<https://www.sparkfun.com/products/14417>
10 pack https://www.adafruit.com/product/4208
<https://www.adafruit.com/product/4208>

My rexcpm is running and working so I can resume testing battery life.

I think it's safe to order pcbs if you want now. The dupont breakout
cable is a good solution for keeping the REXCPM side of things simple
and stock, and adding the single wire for gnd is easy, reasonably safe
against blunders, and leaves the REXCPM still compatible with it's
original bus board and cable.  So the bus board can keep the qwiic
connector.

I have tested the 102/200 board now too. good to go. I don't have a
pcbway or gerbers up for that yet but will shortly.

-- 
bkw



On 9/19/23 04:29, Brian K. White wrote:
> My boards came in and at least the model 100 one works fine.
>
> There's room, but no good way to solder the qwiic connector to the 
> REXCPM, so the most practical way to handle the REXCPM side is just 
> use the pre-made adapter cable that has female dupont sockets, and 
> stick them right onto the original pins.

>
> For the GND wire, you can treat it as optional and leave that wire 
> unconnected, or add a single solid-core wire to the big cap for the 
> gnd connection. If you use 23 gauge solid core wire, or maybe a size 
> or so thicker, the wire is stiff enough to hold it's shape and thick 
> enough for a female dupont socket to stick onto it and not fall off. I 
> used 23 gauge wire from some solid core ethernet cable and that was 
> about perfect. Other common sources, thermostat wire, doorbell wire.

>
> Take a 25mm piece of wire, strip 3mm on one end and bend it sharp 90 
> degrees, strip 6mm on the other end, poke the wire in between the cap 
> and the 3 pins and solder the short bent end to the cap.

>
> Then the 4 female dupont wires go like this:
>
> black  (GND) ->  wire on cap
> red    (/WR) ->  closest pin to cap
> blue   (RAM) ->  middle pin
> yellow (RAM_RST) ->  furthest pin from cap
>
>
>
> It turns out you have to be very careful not to strain the original 
> pins on the REXCPM.. They rotate pretty easily and break the via

Re: [M100] rexcpm battery

[Stephen Adolph]

Hi,
I only want to comment that I think this is very clever and useful!  Looks
like great work indeed!

A point of clarification though.  Brian, rexcpm is not usable in Tandy
200.

Cheers  Steve

On Wednesday, September 20, 2023, Ken St. Cyr  wrote:

> It turned out nice and looks pretty solid (at least in the pictures). I
> ordered boards and parts the other day, so I'm just waiting for those to
> arrive now. I'll report back and share my experience after getting one
> together -
>
> //Ken
> --
> *From:* M100  on behalf of Brian K.
> White 
> *Sent:* Tuesday, September 19, 2023 10:18 PM
> *To:* m100@lists.bitchin100.com 
> *Subject:* Re: [M100] rexcpm battery
>
> I have repaired my REXCPM and now the github readme includes pics that
> show a good way to mount a qwiic connector and where to connect bodge
> wires if you want to take on the challenge of such small loose wires
> going to such small places. All 4 solder points are at least a
> reasonable chip leg, no soldering directly to delicate traces. So the
> wires are reasonably robust in the end. You can install & remove the
> rexcpm module without straining the wires. I will probably further
> secure them with glue sometime later but haven't yet.
>
> I don't think it's worth it just to get the connector if your original
> pins are still intact, even though the connector is more convenient in
> the end, but since my original pins rotated and broke their traces
> anyway, I had to do a bodge wire repair anyway. And mounting the
> connector seems to be solid enough by super-glueing it to the top of a
> chip, and by using one of the black versions of the connector which I
> think is a material that the glue can stick to easier. The natural
> colored ones look like they might be something no glue will stick to.
> The black ones feel like they have some glass filler, and can be scuffed
> to a rough texture. Seems to be pretty solid so far though I'm not
> testing-to-destruction just to find out. :)
> single https://www.sparkfun.com/products/14417
> 10 pack https://www.adafruit.com/product/4208
>
> My rexcpm is running and working so I can resume testing battery life.
>
> I think it's safe to order pcbs if you want now. The dupont breakout
> cable is a good solution for keeping the REXCPM side of things simple
> and stock, and adding the single wire for gnd is easy, reasonably safe
> against blunders, and leaves the REXCPM still compatible with it's
> original bus board and cable.  So the bus board can keep the qwiic
> connector.
>
> I have tested the 102/200 board now too. good to go. I don't have a
> pcbway or gerbers up for that yet but will shortly.
>
> --
> bkw
>
>
> On 9/19/23 04:29, Brian K. White wrote:
> > My boards came in and at least the model 100 one works fine.
> >
> > There's room, but no good way to solder the qwiic connector to the
> > REXCPM, so the most practical way to handle the REXCPM side is just
> > use the pre-made adapter cable that has female dupont sockets, and
> > stick them right onto the original pins.
> >
> > For the GND wire, you can treat it as optional and leave that wire
> > unconnected, or add a single solid-core wire to the big cap for the
> > gnd connection. If you use 23 gauge solid core wire, or maybe a size
> > or so thicker, the wire is stiff enough to hold it's shape and thick
> > enough for a female dupont socket to stick onto it and not fall off. I
> > used 23 gauge wire from some solid core ethernet cable and that was
> > about perfect. Other common sources, thermostat wire, doorbell wire.
> >
> > Take a 25mm piece of wire, strip 3mm on one end and bend it sharp 90
> > degrees, strip 6mm on the other end, poke the wire in between the cap
> > and the 3 pins and solder the short bent end to the cap.
> >
> > Then the 4 female dupont wires go like this:
> >
> > black  (GND) ->  wire on cap
> > red(/WR) ->  closest pin to cap
> > blue   (RAM) ->  middle pin
> > yellow (RAM_RST) ->  furthest pin from cap
> >
> >
> >
> > It turns out you have to be very careful not to strain the original
> > pins on the REXCPM.. They rotate pretty easily and break the via free
> > inside the pcb, and then the traces break.
> >
> > At one point I was stuffing the gnd wire down from the top in between
> > the pin and the cap, and that put sideways strain on the pin.
> >
> > My REXCPM doesn't work now unless I hold the pins a certain way to
> > cause them to make contact.
> >
> > I have to desolder a few parts to figure out where 

Re: [M100] rexcpm battery

[Ken St. Cyr]

It turned out nice and looks pretty solid (at least in the pictures). I ordered 
boards and parts the other day, so I'm just waiting for those to arrive now. 
I'll report back and share my experience after getting one together -

//Ken

From: M100  on behalf of Brian K. White 

Sent: Tuesday, September 19, 2023 10:18 PM
To: m100@lists.bitchin100.com 
Subject: Re: [M100] rexcpm battery

I have repaired my REXCPM and now the github readme includes pics that
show a good way to mount a qwiic connector and where to connect bodge
wires if you want to take on the challenge of such small loose wires
going to such small places. All 4 solder points are at least a
reasonable chip leg, no soldering directly to delicate traces. So the
wires are reasonably robust in the end. You can install & remove the
rexcpm module without straining the wires. I will probably further
secure them with glue sometime later but haven't yet.

I don't think it's worth it just to get the connector if your original
pins are still intact, even though the connector is more convenient in
the end, but since my original pins rotated and broke their traces
anyway, I had to do a bodge wire repair anyway. And mounting the
connector seems to be solid enough by super-glueing it to the top of a
chip, and by using one of the black versions of the connector which I
think is a material that the glue can stick to easier. The natural
colored ones look like they might be something no glue will stick to.
The black ones feel like they have some glass filler, and can be scuffed
to a rough texture. Seems to be pretty solid so far though I'm not
testing-to-destruction just to find out. :)
single https://www.sparkfun.com/products/14417
10 pack https://www.adafruit.com/product/4208

My rexcpm is running and working so I can resume testing battery life.

I think it's safe to order pcbs if you want now. The dupont breakout
cable is a good solution for keeping the REXCPM side of things simple
and stock, and adding the single wire for gnd is easy, reasonably safe
against blunders, and leaves the REXCPM still compatible with it's
original bus board and cable.  So the bus board can keep the qwiic
connector.

I have tested the 102/200 board now too. good to go. I don't have a
pcbway or gerbers up for that yet but will shortly.

--
bkw


On 9/19/23 04:29, Brian K. White wrote:
> My boards came in and at least the model 100 one works fine.
>
> There's room, but no good way to solder the qwiic connector to the
> REXCPM, so the most practical way to handle the REXCPM side is just
> use the pre-made adapter cable that has female dupont sockets, and
> stick them right onto the original pins.
>
> For the GND wire, you can treat it as optional and leave that wire
> unconnected, or add a single solid-core wire to the big cap for the
> gnd connection. If you use 23 gauge solid core wire, or maybe a size
> or so thicker, the wire is stiff enough to hold it's shape and thick
> enough for a female dupont socket to stick onto it and not fall off. I
> used 23 gauge wire from some solid core ethernet cable and that was
> about perfect. Other common sources, thermostat wire, doorbell wire.
>
> Take a 25mm piece of wire, strip 3mm on one end and bend it sharp 90
> degrees, strip 6mm on the other end, poke the wire in between the cap
> and the 3 pins and solder the short bent end to the cap.
>
> Then the 4 female dupont wires go like this:
>
> black  (GND) ->  wire on cap
> red(/WR) ->  closest pin to cap
> blue   (RAM) ->  middle pin
> yellow (RAM_RST) ->  furthest pin from cap
>
>
>
> It turns out you have to be very careful not to strain the original
> pins on the REXCPM.. They rotate pretty easily and break the via free
> inside the pcb, and then the traces break.
>
> At one point I was stuffing the gnd wire down from the top in between
> the pin and the cap, and that put sideways strain on the pin.
>
> My REXCPM doesn't work now unless I hold the pins a certain way to
> cause them to make contact.
>
> I have to desolder a few parts to figure out where two of the traces
> go so I can find where to run bodge wires. Fixing the original traces
> right where they broke at the base of the pins is probably too fragile
> now that the vias are moving like that.
>
> Maybe I'll just remove the pins, fix the existing traces where they
> broke, and solder flexible wires instead of pins where the pins used
> to go, and secure the solder joints with glue or epoxy. Hopefully the
> combination of the glue and the flexible wire, and being super careful
> from now on, will be enough to keep the traces from breaking again.
>
> So I think the battery board is fine, and the cable connection at
> least for model 100 is practical en

Re: [M100] rexcpm battery

[Brian K. White]

I have repaired my REXCPM and now the github readme includes pics that 
show a good way to mount a qwiic connector and where to connect bodge 
wires if you want to take on the challenge of such small loose wires 
going to such small places. All 4 solder points are at least a 
reasonable chip leg, no soldering directly to delicate traces. So the 
wires are reasonably robust in the end. You can install & remove the 
rexcpm module without straining the wires. I will probably further 
secure them with glue sometime later but haven't yet.


I don't think it's worth it just to get the connector if your original 
pins are still intact, even though the connector is more convenient in 
the end, but since my original pins rotated and broke their traces 
anyway, I had to do a bodge wire repair anyway. And mounting the 
connector seems to be solid enough by super-glueing it to the top of a 
chip, and by using one of the black versions of the connector which I 
think is a material that the glue can stick to easier. The natural 
colored ones look like they might be something no glue will stick to. 
The black ones feel like they have some glass filler, and can be scuffed 
to a rough texture. Seems to be pretty solid so far though I'm not 
testing-to-destruction just to find out. :)

single https://www.sparkfun.com/products/14417
10 pack https://www.adafruit.com/product/4208

My rexcpm is running and working so I can resume testing battery life.

I think it's safe to order pcbs if you want now. The dupont breakout 
cable is a good solution for keeping the REXCPM side of things simple 
and stock, and adding the single wire for gnd is easy, reasonably safe 
against blunders, and leaves the REXCPM still compatible with it's 
original bus board and cable.  So the bus board can keep the qwiic 
connector.


I have tested the 102/200 board now too. good to go. I don't have a 
pcbway or gerbers up for that yet but will shortly.


--
bkw


On 9/19/23 04:29, Brian K. White wrote:

My boards came in and at least the model 100 one works fine.

There's room, but no good way to solder the qwiic connector to the 
REXCPM, so the most practical way to handle the REXCPM side is just 
use the pre-made adapter cable that has female dupont sockets, and 
stick them right onto the original pins.


For the GND wire, you can treat it as optional and leave that wire 
unconnected, or add a single solid-core wire to the big cap for the 
gnd connection. If you use 23 gauge solid core wire, or maybe a size 
or so thicker, the wire is stiff enough to hold it's shape and thick 
enough for a female dupont socket to stick onto it and not fall off. I 
used 23 gauge wire from some solid core ethernet cable and that was 
about perfect. Other common sources, thermostat wire, doorbell wire.


Take a 25mm piece of wire, strip 3mm on one end and bend it sharp 90 
degrees, strip 6mm on the other end, poke the wire in between the cap 
and the 3 pins and solder the short bent end to the cap.


Then the 4 female dupont wires go like this:

black  (GND) ->  wire on cap
red    (/WR) ->  closest pin to cap
blue   (RAM) ->  middle pin
yellow (RAM_RST) ->  furthest pin from cap



It turns out you have to be very careful not to strain the original 
pins on the REXCPM.. They rotate pretty easily and break the via free 
inside the pcb, and then the traces break.


At one point I was stuffing the gnd wire down from the top in between 
the pin and the cap, and that put sideways strain on the pin.


My REXCPM doesn't work now unless I hold the pins a certain way to 
cause them to make contact.


I have to desolder a few parts to figure out where two of the traces 
go so I can find where to run bodge wires. Fixing the original traces 
right where they broke at the base of the pins is probably too fragile 
now that the vias are moving like that.


Maybe I'll just remove the pins, fix the existing traces where they 
broke, and solder flexible wires instead of pins where the pins used 
to go, and secure the solder joints with glue or epoxy. Hopefully the 
combination of the glue and the flexible wire, and being super careful 
from now on, will be enough to keep the traces from breaking again.


So I think the battery board is fine, and the cable connection at 
least for model 100 is practical enough (I'd prefer a matching 
polarized connector instead of 4 individual wires, but there is just 
no good way to add that tiny connector that won't be too delicate and 
just break in no time) but my rexcpm is out of commission and I can't 
do any further real testing to get real current and voltages etc right 
now.


I did have it fully hooked up and running briefly before I twisted the 
pins.


I can't test the 102/200 board right now, and the pre-made 
qwiic-dupont cable is only 150mm, not long enough to reach all the way 
from the board to the rexcpm. You could add short male-female dupont 
extensions/jumpers, but that's kind of annoying.


For the 102/200 board, really may

Re: [M100] rexcpm battery

[Brian K. White]

My boards came in and at least the model 100 one works fine.

There's room, but no good way to solder the qwiic connector to the 
REXCPM, so the most practical way to handle the REXCPM side is just use 
the pre-made adapter cable that has female dupont sockets, and stick 
them right onto the original pins.


For the GND wire, you can treat it as optional and leave that wire 
unconnected, or add a single solid-core wire to the big cap for the gnd 
connection. If you use 23 gauge solid core wire, or maybe a size or so 
thicker, the wire is stiff enough to hold it's shape and thick enough 
for a female dupont socket to stick onto it and not fall off. I used 23 
gauge wire from some solid core ethernet cable and that was about 
perfect. Other common sources, thermostat wire, doorbell wire.


Take a 25mm piece of wire, strip 3mm on one end and bend it sharp 90 
degrees, strip 6mm on the other end, poke the wire in between the cap 
and the 3 pins and solder the short bent end to the cap.


Then the 4 female dupont wires go like this:

black  (GND) ->  wire on cap
red(/WR) ->  closest pin to cap
blue   (RAM) ->  middle pin
yellow (RAM_RST) ->  furthest pin from cap



It turns out you have to be very careful not to strain the original pins 
on the REXCPM.. They rotate pretty easily and break the via free inside 
the pcb, and then the traces break.


At one point I was stuffing the gnd wire down from the top in between 
the pin and the cap, and that put sideways strain on the pin.


My REXCPM doesn't work now unless I hold the pins a certain way to cause 
them to make contact.


I have to desolder a few parts to figure out where two of the traces go 
so I can find where to run bodge wires. Fixing the original traces right 
where they broke at the base of the pins is probably too fragile now 
that the vias are moving like that.


Maybe I'll just remove the pins, fix the existing traces where they 
broke, and solder flexible wires instead of pins where the pins used to 
go, and secure the solder joints with glue or epoxy. Hopefully the 
combination of the glue and the flexible wire, and being super careful 
from now on, will be enough to keep the traces from breaking again.


So I think the battery board is fine, and the cable connection at least 
for model 100 is practical enough (I'd prefer a matching polarized 
connector instead of 4 individual wires, but there is just no good way 
to add that tiny connector that won't be too delicate and just break in 
no time) but my rexcpm is out of commission and I can't do any further 
real testing to get real current and voltages etc right now.


I did have it fully hooked up and running briefly before I twisted the pins.

I can't test the 102/200 board right now, and the pre-made qwiic-dupont 
cable is only 150mm, not long enough to reach all the way from the board 
to the rexcpm. You could add short male-female dupont 
extensions/jumpers, but that's kind of annoying.


For the 102/200 board, really maybe for both boards, maybe it's better 
to just go down to 2 or 3 cells and full size generic 4-pin headers 
instead of the qwiic connectors.


It does work fine for the 100 version though since there is a pre-made 
cable that is long enough all in one piece.


I've updated the github with bom and pcbway links, and gerber zip for 
the model 100 version.


I say it's safe to order the 100 version at least.

The 102/200 version I haven't worked out how best to connect to the 
REXCPM yet.


https://github.com/bkw777/REXCPM_UPS

--
bkw


On 9/17/23 20:33, Ken St. Cyr wrote:
Thanks for the detailed explanation - I totally get it now.  I'll wait 
until you verify the board and post the gerber before ordering a set. I 
typically have an order or two open with JLCPCB at any given time - for 
just about every order, it's exactly 10 days from the time I click the 
purchase button before the blue box shows up in my mailbox, and that's 
with the cheapest shipping option. I'm not in a hurry to try it out, but 
if I was, I would probably just mill a prototype board on my CNC.


Regarding the 4-wire connector... I'm happy to just solder the ground 
wire directly to the REXCPM, though I'm sure most normal people would 
prefer to have it on a connector.


//Ken S.

*From:* M100  on behalf of Brian K. 
White 

*Sent:* Thursday, September 14, 2023 10:16 PM
*To:* m100@lists.bitchin100.com 
*Subject:* Re: [M100] rexcpm battery
On 9/14/23 21:27, Brian K. White wrote:
But somehow there is power differential between gnd and vmem (or 
whatever the positive side of the big cap is, I say vmem because 
obviously it powers the sram) on the rexcpm, and 0.7uA of current 
flowing along RAM_RST. 


7uA not 0.7uA!

--
bkw



--
bkw

Re: [M100] rexcpm battery

[Ken St. Cyr]

Thanks for the detailed explanation - I totally get it now.  I'll wait until 
you verify the board and post the gerber before ordering a set. I typically 
have an order or two open with JLCPCB at any given time - for just about every 
order, it's exactly 10 days from the time I click the purchase button before 
the blue box shows up in my mailbox, and that's with the cheapest shipping 
option. I'm not in a hurry to try it out, but if I was, I would probably just 
mill a prototype board on my CNC.

Regarding the 4-wire connector... I'm happy to just solder the ground wire 
directly to the REXCPM, though I'm sure most normal people would prefer to have 
it on a connector.

//Ken S.

From: M100  on behalf of Brian K. White 

Sent: Thursday, September 14, 2023 10:16 PM
To: m100@lists.bitchin100.com 
Subject: Re: [M100] rexcpm battery

On 9/14/23 21:27, Brian K. White wrote:
> But somehow there is power differential between gnd and vmem (or
> whatever the positive side of the big cap is, I say vmem because
> obviously it powers the sram) on the rexcpm, and 0.7uA of current
> flowing along RAM_RST.

7uA not 0.7uA!

--
bkw

Re: [M100] rexcpm battery

[Brian K. White]

On 9/14/23 21:27, Brian K. White wrote:
But somehow there is power differential between gnd and vmem (or 
whatever the positive side of the big cap is, I say vmem because 
obviously it powers the sram) on the rexcpm, and 0.7uA of current 
flowing along RAM_RST. 


7uA not 0.7uA!

--
bkw

Re: [M100] rexcpm battery

[Brian K. White]

also the updated design is visible here
https://github.com/bkw777/REXCPM_UPS
The schematic now also documents which pins are which on the rexcpm too 
just for convenience & reference.


You *could* got ahead and export gerbers and order boards right now 
without waiting. But I have a set on the way and I did pay for DHL, so 
it will only be about a week.
Once I build one and there is no bonehead mistake, I'll update the 
readme with links to oshpark or pcbway or both, and add gerber zips 
under releases.


I think the board should have ENIG finish so that the battery contacts 
are gold plated, but that makes the cost go up a lot on pcbway. elecrow 
and jlc are a lot cheaper for ENIG. oshpark is always ENIG.
But the soldermask from jlc is kind of junk. Maybe it's just if getting 
blue or black and maybe green is better, but definitely black especially 
is weak and scrapes off easily.
I'm still using them though at least for testing because, well that's 
why it's called prototyping.


The boms are already updated with the new parts, including an extra male 
connector for the rexcpm, though there are no directions or plan or 
anything for what exactly to do with that connector. It's an SMT part 
and no obvious non-janky way to hook it up yet. Not even sure it even 
fits in the space allowed yet (but probably does, because the original 
connectors are already 2.54mm thick and they do not take up the entire 
space, so 2.95mm should be ok)


There's some other options for the cables too not shown. Digikey has 
some plain black wire cables made by JST.


That doesn't matter for the 100 where the wires are inside a 
compartment, but for 102 or 200 where it has to run externally and be 
taped to the bottom or something it might be slightly less ugly.

12" for 102/200
https://www.digikey.com/short/0m7pnpwm

4" for 100
https://www.digikey.com/short/5b7vjjvq

or 2" for 100 but which might not be long enough
https://www.digikey.com/short/mqh5ncbd

Similarly, although the bom has white connectors from digikey. adafruit 
sells some black connectors:

https://www.adafruit.com/product/4208

--
bkw

On 9/14/23 21:26, Brian K. White wrote:

Yes to most of your understanding, not yet on the 4-cell test.

I just ordered the pcb's yesterday so it'll be about a week.

Although there is not much to actually test about the updated board.
It's just more of the same. It's the same circuit. All it changes is 
adding more celles and a ground wire.


The gnd wire isn't really a new addition because when the boards are 
installed in the machine, there is an equivalent gnd connection 
through the normal gnd pins in both sockets.


Both boards do have their local GND connected to the GND pins on their 
own respective sockets, and both sockets are connected to the same GND 
rail all throughout the 100. So when both boards are installed, there 
is a common GND connection between the two boards the same as a wire.


Nothing about the fitment changes, it's the same pin headers and same 
battery holders. The pin headers are pretty tall at just over 4mm and 
the was a real question if that would fit or if it needed a special 
pin header with shorter shoulders. But that turned out ok. Yiu do need 
to flush-cut all the pins on top and then ideally touch each one again 
to melt the shap cut to a smooth dome. But that's easy. The new board 
is no different. The Qwiic connector is new, but it is 2.95mm, and so 
that's that, no worry even though I haven't actually got it yet.


So nothing much changes either electrically or physically, at least 
not in terms of wondering if it will work or not.


In the mean time, while waiting for the new boards I have had the 
original board installed in a 100 with the memory power switch turned 
off, and it's still reading 2.69v at the cap right now after... 4 or 5 
days so far? My original email was 4 days ago and I had done over 24 
hours of testing at that time.


This is good.

The leakage thing is this:

First, background, the REXCPM lives in a socket that was only designed 
for a ROM, and so that socket only has minimal bus signals. Just 
power, address, data, chip-enable, output-enable. It doesn't even have 
a write-enable signal like an sram would have. What matters in this 
case is among the things it doesn't have is it has no provision 
keeping something powered-but-disabled while the machine is turned 
off. It just has a VCC pin the dies when everything else dies.


The system bus has a bunch of other signals, including RAM_RST, which 
is held *high* the entire time the machine is "off". This is to keep 
sram disabled and asleep by holding their active-low /CE pins high. 
Not just for a peripheral connected to the system bus but also all the 
internal ram is disabled (or enabled) by that same signal.


I don't know if this signal was originally intended to be used as a 
power source vs just a control signal. The internal ram has an actual 
VBAT power line on their VCC pins, and there is no pin for that

Re: [M100] rexcpm battery

[Brian K. White]

t 
need mounting tape or who knows what.


Maybe I just change the design again to use some other more convenient 
type of connector that isn't quite so small but still small enough?


There are cheap male & female pigtail kits for JST-PH 2.0mm that have a 
male connactor crimped on to wires. That would be dead easy to solder 
the male side onto the rexcpm.

https://www.amazon.com/dp/B081CRLN8B
And I guess the other end could just be wires soldered to the bus board 
too, so that one kit does everything, but I actually really prefer the 
original arrangement with only fixed connectors (be they male or female) 
on the boards and wires only in the cable between. I would rather figure 
out some way no matter what it takes, to have just fixed connectors on 
the boards.


Maybe I can desolder the original pins but only to slide them up 
slightly so that they are as high in the air as they can go before 
hitting the compartment cover, and maybe that leaves enough space 
between the pins and the pcb to solder the connector to the underside of 
the pins, and the pins provide the rigid mounting. Then the gnd wire can 
be a loose bodge wire glued down. Maybe I can add a 4th rigid pin 
extracted from some other generic header or connector, from the rear of 
the cap over to the connector, to solder to one of the mechanical 
mounting solder pads on the side of the connector too, as well as the 
gnd pin.


The rexcpm side of things is now the unknown tricky part but hopefully I 
figure out some plan that isn't too terribly hacky and is actually 
doable and solid.


--
bkw

On 9/14/23 14:53, Ken St. Cyr wrote:
Great work! To make sure I’m following - the REXCPM relies on having a 
ground path through the socket, so the idea is to swap out the 3-wire 
JST connection for a 4-wire version, which adds the ground pin... And 
you’re saying the only reason it works outside the unit right now 
without the ground path is because there’s leakage on the RAM_RST line?


I'd like to give it a shot ... have you done a prototype run of the 4x 
battery board yet?


//Ken S

*From:* M100  on behalf of Brian K. 
White 

*Sent:* Wednesday, September 13, 2023 3:13:53 AM
*To:* m100@lists.bitchin100.com 
*Subject:* Re: [M100] rexcpm battery
Let's give THIS a try...
https://photos.app.goo.gl/JaSofoK2VotHzVco9 
<https://photos.app.goo.gl/JaSofoK2VotHzVco9>


The connector is a standard JST-SH, and cables are available pre-made in
both 2" for the 100 and 12" for the 102 or 200.
There's even an off-the-shelf cable that has dupont sockets on one end,
so you could connect to an unmodified rexcpm.

So now we have
120 mah
gnd connection
polarized plug

I think we're looking at at least 2 years of shelf life now.

--
bkw


On 9/12/23 15:05, Brian K. White wrote:

I've done a little more testing.

The GND path is backfeeding only via the RAM line. Nothing on /WR. 
(the only possible connections)


I am measuring only 6.6uA on the RAM_RST line between the two boards 
with the boards outside of the 100.


That is a little high but actually not too bad. I would hope for under 
5uA ideally but 7uA is in the same class.


At that rate, nominally the batteries should last over 11 months. And 
at that low current there shouldn't be much voltage drop across the 
diode on RAM_RST, and indeed there isn't. I only lose about 0.1v from 
the battery to RAM_RST.


The bulk of the voltage drop is happening along the GND path, and 
things change a lot when the boards are installed in the 100 and the 
100 provides a real GND connection between the two boards.


With both boards outside of the 100, I currently measure
(the batteries are draining as time goes on so these numbers all 
change a little each time I check something, so I'll keep saying the 
battery voltage along with whatever else I'm talking about)


2.99v between BATT- and BATT+
2.91v between BATT- and RAM_RST (so practically no drop through the 
diode on the bus board)
2.76v between BATT- and CAP+ (it's not labelled CAP+, I just mean the 
positive side of the big cap) on the REXCPM (after giving it time to 
drain away the 5v from the 100)

2.26v between CAP- and CAP+

So there is not actually much drop from BATT+ along RAM_RST to REXCPM 
VCC, but a 0.5v loss along the GND-via-RAM path.


Next, when I provide an actual GND connection between the boards by 
plugging them in to the 100 with the memory power switch turned off, 
the current draw actually increases slightly to 7.2uA (after an 
initial spike probably charging the cap), but the voltage drop 
decreases. The battery is currently at 2.99v and I get 2.72v at the 
cap instead of 2.26v


While writing this the current along RAM_RST very gradually dropped 
further to 6.9uA. Maybe it will continue creeping down to settle at 
the same 6.6-6.7 eventually?


This suggests that maybe the batteries would provide a

Re: [M100] rexcpm battery

[Brian K. White]

t 
need mounting tape or who knows what.


Maybe I just change the design again to use some other more convenient 
type of connector that isn't quite so small but still small enough?


There are cheap male & female pigtail kits for JST-PH 2.0mm that have a 
male connactor crimped on to wires. That would be dead easy to solder 
the male side onto the rexcpm.

https://www.amazon.com/dp/B081CRLN8B
And I guess the other end could just be wires soldered to the bus board 
too, so that one kit does everything, but I actually really prefer the 
original arrangement with only fixed connectors (be they male or female) 
on the boards and wires only in the cable between. I would rather figure 
out some way no matter what it takes, to have just fixed connectors on 
the boards.


Maybe I can desolder the original pins but only to slide them up 
slightly so that they are as high in the air as they can go before 
hitting the compartment cover, and maybe that leaves enough space 
between the pins and the pcb to solder the connector to the underside of 
the pins, and the pins provide the rigid mounting. Then the gnd wire can 
be a loose bodge wire glued down. Maybe I can add a 4th rigid pin 
extracted from some other generic header or connector, from the rear of 
the cap over to the connector, to solder to one of the mechanical 
mounting solder pads on the side of the connector too, as well as the 
gnd pin.


The rexcpm side of things is now the unknown tricky part but hopefully I 
figure out some plan that isn't too terribly hacky and is actually 
doable and solid.


--
bkw

On 9/14/23 14:53, Ken St. Cyr wrote:
Great work! To make sure I’m following - the REXCPM relies on having a 
ground path through the socket, so the idea is to swap out the 3-wire 
JST connection for a 4-wire version, which adds the ground pin... And 
you’re saying the only reason it works outside the unit right now 
without the ground path is because there’s leakage on the RAM_RST line?


I'd like to give it a shot ... have you done a prototype run of the 4x 
battery board yet?


//Ken S

*From:* M100  on behalf of Brian K. 
White 

*Sent:* Wednesday, September 13, 2023 3:13:53 AM
*To:* m100@lists.bitchin100.com 
*Subject:* Re: [M100] rexcpm battery
Let's give THIS a try...
https://photos.app.goo.gl/JaSofoK2VotHzVco9 
<https://photos.app.goo.gl/JaSofoK2VotHzVco9>


The connector is a standard JST-SH, and cables are available pre-made in
both 2" for the 100 and 12" for the 102 or 200.
There's even an off-the-shelf cable that has dupont sockets on one end,
so you could connect to an unmodified rexcpm.

So now we have
120 mah
gnd connection
polarized plug

I think we're looking at at least 2 years of shelf life now.

--
bkw


On 9/12/23 15:05, Brian K. White wrote:

I've done a little more testing.

The GND path is backfeeding only via the RAM line. Nothing on /WR. 
(the only possible connections)


I am measuring only 6.6uA on the RAM_RST line between the two boards 
with the boards outside of the 100.


That is a little high but actually not too bad. I would hope for under 
5uA ideally but 7uA is in the same class.


At that rate, nominally the batteries should last over 11 months. And 
at that low current there shouldn't be much voltage drop across the 
diode on RAM_RST, and indeed there isn't. I only lose about 0.1v from 
the battery to RAM_RST.


The bulk of the voltage drop is happening along the GND path, and 
things change a lot when the boards are installed in the 100 and the 
100 provides a real GND connection between the two boards.


With both boards outside of the 100, I currently measure
(the batteries are draining as time goes on so these numbers all 
change a little each time I check something, so I'll keep saying the 
battery voltage along with whatever else I'm talking about)


2.99v between BATT- and BATT+
2.91v between BATT- and RAM_RST (so practically no drop through the 
diode on the bus board)
2.76v between BATT- and CAP+ (it's not labelled CAP+, I just mean the 
positive side of the big cap) on the REXCPM (after giving it time to 
drain away the 5v from the 100)

2.26v between CAP- and CAP+

So there is not actually much drop from BATT+ along RAM_RST to REXCPM 
VCC, but a 0.5v loss along the GND-via-RAM path.


Next, when I provide an actual GND connection between the boards by 
plugging them in to the 100 with the memory power switch turned off, 
the current draw actually increases slightly to 7.2uA (after an 
initial spike probably charging the cap), but the voltage drop 
decreases. The battery is currently at 2.99v and I get 2.72v at the 
cap instead of 2.26v


While writing this the current along RAM_RST very gradually dropped 
further to 6.9uA. Maybe it will continue creeping down to settle at 
the same 6.6-6.7 eventually?


This suggests that maybe the batteries would provide a

Re: [M100] rexcpm battery

[Ken St. Cyr]

Great work! To make sure I’m following - the REXCPM relies on having a ground 
path through the socket, so the idea is to swap out the 3-wire JST connection 
for a 4-wire version, which adds the ground pin... And you’re saying the only 
reason it works outside the unit right now without the ground path is because 
there’s leakage on the RAM_RST line?

I'd like to give it a shot ... have you done a prototype run of the 4x battery 
board yet?

//Ken S

From: M100  on behalf of Brian K. White 

Sent: Wednesday, September 13, 2023 3:13:53 AM
To: m100@lists.bitchin100.com 
Subject: Re: [M100] rexcpm battery

Let's give THIS a try...
https://photos.app.goo.gl/JaSofoK2VotHzVco9

The connector is a standard JST-SH, and cables are available pre-made in
both 2" for the 100 and 12" for the 102 or 200.
There's even an off-the-shelf cable that has dupont sockets on one end,
so you could connect to an unmodified rexcpm.

So now we have
120 mah
gnd connection
polarized plug

I think we're looking at at least 2 years of shelf life now.

--
bkw


On 9/12/23 15:05, Brian K. White wrote:
> I've done a little more testing.
>
> The GND path is backfeeding only via the RAM line. Nothing on /WR.
> (the only possible connections)
>
> I am measuring only 6.6uA on the RAM_RST line between the two boards
> with the boards outside of the 100.
>
> That is a little high but actually not too bad. I would hope for under
> 5uA ideally but 7uA is in the same class.
>
> At that rate, nominally the batteries should last over 11 months. And
> at that low current there shouldn't be much voltage drop across the
> diode on RAM_RST, and indeed there isn't. I only lose about 0.1v from
> the battery to RAM_RST.
>
> The bulk of the voltage drop is happening along the GND path, and
> things change a lot when the boards are installed in the 100 and the
> 100 provides a real GND connection between the two boards.
>
> With both boards outside of the 100, I currently measure
> (the batteries are draining as time goes on so these numbers all
> change a little each time I check something, so I'll keep saying the
> battery voltage along with whatever else I'm talking about)
>
> 2.99v between BATT- and BATT+
> 2.91v between BATT- and RAM_RST (so practically no drop through the
> diode on the bus board)
> 2.76v between BATT- and CAP+ (it's not labelled CAP+, I just mean the
> positive side of the big cap) on the REXCPM (after giving it time to
> drain away the 5v from the 100)
> 2.26v between CAP- and CAP+
>
> So there is not actually much drop from BATT+ along RAM_RST to REXCPM
> VCC, but a 0.5v loss along the GND-via-RAM path.
>
> Next, when I provide an actual GND connection between the boards by
> plugging them in to the 100 with the memory power switch turned off,
> the current draw actually increases slightly to 7.2uA (after an
> initial spike probably charging the cap), but the voltage drop
> decreases. The battery is currently at 2.99v and I get 2.72v at the
> cap instead of 2.26v
>
> While writing this the current along RAM_RST very gradually dropped
> further to 6.9uA. Maybe it will continue creeping down to settle at
> the same 6.6-6.7 eventually?
>
> This suggests that maybe the batteries would provide a worthwhile
> shelf-life extension after all, at least while installed in the
> machine which provides a real GND connection.
>
> 60mAh at 8uA works out to just over 10 months. (according to
> https://www.digikey.com/en/resources/conversion-calculators/conversion-calculator-battery-life)
>
> That's worth doing I think. Especially when added to the 100's own
> shelf-life, that should work out to maybe 1.5 years total.
>
> I still have to check the actual current drain at the battery. My
> current measurements above were just on the RAM_RST line from the bus
> board to the rexcpm, not at the battery itself. It's possible the
> battery is seeing more total current than just that through additional
> paths like reverse leakage through the schottkey from BATT+ to VBUS,
> and through RAM_RST into the 100.
>
> Anyway it looks a lot more promising than I thought at first.
>
>
> As for getting that same long shelf-life outside of the 100, one idea
> might be to mod the REXCPM to use a 4-pin JST-SH connector and use the
> same connector on the bus board, and a pre-made cable assembly.
>
> Those are very small connectors and would be difficult to crimp the
> female connectors on the cable by hand, but they sell those pre-made
> in suitable lengths. And the male connectors are only 2.95mm tall and
> 7mm wide (really only 6mm but the flanges on the cable connector are
> 7mm) and that fits easily on both the rexcpm and the

Re: [M100] rexcpm battery

[Brian K. White]

Let's give THIS a try...
https://photos.app.goo.gl/JaSofoK2VotHzVco9

The connector is a standard JST-SH, and cables are available pre-made in 
both 2" for the 100 and 12" for the 102 or 200.
There's even an off-the-shelf cable that has dupont sockets on one end, 
so you could connect to an unmodified rexcpm.


So now we have
120 mah
gnd connection
polarized plug

I think we're looking at at least 2 years of shelf life now.

--
bkw


On 9/12/23 15:05, Brian K. White wrote:

I've done a little more testing.

The GND path is backfeeding only via the RAM line. Nothing on /WR. 
(the only possible connections)


I am measuring only 6.6uA on the RAM_RST line between the two boards 
with the boards outside of the 100.


That is a little high but actually not too bad. I would hope for under 
5uA ideally but 7uA is in the same class.


At that rate, nominally the batteries should last over 11 months. And 
at that low current there shouldn't be much voltage drop across the 
diode on RAM_RST, and indeed there isn't. I only lose about 0.1v from 
the battery to RAM_RST.


The bulk of the voltage drop is happening along the GND path, and 
things change a lot when the boards are installed in the 100 and the 
100 provides a real GND connection between the two boards.


With both boards outside of the 100, I currently measure
(the batteries are draining as time goes on so these numbers all 
change a little each time I check something, so I'll keep saying the 
battery voltage along with whatever else I'm talking about)


2.99v between BATT- and BATT+
2.91v between BATT- and RAM_RST (so practically no drop through the 
diode on the bus board)
2.76v between BATT- and CAP+ (it's not labelled CAP+, I just mean the 
positive side of the big cap) on the REXCPM (after giving it time to 
drain away the 5v from the 100)

2.26v between CAP- and CAP+

So there is not actually much drop from BATT+ along RAM_RST to REXCPM 
VCC, but a 0.5v loss along the GND-via-RAM path.


Next, when I provide an actual GND connection between the boards by 
plugging them in to the 100 with the memory power switch turned off, 
the current draw actually increases slightly to 7.2uA (after an 
initial spike probably charging the cap), but the voltage drop 
decreases. The battery is currently at 2.99v and I get 2.72v at the 
cap instead of 2.26v


While writing this the current along RAM_RST very gradually dropped 
further to 6.9uA. Maybe it will continue creeping down to settle at 
the same 6.6-6.7 eventually?


This suggests that maybe the batteries would provide a worthwhile 
shelf-life extension after all, at least while installed in the 
machine which provides a real GND connection.


60mAh at 8uA works out to just over 10 months. (according to 
https://www.digikey.com/en/resources/conversion-calculators/conversion-calculator-battery-life)


That's worth doing I think. Especially when added to the 100's own 
shelf-life, that should work out to maybe 1.5 years total.


I still have to check the actual current drain at the battery. My 
current measurements above were just on the RAM_RST line from the bus 
board to the rexcpm, not at the battery itself. It's possible the 
battery is seeing more total current than just that through additional 
paths like reverse leakage through the schottkey from BATT+ to VBUS, 
and through RAM_RST into the 100.


Anyway it looks a lot more promising than I thought at first.


As for getting that same long shelf-life outside of the 100, one idea 
might be to mod the REXCPM to use a 4-pin JST-SH connector and use the 
same connector on the bus board, and a pre-made cable assembly.


Those are very small connectors and would be difficult to crimp the 
female connectors on the cable by hand, but they sell those pre-made 
in suitable lengths. And the male connectors are only 2.95mm tall and 
7mm wide (really only 6mm but the flanges on the cable connector are 
7mm) and that fits easily on both the rexcpm and the bus board.


On the rexcpm side it would have to be bodge wired to the 3 existing 
pins and the 4th pin to the negative side of the big cap, then secured 
with glue or mounting foam tape.


On the bus board it's nothing. The connector footprint fits right 
where the existing 3-pin header is now.


https://mou.sr/3K9FwRe
https://mou.sr/44Pcako

or

https://www.digikey.com/short/7hb4cm4q
https://www.digikey.com/short/wzj8ppjb


And as an added bonus, the new cable is fully polarity keyed on both 
ends too.




--
bkw

Re: [M100] rexcpm battery

[Brian K. White]

I've done a little more testing.

The GND path is backfeeding only via the RAM line. Nothing on /WR. (the 
only possible connections)


I am measuring only 6.6uA on the RAM_RST line between the two boards 
with the boards outside of the 100.


That is a little high but actually not too bad. I would hope for under 
5uA ideally but 7uA is in the same class.


At that rate, nominally the batteries should last over 11 months. And at 
that low current there shouldn't be much voltage drop across the diode 
on RAM_RST, and indeed there isn't. I only lose about 0.1v from the 
battery to RAM_RST.


The bulk of the voltage drop is happening along the GND path, and things 
change a lot when the boards are installed in the 100 and the 100 
provides a real GND connection between the two boards.


With both boards outside of the 100, I currently measure
(the batteries are draining as time goes on so these numbers all change 
a little each time I check something, so I'll keep saying the battery 
voltage along with whatever else I'm talking about)


2.99v between BATT- and BATT+
2.91v between BATT- and RAM_RST (so practically no drop through the 
diode on the bus board)
2.76v between BATT- and CAP+ (it's not labelled CAP+, I just mean the 
positive side of the big cap) on the REXCPM (after giving it time to 
drain away the 5v from the 100)

2.26v between CAP- and CAP+

So there is not actually much drop from BATT+ along RAM_RST to REXCPM 
VCC, but a 0.5v loss along the GND-via-RAM path.


Next, when I provide an actual GND connection between the boards by 
plugging them in to the 100 with the memory power switch turned off, the 
current draw actually increases slightly to 7.2uA (after an initial 
spike probably charging the cap), but the voltage drop decreases. The 
battery is currently at 2.99v and I get 2.72v at the cap instead of 2.26v


While writing this the current along RAM_RST very gradually dropped 
further to 6.9uA. Maybe it will continue creeping down to settle at the 
same 6.6-6.7 eventually?


This suggests that maybe the batteries would provide a worthwhile 
shelf-life extension after all, at least while installed in the machine 
which provides a real GND connection.


60mAh at 8uA works out to just over 10 months. (according to 
https://www.digikey.com/en/resources/conversion-calculators/conversion-calculator-battery-life)


That's worth doing I think. Especially when added to the 100's own 
shelf-life, that should work out to maybe 1.5 years total.


I still have to check the actual current drain at the battery. My 
current measurements above were just on the RAM_RST line from the bus 
board to the rexcpm, not at the battery itself. It's possible the 
battery is seeing more total current than just that through additional 
paths like reverse leakage through the schottkey from BATT+ to VBUS, and 
through RAM_RST into the 100.


Anyway it looks a lot more promising than I thought at first.


As for getting that same long shelf-life outside of the 100, one idea 
might be to mod the REXCPM to use a 4-pin JST-SH connector and use the 
same connector on the bus board, and a pre-made cable assembly.


Those are very small connectors and would be difficult to crimp the 
female connectors on the cable by hand, but they sell those pre-made in 
suitable lengths. And the male connectors are only 2.95mm tall and 7mm 
wide (really only 6mm but the flanges on the cable connector are 7mm) 
and that fits easily on both the rexcpm and the bus board.


On the rexcpm side it would have to be bodge wired to the 3 existing 
pins and the 4th pin to the negative side of the big cap, then secured 
with glue or mounting foam tape.


On the bus board it's nothing. The connector footprint fits right where 
the existing 3-pin header is now.


https://mou.sr/3K9FwRe
https://mou.sr/44Pcako

or

https://www.digikey.com/short/7hb4cm4q
https://www.digikey.com/short/wzj8ppjb


And as an added bonus, the new cable is fully polarity keyed on both 
ends too.


--
bkw


On 9/11/23 15:47, Ken St. Cyr wrote:
I love the idea, and would be keen to build one for myself if it could 
indeed extend the shelf life of my REXCPM memory to at least a few 
weeks. I tend to swap between my REXCPM and a standard REX, so even just 
having something to keep my REXCPM memory active for a few days while 
it’s out of the machine would save some trouble. I was thinking about 
doing a quick backup and restore using a TL866, but haven’t gotten 
around to tinkering with it.


It doesn’t sound like this would work well with that big cap needing to 
be kept charged. It’d be great if there was a way to take it out of 
circuit… maybe a jumper that you could remove if you have the REXCPM UPS 
hooked up


//Ken

*From: *M100  on behalf of Brian K. 
White 

*Date: *Monday, September 11, 2023 at 2:28 AM
*To: *m...@bitchin100.com 
*Subject: *[M100] rexcpm battery

I thought I made the slickest thing.

https://github.com/bkw77

Re: [M100] rexcpm battery

[Brian K. White]

On 9/11/23 15:47, Ken St. Cyr wrote:
I love the idea, and would be keen to build one for myself if it could 
indeed extend the shelf life of my REXCPM memory to at least a few 
weeks. I tend to swap between my REXCPM and a standard REX, so even just 
having something to keep my REXCPM memory active for a few days while 
it’s out of the machine would save some trouble. I was thinking about 
doing a quick backup and restore using a TL866, but haven’t gotten 
around to tinkering with it.


It doesn’t sound like this would work well with that big cap needing to 
be kept charged. It’d be great if there was a way to take it out of 
circuit… maybe a jumper that you could remove if you have the REXCPM UPS 
hooked up


I think the big cap is only a good thing. It's not draining the 
batteries, it's only helping them. It's providing the first 15 minutes 
of life for free, and then not hurting after that.


It also provides up to 15 minutes of battery-change grace period, 
depending on the starting level. If you briefly power-on the main 
computer before changing the batteries, you'll get the full 15 minutes 
at least (a few more before the ram actually loses data, but 15 is 
safe). If you start with almost dead batteries and simply remove them, 
you still may get a whole minute or more depending on just how dead they 
were. Even 15 seconds is a lot if you prepare and have the new batteries 
unpackaged and ready to go first.


The excess drain might possibly be because of the unintended ground path 
backfeeding though what are supposed to only be signal handling input or 
output gates in other components, instead of having an actual GND 
connection from the REXCPM to the battery negative. It could even be 
causing some ICs to no be disabled by their active-low /CE pins maybe.


Or it might be the REXCPM is keeping more stuff alive than the sram, or 
maybe there are pullups or pulldowns that have lower than necessary 
values burning current at all times. Or, maybe my replacement sram chip 
burns more than the original*.


These questions don't really have to be mysteries, they can all be 
answered by just looking and testing, I just haven't done that yet.


* When I got my REXCPM, Steve didn't have any 4M chips, so I got a 2M 
unit and replaced the chip myself, and I don't remember off the top of 
my head exactly what it's quiescent current was. The "over 1 year" 
estimate is just based on the typical value for almost any sram since 
the early 90's of 5 uA or less.


It just turned me on to get removable batteries into the available space 
right on the board and still be able to close the compartment cover.


It does require flush-cutting all the solder posts and the battery 
holder tabs. But to me that is more straightforward, convenient, and 
repeatable than finnicky hack or otherwise specialized pin construction.


Normally for "fake DIP legs" on a pcb intended to go into a dip socket, 
you want the pins to be as thin as possible to mimick an actual dip leg, 
so as not to stretch out flat leaf-style sockets. And often also want 
the pcb to be as low profile as possible with little or no 
shoulder/insulator between the contact leg and the pcb, to allow the 
most room for the components on top. But in this case the socket has 
machined round pin holes, and commodity machined round pin headers are 
perfectly fine in them, and the huge 4mm shoulder height is ok if all 
the parts can fit on the bottom of the pcb and leave the top clean and flat.


A separate keeper board will be trivial so I'll add that to the repo 
shortly. So, even if we have to just live with the inefficient sleeping 
instead of solving it, a couple AA's or something will be cheap, easy, 
and last a long time. That will be better than nothing and simple to do.




//Ken

*From: *M100  on behalf of Brian K. 
White 

*Date: *Monday, September 11, 2023 at 2:28 AM
*To: *m...@bitchin100.com 
*Subject: *[M100] rexcpm battery

I thought I made the slickest thing.

https://github.com/bkw777/REXCPM_UPS <https://github.com/bkw777/REXCPM_UPS>
https://photos.app.goo.gl/i87E4wzimexCR3wL6 
<https://photos.app.goo.gl/i87E4wzimexCR3wL6>


I was able to get 60mah of battery onto the system bus interface board
for REXCPM, and theoretically that should be able to keep the sram
memory for at least a year, but it looks like it will only last about 2
possibly 3 days.

So plan B is a separate "keeper". A separate thing with a much larger
battery that you connect to the rexcpm when not in the computer.

But that's only half of what I wanted. What I was really hoping for
though was to have the battery built-in, so that when the 100 batteries
die sitting on the shelf, the on-board battery is still there for at
least another year.

Both of these boards do work as merely ordinary rexcpm bus adapters,
whether the batteries are installed or not.

The 102/200 board also a

Re: [M100] rexcpm battery

[Ken St. Cyr]

I love the idea, and would be keen to build one for myself if it could indeed 
extend the shelf life of my REXCPM memory to at least a few weeks. I tend to 
swap between my REXCPM and a standard REX, so even just having something to 
keep my REXCPM memory active for a few days while it’s out of the machine would 
save some trouble. I was thinking about doing a quick backup and restore using 
a TL866, but haven’t gotten around to tinkering with it.

It doesn’t sound like this would work well with that big cap needing to be kept 
charged. It’d be great if there was a way to take it out of circuit… maybe a 
jumper that you could remove if you have the REXCPM UPS hooked up

//Ken

From: M100  on behalf of Brian K. White 

Date: Monday, September 11, 2023 at 2:28 AM
To: m...@bitchin100.com 
Subject: [M100] rexcpm battery
I thought I made the slickest thing.

https://github.com/bkw777/REXCPM_UPS
https://photos.app.goo.gl/i87E4wzimexCR3wL6

I was able to get 60mah of battery onto the system bus interface board
for REXCPM, and theoretically that should be able to keep the sram
memory for at least a year, but it looks like it will only last about 2
possibly 3 days.

So plan B is a separate "keeper". A separate thing with a much larger
battery that you connect to the rexcpm when not in the computer.

But that's only half of what I wanted. What I was really hoping for
though was to have the battery built-in, so that when the 100 batteries
die sitting on the shelf, the on-board battery is still there for at
least another year.

Both of these boards do work as merely ordinary rexcpm bus adapters,
whether the batteries are installed or not.

The 102/200 board also allows one to use a REXCPM on a 102 or 200
without soldering any wires or opening the case, although it does mean
using an external wire which is not exactly robust.

--
bkw

[M100] rexcpm battery

[Brian K. White]

I thought I made the slickest thing.

https://github.com/bkw777/REXCPM_UPS
https://photos.app.goo.gl/i87E4wzimexCR3wL6

I was able to get 60mah of battery onto the system bus interface board 
for REXCPM, and theoretically that should be able to keep the sram 
memory for at least a year, but it looks like it will only last about 2 
possibly 3 days.


So plan B is a separate "keeper". A separate thing with a much larger 
battery that you connect to the rexcpm when not in the computer.


But that's only half of what I wanted. What I was really hoping for 
though was to have the battery built-in, so that when the 100 batteries 
die sitting on the shelf, the on-board battery is still there for at 
least another year.


Both of these boards do work as merely ordinary rexcpm bus adapters, 
whether the batteries are installed or not.


The 102/200 board also allows one to use a REXCPM on a 102 or 200 
without soldering any wires or opening the case, although it does mean 
using an external wire which is not exactly robust.


--
bkw

Re: [M100] REXCPM

[John R. Hogerhuis]

On Thu, May 18, 2023, 6:32 AM David Plass  wrote:

> (Off topic): The beauty of a wiki is that all (approved) editors can edit
> and organize the content. I propose that there be more editors, to share
> the load.
>

More people creating content is always welcome! If anyone wants an account
just send me the email and username you want to use and I will create the
account.

Other than rex .. please don't edit the Rex pages, since that's content
Steve needs to control.

-- John.

Re: [M100] REXCPM

[David Plass]

(Off topic): The beauty of a wiki is that all (approved) editors can edit
and organize the content. I propose that there be more editors, to share
the load.

On Wed, May 17, 2023 at 10:38 PM Mike Stein  wrote:

> It is indeed a challenge to organize so much varied info; overall it's
> pretty well done but I think John could also put a few more entries in the
> top level index.
>
> Am I getting senile, or did you put a link to Ordering Info in the
> REX/REXCPM main page? Don't recall seeing that; problem solved..
>
> m
>
> On Wed, May 17, 2023 at 4:22 PM Stephen Adolph 
> wrote:
>
>> I'm not great at organizing stuff on the wiki.
>>
>> I'm also concious of creating dead pages since iirc you can't delete a
>> page.  In other words I try to reuse pages.
>>
>> I'll take a look and see if I can reorganize or otherwise improve.
>>
>> I have also thought about a fancier website, but it feels like it would
>> be a lot of extra work and cost.
>>
>>
>>
>> On Wednesday, May 17, 2023, John R. Hogerhuis  wrote:
>>
>>> OK. I was just curious where the confusion was... FWIW, Rex sales and
>>> support has always been in the wiki. I guess you're looking for it on the
>>> top level bitchin100 site, we could put a link there.
>>>
>>> As to REXCPM, I agree... the ordering link is under the REX# section of
>>> the REX page. If you search for rex, then immediately click on Rexcpm you
>>> will miss the ordering link.
>>>
>>> Probably bitchin100 should add a e-commerce store. We'll see.
>>>
>>> -- John.
>>>
>>> On Wed, May 17, 2023 at 12:42 PM MikeS  wrote:
>>>
>>>> Well, if you expect to find ordering info in the Wiki section...
>>>>
>>>> Even when you finally find the REXCPM section there's no mention of
>>>> ordering info in the contents index either; you have to guess that it's
>>>> under 'Links' in the Overview section as though it were on some external
>>>> site...
>>>>
>>>> I see I'm not the only one, and the person I just told about it
>>>> couldn't find it either (which is why I asked).
>>>>
>>>> 
>>>>
>>>> m
>>>>
>>>>
>>>> - Original Message -
>>>> *From:* John R. Hogerhuis 
>>>> *To:* m...@bitchin100.com
>>>> *Sent:* Wednesday, May 17, 2023 11:58 AM
>>>> *Subject:* Re: [M100] REXCPM
>>>>
>>>>
>>>>
>>>> On Wed, May 17, 2023, 7:39 AM MikeS  wrote:
>>>>
>>>>> Having a lot of trouble finding stuff in Bitchin100 these days...
>>>>> Where's the order page for REXCPM?
>>>>>
>>>>> m
>>>>>
>>>>
>>>> I went to the wiki, typed rex into the media wiki search bar and it
>>>> showed a link to the ordering page for rex#
>>>>
>>>> And since bitchin100 is now indexed by Google and bing you can just
>>>> search them for bitchin100 ordering rex and it takes you to the order page.
>>>>
>>>> So seems findable?
>>>>
>>>> -- John
>>>>
>>>>>
>>>>
>>>>

Re: [M100] REXCPM

[Mike Stein]

It is indeed a challenge to organize so much varied info; overall it's
pretty well done but I think John could also put a few more entries in the
top level index.

Am I getting senile, or did you put a link to Ordering Info in the
REX/REXCPM main page? Don't recall seeing that; problem solved..

m

On Wed, May 17, 2023 at 4:22 PM Stephen Adolph  wrote:

> I'm not great at organizing stuff on the wiki.
>
> I'm also concious of creating dead pages since iirc you can't delete a
> page.  In other words I try to reuse pages.
>
> I'll take a look and see if I can reorganize or otherwise improve.
>
> I have also thought about a fancier website, but it feels like it would be
> a lot of extra work and cost.
>
>
>
> On Wednesday, May 17, 2023, John R. Hogerhuis  wrote:
>
>> OK. I was just curious where the confusion was... FWIW, Rex sales and
>> support has always been in the wiki. I guess you're looking for it on the
>> top level bitchin100 site, we could put a link there.
>>
>> As to REXCPM, I agree... the ordering link is under the REX# section of
>> the REX page. If you search for rex, then immediately click on Rexcpm you
>> will miss the ordering link.
>>
>> Probably bitchin100 should add a e-commerce store. We'll see.
>>
>> -- John.
>>
>> On Wed, May 17, 2023 at 12:42 PM MikeS  wrote:
>>
>>> Well, if you expect to find ordering info in the Wiki section...
>>>
>>> Even when you finally find the REXCPM section there's no mention of
>>> ordering info in the contents index either; you have to guess that it's
>>> under 'Links' in the Overview section as though it were on some external
>>> site...
>>>
>>> I see I'm not the only one, and the person I just told about it couldn't
>>> find it either (which is why I asked).
>>>
>>> 
>>>
>>> m
>>>
>>>
>>> - Original Message -
>>> *From:* John R. Hogerhuis 
>>> *To:* m...@bitchin100.com
>>> *Sent:* Wednesday, May 17, 2023 11:58 AM
>>> *Subject:* Re: [M100] REXCPM
>>>
>>>
>>>
>>> On Wed, May 17, 2023, 7:39 AM MikeS  wrote:
>>>
>>>> Having a lot of trouble finding stuff in Bitchin100 these days...
>>>> Where's the order page for REXCPM?
>>>>
>>>> m
>>>>
>>>
>>> I went to the wiki, typed rex into the media wiki search bar and it
>>> showed a link to the ordering page for rex#
>>>
>>> And since bitchin100 is now indexed by Google and bing you can just
>>> search them for bitchin100 ordering rex and it takes you to the order page.
>>>
>>> So seems findable?
>>>
>>> -- John
>>>
>>>>
>>>
>>>

Re: [M100] REXCPM

[Stephen Adolph]

I'm not great at organizing stuff on the wiki.

I'm also concious of creating dead pages since iirc you can't delete a
page.  In other words I try to reuse pages.

I'll take a look and see if I can reorganize or otherwise improve.

I have also thought about a fancier website, but it feels like it would be
a lot of extra work and cost.



On Wednesday, May 17, 2023, John R. Hogerhuis  wrote:

> OK. I was just curious where the confusion was... FWIW, Rex sales and
> support has always been in the wiki. I guess you're looking for it on the
> top level bitchin100 site, we could put a link there.
>
> As to REXCPM, I agree... the ordering link is under the REX# section of
> the REX page. If you search for rex, then immediately click on Rexcpm you
> will miss the ordering link.
>
> Probably bitchin100 should add a e-commerce store. We'll see.
>
> -- John.
>
> On Wed, May 17, 2023 at 12:42 PM MikeS  wrote:
>
>> Well, if you expect to find ordering info in the Wiki section...
>>
>> Even when you finally find the REXCPM section there's no mention of
>> ordering info in the contents index either; you have to guess that it's
>> under 'Links' in the Overview section as though it were on some external
>> site...
>>
>> I see I'm not the only one, and the person I just told about it couldn't
>> find it either (which is why I asked).
>>
>> 
>>
>> m
>>
>>
>> - Original Message -
>> *From:* John R. Hogerhuis 
>> *To:* m...@bitchin100.com
>> *Sent:* Wednesday, May 17, 2023 11:58 AM
>> *Subject:* Re: [M100] REXCPM
>>
>>
>>
>> On Wed, May 17, 2023, 7:39 AM MikeS  wrote:
>>
>>> Having a lot of trouble finding stuff in Bitchin100 these days...
>>> Where's the order page for REXCPM?
>>>
>>> m
>>>
>>
>> I went to the wiki, typed rex into the media wiki search bar and it
>> showed a link to the ordering page for rex#
>>
>> And since bitchin100 is now indexed by Google and bing you can just
>> search them for bitchin100 ordering rex and it takes you to the order page.
>>
>> So seems findable?
>>
>> -- John
>>
>>>
>>
>>

Re: [M100] REXCPM

[John R. Hogerhuis]

OK. I was just curious where the confusion was... FWIW, Rex sales and
support has always been in the wiki. I guess you're looking for it on the
top level bitchin100 site, we could put a link there.

As to REXCPM, I agree... the ordering link is under the REX# section of the
REX page. If you search for rex, then immediately click on Rexcpm you will
miss the ordering link.

Probably bitchin100 should add a e-commerce store. We'll see.

-- John.

On Wed, May 17, 2023 at 12:42 PM MikeS  wrote:

> Well, if you expect to find ordering info in the Wiki section...
>
> Even when you finally find the REXCPM section there's no mention of
> ordering info in the contents index either; you have to guess that it's
> under 'Links' in the Overview section as though it were on some external
> site...
>
> I see I'm not the only one, and the person I just told about it couldn't
> find it either (which is why I asked).
>
> 
>
> m
>
>
> - Original Message -
> *From:* John R. Hogerhuis 
> *To:* m...@bitchin100.com
> *Sent:* Wednesday, May 17, 2023 11:58 AM
> *Subject:* Re: [M100] REXCPM
>
>
>
> On Wed, May 17, 2023, 7:39 AM MikeS  wrote:
>
>> Having a lot of trouble finding stuff in Bitchin100 these days...
>> Where's the order page for REXCPM?
>>
>> m
>>
>
> I went to the wiki, typed rex into the media wiki search bar and it showed
> a link to the ordering page for rex#
>
> And since bitchin100 is now indexed by Google and bing you can just search
> them for bitchin100 ordering rex and it takes you to the order page.
>
> So seems findable?
>
> -- John
>
>>
>
>

Re: [M100] REXCPM

[MikeS]

Well, if you expect to find ordering info in the Wiki section...

Even when you finally find the REXCPM section there's no mention of ordering 
info in the contents index either; you have to guess that it's under 'Links' in 
the Overview section as though it were on some external site...

I see I'm not the only one, and the person I just told about it couldn't find 
it either (which is why I asked).



m

  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Wednesday, May 17, 2023 11:58 AM
  Subject: Re: [M100] REXCPM





  On Wed, May 17, 2023, 7:39 AM MikeS  wrote:

Having a lot of trouble finding stuff in Bitchin100 these days...
Where's the order page for REXCPM?

m



  I went to the wiki, typed rex into the media wiki search bar and it showed a 
link to the ordering page for rex#


  And since bitchin100 is now indexed by Google and bing you can just search 
them for bitchin100 ordering rex and it takes you to the order page. 


  So seems findable?


  -- John

Re: [M100] REXCPM

[John R. Hogerhuis]

On Wed, May 17, 2023, 7:39 AM MikeS  wrote:

> Having a lot of trouble finding stuff in Bitchin100 these days...
> Where's the order page for REXCPM?
>
> m
>

I went to the wiki, typed rex into the media wiki search bar and it showed
a link to the ordering page for rex#

And since bitchin100 is now indexed by Google and bing you can just search
them for bitchin100 ordering rex and it takes you to the order page.

So seems findable?

-- John

>

Re: [M100] REXCPM

[Ken St. Cyr]

I had some difficulty finding it when I ordered mine a while back, too - 
http://bitchin100.com/wiki/index.php?title=Ordering_Information

FYI, I did a video last month on how I set mine up in case it helps - 
https://youtu.be/eZQLcTmW1sE

//Ken S.

From: M100  on behalf of MikeS 

Sent: Wednesday, May 17, 2023 10:39 AM
To: Model 100 Discussion 
Subject: [M100] REXCPM

Having a lot of trouble finding stuff in Bitchin100 these days...

Where's the order page for REXCPM?

m

[M100] REXCPM

[MikeS]

Having a lot of trouble finding stuff in Bitchin100 these days...

Where's the order page for REXCPM?

m

Re: [M100] RexCPM install

[Brian K. White]

I recently got dlplus working under cygwin and msys2, but I had to make 
changes to support it, it didn't work out of the box.
Were you using github.com/bkw777/dlplus or the zip file on bitchin100? 
It just worked or did you have to do anything to make it work?


I need to change the name of my fork. "dlplus" really still refers to 
John's version from the zip file on bitchin100.
And mine has deviated so far by now that it's no longer even very 
similar either inside or out.
And, I never liked that it was called dl-anything in the first place. 
DeskLink is Travelling Software's name, and so the original "dl for 
unix" and John's continuation "dlplus" should just not have been 
dl-anything in the first place, just like I should not call it 
LaddiePlus now.

But I don't know what.

dl2 makes the most sense if I didn't care about the "dl" part. It says 
what it is and what to expect correctly and succinctly.


vpdd ? virtual pdd,   meh
ndl ? new desklink or not desklink as you prefer,  meh
pddserver - just to needle Steve ;)
tpddd - tandy portable disk drive daemon , even I don't hate people that 
much

pdde ? maybe
fb100ulator - nailed it

--
bkw

On 10/16/22 17:33, Ben Wiley Sittler wrote:
I regularly use dlplus from a Cygwin command-line shell interface in 
Windows too, but I realize that's not everyone's cup of tea


On Sun, Oct 16, 2022, 14:29 Brian K. White  wrote:

On 10/16/22 14:17, Stephen Adolph wrote:
> Hi Robert, couple of comments.
>
> 1) test your REXCPM.  you can always test it yourself and see if
you
> have a hardware problem
> https://bitchin100.com/wiki/index.php?title=REXCPM
> 
> read up on how to load and run REXCPM.
> I would not do this if you are happy with the REX# part of the
install.
> In fact if that is working, likely no hardware problem.
> There is only one memory chip and it is used for both REX# and CPM.
>
> 2)  Philip's routines more or less rely on LaddieAlpha to
operate.  I
> would recommend you use LaddieAlpha as the TPDD client.

Laddie is a server not a client. You confuse things by insisting on
using the wrong terminology in what are supposed to be reference
documents.

I routinely use dlplus to reload rexcpm. But that's only available
from
linux or mac. In fact thanks to the fact that you have packaged up
rxcini as a loader.do it makes it super convenient to use the
bootstrapper to directly run rxcini in one shot. Same for REX#.
Thanks
much for that.

You can get that same convenience from Windows with a combination of
tsend.ps1 and laddie. Basically:
tsend.ps1 rxcini.DO ;laddiealpha.exe laddie-options-I-don't-remember
all one commandline.

github.com/bkw777/tsend.ps1 

For Robert, I would make sure you're following the points about
clearing
ram before trying to run cpmupd, and definitely use tpdd to copy
cpmupd
to the machine in case you're not.

I think you'll have to list out all the actual steps you're
performing
when you say doesn't work because "it works for me". But it doesn't
always work the first time just from memory.

The directions are somehow confusing to read and get the bullet
points
that matter. Even though I've done it several times and have tried to
write down my own more direct version, I still end up having to
pull up
the bitchin100 pages and refer to some points after it doesn't
work the
first time just from memory. Usually I forget one of the two times
you
should issue a clear statement.

> This is because the files are binary files with a .BK extension.
> Also, make sure you load and run CPMUPD.CO 
> after you
> power off, power on.  This is to ensure you are in the default
RAM config.

There you go, exactly the kind of step I skip or forget the
importance of.

But when I go back to the wiki page and don't skip anything, it
always
works.

-- 
bkw

[M100] REXCPM (2meg) and VT100 adapter board for sale

[bob]

Hello!  I have enjoyed using my M100 REXCPM OptROM and VT100 adapter board
that Steve Adolph sells.  But it is time to part with them.
If anyone is interested at $90 plus shipping, please contact me off list.
Thank you.

b...@pigford.org 

Re: [M100] RexCPM install

[Ben Wiley Sittler]

Unlike wsl, cygwin has access to hardware (at least when run with suitable
permissions)

On Sun, Oct 16, 2022, 18:11 Brian White  wrote:

> It actually works from cygwin? I've actually never even tried it. (dlplus
> I mean, I used to use cygwin all the time but not in the last several
> years). I figured if WSL doesn't work then not even worth trying cygwin.
>
> I will try it and update the readme because this would be great.
>
>
> bkw
>
> On Sun, Oct 16, 2022, 5:33 PM Ben Wiley Sittler 
> wrote:
>
>> I regularly use dlplus from a Cygwin command-line shell interface in
>> Windows too, but I realize that's not everyone's cup of tea
>>
>> On Sun, Oct 16, 2022, 14:29 Brian K. White  wrote:
>>
>>> On 10/16/22 14:17, Stephen Adolph wrote:
>>> > Hi Robert, couple of comments.
>>> >
>>> > 1) test your REXCPM.  you can always test it yourself and see if you
>>> > have a hardware problem
>>> > https://bitchin100.com/wiki/index.php?title=REXCPM
>>> > 
>>> > read up on how to load and run REXCPM.
>>> > I would not do this if you are happy with the REX# part of the
>>> install.
>>> > In fact if that is working, likely no hardware problem.
>>> > There is only one memory chip and it is used for both REX# and CPM.
>>> >
>>> > 2)  Philip's routines more or less rely on LaddieAlpha to operate.  I
>>> > would recommend you use LaddieAlpha as the TPDD client.
>>>
>>> Laddie is a server not a client. You confuse things by insisting on
>>> using the wrong terminology in what are supposed to be reference
>>> documents.
>>>
>>> I routinely use dlplus to reload rexcpm. But that's only available from
>>> linux or mac. In fact thanks to the fact that you have packaged up
>>> rxcini as a loader.do it makes it super convenient to use the
>>> bootstrapper to directly run rxcini in one shot. Same for REX#. Thanks
>>> much for that.
>>>
>>> You can get that same convenience from Windows with a combination of
>>> tsend.ps1 and laddie. Basically:
>>> tsend.ps1 rxcini.DO ;laddiealpha.exe laddie-options-I-don't-remember
>>> all one commandline.
>>>
>>> github.com/bkw777/tsend.ps1
>>>
>>> For Robert, I would make sure you're following the points about clearing
>>> ram before trying to run cpmupd, and definitely use tpdd to copy cpmupd
>>> to the machine in case you're not.
>>>
>>> I think you'll have to list out all the actual steps you're performing
>>> when you say doesn't work because "it works for me". But it doesn't
>>> always work the first time just from memory.
>>>
>>> The directions are somehow confusing to read and get the bullet points
>>> that matter. Even though I've done it several times and have tried to
>>> write down my own more direct version, I still end up having to pull up
>>> the bitchin100 pages and refer to some points after it doesn't work the
>>> first time just from memory. Usually I forget one of the two times you
>>> should issue a clear statement.
>>>
>>> > This is because the files are binary files with a .BK extension.
>>> > Also, make sure you load and run CPMUPD.CO  after
>>> you
>>> > power off, power on.  This is to ensure you are in the default RAM
>>> config.
>>>
>>> There you go, exactly the kind of step I skip or forget the importance
>>> of.
>>>
>>> But when I go back to the wiki page and don't skip anything, it always
>>> works.
>>>
>>> --
>>> bkw
>>>
>>>

Re: [M100] RexCPM install

[Brian White]

It actually works from cygwin? I've actually never even tried it. (dlplus I
mean, I used to use cygwin all the time but not in the last several years).
I figured if WSL doesn't work then not even worth trying cygwin.

I will try it and update the readme because this would be great.


bkw

On Sun, Oct 16, 2022, 5:33 PM Ben Wiley Sittler  wrote:

> I regularly use dlplus from a Cygwin command-line shell interface in
> Windows too, but I realize that's not everyone's cup of tea
>
> On Sun, Oct 16, 2022, 14:29 Brian K. White  wrote:
>
>> On 10/16/22 14:17, Stephen Adolph wrote:
>> > Hi Robert, couple of comments.
>> >
>> > 1) test your REXCPM.  you can always test it yourself and see if you
>> > have a hardware problem
>> > https://bitchin100.com/wiki/index.php?title=REXCPM
>> > 
>> > read up on how to load and run REXCPM.
>> > I would not do this if you are happy with the REX# part of the
>> install.
>> > In fact if that is working, likely no hardware problem.
>> > There is only one memory chip and it is used for both REX# and CPM.
>> >
>> > 2)  Philip's routines more or less rely on LaddieAlpha to operate.  I
>> > would recommend you use LaddieAlpha as the TPDD client.
>>
>> Laddie is a server not a client. You confuse things by insisting on
>> using the wrong terminology in what are supposed to be reference
>> documents.
>>
>> I routinely use dlplus to reload rexcpm. But that's only available from
>> linux or mac. In fact thanks to the fact that you have packaged up
>> rxcini as a loader.do it makes it super convenient to use the
>> bootstrapper to directly run rxcini in one shot. Same for REX#. Thanks
>> much for that.
>>
>> You can get that same convenience from Windows with a combination of
>> tsend.ps1 and laddie. Basically:
>> tsend.ps1 rxcini.DO ;laddiealpha.exe laddie-options-I-don't-remember
>> all one commandline.
>>
>> github.com/bkw777/tsend.ps1
>>
>> For Robert, I would make sure you're following the points about clearing
>> ram before trying to run cpmupd, and definitely use tpdd to copy cpmupd
>> to the machine in case you're not.
>>
>> I think you'll have to list out all the actual steps you're performing
>> when you say doesn't work because "it works for me". But it doesn't
>> always work the first time just from memory.
>>
>> The directions are somehow confusing to read and get the bullet points
>> that matter. Even though I've done it several times and have tried to
>> write down my own more direct version, I still end up having to pull up
>> the bitchin100 pages and refer to some points after it doesn't work the
>> first time just from memory. Usually I forget one of the two times you
>> should issue a clear statement.
>>
>> > This is because the files are binary files with a .BK extension.
>> > Also, make sure you load and run CPMUPD.CO  after
>> you
>> > power off, power on.  This is to ensure you are in the default RAM
>> config.
>>
>> There you go, exactly the kind of step I skip or forget the importance of.
>>
>> But when I go back to the wiki page and don't skip anything, it always
>> works.
>>
>> --
>> bkw
>>
>>

Re: [M100] RexCPM install

[Ben Wiley Sittler]

I regularly use dlplus from a Cygwin command-line shell interface in
Windows too, but I realize that's not everyone's cup of tea

On Sun, Oct 16, 2022, 14:29 Brian K. White  wrote:

> On 10/16/22 14:17, Stephen Adolph wrote:
> > Hi Robert, couple of comments.
> >
> > 1) test your REXCPM.  you can always test it yourself and see if you
> > have a hardware problem
> > https://bitchin100.com/wiki/index.php?title=REXCPM
> > 
> > read up on how to load and run REXCPM.
> > I would not do this if you are happy with the REX# part of the install.
> > In fact if that is working, likely no hardware problem.
> > There is only one memory chip and it is used for both REX# and CPM.
> >
> > 2)  Philip's routines more or less rely on LaddieAlpha to operate.  I
> > would recommend you use LaddieAlpha as the TPDD client.
>
> Laddie is a server not a client. You confuse things by insisting on
> using the wrong terminology in what are supposed to be reference documents.
>
> I routinely use dlplus to reload rexcpm. But that's only available from
> linux or mac. In fact thanks to the fact that you have packaged up
> rxcini as a loader.do it makes it super convenient to use the
> bootstrapper to directly run rxcini in one shot. Same for REX#. Thanks
> much for that.
>
> You can get that same convenience from Windows with a combination of
> tsend.ps1 and laddie. Basically:
> tsend.ps1 rxcini.DO ;laddiealpha.exe laddie-options-I-don't-remember
> all one commandline.
>
> github.com/bkw777/tsend.ps1
>
> For Robert, I would make sure you're following the points about clearing
> ram before trying to run cpmupd, and definitely use tpdd to copy cpmupd
> to the machine in case you're not.
>
> I think you'll have to list out all the actual steps you're performing
> when you say doesn't work because "it works for me". But it doesn't
> always work the first time just from memory.
>
> The directions are somehow confusing to read and get the bullet points
> that matter. Even though I've done it several times and have tried to
> write down my own more direct version, I still end up having to pull up
> the bitchin100 pages and refer to some points after it doesn't work the
> first time just from memory. Usually I forget one of the two times you
> should issue a clear statement.
>
> > This is because the files are binary files with a .BK extension.
> > Also, make sure you load and run CPMUPD.CO  after you
> > power off, power on.  This is to ensure you are in the default RAM
> config.
>
> There you go, exactly the kind of step I skip or forget the importance of.
>
> But when I go back to the wiki page and don't skip anything, it always
> works.
>
> --
> bkw
>
>

Re: [M100] RexCPM install

[Brian K. White]

On 10/16/22 14:17, Stephen Adolph wrote:

Hi Robert, couple of comments.

1) test your REXCPM.  you can always test it yourself and see if you 
have a hardware problem
https://bitchin100.com/wiki/index.php?title=REXCPM 


read up on how to load and run REXCPM.
I would not do this if you are happy with the REX# part of the install.  
In fact if that is working, likely no hardware problem.

There is only one memory chip and it is used for both REX# and CPM.

2)  Philip's routines more or less rely on LaddieAlpha to operate.  I 
would recommend you use LaddieAlpha as the TPDD client.


Laddie is a server not a client. You confuse things by insisting on 
using the wrong terminology in what are supposed to be reference documents.


I routinely use dlplus to reload rexcpm. But that's only available from 
linux or mac. In fact thanks to the fact that you have packaged up 
rxcini as a loader.do it makes it super convenient to use the 
bootstrapper to directly run rxcini in one shot. Same for REX#. Thanks 
much for that.


You can get that same convenience from Windows with a combination of 
tsend.ps1 and laddie. Basically:

tsend.ps1 rxcini.DO ;laddiealpha.exe laddie-options-I-don't-remember
all one commandline.

github.com/bkw777/tsend.ps1

For Robert, I would make sure you're following the points about clearing 
ram before trying to run cpmupd, and definitely use tpdd to copy cpmupd 
to the machine in case you're not.


I think you'll have to list out all the actual steps you're performing 
when you say doesn't work because "it works for me". But it doesn't 
always work the first time just from memory.


The directions are somehow confusing to read and get the bullet points 
that matter. Even though I've done it several times and have tried to 
write down my own more direct version, I still end up having to pull up 
the bitchin100 pages and refer to some points after it doesn't work the 
first time just from memory. Usually I forget one of the two times you 
should issue a clear statement.



This is because the files are binary files with a .BK extension.
Also, make sure you load and run CPMUPD.CO  after you 
power off, power on.  This is to ensure you are in the default RAM config.


There you go, exactly the kind of step I skip or forget the importance of.

But when I go back to the wiki page and don't skip anything, it always 
works.


--
bkw

Re: [M100] RexCPM install

[Philip Avery]

Robert

Are you sure you're using the same TPDD emulator & any usb-serial cable 
as previously? LaddieAlpha is rock solid in my experience and CPMUPD 
will work, presuming REXCPM is operating normally.


Philip

On 17/10/2022 7:17 am, Stephen Adolph wrote:

Hi Robert, couple of comments.

1) test your REXCPM.  you can always test it yourself and see if you 
have a hardware problem

https://bitchin100.com/wiki/index.php?title=REXCPM
read up on how to load and run REXCPM.
I would not do this if you are happy with the REX# part of the 
install.  In fact if that is working, likely no hardware problem.

There is only one memory chip and it is used for both REX# and CPM.

2)  Philip's routines more or less rely on LaddieAlpha to operate.  I 
would recommend you use LaddieAlpha as the TPDD client.

This is because the files are binary files with a .BK extension.
Also, make sure you load and run CPMUPD.CO  after 
you power off, power on.  This is to ensure you are in the default RAM 
config.



cheers
Steve



On Sat, Oct 15, 2022 at 5:24 PM Robert Hutchins 
 wrote:


Hi all,

Having trouble installing CPM into my Model 100 with the RexCPM
ROM kit.

I get the REX part installed, but am unable to get CPMUPD to do
its job…

It either just hangs, doing nothing or sometimes it will work, but
then, when it

prompts for the CPM file (CPM210.bk) it refuses to load this. Just
sits there hung…

Any ideas would be welcome.

At one point in the past,  I did have it working, but it expired
(batteries all died) .

Is there any chance the memory in the RexCPM device is failing…

Thank you

Robert J. Hutchins

Re: [M100] RexCPM install

[Stephen Adolph]

Hi Robert, couple of comments.

1) test your REXCPM.  you can always test it yourself and see if you have a
hardware problem
https://bitchin100.com/wiki/index.php?title=REXCPM
read up on how to load and run REXCPM.
I would not do this if you are happy with the REX# part of the install.  In
fact if that is working, likely no hardware problem.
There is only one memory chip and it is used for both REX# and CPM.

2)  Philip's routines more or less rely on LaddieAlpha to operate.  I would
recommend you use LaddieAlpha as the TPDD client.
This is because the files are binary files with a .BK extension.
Also, make sure you load and run CPMUPD.CO after you power off, power on.
This is to ensure you are in the default RAM config.


cheers
Steve



On Sat, Oct 15, 2022 at 5:24 PM Robert Hutchins 
wrote:

>
>
> Hi all,
>
>
>
> Having trouble installing CPM into my Model 100 with the RexCPM ROM kit.
>
> I get the REX part installed, but am unable to get CPMUPD to do its job…
>
>
>
> It either just hangs, doing nothing or sometimes it will work, but then,
> when it
>
> prompts for the CPM file (CPM210.bk) it refuses to load this. Just sits
> there hung…
>
>
>
> Any ideas would be welcome.
>
> At one point in the past,  I did have it working, but it expired
> (batteries all died) .
>
> Is there any chance the memory in the RexCPM device is failing…
>
>
>
> Thank you
>
> Robert J. Hutchins
>
>
>

[M100] RexCPM install

[Robert Hutchins]

 

Hi all,

 

Having trouble installing CPM into my Model 100 with the RexCPM ROM kit.

I get the REX part installed, but am unable to get CPMUPD to do its job.

 

It either just hangs, doing nothing or sometimes it will work, but then,
when it

prompts for the CPM file (CPM210.bk) it refuses to load this. Just sits
there hung.

 

Any ideas would be welcome.

At one point in the past,  I did have it working, but it expired (batteries
all died) .

Is there any chance the memory in the RexCPM device is failing.

 

Thank you

Robert J. Hutchins

 

Re: [M100] REXCPM for Model 200?

[Stephen Adolph]

Soldered.  Would be nice to make that easier.

On Saturday, September 3, 2022, B 9  wrote:

> I agree with Birt, those micrograbbers are finicky. How does the wire for
> RexCPM connect securely in the T102?
>
> —b9
>
> On Mon, Aug 29, 2022 at 5:25 PM Stephen Adolph 
> wrote:
>
>> Bit of a step forward in terms of REXCPM for T200.
>>
>> In experiments on a real T200 (not virtualT), I get the following nice
>> result.
>>
>> Question:  What memory is accessed in the "address hole" from 8000-9FFF"
>> when Option ROM is selected (BANK3)?
>> - ideally CP/M needs a full 64k
>> - we have ram from A000-
>> - we have "REXCPM RAM" from -7FFF (when BANK3 is active)
>> - ... and,  we know that the 2nd 8K MAIN ROM is accessed from 8000-9FFF
>> when BANK1 is active.
>>
>> Turns out that the Option ROM is actually chip selected for the entire
>> address range from -7FFF AND 8000-9FFF!
>> --> when I run a "peeker" program that switches the option ROM on, and
>> then reads back the memory value from an address, the laptop responds with
>> the SAME value from -1FFF and 8000-9FFF.
>>
>> --> if the option ROM socket had the A15 signal, then it could
>> distinguish between the addresses.
>>
>> Said another way,
>> If the Option ROM socket had a 33rd signal, A15, it could support 40KB
>> worth of ROM memory.
>>
>> Maybe we can use something like this as an easy way to grab A15 from an
>> internal location?
>>
>> https://www.ebay.ca/itm/253076010211?hash=item3aec8174e3:g:
>> U6cAAOSwbmdZgrNP&amdata=enc%3AAQAH8O%2BKwe9wfSB0ZCf9NL04BWAEWnVZHPJ
>> %2BT%2BHLBzEY1gVeSf7OTaXsaxnr6JwWChHUHT7prORrrMSMiHFq%2F1%
>> 2Bjtp6bDA8e9kV2jiEeIOs3%2BGUpm7kzMlXvBrqcxGnckEHOk6dda
>> qGdNkxwD%2BXT3mw6PRS4fvgyEb6F%2B%2B6n1HNINZA87pEbiSn7B6AZkEVbVi
>> f2zL7S0cJbabZHXoFcWtu0WhUYfu56fE4OdjuyRx%2BafocbP2PnQ%2Fn%
>> 2Fu9tCqD9TYlXbA7n%2F75Ph6UZCTUtcgh36XdeqMgK5xDfYo9C8GnRVZRhmXRc8TM82NB%
>> 2FmMpp7aSL4fA%3D%3D%7Ctkp%3ABk9SR5DLx7_dYA
>>
>>
>> Steve
>>
>> Therefore, the only "additional signal" needed, for REXCPM in T200, is to
>> bring A15 to the memory area.
>>
>>
>>

Re: [M100] REXCPM for Model 200?

[B 9]

I agree with Birt, those micrograbbers are finicky. How does the wire for
RexCPM connect securely in the T102?

—b9

On Mon, Aug 29, 2022 at 5:25 PM Stephen Adolph  wrote:

> Bit of a step forward in terms of REXCPM for T200.
>
> In experiments on a real T200 (not virtualT), I get the following nice
> result.
>
> Question:  What memory is accessed in the "address hole" from 8000-9FFF"
> when Option ROM is selected (BANK3)?
> - ideally CP/M needs a full 64k
> - we have ram from A000-
> - we have "REXCPM RAM" from -7FFF (when BANK3 is active)
> - ... and,  we know that the 2nd 8K MAIN ROM is accessed from 8000-9FFF
> when BANK1 is active.
>
> Turns out that the Option ROM is actually chip selected for the entire
> address range from -7FFF AND 8000-9FFF!
> --> when I run a "peeker" program that switches the option ROM on, and
> then reads back the memory value from an address, the laptop responds with
> the SAME value from -1FFF and 8000-9FFF.
>
> --> if the option ROM socket had the A15 signal, then it could distinguish
> between the addresses.
>
> Said another way,
> If the Option ROM socket had a 33rd signal, A15, it could support 40KB
> worth of ROM memory.
>
> Maybe we can use something like this as an easy way to grab A15 from an
> internal location?
>
>
> https://www.ebay.ca/itm/253076010211?hash=item3aec8174e3:g:U6cAAOSwbmdZgrNP&amdata=enc%3AAQAH8O%2BKwe9wfSB0ZCf9NL04BWAEWnVZHPJ%2BT%2BHLBzEY1gVeSf7OTaXsaxnr6JwWChHUHT7prORrrMSMiHFq%2F1%2Bjtp6bDA8e9kV2jiEeIOs3%2BGUpm7kzMlXvBrqcxGnckEHOk6ddaqGdNkxwD%2BXT3mw6PRS4fvgyEb6F%2B%2B6n1HNINZA87pEbiSn7B6AZkEVbVif2zL7S0cJbabZHXoFcWtu0WhUYfu56fE4OdjuyRx%2BafocbP2PnQ%2Fn%2Fu9tCqD9TYlXbA7n%2F75Ph6UZCTUtcgh36XdeqMgK5xDfYo9C8GnRVZRhmXRc8TM82NB%2FmMpp7aSL4fA%3D%3D%7Ctkp%3ABk9SR5DLx7_dYA
>
>
> Steve
>
> Therefore, the only "additional signal" needed, for REXCPM in T200, is to
> bring A15 to the memory area.
>
>
>

Re: [M100] REXCPM for Model 200?

[birt_j]

I find quality micrograbbers ‘OK’ for a test situation for a permanent 
connection, particularly on something portable I don’t think they are a good 
solution. Cheap micrograbbers fall off if you look at them cross eyed.

 

Jeff Birt

 

From: M100  On Behalf Of Stephen Adolph
Sent: Monday, August 29, 2022 7:24 PM
To: m...@bitchin100.com
Subject: Re: [M100] REXCPM for Model 200?

 

Bit of a step forward in terms of REXCPM for T200.

 

In experiments on a real T200 (not virtualT), I get the following nice result.

 

Question:  What memory is accessed in the "address hole" from 8000-9FFF" when 
Option ROM is selected (BANK3)?

- ideally CP/M needs a full 64k

- we have ram from A000-

- we have "REXCPM RAM" from -7FFF (when BANK3 is active)

- ... and,  we know that the 2nd 8K MAIN ROM is accessed from 8000-9FFF when 
BANK1 is active.

 

Turns out that the Option ROM is actually chip selected for the entire address 
range from -7FFF AND 8000-9FFF!

--> when I run a "peeker" program that switches the option ROM on, and then 
reads back the memory value from an address, the laptop responds with the SAME 
value from -1FFF and 8000-9FFF.

 

--> if the option ROM socket had the A15 signal, then it could distinguish 
between the addresses.

 

Said another way, 

If the Option ROM socket had a 33rd signal, A15, it could support 40KB worth of 
ROM memory.

 

Maybe we can use something like this as an easy way to grab A15 from an 
internal location?

 

https://www.ebay.ca/itm/253076010211?hash=item3aec8174e3:g:U6cAAOSwbmdZgrNP 
<https://www.ebay.ca/itm/253076010211?hash=item3aec8174e3:g:U6cAAOSwbmdZgrNP&amdata=enc%3AAQAH8O%2BKwe9wfSB0ZCf9NL04BWAEWnVZHPJ%2BT%2BHLBzEY1gVeSf7OTaXsaxnr6JwWChHUHT7prORrrMSMiHFq%2F1%2Bjtp6bDA8e9kV2jiEeIOs3%2BGUpm7kzMlXvBrqcxGnckEHOk6ddaqGdNkxwD%2BXT3mw6PRS4fvgyEb6F%2B%2B6n1HNINZA87pEbiSn7B6AZkEVbVif2zL7S0cJbabZHXoFcWtu0WhUYfu56fE4OdjuyRx%2BafocbP2PnQ%2Fn%2Fu9tCqD9TYlXbA7n%2F75Ph6UZCTUtcgh36XdeqMgK5xDfYo9C8GnRVZRhmXRc8TM82NB%2FmMpp7aSL4fA%3D%3D%7Ctkp%3ABk9SR5DLx7_dYA>
 
&amdata=enc%3AAQAH8O%2BKwe9wfSB0ZCf9NL04BWAEWnVZHPJ%2BT%2BHLBzEY1gVeSf7OTaXsaxnr6JwWChHUHT7prORrrMSMiHFq%2F1%2Bjtp6bDA8e9kV2jiEeIOs3%2BGUpm7kzMlXvBrqcxGnckEHOk6ddaqGdNkxwD%2BXT3mw6PRS4fvgyEb6F%2B%2B6n1HNINZA87pEbiSn7B6AZkEVbVif2zL7S0cJbabZHXoFcWtu0WhUYfu56fE4OdjuyRx%2BafocbP2PnQ%2Fn%2Fu9tCqD9TYlXbA7n%2F75Ph6UZCTUtcgh36XdeqMgK5xDfYo9C8GnRVZRhmXRc8TM82NB%2FmMpp7aSL4fA%3D%3D%7Ctkp%3ABk9SR5DLx7_dYA

 

 

Steve

 

Therefore, the only "additional signal" needed, for REXCPM in T200, is to bring 
A15 to the memory area.

 

 

Re: [M100] REXCPM for Model 200?

[Stephen Adolph]

Bit of a step forward in terms of REXCPM for T200.

In experiments on a real T200 (not virtualT), I get the following nice
result.

Question:  What memory is accessed in the "address hole" from 8000-9FFF"
when Option ROM is selected (BANK3)?
- ideally CP/M needs a full 64k
- we have ram from A000-
- we have "REXCPM RAM" from -7FFF (when BANK3 is active)
- ... and,  we know that the 2nd 8K MAIN ROM is accessed from 8000-9FFF
when BANK1 is active.

Turns out that the Option ROM is actually chip selected for the entire
address range from -7FFF AND 8000-9FFF!
--> when I run a "peeker" program that switches the option ROM on, and then
reads back the memory value from an address, the laptop responds with the
SAME value from -1FFF and 8000-9FFF.

--> if the option ROM socket had the A15 signal, then it could distinguish
between the addresses.

Said another way,
If the Option ROM socket had a 33rd signal, A15, it could support 40KB
worth of ROM memory.

Maybe we can use something like this as an easy way to grab A15 from an
internal location?

https://www.ebay.ca/itm/253076010211?hash=item3aec8174e3:g:U6cAAOSwbmdZgrNP&amdata=enc%3AAQAH8O%2BKwe9wfSB0ZCf9NL04BWAEWnVZHPJ%2BT%2BHLBzEY1gVeSf7OTaXsaxnr6JwWChHUHT7prORrrMSMiHFq%2F1%2Bjtp6bDA8e9kV2jiEeIOs3%2BGUpm7kzMlXvBrqcxGnckEHOk6ddaqGdNkxwD%2BXT3mw6PRS4fvgyEb6F%2B%2B6n1HNINZA87pEbiSn7B6AZkEVbVif2zL7S0cJbabZHXoFcWtu0WhUYfu56fE4OdjuyRx%2BafocbP2PnQ%2Fn%2Fu9tCqD9TYlXbA7n%2F75Ph6UZCTUtcgh36XdeqMgK5xDfYo9C8GnRVZRhmXRc8TM82NB%2FmMpp7aSL4fA%3D%3D%7Ctkp%3ABk9SR5DLx7_dYA


Steve

Therefore, the only "additional signal" needed, for REXCPM in T200, is to
bring A15 to the memory area.

Re: [M100] REXCPM for Model 200?

[B 9]

A wire sounds good enough for me. I tried to trace the PCB to figure out
where A15 could most easily be tapped, but the resolution of the PCB scan
from the Tandy 200 Service Manual is too low.

—b9


On Wed, May 25, 2022 at 7:34 PM Stephen Adolph  wrote:

> Well,
> Looking at the REXCPM board, it is possible to go from 3 signals on the
> jumper to 4.
> This would allow for A15 to be brought in, and to identify the special
> case where /BANK3 is zero but the address bus is 8000-9FFF.
> At first blush I can't think of a good way to solve this other than by
> adding a wire.
>
> Which puts the T200 install on the same page as T102, with a single wire
> required.
>
>
> On Wed, May 25, 2022 at 10:16 PM Stephen Adolph 
> wrote:
>
>> AH, I see your point.
>> I stand corrected, A15 is not on the socket.
>> [image: image.png]
>>
>> So, maybe your suggestion works; is A15 needed at all?
>>
>> Yes, I think it is needed.
>>
>> How would you tell the difference between these two addresses, from the
>> perspective of REXCPM?
>>
>>   vs 8000.
>> Both have /BANK3 = 0, and /BANK6=1.  And A14 to A0 = 000.
>>
>>
>> Seems like you gotta have an additional signal, A15.  And A15 is NOT on
>> the memory card.  That means you would need to jumper in from inside the
>> case.
>>
>>
>> Thanks, good discussion. I think I got all excited but I forgot which
>> part of the address was multiplexed!!
>>
>>
>>
>> On Wed, May 25, 2022 at 10:08 PM Stephen Adolph 
>> wrote:
>>
>>> Couple of comments.
>>>
>>> Agree with your rule, but REXCPM is even more fancy.
>>>
>>> It supports 32k bank switching in  to 7FFF and 2 banks of 16k
>>> switched at 8000 to BFFF and C000 to .  So REXCPM has to differentiate
>>> a bit based on which bank is indicated.
>>>
>>> All this bank switching to support RAM disk as well as general option
>>> rom switching, plus general ram banking.
>>>
>>> I agree the service manual isnt clear.  But I know from experience that
>>> ALE can latch A8 to A15 in T200 and M100 option rom socket.
>>>
>>> One diagram does make it clear though.  I'll snip and send separately.
>>>
>>> 8085 in general has a multiplexed address bus.
>>>
>>>
>>>
>>> On Wednesday, May 25, 2022, B 9  wrote:
>>>
>>>> Yes, that helps quite a bit. Thank you.
>>>>
>>>> One more question: If you are already handling situations 1 & 3 — bank3
>>>> is low and bank 6 is high for both, so A15 must be checked — why not reduce
>>>> the scenarios to a single rule:
>>>>
>>>>- If either bank3 or bank6 is low, address is 0 to , rexcpm
>>>>responds.
>>>>
>>>> —b9
>>>>
>>>> P.S. Where can I read more about the data latched in by ALE? The Tandy
>>>> 200 service manual and technical reference make it look like the AD bus is
>>>> holding only the lowest 8 bits of the memory address, A7 to A0, so I do not
>>>> yet understand how it contains A15.
>>>>
>>>>
>>>> On Wed, May 25, 2022 at 6:10 PM Stephen Adolph 
>>>> wrote:
>>>>
>>>>> when bank3 is low, address  to 7fff, bank6 is high, rexcpm
>>>>> responds.
>>>>>
>>>>> When bank6 is low, address a000 to , bank3 is high, rexcpm responds
>>>>>
>>>>> When bank3 is low, address 8000 to 9fff, bank6 is high, rexcpm
>>>>> responds.
>>>>>
>>>>> All of these scenarios are unique.  Cpm gets 64k when option rom and
>>>>> optikn ram 2 are engaged.
>>>>>
>>>>> Yah?  Hope that helps.
>>>>>
>>>>> Steve
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wednesday, May 25, 2022, B 9  wrote:
>>>>>
>>>>>> I'm a little confused.
>>>>>>
>>>>>> It sounds like you're selecting on /BANK3 = 0 (option ROM selected)
>>>>>> AND  /BANK6 = 0 (expansion RAM selected). But, if I'm reading figure 4-6
>>>>>> from the service manual correctly, /BANK3=0 AND /BANK6=0 will always be
>>>>>> false because no two banks are ever selected at the same time. Decoders
>>>>>> AA0037 and AA0038 are mutually exclusive, governed by the same logic: NOT
>>>>&

Re: [M100] REXCPM for Model 200?

[Stephen Adolph]

Well,
Looking at the REXCPM board, it is possible to go from 3 signals on the
jumper to 4.
This would allow for A15 to be brought in, and to identify the special case
where /BANK3 is zero but the address bus is 8000-9FFF.
At first blush I can't think of a good way to solve this other than by
adding a wire.

Which puts the T200 install on the same page as T102, with a single wire
required.


On Wed, May 25, 2022 at 10:16 PM Stephen Adolph 
wrote:

> AH, I see your point.
> I stand corrected, A15 is not on the socket.
> [image: image.png]
>
> So, maybe your suggestion works; is A15 needed at all?
>
> Yes, I think it is needed.
>
> How would you tell the difference between these two addresses, from the
> perspective of REXCPM?
>
>   vs 8000.
> Both have /BANK3 = 0, and /BANK6=1.  And A14 to A0 = 000.
>
>
> Seems like you gotta have an additional signal, A15.  And A15 is NOT on
> the memory card.  That means you would need to jumper in from inside the
> case.
>
>
> Thanks, good discussion. I think I got all excited but I forgot which part
> of the address was multiplexed!!
>
>
>
> On Wed, May 25, 2022 at 10:08 PM Stephen Adolph 
> wrote:
>
>> Couple of comments.
>>
>> Agree with your rule, but REXCPM is even more fancy.
>>
>> It supports 32k bank switching in  to 7FFF and 2 banks of 16k
>> switched at 8000 to BFFF and C000 to .  So REXCPM has to differentiate
>> a bit based on which bank is indicated.
>>
>> All this bank switching to support RAM disk as well as general option rom
>> switching, plus general ram banking.
>>
>> I agree the service manual isnt clear.  But I know from experience that
>> ALE can latch A8 to A15 in T200 and M100 option rom socket.
>>
>> One diagram does make it clear though.  I'll snip and send separately.
>>
>> 8085 in general has a multiplexed address bus.
>>
>>
>>
>> On Wednesday, May 25, 2022, B 9  wrote:
>>
>>> Yes, that helps quite a bit. Thank you.
>>>
>>> One more question: If you are already handling situations 1 & 3 — bank3
>>> is low and bank 6 is high for both, so A15 must be checked — why not reduce
>>> the scenarios to a single rule:
>>>
>>>- If either bank3 or bank6 is low, address is 0 to , rexcpm
>>>responds.
>>>
>>> —b9
>>>
>>> P.S. Where can I read more about the data latched in by ALE? The Tandy
>>> 200 service manual and technical reference make it look like the AD bus is
>>> holding only the lowest 8 bits of the memory address, A7 to A0, so I do not
>>> yet understand how it contains A15.
>>>
>>>
>>> On Wed, May 25, 2022 at 6:10 PM Stephen Adolph 
>>> wrote:
>>>
>>>> when bank3 is low, address  to 7fff, bank6 is high, rexcpm responds.
>>>>
>>>> When bank6 is low, address a000 to , bank3 is high, rexcpm responds
>>>>
>>>> When bank3 is low, address 8000 to 9fff, bank6 is high, rexcpm responds.
>>>>
>>>> All of these scenarios are unique.  Cpm gets 64k when option rom and
>>>> optikn ram 2 are engaged.
>>>>
>>>> Yah?  Hope that helps.
>>>>
>>>> Steve
>>>>
>>>>
>>>>
>>>>
>>>> On Wednesday, May 25, 2022, B 9  wrote:
>>>>
>>>>> I'm a little confused.
>>>>>
>>>>> It sounds like you're selecting on /BANK3 = 0 (option ROM selected)
>>>>> AND  /BANK6 = 0 (expansion RAM selected). But, if I'm reading figure 4-6
>>>>> from the service manual correctly, /BANK3=0 AND /BANK6=0 will always be
>>>>> false because no two banks are ever selected at the same time. Decoders
>>>>> AA0037 and AA0038 are mutually exclusive, governed by the same logic: NOT
>>>>> (A15 AND (A14 OR A13)).
>>>>>
>>>>> That is, it appears that for addresses 8000 to 9FFF, bank 3 is
>>>>> selected: /BANK3=0 and /BANK6=1.
>>>>>
>>>>> Or, am I missing something?
>>>>>
>>>>> —b9
>>>>>
>>>>> On Wed, May 25, 2022 at 5:41 PM Stephen Adolph 
>>>>> wrote:
>>>>>
>>>>>> I've been thinking about it too.
>>>>>>
>>>>>> /BANK6 is perfect for selecting that ram bank for address A000 to
>>>>>> .  No issue.
>>>>>>
>>>>>> I believe that  , when option 

Re: [M100] REXCPM for Model 200?

[Stephen Adolph]

 AH, I see your point.
I stand corrected, A15 is not on the socket.
[image: image.png]

So, maybe your suggestion works; is A15 needed at all?

Yes, I think it is needed.

How would you tell the difference between these two addresses, from the
perspective of REXCPM?

  vs 8000.
Both have /BANK3 = 0, and /BANK6=1.  And A14 to A0 = 000.


Seems like you gotta have an additional signal, A15.  And A15 is NOT on the
memory card.  That means you would need to jumper in from inside the case.


Thanks, good discussion. I think I got all excited but I forgot which part
of the address was multiplexed!!



On Wed, May 25, 2022 at 10:08 PM Stephen Adolph 
wrote:

> Couple of comments.
>
> Agree with your rule, but REXCPM is even more fancy.
>
> It supports 32k bank switching in  to 7FFF and 2 banks of 16k switched
> at 8000 to BFFF and C000 to .  So REXCPM has to differentiate a bit
> based on which bank is indicated.
>
> All this bank switching to support RAM disk as well as general option rom
> switching, plus general ram banking.
>
> I agree the service manual isnt clear.  But I know from experience that
> ALE can latch A8 to A15 in T200 and M100 option rom socket.
>
> One diagram does make it clear though.  I'll snip and send separately.
>
> 8085 in general has a multiplexed address bus.
>
>
>
> On Wednesday, May 25, 2022, B 9  wrote:
>
>> Yes, that helps quite a bit. Thank you.
>>
>> One more question: If you are already handling situations 1 & 3 — bank3
>> is low and bank 6 is high for both, so A15 must be checked — why not reduce
>> the scenarios to a single rule:
>>
>>- If either bank3 or bank6 is low, address is 0 to , rexcpm
>>responds.
>>
>> —b9
>>
>> P.S. Where can I read more about the data latched in by ALE? The Tandy
>> 200 service manual and technical reference make it look like the AD bus is
>> holding only the lowest 8 bits of the memory address, A7 to A0, so I do not
>> yet understand how it contains A15.
>>
>>
>> On Wed, May 25, 2022 at 6:10 PM Stephen Adolph 
>> wrote:
>>
>>> when bank3 is low, address  to 7fff, bank6 is high, rexcpm responds.
>>>
>>> When bank6 is low, address a000 to , bank3 is high, rexcpm responds
>>>
>>> When bank3 is low, address 8000 to 9fff, bank6 is high, rexcpm responds.
>>>
>>> All of these scenarios are unique.  Cpm gets 64k when option rom and
>>> optikn ram 2 are engaged.
>>>
>>> Yah?  Hope that helps.
>>>
>>> Steve
>>>
>>>
>>>
>>>
>>> On Wednesday, May 25, 2022, B 9  wrote:
>>>
>>>> I'm a little confused.
>>>>
>>>> It sounds like you're selecting on /BANK3 = 0 (option ROM selected)
>>>> AND  /BANK6 = 0 (expansion RAM selected). But, if I'm reading figure 4-6
>>>> from the service manual correctly, /BANK3=0 AND /BANK6=0 will always be
>>>> false because no two banks are ever selected at the same time. Decoders
>>>> AA0037 and AA0038 are mutually exclusive, governed by the same logic: NOT
>>>> (A15 AND (A14 OR A13)).
>>>>
>>>> That is, it appears that for addresses 8000 to 9FFF, bank 3 is
>>>> selected: /BANK3=0 and /BANK6=1.
>>>>
>>>> Or, am I missing something?
>>>>
>>>> —b9
>>>>
>>>> On Wed, May 25, 2022 at 5:41 PM Stephen Adolph 
>>>> wrote:
>>>>
>>>>> I've been thinking about it too.
>>>>>
>>>>> /BANK6 is perfect for selecting that ram bank for address A000 to
>>>>> .  No issue.
>>>>>
>>>>> I believe that  , when option rom is selected, it is actually selected
>>>>> for all addresses from  to 9FFF.
>>>>>
>>>>> Now about A15.  It is actually present in the socket because the AD
>>>>> bus is present and ALE is present.
>>>>>
>>>>> So all you need is a register to capture it. A15 is AD7 sampled by ALE.
>>>>>
>>>>> The T200 diagrams dont call the bus AD but it is.
>>>>>
>>>>> So, the T200 ram adapter needs to supply
>>>>> 1. Battery voltage
>>>>> 2. /WR
>>>>> 3. /BANK6  (and or BANK5)
>>>>>
>>>>> Three wires, the same as M100 REXCPM but with different logic
>>>>> implemented in the CPLD.
>>>>>
>>>>> For the record, in M100 and T102 REXCPM disables the internal ram by

Re: [M100] REXCPM for Model 200?

[Stephen Adolph]

Couple of comments.

Agree with your rule, but REXCPM is even more fancy.

It supports 32k bank switching in  to 7FFF and 2 banks of 16k switched
at 8000 to BFFF and C000 to .  So REXCPM has to differentiate a bit
based on which bank is indicated.

All this bank switching to support RAM disk as well as general option rom
switching, plus general ram banking.

I agree the service manual isnt clear.  But I know from experience that ALE
can latch A8 to A15 in T200 and M100 option rom socket.

One diagram does make it clear though.  I'll snip and send separately.

8085 in general has a multiplexed address bus.



On Wednesday, May 25, 2022, B 9  wrote:

> Yes, that helps quite a bit. Thank you.
>
> One more question: If you are already handling situations 1 & 3 — bank3 is
> low and bank 6 is high for both, so A15 must be checked — why not reduce
> the scenarios to a single rule:
>
>- If either bank3 or bank6 is low, address is 0 to , rexcpm
>responds.
>
> —b9
>
> P.S. Where can I read more about the data latched in by ALE? The Tandy 200
> service manual and technical reference make it look like the AD bus is
> holding only the lowest 8 bits of the memory address, A7 to A0, so I do not
> yet understand how it contains A15.
>
>
> On Wed, May 25, 2022 at 6:10 PM Stephen Adolph 
> wrote:
>
>> when bank3 is low, address  to 7fff, bank6 is high, rexcpm responds.
>>
>> When bank6 is low, address a000 to , bank3 is high, rexcpm responds
>>
>> When bank3 is low, address 8000 to 9fff, bank6 is high, rexcpm responds.
>>
>> All of these scenarios are unique.  Cpm gets 64k when option rom and
>> optikn ram 2 are engaged.
>>
>> Yah?  Hope that helps.
>>
>> Steve
>>
>>
>>
>>
>> On Wednesday, May 25, 2022, B 9  wrote:
>>
>>> I'm a little confused.
>>>
>>> It sounds like you're selecting on /BANK3 = 0 (option ROM selected) AND
>>> /BANK6 = 0 (expansion RAM selected). But, if I'm reading figure 4-6 from
>>> the service manual correctly, /BANK3=0 AND /BANK6=0 will always be false
>>> because no two banks are ever selected at the same time. Decoders AA0037
>>> and AA0038 are mutually exclusive, governed by the same logic: NOT (A15 AND
>>> (A14 OR A13)).
>>>
>>> That is, it appears that for addresses 8000 to 9FFF, bank 3 is selected:
>>> /BANK3=0 and /BANK6=1.
>>>
>>> Or, am I missing something?
>>>
>>> —b9
>>>
>>> On Wed, May 25, 2022 at 5:41 PM Stephen Adolph 
>>> wrote:
>>>
>>>> I've been thinking about it too.
>>>>
>>>> /BANK6 is perfect for selecting that ram bank for address A000 to
>>>> .  No issue.
>>>>
>>>> I believe that  , when option rom is selected, it is actually selected
>>>> for all addresses from  to 9FFF.
>>>>
>>>> Now about A15.  It is actually present in the socket because the AD bus
>>>> is present and ALE is present.
>>>>
>>>> So all you need is a register to capture it. A15 is AD7 sampled by ALE.
>>>>
>>>> The T200 diagrams dont call the bus AD but it is.
>>>>
>>>> So, the T200 ram adapter needs to supply
>>>> 1. Battery voltage
>>>> 2. /WR
>>>> 3. /BANK6  (and or BANK5)
>>>>
>>>> Three wires, the same as M100 REXCPM but with different logic
>>>> implemented in the CPLD.
>>>>
>>>> For the record, in M100 and T102 REXCPM disables the internal ram by
>>>> manipulating RAMRST.  This isn't necessary for T200.  The option rams can
>>>> be replaced by REXCPM.  Back driving RAMRST takes only a few mA.
>>>>
>>>> So yeah I think it works.  I am thinking about a few little experiments
>>>> to confirm my suspicions.
>>>>
>>>> Still a lot of firmware and software work to do.  I already laid out
>>>> the adapter. That's easy... ;)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wednesday, May 25, 2022, B 9  wrote:
>>>>
>>>>> If you can get A15 without a blue wire, it does not seem that you
>>>>> would need the new select signal based on /BANK6. Requests for 8000 to 
>>>>> 9FFF
>>>>> appear to already go to Bank 3, so you'd just need to detect addresses in
>>>>> that range in the OPTION ROM. It looks like the service manual schematic
>>>>> for bank select does t

Re: [M100] REXCPM for Model 200?

[B 9]

Yes, that helps quite a bit. Thank you.

One more question: If you are already handling situations 1 & 3 — bank3 is
low and bank 6 is high for both, so A15 must be checked — why not reduce
the scenarios to a single rule:

   - If either bank3 or bank6 is low, address is 0 to , rexcpm responds.

—b9

P.S. Where can I read more about the data latched in by ALE? The Tandy 200
service manual and technical reference make it look like the AD bus is
holding only the lowest 8 bits of the memory address, A7 to A0, so I do not
yet understand how it contains A15.


On Wed, May 25, 2022 at 6:10 PM Stephen Adolph  wrote:

> when bank3 is low, address  to 7fff, bank6 is high, rexcpm responds.
>
> When bank6 is low, address a000 to , bank3 is high, rexcpm responds
>
> When bank3 is low, address 8000 to 9fff, bank6 is high, rexcpm responds.
>
> All of these scenarios are unique.  Cpm gets 64k when option rom and
> optikn ram 2 are engaged.
>
> Yah?  Hope that helps.
>
> Steve
>
>
>
>
> On Wednesday, May 25, 2022, B 9  wrote:
>
>> I'm a little confused.
>>
>> It sounds like you're selecting on /BANK3 = 0 (option ROM selected) AND
>> /BANK6 = 0 (expansion RAM selected). But, if I'm reading figure 4-6 from
>> the service manual correctly, /BANK3=0 AND /BANK6=0 will always be false
>> because no two banks are ever selected at the same time. Decoders AA0037
>> and AA0038 are mutually exclusive, governed by the same logic: NOT (A15 AND
>> (A14 OR A13)).
>>
>> That is, it appears that for addresses 8000 to 9FFF, bank 3 is selected:
>> /BANK3=0 and /BANK6=1.
>>
>> Or, am I missing something?
>>
>> —b9
>>
>> On Wed, May 25, 2022 at 5:41 PM Stephen Adolph 
>> wrote:
>>
>>> I've been thinking about it too.
>>>
>>> /BANK6 is perfect for selecting that ram bank for address A000 to .
>>> No issue.
>>>
>>> I believe that  , when option rom is selected, it is actually selected
>>> for all addresses from  to 9FFF.
>>>
>>> Now about A15.  It is actually present in the socket because the AD bus
>>> is present and ALE is present.
>>>
>>> So all you need is a register to capture it. A15 is AD7 sampled by ALE.
>>>
>>> The T200 diagrams dont call the bus AD but it is.
>>>
>>> So, the T200 ram adapter needs to supply
>>> 1. Battery voltage
>>> 2. /WR
>>> 3. /BANK6  (and or BANK5)
>>>
>>> Three wires, the same as M100 REXCPM but with different logic
>>> implemented in the CPLD.
>>>
>>> For the record, in M100 and T102 REXCPM disables the internal ram by
>>> manipulating RAMRST.  This isn't necessary for T200.  The option rams can
>>> be replaced by REXCPM.  Back driving RAMRST takes only a few mA.
>>>
>>> So yeah I think it works.  I am thinking about a few little experiments
>>> to confirm my suspicions.
>>>
>>> Still a lot of firmware and software work to do.  I already laid out the
>>> adapter. That's easy... ;)
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wednesday, May 25, 2022, B 9  wrote:
>>>
>>>> If you can get A15 without a blue wire, it does not seem that you would
>>>> need the new select signal based on /BANK6. Requests for 8000 to 9FFF
>>>> appear to already go to Bank 3, so you'd just need to detect addresses in
>>>> that range in the OPTION ROM. It looks like the service manual schematic
>>>> for bank select does that using NOT( A15 AND (A14 OR A13) ).
>>>>
>>>> —b9
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, May 16, 2022 at 3:57 PM Stephen Adolph 
>>>> wrote:
>>>>
>>>>> I took a fresh look at the T200 "all ram mode" which would be
>>>>> needed for REXCPM to work (nicely).
>>>>> Summary: it is actually feasible I believe to implement an all RAM
>>>>> mode fairly easily, which would support CP/M nicely.
>>>>>
>>>>> *Issue 1.  The 8k ROM at 8000-9FFF*
>>>>> * as shown on the schematic, the M15 ROM is only enabled when /BANK1
>>>>> is low and A15 is high.
>>>>>(also reference the 8k rom datasheet in the tech reference manual)
>>>>> * also as shown on the schematic, the M13 32k ROM is only enabled when
>>>>> /BANK1 is low and A15 is low.
>>>>>
>>>>> *SO - the 8k range is only active in /BANK

Re: [M100] REXCPM for Model 200?

[Stephen Adolph]

when bank3 is low, address  to 7fff, bank6 is high, rexcpm responds.

When bank6 is low, address a000 to , bank3 is high, rexcpm responds

When bank3 is low, address 8000 to 9fff, bank6 is high, rexcpm responds.

All of these scenarios are unique.  Cpm gets 64k when option rom and optikn
ram 2 are engaged.

Yah?  Hope that helps.

Steve




On Wednesday, May 25, 2022, B 9  wrote:

> I'm a little confused.
>
> It sounds like you're selecting on /BANK3 = 0 (option ROM selected) AND
> /BANK6 = 0 (expansion RAM selected). But, if I'm reading figure 4-6 from
> the service manual correctly, /BANK3=0 AND /BANK6=0 will always be false
> because no two banks are ever selected at the same time. Decoders AA0037
> and AA0038 are mutually exclusive, governed by the same logic: NOT (A15 AND
> (A14 OR A13)).
>
> That is, it appears that for addresses 8000 to 9FFF, bank 3 is selected:
> /BANK3=0 and /BANK6=1.
>
> Or, am I missing something?
>
> —b9
>
> On Wed, May 25, 2022 at 5:41 PM Stephen Adolph 
> wrote:
>
>> I've been thinking about it too.
>>
>> /BANK6 is perfect for selecting that ram bank for address A000 to .
>> No issue.
>>
>> I believe that  , when option rom is selected, it is actually selected
>> for all addresses from  to 9FFF.
>>
>> Now about A15.  It is actually present in the socket because the AD bus
>> is present and ALE is present.
>>
>> So all you need is a register to capture it. A15 is AD7 sampled by ALE.
>>
>> The T200 diagrams dont call the bus AD but it is.
>>
>> So, the T200 ram adapter needs to supply
>> 1. Battery voltage
>> 2. /WR
>> 3. /BANK6  (and or BANK5)
>>
>> Three wires, the same as M100 REXCPM but with different logic implemented
>> in the CPLD.
>>
>> For the record, in M100 and T102 REXCPM disables the internal ram by
>> manipulating RAMRST.  This isn't necessary for T200.  The option rams can
>> be replaced by REXCPM.  Back driving RAMRST takes only a few mA.
>>
>> So yeah I think it works.  I am thinking about a few little experiments
>> to confirm my suspicions.
>>
>> Still a lot of firmware and software work to do.  I already laid out the
>> adapter. That's easy... ;)
>>
>>
>>
>>
>>
>>
>> On Wednesday, May 25, 2022, B 9  wrote:
>>
>>> If you can get A15 without a blue wire, it does not seem that you would
>>> need the new select signal based on /BANK6. Requests for 8000 to 9FFF
>>> appear to already go to Bank 3, so you'd just need to detect addresses in
>>> that range in the OPTION ROM. It looks like the service manual schematic
>>> for bank select does that using NOT( A15 AND (A14 OR A13) ).
>>>
>>> —b9
>>>
>>>
>>>
>>>
>>>
>>> On Mon, May 16, 2022 at 3:57 PM Stephen Adolph 
>>> wrote:
>>>
>>>> I took a fresh look at the T200 "all ram mode" which would be
>>>> needed for REXCPM to work (nicely).
>>>> Summary: it is actually feasible I believe to implement an all RAM mode
>>>> fairly easily, which would support CP/M nicely.
>>>>
>>>> *Issue 1.  The 8k ROM at 8000-9FFF*
>>>> * as shown on the schematic, the M15 ROM is only enabled when /BANK1 is
>>>> low and A15 is high.
>>>>(also reference the 8k rom datasheet in the tech reference manual)
>>>> * also as shown on the schematic, the M13 32k ROM is only enabled when
>>>> /BANK1 is low and A15 is low.
>>>>
>>>> *SO - the 8k range is only active in /BANK1.*
>>>>
>>>> *Issue 2.  Creating an all RAM mode*
>>>> * /BANK3 enables the option ROM socket for -7FFF address range
>>>> * /BANK6 enables the 2nd option RAM socket for A000- address range.
>>>> * a new select signal is needed for when /BANK3 = 0 (option rom
>>>> selected) AND A15=1 (upper addresses) AND  /BANK6=0
>>>> (so when we are using the option ROM, and address is in range
>>>> 8000-9FFF)
>>>>
>>>> * A15 is available in the OPTION ROM socket indirectly; as shown in the
>>>> service manual in Figure 4-3, the AD bus is provided to the option ROM
>>>> socket, as is ALE.  This means that A15 is present on AD7 (D7) on the
>>>> falling edge of ALE.
>>>>
>>>> *SO - by stealing /BANK6 from the 2nd Option RAM socket, REXCPM could
>>>> be programmed to provide an all RAM mode.*
>>>>
>>>> *What's needed to make REX

Re: [M100] REXCPM for Model 200?

[B 9]

I'm a little confused.

It sounds like you're selecting on /BANK3 = 0 (option ROM selected) AND
/BANK6 = 0 (expansion RAM selected). But, if I'm reading figure 4-6 from
the service manual correctly, /BANK3=0 AND /BANK6=0 will always be false
because no two banks are ever selected at the same time. Decoders AA0037
and AA0038 are mutually exclusive, governed by the same logic: NOT (A15 AND
(A14 OR A13)).

That is, it appears that for addresses 8000 to 9FFF, bank 3 is selected:
/BANK3=0 and /BANK6=1.

Or, am I missing something?

—b9

On Wed, May 25, 2022 at 5:41 PM Stephen Adolph  wrote:

> I've been thinking about it too.
>
> /BANK6 is perfect for selecting that ram bank for address A000 to .
> No issue.
>
> I believe that  , when option rom is selected, it is actually selected for
> all addresses from  to 9FFF.
>
> Now about A15.  It is actually present in the socket because the AD bus is
> present and ALE is present.
>
> So all you need is a register to capture it. A15 is AD7 sampled by ALE.
>
> The T200 diagrams dont call the bus AD but it is.
>
> So, the T200 ram adapter needs to supply
> 1. Battery voltage
> 2. /WR
> 3. /BANK6  (and or BANK5)
>
> Three wires, the same as M100 REXCPM but with different logic implemented
> in the CPLD.
>
> For the record, in M100 and T102 REXCPM disables the internal ram by
> manipulating RAMRST.  This isn't necessary for T200.  The option rams can
> be replaced by REXCPM.  Back driving RAMRST takes only a few mA.
>
> So yeah I think it works.  I am thinking about a few little experiments to
> confirm my suspicions.
>
> Still a lot of firmware and software work to do.  I already laid out the
> adapter. That's easy... ;)
>
>
>
>
>
>
> On Wednesday, May 25, 2022, B 9  wrote:
>
>> If you can get A15 without a blue wire, it does not seem that you would
>> need the new select signal based on /BANK6. Requests for 8000 to 9FFF
>> appear to already go to Bank 3, so you'd just need to detect addresses in
>> that range in the OPTION ROM. It looks like the service manual schematic
>> for bank select does that using NOT( A15 AND (A14 OR A13) ).
>>
>> —b9
>>
>>
>>
>>
>>
>> On Mon, May 16, 2022 at 3:57 PM Stephen Adolph 
>> wrote:
>>
>>> I took a fresh look at the T200 "all ram mode" which would be needed for
>>> REXCPM to work (nicely).
>>> Summary: it is actually feasible I believe to implement an all RAM mode
>>> fairly easily, which would support CP/M nicely.
>>>
>>> *Issue 1.  The 8k ROM at 8000-9FFF*
>>> * as shown on the schematic, the M15 ROM is only enabled when /BANK1 is
>>> low and A15 is high.
>>>(also reference the 8k rom datasheet in the tech reference manual)
>>> * also as shown on the schematic, the M13 32k ROM is only enabled when
>>> /BANK1 is low and A15 is low.
>>>
>>> *SO - the 8k range is only active in /BANK1.*
>>>
>>> *Issue 2.  Creating an all RAM mode*
>>> * /BANK3 enables the option ROM socket for -7FFF address range
>>> * /BANK6 enables the 2nd option RAM socket for A000- address range.
>>> * a new select signal is needed for when /BANK3 = 0 (option rom
>>> selected) AND A15=1 (upper addresses) AND  /BANK6=0
>>> (so when we are using the option ROM, and address is in range
>>> 8000-9FFF)
>>>
>>> * A15 is available in the OPTION ROM socket indirectly; as shown in the
>>> service manual in Figure 4-3, the AD bus is provided to the option ROM
>>> socket, as is ALE.  This means that A15 is present on AD7 (D7) on the
>>> falling edge of ALE.
>>>
>>> *SO - by stealing /BANK6 from the 2nd Option RAM socket, REXCPM could be
>>> programmed to provide an all RAM mode.*
>>>
>>> *What's needed to make REXCPM support T200*
>>>
>>>1. A modified REXCPM that is able to deduce when to enable RAM in
>>>the 8000-9FFF range.
>>>2. an Adapter Board sitting in Option RAM #2, which sends 3 signals
>>>to REXCPM  (1)  Battery voltage  (2) /RD signal and (3) /BANK6 signal.
>>>3. an updated RXCMGR application
>>>4. an updated "T200 CP/M"  IE the M100 CP/M modified to use the T200
>>>environment.
>>>5. updated CP/M uilities
>>>6. (VirtualT updated to support REXCPM for T200...)
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sun, May 15, 2022 at 5:35 PM Stephen Adolph 
>>> wrote:
>>>
>>>> There would have to be a convenien

Re: [M100] REXCPM for Model 200?

[Stephen Adolph]

I've been thinking about it too.

/BANK6 is perfect for selecting that ram bank for address A000 to .  No
issue.

I believe that  , when option rom is selected, it is actually selected for
all addresses from  to 9FFF.

Now about A15.  It is actually present in the socket because the AD bus is
present and ALE is present.

So all you need is a register to capture it. A15 is AD7 sampled by ALE.

The T200 diagrams dont call the bus AD but it is.

So, the T200 ram adapter needs to supply
1. Battery voltage
2. /WR
3. /BANK6  (and or BANK5)

Three wires, the same as M100 REXCPM but with different logic implemented
in the CPLD.

For the record, in M100 and T102 REXCPM disables the internal ram by
manipulating RAMRST.  This isn't necessary for T200.  The option rams can
be replaced by REXCPM.  Back driving RAMRST takes only a few mA.

So yeah I think it works.  I am thinking about a few little experiments to
confirm my suspicions.

Still a lot of firmware and software work to do.  I already laid out the
adapter. That's easy... ;)






On Wednesday, May 25, 2022, B 9  wrote:

> If you can get A15 without a blue wire, it does not seem that you would
> need the new select signal based on /BANK6. Requests for 8000 to 9FFF
> appear to already go to Bank 3, so you'd just need to detect addresses in
> that range in the OPTION ROM. It looks like the service manual schematic
> for bank select does that using NOT( A15 AND (A14 OR A13) ).
>
> —b9
>
>
>
>
>
> On Mon, May 16, 2022 at 3:57 PM Stephen Adolph 
> wrote:
>
>> I took a fresh look at the T200 "all ram mode" which would be needed for
>> REXCPM to work (nicely).
>> Summary: it is actually feasible I believe to implement an all RAM mode
>> fairly easily, which would support CP/M nicely.
>>
>> *Issue 1.  The 8k ROM at 8000-9FFF*
>> * as shown on the schematic, the M15 ROM is only enabled when /BANK1 is
>> low and A15 is high.
>>(also reference the 8k rom datasheet in the tech reference manual)
>> * also as shown on the schematic, the M13 32k ROM is only enabled when
>> /BANK1 is low and A15 is low.
>>
>> *SO - the 8k range is only active in /BANK1.*
>>
>> *Issue 2.  Creating an all RAM mode*
>> * /BANK3 enables the option ROM socket for -7FFF address range
>> * /BANK6 enables the 2nd option RAM socket for A000- address range.
>> * a new select signal is needed for when /BANK3 = 0 (option rom selected)
>> AND A15=1 (upper addresses) AND  /BANK6=0
>> (so when we are using the option ROM, and address is in range
>> 8000-9FFF)
>>
>> * A15 is available in the OPTION ROM socket indirectly; as shown in the
>> service manual in Figure 4-3, the AD bus is provided to the option ROM
>> socket, as is ALE.  This means that A15 is present on AD7 (D7) on the
>> falling edge of ALE.
>>
>> *SO - by stealing /BANK6 from the 2nd Option RAM socket, REXCPM could be
>> programmed to provide an all RAM mode.*
>>
>> *What's needed to make REXCPM support T200*
>>
>>1. A modified REXCPM that is able to deduce when to enable RAM in the
>>8000-9FFF range.
>>2. an Adapter Board sitting in Option RAM #2, which sends 3 signals
>>to REXCPM  (1)  Battery voltage  (2) /RD signal and (3) /BANK6 signal.
>>3. an updated RXCMGR application
>>4. an updated "T200 CP/M"  IE the M100 CP/M modified to use the T200
>>environment.
>>5. updated CP/M uilities
>>6. (VirtualT updated to support REXCPM for T200...)
>>
>>
>>
>>
>>
>>
>> On Sun, May 15, 2022 at 5:35 PM Stephen Adolph 
>> wrote:
>>
>>> There would have to be a convenient plug and play ideally way to decode
>>> that.
>>> From what is present in the ram module compartment, I dont see a good
>>> solution.
>>> I'll take another look.
>>>
>>> On Sunday, May 15, 2022, B 9  wrote:
>>>
>>>> I, too, would love to see RexCPM for the Tandy 200.
>>>>
>>>> I apologize for my ignorance, but why is there a hole? For ROM? Would
>>>> it be possible to bank out 8000 to 9FFF and replace it with RAM when
>>>> running CPM?
>>>>
>>>> —B9
>>>>
>>>>
>>>> On Sun, May 15, 2022 at 9:44 AM Stephen Adolph 
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> At this time, no.   It would require some changes due to the unique
>>>>> memory map in the T200 relative to the M100.
>>>>>
>>>>> I think the biggest issue is that an all ram mode is not clearly
>>>>> possible.  There would be a hole fro. 8000 to 9FFF.   That's not great for
>>>>> CPM.
>>>>>
>>>>> Steve
>>>>>
>>>>> On Saturday, May 14, 2022, Hiraghm  wrote:
>>>>>
>>>>>> Is there an equivalent to the Model 100 REXCPM rom for the Model 200?
>>>>>>
>>>>>>
>>>>>>

Re: [M100] REXCPM for Model 200?

[B 9]

If you can get A15 without a blue wire, it does not seem that you would
need the new select signal based on /BANK6. Requests for 8000 to 9FFF
appear to already go to Bank 3, so you'd just need to detect addresses in
that range in the OPTION ROM. It looks like the service manual schematic
for bank select does that using NOT( A15 AND (A14 OR A13) ).

—b9





On Mon, May 16, 2022 at 3:57 PM Stephen Adolph  wrote:

> I took a fresh look at the T200 "all ram mode" which would be needed for
> REXCPM to work (nicely).
> Summary: it is actually feasible I believe to implement an all RAM mode
> fairly easily, which would support CP/M nicely.
>
> *Issue 1.  The 8k ROM at 8000-9FFF*
> * as shown on the schematic, the M15 ROM is only enabled when /BANK1 is
> low and A15 is high.
>(also reference the 8k rom datasheet in the tech reference manual)
> * also as shown on the schematic, the M13 32k ROM is only enabled when
> /BANK1 is low and A15 is low.
>
> *SO - the 8k range is only active in /BANK1.*
>
> *Issue 2.  Creating an all RAM mode*
> * /BANK3 enables the option ROM socket for -7FFF address range
> * /BANK6 enables the 2nd option RAM socket for A000- address range.
> * a new select signal is needed for when /BANK3 = 0 (option rom selected)
> AND A15=1 (upper addresses) AND  /BANK6=0
> (so when we are using the option ROM, and address is in range
> 8000-9FFF)
>
> * A15 is available in the OPTION ROM socket indirectly; as shown in the
> service manual in Figure 4-3, the AD bus is provided to the option ROM
> socket, as is ALE.  This means that A15 is present on AD7 (D7) on the
> falling edge of ALE.
>
> *SO - by stealing /BANK6 from the 2nd Option RAM socket, REXCPM could be
> programmed to provide an all RAM mode.*
>
> *What's needed to make REXCPM support T200*
>
>1. A modified REXCPM that is able to deduce when to enable RAM in the
>8000-9FFF range.
>2. an Adapter Board sitting in Option RAM #2, which sends 3 signals to
>REXCPM  (1)  Battery voltage  (2) /RD signal and (3) /BANK6 signal.
>3. an updated RXCMGR application
>4. an updated "T200 CP/M"  IE the M100 CP/M modified to use the T200
>environment.
>5. updated CP/M uilities
>6. (VirtualT updated to support REXCPM for T200...)
>
>
>
>
>
>
> On Sun, May 15, 2022 at 5:35 PM Stephen Adolph 
> wrote:
>
>> There would have to be a convenient plug and play ideally way to decode
>> that.
>> From what is present in the ram module compartment, I dont see a good
>> solution.
>> I'll take another look.
>>
>> On Sunday, May 15, 2022, B 9  wrote:
>>
>>> I, too, would love to see RexCPM for the Tandy 200.
>>>
>>> I apologize for my ignorance, but why is there a hole? For ROM? Would it
>>> be possible to bank out 8000 to 9FFF and replace it with RAM when running
>>> CPM?
>>>
>>> —B9
>>>
>>>
>>> On Sun, May 15, 2022 at 9:44 AM Stephen Adolph 
>>> wrote:
>>>
 Hi

 At this time, no.   It would require some changes due to the unique
 memory map in the T200 relative to the M100.

 I think the biggest issue is that an all ram mode is not clearly
 possible.  There would be a hole fro. 8000 to 9FFF.   That's not great for
 CPM.

 Steve

 On Saturday, May 14, 2022, Hiraghm  wrote:

> Is there an equivalent to the Model 100 REXCPM rom for the Model 200?
>
>
>

Re: [M100] REXCPM for Model 200?

[B 9]

(Sorry for the random seeming reply. I had thought I had sent that earlier.)

On Wed, May 25, 2022 at 4:49 PM B 9  wrote:

> Let me see if I understand correctly. The main problem is that CPM
> requires the entire 64K of address space to be RAM. For the Model 100,
> REXCPM somehow is able to replace both the builtin ROM (0-7FFF) and RAM
> (8000-) with its own System RAM. That method will not work for the
> Model 200 in which the ROM goes from 0 to 9FFF and the RAM is in three
> banks at A000-.
>
> I tried to look up how REXCPM is able to switch out the ROM and RAM to see
> if I could find an analogous solution for the Model 200, but unfortunately
> REXCPM's Technical Information simply says, "Work in progress!!!"
> .
> I'm guessing that REXCPM is able to replace the lower 32KB on a Model 100
> simply by virtue of being an "OPTION ROM". I have no idea how it replaces
> the RAM.
>
> Despite the Model 200 BASIC ROM now going to 40KB, the service manual
> states that OPTION ROMs are limited to 32KB. I see that only fifteen
> address lines (32KB) go to the socket. But is that insurmountable? The
> diagram for the Bank Selection Circuit (SLA5080F0U) appears to select the
> ROM for addresses up to 9FFF, regardless of whether the ROM is bank 1
> (BASIC) or bank 3 (OPTION ROM). So, any OPTION ROM would already be filling
> in that hole from 8000 to 9, but with the data from 0 to 1FFF since it
> is missing *A₁₅*, the high bit of the address. Right?
>
> Correct me if I'm wrong — and I probably am — but theoretically couldn't
> one create an option ROM chip that has an extra input pin for *A₁₅* and
> have it work  to replace all 40KB of ROM with RAM? I'm imagining a blue
> wire for *A₁₅* connecting to, perhaps, pin 27 on chip M13, the
> supplemental 8KB of BASIC ROM.
>
> —B9
>
> On Sun, May 15, 2022 at 2:35 PM Stephen Adolph 
> wrote:
>
>> There would have to be a convenient plug and play ideally way to decode
>> that.
>> From what is present in the ram module compartment, I dont see a good
>> solution.
>> I'll take another look.
>>
>> On Sunday, May 15, 2022, B 9  wrote:
>>
>>> I, too, would love to see RexCPM for the Tandy 200.
>>>
>>> I apologize for my ignorance, but why is there a hole? For ROM? Would it
>>> be possible to bank out 8000 to 9FFF and replace it with RAM when running
>>> CPM?
>>>
>>> —B9
>>>
>>>
>>> On Sun, May 15, 2022 at 9:44 AM Stephen Adolph 
>>> wrote:
>>>
 Hi

 At this time, no.   It would require some changes due to the unique
 memory map in the T200 relative to the M100.

 I think the biggest issue is that an all ram mode is not clearly
 possible.  There would be a hole fro. 8000 to 9FFF.   That's not great for
 CPM.

 Steve

 On Saturday, May 14, 2022, Hiraghm  wrote:

> Is there an equivalent to the Model 100 REXCPM rom for the Model 200?
>
>
>

Re: [M100] REXCPM for Model 200?

[B 9]

Let me see if I understand correctly. The main problem is that CPM requires
the entire 64K of address space to be RAM. For the Model 100, REXCPM
somehow is able to replace both the builtin ROM (0-7FFF) and RAM
(8000-) with its own System RAM. That method will not work for the
Model 200 in which the ROM goes from 0 to 9FFF and the RAM is in three
banks at A000-.

I tried to look up how REXCPM is able to switch out the ROM and RAM to see
if I could find an analogous solution for the Model 200, but unfortunately
REXCPM's Technical Information simply says, "Work in progress!!!"
.
I'm guessing that REXCPM is able to replace the lower 32KB on a Model 100
simply by virtue of being an "OPTION ROM". I have no idea how it replaces
the RAM.

Despite the Model 200 BASIC ROM now going to 40KB, the service manual
states that OPTION ROMs are limited to 32KB. I see that only fifteen
address lines (32KB) go to the socket. But is that insurmountable? The
diagram for the Bank Selection Circuit (SLA5080F0U) appears to select the
ROM for addresses up to 9FFF, regardless of whether the ROM is bank 1
(BASIC) or bank 3 (OPTION ROM). So, any OPTION ROM would already be filling
in that hole from 8000 to 9, but with the data from 0 to 1FFF since it
is missing *A₁₅*, the high bit of the address. Right?

Correct me if I'm wrong — and I probably am — but theoretically couldn't
one create an option ROM chip that has an extra input pin for *A₁₅* and
have it work  to replace all 40KB of ROM with RAM? I'm imagining a blue
wire for *A₁₅* connecting to, perhaps, pin 27 on chip M13, the supplemental
8KB of BASIC ROM.

—B9

On Sun, May 15, 2022 at 2:35 PM Stephen Adolph  wrote:

> There would have to be a convenient plug and play ideally way to decode
> that.
> From what is present in the ram module compartment, I dont see a good
> solution.
> I'll take another look.
>
> On Sunday, May 15, 2022, B 9  wrote:
>
>> I, too, would love to see RexCPM for the Tandy 200.
>>
>> I apologize for my ignorance, but why is there a hole? For ROM? Would it
>> be possible to bank out 8000 to 9FFF and replace it with RAM when running
>> CPM?
>>
>> —B9
>>
>>
>> On Sun, May 15, 2022 at 9:44 AM Stephen Adolph 
>> wrote:
>>
>>> Hi
>>>
>>> At this time, no.   It would require some changes due to the unique
>>> memory map in the T200 relative to the M100.
>>>
>>> I think the biggest issue is that an all ram mode is not clearly
>>> possible.  There would be a hole fro. 8000 to 9FFF.   That's not great for
>>> CPM.
>>>
>>> Steve
>>>
>>> On Saturday, May 14, 2022, Hiraghm  wrote:
>>>
 Is there an equivalent to the Model 100 REXCPM rom for the Model 200?

Re: [M100] REXCPM for Model 200?

[Ken Pettit]

Hey Steve,

This makes sense!  Let me know if you plan to proceed and need help with 
number 6 below.  :)


Ken

On 5/16/22 3:57 PM, Stephen Adolph wrote:
I took a fresh look at the T200 "all ram mode" which would be 
needed for REXCPM to work (nicely).
Summary: it is actually feasible I believe to implement an all RAM 
mode fairly easily, which would support CP/M nicely.


*Issue 1.  The 8k ROM at 8000-9FFF*
* as shown on the schematic, the M15 ROM is only enabled when /BANK1 
is low and A15 is high.

   (also reference the 8k rom datasheet in the tech reference manual)
* also as shown on the schematic, the M13 32k ROM is only enabled when 
/BANK1 is low and A15 is low.


*SO - the 8k range is only active in /BANK1.*

*Issue 2.  Creating an all RAM mode*
* /BANK3 enables the option ROM socket for -7FFF address range
* /BANK6 enables the 2nd option RAM socket for A000- address range.
* a new select signal is needed for when /BANK3 = 0 (option rom 
selected) AND A15=1 (upper addresses) AND /BANK6=0
(so when we are using the option ROM, and address is in range 
8000-9FFF)


* A15 is available in the OPTION ROM socket indirectly; as shown in 
the service manual in Figure 4-3, the AD bus is provided to the option 
ROM socket, as is ALE.  This means that A15 is present on AD7 (D7) on 
the falling edge of ALE.


*SO - by stealing /BANK6 from the 2nd Option RAM socket, REXCPM could 
be programmed to provide an all RAM mode.*

*
*
*What's needed to make REXCPM support T200*

 1. A modified REXCPM that is able to deduce when to enable RAM in the
8000-9FFF range.
 2. an Adapter Board sitting in Option RAM #2, which sends 3 signals
to REXCPM  (1)  Battery voltage  (2) /RD signal and (3) /BANK6 signal.
 3. an updated RXCMGR application
 4. an updated "T200 CP/M"  IE the M100 CP/M modified to use the T200
environment.
 5. updated CP/M uilities
 6. (VirtualT updated to support REXCPM for T200...)




*
*

On Sun, May 15, 2022 at 5:35 PM Stephen Adolph > wrote:


There would have to be a convenient plug and play ideally way to
decode that.
From what is present in the ram module compartment, I dont see a
good solution.
I'll take another look.

On Sunday, May 15, 2022, B 9 mailto:hacke...@gmail.com>> wrote:

I, too, would love to see RexCPM for the Tandy 200.

I apologize for my ignorance, but why is there a hole? For
ROM? Would it be possible to bank out 8000 to 9FFF and replace
it with RAM when running CPM?

—B9


On Sun, May 15, 2022 at 9:44 AM Stephen Adolph
mailto:twospru...@gmail.com>> wrote:

Hi

At this time, no.   It would require some changes due to
the unique memory map in the T200 relative to the M100.

I think the biggest issue is that an all ram mode is not
clearly possible.  There would be a hole fro. 8000 to
9FFF.   That's not great for CPM.

Steve

On Saturday, May 14, 2022, Hiraghm mailto:hira...@hotmail.com>> wrote:

Is there an equivalent to the Model 100 REXCPM rom for
the Model 200?

Re: [M100] REXCPM for Model 200?

[Stephen Adolph]

I took a fresh look at the T200 "all ram mode" which would be needed for
REXCPM to work (nicely).
Summary: it is actually feasible I believe to implement an all RAM mode
fairly easily, which would support CP/M nicely.

*Issue 1.  The 8k ROM at 8000-9FFF*
* as shown on the schematic, the M15 ROM is only enabled when /BANK1 is low
and A15 is high.
   (also reference the 8k rom datasheet in the tech reference manual)
* also as shown on the schematic, the M13 32k ROM is only enabled when
/BANK1 is low and A15 is low.

*SO - the 8k range is only active in /BANK1.*

*Issue 2.  Creating an all RAM mode*
* /BANK3 enables the option ROM socket for -7FFF address range
* /BANK6 enables the 2nd option RAM socket for A000- address range.
* a new select signal is needed for when /BANK3 = 0 (option rom selected)
AND A15=1 (upper addresses) AND  /BANK6=0
(so when we are using the option ROM, and address is in range 8000-9FFF)

* A15 is available in the OPTION ROM socket indirectly; as shown in the
service manual in Figure 4-3, the AD bus is provided to the option ROM
socket, as is ALE.  This means that A15 is present on AD7 (D7) on the
falling edge of ALE.

*SO - by stealing /BANK6 from the 2nd Option RAM socket, REXCPM could be
programmed to provide an all RAM mode.*

*What's needed to make REXCPM support T200*

   1. A modified REXCPM that is able to deduce when to enable RAM in the
   8000-9FFF range.
   2. an Adapter Board sitting in Option RAM #2, which sends 3 signals to
   REXCPM  (1)  Battery voltage  (2) /RD signal and (3) /BANK6 signal.
   3. an updated RXCMGR application
   4. an updated "T200 CP/M"  IE the M100 CP/M modified to use the T200
   environment.
   5. updated CP/M uilities
   6. (VirtualT updated to support REXCPM for T200...)






On Sun, May 15, 2022 at 5:35 PM Stephen Adolph  wrote:

> There would have to be a convenient plug and play ideally way to decode
> that.
> From what is present in the ram module compartment, I dont see a good
> solution.
> I'll take another look.
>
> On Sunday, May 15, 2022, B 9  wrote:
>
>> I, too, would love to see RexCPM for the Tandy 200.
>>
>> I apologize for my ignorance, but why is there a hole? For ROM? Would it
>> be possible to bank out 8000 to 9FFF and replace it with RAM when running
>> CPM?
>>
>> —B9
>>
>>
>> On Sun, May 15, 2022 at 9:44 AM Stephen Adolph 
>> wrote:
>>
>>> Hi
>>>
>>> At this time, no.   It would require some changes due to the unique
>>> memory map in the T200 relative to the M100.
>>>
>>> I think the biggest issue is that an all ram mode is not clearly
>>> possible.  There would be a hole fro. 8000 to 9FFF.   That's not great for
>>> CPM.
>>>
>>> Steve
>>>
>>> On Saturday, May 14, 2022, Hiraghm  wrote:
>>>
 Is there an equivalent to the Model 100 REXCPM rom for the Model 200?

[M100] REXCPM for Model 200?

[Stephen Adolph]

There would have to be a convenient plug and play ideally way to decode
that.
>From what is present in the ram module compartment, I dont see a good
solution.
I'll take another look.

On Sunday, May 15, 2022, B 9  wrote:

> I, too, would love to see RexCPM for the Tandy 200.
>
> I apologize for my ignorance, but why is there a hole? For ROM? Would it
> be possible to bank out 8000 to 9FFF and replace it with RAM when running
> CPM?
>
> —B9
>
>
> On Sun, May 15, 2022 at 9:44 AM Stephen Adolph 
> wrote:
>
>> Hi
>>
>> At this time, no.   It would require some changes due to the unique
>> memory map in the T200 relative to the M100.
>>
>> I think the biggest issue is that an all ram mode is not clearly
>> possible.  There would be a hole fro. 8000 to 9FFF.   That's not great for
>> CPM.
>>
>> Steve
>>
>> On Saturday, May 14, 2022, Hiraghm  wrote:
>>
>>> Is there an equivalent to the Model 100 REXCPM rom for the Model 200?
>>>
>>>
>>>

Re: [M100] REXCPM for Model 200?

[B 9]

I, too, would love to see RexCPM for the Tandy 200.

I apologize for my ignorance, but why is there a hole? For ROM? Would it be
possible to bank out 8000 to 9FFF and replace it with RAM when running CPM?

—B9


On Sun, May 15, 2022 at 9:44 AM Stephen Adolph  wrote:

> Hi
>
> At this time, no.   It would require some changes due to the unique memory
> map in the T200 relative to the M100.
>
> I think the biggest issue is that an all ram mode is not clearly
> possible.  There would be a hole fro. 8000 to 9FFF.   That's not great for
> CPM.
>
> Steve
>
> On Saturday, May 14, 2022, Hiraghm  wrote:
>
>> Is there an equivalent to the Model 100 REXCPM rom for the Model 200?
>>
>>
>>

Re: [M100] REXCPM for Model 200?

[Stephen Adolph]

Hi

At this time, no.   It would require some changes due to the unique memory
map in the T200 relative to the M100.

I think the biggest issue is that an all ram mode is not clearly possible.
There would be a hole fro. 8000 to 9FFF.   That's not great for CPM.

Steve

On Saturday, May 14, 2022, Hiraghm  wrote:

> Is there an equivalent to the Model 100 REXCPM rom for the Model 200?
>
>
>

[M100] REXCPM for Model 200?

[Hiraghm]

Is there an equivalent to the Model 100 REXCPM rom for the Model 200?

Re: [M100] REXCPM 2M vs 4M

[Jim Anderson]

> -Original Message-
> Correct Jim, it hasn't been fixed yet. After Easter I can get back to
> it.

That'll be awesome, thanks for the update!  For now, it's incentive to keep my 
CP/M file count from bloating out of control :)







jim

Re: [M100] REXCPM 2M vs 4M

[Philip Avery]

Correct Jim, it hasn't been fixed yet. After Easter I can get back to it.

Philip

On 26/02/2021 11:56 am, Jim Anderson wrote:

-Original Message-
For the record, I did end up successfully upgrading a 2M REXCPM to 4M
using the RMLV3216AGSA linked below.

This reminds me... did I miss an announcement, or is the release of a CP/M 
image for the 4MB REX with increased directory entries still pending?  The 
current image linked on http://bitchin100.com/wiki/index.php?title=M100_CP/M is 
CPM410.BK which is the same filename as I have, so unless it's posted somewhere 
else I guess it hasn't been fixed yet.







 jim

Re: [M100] REXCPM 2M vs 4M

[Jim Anderson]

> -Original Message-
> For the record, I did end up successfully upgrading a 2M REXCPM to 4M
> using the RMLV3216AGSA linked below.

This reminds me... did I miss an announcement, or is the release of a CP/M 
image for the 4MB REX with increased directory entries still pending?  The 
current image linked on http://bitchin100.com/wiki/index.php?title=M100_CP/M is 
CPM410.BK which is the same filename as I have, so unless it's posted somewhere 
else I guess it hasn't been fixed yet.







jim

Re: [M100] REXCPM 2M vs 4M

[Brian K. White]

For the record, I did end up successfully upgrading a 2M REXCPM to 4M 
using the RMLV3216AGSA linked below.


The only special note other than "how to desoldering alloy" and "how to 
drag solder" was that the epoxy holding the copper on the pcb is weak. 
Be exceedingly gentle wicking up the desoldering alloy, don't scrub, and 
even with gentle wiping, only move in the same direction as the the 
pads, don't wipe them sideways. Blot-lift-move-blot instead. One of the 
teeny pads for the sram shifted sideways on me even though I was being 
careful. I was able to nudge it back into place eever so carefully 
without breaking the trace and solder the new chip.


Other than that it was straightforward. The pin-1 corner is marked on 
the silkscreen, and there was nothing special to do, just solder the 
chip and load the same firmware, only using the 4M cpm file.


Thus do I publicly waive any hint of warranty on my rexcpm. ;)

Also the dlplus bootstrap option can be used for rxctst.DO too.
dl -b./rxctst.DO    and   RUN "COM:98N1EN"   and it runs all the tests 
on the rexcpm.


--
bkw


On 6/29/20 9:29 PM, Brian K. White wrote:


$56 for a single
https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/CY62177EV30LL-55ZXI/428-3278-ND/2188331 



This looks compatible for $26 for a single
https://www.digikey.com/product-detail/en/renesas-electronics-america/RMLV3216AGSA-5S2-AA0/RMLV3216AGSA-5S2-AA0-ND/9650085 



$32 at Mouser
https://www.mouser.com/Semiconductors/Memory-ICs/SRAM/_/N-4bzpt?P=1z0w8ge

It even seems to have a lower standby current. The Cypress data sheet 
says 3uA and the Renesas says 0.6uA


If I buy one of these myself and solder it, will that be enough other 
than re-programming?


$26 is a lot, and I wouldn't expect you to buy 100 of them for $2400 
but, if I want it, and assuming a perfect solder job, is there 
anything else besides a reflash required to make it work?


Obviously, it's a given that all concept of warranty and liability 
goes out the window instantly.







--
bkw

[M100] REXCPM and NADSBox

[Chris Fezzler]

 First impression after installation.  A dream come true!
Oh, I found the recommended CPM apps (So listserv manager, feel free to reject 
my last post.)
Any favorite CPM apps for Model 100 from members?  

[M100] REXCPM

[Chris Fezzler]

So any recommendations for CPM software to run on REXCPM?
WordStar, VisCalc, other?  
What to try and where to get?

Re: [M100] REXCPM Upgrade to version 2 available

[Stephen Adolph]

early reports of trouble; i must have missed something.
I'll take it down until I have found the problem...

On Fri, Jan 15, 2021 at 6:03 PM Stephen Adolph  wrote:

> The next version of REXCPM is now available for download.
>
> http://bitchin100.com/wiki/index.php?title=REXCPM#Software
>
> Version 2 provides the integrated VT100 driver, and adds in the CNTL-A
> quickmenu shortcut to start RXCMGR.
>
> I have run through the upgrade process on my machines, from Version 1
> build 43 to Version 2 build 10.  Worked for me, and worked in VirtualT.
>
> Please read the instructions carefully, and download the software and
> utilities bundle.
> Delete your old utilities and use the new ones.
> To do a fresh install (as in you have never installed it before) then use
> RXCINI.DO.
> To UPGRADE an existing V1 install, please use RXCUPG.DO.
>
> Let me know if there any problems, and of course bug reports are valuable.
>
> Also, I have updated the BCR hack page with information on how to apply
> the hack to T102.
>
> http://bitchin100.com/wiki/index.php?title=BCR_TTL_SERIAL_HACK#T102
>
> thanks
> Steve
>
>
>

Re: [M100] REXCPM Upgrade to version 2 available

[Stephen Adolph]

Sorry Jim.  Ok I guess something is broken that I didnt see.

I will investigate.

Fyi I attempted the directory structure with rex# so that the same sort
routines would be used!


On Saturday, January 16, 2021, Jim Anderson  wrote:

> I tried upgrading to this new release (using RXCUPG), and encountered
> issues when restoring a RAM image back from backup.  The same thing happens
> sometimes when switching from one RAM image to another, but every time when
> restoring from an image (either through Ctrl-R or through RXCMGR).  The
> progress bar indicates data is being copied to RAM, but then the M100 locks
> up, sometimes showing a screen like the photo below, and sometimes just a
> frozen screen.  Sometimes Reset or a power-cycle will recover the machine,
> sometimes it needs a cold reset.
>
>
>
> I also tried using RXCINI (the new one from REXCPMV2_b11.ZIP) to create a
> new directory and load REX from scratch, and the same issue is present.  In
> addition, there are more strange behaviours – when starting from an empty
> directory I can create a new RAM backup, but if I try to create another RAM
> backup or switch to a RAM image I’ve loaded back from TPDD, RXCMGR just
> creates a new RAM image with the same name as the current one.  If I try to
> delete the non-active image I get a message which I thought I had committed
> firmly to memory (sorry) – it said something about ‘error: flash not
> available’ or not ready or something to that effect.
>
>
>
> On the upside, my RAM image was actually being sorted correctly by date
> and time.  :)  I’ve restored my backup and running v1 build 43 again as it
> was essentially unusable the way things were.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> jim
>
>
>
> *From:* M100 [mailto:m100-boun...@lists.bitchin100.com] *On Behalf Of *Stephen
> Adolph
> *Sent:* Friday, January 15, 2021 17:02
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] REXCPM Upgrade to version 2 available
>
>
>
> *CAUTION External Sender:* Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
>
>
>
> I found a minor issue just now;
>
> When switching from M100 to CP/M, it is possible that the M100 leaves the
> SCREEN in the scroll lock state.
>
>
>
> Here is a simple basic program that de-scroll locks the screen and starts
> CPM.
>
> It assumes RXCMGR is installed.
>
>
>
>
>
> CPM.BA
> <https://can01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcpm.ba%2F&data=04%7C01%7CJim.Anderson%40kpu.ca%7C454b6c9b74484a9b1c2b08d8b9ba59ed%7C66b9f62d3042495eaab6db86f21500c0%7C0%7C0%7C637463557310257626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FtLiLbYFv3AjUJDdt8vby6QAyqaAXGZxO%2FBmX%2FvrN1w%3D&reserved=0>
>
>
>
> 10 screen0:cls:print"Enabling scroll..."
>
> 20 screen2:printchr$(27);"W";
>
> 30 screen0:print"starting CP/M."
>
> 40 call32804,3
>
>
>
>
>
> it is  a work around until i drop a new load with a fix.
>
> cheers
>
> Steve
>
>
>
>
>
>
>
> On Fri, Jan 15, 2021 at 6:03 PM Stephen Adolph 
> wrote:
>
> The next version of REXCPM is now available for download.
>
>
>
> http://bitchin100.com/wiki/index.php?title=REXCPM#Software
> <https://can01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbitchin100.com%2Fwiki%2Findex.php%3Ftitle%3DREXCPM%23Software&data=04%7C01%7CJim.Anderson%40kpu.ca%7C454b6c9b74484a9b1c2b08d8b9ba59ed%7C66b9f62d3042495eaab6db86f21500c0%7C0%7C0%7C637463557310257626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yw7hTp1TeBzj2JUE4Zuu7zAQlFITBc0Px1vgRLMd6ec%3D&reserved=0>
>
>
>
> Version 2 provides the integrated VT100 driver, and adds in the CNTL-A
> quickmenu shortcut to start RXCMGR.
>
>
>
> I have run through the upgrade process on my machines, from Version 1
> build 43 to Version 2 build 10.  Worked for me, and worked in VirtualT.
>
>
>
> Please read the instructions carefully, and download the software and
> utilities bundle.
>
> Delete your old utilities and use the new ones.
>
> To do a fresh install (as in you have never installed it before) then use
> RXCINI.DO.
>
> To UPGRADE an existing V1 install, please use RXCUPG.DO.
>
>
>
> Let me know if there any problems, and of course bug reports are valuable.
>
>
>
> Also, I have updated the BCR hack page with information on how to apply
> the hack to T102.
>
>
>
> http://bitchin100.com/wiki/index.php?title=BCR_TTL_SERIAL_HACK#T102
> <https://can01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbitchin100.com%2Fwiki%2Findex.php%3Ftitle%3DBCR_TTL_SERIAL_HACK%23T102&data=04%7C01%7CJim.Anderson%40kpu.ca%7C454b6c9b74484a9b1c2b08d8b9ba59ed%7C66b9f62d3042495eaab6db86f21500c0%7C0%7C0%7C637463557310267623%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wKyc4d0P4Gn%2FmmNE3laQx9hWP8%2B8XTGAmDfnoZaUAS4%3D&reserved=0>
>
>
>
> thanks
>
> Steve
>
>
>
>
>
>

Re: [M100] REXCPM Upgrade to version 2 available

[Jim Anderson]

I tried upgrading to this new release (using RXCUPG), and encountered issues 
when restoring a RAM image back from backup.  The same thing happens sometimes 
when switching from one RAM image to another, but every time when restoring 
from an image (either through Ctrl-R or through RXCMGR).  The progress bar 
indicates data is being copied to RAM, but then the M100 locks up, sometimes 
showing a screen like the photo below, and sometimes just a frozen screen.  
Sometimes Reset or a power-cycle will recover the machine, sometimes it needs a 
cold reset.

I also tried using RXCINI (the new one from REXCPMV2_b11.ZIP) to create a new 
directory and load REX from scratch, and the same issue is present.  In 
addition, there are more strange behaviours - when starting from an empty 
directory I can create a new RAM backup, but if I try to create another RAM 
backup or switch to a RAM image I've loaded back from TPDD, RXCMGR just creates 
a new RAM image with the same name as the current one.  If I try to delete the 
non-active image I get a message which I thought I had committed firmly to 
memory (sorry) - it said something about 'error: flash not available' or not 
ready or something to that effect.

On the upside, my RAM image was actually being sorted correctly by date and 
time.  :)  I've restored my backup and running v1 build 43 again as it was 
essentially unusable the way things were.

[cid:image001.jpg@01D6EBA8.70354260]







jim

From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of Stephen 
Adolph
Sent: Friday, January 15, 2021 17:02
To: m...@bitchin100.com
Subject: Re: [M100] REXCPM Upgrade to version 2 available

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

I found a minor issue just now;
When switching from M100 to CP/M, it is possible that the M100 leaves the 
SCREEN in the scroll lock state.

Here is a simple basic program that de-scroll locks the screen and starts CPM.
It assumes RXCMGR is installed.


CPM.BA<https://can01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcpm.ba%2F&data=04%7C01%7CJim.Anderson%40kpu.ca%7C454b6c9b74484a9b1c2b08d8b9ba59ed%7C66b9f62d3042495eaab6db86f21500c0%7C0%7C0%7C637463557310257626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FtLiLbYFv3AjUJDdt8vby6QAyqaAXGZxO%2FBmX%2FvrN1w%3D&reserved=0>

10 screen0:cls:print"Enabling scroll..."
20 screen2:printchr$(27);"W";
30 screen0:print"starting CP/M."
40 call32804,3


it is  a work around until i drop a new load with a fix.
cheers
Steve



On Fri, Jan 15, 2021 at 6:03 PM Stephen Adolph 
mailto:twospru...@gmail.com>> wrote:
The next version of REXCPM is now available for download.

http://bitchin100.com/wiki/index.php?title=REXCPM#Software<https://can01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbitchin100.com%2Fwiki%2Findex.php%3Ftitle%3DREXCPM%23Software&data=04%7C01%7CJim.Anderson%40kpu.ca%7C454b6c9b74484a9b1c2b08d8b9ba59ed%7C66b9f62d3042495eaab6db86f21500c0%7C0%7C0%7C637463557310257626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yw7hTp1TeBzj2JUE4Zuu7zAQlFITBc0Px1vgRLMd6ec%3D&reserved=0>

Version 2 provides the integrated VT100 driver, and adds in the CNTL-A 
quickmenu shortcut to start RXCMGR.

I have run through the upgrade process on my machines, from Version 1 build 43 
to Version 2 build 10.  Worked for me, and worked in VirtualT.

Please read the instructions carefully, and download the software and utilities 
bundle.
Delete your old utilities and use the new ones.
To do a fresh install (as in you have never installed it before) then use 
RXCINI.DO.
To UPGRADE an existing V1 install, please use RXCUPG.DO.

Let me know if there any problems, and of course bug reports are valuable.

Also, I have updated the BCR hack page with information on how to apply the 
hack to T102.

http://bitchin100.com/wiki/index.php?title=BCR_TTL_SERIAL_HACK#T102<https://can01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbitchin100.com%2Fwiki%2Findex.php%3Ftitle%3DBCR_TTL_SERIAL_HACK%23T102&data=04%7C01%7CJim.Anderson%40kpu.ca%7C454b6c9b74484a9b1c2b08d8b9ba59ed%7C66b9f62d3042495eaab6db86f21500c0%7C0%7C0%7C637463557310267623%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wKyc4d0P4Gn%2FmmNE3laQx9hWP8%2B8XTGAmDfnoZaUAS4%3D&reserved=0>

thanks
Steve

Re: [M100] REXCPM Upgrade to version 2 available

[Stephen Adolph]

I found a minor issue just now;
When switching from M100 to CP/M, it is possible that the M100 leaves the
SCREEN in the scroll lock state.

Here is a simple basic program that de-scroll locks the screen and starts
CPM.
It assumes RXCMGR is installed.


CPM.BA

10 screen0:cls:print"Enabling scroll..."
20 screen2:printchr$(27);"W";
30 screen0:print"starting CP/M."
40 call32804,3


it is  a work around until i drop a new load with a fix.
cheers
Steve



On Fri, Jan 15, 2021 at 6:03 PM Stephen Adolph  wrote:

> The next version of REXCPM is now available for download.
>
> http://bitchin100.com/wiki/index.php?title=REXCPM#Software
>
> Version 2 provides the integrated VT100 driver, and adds in the CNTL-A
> quickmenu shortcut to start RXCMGR.
>
> I have run through the upgrade process on my machines, from Version 1
> build 43 to Version 2 build 10.  Worked for me, and worked in VirtualT.
>
> Please read the instructions carefully, and download the software and
> utilities bundle.
> Delete your old utilities and use the new ones.
> To do a fresh install (as in you have never installed it before) then use
> RXCINI.DO.
> To UPGRADE an existing V1 install, please use RXCUPG.DO.
>
> Let me know if there any problems, and of course bug reports are valuable.
>
> Also, I have updated the BCR hack page with information on how to apply
> the hack to T102.
>
> http://bitchin100.com/wiki/index.php?title=BCR_TTL_SERIAL_HACK#T102
>
> thanks
> Steve
>
>
>

Re: [M100] REXCPM Upgrade to version 2 available

[Brian White]

Thank you sir.

On Fri, Jan 15, 2021, 6:03 PM Stephen Adolph  wrote:

> The next version of REXCPM is now available for download.
>
> http://bitchin100.com/wiki/index.php?title=REXCPM#Software
>
> Version 2 provides the integrated VT100 driver, and adds in the CNTL-A
> quickmenu shortcut to start RXCMGR.
>
> I have run through the upgrade process on my machines, from Version 1
> build 43 to Version 2 build 10.  Worked for me, and worked in VirtualT.
>
> Please read the instructions carefully, and download the software and
> utilities bundle.
> Delete your old utilities and use the new ones.
> To do a fresh install (as in you have never installed it before) then use
> RXCINI.DO.
> To UPGRADE an existing V1 install, please use RXCUPG.DO.
>
> Let me know if there any problems, and of course bug reports are valuable.
>
> Also, I have updated the BCR hack page with information on how to apply
> the hack to T102.
>
> http://bitchin100.com/wiki/index.php?title=BCR_TTL_SERIAL_HACK#T102
>
> thanks
> Steve
>
>
>

[M100] REXCPM Upgrade to version 2 available

[Stephen Adolph]

The next version of REXCPM is now available for download.

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

Version 2 provides the integrated VT100 driver, and adds in the CNTL-A
quickmenu shortcut to start RXCMGR.

I have run through the upgrade process on my machines, from Version 1 build
43 to Version 2 build 10.  Worked for me, and worked in VirtualT.

Please read the instructions carefully, and download the software and
utilities bundle.
Delete your old utilities and use the new ones.
To do a fresh install (as in you have never installed it before) then use
RXCINI.DO.
To UPGRADE an existing V1 install, please use RXCUPG.DO.

Let me know if there any problems, and of course bug reports are valuable.

Also, I have updated the BCR hack page with information on how to apply the
hack to T102.

http://bitchin100.com/wiki/index.php?title=BCR_TTL_SERIAL_HACK#T102

thanks
Steve

Re: [M100] REXCPM Reload/Update

[Greg Swallow]

Ah,

Software :1.0,   CS=8E71
Build    :43 #B-I-N-G-O
Model  :REXCPM
Firmware    :10(0)

Thanks again,

GregS <><

Dec 13, 2020 11:44:29 AM Stephen Adolph :

> sure, press the I key.  reports "information"... thanks for the info -Steve
> 
> On Sun, Dec 13, 2020 at 1:20 PM Greg Swallow  wrote:
>> Steve,
>> 
>> Finally took time to figure out what I was (or was not) doing to start mComm 
>> under macOS Catalina. So far it all looks well. SR & TSDOS ROM images as 
>> well as my RAM backup of Personal Finance (PF) are intacted. I was able to 
>> activate TSDOS from REXMGR when SR (CALL 63012) was all I could do after the 
>> reset.
>> 
>> I used files/image from RXC_11_b43 and noticed REXMGR still at v1.0. Wanted 
>> to ask if there is a way to verify the reload/update has taken?
>> 
>> In any case it looks to be working fine. Ctrl-C opens CPN et al.
>> 
>> Thanks again for REX/REXCPM/MVT100.
>> 
>> God Bless,
>> 
>> GregS <><

Re: [M100] REXCPM Reload/Update

[Stephen Adolph]

sure, press the I key.  reports "information"... thanks for the info -Steve

On Sun, Dec 13, 2020 at 1:20 PM Greg Swallow  wrote:

> Steve,
>
> Finally took time to figure out what I was (or was not) doing to start
> mComm under macOS Catalina. So far it all looks well. SR & TSDOS ROM images
> as well as my RAM backup of Personal Finance (PF) are intacted. I was able
> to activate TSDOS from REXMGR when SR (CALL 63012) was all I could do after
> the reset.
>
> I used files/image from RXC_11_b43 and noticed REXMGR still at v1.0.
> Wanted to ask if there is a way to verify the reload/update has taken?
>
> In any case it looks to be working fine. Ctrl-C opens CPN et al.
>
> Thanks again for REX/REXCPM/MVT100.
>
> God Bless,
>
> GregS <><
>

[M100] REXCPM Reload/Update

[Greg Swallow]

Steve,

Finally took time to figure out what I was (or was not) doing to start mComm 
under macOS Catalina. So far it all looks well. SR & TSDOS ROM images as well 
as my RAM backup of Personal Finance (PF) are intacted. I was able to activate 
TSDOS from REXMGR when SR (CALL 63012) was all I could do after the reset.

I used files/image from RXC_11_b43 and noticed REXMGR still at v1.0. Wanted to 
ask if there is a way to verify the reload/update has taken?

In any case it looks to be working fine. Ctrl-C opens CPN et al.

Thanks again for REX/REXCPM/MVT100.

God Bless,

GregS <><

Re: [M100] REXCPM update

[Jonathan Yuen]

Hello,

I was trying to use mcomm to inject ts-dos-like-thing, and like you I could 
then install rxmgr but then things got messed up with the ROM images that I 
loaded via rexmgr.  In the end I used a plain serial connection (at 300 baud so 
I could watch) and sent over rxcini.do from a pc.  I had it running linux and 
used minicom.  I was trying to use mcomm on my android phone and while it sent 
over what I assume is teeny or something very similar, there were defintely 
memory conflicts when I tried to bootstrap with mcomm.  After everything was in 
place, mcomm worked just fine.

Jonathan

jonathan.y...@mykopat.slu.se

Från: M100 [m100-boun...@lists.bitchin100.com] för Tom Hoppe [tjho...@gmail.com]
Skickat: den 2 december 2020 23:07
Till: m...@bitchin100.com
Ämne: Re: [M100] REXCPM update

I figured it out, to a point. I was using mComm to inject TS-DOS via 
RUN"COM:98N1E" but after it loads I can no longer CLEAR 1000,62000 (even if I 
delete TS-DOS.BA<http://TS-DOS.BA>). However, I *now* know that the CLEAR 
command works fine from a clean M100 (as it should), and I determined that 
loading it via TEENY does work properly. I am able to get RXCMGR 1.0 to install 
fine now, but when I "install" a ROM image (ie.TSD101) from REXMGR the machine 
locks up. I can hit reset to recover but everything in memory is gone at that 
point. I did run the RXCTST and it reports no issues with memory. I can say 
that the last version ran fine, so I'm unsure of what to try next (and curious 
about the cause).

Tom

On Mon, Nov 30, 2020 at 4:59 PM Stephen Adolph 
mailto:twospru...@gmail.com>> wrote:
Makes no sense.  I would cold boot.
The ram file system gets damaged by the current version  of RXCMGR.  So it 
makes sense to clean house anyways.


On Monday, November 30, 2020, Tom Hoppe 
mailto:tjho...@gmail.com>> wrote:
Hmm. Getting this error when I try to run RXCUTL.BA<http://RXCUTL.BA> for the 
update on an clean/empty M100:

?FC Error in 10
Ok

If I run CLEAR 1000,62000 manually by itself I get the same error. I can omit 
this CLEAR statement in line 10 and it seems to install fine but then I have 
instability issues later.

Tom

On Sun, Nov 29, 2020 at 6:33 AM Stephen Adolph 
mailto:twospru...@gmail.com>> wrote:
http://bitchin100.com/wiki/index.php?title=REXCPM#Backup_and_Restore

Update RXCMGR ROM build 43 and utilities V2 are posted at the above link, with 
minor updates to the page.

Build 43 includes
* bug fix:  M100 directory corruption occurs on exit from CP/M.  This is 
repaired now.
* Date/Time/Sort function added to RXCMGR

As usual, please report bugs!  This bug was discovered by a very diligent 
user... I missed it completely!

Version 2 utilities have had some improvements.
* safer transfer:  I've changed the embedded ML codes to be 7 bit ASCII 
encoding, not 8.
* this should make serial transfer as a .DO file more robust.
* I also included checksum on the embedded ML code
* lastly, I have a 2 stage loader that is much faster now.

Generally the utilities work the same, but please scan the wiki page for the 
instructions.

Good luck with the upgrade.  RXCINI is the utility you need.
Remember, only load the new SW image.  Do not choose to initialize your 
directory!


cheers
Steve




---
När du skickar e-post till SLU så innebär detta att SLU behandlar dina 
personuppgifter. För att läsa mer om hur detta går till, klicka här 
<https://www.slu.se/om-slu/kontakta-slu/personuppgifter/>
E-mailing SLU will result in SLU processing your personal data. For more 
information on how this is done, click here 
<https://www.slu.se/en/about-slu/contact-slu/personal-data/>

Re: [M100] REXCPM update

[Stephen Adolph]

Also, just a comment, for the sake of those on the list,
If you ran RXCTST, your REXCPM is now completely blank.  I hope that comes
as no surprise!\No Directory, no ROMs, no REXMGR.  So, you really have
to re-run RXCINI.DO to re install RXCMGR from scratch, and then re-install
TS-DOS.

cheers
Steve


On Wed, Dec 2, 2020 at 5:07 PM Tom Hoppe  wrote:

> I figured it out, to a point. I was using mComm to inject TS-DOS via
> RUN"COM:98N1E" but after it loads I can no longer CLEAR 1000,62000 (even if
> I delete TS-DOS.BA). However, I *now* know that the CLEAR command works
> fine from a clean M100 (as it should), and I determined that loading it via
> TEENY does work properly. I am able to get RXCMGR 1.0 to install fine now,
> but when I "install" a ROM image (ie.TSD101) from REXMGR the machine locks
> up. I can hit reset to recover but everything in memory is gone at that
> point. I did run the RXCTST and it reports no issues with memory. I can say
> that the last version ran fine, so I'm unsure of what to try next (and
> curious about the cause).
>
> Tom
>
> On Mon, Nov 30, 2020 at 4:59 PM Stephen Adolph 
> wrote:
>
>> Makes no sense.  I would cold boot.
>> The ram file system gets damaged by the current version  of RXCMGR.  So
>> it makes sense to clean house anyways.
>>
>>
>> On Monday, November 30, 2020, Tom Hoppe  wrote:
>>
>>> Hmm. Getting this error when I try to run RXCUTL.BA for the update on
>>> an clean/empty M100:
>>>
>>> ?FC Error in 10
>>> Ok
>>>
>>> If I run CLEAR 1000,62000 manually by itself I get the same error. I can
>>> omit this CLEAR statement in line 10 and it seems to install fine but then
>>> I have instability issues later.
>>>
>>> Tom
>>>
>>> On Sun, Nov 29, 2020 at 6:33 AM Stephen Adolph 
>>> wrote:
>>>
 http://bitchin100.com/wiki/index.php?title=REXCPM#Backup_and_Restore

 Update RXCMGR ROM build 43 and utilities V2 are posted at the above
 link, with minor updates to the page.

 Build 43 includes
 * bug fix:  M100 directory corruption occurs on exit from CP/M.  This
 is repaired now.
 * Date/Time/Sort function added to RXCMGR

 As usual, please report bugs!  This bug was discovered by a very
 diligent user... I missed it completely!

 Version 2 utilities have had some improvements.
 * safer transfer:  I've changed the embedded ML codes to be 7 bit ASCII
 encoding, not 8.
 * this should make serial transfer as a .DO file more robust.
 * I also included checksum on the embedded ML code
 * lastly, I have a 2 stage loader that is much faster now.

 Generally the utilities work the same, but please scan the wiki page
 for the instructions.

 Good luck with the upgrade.  RXCINI is the utility you need.
 Remember, only load the new SW image.  Do not choose to initialize your
 directory!


 cheers
 Steve

Re: [M100] REXCPM update

[Stephen Adolph]

remember, the reason for the upgrade is the fairly damaging bug discovered
with REXCPM, which corrupts the file system. So, not surprising things
could be messed up.  A cold restart WITH A POWER CYCLE is necessary to make
sure REXCPM starts up in default state and has freshly cleaned out RAM.
I've tried to make this very very clear on my wiki page.  thx


On Wed, Dec 2, 2020 at 5:07 PM Tom Hoppe  wrote:

> I figured it out, to a point. I was using mComm to inject TS-DOS via
> RUN"COM:98N1E" but after it loads I can no longer CLEAR 1000,62000 (even if
> I delete TS-DOS.BA). However, I *now* know that the CLEAR command works
> fine from a clean M100 (as it should), and I determined that loading it via
> TEENY does work properly. I am able to get RXCMGR 1.0 to install fine now,
> but when I "install" a ROM image (ie.TSD101) from REXMGR the machine locks
> up. I can hit reset to recover but everything in memory is gone at that
> point. I did run the RXCTST and it reports no issues with memory. I can say
> that the last version ran fine, so I'm unsure of what to try next (and
> curious about the cause).
>
> Tom
>
> On Mon, Nov 30, 2020 at 4:59 PM Stephen Adolph 
> wrote:
>
>> Makes no sense.  I would cold boot.
>> The ram file system gets damaged by the current version  of RXCMGR.  So
>> it makes sense to clean house anyways.
>>
>>
>> On Monday, November 30, 2020, Tom Hoppe  wrote:
>>
>>> Hmm. Getting this error when I try to run RXCUTL.BA for the update on
>>> an clean/empty M100:
>>>
>>> ?FC Error in 10
>>> Ok
>>>
>>> If I run CLEAR 1000,62000 manually by itself I get the same error. I can
>>> omit this CLEAR statement in line 10 and it seems to install fine but then
>>> I have instability issues later.
>>>
>>> Tom
>>>
>>> On Sun, Nov 29, 2020 at 6:33 AM Stephen Adolph 
>>> wrote:
>>>
 http://bitchin100.com/wiki/index.php?title=REXCPM#Backup_and_Restore

 Update RXCMGR ROM build 43 and utilities V2 are posted at the above
 link, with minor updates to the page.

 Build 43 includes
 * bug fix:  M100 directory corruption occurs on exit from CP/M.  This
 is repaired now.
 * Date/Time/Sort function added to RXCMGR

 As usual, please report bugs!  This bug was discovered by a very
 diligent user... I missed it completely!

 Version 2 utilities have had some improvements.
 * safer transfer:  I've changed the embedded ML codes to be 7 bit ASCII
 encoding, not 8.
 * this should make serial transfer as a .DO file more robust.
 * I also included checksum on the embedded ML code
 * lastly, I have a 2 stage loader that is much faster now.

 Generally the utilities work the same, but please scan the wiki page
 for the instructions.

 Good luck with the upgrade.  RXCINI is the utility you need.
 Remember, only load the new SW image.  Do not choose to initialize your
 directory!


 cheers
 Steve

Re: [M100] REXCPM update

[Stephen Adolph]

Tom ,please contact me off list to debug.  It will get too involved to have
on list, ok?  thanks.


On Wed, Dec 2, 2020 at 5:07 PM Tom Hoppe  wrote:

> I figured it out, to a point. I was using mComm to inject TS-DOS via
> RUN"COM:98N1E" but after it loads I can no longer CLEAR 1000,62000 (even if
> I delete TS-DOS.BA). However, I *now* know that the CLEAR command works
> fine from a clean M100 (as it should), and I determined that loading it via
> TEENY does work properly. I am able to get RXCMGR 1.0 to install fine now,
> but when I "install" a ROM image (ie.TSD101) from REXMGR the machine locks
> up. I can hit reset to recover but everything in memory is gone at that
> point. I did run the RXCTST and it reports no issues with memory. I can say
> that the last version ran fine, so I'm unsure of what to try next (and
> curious about the cause).
>
> Tom
>
> On Mon, Nov 30, 2020 at 4:59 PM Stephen Adolph 
> wrote:
>
>> Makes no sense.  I would cold boot.
>> The ram file system gets damaged by the current version  of RXCMGR.  So
>> it makes sense to clean house anyways.
>>
>>
>> On Monday, November 30, 2020, Tom Hoppe  wrote:
>>
>>> Hmm. Getting this error when I try to run RXCUTL.BA for the update on
>>> an clean/empty M100:
>>>
>>> ?FC Error in 10
>>> Ok
>>>
>>> If I run CLEAR 1000,62000 manually by itself I get the same error. I can
>>> omit this CLEAR statement in line 10 and it seems to install fine but then
>>> I have instability issues later.
>>>
>>> Tom
>>>
>>> On Sun, Nov 29, 2020 at 6:33 AM Stephen Adolph 
>>> wrote:
>>>
 http://bitchin100.com/wiki/index.php?title=REXCPM#Backup_and_Restore

 Update RXCMGR ROM build 43 and utilities V2 are posted at the above
 link, with minor updates to the page.

 Build 43 includes
 * bug fix:  M100 directory corruption occurs on exit from CP/M.  This
 is repaired now.
 * Date/Time/Sort function added to RXCMGR

 As usual, please report bugs!  This bug was discovered by a very
 diligent user... I missed it completely!

 Version 2 utilities have had some improvements.
 * safer transfer:  I've changed the embedded ML codes to be 7 bit ASCII
 encoding, not 8.
 * this should make serial transfer as a .DO file more robust.
 * I also included checksum on the embedded ML code
 * lastly, I have a 2 stage loader that is much faster now.

 Generally the utilities work the same, but please scan the wiki page
 for the instructions.

 Good luck with the upgrade.  RXCINI is the utility you need.
 Remember, only load the new SW image.  Do not choose to initialize your
 directory!


 cheers
 Steve

Re: [M100] REXCPM update

[Tom Hoppe]

I figured it out, to a point. I was using mComm to inject TS-DOS via
RUN"COM:98N1E" but after it loads I can no longer CLEAR 1000,62000 (even if
I delete TS-DOS.BA). However, I *now* know that the CLEAR command works
fine from a clean M100 (as it should), and I determined that loading it via
TEENY does work properly. I am able to get RXCMGR 1.0 to install fine now,
but when I "install" a ROM image (ie.TSD101) from REXMGR the machine locks
up. I can hit reset to recover but everything in memory is gone at that
point. I did run the RXCTST and it reports no issues with memory. I can say
that the last version ran fine, so I'm unsure of what to try next (and
curious about the cause).

Tom

On Mon, Nov 30, 2020 at 4:59 PM Stephen Adolph  wrote:

> Makes no sense.  I would cold boot.
> The ram file system gets damaged by the current version  of RXCMGR.  So it
> makes sense to clean house anyways.
>
>
> On Monday, November 30, 2020, Tom Hoppe  wrote:
>
>> Hmm. Getting this error when I try to run RXCUTL.BA for the update on an
>> clean/empty M100:
>>
>> ?FC Error in 10
>> Ok
>>
>> If I run CLEAR 1000,62000 manually by itself I get the same error. I can
>> omit this CLEAR statement in line 10 and it seems to install fine but then
>> I have instability issues later.
>>
>> Tom
>>
>> On Sun, Nov 29, 2020 at 6:33 AM Stephen Adolph 
>> wrote:
>>
>>> http://bitchin100.com/wiki/index.php?title=REXCPM#Backup_and_Restore
>>>
>>> Update RXCMGR ROM build 43 and utilities V2 are posted at the above
>>> link, with minor updates to the page.
>>>
>>> Build 43 includes
>>> * bug fix:  M100 directory corruption occurs on exit from CP/M.  This is
>>> repaired now.
>>> * Date/Time/Sort function added to RXCMGR
>>>
>>> As usual, please report bugs!  This bug was discovered by a very
>>> diligent user... I missed it completely!
>>>
>>> Version 2 utilities have had some improvements.
>>> * safer transfer:  I've changed the embedded ML codes to be 7 bit ASCII
>>> encoding, not 8.
>>> * this should make serial transfer as a .DO file more robust.
>>> * I also included checksum on the embedded ML code
>>> * lastly, I have a 2 stage loader that is much faster now.
>>>
>>> Generally the utilities work the same, but please scan the wiki page for
>>> the instructions.
>>>
>>> Good luck with the upgrade.  RXCINI is the utility you need.
>>> Remember, only load the new SW image.  Do not choose to initialize your
>>> directory!
>>>
>>>
>>> cheers
>>> Steve
>>>
>>>
>>>
>>>
>>>

Re: [M100] REXCPM update

[Stephen Adolph]

Makes no sense.  I would cold boot.
The ram file system gets damaged by the current version  of RXCMGR.  So it
makes sense to clean house anyways.


On Monday, November 30, 2020, Tom Hoppe  wrote:

> Hmm. Getting this error when I try to run RXCUTL.BA for the update on an
> clean/empty M100:
>
> ?FC Error in 10
> Ok
>
> If I run CLEAR 1000,62000 manually by itself I get the same error. I can
> omit this CLEAR statement in line 10 and it seems to install fine but then
> I have instability issues later.
>
> Tom
>
> On Sun, Nov 29, 2020 at 6:33 AM Stephen Adolph 
> wrote:
>
>> http://bitchin100.com/wiki/index.php?title=REXCPM#Backup_and_Restore
>>
>> Update RXCMGR ROM build 43 and utilities V2 are posted at the above link,
>> with minor updates to the page.
>>
>> Build 43 includes
>> * bug fix:  M100 directory corruption occurs on exit from CP/M.  This is
>> repaired now.
>> * Date/Time/Sort function added to RXCMGR
>>
>> As usual, please report bugs!  This bug was discovered by a very diligent
>> user... I missed it completely!
>>
>> Version 2 utilities have had some improvements.
>> * safer transfer:  I've changed the embedded ML codes to be 7 bit ASCII
>> encoding, not 8.
>> * this should make serial transfer as a .DO file more robust.
>> * I also included checksum on the embedded ML code
>> * lastly, I have a 2 stage loader that is much faster now.
>>
>> Generally the utilities work the same, but please scan the wiki page for
>> the instructions.
>>
>> Good luck with the upgrade.  RXCINI is the utility you need.
>> Remember, only load the new SW image.  Do not choose to initialize your
>> directory!
>>
>>
>> cheers
>> Steve
>>
>>
>>
>>
>>

Re: [M100] REXCPM update

[Tom Hoppe]

Hmm. Getting this error when I try to run RXCUTL.BA for the update on an
clean/empty M100:

?FC Error in 10
Ok

If I run CLEAR 1000,62000 manually by itself I get the same error. I can
omit this CLEAR statement in line 10 and it seems to install fine but then
I have instability issues later.

Tom

On Sun, Nov 29, 2020 at 6:33 AM Stephen Adolph  wrote:

> http://bitchin100.com/wiki/index.php?title=REXCPM#Backup_and_Restore
>
> Update RXCMGR ROM build 43 and utilities V2 are posted at the above link,
> with minor updates to the page.
>
> Build 43 includes
> * bug fix:  M100 directory corruption occurs on exit from CP/M.  This is
> repaired now.
> * Date/Time/Sort function added to RXCMGR
>
> As usual, please report bugs!  This bug was discovered by a very diligent
> user... I missed it completely!
>
> Version 2 utilities have had some improvements.
> * safer transfer:  I've changed the embedded ML codes to be 7 bit ASCII
> encoding, not 8.
> * this should make serial transfer as a .DO file more robust.
> * I also included checksum on the embedded ML code
> * lastly, I have a 2 stage loader that is much faster now.
>
> Generally the utilities work the same, but please scan the wiki page for
> the instructions.
>
> Good luck with the upgrade.  RXCINI is the utility you need.
> Remember, only load the new SW image.  Do not choose to initialize your
> directory!
>
>
> cheers
> Steve
>
>
>
>
>

Re: [M100] REXCPM update

[r cs]

Thanks Steve!

rcs

On Sun, Nov 29, 2020 at 9:33 AM Stephen Adolph  wrote:

> http://bitchin100.com/wiki/index.php?title=REXCPM#Backup_and_Restore
>
> Update RXCMGR ROM build 43 and utilities V2 are posted at the above link,
> with minor updates to the page.
>
> Build 43 includes
> * bug fix:  M100 directory corruption occurs on exit from CP/M.  This is
> repaired now.
> * Date/Time/Sort function added to RXCMGR
>
> As usual, please report bugs!  This bug was discovered by a very diligent
> user... I missed it completely!
>
> Version 2 utilities have had some improvements.
> * safer transfer:  I've changed the embedded ML codes to be 7 bit ASCII
> encoding, not 8.
> * this should make serial transfer as a .DO file more robust.
> * I also included checksum on the embedded ML code
> * lastly, I have a 2 stage loader that is much faster now.
>
> Generally the utilities work the same, but please scan the wiki page for
> the instructions.
>
> Good luck with the upgrade.  RXCINI is the utility you need.
> Remember, only load the new SW image.  Do not choose to initialize your
> directory!
>
>
> cheers
> Steve
>
>
>
>
>

-- 
*Níl aon tinteán mar do thinteán féin. *[Irish Gaelic]
(There is no fireside like your own fireside.)

Re: [M100] REXCPM update

[Greg Swallow]

David,

There's the rub. I sufffersd a cold boot while editing in BASIC. This left me 
with a clear MENU and no REXMGR, RXCINI, et al. The last ROM I had active was 
SR not TS-DOS. So I need to COM the RXCINI utility to get the update loaded. 
Should be AOK after reloading and not formatting the directory.

I founa CoolTerm which did a great job; though I had to drop the baud. Default 
of 9600 didn't fly so I went to 300 and got it done. Now I have to find the 
command to start mcomm in Terminal.

Thanks,

GregS <><

Nov 29, 2020 4:10:17 PM David Grissom :

> Greg,
> 
> If your REXCPM is still working with a working TS-DOS ROM, and a Mac-based 
> Desklink workalike set up (MComm, etc):
> 
> … Then use TS-DOS to load the new RCXINI.do on your M100/102.
> 
> Have the new REXCPM update available in the correct TPDD directory.
> 
> Use F7 within REXMGR remove it from memory.  Follow Stephens instructions and 
> load the new version.
> 
> That process worked for me this morning.
> 
> (I don’t have a Mac.  Just a PC.  However, am confident this would have 
> worked with my Linux setup as well.)
> 
> Hope this helps?
> 
> David
> 
> Sent from Mail[https://go.microsoft.com/fwlink/?LinkId=550986] for Windows 10
> 
> From: Greg Swallow[gswal...@mchsi.com]
> Sent: Sunday, November 29, 2020 10:51 AM
> To: m...@bitchin100.com
> Subject: Re: [M100] REXCPM update
> 
> Steve,
> 
> Very cool. Thanks.
> 
> One question. When I first loaded/configured REXCPM, I did so using an ol’ 
> Windows 7 HP computer. I have since gone all macOS; Catalina. I have gotten 
> mComm working,— though I seem to have lost the command line to start it up, I 
> wonder what ASCII terminal program those on the list have had success with 
> under macOS? Apple's App Store has oTerminal for $3.99 and it looks like a 
> pretty good set of features.
> 
> God Bless,
> 
> GregS <><
> 
>> On Nov 29, 2020, at 7:33 AM, Stephen Adolph  wrote:
>> 
>> http://bitchin100.com/wiki/index.php?title=REXCPM#Backup_and_Restore
>> 
>> ..snip..
>> 

Re: [M100] REXCPM update

[David Grissom]

Greg,

If your REXCPM is still working with a working TS-DOS ROM, and a Mac-based 
Desklink workalike set up (MComm, etc):

… Then use TS-DOS to load the new RCXINI.do on your M100/102.  
Have the new REXCPM update available in the correct TPDD directory.
Use F7 within REXMGR remove it from memory.  Follow Stephens instructions and 
load the new version.

That process worked for me this morning.
(I don’t have a Mac.  Just a PC.  However, am confident this would have worked 
with my Linux setup as well.)

Hope this helps?

David

Sent from Mail for Windows 10

From: Greg Swallow
Sent: Sunday, November 29, 2020 10:51 AM
To: m...@bitchin100.com
Subject: Re: [M100] REXCPM update

Steve,

Very cool. Thanks.

One question. When I first loaded/configured REXCPM, I did so using an ol’ 
Windows 7 HP computer. I have since gone all macOS; Catalina. I have gotten 
mComm working,— though I seem to have lost the command line to start it up, I 
wonder what ASCII terminal program those on the list have had success with 
under macOS? Apple's App Store has oTerminal for $3.99 and it looks like a 
pretty good set of features.

God Bless,

GregS <><


On Nov 29, 2020, at 7:33 AM, Stephen Adolph  wrote:

http://bitchin100.com/wiki/index.php?title=REXCPM#Backup_and_Restore

..snip..

Re: [M100] REXCPM update

[Greg Swallow]

Steve,

Very cool. Thanks.

One question. When I first loaded/configured REXCPM, I did so using an ol’ 
Windows 7 HP computer. I have since gone all macOS; Catalina. I have gotten 
mComm working,— though I seem to have lost the command line to start it up, I 
wonder what ASCII terminal program those on the list have had success with 
under macOS? Apple's App Store has oTerminal for $3.99 and it looks like a 
pretty good set of features.

God Bless,

GregS <><

> On Nov 29, 2020, at 7:33 AM, Stephen Adolph  wrote:
> 
> http://bitchin100.com/wiki/index.php?title=REXCPM#Backup_and_Restore 
> 
> 
> Update RXCMGR ROM build 43 and utilities V2 are posted at the above link, 
> with minor updates to the page.
> 
> Build 43 includes
> * bug fix:  M100 directory corruption occurs on exit from CP/M.  This is 
> repaired now.
> * Date/Time/Sort function added to RXCMGR
> 
> As usual, please report bugs!  This bug was discovered by a very diligent 
> user... I missed it completely! 
> 
> Version 2 utilities have had some improvements.
> * safer transfer:  I've changed the embedded ML codes to be 7 bit ASCII 
> encoding, not 8.
> * this should make serial transfer as a .DO file more robust.
> * I also included checksum on the embedded ML code
> * lastly, I have a 2 stage loader that is much faster now.
> 
> Generally the utilities work the same, but please scan the wiki page for the 
> instructions.
> 
> Good luck with the upgrade.  RXCINI is the utility you need.
> Remember, only load the new SW image.  Do not choose to initialize your 
> directory!
> 
> 
> cheers
> Steve
> 
> 
> 
> 

[M100] REXCPM update

[Stephen Adolph]

http://bitchin100.com/wiki/index.php?title=REXCPM#Backup_and_Restore

Update RXCMGR ROM build 43 and utilities V2 are posted at the above link,
with minor updates to the page.

Build 43 includes
* bug fix:  M100 directory corruption occurs on exit from CP/M.  This is
repaired now.
* Date/Time/Sort function added to RXCMGR

As usual, please report bugs!  This bug was discovered by a very diligent
user... I missed it completely!

Version 2 utilities have had some improvements.
* safer transfer:  I've changed the embedded ML codes to be 7 bit ASCII
encoding, not 8.
* this should make serial transfer as a .DO file more robust.
* I also included checksum on the embedded ML code
* lastly, I have a 2 stage loader that is much faster now.

Generally the utilities work the same, but please scan the wiki page for
the instructions.

Good luck with the upgrade.  RXCINI is the utility you need.
Remember, only load the new SW image.  Do not choose to initialize your
directory!


cheers
Steve

Re: [M100] REXCPM vs Reset

[Greg Swallow]

Steve,

Thank you kind sir. I shall keep an eye out.

God Bless,

GregS <><

Nov 28, 2020 3:02:49 PM Stephen Adolph :

> hi Greg,
> 
> I have a known bug. I have an update I am about to release to the wild to 
> address.  Probably tomorrow.  Please watch the list for then notice. I will 
> post the revised programs at the REX wiki.
> 
> cheers
> 
> Steve
> 
> On Sat, Nov 28, 2020 at 4:21 PM Greg Swallow  wrote:
> 
>> Steve,
>> 
>> While exanining soms code in BASIC/EDIT my MT w/ REXCPM did a cold boot. SR 
>> was still active as "CALL 63012" brought it up fine. MENU is otherwise 
>> empty. Ctrl-C does nothing (^C). Would like to see if loading REXMGR will be 
>> enough or whatever steps to try and avoid a full reload et al?
>> 
>> God Bless,
>> 
>> GregS <><
>> 
>> Nov 28, 2020 2:14:44 PM Greg Swallow :
>> 
>>> Hey Chris,
>>>
>>> Lucid here. Two MT w/ SR and have Lucid for DOS & Windows (3.1).
>>>
>>> God Bless,
>>>
>>> GregS <><
>>>
>>> Nov 28, 2020 11:49:08 AM Chris Fezzler :
>>>
 Any active Model T-family spreadsheet users?

 Any preference between Microsoft MultiPlan or Lucid?

 Were there others with the same level of functionality?

> 

Re: [M100] REXCPM vs Reset

[Stephen Adolph]

hi Greg,
I have a known bug. I have an update I am about to release to the wild to
address.  Probably tomorrow.  Please watch the list for then notice. I will
post the revised programs at the REX wiki.
cheers
Steve

On Sat, Nov 28, 2020 at 4:21 PM Greg Swallow  wrote:

> Steve,
>
> While exanining soms code in BASIC/EDIT my MT w/ REXCPM did a cold boot.
> SR was still active as "CALL 63012" brought it up fine. MENU is otherwise
> empty. Ctrl-C does nothing (^C). Would like to see if loading REXMGR will
> be enough or whatever steps to try and avoid a full reload et al?
>
> God Bless,
>
> GregS <><
>
> Nov 28, 2020 2:14:44 PM Greg Swallow :
>
> > Hey Chris,
> >
> > Lucid here. Two MT w/ SR and have Lucid for DOS & Windows (3.1).
> >
> > God Bless,
> >
> > GregS <><
> >
> > Nov 28, 2020 11:49:08 AM Chris Fezzler :
> >
> >> Any active Model T-family spreadsheet users?
> >>
> >> Any preference between Microsoft MultiPlan or Lucid?
> >>
> >> Were there others with the same level of functionality?
> >>
>

[M100] REXCPM vs Reset

[Greg Swallow]

Steve,

While exanining soms code in BASIC/EDIT my MT w/ REXCPM did a cold boot. SR was 
still active as "CALL 63012" brought it up fine. MENU is otherwise empty. 
Ctrl-C does nothing (^C). Would like to see if loading REXMGR will be enough or 
whatever steps to try and avoid a full reload et al?

God Bless,

GregS <><

Nov 28, 2020 2:14:44 PM Greg Swallow :

> Hey Chris,
> 
> Lucid here. Two MT w/ SR and have Lucid for DOS & Windows (3.1).
> 
> God Bless,
> 
> GregS <><
> 
> Nov 28, 2020 11:49:08 AM Chris Fezzler :
> 
>> Any active Model T-family spreadsheet users?
>> 
>> Any preference between Microsoft MultiPlan or Lucid?
>> 
>> Were there others with the same level of functionality?
>> 

Re: [M100] REXCPM software update

[Bert Put]

On 11/23/20 1:08 PM, Jim Anderson wrote:
>> -Original Message-
>> One of our list members (David Grissom) has been able to show that there
>> was a problem created in the M100 file directory when switching in and
>> out of CP/M.  To do so took a fair amount of effort so thanks David.
> 
> Wacky - I've had a couple of corruption issues with the M100 filesystem but 
> was never able to track it down and just started forming a habit of using 
> Ctrl-R to restore from REX backup after exiting CP/M.  I guess I should have 
> mentioned it to you but I have a hard time drawing the line between reporting 
> bugs and feeling like I'm complaining about a good thing I'm grateful to have 
> :)
> 
> 
Wacky indeed -- In all the messing around in REXCPM that I've done, I've
never had any problem with filesystem corruption in M-100 or CP/M.

Cheers,Bert

Re: [M100] REXCPM software update

[Stephen Adolph]

even more whacky,
* the bug seems to exist only in M100, not T102.  (different roms)
* VirtualT did not show the bug occurring unless you are in M100 mode, with
stock ROM, and you are running at 2.5 MHz.

As soon as you can make virtualT show the error, then you are golden...

On Mon, Nov 23, 2020 at 2:09 PM Jim Anderson  wrote:

> > -Original Message-
> > One of our list members (David Grissom) has been able to show that there
> > was a problem created in the M100 file directory when switching in and
> > out of CP/M.  To do so took a fair amount of effort so thanks David.
>
> Wacky - I've had a couple of corruption issues with the M100 filesystem
> but was never able to track it down and just started forming a habit of
> using Ctrl-R to restore from REX backup after exiting CP/M.  I guess I
> should have mentioned it to you but I have a hard time drawing the line
> between reporting bugs and feeling like I'm complaining about a good thing
> I'm grateful to have :)
>
>
>
>
>
>
>
> jim
>
>

Re: [M100] REXCPM software update

[Jim Anderson]

> -Original Message-
> One of our list members (David Grissom) has been able to show that there
> was a problem created in the M100 file directory when switching in and
> out of CP/M.  To do so took a fair amount of effort so thanks David.

Wacky - I've had a couple of corruption issues with the M100 filesystem but was 
never able to track it down and just started forming a habit of using Ctrl-R to 
restore from REX backup after exiting CP/M.  I guess I should have mentioned it 
to you but I have a hard time drawing the line between reporting bugs and 
feeling like I'm complaining about a good thing I'm grateful to have :)







jim

Re: [M100] REXCPM software update

[Gregory McGill]

Thanks Stephen for figuring this out! :)  I know it's difficult when
there's some quirky bug and only one user is experiencing it! :)

Greg

On Sun, Nov 22, 2020 at 7:51 AM Stephen Adolph  wrote:

> One of our list members (David Grissom) has been able to show that there
> was a problem created in the M100 file directory when switching in and out
> of CP/M.  To do so took a fair amount of effort so thanks David.
>
> With a good deal of effort, David, Philip and I dug in and found the
> problem.
> I've implemented a change that seems to address the problem.
>
> Doing some more testing, and I've handed it to Philip and David for their
> gruelling workout.
>
> When it looks good, I'll be posting an update to the REXCPM wiki for a the
> updated RXCMGR ROM, as well as the utilities (which have had minor changes
> only).
>
> Steve
>
>

[M100] REXCPM software update

[Stephen Adolph]

One of our list members (David Grissom) has been able to show that there
was a problem created in the M100 file directory when switching in and out
of CP/M.  To do so took a fair amount of effort so thanks David.

With a good deal of effort, David, Philip and I dug in and found the
problem.
I've implemented a change that seems to address the problem.

Doing some more testing, and I've handed it to Philip and David for their
gruelling workout.

When it looks good, I'll be posting an update to the REXCPM wiki for a the
updated RXCMGR ROM, as well as the utilities (which have had minor changes
only).

Steve

Re: [M100] REXCPM-RXCUTL.DO backup/restore Question

[Stephen Adolph]

David,
to restore using RXCUTL you must first have done a backup with RXCUTL.
RXCINI is to rebuild REXCPM (REX half) from scratch.
Steve

On Sun, Nov 15, 2020 at 5:03 PM dgris...@knology.net 
wrote:

> Stephen, All
>
> If I need to do a full restore of both the CP/M and REXCPM, will RXCUTL.DO
> restore everything without having to use RXCINI.DO? (All RAM on REXCPM
> previously and fully reset.)
>
> Thanks
> David G
>
> Sent from my Huawei Mobile

Re: [M100] REXCPM-RXCUTL.DO backup/restore Question

[Stephen Adolph]

Yes.  The restorw is from a pre previously saved backup file.

On Sunday, November 15, 2020, dgris...@knology.net 
wrote:

> Stephen, All
>
> If I need to do a full restore of both the CP/M and REXCPM, will RXCUTL.DO
> restore everything without having to use RXCINI.DO? (All RAM on REXCPM
> previously and fully reset.)
>
> Thanks
> David G
>
> Sent from my Huawei Mobile

[M100] REXCPM-RXCUTL.DO backup/restore Question

[dgris...@knology.net]

Stephen, AllIf I need to do a full restore of both the CP/M and REXCPM, will RXCUTL.DO restore everything without having to use RXCINI.DO? (All RAM on REXCPM previously and fully reset.)ThanksDavid GSent from my Huawei Mobile