Re: [M100] new project

[Jim Anderson]

> -Original Message-
> 
> There is an optional pretty easy modification we can do when building
> the existing design, to make a more reasonable port_en touch point.
> [...]

Thanks - I remember you mentioning this before.  I didn't build mine this way 
because I don't find I have trouble hitting the correct end of R3 the way I'm 
doing it.  FYI this wasn't the cause of the CPLD problems I was having because 
iMPACT was reporting multiple devices and other erratic behaviour when doing a 
boundary scan long before I tried touching R3 for the first time on that 
particular REX.







jim

Re: [M100] new project

[Jim Anderson]

> -Original Message-
> 
> > was telling me there were 17 CPLDs on the JTAG bus, then the whole thing
> > quit and the 3.3v bus is shorted to ground now...)
> 
> I encountered that exact same failure mode on one of my builds. Did you
> get your CPLDs from DigiKey? I wonder about their stock of CPLDs. I've
> had 2 that didn't work for me so far; the second one just won't
> enumerate on the JTAG bus.

I did get them from DigiKey - I am not 100% sure if the CPLD was bad from the 
start or not, because after I first powered it up and tried to program it I 
started examining the boards and found many of the pins of the flash chip were 
inadequately soldered (I was too quick with the drag technique - after I found 
a couple of pins not 'stuck' I pried gently under the chip to see if any pins 
would visibly lift from the board and one whole end of the chip popped right 
off the PCB)... the second time I tried to program the CPLD after mounting a 
new flash chip I had similar results for a few minutes, followed by death, 
after which I found a tiny solder bridge on the flash chip which I could only 
make out with 10x magnification.

DigiKey's stock of this CPLD is all old, obviously, as is everybody's - I'm 
given to understand that these parts are no longer made.  It was nicely packed 
with a dessicant pack and a humidity telltale card but of course that assumes 
it was properly stored for years and/or recently baked, if that's the problem...

I guess the test would be to try making a batch out of freshly-baked CPLDs and 
see if the failure rate changes.  I'd need to get a toaster oven to try this 
myself since my kitchen oven is gas (and I've already built all but one of them 
anyway).







jim

Re: [M100] new project

[Brian White]

There is an optional pretty easy modification we can do when building the
existing design, to make a more reasonable port_en touch point.

Cut the trace from C1 to R3.

Install R3 over the cut trace.

Solder bridge the two pads of the original R3 location.

Now the unused pad of R3 is a nice big target to hit with a probe. Should
be reasonably safer from accidental shorts.

https://photos.app.goo.gl/jzBgTRqOtNtCWV8o1

-- 
bkw

Re: [M100] new project

[Josh Malone]

On Nov 14, 2017 6:51 PM, "Jim Anderson"  wrote:



As it turns out, I did mess one module up (the third one I built) where the
CPLD now seems to be fried and I gave up on the whole module (I don't know
if the CPLD was bad to start with, or if bad soldering on the flash chip
contributed, but it did work for a few minutes while iMPACT was telling me
there were 17 CPLDs on the JTAG bus, then the whole thing quit and the 3.3v
bus is shorted to ground now...)


I encountered that exact same failure mode on one of my builds. Did you get
your CPLDs from DigiKey? I wonder about their stock of CPLDs. I've had 2
that didn't work for me so far; the second one just won't enumerate on the
JTAG bus.

Re: [M100] new project

[Jim Anderson]

> -Original Message-
> 
> 5 REX !!! ?  wow!

I ordered six boards and corresponding parts, plus two of the Macronix flash 
chips to test, because I needed to build four of them and I thought I might 
mess one or two of them up.

As it turns out, I did mess one module up (the third one I built) where the 
CPLD now seems to be fried and I gave up on the whole module (I don't know if 
the CPLD was bad to start with, or if bad soldering on the flash chip 
contributed, but it did work for a few minutes while iMPACT was telling me 
there were 17 CPLDs on the JTAG bus, then the whole thing quit and the 3.3v bus 
is shorted to ground now...)

I spent this long weekend building the kids' REX modules - they did their own 
castellation by hand, and soldered the ICs after I tacked them down, and loaded 
the CPLD firmware and REX software.  Now everybody has REX in our house and 
everybody is Very Happy.  :)  My son can borrow my machine and his sister's 
machine and uses them to write BASIC programs to play music in sync as 
three-part harmony, without risk of clobbering our files accidentally.

I've got one more I could build when I have another free evening.  Might build 
it as a spare or to mail out to someone who needs one.

> I should have  said - losing power and backup battery... which takes a
> while!

Yeah, I hadn't tested my own machine to see how long the poor little 
34-year-old nicad battery would hold the RAM and RTC, beyond the few minutes it 
usually takes for a battery swap.  (Mostly because I didn't have REX and it 
would have meant TBACK to recover after reaching the time limit, which is not 
terribly painful but I didn't want to know *that* badly and I didn't want to 
stress the old nicad needlessly.  Maybe I'll test one of the kids' machines 
before doing the supercap upgrade...)







jim

Re: [M100] new project

[Stephen Adolph]

5 REX !!! ?  wow!
I should have  said - losing power and backup battery... which takes a
while!

On Tue, Nov 14, 2017 at 6:20 PM, Jim Anderson  wrote:

> > -Original Message-
> >
> > Losing power would wipe the card..so that's a big difference from REX.
>
> I have to say, this worried me when I first read it, but not as much
> anymore as of this weekend...
>
> I did my first supercap swap on an m100 (my nicad was swollen and starting
> to corrode) and with the AA batteries removed from the machine the RAM
> contents and system RTC stayed intact and running for 7+ hours overnight.
>
> (I have to say, after building five REX modules it was almost like
> playtime to work on a through-hole component again) :)
>
>
>
>
>
>
>
> jim
>

