Building blocks with 7400 series logic

[Jokse]

I've been looking around on the web for something like a library with 7400 logic used to perform various functions, like a register or a range comparator circuit (say 8bit, has to be within the range of 0b00110000 and 0b00110011), but I've yet to find something useful. Have you guys any pointers to where they might be or should we actually have a thread with self contained circuit blocks that can be used to do stuff like an ALU, barrel shifter or counter circuit with settable reset on specific values?

[GARTHWILSON]

I guess the days of data books are gone. I'm sure glad I kept my three shelf-feet of National Semiconductor data books. Actually now National has been gobbled up by TI, and TI says, "We already have that part, so we'll replace National's data sheet with our own," and a lot of helpful info is lost, even in their online data sheets. Typical of TI. With real books, it was easier to look up functions like you want. You can try http://www.ti.com/lsds/ti/logic/home_st ... logic.page though. Try the '521 or '688 for the selector you mention.

[grzeg]

Jokse wrote:

a range comparator circuit (say 8bit, has to be within the range of 0b00110000 and 0b00110011),

look 7485
ALU 74181 ,add 74182,7483

http://en.wikipedia.org/wiki/List_of_74 ... d_circuits

[Klaus2m5]

Jokse wrote:

I've been looking around on the web for something like a library with 7400 logic used to perform various functions, like a register or a range comparator circuit (say 8bit, has to be within the range of 0b00110000 and 0b00110011), but I've yet to find something useful. Have you guys any pointers to where they might be or should we actually have a thread with self contained circuit blocks that can be used to do stuff like an ALU, barrel shifter or counter circuit with settable reset on specific values?

If the range is fixed, the cicuit design is simple with the help of a truth table.

Code: Select all

