On 08/01/2012 08:35 AM, HÁRSFALVI Levente wrote: > On 2012-07-31 18:00, Gerrit Heitsch wrote: >> >> The extra logic will have to detect $4000-$7fff (A15 low, A14 high), >> disable the internal RAM in that range by brute force and generate _CAS >> for the external RAM. > > Well, first, the extra bank would have to be mirrored at $c000-$ffff > (otherwise, writes to $fffc...$ffff end up at $3ffc...$3fff instead of > $7ffc...$7fff which causes problems on a supposedly 32k-spec machine). Unless you kill _CAS for everything that is not $0000-3FFF. Then there would be no RAM underneath the ROM and no mirroring. Then you use A15 low / A14 high to enable the module. Not sure if that would cause a problem, never tried it. > That makes A15 redundant, and incorporating CAS' (the TED's CAS', that > is) a must. IMHO this is, where things start getting tricky. > > That said, I don't know how it's actually done. > > One possibility is to store CAS' first, "kill" it if CAS'(stored) is low > and A14 is high, supply CAS'(stored) to the expansion ram; (and > obviously do neither if A14 is low). Then clear flip-flop by the rising > edge of RAS', MUX', or any arbitrary self generated signal. Something > like this might be suggested by the presence of the 74ls73 J-K > flip-flop. Yes, but the thing is, only one of the two has a 74LS73 on board, the other one seems to achieve the same result with a 74LS00 (4 x NAND) and a 74LS133 (on 13 input NAND) plus some diodes. > Problem is, an inevitable glitch on CAS' before the CAS' > killer is activated. I haven't checked whether that's problematic, > according to jedec ram spec. Regardless to that, it seems to be ugly. The datasheet for the MB81416 says that CAS has a minimum pulse width of 75ns (for the 150ns part) and since CAS also controls the output drivers, a short enough glitch might not cause any problems. Still a very dirty hack. >> Well, the C16 and C116 used only TMS4416 DRAMs (at least all I ever >> seen), so you only had to find a batch of DRAMs, maybe from a different >> maker that has better output drivers and can override the internal RAM. >> I can see no other way since the multiplexer will only supply the >> multiplexed addresses, there is no _CAS generator, no resistor to force >> _CAS high and they didn't do SMD back then, so there is no hidden logic >> on the back. > > First, we seem to have an exception here (the C116 board I used for the > tests uses HM48416AP-12 ie. Hitachi drams, datecode 8432). Hm, OK... another theory shot to hell... Not all 16Kx4 DRAMs were compatible with the refresh supplied by TED, the Hitachi obviously were. > As for the memory expansion logic: I'm still a little bit reluctant to > believe that they just let 8 data lines to fight all the time in any > arbitrary dram cycles. (That must be a lot of current at the first > place, and second, we're still talking about NMOS dram chips that > supposedly have much weaker H than L drivers; that is, whichever the > type, the dram which stores 0 bits should probably win). But I'm not > sure, that is, until someone checks one of these expansion modules closely. I see no other way than to have the drivers fight it out with what's on the board. Unless the installation manual had you remove a signal from the internal RAM (like _CAS or _OE, assuming the RAM interprets the open input as HIGH) prior to installation. I remember the first 64KB expansion from Kingsoft, that one went into the TED socket (which made it easy to intercept _CAS and disable the original RAM) and back then it was considered impossible to do a 64 KB expansion on the expansion port without removing the internal RAM. Gerrit Message was sent through the cbm-hackers mailing listReceived on 2012-08-01 15:00:09
Archive generated by hypermail 2.2.0.