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 <[email protected]> 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 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 > > > > >
