ATMEGA64A memory interface

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am planning on doing a Z80 project where I am going to have an ATMEGA64A be the I/O controller for the Z80.  I am going to use the flip flop method that I've seen a few others do where the IORQ signal from the Z80 will trigger the WAIT signal to give the AVR time to fire an interrupt and process the I/O.  An OUT instruction from the Z80 will be easy, just capture the low address (port) and data and release the wait.  An IN instruction is a little trickier in that the AVR has to provide the data by switching its pins to output, but ONLY long enough for the Z80 to capture them and then it must switch them back to input so there is no contention.  I've not tested it yet, but I'm hoping that:

 

port=data

cli

ddr=0xff

clear flip flop

ddr=0x00

sei

port=0

 

the distance between clear flip flop and ddr=0x00 is long enough for the Z80 to capture the data, but not long enough to be too slow to release the bus.

 

Well, anyway, I've selected the ATMEGA64A for this job and I was reading through the datasheet and noticed it HAS a memory interface.  I plan on having a 128K SRAM (lower 48K in two banks, upper 16K common for CP/M 3.1).  I plan on holding the Z80 in reset and accessing the SRAM directly so I can preload "ROM" into it at startup after doing a memory test.  I had planned on doing the SRAM interface bit bang, but I wonder if the built in memory interface is worth considering?  It looks like it shares the low address and data pins so that would be an extra component to latch the address I would think.  I'm thinking it may not be worth using, but I thought I'd see what you guys think.

 

And yes, I know everyone has done Z80 projects to death!  I think it is an interesting CPU and so I thought I'd do something with one!!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alank2 wrote:
I had planned on doing the SRAM interface bit bang, but I wonder if the built in memory interface is worth considering?
Yes

There are systems with two 8-bit MPUs by shared memory.

alank2 wrote:
It looks like it shares the low address and data pins so that would be an extra component to latch the address I would think.
Might be that simple though could implement by a cPLD (more functionality, just in case)

There are dual-port SRAM.

alank2 wrote:
I think it is an interesting CPU and so I thought I'd do something with one!!!
Some would concur with you as Z80 is still in production.

 


Cypress Semiconductor

Other Memories

http://www.cypress.com/products/other-memories

...

Dual-Port SRAMs

...

MoBL Dual-Ports

...

Integrated Device Technology, Inc. (IDT)

IDT

Multi-Port Memory

https://www.idt.com/products/memory-logic/multi-port-memory

Zilog

eZ80

https://www.zilog.com/index.php?option=com_product&task=product&businessLine=1&id=77&parent_id=77&Itemid=57

Features

The eZ80F91 Mini Enet Module, a member of Zilog’s eZ80AcclaimPlus! family, is a compact, high performance Ethernet module specially designed for the rapid development and deployment of embedded systems requiring remote control and Internet/Intranet connectivity. 

...

50MHz

Ethernet MAC

128KB external SRAM

256KB flash

8KB internal SRAM

RTC

32 5V tolerant I/O

3.3V

Zilog

ZGATE

https://www.zilog.com/index.php?option=com_product&task=product&businessLine=168&id=169&parent_id=169&Itemid=16026

Features

The ZGATE™ Embedded Security Firewall combines the eZ80F91 MCU and Zilog’s full-featured ZTP Embedded Internet Software Suite and TCP/IP Stack with a world-class embedded firewall.

...

https://www.digikey.com/products/en/integrated-circuits-ics/embedded-microcontrollers/685?k=ZGATE

 

Edits: Digi-Key, IDT

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Feb 22, 2018 - 05:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A sneaky method might be to have the AVR control the dma req to the z80, wait for the dma ack then enable the avr bus port. The avr can access a shared block of ram then disable the bus port and release the dma req. the avr can toggle a port bit hooked up to the z80’s int. Conversely, the z80 can address a port that tickles an extint on the avr.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is exactly the method I'm going to use Kartman.  I'm going to use a 74138 decoder to decode the A7/A6/A5/A4/IORQ/WR signals to set a flip flop that will assert BUSREQ.  This will trap 0xF0-0xFF and I don't care which port or the data it sends - all of it is too much of a pain to try to capture with the AVR given the timing.  Once BUSREQ is asserted and the OUT command finishes, the Z80 will go into HiZ mode and assert BUSACK.  I'll have the AVR determine that the flip flop has activated BUSREQ and wait for the BUSACK.  Probably it will already be asserted before the AVR can even test for it.  Once here, the AVR can take over the bus and do direct memory access for everything I need to get done.  I'm going to set aside a 32 byte windows at 0xFFE0-0xFFFF to be a communications window between the Z80 and AVR.  The Z80 will put a command at 0xFFE0 along with any parameters, pointers, etc., and then invoke an AVR transactions with the out 0xF0,0 statement.  The AVR will read 0xFFE0 and perform the command, transferring a disk block or out of memory, processing character I/O, etc. and then leave a return code and release the bus.

 

I did get the memory interface on the ATMEGA64A working beautifully.  I got a 73573 latch for latching the address lines using ALE.  One thing I didn't see covered in the AVR datasheet was how to handle the OE line on it.  I am guessing I am going to have to drive it with an I/O pin and turn it on when the AVR takes control of the bus and enables the external memory interface.  It is very fast and very convenient to access the external memory directly with pointers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you have the io decode fire an interrupt on the AVR, then the AVR can handle the busreq/ack. No f/f needed.
The oe on the ‘573 is normally tied low, so in order to release the bus, you’ll need to control it as you’ve said.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, so moving to a different SRAM 512K IC, the AVR memory interface is giving me fits.  I've tried a ton of things including dropping the clock speed to no avail.

 

I've got a thread over at eevblog with a logic capture, but no one is responding so far:

 

http://www.eevblog.com/forum/pro...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have bypass caps close to the AVR? You need to be aware that the logic switches fairly quickly, so there may be glitches your analyser doesn’t detect. You also need to be careful with your ground wiring so you don’t get ground bounce.

Last Edited: Sat. Mar 3, 2018 - 03:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It _is_ on a breadboard.  All GND/VCC connections on the AVR and SRAM have a bypass cap.  It fails in an oddly consistent way.  Reading a value that is NOT in the SRAM.  Even if the SRAM misinterprets any of the address lines, the value presented should be 1 of 2 values because of the way I am writing it and it comes up with something different.  You make a good point though, it may be time to get out the scope and start looking at signals to see what they look like.