74HC670 4x4 Register File IC Info'?

[Michael]

I'd like to add an MMU to my design using a 74HC670 "4x4 Register File" IC and I'd like to go straight to a PCB but I'm uncertain about writing to the IC and I'm not in a position to breadboard a 'test' circuit. It seems the write side of the chip is something like a transparent latch that latches on the rising edge of the /WE signal. My question is; can I use an IO strobe by itself (see below) which probably lasts a bit longer than the falling edge of PHI2 or will I need to combine the shorter clock-qualified /WR signal with the IO strobe? Also, if there's a better way to implement a simple MMU, please feel free to share.

TIA. Cheerful regards, Mike

[barnacle]

I can't speak with authority - I've looked at the '760 in the past but never used one - but my suspicion is that you would need to qualify with PH2. I suspect that otherwise, the latch on the rising edge could arrive too late to guarantee stable data; I think you might otherwise be relying on bus capacitance to hold the data.

Neil

[Dr Jefyll]

Oooo! -- the '670!

It's a delightful little nugget of Solution, apt for a surprising variety of Problems! And this includes memory mapping arrangements. (I wrote about the '670 here.)

Quote:

It seems the write side of the chip is something like a transparent latch that latches on the rising edge of the /WE signal.

Yes, exactly.

Quote:

can I use an IO strobe by itself (see below) which probably lasts a bit longer than the falling edge of PHI2

Uh... remember, it's a transparent latch -- not edge-triggered. And it seems to me you're worrying about the wrong end of the pulse.

It's probably alright if the 670's /WE stays low briefly even after the falling edge of PHI2 -- there'll still be valid data on the data bus. (Due to bus capacitance, as Neil pointed out.)

But I would be concerned about the potential for /WE falsely going low very early in the cycle, while the address bus is still in transition. It's possible that $C0C0 will momentarily and erroneously appear even though the final, valid address has nothing to do with the '670.

It's the same potential pitfall that obliges one to use PHI2 to qualify the /WE for an ordinary SRAM. You mustn't begin writing too soon because the address may not yet be fully baked.

-- Jeff

ETA: be aware that the Read section of the '670 will promptly track what's being written (without waiting for PHI2 to go low). Will it be awkward for you if the 670's output updates -- thus changing your mapping scheme -- while the write to the '670 is still in progress?

(In some ways it would be nicer if the writes to the 670 were indeed edge-triggered! But simulating this requires the addition a bit more circuitry. )

[BigDumbDinosaur]

Given that the 74HC670 is as slow as a snake in a snowstorm and the somewhat-faster 74AC version seems to have vanished, perhaps tweaking the design to use a GAL might be a better route to take.  A 16V8 could be made to do what you want, and with low prop time.  The Atmel ATF16V8C is available at speeds down to 7.5ns in PDIP or 5ns in PLCC20.

[John West]

I don't see a 16V8 being suitable at all - it has only 8 flip-flops, all of which are directly connected to pins. The '670 has 16 bits of state, with four multiplexed onto each output. A CPLD like the ATF1502 should be able to do it if you wanted to go that route.

Or alternatively, use the 74HC670 - it's an interesting part that does what the design needs. Not everyone wants to get the highest clock speeds possible.

I once used one to give a Commodore 64 a 256K RAM expansion. This was more than 35 years ago and I don't remember any of the details, other than it was simple and it worked (and it used piggy-backed 41256 DRAMs).

[Dr Jefyll]

BigDumbDinosaur wrote:

A 16V8 could be made to do what you want, and with low prop time.

Agree about the low prop time, but a 16V8 has 8 macrocells, each with only 1 bit of storage. Thus it's incapable of replacing a '670, which has sixteen bits of storage.

(I see John West has just posted, including that same point. And I agree too about the mux'ing.)


The transparent behavior of the 670 is sometimes less than ideal (as noted in my previous post). Programmable logic -- such as an ATF1502 -- is one solution, but that's not everyone's cup of tea.

If required, one discrete-logic solution is to insert a '573 in the write path, just upstream of the '670. At the fall of PHI2, the '573 captures the /WE, address and data signals that'll get passed along to the write section of the '670. Then the write to the '670 begins when PHI2 falls.

(IOW, the 670 doesn't "open" until the the 573 "closes." This opposing-phase combination of one transparent latch followed by another is equivalent to an edge-triggered operation.)

-- Jeff

[floobydust]

Just an thought... the RC2014 Bus project has a 512KB RAM/ROM card which uses a pair of the '670 register chips.

There's also the Fuzix project that supports the memory expansion and has a 65C02 port as well as the normal Z80 CPU used on the RC2014 series of boards.

Attached the PDF schematic for the 512KB expansion board.

512kROMRAM.pdf

(58.63 KiB) Downloaded 18 times

[BigDumbDinosaur]

floobydust wrote:

Attached the PDF schematic for the 512KB expansion board.

Too bad it’s in color...can’t read it.

[floobydust]

Yes, not my file... just grabbed PDF from RC2014 site some years ago.

Try this:

[BigDumbDinosaur]

floobydust wrote:

Yes, not my file... just grabbed PDF from RC2014 site some years ago.

Try this:

512K-RAM-ROM.jpeg

Thanks!

[Rob Finch]

'H670 would work great. There are also other IC's that could be used to map memory.
I am reminded of the 74LS612. A while back I saw some 6829's for sale.

Is the 'HC670 for a CMOS system?
Need to be careful interfacing CMOS to other standards.