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

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.

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