> I'm still futzing about with this IIfx SIMM idea. I plan to use a
> pair of SN74ABT241A octal buffers to make the 16M X 4 chips look as
> if they have separate Din and Dout pins. And I planned to use the
> WE_ signal as the control to the buffers.
>
> However, it occurred to me that the computer might hold WE high at
> all times except during writes. This would leave the Dout path
> enabled almost all the time, which might interfere with other
> activity on the data bus.
It finally sunk into my brain what you are trying to do. Since I'm reading
this on cctech with its day or two delay, this has probably been covered,
but I'm sending it anyway.
The purpose of the separate Din and Dout is that the IIfx SIMMs latched the
write data so it could start the next read cycle before the write cycle was
complete, saving a cycle or two at 40 MHz. I'm not sure that your idea will
work for that. I think you'll need a tristate latch on the Din, maybe
latched with WE# and enabled by WE# | CAS#. Dout could be tristated to ~(WE#
| CAS#) | OE#. (if there is a separate OE#) There are a lot of caveats,
though. I'm assuming that there is never a R/W cycle. I'm also assuming your
DRAM outputs remain at high Z throughout a write only (aka "early write")
cycle regardless of the state of OE#. If your DRAMS support this you can
just ground the DRAM OE# and forget about it and just worry about when to
tristate your buffers. Also watch out for systems that use WE# and OE#
interchangably or mix them in funky ways. Your best bet is to study your
DRAM datasheets carefully.
It would be nice to have a IIfx timing diagram. I certainly don't have a
logic analyzer fast enough for this task....
Eric
>From: ard at p850ug1.demon.co.uk
>
>> 1) The RAS only, and Hidden Refresh cycles involve a Row address
>> supplied on the address lines. So, unless there's some undocumented
>> requirement that these address be supplied in a particular order, I
>> don't think that will cause a problem. However, I recognize that
>> sometimes datasheets (and documentation in general) assume general
>> knowledge about the topic. So if there is some implicit assumption
>> about the addresses supplied during a refresh, I'd appreciate someone
>> explaining it to me.
>
>I've never head of such a requirement, only that all 2^n states of the
>address lines are used within a certain time.
>
>The only issue is if only some of the address lines to the RAM are used
>for refresh, then you have to make sure those are kept together (but you
>can scramble their order, just as you can scramble the order of the ones
>not used in the refresh operation).
>
>-tony
Hi
This is what I was talking about with the A0-A6. You need
to see how many cycles are needed for refresh. This should
be in the spec. You need to determine how many address lines
are needed to complete that cycle. As an example. If it is
a 128 cycle refresh A0-A6 need to be grouped as Tony states.
If it is 256 cycle, A0-A7 need to be grouped and so on.
The cycles tells you how many addresses need to be cycled
through on a refresh to get all of the internal banks.
They always assume starting with A0 on to figure.
Between what Tony and I are saying, does it make sense??
Dwight
Hello all,
My latest "refocusing" of the collection is on IBM PC hardware
(PC/XT/AT, original IBM cards, peripherals, etc.) and on software IBM
sold for the PC line. In line with this, I'm also very interested in
any technical manuals IBM produced.
So far my meager technical manual collection is:
1. Guide to operations (PC, XT, AT)
2. Technical Reference (XT, AT)
3. Hardware Maintenance and Service (XT, AT)
All of the above are originals, and the AT Maintenance set includes
diagnostics from 1.01 to 1.05 along with loopback testers, and what
looks like a 10-BASE2 terminator (or maybe Arcnet??).
I'd like to get:
1. Technical Reference (PC)
2. Hardware Maintenance and Service (PC)
Original, copies, or scans will do ...
Also, I'm wondering what other technical manuals exist. I know there
is an "options and adapters" series, but what else is there?
Oh, and if anyone is junking a PC-1 (black power supply, 16-64KB
motherboard), I'll take it :-)
Thanks for pointers,
Rich B.
>
>Subject: RE: difference between LSI-11 CPU's M7264 and M7270
> From: "Gooijen, Henk" <GOOI at oce.nl>
> Date: Tue, 27 Sep 2005 17:18:41 +0200
> To: "'General Discussion: On-Topic and Off-Topic Posts'" <cctalk at classiccmp.org>
>
>
>Thanks, Frank and Allison.
>I guess, now is a good moment to start reading the LSI-11 handbook
>and to look out for a bootstrap kind of module ! Is there a specific
>module to look for, or are there several possibilities? Remember,
>this system only has 4 slots (almost 2 occupied), and I want to add
>at least modules to get some parallel I/O (TTL) lines, and to boot
>the system from (Pete Collum's RXV11) ...
Rev11 is available most commonly with RXV11/21 floppy boot and others
that exist for paper tape boot and maybe other disks.
It's not essential as a boot prom as most boots are small and uODT
can be used to hand load them.
>The idea that I have for this system is the following.
>I want to use a small 486 system as terminal and mass storage.
>The parallel I/O will interface to a filter-based RTTY demodulator.
>Software (to be written) will turn this setup to a telex reception
>station (transmitting RTTY will follow!) I know that many programs
>already exist for this (not on PDP-11), but I want to learn MACRO-11
>and learning a language goes best if you have an application idea.
>I expect it will not be difficult, after I learned the way MACRO-11
>wants its assembly text, because it looks quite like M68000 mnemonics.
>That will probably cause some pitfalls, but I must look up all the
>PDP-11 mnemonics in the beginning anyway.
RTTY can also be done with a serial line card. The only thing
is baud rate setting (external switch) for multiple rates. If you
can find a DLV11J (thats 4 serial ports on one dual width card) or
MXV11 (2 serial ports +ram +rom) that would save slots.
One thought, a M7270(KD-11F) OR M8186(KDF-11A) and M8047(mxv11)
will be a complete system on two dual width cards (cpu, 2 serial,
ram and eprom). It will need about 4A of +5 and under 1A of +12 power.
An alternate CPU is the falcon card M8063 (Kxt11 SBC11/21) which
also has ram, Eprom, two serial lines and parallel io with a Qbus
interface. Common as can be but rarely seen as they are often
embedded in larger systems (like a NC milling machine).
The above was typical of how LSI-11 series componenets were used in
embedded systems.
The instruction set for PDP11 is more regular than 68k and very
orthoginal CISC. Do read the various dec PDP-11 programming books
as it's a flexible machine and relocatable code is easy to do.
Allison
>Date: Mon, 26 Sep 2005 08:18:24 -0600
>From: woodelf <bfranchuk at jetnet.ab.ca>
>Subject: Re: SIMM, Address Lines Order?
>der Mouse wrote:
>>>When connecting DRAM chips to the pins of a SIMM (i.e. laying out the
>>>traces) does it matter if the order of the address and data lines is
>>>preserved? [...]
>>
>>
>> What about refreshes? (This is a question, not a challenge; I do not
>> know enough about how dynamic RAM refresh works to know whether this
>> really is relevant. But it seems to me that it might be.)
>>
>
>Just that all of them gets refeshed in the alloted time.
>Note they just have to be read for refesh. Still you better
>check the data sheets if you got them for the fine print.
I do have the data sheets. I am planning to use the KM44C16100 from Samsung.
Looking at the various refresh options in the datasheet:
1) The RAS only, and Hidden Refresh cycles involve a Row address
supplied on the address lines. So, unless there's some undocumented
requirement that these address be supplied in a particular order, I
don't think that will cause a problem. However, I recognize that
sometimes datasheets (and documentation in general) assume general
knowledge about the topic. So if there is some implicit assumption
about the addresses supplied during a refresh, I'd appreciate someone
explaining it to me.
2) During CAS before RAS refresh, the address lines are listed as
'don't cares'.
In other weirdness, I never saw the "der Mouse" reply to my posting,
so I checked the cctalk archives, on a hunch. There are several
replies to my posting in cctalk which never appeared in the cctech
digest or archive. Is this normal? How are the two lists organized
wrt each other? Does cctalk see all the cctech postings, but not
vice versa? It creates difficulties if folks on cctalk reply to
cctech postings by emailing to cctalk. Is it assumed that everyone
is subscribed to both? I am happy to adjust as necessary. I just
don't understand the arrangement, yet.
* Jim Battle frustum at pacbell.net writes:
> Burst mode DRAMs could be a problem.
I mis-wrote. These DRAMs have a Fast Page mode--not a burst mode. I
was mislead by discussion of burst reads in "The Guide to the
Macintosh Family Hardware" but I believe those burst reads are
between the CPU and the memory controller chip in the IIfx.
I should have written Fast Page mode, during which a Row address is
supplied with the RAS, then a series of Column address is supplied
while strobing the CAS for each change in Column address. Because
the addresses are explicitly supplied, I don't think that reordering
the address pins should cause any problems. A FP read will still
stay within the same page (row address) for a given DRAM chip.
> One last thing. There were DRAMs that used a different number of
>address lines
> for RAS than for CAS.
Good point. These are 12 X 12, 16M X 4 chips, so that should not be
an issue. If they were 13 X 11, I'd need to make sure that the upper
two address line orders were preserved?
> As a disclaimer, I have designed, implemented and shipped a number (10?) of
> DRAM controllers, both in TTL and in ASIC forms, but the most recent to ship
> was about 1991, so some details might have faded.
The computer for which I'm building the SIMMs was released around
1991, so there's a nice symmetry there.
* Allison ajp166 at bellatlantic.net writes:
> Tim Olmstead wrote a Z80 Dram interfacing manual
Google turned it up. Thank you for pointing it out.
* Dwight K. Elvey dwight.elvey at amd.com writes:
> Only that the first address lines that are used for refresh
> need to be grouped. As example for a 128 cycle refresh, that would
> be that one could mix any of the A0-A6 lines. This is because
> of how the blocks of RAM are accessed and then selected by
> a mux to the output.
Can you elaborate on this. I must be missing some key bit of
information about refresh. I get that 7 address lines are 128
addresses or blocks of RAM if one is just talking about Row
addresses. But how does that mean that some address lines can be
mixed and others not?
Is there a refresh mode where multiple blocks are chosen at one
time--where the upper address bits are defined, but the lower bits
are don't cares? That's not mentioned in the datasheet, but just
because it isn't mentioned, doesn't mean it isn't assumed.
I've been trying to find out which refresh scheme the IIfx uses, but
haven't found it in the limited documentation I have here. I have a
feeling I've read it somewhere...darn it.
Thank you for all the comments and help folks,
Jeff
In a message dated 9/26/05 8:02:30 AM Central Daylight Time,
cctalk-request at classiccmp.org writes:
> For a good example of HDPE, you need go no further than your wastebasket or
> garbage can--or the liner bag in a box of corn flakes. I've tried to
> mechanically polish the stuff, but it's soft and any abrasive is easily embedded in
> the surface and it tends to get "stringy" if it gets warm under the buffing
> wheel.
Have you tried Dow Scrubbing bubbles bathroom cleaner and a scotch pad? Spray
the cleaner on and let it set a few minutes , spray again then use scotch
pad.
Isa
These are local to me, eastern MA area. I'll contanct the owner to be
more definitive.
Allison
>
>Subject: Re: Available for pickup.
> From: Allison <ajp166 at bellatlantic.net>
> Date: Tue, 27 Sep 2005 10:23:26 -0400
> To: cctalk at classiccmp.org
>
>I take it that I can notify the owner that these systems are of no interest
>to anyone here. I cant take them, too much and too big.
>
>Allison
>
>
>>
>>Subject: Available for pickup.
>> From: Allison <ajp166 at bellatlantic.net>
>> Date: Mon, 26 Sep 2005 18:42:52 -0400
>> To: cctalk at classiccmp.org
>>
>>
>>I do not hold these but I've been asked if I want them.
>>
>>Allison
>>
>>
>>>I sent this earlier to arrl.org, but I thought I would also try here. These
>>>are free to the first taker, but that may be the rubbish man !
>>>Apollo 400
>>>Apollo 715s/50
>>>Apollo 715t/50
>>>(2) Apollo 715/64
>>>Apollo 400
>>
>>
If a tristate buffer is enabled by its control line, but the input to
the buffer is at high-Z is there a typical output?
I checked the relevant datasheet, but this situation isn't covered.
There's timing for when the buffer is enabled and the input switches
>from L to H or H to L, but nothing about the input at high-Z.
The truth table as written in the datasheet:
2OE 2A 2Y
H H H
H L L
L X Z
I need another row for
2OE 2A 2Y
H Z ?
Where OE is the control, A is the input and Y is the output.
I'm still futzing about with this IIfx SIMM idea. I plan to use a
pair of SN74ABT241A octal buffers to make the 16M X 4 chips look as
if they have separate Din and Dout pins. And I planned to use the
WE_ signal as the control to the buffers.
However, it occurred to me that the computer might hold WE high at
all times except during writes. This would leave the Dout path
enabled almost all the time, which might interfere with other
activity on the data bus.
Once CAS goes high, the Dout of the DRAM chips would go back to
high-Z, so the computer designers would figure, leaving WE_ high most
times is fine. DRAM output is high-Z unless one just did a read with
a CAS signal.
But if I'm feeding the DRAM output into a tristate buffer this might
not work. The high-Z from the DRAM goes to the buffer as input. The
WE_ signal enables the buffer. What comes out the other end of the
tristate buffer onto the data bus? If the buffer drives the data bus
in this situation, then this won't work.
I really don't want to add an AND gate and an inverter so I can
change OE for the tristate buffer to WE*CAS'.
Of course, if WE_ is floating most of the time, it's not a problem.
I just lightly tie OE to GND and when WE floats, the buffer outputs
go to high-Z. But I can't count on that.
Run off a set with spaces for all the possible control signals I can
imagine and experiment?
Jeff Walther
