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

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 list