I am looking for an article that contain the project listed below. Grateful if any one could find the article.

http://www.acornatom.nl/sites/fpga/www.howell1964.freeserve.co.uk/projects/dram_6502.htm

The author was K. Howell and I believe he is from Holland.

It was about interfacing 64K DRAM to 6502.



Allen

 

Back in those days when high capacity SRAM was not available you had no choice but to use DRAM.
Why not use SRAM now instead of DRAM?
I can show you how to interface to SRAM.

 

Thank you so much Mr Chips for your offer.

But my purpose is not so much to use the 64K memory with the 6502 for any practical reason, but to understand how to interface, and get all the timings correct. Whether it is 64K x 8 or 16K x 1 bit both would be OK.

At first, I was thinking of using 8051 SBC with 16K epROM, 16K SRAM. Then using one 4116 DRAM addressed as $8000-BFFF with only one bit connected to the data bus. Then I would write a test program in asm to write 16Kbit of 1/0 patterns to the D0 of all the DRAM addresses. Then read them back and compare them with the test patterm.


If they are the same, which means that my interface is working correctly.

I wanted to do this since 2000. It was my dream to be able to full-fill it.

After reading the article in PIC List. I begin to see the possibilities of using a shift register HC164 with a higher clock signal (compared to the CPU clock) to clock the S.R. to get all the timings and a counter to do the refresh. I was about to start designing based on that article and I found this simple interfacing scheme with the 6502. So I think why not start with this simple one first and that's how I start looking for the schematics of this article in the ETI magazine.

Presently, I have a few boards of 4027 DRAM, lots of 4116, a few 4164 and 4464. Plus about 10 strips of SIMM FP DRAM. SO if my interface fails and destroy some of the chips, that's OK too. After all they dont cost anything now.

Allen

 

I have labelled all the chips and if I couldn't find the schematics. I'd have to reverse engineer from this picture to a reasonable schematic.



Allen

 

Before you embark on this exercise you ought to seriously consider the following things.

1) The basic microprocessor bus consists of address, data and control signals.
2) There are two different flavours of legacy buses - Intel bus and Motorola bus.
3) Data bus may be multiplexed or non-multiplexed. A multiplexed data bus means that data bus carries both address and data.
4) Assuming you are doing this just to learn how buses operate, interfacing to SRAM would be the simpler exercise.
5) You are not likely going to damage the chips if you get it wrong. The worse is it wouldn't work.
6) Before you build the memory interface you ought to choose the microprocessor chip, e.g. 8051, 6502, 6800 etc.
7) What you really need to examine is the timing specifications of the chosen microprocessor.
8) Could you not learn in theory how interfacing work by looking at examples rather than actually building it?
9) Assuming you really want to build this, how are you going to get the program code written and uploaded into memory?
10) In reality, modern microcontroller chips make interfacing to memory and peripheral chips obsolete. On a single chip you can have every conceivable memory and peripheral function you can imagine. Knowledge of how buses operate is good to have, similar to knowing how the circuit of a 7400 NAND gate works. Where are you going to apply this knowledge in the future?

Learning the theory is great. Move on to doing something practical with more modern technology,

 

Before you embark on this exercise you ought to seriously consider the following things.

1) The basic microprocessor bus consists of address, data and control signals.
2) There are two different flavours of legacy buses - Intel bus and Motorola bus.
3) Data bus may be multiplexed or non-multiplexed. A multiplexed data bus means that data bus carries both address and data.
4) Assuming you are doing this just to learn how buses operate, interfacing to SRAM would be the simpler exercise.
5) You are not likely going to damage the chips if you get it wrong. The worse is it wouldn't work.
6) Before you build the memory interface you ought to choose the microprocessor chip, e.g. 8051, 6502, 6800 etc.
7) What you really need to examine is the timing specifications of the chosen microprocessor.
8) Could you not learn in theory how interfacing work by looking at examples rather than actually building it?
9) Assuming you really want to build this, how are you going to get the program code written and uploaded into memory?
10) In reality, modern microcontroller chips make interfacing to memory and peripheral chips obsolete. On a single chip you can have every conceivable memory and peripheral function you can imagine. Knowledge of how buses operate is good to have, similar to knowing how the circuit of a 7400 NAND gate works. Where are you going to apply this knowledge in the future?