Re: [M100] new project

[Jim Anderson]

> -Original Message-
> 
> Losing power would wipe the card..so that's a big difference from REX.

I have to say, this worried me when I first read it, but not as much anymore as 
of this weekend...

I did my first supercap swap on an m100 (my nicad was swollen and starting to 
corrode) and with the AA batteries removed from the machine the RAM contents 
and system RTC stayed intact and running for 7+ hours overnight.

(I have to say, after building five REX modules it was almost like playtime to 
work on a through-hole component again) :)







jim

Re: [M100] new project

[Stephen Adolph]

yah nothing like some crappy weather to give me time for hobbies.  I've
noticed this trend that October and November are good months for m100 and
me.

I have really been working hard on perfecting quad also, unfortunately at
the expense of the bom.  But I think I have a really good solution to the
issues.  I'll have to post a summary once I have things tested out.

I just wish Oshpark could do better than 15 days from board order to boards
in hand.


On Tue, Nov 14, 2017 at 2:12 PM, Mike Stein <mhs.st...@gmail.com> wrote:

> Good stuff; sounds like you've been busy!
>
> m
>
> - Original Message -
> *From:* Stephen Adolph <twospru...@gmail.com>
> *To:* Model 100 Discussion <m100@lists.bitchin100.com>
> *Sent:* Monday, November 13, 2017 10:29 PM
> *Subject:* Re: [M100] new project
>
> update-
> I have gotten REXCPM working on my bench. I built the first unit with just
> 1MB of SRAM, while it is capable of 2MB.
> I am able to bank switch, read and write.  That's pretty much it. I have
> some additional verification to do still, and making sure that the SRAM is
> protected during power cycles adequately.
>
> I'll probably build another and ship it to New Zealand so Phil can port
> CP/M onto it, and create those much needed SRAM drives.
>
> ..Steve
>
> On Wed, Oct 25, 2017 at 5:40 PM, Stephen Adolph <twospru...@gmail.com>
> wrote:
>
>> I met up with Phil Avery recently in person, which was a real hoot.  In
>> the process I got a front row demo of a T102 running CPM.  Very cool!  Now,
>> this T102 was special as it was equipped with a Remem - which provides very
>> flexible flash/ram storage.  Specifically, 4MB of flash and 2MB of SRAM.
>>
>> What's important here, is that that big pile of SRAM makes for 2 very
>> fast RAM disks for CPM.
>>
>> Phil and I discussed the challenge of how to make CPM more obtainable.
>> Remem was cool, but never easy to install and awful to build.  Keeping the
>> serial port free is also nice as it allows for the link to the outside
>> world.
>>
>> So, where we landed was that an all-SRAM REX could make CPM more
>> achievable, as it would provide not only ram in the critical -7FFF
>> memory space, but also supply ramdisk via bank switching in/out of the
>> optrom bank.
>>
>> Large SRAM chips (meaning 1MB or bigger) tend to be 3.3V IE they need to
>> be buffered to use them in M100-land.
>>
>> Anyhow, long story short, I am awaiting 3 "REXCPM" board now, which look
>> a lot like REX except with a 2MB SRAM chip, extra buffer chips, and 3 wires
>> that need hookup to the M100.  Kinda like (exactly like) a mega-EXTRAM.
>>
>> Back in the day, there was a product called EXTRAM that put RAM in the
>> optrom socket - 32kB.  Then there was XR4, which was EXTRAM x 4 or 128kB in
>> the optrom socket.  XR4 used the IO/M signal to allow PORT based bank
>> selection.  Here, REX is instead listening for an unlock sequence on the
>> address bus to enable bank selection.
>>
>> I think EXTRAM used 2 wires - Vnicad, /WR
>> I think XR4 used 3 wires - Vnicad, IO/M and /WR.
>> REXCPM plan is to use 3 wires - Vnicad, /WR and RAMRST.
>>
>> RAMRST may or may not be needed.  That signal is intended to protect
>> memory during power down.  Perhaps the developer of XR4 found an
>> alternative way to protect the memory.  Anyhow if I can eliminate RAMRST I
>> will.  Anyone have any thoughts on the subject?
>>
>> In practice this would install the same way as REX2-
>> In M100 - 3 wires over to the system bus socket
>> in T102 - 3 wires over to an adjacent RAM chip
>> in NEC - 3 wires over to a memory module.
>>
>> Losing power would wipe the card..so that's a big difference from REX.
>>
>> Having said that, SRAM does have advantages, and in principle one could
>> have many of the same REX features working on REXCPM - memory backup,
>> option roms etc.
>>
>> anyhow, that's the update.
>>
>> Steve
>>
>>
>> [image: Inline image 1]
>>
>>
>>
>>
>>
>

Re: [M100] new project

[Mike Stein]

Good stuff; sounds like you've been busy!

m
  - Original Message - 
  From: Stephen Adolph 
  To: Model 100 Discussion 
  Sent: Monday, November 13, 2017 10:29 PM
  Subject: Re: [M100] new project


  update-

  I have gotten REXCPM working on my bench. I built the first unit with just 
1MB of SRAM, while it is capable of 2MB.

  I am able to bank switch, read and write.  That's pretty much it. I have some 
additional verification to do still, and making sure that the SRAM is protected 
during power cycles adequately.


  I'll probably build another and ship it to New Zealand so Phil can port CP/M 
onto it, and create those much needed SRAM drives.


  ..Steve



  On Wed, Oct 25, 2017 at 5:40 PM, Stephen Adolph <twospru...@gmail.com> wrote:

