Re: external ram expansion modules for 16k 264 series machines

From: Imre Széll <iszell75_at_gmail.com>
Date: Thu, 2 Aug 2012 21:08:52 +0200
Message-ID: <CAHFX3ZNunx8hnM5PN01o8u-4iHH5rVC6csYH0HCZOKd_4PSz=Q@mail.gmail.com>
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 list
Received on 2012-08-02 20:00:05

Archive generated by hypermail 2.2.0.