Learning the theory is great. Move on to doing something practical with more modern technology,

I suspect it is a personal endeavor, not a professional one. The only goal is the design and building itself.

 

From my limited knowledge of DRAM, it seems that you may need a DRAM controller for the periodic refreshing of the memory cells in the DRAM in order not to tie down the microprocessor. A small fpga or a cpld could do this but it isn't really necessary unless if you are planning to combine the system with a video and sound system.

Many homebrew systems employ an SRAM based system due to the more direct nature (only read and write) and does not include the periodic refreshing.

 

8) Could you not learn in theory how interfacing work by looking at examples rather than actually building it?

In theory, he could.

 

Before you embark on this exercise you ought to seriously consider the following things.

1) The basic microprocessor bus consists of address, data and control signals.
2) There are two different flavours of legacy buses - Intel bus and Motorola bus.

Both the processors (6502 and 8051) I've chosen to use have Address, Data and control bus.
I think both 6502 and 8051 use memory mapped IO, the 8051 address and data lines can be extended to the outside.

3) Data bus may be multiplexed or non-multiplexed. A multiplexed data bus means that data bus carries both address and data.

The 6502 data bus is not multiplexed. But the 8051's lower 8 bit address is muxed with the data bus. Would that be a problem?

4) Assuming you are doing this just to learn how buses operate, interfacing to SRAM would be the simpler exercise.

I am doing this as an nostalgic exercise. I dont think there is any commercial values after I complete this project. As for the SRAM interfacing the 8051 and 6803, I have tried them before and there is not much problems for me .

5) You are not likely going to damage the chips if you get it wrong. The worse is it wouldn't work.
6) Before you build the memory interface you ought to choose the microprocessor chip, e.g. 8051, 6502, 6800 etc.

That's a good news and I think I made the right choice on the mpus.
Presently I have 6502, 8051, 8085, 6803 and 6809 and 68000.

7) What you really need to examine is the timing specifications of the chosen microprocessor.

That is what I am trying to learn

8) Could you not learn in theory how interfacing work by looking at examples rather than actually building it?

I have the Apple II hardware description manual, the whole clock timing section was so complicated. It has to take care of the video timimg, refresh of DRAM as well as the MPU A & D bus timing. I have a hard time understanding it. That's why I am searching for this simple project that just interface to the DRAM with only a few chips.

9) Assuming you really want to build this, how are you going to get the program code written and uploaded into memory?

That's quite true. That's why my block diagram in post#3 has ROM and SRAM on the lower 64K and the DRAM is on the upper 64K memory. Would it work if I only use 1/4 of the 4464 chips?

10) In reality, modern microcontroller chips make interfacing to memory and peripheral chips obsolete. On a single chip you can have every conceivable memory and peripheral function you can imagine. Knowledge of how buses operate is good to have, similar to knowing how the circuit of a 7400 NAND gate works. Where are you going to apply this knowledge in the future?

That's quite true. But as I said I just wanted to have fun and learn what I missed long ago. My friend wanted me to do IoT projects with him and he got really mad when I turned him down.

Actually it is the older things that I wanted to do and only read about the newer thing.

Allen

 

From my limited knowledge of DRAM, it seems that you may need a DRAM controller for the periodic refreshing of the memory cells in the DRAM in order not to tie down the microprocessor. A small fpga or a cpld could do this but it isn't really necessary unless if you are planning to combine the system with a video and sound system.

Many homebrew systems employ an SRAM based system due to the more direct nature (only read and write) and does not include the periodic refreshing.

I am quoting from the article

