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 <[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
>
>
>
>
>
>

-- 
-- 
Brad Grier

Reply via email to