2012/8/2 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> > On 08/01/2012 10:41 PM, HÁRSFALVI Levente wrote: > >> >> On 2012-08-01 16:49, Gerrit Heitsch wrote: >> >>> >>>> 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. >>> >> >> The problem is the original design relying on ram to be present in the >> whole 64k address space. (That is, 4 mirrors of 16k, 2 mirrors of 32k >> and obviously 1 single page of 64k on 16k / 32k / 64k machines >> respectively). >> >> The Kernal's memory size calculator routine (which is called as a step >> of the reset sequence) actually works by checking whether a sequence of >> bytes, written to somewhere above $ff40, gets mirrored above $7f40 and >> $3f40 (resulting in 28661 or 12277 bytes free for Basic, respectively - >> or 60671 if there was no match). >> >> Also, ram needs to be mapped to $fffc...$ffff in any case (else, there'd >> be no way to set the IRQ and Reset vectors with ROM mapped off, which >> kills backwards compatibility; defining custom IRQ and Reset is >> frequently done by games capable of running even on the stock 16k >> machine). >> > > We also need to exclude I/O space ($FD00 to $FEFF?) and the TED registers > ($FF00 to $FF3F) from the RAM mapping. I assume that's where the 13-input > NAND on one of the boards comes in handy. Usually TED does this decoding. > You don't have to do that for yourself: the PLA handles the I/O space (from $fd00-$ff3f) > > I also did find a signal that might help though... _CS1 from TED is > available on the expansion port. As long as this one stays high, TED does > RAM cycles (or I/O) on $C000 to $FFFF, as soon as it goes low, the ROM in > the same range will be accessed. > > So as long as A14 = high and _CS1 = high, _CAS for the internal RAM needs > to be killed. This way we avoid the glitches. If either of them goes low, > it's either ROM access or a different RAM block which means the expansion > RAM must not see a valid _CAS and the internal RAM will get a normal _CAS > signal. > > So all we need now is a way to generate our own _CAS for the external RAM. > That should be possible with a slightly delayed MUX-signal. > > (You should really open your module :)) > > > > > 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. >>> >> >> Haven't known about problems concerning 16k*4 rams vs. TED memory refresh. >> > > Ok... I wasn't quite clear... The 16Kx4 DRAMs are a bit strange. The row > address is 8Bit (and TED does an 8Bit refresh). To get the full 16K, you > then need a 6 bit column address. Those 6 Bit are not supplied on A0 to A5 > but on A1 to A6 to the DRAM. The multiplexer wiring reflects that and that > explains why you had to run A14 and A15 to different multiplexers when > doing the 64K expansion. > > The problem is, not all 16Kx4 DRAMs use this mapping, others expect the > column address on a different pin range. So far I found the following 16Kx4 > DRAMs to be usable: > > TMS4416 (needs 8Bit refresh) > M5M4416 (needs 7Bit refresh) > MB81416 (needs 7Bit refresh) > > > > > I seem to remember problems that you're talking about (having to modify >> the machine in order to get an external memory expansion module to work >> and such). Never seen that in practice, though. Most (all) machines I've >> seen so far were either stock 16k machines, or internally expanded >> machines (using either 64k*4 bit rams or a bank of 4164s on a >> daughterboard). >> > > Interesting idea to use 4164... Never occured to me since 64Kx4 DRAMs were > hard to get, but you could find them if you looked in the right places. > Nowadays 1st generation VGA cards are a good source if one needs > replacements. > > > > They don't mention the >> suggested remedy of incompatibility problems, ie. cutting some traces on >> the mainboard. (They do list, however, the overall current consumption >> of the stock machine, the internally expanded machines, and stock >> machine + external modules, which might possibly be interesting; it's >> 762mA, 778mA, 878mA, 904mA, and 958mA, respectively (...although, we >> don't know anything about the internals of these expansion modules)). >> > > That's cutting it mighty close with the original power supply and internal > regulator... BTW... My C16, using 53C464 DRAMs and CMOS EPROMs instead of > NMOS ROMs together with a 1.5A RECOM regulator is down to around 400mA on > the regulator input. > > > > I've just set up some triggers so that I'd know whenever one of the >> "simple" memory expansion modules pops up at some auction sites. We'd >> just need to know that detail someday... at least, I'm eager to know that. >> > > So am I... > > Gerrit > > > > > Message was sent through the cbm-hackers mailing list > Message was sent through the cbm-hackers mailing listReceived on 2012-08-02 20:00:05
Archive generated by hypermail 2.2.0.