Counters for address bus - do I need latches?

[zappedy]

I want to read arbitrarily sized parallel memory chips (ROM) via a bidirectional PC parallel port (PP). Don't ask why that platform...). Lots of experience with assembly programming, no experience with glue logic or hardware.

So, I was going to connect a bunch of 74590's in cascade and clock them with a single PP pin. The outputs of the 74590s then go to the address pins of the ROM and the data lines from the ROM goes back to the input pins of PP. So, very basic. I simulated my circuit and it looks like it works.

However, the 74590's only have a ripple carry. From what I understand, this means that every 74590 will change slightly later then the previous. Does this mean I will need additional clocked latch chips after each 74590?

Can I use the Register Clock on the 74590's to somehow make the address bus change synchronously? I don't really understand what it does.

Do I even have to do this synchronously, or could I even use a plain ripple counter to drive the address bus without problems, assuming I use the proper timing delays in the software?

[PA0PBZ]

As long as you wait long enough to stabilize the address before reading the data it should work ok. You can even use dip switches to select an address.

[SeanB]

Ripple counter is fine, just do the read of the data well after the last counter has changed state. Minimum is the sum of all the delays of the riple counters ( 16 times in your case with a 64K chip), plus the decode time of the ROM chip, then add a few ns extra to settle on the data bus then read. If you use 1ms as a read rate then you likely will have no problems, read the data just before you do the next clock.

[zappedy]

Thanks guys! I will try your suggestion and use ripple counters because I already have a bunch of those in my parts drawer. No need for speed so it will probably work!

[T3sl4co1l]

I made one of those a long time ago, I used a few latches to store the desired address, no counter.

http://webpages.charter.net/dawill/tmoranwms/Elec_RamR.html

Unidirectional port at that, so the data byte was read a nibble at a time via status signals.

Tim

[zappedy]

Thanks, I'll keep that design in mind!

Since I'm waiting for components to arrive by mail, I read some more.

Do I really need protection circuitry for the parallel port, and if so, what?

I read about shorts to ground when devices are unplugged and so on. I would not like to zap the motherboard of my old laptop that still has a working 5V parallel port!

Some sites mentioned the 74LVC245 buffers, and it's 16-bit counterpart, but getting those with breakout boards for DIP will be expensive, and will require another month or so waiting on them to arrive...

Perhaps this is all unnecessary?

[T3sl4co1l]

"Meh" comes to mind?...

Dunno.  I don't really know what is typical for use on computers.  Think the last motherboard I had with a parallel port, there was a 74LV244 nearby, which seems suggestive.  Others, it's hard to tell if they just go right up to the system chip, or what...

If you're careful, taking ESD precautions and all that, it shouldn't be any problem.  Also, keep the baud rate moderate to low (i.e., less than MB/s) to minimize the effects of reflections, especially on long cables (>3ft?).

Tim

[Asmyldof]

Meh seems about right.

Plug/unplug is not going to destroy anything if you hook up the signals right and use a factory standard Sub-D connector using only logic and ROM that's all powered from a low-power supply or the connector itself.
There's designs out there that are powered by the port itself by means of a set of 1n4148 diodes on all signals and a nominal series resistance that don't require ultra quick data flanks that worked for those people.
Caveat: No CE/TuV will ever approve that, because it CAN destroy the buffers or control logic. Most computers have buffers.

If you want to be 100% safe you can apply some modern connector trickery by heating the GND pins and pushing them out a little bit, so that they all connect first and disconnect last, but this is more work with basically no real-world need.

What you DO have to be very careful of is boot-up. During boot BIOS and/or OS kernel may send control signals on the bidirectionals and control signals to check if a terminal printer or terminal display is there, to output logs or statistics to. So if you have outputs on your side on a bidirectional and the PC then wants to output the opposite voltage, that conflict may end in burn-outs on your motherboard. In another case the ROM might coincidentally "respond" in one certain way, making the system going into Kernel-dump sending out bunches of data on the signal lines on EPP type ports, where your ROM is also outputting something.
Although that is also not very likely, it is more a consideration than the plug-risk in my experience. So while booting the safest thing is to not have anything attached, and plug it in after you have a familiar screen (login or near-login, etc).