I met up with Phil Avery recently in person, which was a real hoot.  In the 
process I got a front row demo of a T102 running CPM.  Very cool!  Now, this 
T102 was special as it was equipped with a Remem - which provides very flexible 
flash/ram storage.  Specifically, 4MB of flash and 2MB of SRAM.


What's important here, is that that big pile of SRAM makes for 2 very fast 
RAM disks for CPM.


Phil and I discussed the challenge of how to make CPM more obtainable.   
Remem was cool, but never easy to install and awful to build.  Keeping the 
serial port free is also nice as it allows for the link to the outside world.


So, where we landed was that an all-SRAM REX could make CPM more 
achievable, as it would provide not only ram in the critical -7FFF memory 
space, but also supply ramdisk via bank switching in/out of the optrom bank.


Large SRAM chips (meaning 1MB or bigger) tend to be 3.3V IE they need to be 
buffered to use them in M100-land.


Anyhow, long story short, I am awaiting 3 "REXCPM" board now, which look a 
lot like REX except with a 2MB SRAM chip, extra buffer chips, and 3 wires that 
need hookup to the M100.  Kinda like (exactly like) a mega-EXTRAM.  


Back in the day, there was a product called EXTRAM that put RAM in the 
optrom socket - 32kB.  Then there was XR4, which was EXTRAM x 4 or 128kB in the 
optrom socket.  XR4 used the IO/M signal to allow PORT based bank selection.  
Here, REX is instead listening for an unlock sequence on the address bus to 
enable bank selection.



I think EXTRAM used 2 wires - Vnicad, /WR

I think XR4 used 3 wires - Vnicad, IO/M and /WR.

REXCPM plan is to use 3 wires - Vnicad, /WR and RAMRST.  


RAMRST may or may not be needed.  That signal is intended to protect memory 
during power down.  Perhaps the developer of XR4 found an alternative way to 
protect the memory.  Anyhow if I can eliminate RAMRST I will.  Anyone have any 
thoughts on the subject?


In practice this would install the same way as REX2-

In M100 - 3 wires over to the system bus socket

in T102 - 3 wires over to an adjacent RAM chip

in NEC - 3 wires over to a memory module.



Losing power would wipe the card..so that's a big difference from REX.


Having said that, SRAM does have advantages, and in principle one could 
have many of the same REX features working on REXCPM - memory backup, option 
roms etc.


anyhow, that's the update.


Steve

Re: [M100] new project

[Stephen Adolph]

update-
I have gotten REXCPM working on my bench. I built the first unit with just
1MB of SRAM, while it is capable of 2MB.
I am able to bank switch, read and write.  That's pretty much it. I have
some additional verification to do still, and making sure that the SRAM is
protected during power cycles adequately.

I'll probably build another and ship it to New Zealand so Phil can port
CP/M onto it, and create those much needed SRAM drives.

..Steve

On Wed, Oct 25, 2017 at 5:40 PM, Stephen Adolph 
wrote:

> I met up with Phil Avery recently in person, which was a real hoot.  In
> the process I got a front row demo of a T102 running CPM.  Very cool!  Now,
> this T102 was special as it was equipped with a Remem - which provides very
> flexible flash/ram storage.  Specifically, 4MB of flash and 2MB of SRAM.
>
> What's important here, is that that big pile of SRAM makes for 2 very fast
> RAM disks for CPM.
>
> Phil and I discussed the challenge of how to make CPM more obtainable.
> Remem was cool, but never easy to install and awful to build.  Keeping the
> serial port free is also nice as it allows for the link to the outside
> world.
>
> So, where we landed was that an all-SRAM REX could make CPM more
> achievable, as it would provide not only ram in the critical -7FFF
> memory space, but also supply ramdisk via bank switching in/out of the
> optrom bank.
>
> Large SRAM chips (meaning 1MB or bigger) tend to be 3.3V IE they need to
> be buffered to use them in M100-land.
>
> Anyhow, long story short, I am awaiting 3 "REXCPM" board now, which look a
> lot like REX except with a 2MB SRAM chip, extra buffer chips, and 3 wires
> that need hookup to the M100.  Kinda like (exactly like) a mega-EXTRAM.
>
> Back in the day, there was a product called EXTRAM that put RAM in the
> optrom socket - 32kB.  Then there was XR4, which was EXTRAM x 4 or 128kB in
> the optrom socket.  XR4 used the IO/M signal to allow PORT based bank
> selection.  Here, REX is instead listening for an unlock sequence on the
> address bus to enable bank selection.
>
> I think EXTRAM used 2 wires - Vnicad, /WR
> I think XR4 used 3 wires - Vnicad, IO/M and /WR.
> REXCPM plan is to use 3 wires - Vnicad, /WR and RAMRST.
>
> RAMRST may or may not be needed.  That signal is intended to protect
> memory during power down.  Perhaps the developer of XR4 found an
> alternative way to protect the memory.  Anyhow if I can eliminate RAMRST I
> will.  Anyone have any thoughts on the subject?
>
> In practice this would install the same way as REX2-
> In M100 - 3 wires over to the system bus socket
> in T102 - 3 wires over to an adjacent RAM chip
> in NEC - 3 wires over to a memory module.
>
> Losing power would wipe the card..so that's a big difference from REX.
>
> Having said that, SRAM does have advantages, and in principle one could
> have many of the same REX features working on REXCPM - memory backup,
> option roms etc.
>
> anyhow, that's the update.
>
> Steve
>
>
> [image: Inline image 1]
>
>
>
>
>

Re: [M100] new project

[Peter Vollan]

