Interfacing a 68000 to RAM

dwight elvey dkelvey at hotmail.com
Tue Jun 2 10:46:14 CDT 2009




----------------------------------------
> Date: Tue, 2 Jun 2009 10:18:33 -0400
> Subject: Re: Interfacing a 68000 to RAM
> From: ethan.dicks at gmail.com
> To: cctalk at classiccmp.org
>
> On Tue, Jun 2, 2009 at 9:53 AM, dwight elvey wrote:
>> Hi
>> Thanks for the pointers guys. I should have given more information.
>> It is SRAM and it is fast SRAM 55ns. It is a real 68000 8MHz.
>
> OK... that RAM is plenty fast enough, but you also need to ensure any
> memory-mapped peripheral I/O chips are also fast enough if you want to
> ground DTACK. We had 4MHz 8530 UARTs, so we _had_ to use DTACK in the
> "expected" way.
>
>> It seens that most seem to prefer the DTACK method over the synchronous one. Is faster or just more versitle?
>
> Simple designs can ground DTACK, more complex designs tend to use
> DTACK normally, especially to be able to use less expensive memory.
> These days, if I were building a 68000 design, I'd look at fast memory
> and fast I/O chips and just do it in the simplest way possible - when
> you ground DTACK, what you are doing is telling the CPU that at the
> time in the cycle that it would check (and wait on) DTACK, the
> transfer has already happened (Data Transfer ACKnowledge) - the CPU
> doesn't have to wait _ever_. In a mixed-speed design, if some
> component is fast enough, DTACK will be grounded at that point in time
> anyway, but through handshaking, not because it was permanently tied
> to ground.
>
>> What I'm doing is to try to find the best way to connect
>> to my Canon Cat....
>> There are 2 empty 28pin locations that were intended for ROMs
>
> Are you trying to do ROM development? Why not use a plug-in ROM
> emulator? (I like the PromICE, but it's made by someone that I've
> known and worked with, starting 25 years ago, so if you have a
> favorite or get one for free, by all means, use it). You don't have
> to do any target-machine hacking - you get a rig that matches your
> target (28-pin cables, 24-pin cables, 32-pin cables, 256Kx8, 128Kx16,
> whatever) - and the PromICE is somewhat configurable in that respect -
> then compile the code and download it. It could be tricky if you need
> the target machine to compile your code because of the tools needed,
> but you could have the Cat make the code, transfer it to another
> machine via serial port or network, then keep ROM images on the other
> machine so you can try new code and revert back to working code if you
> compile up a dud.
>
> I would hesitate to make recommendations on how to hack into an
> existing design without schematics in front of me, but if all you are
> trying to do is get writable ROMs, I'd seriously recommend a ROM
> emulator that's externally loadable (built or bought, makes no
> difference there).
>
> -ethan

Hi Ethan
 I still need to figure how to get the 256kb of RAM into the
Cat memory.
 I wasn't thinking of tying the DTACK low, just adding another
O.C. drive on the wire when decoding my new address space.
 Most all of the circuits are inside of ASICs so there isn't
much other than wires to and from the CPU. Just think of
CPU, Black-Box then everything else. The Cat does use both the
DTACK and the VPA lines. I think the VPA is used for the
serial chip.
 The CPU doesn't hang when accessing invalid memory so maybe
the ASIC is generating DTACKs, even for invalid memory. In
that case, all I need is address decoders.
 I was thinking that the extra ROM decode might work but
thinking about proper design, they'd have put R/W in the CE*
signal. If so, I can't use it.
 Dwight
 
_________________________________________________________________
Windows Live™: Keep your life in sync. 
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_BR_life_in_synch_062009


More information about the cctech mailing list