There are various ways to refresh DRAM, most of which are quite complex. Texas Instruments made the TMS4500 DRAM controller (a 40-pin chip in itself) which would make the CPU wait if a refresh cycle was in progress. The Z80 helped by having a 7-bit refresh row counter. Neither of which is very useful to the 6502 which does not support wait states.

The 6502 does have one significant advantage: the memory access cycles are very regular. The 6502 has a single clock output with a 50% duty cycle. If the memory is fast enough, it is possible to use the last half (clock high) for CPU access, and the first half (clock low) for something else.

I dont have the TMS4500 DRAM controller chip but I do have the DP8409 from National Semiconductor. It is a 48 pin chip and I think it is too big for this project.

I have bought some CPLD and just started to use VHDL to program the chips. If I am successful with this interface project, I'd put the interface into the CPLD chips.

Allen

 

Ok, let's suppose you want to do this for nostalgic reasons. I don't have a problem with that. Even better yet if you have a sound practical reason for doing it. A good example would be building an audio amplifier entirely using vacuum tubes.

On the other hand, I would not want to attempt to build even a digital clock, much less a computer, using discrete transistors.

So you say you can understand how to interface to SRAM. That is relatively simple compared to working with DRAMS. For DRAMS, you need to consider refreshing mechanism and circuitry. Personally, I would not have the slightest incentive to want to use DRAMS.

For nostalgic purposes, I would rather go down the μP memory lane and rework a classic μP SBC (single board computer) design. Hence I would be focusing on the choice of μP. It would not be a difficult choice for me to make. MC6809 would win hands down.

My second choice would be a MC68000 design. The MC68000 has much more power and capabilities than the MC6809.
MC6809 wins with its elegance and simplicity. I have created SBC for both MC6809 and MC68000.

If this is what you want to do I would be very happy to contribute to such an exercise.
But I would not be using DRAMS. I am not a masochist.

(My MC6809 project consisted of a floppy drive interface and graphics output to a CRT display about a few months before the Apple Macintosh was launched. I canned the project and bought my first Macintosh for $3500. The rest is history.)

 

IoT project? Now you're talking.

My Omega2 kit just came in this week and I just can't wait to get into some serious hacking!

 

The CPU address and refresh row counter multiplexing was done by two LS257 chips on the CPU side, and an LS244 tristate buffer to an LS393 binary counter on the other.

So I assume it should be connected like this....

The output of LS257 can be tri-stated by controlling the /OE input so it should be able to share the addresses of DRAM with the LS244 buffers. Am I correct?



But then it says...

When using 16Kx4 bit chips, take care that the most significant address lines A14 and A15 multiplex into the row on MA0 and MA7 respectively. The 16Kx4 bit RAM chips use an 8-bit column address but only 6-bits of row address (from MA1-6). This precaution will ensure easy upgrades from two 16Kx4 to two 64Kx4 chips.

What should I do to correct this?

Allen

 

IoT project? Now you're talking.

My Omega2 kit just came in this week and I just can't wait to get into some serious hacking!

My friend started IoT with the Rasberry Pi and ESP8266 breakout boards. He even bought one more of the later RPi with more memory and USB ports.

[Oops, I have deleted all the pics he sent to my phone]

Allen

 

Ok, let's suppose you want to do this for nostalgic reasons. I don't have a problem with that. Even better yet if you have a sound practical reason for doing it. A good example would be building an audio amplifier entirely using vacuum tubes.

I have done that in 1972. Before that my friend and me made a Guitar Bass Amplifier totally out of tubes. My tube amp was using 7189A output tubes; it is still inside a box in my study room upstairs. Nowadays, it is getting very difficult and expensive to get new tubes and output transformers. I have lost all my tubes in the years and now my tube amp. is without the 7189 push pull o/p tubes.

So you say you can understand how to interface to SRAM. That is relatively simple compared to working with DRAMS. For DRAMS, you need to consider refreshing mechanism and circuitry. Personally, I would not have the slightest incentive to want to use DRAMS.

