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