A few things about ram for the 100...
1 - Just to get it out of the way for completeness, if you just want to
fill out the 32k, then you can build or buy normal 8k modules.
https://github.com/bkw777/Model_T_RAM
2 - Several years ago Steve had a thing called QUAD which does this
ramrst trick. He stopped producing it and took it down from oshpark so
that people didn't unwittingly buy it after he determined that it had a
little problem that it didn't reliably reset to itself to bank 0 on
power-cycle. Plus I think there was some conflict between the 0QUAD
driver software and REXMGR or REX itself which was never resolved.
However, for the purpose of study, you can read about it and look over
the schematic here: http://bitchin100.com/wiki/index.php?title=QUAD
3 - Since then I have taken that QUAD info and made a modified version,
and Steve has graciously granted me permission to share that derivative
work from his. For my part, I think the original reset problem just
doesn't matter much and am willing to accept it since I think it's
recoverable by just resetting again or at worst by issuing the
controlling poke actively, plus, I've never actually seen it happen. But
even beyond that, I also decided to simply remove the resistor-cap
resetter and just power all the logic at all times along with the ram,
so it never needs to reset. I also just accept the compatibility
limitation and just don't use one in the same machine with a REX. I
usually use rex image backups rather than ram banks anyway and the rex
is more useful than extra ram banks all in all. But I still wanted to
explore it just academically for the heck of it even if I don't use it
generally. You can look over that here:
https://github.com/bkw777/reQUAD
I wouldn't order any parts or pcbs immediately. I haven't built and
tested the latest version yet, but I do have the parts and pcbs for a
slightly earlier version that's only different cosmetically, same
circuit, so I'll throw one together and double-check it. It was about a
year ago the last time I played with this, other than just now putting
together the public stuff yesterday, so it's worth a verification.
Thanks again Steve.
--
bkw
On 8/21/22 19:13, Henner Zeller wrote:
On Sun, 21 Aug 2022 at 16:04, Stephen Adolph <[email protected]
<mailto:[email protected]>> wrote:
I guess I got the polarity wrong regarding A*.
Well,
I guess try what you like. In my tests, A* seems durable to output
shorting. I think I read the buffer datasheet to see what the output
short current is. Anyhow you see the issues.
I think the only way you see that there is a PSU discontinuity
coming is by monitoring /RAMRST. Which makes it hard if you are
back driving it. One could do it with a current monitor of some
kind, maybe
in M100 CP/M, the BIOS makes extensive use of the M100 main ROM. If
you disable and replace with RAM, you'd need to replicate all of
that ROMware to support CP/M.
Doable for sure. Why not just replace the optrom with RAM? leave
the main ROM alone.
The scenarios that drive the need for ram protection
1) battery runs out (or any other discontinuity) and PSU shuts down
via TRAP
2) user hits reset
3) program inadvertently shuts off the PSU (kinda the same as 1)
Thanks for your insights, Stephen! I'll play with the options.
It might take a while (too many projects :)), but if I run into issues
or have progress to show, I'll report back to the list.
Cheers,
Henner.
--
bkw