Perhaps I should remind everyone at this point that I wrote a program
to sync your time with the NIST in Colorado, it is on my member upload
page. Also a program to change one's time to account for DST or any
other time zone change.

On 1 November 2017 at 08:04, Stephen Adolph  wrote:
> ah, so in some cases it would be good to have REX restore the date too.
>
> On Wed, Nov 1, 2017 at 8:53 AM, Brian Brindle  wrote:
>>
>> Stephen, yes - that works perfectly. The situation I was describing above
>> is after a CTRL-BREAK-RESET total wipe of the M100 after I have wedged it
>> completely - then reload RAM from REX.
>>
>>
>> On Wed, Nov 1, 2017 at 8:43 AM, Stephen Adolph 
>> wrote:
>>>
>>> At some point in REX I included a feature to maintain clock setting
>>> through ram image swaps.
>>>
>>> On Wed, Nov 1, 2017 at 8:21 AM, Brian Brindle  wrote:

 Peter,

 The current clock in the M100 does just fine usually. Unless it sits for
 a long time. My request for another one is just me being lazy. (sort of).

 I use my m100 in strange ways and often I have issues where it crashes
 or locks up and requires a total system reset.
 Most of my activities with it require accurate time. I'm either logging
 things, tracking things or just doing notes etc.
 With REX it's like a dream to recover from these situations. Granted,
 more times than not REX is also the cause..

 But right now I reset, load REXMGR, reload the RAM image and it takes
 seconds.

 Then I have to set the clock by either going into BASIC and setting the
 3 variables or attaching one of my external devices
 and running a basic program to do it for me.

 Not hard mind you but when I do this same thing in VirtualT the time is
 always right so maybe I'm spoiled.


 Brian




 On Oct 31, 2017 7:01 PM, "Peter Vollan"  wrote:

 Let me sure that I understand: however correctly you set the time on
 your Model 100, it will "drift off", because it cannot keep correct
 time?


 On 26 October 2017 at 12:58, John R. Hogerhuis  wrote:
 >
 >
 > On Thu, Oct 26, 2017 at 12:22 PM, Brian Brindle 
 > wrote:
 >>
 >> Hey John,
 >>
 >> To move RAM images around I"m using REX, creating a backup of the RAM
 >> image and saving it to "disk" or in this case Mcomm or my NADS. I
 >> like Mcomm
 >> because the directory it saves everything in on the phone is
 >> automatically
 >> backed up (by another application) to dropbox right now. Then I load
 >> that
 >> image in VirtualT on the PC.
 >>
 >
 > Ah. Well, I did write a program to sync time with NADSBox.
 >
 >
 > http://bitchin100.com/wiki/index.php?title=Synchronize_Time_with_your_NADS
 >
 > -- John.


>>>
>>>
>>
>

Re: [M100] new project

[Stephen Adolph]

ah, so in some cases it would be good to have REX restore the date too.

On Wed, Nov 1, 2017 at 8:53 AM, Brian Brindle  wrote:

> Stephen, yes - that works perfectly. The situation I was describing above
> is after a CTRL-BREAK-RESET total wipe of the M100 after I have wedged it
> completely - then reload RAM from REX.
>
>
> On Wed, Nov 1, 2017 at 8:43 AM, Stephen Adolph 
> wrote:
>
>> At some point in REX I included a feature to maintain clock setting
>> through ram image swaps.
>>
>> On Wed, Nov 1, 2017 at 8:21 AM, Brian Brindle  wrote:
>>
>>> Peter,
>>>
>>> The current clock in the M100 does just fine usually. Unless it sits for
>>> a long time. My request for another one is just me being lazy. (sort of).
>>>
>>> I use my m100 in strange ways and often I have issues where it crashes
>>> or locks up and requires a total system reset.
>>> Most of my activities with it require accurate time. I'm either logging
>>> things, tracking things or just doing notes etc.
>>> With REX it's like a dream to recover from these situations. Granted,
>>> more times than not REX is also the cause..
>>>
>>> But right now I reset, load REXMGR, reload the RAM image and it takes
>>> seconds.
>>>
>>> Then I have to set the clock by either going into BASIC and setting the
>>> 3 variables or attaching one of my external devices
>>> and running a basic program to do it for me.
>>>
>>> Not hard mind you but when I do this same thing in VirtualT the time is
>>> always right so maybe I'm spoiled.
>>>
>>>
>>> Brian
>>>
>>>
>>>
>>>
>>> On Oct 31, 2017 7:01 PM, "Peter Vollan"  wrote:
>>>
>>> Let me sure that I understand: however correctly you set the time on
>>> your Model 100, it will "drift off", because it cannot keep correct
>>> time?
>>>
>>>
>>> On 26 October 2017 at 12:58, John R. Hogerhuis  wrote:
>>> >
>>> >
>>> > On Thu, Oct 26, 2017 at 12:22 PM, Brian Brindle 
>>> wrote:
>>> >>
>>> >> Hey John,
>>> >>
>>> >> To move RAM images around I"m using REX, creating a backup of the RAM
>>> >> image and saving it to "disk" or in this case Mcomm or my NADS. I
>>> like Mcomm
>>> >> because the directory it saves everything in on the phone is
>>> automatically
>>> >> backed up (by another application) to dropbox right now. Then I load
>>> that
>>> >> image in VirtualT on the PC.
>>> >>
>>> >
>>> > Ah. Well, I did write a program to sync time with NADSBox.
>>> >
>>> > http://bitchin100.com/wiki/index.php?title=Synchronize_Time_
>>> with_your_NADS
>>> >
>>> > -- John.
>>>
>>>
>>>
>>
>>
>

Re: [M100] new project

[Brian Brindle]