Yes, I'll treat that as a challenge too. May be it's time to get out my scopes that were collecting dust.

Actually I wanted to do a "4 bit cpu out of discrete chips" called the Nibbler. After that I would follow the MSP430 launcher series mini-projects in your blog.

For nostalgic purposes, I would rather go down the μP memory lane and rework a classic μP SBC (single board computer) design. Hence I would be focusing on the choice of μP. It would not be a difficult choice for me to make. MC6809 would win hands down.

My second choice would be a MC68000 design. The MC68000 has much more power and capabilities than the MC6809.
MC6809 wins with its elegance and simplicity. I have created SBC for both MC6809 and MC68000.

I have all the chips but lack the knowledge to tackle such a huge project like that. I did the 1802 cosmac elf project with the help of Lee Harts. He sold me the 1802 CPU and the SRAM chips used in the COSMAC. I have the orignal display LED from the condemned MFC machine used in our ARF Xbar Exchange.

If this is what you want to do I would be very happy to contribute to such an exercise.
But I would not be using DRAMS. I am not a masochist.

(My MC6809 project consisted of a floppy drive interface and graphics output to a CRT display about a few months before the Apple Macintosh was launched. I canned the project and bought my first Macintosh for $3500. The rest is history.)

Did you take any photos of your 68K SBC? How were all the wiring done? Customed PCB or Wire Wrapping? Where to get the sockets for the 48 pin DIP for the 68000? Actually I preferred the 68008 which is like 8088 to the 8086.
It's nice to see how some Historical SBC were made in the '80s....

Allen

 

I think I must have covered the whole gamut of the microcomputer revolution, from the COSMAC 1802, 6502, 6800, 6809, 6805, 68000, 68008, Z80, 8085, 8086, 8088.
As for the 1802, 6809, 68008 SBC, I think I still have the boards and documentation somewhere.
As I said, pick a μP and we can work on it together. I would narrow it down to 6809 or 68008.
Mind you, 68HC11, 68HC12, 9S08, MSP430, Atmel AVR would all be good candidates in my scheme of things to learn about MCU technology.

 

I have labelled all the chips and if I couldn't find the schematics. I'd have to reverse engineer from this picture to a reasonable schematic.

Cool project. I could not find the original ETI article either. Here is an earlier ETI article with 4164 that may be of help..this one is a little simpler (also see the pages it came from) and also uses 4164 ...and of course the hardware manual. I confess that I am confused about why the entire address space would be mapped to dram, but I don't know.

Hope it helps.

 

So I assume it should be connected like this....

As far as refresh goes, the '4464 has the refresh counter built in. You do this by sending a /CAS-before-/RAS control sequence. See page 14-581 of the attached data sheet for more details.

I once did a MC68000 (maybe it was a MC68008) that used an interupt to do the refresh. The 68000 could do a write of all of its registers to memory in one instruction. This would save all 64 registers which caused 64 sequencial accesses to memory. I had to do several register-save instructions to get the entire memory refreshed.

The trick that the Apple][ did was to map the graphics into the DRAM so that the normal accessing of the graphics data kept the memory refreshed. The 6502 accessed that RAM during one phase of the 2-phase clock and the graphics accessed the RAM during the other phase.

 

From my limited knowledge of DRAM, it seems that you may need a DRAM controller for the periodic refreshing of the memory cells in the DRAM in order not to tie down the microprocessor. A small fpga or a cpld could do this but it isn't really necessary unless if you are planning to combine the system with a video and sound system.

Many homebrew systems employ an SRAM based system due to the more direct nature (only read and write) and does not include the periodic refreshing.

Most manufactured computers of the era had a DMA chip that handled all the refresh timing and interleaving read/write cycles.

 

Hello,

Wich number are you looking for?
http://www.americanradiohistory.com/ETI_Magazine.htm

Bertus