I think A* is on the system bus for exactly this purpose. /RD and /WR are both there, so why bring out RDWR?
Other memory products used this like to disable internal ram. On Sun, Aug 21, 2022 at 7:04 PM Stephen Adolph <[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) > > > > On Sun, Aug 21, 2022 at 6:02 PM Henner Zeller <[email protected]> wrote: > >> On Sun, 21 Aug 2022 at 14:16, Stephen Adolph <[email protected]> >> wrote: >> >>> Henner, >>> I have taken both approaches. >>> I have a few comments: >>> >>> 1) RAMRST serves to protect RAM during power events. So, I think you >>> can for sure use it to disable the internal ram, but then you need to take >>> some precautions on whatever RAM you add. I don't think it's purpose was >>> to disable ram for any other reason than protection. RAMRST is switched >>> using a number of different conditions, including auto-power down. I >>> don't have a good recommendation on such a protection ckt. >>> >> >> My intent is to replace the RAM entirely as I have a machine with not >> full 32k, and I also intend to make the lower 32k writeable (makes it >> simpler to write a new operating system and possibly run CP/M; I think >> you're running CPM successfully on your machine with a trick like this ?). >> I'd have to make sure that memory is preserved on power down of course. >> Besides losing power and memory in the external RAM, are there other >> conditions you can think of that might be problematic ? If I set RAMRST I >> would have to detect power-down/halt situations in a different way, but >> given that ~RESET is just the inverted signal of RAMRST and I get it at the >> bus as well, this should be doable. >> >> Reading again page 4-13, RAMRST seems to be indeed more meant to tell an >> external RAM module to be enabled/disabled, _not_ that it can/should be >> manipulated, which was my initial hopeful reading >> (in fact, on 4-12, RAMRST is marked as output, i.e. input to the external >> module). >> >> 2) A* can be pulled high. This has the effect of killing the chip selects >>> to the ram modules. This is more "painful" but it can be done. You could >>> for example add a switch and control which RAM you want to use. I would >>> recommend using a RAM with 2 chip selects, and then using RAMRST to >>> protect the secondary ram. >>> >> >> mmh, A* (or RDWR* as I like to call it as it is better describing what it >> means. Apparently they ran out of ideas back in the day, and thought "Ⓐ*" >> is the best way to describe the signal...), is the output of the M20 >> (40H367) buffer, so pulling that low to disable the M3 and M4 chip selects >> would put a strain on the output buffer transistors, risking damaging a 40 >> year old chip. >> >> So looks like both methods are essentially fighting output of some >> transistors, though I think I'd be more comfortable doing that to a >> discrete T9 than to an output stage in a buffer chip. WDYT ? >> >> (Note, I have not wired up anything yet to my bus, still in planning >> stages, so I might miss things; and you certainly have a lot more >> experience with these machines). >> >> -h >> >> >>> I would recommend manipulating A* at the system bus. >>> >>> Steve >>> >>> >>> >>> On Sun, Aug 21, 2022 at 4:56 PM Henner Zeller <[email protected]> wrote: >>> >>>> On Sat, 20 Aug 2022 at 14:44, Henner Zeller <[email protected]> wrote: >>>> >>>>> Hi, >>>>> I enjoy playing with my new/old T100 and want to start doing some >>>>> hardware hacking with its system bus. >>>>> >>>>> According to the docs, REXCPM can disable >>>>> <https://bitchin100.com/wiki/index.php?title=REXCPM#Overview> the >>>>> built-in RAM and shadow the internal ram with its own banked RAM. Since I >>>>> consider doing some RAM banking without pulling out the original RAM or >>>>> sneaking in an extra wire or resistor and wondering how that can be >>>>> achieved. >>>>> >>>>> It would mean that we need to switch off the internal RAM. But looking at >>>>> the schematic <https://github.com/hzeller/trs80-100-schematic>, it >>>>> looks like options would be to >>>>> >>>>> * Either make sure that none of the chip enable signals for the RAM >>>>> ever go to zero, but they are under control of M3 and M4 and this looks >>>>> infeasible >>>>> * We could force pull the RAMRST signal to high, but I suppose that >>>>> would make transistor T9 not very happy. So also not feasible >>>>> * The option that I missed :) >>>>> >>>> >>>> To answer my own question: pulling RAMRST is indeed what needs to be >>>> done and it is intended for that purpose. >>>> The service manual states it on page 4-13. >>>> >>>> Measuring, it turns out that pulling up RAMRST to VDD only takes about >>>> 1.2mA, so the transistor T9 will not have trouble with it. >>>> >>>> -h >>>> >>>>>
