Re: [M100] NiCd Battery
> On Nov 10, 2021, at 6:10 PM, Patrick McDougal wrote: > I was hoping for some advice regarding my next step. Replace? Remove? Leave > it alone? Hi Patrick! Please replace or remove until you are ready to replace. Leaving it alone will, in time, result in damage to the system. > If replacement is recommended, can anyone suggest a good vendor for the part? This vendor (a member of the list) has provided me with excellent batteries: https://www.arcadeshopper.com/wp/store/#!/Replacement-Batteries/c/32594049
[M100] NiCd Battery
Hey all, I am new to the group… I just bought a Model 100 on Ebay after a bit of nostalgia for my T200 which I used through college in the 80s. Anyway, it powers up, has a good LCD, the keyboard is a bit sticky but the machine was a bit dirty. I disassembled it for cleaning and saw the NiCd memory battery on the board. Visually it is good shape but I have read that they should “always be replaced or removed”. I checked the voltage and it is 4.04 volts. I was hoping for some advice regarding my next step. Replace? Remove? Leave it alone? If replacement is recommended, can anyone suggest a good vendor for the part? Thanks for any guidance, Patrick smime.p7s Description: S/MIME cryptographic signature
Re: [M100] 5MHz and RAM in M100/T102
Whoa, nice! That's great work Stephen! I'm guessing that this upgrade process for the m100's cousins (NEC/Olivetti, etc) would also be possible, but again with new ROM and memory (as REXCPM isn't available for the cousins). For future consideration? :) --Brad On Wed, Nov 10, 2021 at 5:27 AM Stephen Adolph wrote: > List has been a bit quiet lately, so I thought.. why not share something > interesting that I just learned? > > I have been toying quite a bit with 5MHz operation in M100 mostly but also > in T102. > In M100, I have been using 5MHz upgrades of a few different types, but > they all involve replacing the SRAM because the stock set up can't work > that fast. > > Same on T102. I did an initial attempt, and it failed, and I set it aside > for a while without digging in to it to understand why. > > When I build REX#/REXCPM, I now have a 5MHz M100 with a test jig attached > that lets me program the CPLD, test, and load the flash in the same setup. > This is a good practical use for 5MHz as it cuts the test time by about > 50%. Not quite 50% but almost. > > I have a "parts machine" T102 however that was gathering dust and I > thought - why not revive it and see what exactly is the problem with the > T102 and 5MHz. This lead to an interesting discovery (at least to me). > > The reason why the T102 can't run at 5MHz is again the SRAM - but the > reason is actually not the speed of the RAM. It is actually how the chip > select circuit is implemented.I noticed that if I compare the SRAM chip > select signals to the main ROM chip select, they had different timing. The > RAM chip select was timed to toggle with the edge of both /RD and /WR > (which is late in the cycle), whereas the chip select for the main ROM > toggles with the actual start of the machine cycle (with ALE, IO/M and all > the Address lines). > > This is totally unnecessary, and really impairs the SRAM! It happens to > work at 2.5MHz but just not any faster. The reason why this is not optimal > is because all SRAM chips have a delayed response to the chip select line. > It is better to use /OE to control the "read output" of the RAM chip > synchronous with /RD with the /CS line toggling early, as opposed to > grounding the /OE signal, and toggling /CS with /RD. > > To prove this out, I made a small change to my donor T102. > 1) Pin 22 on the HM6264 SRAM is /OE and it is grounded. I cut that track > (in 4 places for 4 SRAMs) > 2) I connected each SRAM pin 22 to /RD (found at the main ROM pin 22). > 3) I removed the A* signal from the M37 NAND gate that is used to control > chip select timing. I lifted pin 9 of M37 and connected the pin to +5V. > > Voila! T102 runs at 5MHz with stock SRAM (in this case 150nsec rated). > > > Disclaimer: I actually have replaced the Main ROM with a 150 nsec 27C256, > because a long time ago I snipped out the original main ROM. Not really > sure if the original main ROM is quick enough but I'll find that out > shortly. > > > So, a simple change allows the T102 installed SRAM to run at 5MHz. Does > the same issue impair the M100? > > The answer is - YES!. in the M100, the A* signal is again used to control > the chip select timing, as can be seen at M3 and M4. Question is - can the > timing be corrected easily and still maintain the function of the memory? > > I think this answer is NO. There isn't a spare unused RAM control that is > simply grounded on the stock 8K RAM modules. On the stock 8K module, the > chip select lines solely control read output. If we try to advance the > timing of the stock 8k module, in the early part of the memory read cycle > the SRAM would not be synchronized with /RD and would be trying to put data > on the bus when the main bus driver M2 is still itself pushing data on the > bus. I think this conflict would be undesireable. > > I may try it out, however. ;) > > So, my observations about running 5MHz are as follows > > 1) the major ICs all seem to handle 5MHz just fine. > > 2) in M100, you have to replace the original main ROM as it is too slow. > That is relatively painless as the main ROM is socketed. You also need to > replace the SRAM modules, which is a pain to be honest since at least one > module is soldered in.. REXCPM is a convenient way to disable and replace > the internal SRAM. > > 3) in T102, the main ROM (TBC) and SRAM all support 5MHz as well, but a > small circuit change is needed to free up the SRAM speed. OR - again > REXCPM is a convenient way around the SRAM mod since it disables internal > SRAM and is itself fast. > > > Is 5MHz practical? Getting there. I certainly like it. I think I will > re-attempt a 5MHz upgrade on one of my good T102 and start using it > regularly to get more confidence in it. > > I currently have 5MHz working on my NSC800 modified CPM dedicated M100. > > In terms of hardware to change the clock from 2.5 MHz to 5MHz, I have > developed a little piggy back board that solders onto the 8085. It > provides the ne
Re: [M100] 5MHz and RAM in M100/T102
Thanks for the note George. To give you a bit of info to your questions: 1) so far, I have seen no issues. Sounds are now 2x higher pitch. The RS-232 port functionality is unchanged as it is important to feed the M100 with 2.5MHz to maintain that. I've not tested the printer port but it should be unchanged. I'll try it at some point. 2) yes, there is an impact on current. I think it is around a 60% increase, from about 60mA to about 100mA. I'm going to be testing a software enabled switch to allow the user to control clock rate. Plan is to use the un-used /Y6 port. My next steps are to really polish the conversion process to a bare minimum of changes and the greatest ease. Steve On Wed, Nov 10, 2021 at 8:46 AM George Goodman wrote: > Hi Steve, > > This sounds like putting afterburners on the M100 (well, maybe more like > replacing the donkey with a mule :) and the boost in performance would be > interesting to see. I wonder: > > 1. Is there any impact on any of the I/Os (RS-232, Centronix port, etc.)? > 2. Have you seen any appreciable impact on battery life? I’m guessing you > haven’t even run the reworked units off of wall power. > > Thanks for the journal of this endeavor. I look forward to the next > chapter. > > george g. > > > On 10Nov2021, at 4:26 AM, Stephen Adolph wrote: > > > > List has been a bit quiet lately, so I thought.. why not share something > interesting that I just learned? > > > > I have been toying quite a bit with 5MHz operation in M100 mostly but > also in T102. > > In M100, I have been using 5MHz upgrades of a few different types, but > they all involve replacing the SRAM because the stock set up can't work > that fast. > > > > Same on T102. I did an initial attempt, and it failed, and I set it > aside for a while without digging in to it to understand why. > > > > When I build REX#/REXCPM, I now have a 5MHz M100 with a test jig > attached that lets me program the CPLD, test, and load the flash in the > same setup. This is a good practical use for 5MHz as it cuts the test time > by about 50%. Not quite 50% but almost. > > > > I have a "parts machine" T102 however that was gathering dust and I > thought - why not revive it and see what exactly is the problem with the > T102 and 5MHz. This lead to an interesting discovery (at least to me). > > > > The reason why the T102 can't run at 5MHz is again the SRAM - but the > reason is actually not the speed of the RAM. It is actually how the chip > select circuit is implemented.I noticed that if I compare the SRAM chip > select signals to the main ROM chip select, they had different timing. The > RAM chip select was timed to toggle with the edge of both /RD and /WR > (which is late in the cycle), whereas the chip select for the main ROM > toggles with the actual start of the machine cycle (with ALE, IO/M and all > the Address lines). > > > > This is totally unnecessary, and really impairs the SRAM! It happens to > work at 2.5MHz but just not any faster. The reason why this is not optimal > is because all SRAM chips have a delayed response to the chip select line. > It is better to use /OE to control the "read output" of the RAM chip > synchronous with /RD with the /CS line toggling early, as opposed to > grounding the /OE signal, and toggling /CS with /RD. > > > > To prove this out, I made a small change to my donor T102. > > 1) Pin 22 on the HM6264 SRAM is /OE and it is grounded. I cut that > track (in 4 places for 4 SRAMs) > > 2) I connected each SRAM pin 22 to /RD (found at the main ROM pin 22). > > 3) I removed the A* signal from the M37 NAND gate that is used to > control chip select timing. I lifted pin 9 of M37 and connected the pin to > +5V. > > > > Voila! T102 runs at 5MHz with stock SRAM (in this case 150nsec rated). > > > > > > Disclaimer: I actually have replaced the Main ROM with a 150 nsec > 27C256, because a long time ago I snipped out the original main ROM. Not > really sure if the original main ROM is quick enough but I'll find that out > shortly. > > > > > > So, a simple change allows the T102 installed SRAM to run at 5MHz. Does > the same issue impair the M100? > > > > The answer is - YES!. in the M100, the A* signal is again used to > control the chip select timing, as can be seen at M3 and M4. Question is - > can the timing be corrected easily and still maintain the function of the > memory? > > > > I think this answer is NO. There isn't a spare unused RAM control that > is simply grounded on the stock 8K RAM modules. On the stock 8K module, > the chip select lines solely control read output. If we try to advance the > timing of the stock 8k module, in the early part of the memory read cycle > the SRAM would not be synchronized with /RD and would be trying to put data > on the bus when the main bus driver M2 is still itself pushing data on the > bus. I think this conflict would be undesireable. > > > > I may try it out, however. ;) > > > > So, my observations about running 5MHz
Re: [M100] 5MHz and RAM in M100/T102
Hi Steve, This sounds like putting afterburners on the M100 (well, maybe more like replacing the donkey with a mule :) and the boost in performance would be interesting to see. I wonder: 1. Is there any impact on any of the I/Os (RS-232, Centronix port, etc.)? 2. Have you seen any appreciable impact on battery life? I’m guessing you haven’t even run the reworked units off of wall power. Thanks for the journal of this endeavor. I look forward to the next chapter. george g. > On 10Nov2021, at 4:26 AM, Stephen Adolph wrote: > > List has been a bit quiet lately, so I thought.. why not share something > interesting that I just learned? > > I have been toying quite a bit with 5MHz operation in M100 mostly but also in > T102. > In M100, I have been using 5MHz upgrades of a few different types, but they > all involve replacing the SRAM because the stock set up can't work that fast. > > Same on T102. I did an initial attempt, and it failed, and I set it aside > for a while without digging in to it to understand why. > > When I build REX#/REXCPM, I now have a 5MHz M100 with a test jig attached > that lets me program the CPLD, test, and load the flash in the same setup. > This is a good practical use for 5MHz as it cuts the test time by about 50%. > Not quite 50% but almost. > > I have a "parts machine" T102 however that was gathering dust and I thought - > why not revive it and see what exactly is the problem with the T102 and 5MHz. > This lead to an interesting discovery (at least to me). > > The reason why the T102 can't run at 5MHz is again the SRAM - but the reason > is actually not the speed of the RAM. It is actually how the chip select > circuit is implemented.I noticed that if I compare the SRAM chip select > signals to the main ROM chip select, they had different timing. The RAM chip > select was timed to toggle with the edge of both /RD and /WR (which is late > in the cycle), whereas the chip select for the main ROM toggles with the > actual start of the machine cycle (with ALE, IO/M and all the Address lines). > > This is totally unnecessary, and really impairs the SRAM! It happens to work > at 2.5MHz but just not any faster. The reason why this is not optimal is > because all SRAM chips have a delayed response to the chip select line. It > is better to use /OE to control the "read output" of the RAM chip synchronous > with /RD with the /CS line toggling early, as opposed to grounding the /OE > signal, and toggling /CS with /RD. > > To prove this out, I made a small change to my donor T102. > 1) Pin 22 on the HM6264 SRAM is /OE and it is grounded. I cut that track > (in 4 places for 4 SRAMs) > 2) I connected each SRAM pin 22 to /RD (found at the main ROM pin 22). > 3) I removed the A* signal from the M37 NAND gate that is used to control > chip select timing. I lifted pin 9 of M37 and connected the pin to +5V. > > Voila! T102 runs at 5MHz with stock SRAM (in this case 150nsec rated). > > > Disclaimer: I actually have replaced the Main ROM with a 150 nsec 27C256, > because a long time ago I snipped out the original main ROM. Not really sure > if the original main ROM is quick enough but I'll find that out shortly. > > > So, a simple change allows the T102 installed SRAM to run at 5MHz. Does the > same issue impair the M100? > > The answer is - YES!. in the M100, the A* signal is again used to control > the chip select timing, as can be seen at M3 and M4. Question is - can the > timing be corrected easily and still maintain the function of the memory? > > I think this answer is NO. There isn't a spare unused RAM control that is > simply grounded on the stock 8K RAM modules. On the stock 8K module, the > chip select lines solely control read output. If we try to advance the > timing of the stock 8k module, in the early part of the memory read cycle the > SRAM would not be synchronized with /RD and would be trying to put data on > the bus when the main bus driver M2 is still itself pushing data on the bus. > I think this conflict would be undesireable. > > I may try it out, however. ;) > > So, my observations about running 5MHz are as follows > > 1) the major ICs all seem to handle 5MHz just fine. > > 2) in M100, you have to replace the original main ROM as it is too slow. > That is relatively painless as the main ROM is socketed. You also need to > replace the SRAM modules, which is a pain to be honest since at least one > module is soldered in.. REXCPM is a convenient way to disable and replace the > internal SRAM. > > 3) in T102, the main ROM (TBC) and SRAM all support 5MHz as well, but a > small circuit change is needed to free up the SRAM speed. OR - again REXCPM > is a convenient way around the SRAM mod since it disables internal SRAM and > is itself fast. > > > Is 5MHz practical? Getting there. I certainly like it. I think I will > re-attempt a 5MHz upgrade on one of my good T102 and start using
[M100] 5MHz and RAM in M100/T102
List has been a bit quiet lately, so I thought.. why not share something interesting that I just learned? I have been toying quite a bit with 5MHz operation in M100 mostly but also in T102. In M100, I have been using 5MHz upgrades of a few different types, but they all involve replacing the SRAM because the stock set up can't work that fast. Same on T102. I did an initial attempt, and it failed, and I set it aside for a while without digging in to it to understand why. When I build REX#/REXCPM, I now have a 5MHz M100 with a test jig attached that lets me program the CPLD, test, and load the flash in the same setup. This is a good practical use for 5MHz as it cuts the test time by about 50%. Not quite 50% but almost. I have a "parts machine" T102 however that was gathering dust and I thought - why not revive it and see what exactly is the problem with the T102 and 5MHz. This lead to an interesting discovery (at least to me). The reason why the T102 can't run at 5MHz is again the SRAM - but the reason is actually not the speed of the RAM. It is actually how the chip select circuit is implemented.I noticed that if I compare the SRAM chip select signals to the main ROM chip select, they had different timing. The RAM chip select was timed to toggle with the edge of both /RD and /WR (which is late in the cycle), whereas the chip select for the main ROM toggles with the actual start of the machine cycle (with ALE, IO/M and all the Address lines). This is totally unnecessary, and really impairs the SRAM! It happens to work at 2.5MHz but just not any faster. The reason why this is not optimal is because all SRAM chips have a delayed response to the chip select line. It is better to use /OE to control the "read output" of the RAM chip synchronous with /RD with the /CS line toggling early, as opposed to grounding the /OE signal, and toggling /CS with /RD. To prove this out, I made a small change to my donor T102. 1) Pin 22 on the HM6264 SRAM is /OE and it is grounded. I cut that track (in 4 places for 4 SRAMs) 2) I connected each SRAM pin 22 to /RD (found at the main ROM pin 22). 3) I removed the A* signal from the M37 NAND gate that is used to control chip select timing. I lifted pin 9 of M37 and connected the pin to +5V. Voila! T102 runs at 5MHz with stock SRAM (in this case 150nsec rated). Disclaimer: I actually have replaced the Main ROM with a 150 nsec 27C256, because a long time ago I snipped out the original main ROM. Not really sure if the original main ROM is quick enough but I'll find that out shortly. So, a simple change allows the T102 installed SRAM to run at 5MHz. Does the same issue impair the M100? The answer is - YES!. in the M100, the A* signal is again used to control the chip select timing, as can be seen at M3 and M4. Question is - can the timing be corrected easily and still maintain the function of the memory? I think this answer is NO. There isn't a spare unused RAM control that is simply grounded on the stock 8K RAM modules. On the stock 8K module, the chip select lines solely control read output. If we try to advance the timing of the stock 8k module, in the early part of the memory read cycle the SRAM would not be synchronized with /RD and would be trying to put data on the bus when the main bus driver M2 is still itself pushing data on the bus. I think this conflict would be undesireable. I may try it out, however. ;) So, my observations about running 5MHz are as follows 1) the major ICs all seem to handle 5MHz just fine. 2) in M100, you have to replace the original main ROM as it is too slow. That is relatively painless as the main ROM is socketed. You also need to replace the SRAM modules, which is a pain to be honest since at least one module is soldered in.. REXCPM is a convenient way to disable and replace the internal SRAM. 3) in T102, the main ROM (TBC) and SRAM all support 5MHz as well, but a small circuit change is needed to free up the SRAM speed. OR - again REXCPM is a convenient way around the SRAM mod since it disables internal SRAM and is itself fast. Is 5MHz practical? Getting there. I certainly like it. I think I will re-attempt a 5MHz upgrade on one of my good T102 and start using it regularly to get more confidence in it. I currently have 5MHz working on my NSC800 modified CPM dedicated M100. In terms of hardware to change the clock from 2.5 MHz to 5MHz, I have developed a little piggy back board that solders onto the 8085. It provides the new crystal, and a little circuit to divide the clock by two to feed the computer CLK signal, and another circuit to enable clock switching between 2.5 and 5 MHz using a software command. More on this when it is fully tested (I just sent out the board). Well that's my morning coffee absorbed, onwards. Steve