Stephen, yes - that works perfectly. The situation I was describing above
is after a CTRL-BREAK-RESET total wipe of the M100 after I have wedged it
completely - then reload RAM from REX.


On Wed, Nov 1, 2017 at 8:43 AM, Stephen Adolph  wrote:

> At some point in REX I included a feature to maintain clock setting
> through ram image swaps.
>
> On Wed, Nov 1, 2017 at 8:21 AM, Brian Brindle  wrote:
>
>> Peter,
>>
>> The current clock in the M100 does just fine usually. Unless it sits for
>> a long time. My request for another one is just me being lazy. (sort of).
>>
>> I use my m100 in strange ways and often I have issues where it crashes or
>> locks up and requires a total system reset.
>> Most of my activities with it require accurate time. I'm either logging
>> things, tracking things or just doing notes etc.
>> With REX it's like a dream to recover from these situations. Granted,
>> more times than not REX is also the cause..
>>
>> But right now I reset, load REXMGR, reload the RAM image and it takes
>> seconds.
>>
>> Then I have to set the clock by either going into BASIC and setting the 3
>> variables or attaching one of my external devices
>> and running a basic program to do it for me.
>>
>> Not hard mind you but when I do this same thing in VirtualT the time is
>> always right so maybe I'm spoiled.
>>
>>
>> Brian
>>
>>
>>
>>
>> On Oct 31, 2017 7:01 PM, "Peter Vollan"  wrote:
>>
>> Let me sure that I understand: however correctly you set the time on
>> your Model 100, it will "drift off", because it cannot keep correct
>> time?
>>
>>
>> On 26 October 2017 at 12:58, John R. Hogerhuis  wrote:
>> >
>> >
>> > On Thu, Oct 26, 2017 at 12:22 PM, Brian Brindle 
>> wrote:
>> >>
>> >> Hey John,
>> >>
>> >> To move RAM images around I"m using REX, creating a backup of the RAM
>> >> image and saving it to "disk" or in this case Mcomm or my NADS. I like
>> Mcomm
>> >> because the directory it saves everything in on the phone is
>> automatically
>> >> backed up (by another application) to dropbox right now. Then I load
>> that
>> >> image in VirtualT on the PC.
>> >>
>> >
>> > Ah. Well, I did write a program to sync time with NADSBox.
>> >
>> > http://bitchin100.com/wiki/index.php?title=Synchronize_Time_
>> with_your_NADS
>> >
>> > -- John.
>>
>>
>>
>
>

Re: [M100] new project

[Stephen Adolph]

At some point in REX I included a feature to maintain clock setting through
ram image swaps.

On Wed, Nov 1, 2017 at 8:21 AM, Brian Brindle  wrote:

> Peter,
>
> The current clock in the M100 does just fine usually. Unless it sits for a
> long time. My request for another one is just me being lazy. (sort of).
>
> I use my m100 in strange ways and often I have issues where it crashes or
> locks up and requires a total system reset.
> Most of my activities with it require accurate time. I'm either logging
> things, tracking things or just doing notes etc.
> With REX it's like a dream to recover from these situations. Granted, more
> times than not REX is also the cause..
>
> But right now I reset, load REXMGR, reload the RAM image and it takes
> seconds.
>
> Then I have to set the clock by either going into BASIC and setting the 3
> variables or attaching one of my external devices
> and running a basic program to do it for me.
>
> Not hard mind you but when I do this same thing in VirtualT the time is
> always right so maybe I'm spoiled.
>
>
> Brian
>
>
>
>
> On Oct 31, 2017 7:01 PM, "Peter Vollan"  wrote:
>
> Let me sure that I understand: however correctly you set the time on
> your Model 100, it will "drift off", because it cannot keep correct
> time?
>
>
> On 26 October 2017 at 12:58, John R. Hogerhuis  wrote:
> >
> >
> > On Thu, Oct 26, 2017 at 12:22 PM, Brian Brindle 
> wrote:
> >>
> >> Hey John,
> >>
> >> To move RAM images around I"m using REX, creating a backup of the RAM
> >> image and saving it to "disk" or in this case Mcomm or my NADS. I like
> Mcomm
> >> because the directory it saves everything in on the phone is
> automatically
> >> backed up (by another application) to dropbox right now. Then I load
> that
> >> image in VirtualT on the PC.
> >>
> >
> > Ah. Well, I did write a program to sync time with NADSBox.
> >
> > http://bitchin100.com/wiki/index.php?title=Synchronize_Time_
> with_your_NADS
> >
> > -- John.
>
>
>

Re: [M100] new project

[Brian Brindle]

Peter,

The current clock in the M100 does just fine usually. Unless it sits for a
long time. My request for another one is just me being lazy. (sort of).

I use my m100 in strange ways and often I have issues where it crashes or
locks up and requires a total system reset.
Most of my activities with it require accurate time. I'm either logging
things, tracking things or just doing notes etc.
With REX it's like a dream to recover from these situations. Granted, more
times than not REX is also the cause..

But right now I reset, load REXMGR, reload the RAM image and it takes
seconds.

Then I have to set the clock by either going into BASIC and setting the 3
variables or attaching one of my external devices
and running a basic program to do it for me.

Not hard mind you but when I do this same thing in VirtualT the time is
always right so maybe I'm spoiled.


Brian




On Oct 31, 2017 7:01 PM, "Peter Vollan"  wrote:

Let me sure that I understand: however correctly you set the time on
your Model 100, it will "drift off", because it cannot keep correct
time?