0b00110000
0b00110011
----------
0b001100xx (x= don't care)

Take the zeroes to the input of an OR-gate and the ones to the input of an AND-gate. Combine the results by feeding one group into a spare input of the other. That requires the correct polarity of the output of the first group (AND vs. NAND or OR vs. NOR).

Code: Select all

                ______
            7 -|      |
               |      |
            6 -|      |
               | NOR  o-+
            3 -|      | |
               |      | |
            2 -|______| |
                        |  ______
                        +-|      |
                          |      |
                       5 -| AND  |-
                          |      |
                       4 -|______|

Want to read on ALU designs (miles ahead of the above): http://www.6502.org/users/dieter/

[Jokse]

Thanks for the suggestions, but I didn't mean a list of 7400 logic, but a library of circuits already predesigned for a specific function. I've already been looking at designing stuff myself and reuse circuit blocks for the same functions across board instead of just reinventing the wheel over and over again, while others might have already accomplished a certain function with a circuit block that could easily be reused.

It could be a standard way to wire up a '374 with one ore more '245s to create a simple 8bit register block that could be used over and over again.

[LGB]

I'm thinking about building an "SPI interface" using 7400 ICs. I am not sure if it's already done by someone else though. It does not seem to be complex, but the evil is always in details What I can think, that some standard shift-in, shift-out register parts can solve the problem of generating signal for MOSI and accepting data from MISO. The clocking though can be tricky, if it's need to be "self running" some kind of counter is needed to stop after 8 steps. I am also thinking on a semi-hardware/semi-software solution, when SPI bandwidth/clock is important but not _that_ important. So the two shift registers remains but eg CPU generates the shift clock (still faster than software-only bit banging the SPI bus). I was thinking to use something like SYNC signal of 65C02 to generate clock and the last op (the previous ones can be NOPs) should stop the clocking (ie some kind of flip-flop can be reset with that which is set with the serial shift-out write). However I would like to use 65816 and it does not have SYNC if I remember correctly. I can't decide which would be the best: the block move opcodes would be nice to use to read/write data from/to SPI but it needs more complex interface. I know about 65SPI, but somehow I feel more interesting if I do myself. If I can at all, even with some help What are your opinions? Thanks.

[nyef]

LGB wrote:

The clocking though can be tricky, if it's need to be "self running" some kind of counter is needed to stop after 8 steps.

I'm not too familiar with SPI, but if you want to only generate clock pulses while there are data bits to clock out, how about using a second shift register, loaded and clocked using the same signals as used to load the data shift register but with the data inputs locked to all ones, and shifting zeros on each clock?

[Dr Jefyll]

LGB wrote:

What I can think, that some standard shift-in, shift-out register parts can solve the problem of generating signal for MOSI and accepting data from MISO.

Yes -- for example, you could use a 74xx595 to shift in the MISO signal, and a 74xx165 to shift out the MOSI signal. Both would connect to the CPU data bus, and they'll need some sort of chip-select signals. That's so the '595 knows when it's being read, and the '165 knows when it's being written. Usually 65xx computers use memory-mapped IO, and if you go that route then the chip-select signals would come from a decoder that's wired to detect certain memory addresses. (You could even use the same address for both the '595 and the '165 if the decoder includes R/W line as one of its inputs.)

To save board space and reduce wiring, a '299 universal shift register could replace both the '595 and the '165. This chip has lots of modes, but most of that can be ignored. Just remember, the mode is always "shift right" except when you're writing to it. That's the only time you need "parallel load" mode. Notice a clock pulse is required when you're writing to it. (Be careful with the bit order. SPI shifts the most-significant bit first. And the '299 document numbers its bits left to right. If you wire the '299 so its I/O0 pin connects to CPU data-bus d0, I/O1 -> d1, I/O2 -> d2 and so on -- not the other way around -- then, according to the '299 doc, the shift required by SPI is called a "shift right.")

299 shift register used for SPI.gif (8.2 KiB) Viewed 1846 times

74HC_HCT299.pdf

(144.18 KiB) Downloaded 119 times

LGB wrote:

The clocking though can be tricky, if it's need to be "self running" some kind of counter is needed to stop after 8 steps. I am also thinking on a semi-hardware/semi-software solution

The semi-hardware/semi-software solution would be simpler to wire up, although not by much (a count-to-8 counter is not that hard). A lot depends on what you feel comfortable with. One easy solution would be to take another signal from that memory decoder and use that as the source of your clock pulses. To generate 8 clock pulses, you'd access the associated memory address 8 times (ignoring the data bus; it's just the address that cues things). Or, on a 'C02 you could detect unused opcodes to trigger the clock pulses. You can probably come up with some ideas of your own for how to manage the clocking, so I'll shut up now (and get back to work )!

cheers,
Jeff

[GARTHWILSON]

nyef wrote:

I'm not too familiar with SPI,

It's very similar to the 6522 VIA's shift register port except that there are the four modes for clock polarity and phase, ie, whether the clock's idle state is high or low and whether its first edge marks the beginning of the first bit time or if the first bit is supposed to be read at that edge:

Code: Select all

 SPI Mode |  Clock Polarity  |  Clock Edge
          |    (CPOL/CKP)    |  (CKE/NCPHA)
----------+------------------+-------------
    0     |        0         |      1
    1     |        0         |      0
    2     |        1         |      1
    3     |        1         |      0

See http://en.wikipedia.org/wiki/Serial_Per ... erface_Bus
and http://wilsonminesco.com/6502primer/pot ... ITBANG_SPI

I never remember which mode is which. I just follow the timing diagrams in the data sheet for each SPI-interfaced IC I use, and it always works.

[LGB]

Thanks for the answers!

SPI has 4 different modes, I would implement only "mode 0" since it seems to be the common "language" among almost all of the SPI capable devices I would need. But anyway, all SPI modes has the attribute to have rising or falling edge of the clock to "read" the signal (ie, read or "capture" MISO by the master) and the other (the opposite) edge to "write" the signal (ie, write or "propagate" MOSI level by the master). I am not sure if a single '299 can do this, as it seems to have a single "CP" pin for clock and the truth table only mentions low-to-high transition (= raising edge) for operations. It would be nice since I am not so familiar with more complex 74' parts other than simplier gates, the usual '138 and similar "usual" stuffs for a more-or-less beginner etc

The other problem: as far as I can understand, the '299 has a single register, I can store a value which is shifted out, while the "received" data is shifted in, to replace (?) the original value in the shift register bit-by-bit. However, for some tasks like SD card interfacing I would need to read a block which requires the output of $FF on MOSI while reading data on MISO from the card (well, SPI is full duplex synchronous serial bus after all). Surely, it's not a problem as I can "refill" the shift register $FF after each shift (well, actually it means to keep MOSI on 1 always, so technically it can be solved in a different way too without providing "true" full duplex interface), but it's a performance bottleneck then, and I would lose the ability to use block move opcode of 65816 which is kinda nice (and would allow to put I/O to the non-zero bank (which is nice: simplier address decoding!) without too much performance problem long addressing would mean, because block movement is the same in speed from any bank, if I am correct).

What I thought for I/O possibilities for the CPU, like this (remember, SPI for real does not have read and write mode, always happens the same time so I name that "transfer" for a 8 bit transaction):

CPU read (read on IO-addr-0): shift-in (MISO) result of the previous transfer (but do NOT start a new transfer for now!)
CPU read (read on IO-addr-1): shift-in (MISO) result of the previous transfer AND start a new transfer with the last written shift-out value by the CPU
CPU write (write on IO-addr-0): shift-out register which will be used on the next transfer (but do NOT start a new transfer for now!)
CPU write (write on IO-addr-1): shift-out register AND start a new transfer

So basically CPU R/W would select shift-in or shift-out register and a single bit difference in the I/O address decides that only reading/writing the shift register, or also the start of a new transfer then. SPI would be clocked to have faster than the minimal possible CPU clocks to access the registers again, so no need for busy flag, etc. This seems to be odd (SD card specification for example writes about max of 400KHz clock - or something like that - before card is identified), but eg the SD-card cartridge for Enterprise-128 (Z80 based though, but never mind) has SPI interface implemented in a CPLD clocked at constant 16MHz - so Z80 would never worry about unfinished 8 bit transfer -, and no problem with most SD cards still. Well, here and in my whole post, SD card is only (but important) example to use SPI for, of course, than can be others (like ENC28J60 for ethernet). This interface would need (I guess) at least two shift registers (for "write" and "read") so maybe one '299 is not enough, but seems not to be overcomplicated yet, still. Or whatever

The trick would be that no need for the I/O address of the SPI interface decoded from the LSB of the CPU address actually. It's because block movement opcode in 65816 has the "problem" that both of source and target address is incremented (well, or decremented) after each copy of a byte. Thus, if we need at least read/write (let's say) 512 bytes with block move op in a clean way (fast enough, short code), then at least 512 continual addresses needed for the I/O with the very same purpose (again, with I/O not in bank zero of 65816, it's usually not problem to "waste" addressing space, unless you need 16MByte RAM and minimal "waste" for I/O ... not my case, 512K SRAM would be enough, practical and also cheap).

My post seems to be somewhat eclectic, since I talked about "not so much performance oriented method" (eg with semi-software solution), but somehow I also feel that performance is not a bad thing of course, if it can be got with a little more complexity. The unused ops of 65C02 is a good idea for the other solution, but I would go with the 65816.

I am not sure how dumb ideas I have, so let's just laugh on me I am really not so experienced but I would like to start to build something at last!!

[Dr Jefyll]

LGB wrote:

I am not sure how dumb ideas I have, so let's just laugh on me I am really not so experienced but I would like to start to build something at last!!

The joke is on me, since you identified an oversight on my part (regarding opposite clocking edges for incoming and outgoing data). Offhand that seems like something that can be fudged over with an RC delay, or more properly corrected using one negative-edge-triggered flip-flop section. (The other half of a flip-flop could be part of your "generate-8-pulses" circuit, perhaps. If I get time later I'll post a diagram.)

LGB wrote:

actually it means to keep MOSI on 1 always, so technically it can be solved in a different way too

Here again, something simple like an OR gate could do the trick, although you'd need to have an output-port bit from somewhere.

Considering these points, using separate shift registers (eg 165 and 595) may be better after all, space-wise. But the '299s is a chip worth studying, given its ability to reconfigure itself for different jobs. It's a classic example of 7400 series MSI logic.

LGB wrote:

I also feel that performance is not a bad thing of course, if it can be got with a little more complexity. The unused ops of 65C02 is a good idea for the other solution, but I would go with the 65816.

The unused opcode of the 65816 ($42, or WDM) should also be able to serve the purpose, although the thread I linked to doesn't mention this. So the option is still worth considering; it's your choice.

-- Jeff