[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [N8VEM-S100:976] i960 / V96BMC ~BLAST timing
Thinking some more about this S-100 80386 board..., I think we might do it
in 3 stages.
1. S-100 CPU board using RAM/ROM on the bus. Slow, many wait states but show
2. Add daughter static RAM board. Something like a 512KX32 bit RAM chips. We
don't not have to fill the board (at least not initially) but this would
allow us to configure the dual board system and check it out. Later this
board could be used as a cash RAM for the CPU.
3. The hard part is adding a third DRAM board. Hopefully in the
multi-megabyte range, GB if possible. All three boards would share a RAM
access bus over the top with a ribbon cable and connectors.
On the latter seems we are down to either the V96BMC or DP8330 types. The
DP8432V seems to have an upper limit of 64MG. Would like more if we are
going this route.
The later/higher capacity Controller chips all seem to call bro Burst mode
refresh. Unfortunately I don?t understand this area enough to know if that
can be used with an 80386.
John Monahan Ph.D
From: n8vem...@googlegroups.com [mailto:n8vem...@googlegroups.com] On
Behalf Of mike
Sent: Monday, July 16, 2012 12:12 AM
Subject: Re: [N8VEM-S100:976] i960 / V96BMC ~BLAST timing
-----BEGIN PGP SIGNED MESSAGE-----
Yes, looking at the basic access timing diagram in the V96BMC diagram they
show the ~BLAST signal remaining low for the duration of the transaction
whereas the i960 shows it rising after one PCLK. I would be willing to bet
that the V96BMC does not care about the rising edge, and that it's just
sampling at the second PCLK following the start of the transaction. I bet
for the 386 you could just tie it to ground to run in basic access mode.
On 07/16/2012 03:06 AM, Mike Sharkey wrote:
> Hmmm...I wonder if the B96BMC would be happy if you just left ~BLAST
> asserted (i.e. tied to ground) in the case of the 386? Or does it need
> to see it rise at some point? I would think perhaps not.
> On 07/16/2012 02:59 AM, mike wrote:
>> So looking at the i960 datasheet and the V96BMC datasheet timing
>> diagram, it appears that ~BLAST should be asserted before the rising
>> edge of the second PCLK. I understand the first PCLK to be the rising
>> edge following the assertion of ~ADS.
>> In any case I think the critical timing is that ~BLAST is asserted
>> before the second PCLK rising edge in order to indicate that is is
>> not a burst mode transaction.
>> On 07/16/2012 02:00 AM, mike wrote:
>>> Since the V96BMC was designed specifically for the i960 processor,
>>> it might be worthwhile to get the documents for that processor and
>>> study the burst mode vs non-burst mode transactions to determine the
>>> proper signal timing relationships.
>>> On 07/16/2012 01:50 AM, mike wrote:
>>>> Actually the basic access timing diagram in the one document shows
>>>> ~BLAST falling at the rising edge of the first PCLK and the other
>>>> shows at the first falling edge, so maybe PCLK is not the right
>>>> reference, perhaps it's relative to ~ADS?
>>>> In any case, it looks like the idea is that you assert ~BLAST
>>>> shortly after the beginning of the transaction cycle, and that
>>>> indicates that it is basic access I think.
>>>> On 07/16/2012 01:33 AM, mike wrote:
>>>>> My understanding is that the device is capable of doing burst mode
>>>>> or basic access mode.
>>>>> If you look at the timing diagrams that show basic timing vs burst
>>>>> mode timing it looks like to do basic timing you would have to
>>>>> come up with something that would simulate ~BLAST on the first
>>>>> falling PCLK at the start of a read or write since I don't think
>>>>> the 386 has a BLAST signal (i.e.
>>>>> does not have a burst mode).
>>>>> Don't take that to the bank, but that's my take on it so far.
>>>>> On 07/16/2012 01:11 AM, John Monahan wrote:
>>>>>> It looks like it only does "Burst mode refresh". Can
>>>>>> this refresh mode be done with the 80386. Are special
>>>>>> DRAM chips required. John
>>>>>> John Monahan Ph.D e-mail: mon...@vitasoft.org Text:
>>>>>> -----Original Message----- From:
>>>>>> [mailto:n8vem...@googlegroups.com] On Behalf Of mike
>>>>>> Sent: Sunday, July 15, 2012 8:47 PM Cc:
>>>>>> n8vem...@googlegroups.com Subject: [N8VEM-S100:962] V96BMC-33LP
>>>>>> - More documents
>>>>>> More documents on the V96BMC chip.
>>>>>> There is one document that covers programming the plain V96BMC
>>>>>> (not Rev-D) so only appear to be capable of driving 256MB DRAMs
>>>>>> but should be pretty similar. I'll continue to see if I can find
>>>>>> the programming data for Rev-D.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----