On 26 October 2017 at 12:58, John R. Hogerhuis  wrote:
>
>
> On Thu, Oct 26, 2017 at 12:22 PM, Brian Brindle 
wrote:
>>
>> Hey John,
>>
>> To move RAM images around I"m using REX, creating a backup of the RAM
>> image and saving it to "disk" or in this case Mcomm or my NADS. I like
Mcomm
>> because the directory it saves everything in on the phone is
automatically
>> backed up (by another application) to dropbox right now. Then I load that
>> image in VirtualT on the PC.
>>
>
> Ah. Well, I did write a program to sync time with NADSBox.
>
> http://bitchin100.com/wiki/index.php?title=Synchronize_Time_with_your_NADS
>
> -- John.

Re: [M100] new project

[John Gardner]

Yup.  If you have a clock,  you know what time it is.

If you have more than one clock,  you don't...   :)

 ...


On 10/31/17, Peter Vollan  wrote:
> Let me sure that I understand: however correctly you set the time on
> your Model 100, it will "drift off", because it cannot keep correct
> time?
>
>
> On 26 October 2017 at 12:58, John R. Hogerhuis  wrote:
>>
>>
>> On Thu, Oct 26, 2017 at 12:22 PM, Brian Brindle 
>> wrote:
>>>
>>> Hey John,
>>>
>>> To move RAM images around I"m using REX, creating a backup of the RAM
>>> image and saving it to "disk" or in this case Mcomm or my NADS. I like
>>> Mcomm
>>> because the directory it saves everything in on the phone is
>>> automatically
>>> backed up (by another application) to dropbox right now. Then I load
>>> that
>>> image in VirtualT on the PC.
>>>
>>
>> Ah. Well, I did write a program to sync time with NADSBox.
>>
>> http://bitchin100.com/wiki/index.php?title=Synchronize_Time_with_your_NADS
>>
>> -- John.
>

Re: [M100] new project

[Peter Vollan]

Let me sure that I understand: however correctly you set the time on
your Model 100, it will "drift off", because it cannot keep correct
time?


On 26 October 2017 at 12:58, John R. Hogerhuis  wrote:
>
>
> On Thu, Oct 26, 2017 at 12:22 PM, Brian Brindle  wrote:
>>
>> Hey John,
>>
>> To move RAM images around I"m using REX, creating a backup of the RAM
>> image and saving it to "disk" or in this case Mcomm or my NADS. I like Mcomm
>> because the directory it saves everything in on the phone is automatically
>> backed up (by another application) to dropbox right now. Then I load that
>> image in VirtualT on the PC.
>>
>
> Ah. Well, I did write a program to sync time with NADSBox.
>
> http://bitchin100.com/wiki/index.php?title=Synchronize_Time_with_your_NADS
>
> -- John.

Re: [M100] new project

[John R. Hogerhuis]

On Thu, Oct 26, 2017 at 12:22 PM, Brian Brindle  wrote:

> Hey John,
>
> To move RAM images around I"m using REX, creating a backup of the RAM
> image and saving it to "disk" or in this case Mcomm or my NADS. I like
> Mcomm because the directory it saves everything in on the phone is
> automatically backed up (by another application) to dropbox right now. Then
> I load that image in VirtualT on the PC.
>
>
Ah. Well, I did write a program to sync time with NADSBox.

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

-- John.

Re: [M100] new project

[Brian Brindle]

Hey John,

To move RAM images around I"m using REX, creating a backup of the RAM image
and saving it to "disk" or in this case Mcomm or my NADS. I like Mcomm
because the directory it saves everything in on the phone is automatically
backed up (by another application) to dropbox right now. Then I load that
image in VirtualT on the PC.

The times when I need an accurately set clock are not always when I'm
backing things up. Time drift is a constant issue when tracking sats with
the M100 in the middle of a field with radio gear strapped all over you. I
have several external devices that can set the clock for me in times like
this but it requires loading a basic program to do so. Not difficult mind
you but not quite just a power cycle either.

I like Thought in SuperROM but wrote some perl scripts to manipulate Idea!
data files many years ago so am pretty set on using it. Your talking to a
guy who still uses his 34 year old PC so I'm pretty resistant to change.

Brian


On Thu, Oct 26, 2017 at 3:10 PM, John R. Hogerhuis  wrote:

> On Thu, Oct 26, 2017 at 11:59 AM, Brian Brindle 
> wrote:
>
>>
>> The RTC request is based on the way I utilize my M100s. I'm constantly
>> doing a total wipe on them for one reason or another
>>
>
>
> What file service do you use if any? You mentioned moving images around to
> VIrtualT does that mean you use TBACK?
>
> I could add a time sync extension to either TBACK or LaddieAlpha.
>
> If TBACK, I could make it skip the clock when restoring an image.
>
>
>> but I use Idea! pretty heavily and rely on a correct date/time. Just
>> always thought it would be nice if it was always correct since it's
>> something I constantly forget to set.
>>
>>
> Have you used Thought in SuperROM?
>
> Idea is compiled BASIC code, IIRC, Thought is MUCH faster.
>
> -- John.
>
>
>

Re: [M100] new project

[John R. Hogerhuis]

On Thu, Oct 26, 2017 at 11:59 AM, Brian Brindle  wrote:

>
> The RTC request is based on the way I utilize my M100s. I'm constantly
> doing a total wipe on them for one reason or another
>


What file service do you use if any? You mentioned moving images around to
VIrtualT does that mean you use TBACK?

I could add a time sync extension to either TBACK or LaddieAlpha.

If TBACK, I could make it skip the clock when restoring an image.


> but I use Idea! pretty heavily and rely on a correct date/time. Just
> always thought it would be nice if it was always correct since it's
> something I constantly forget to set.
>
>
Have you used Thought in SuperROM?

