This is a schematic of a circuit I built to read ROMs (2764, 27128,
27256, 27512) via a peecee parallel port.

Power connections are not shown (everything is TTL and thus uses 5V
power); for non-power pins connected to a power rail, a down-pointing
triangle of lines means "ground" and a hollow up-pointing triangle
means "+5V".  In most cases, pins left unconnected are not mentioned;
in a few cases where I wanted to explicitly indicate "no connection"
(the parallel port, and the high-order '161), I've used a small X.

Parts list:

74LS161 x4
74150   x3
74LS04  x1
74LS373 x1
74LS138 x1
74LS367 x1
Socket for the ROM
DB25M connector for the parallel port

(74LS150s would doubtless work as well as 74150s; I listed above what I
actually used.  I imagine any TTL-compatible family would work, such as
74HCT....)

The four 161s are connected as a 16-bit counter, driving the ROM's
address lines.  The 24 lines to the ROM (16 address and 8 data) are
connected to the three 150s, which multiplex them onto the three input
lines, controlled by the low four output data bits.  (I didn't want to
assume bidirectional parallel port hardware, so I restricted myself to
the lines that are inputs even on legacy parallel ports.  There are
actually five input lines; I forget why I used only three of them.
Perhaps I didn't have enough muxes on hand, or perhaps I found that
some of them generated interrupts when toggled and thus weren't usable
for general-purpose I/O.)

The 138 and 373 exist to control the counters.  Pulse the G1 input of
the 138 high while holding the other seven data bits constant (ie,
write V, V|0x80, V to the parallel port); what happens depends on the
0x70 bits of V.  If 0x00, this clocks the 161s.  If 0x70, this sets the
load bits to the low four data bits, one per nibble; when clocked, a
counter whose load bit is low will take on the value then present on
the low four data lines.  (A counter whose load bit is high will do
nothing or increment, depending on the values of less-significant
nibbles.  Careful planning is required to use this to store arbitrary
values into the counter; its primary use is to clear to 0, which uses
all load bits at the same time.)  You have to turn off the load bits
explicitly with another 0x70 pulse in order to return to normal
counting.  Values other than 0x00 or 0x70 do nothing (the Y1 through Y6
outputs of the 138 are not connected).

The E0 and E1 inputs of the 150s are used to provide a signature: the
values read back for low nibbles 0000 and 0001 are constant and are
used by the driving software to help catch attempts to use a
disconnected or powered-off circuit.

In principle I could have saved one read by packing the 24 bits of
readable data into 8 reads rather than 9.  I decided that keeping the
address and data separate was worth one extra read.

This obviously requires software support from the host.  In my case
this meant special-case hacks in the parallel port driver in the NetBSD
kernel.  Depending on what you're running on the host, the necessary
software support may be anything from trivial to (almost) impossible.
The interface I chose was that userland passes a block of bytes to the
kernel; the kernel then loops, writing bytes to the port and reading
back the resulting data lines, until the block is exhausted.  The rest
is done in userland.  Performance is not stellar but acceptable; it
takes me no more than a few seconds to read the full 64KB contents of a
27512.

When reading a ROM smaller than a 27512, I manually disconnect the
wires for address bits that don't exist on the ROM.  If the host
software always reads a full 64K, it will get aliased copies of smaller
ROMs.  Smaller ROMs would presumably be handled some other way in a
more polished version.

The reason I've drawn the parallel port connector the way I have,
rather than listing the pins in numerical order, is that I used a DB25M
with ribbon cable soldered onto it, which produced the pins interleaved
on the cable the way they are on the drawing; this kept the drawing
closer to the physical reality, reducing the chance of errors.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B