Idea is compiled BASIC code, IIRC, Thought is MUCH faster.

-- John.

Re: [M100] new project

[Brian Brindle]

This does look awesome Stephen so forgive the selfish RTC request - I don't
want to seem like I'm diminishing all the other incredibly amazing / mind
blowing things you are already bringing. I don't know how I've gone this
long without having a REX but I did and I've spent the last two weeks
positively giddy with my new capabilities. I used to have different M100s
for different projects and would grab the appropriate one when I wanted to
do that thing. My (now horribly neglected) satellite tracking project for
example. Because of the size of the Keplerian database and my lack of
ambition to do anything like load stuff from SD card I just kept it all
loaded on one unit. Now I can pop that image on the current M100 I'm
working on, copy it to my phone, sync via dropbox or GoogleDrive and play
with that image on VirtualT then reverse the process to get it back on
physical hardware. It's downright amazing. Everyone needs a REX.

The RTC request is based on the way I utilize my M100s. I'm constantly
doing a total wipe on them for one reason or another but I use Idea! pretty
heavily and rely on a correct date/time. Just always thought it would be
nice if it was always correct since it's something I constantly forget to
set.

On Wed, Oct 25, 2017 at 9:05 PM, Stephen Adolph 
wrote:

> I looked a bit at a supercap but...we have a battery...we just need a
> wire!.
>
> What would one need an rtc For?
>
>
> On Wednesday, October 25, 2017, Brian Brindle  wrote:
>
>> Any thoughts of a battery backup and or a RTC?
>>
>> On Oct 25, 2017 6:49 PM, "Josh Malone"  wrote:
>>
>>> Wow. This sounds very cool! I've never actually run CP/M, and I'm not
>>> sure that running it on Model-T is super exciting (probably just because I
>>> haven't tried it) but the capabilities of the REXCPM sound awesome.
>>>
>>> I'm fine with a 3-wire install. Hell, any number of wires to the mobo
>>> would not be a turn-off for me using it; basically as long as trace-cutting
>>> isn't involved it won't bother me.
>>>
>>> I'm assuming the CPLD and SRAM are on the other side? Man, that board is
>>> gonna be crammed! :)
>>>
>>> -Josh
>>>
>>

Re: [M100] new project

[Mike Stein]

No soldering (or Vnicad) required; turns out that the M100 EXTRAM does indeed 
only use /WR and RAMRST with the XR4 also using /Y0 for the bank selection, all 
plugged into the bus. The 102 connected to an adjacent RAM chip instead, but no 
idea how they connected /Y0 on the 102.

m
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Wednesday, October 25, 2017 10:39 PM
  Subject: Re: [M100] new project




  On Wed, Oct 25, 2017 at 6:10 PM Mike Stein <mhs.st...@gmail.com> wrote:



I think EXTRAM (and presumably also XR4) used RAMRST, at least in the M100; 
where is this Vnicad you speak of? If you mean Vb, I don't think it's available 
on the bus?



  If it was he wouldn’t need a wire soldered to get it :-)


  — John. 

Re: [M100] new project

[Brian White]

Sure as hell sounds cool.
​--
bkw

Re: [M100] new project

[John R. Hogerhuis]

On Wed, Oct 25, 2017 at 6:10 PM Mike Stein  wrote:

>
> I think EXTRAM (and presumably also XR4) used RAMRST, at least in the
> M100; where is this Vnicad you speak of? If you mean Vb, I don't think it's
> available on the bus?
>
>

If it was he wouldn’t need a wire soldered to get it :-)

— John.

Re: [M100] new project

[Mike Stein]

Hey, hey; an expanded XR4 for CP/M was my idea! ;-)

Yeah, it was great to finally meet Phil in person; really sorry that meeting up 
with you couldn't work out.

I think EXTRAM (and presumably also XR4) used RAMRST, at least in the M100; 
where is this Vnicad you speak of? If you mean Vb, I don't think it's available 
on the bus?

As I discussed with Phil I was actually working on an EXTRAM clone (although 
not specifically for CP/M) and exploring how XR4 did its bank switching; do you 
have any specifics?

m
  - Original Message - 
  From: Stephen Adolph 
  To: Model 100 Discussion 
  Sent: Wednesday, October 25, 2017 5:40 PM
  Subject: [M100] new project


  I met up with Phil Avery recently in person, which was a real hoot.  In the 
process I got a front row demo of a T102 running CPM.  Very cool!  Now, this 
T102 was special as it was equipped with a Remem - which provides very flexible 
flash/ram storage.  Specifically, 4MB of flash and 2MB of SRAM.


  What's important here, is that that big pile of SRAM makes for 2 very fast 
RAM disks for CPM.


  Phil and I discussed the challenge of how to make CPM more obtainable.   
Remem was cool, but never easy to install and awful to build.  Keeping the 
serial port free is also nice as it allows for the link to the outside world.


  So, where we landed was that an all-SRAM REX could make CPM more achievable, 
as it would provide not only ram in the critical -7FFF memory space, but 
also supply ramdisk via bank switching in/out of the optrom bank.


  Large SRAM chips (meaning 1MB or bigger) tend to be 3.3V IE they need to be 
buffered to use them in M100-land.


  Anyhow, long story short, I am awaiting 3 "REXCPM" board now, which look a 
lot like REX except with a 2MB SRAM chip, extra buffer chips, and 3 wires that 
need hookup to the M100.  Kinda like (exactly like) a mega-EXTRAM.  


  Back in the day, there was a product called EXTRAM that put RAM in the optrom 
socket - 32kB.  Then there was XR4, which was EXTRAM x 4 or 128kB in the optrom 
socket.  XR4 used the IO/M signal to allow PORT based bank selection.  Here, 
REX is instead listening for an unlock sequence on the address bus to enable 
bank selection.



  I think EXTRAM used 2 wires - Vnicad, /WR

  I think XR4 used 3 wires - Vnicad, IO/M and /WR.

  REXCPM plan is to use 3 wires - Vnicad, /WR and RAMRST.  


  RAMRST may or may not be needed.  That signal is intended to protect memory 
during power down.  Perhaps the developer of XR4 found an alternative way to 
protect the memory.  Anyhow if I can eliminate RAMRST I will.  Anyone have any 
thoughts on the subject?


  In practice this would install the same way as REX2-

  In M100 - 3 wires over to the system bus socket

  in T102 - 3 wires over to an adjacent RAM chip

  in NEC - 3 wires over to a memory module.



  Losing power would wipe the card..so that's a big difference from REX.


  Having said that, SRAM does have advantages, and in principle one could have 
many of the same REX features working on REXCPM - memory backup, option roms 
etc.


  anyhow, that's the update.


  Steve

Re: [M100] new project

[Stephen Adolph]

I looked a bit at a supercap but...we have a battery...we just need a wire!.

What would one need an rtc For?

On Wednesday, October 25, 2017, Brian Brindle  wrote:

> Any thoughts of a battery backup and or a RTC?
>
> On Oct 25, 2017 6:49 PM, "Josh Malone"  > wrote:
>
>> Wow. This sounds very cool! I've never actually run CP/M, and I'm not
>> sure that running it on Model-T is super exciting (probably just because I
>> haven't tried it) but the capabilities of the REXCPM sound awesome.
>>
>> I'm fine with a 3-wire install. Hell, any number of wires to the mobo
>> would not be a turn-off for me using it; basically as long as trace-cutting
>> isn't involved it won't bother me.
>>
>> I'm assuming the CPLD and SRAM are on the other side? Man, that board is
>> gonna be crammed! :)
>>
>> -Josh
>>
>

Re: [M100] new project

[Brian Brindle]

Any thoughts of a battery backup and or a RTC?

On Oct 25, 2017 6:49 PM, "Josh Malone"  wrote:

> Wow. This sounds very cool! I've never actually run CP/M, and I'm not sure
> that running it on Model-T is super exciting (probably just because I
> haven't tried it) but the capabilities of the REXCPM sound awesome.
>
> I'm fine with a 3-wire install. Hell, any number of wires to the mobo
> would not be a turn-off for me using it; basically as long as trace-cutting
> isn't involved it won't bother me.
>
> I'm assuming the CPLD and SRAM are on the other side? Man, that board is
> gonna be crammed! :)
>
> -Josh
>

Re: [M100] new project

[Josh Malone]

Wow. This sounds very cool! I've never actually run CP/M, and I'm not sure
that running it on Model-T is super exciting (probably just because I
haven't tried it) but the capabilities of the REXCPM sound awesome.

I'm fine with a 3-wire install. Hell, any number of wires to the mobo would
not be a turn-off for me using it; basically as long as trace-cutting isn't
involved it won't bother me.

I'm assuming the CPLD and SRAM are on the other side? Man, that board is
gonna be crammed! :)

-Josh

[M100] new project

[Stephen Adolph]

I met up with Phil Avery recently in person, which was a real hoot.  In the
process I got a front row demo of a T102 running CPM.  Very cool!  Now,
this T102 was special as it was equipped with a Remem - which provides very
flexible flash/ram storage.  Specifically, 4MB of flash and 2MB of SRAM.

What's important here, is that that big pile of SRAM makes for 2 very fast
RAM disks for CPM.

Phil and I discussed the challenge of how to make CPM more obtainable.
Remem was cool, but never easy to install and awful to build.  Keeping the
serial port free is also nice as it allows for the link to the outside
world.

So, where we landed was that an all-SRAM REX could make CPM more
achievable, as it would provide not only ram in the critical -7FFF
memory space, but also supply ramdisk via bank switching in/out of the
optrom bank.

Large SRAM chips (meaning 1MB or bigger) tend to be 3.3V IE they need to be
buffered to use them in M100-land.

Anyhow, long story short, I am awaiting 3 "REXCPM" board now, which look a
lot like REX except with a 2MB SRAM chip, extra buffer chips, and 3 wires
that need hookup to the M100.  Kinda like (exactly like) a mega-EXTRAM.

Back in the day, there was a product called EXTRAM that put RAM in the
optrom socket - 32kB.  Then there was XR4, which was EXTRAM x 4 or 128kB in
the optrom socket.  XR4 used the IO/M signal to allow PORT based bank
selection.  Here, REX is instead listening for an unlock sequence on the
address bus to enable bank selection.

I think EXTRAM used 2 wires - Vnicad, /WR
I think XR4 used 3 wires - Vnicad, IO/M and /WR.
REXCPM plan is to use 3 wires - Vnicad, /WR and RAMRST.

RAMRST may or may not be needed.  That signal is intended to protect memory
during power down.  Perhaps the developer of XR4 found an alternative way
to protect the memory.  Anyhow if I can eliminate RAMRST I will.  Anyone
have any thoughts on the subject?

In practice this would install the same way as REX2-
In M100 - 3 wires over to the system bus socket
in T102 - 3 wires over to an adjacent RAM chip
in NEC - 3 wires over to a memory module.

Losing power would wipe the card..so that's a big difference from REX.

Having said that, SRAM does have advantages, and in principle one could
have many of the same REX features working on REXCPM - memory backup,
option roms etc.

anyhow, that's the update.

Steve


[image: Inline image 1]