Z80 Front Panel Interface - Page 1
Forum section: electronics / projects

author: MrAureliusR
author_rank: Unknown
timestamp: May 11, 2014, 06:15:38 am
content: Back in November of last year, I became interested in designing a Z80 based computer. At the time, even though I studied at length, I didn't have the patience to wrap my head around it all and I lost interest.Recently, I decided to give it another shot. This time, I used my larger breadboard, and instead of using the cheap jumper wires that come with breadboards I did all the wiring by hand, with solid core wire. This made everything neater, and the colour coding helps me to keep it all organized.Before I get further in my project, I want to build a simple bus monitor, à la PDP-8 front panel. Lights for the data and address line a, plus the added benefit of a 7-segment decoder. So far, all I have is the Z80, a 28C256, and a Toshiba SRAM (32k I think). However, for the first stage, I'm planning on using only 4k of each, for a total of 8k mapped memory.I have some bus transceivers and buffers, and I can build the simple LED/7-segment part of the panel. My question is about the auxiliary switches and also some design philosophy. A user named grumpydoc gave me tons of info on different memory decoding/bank switching schemes. However, I want to be able to enter basic programs line by line into my RAM. I've watched a series of YouTube videos, in which a 6809 based system is built on protoboard. The 6809 seems to have a HALT input - he starts the system with the processor stopped and disconnected from the bus. He then enters a basic program through switches, and once it's completed, he puts the 6809 back on the bus, releases the halt for a second, and then examines the contents of memory to see if it ran correctly.Essentially, I want to do the same. So:- what is the equivalent of HALT on a Z80? The /HALT line is an output only, to let the user know when the processor is halted, but how to get it there?- I may end up using a small micro to handle the Mem+, Mem-, Store and other buttons. I like how in the videos, pressing Store/Load automatically advances to the next position in memory.- I'll also need an Addr/Data toggle to determine what the switches are controlling.I've been trying to find schematics for a design online, but it's almost like I can't find the right search terms. "Bus Monitor" seems to me to be the most descriptive name, but it doesn't bring up what I'm looking for.Any and all suggestions are greatly appreciated!! The reason I want to use a front panel design is tl familiarize myself with basic Z80 assembly and opcodes. Once I'm confident I'll move to a cross-compiler and burn EEPROM directly.

author: Skimask
author_rank: Super Contributor
timestamp: May 11, 2014, 06:28:18 am
content: HALT on a Z-80 is an instruction. Pulls the *HALT output pin low. The Z-80 basically executes NOPs until an interrupt or a reset is tripped and it continues accordingly...

author: Skimask
author_rank: Super Contributor
timestamp: May 11, 2014, 06:38:08 am
content: The Z-80 was killing Jedi's before Palpatine was...

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 11, 2014, 02:41:19 pm
content: There's a WAIT signal, primarily used for slow memory (e.g., waiting for full RAS and CAS cycles on DRAM), but also used for IO (say you have an IO-mapped parallel ADC that takes some time to produce a conversion -- unlike today's vast array of SPI ADCs, which do the conversion while pumping data out!) and, if you wanted to feed the processor bytes by hand, you could apply a little logic so that a debounced pushbutton holds WAIT until you're readied your next byte, and so on.This isn't so great for memory. What you'll want is either holding the processor in RESET (it starts at 0000h when released) or stalling it with a bus mastering cycle (I forget what does this, but it's in the datasheet). Which, after all, is what you're after: you want to assert the address and data buses to program the memory by hand.Tim

author: dajt
author_rank: Contributor
timestamp: May 11, 2014, 10:35:16 pm
content: I'm working on the same thing. My idea is to use the WAIT line to allow single stepping and the BUSREQ (I think) signal when I want to program the EEPROM.BUSREQ should tell the Z80 you want the bus and it will respond by asserting BUSACK when it has tri-stated its bus connections.But I can't get as far as making the shift registers work correctly with soldered connections. Fine on the breadboard, flaky when soldered.Regards,David.

author: grumpydoc
author_rank: Super Contributor
timestamp: May 11, 2014, 10:44:41 pm
content: QuoteNot sure how you use WAIT for single step.There is a neat way to do single step with a bit of external logic - basically you toggle a bit on an output port to initiate counting a couple of m1 cycles and then generate an NMI - set up the stack to "return" to the instruction you want, fill the registers and then do a "RETN". Get it right and the CPU executes one instruction and then takes the NMI giving you control back.The Nascom 2 used that approach - I'll see if I can did the circuit (and software to use it) out.

author: MrAureliusR
author_rank: Unknown
timestamp: May 12, 2014, 05:04:33 am
content: Or, of course, you can just hand step the clock. Great thing about the Z80 is it's totally static. You can completely stop the clock if you want.Well, I have the breadboard all wired up. Simply using 8k of ROM and 8k of RAM (though I'll mostly be programming some basic stuff into RAM by hand for now). However I'm having the opposite problem -- my breadboard is the type that has the big metal plate as a base. This, combined with the many wires for the data and address buses is causing all sorts of strange interference. I'll either temporarily strip it all back to just RAM, or transfer everything to a protoboard. Wish I could find one similar to the 6809 design I've been watching. Eurocard format, with good quality FR4 and double sided plating on the holes. Plus spots for D connectors, DIN 41612, etc.I've found a basic 'front panel' design, but I'm also spinning my own. I'll post schematics here if it works (lol). The basic memory decoding is working. Just as grumpydoc showed me, when you're only using 8k pages, all you need is an LS138.

author: dajt
author_rank: Contributor
timestamp: May 12, 2014, 10:38:23 pm
content: Quote from: grumpydoc on May 11, 2014, 10:44:41 pmActually, I didn't explain that correctly.I am using wait to give the bus sniffer time to decode and display the address lines during the M1 cycle. I could keep asserting wait at this point to halt the processing.I'm also considering a switch to use either a crystal or a line from the MCU controlling the bus sniffer as the clock. Then I can make the clock stop or go any speed I want when using the MCU line.Regards,David.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 12, 2014, 11:22:18 pm
content: Quote from: MrAureliusR on May 12, 2014, 05:04:33 amEhh, Z80C...I have a few NMOS that get heartburn if the clock is ~50% outside of specTim

author: MrAureliusR
author_rank: Unknown
timestamp: May 13, 2014, 02:07:15 am
content: Anyway, back to my original point. I found some 74LS642's I think, bus tranceivers. Plus I've got the LS241 and 244's handy. I might cheap out and just use an ATmega to control the front panel interface.I want to be able to view the contents of memory, and program the SRAM from the panel as well. I guess I need to think of the panel as another unit on the bus - it essentially replaces the CPU. So I suppose I just program it to assert all the same lines that the CPU would when reading and writing the SRAM.I wanted to do it with logic chips only, but I just don't seem to have the right ones on hand. I contacted Matt Sarnoff of Ultim809 fame to ask about his front panel. I'm basically just trying to get ideas.All it needs to do is display the address and data buses, have switches to enter data, have switches to stop, reset,and otherwise control the Z80 (perhaps also change the clock source, or stop it at will). So there will be Address +, Address -, Load, Reset, and I guess a 'Load Address' button in case I want to jump by more than a couple addresses. The Load button should also auto-increment the address. Also, when the address is changed, it should immediately display the contents of that address.This many buttons, switches, and bus lines overwhelms almost all the microcontrollers I can think of (in terms of pin count). I suppose the micro doesn't need to interface with the data bus directly... it's not doing the display, the 7-seg driver will handle all that.Any suggestions, or if anyone can point me to a good design, is much appreciated. I have found one basic front panel schematic. I'll post the link here when I'm back on my PC.Thanks everyone!

author: dajt
author_rank: Contributor
timestamp: May 14, 2014, 01:03:12 am
content: I'm using shift registers to interface with the busses, so for ex. the address bus can be read with 4 lines, or use 3 shift regs and add the data bus into that, read all three with 4 lines.I'm using a cheap Chinese arduino nano as the panel controller and I'm pretty sure I ended up with enough lines to work with the address and data bus, and program the EEPROM, plus handle some of the Z80s control signals.

author: retrolefty
author_rank: Super Contributor
timestamp: May 14, 2014, 01:29:01 am
content: Quote from: T3sl4co1l on May 12, 2014, 11:22:18 pmI've got a Z80 manual by Zilog somewhere around here, had it sense the early 80s, and I'm sure even the original talked about being total static capable?Anyone also recall the 'undocumented' machine instructions that were discovered?

author: MrAureliusR
author_rank: Unknown
timestamp: May 14, 2014, 02:20:43 am
content: Quote from: retrolefty on May 14, 2014, 01:29:01 amYup, z80.info has links to the complete list of undocumented opcodes.Thanks for the suggestion -- I think I have a basic design in mind now. I'm going to use the 74F241 buffers to buffer theincomingdata and address lines, plus some of the other status lines that are output by the Z80. Then, to control the buses, I'm going to use 74HC574's, that are controlled by the 16 switches, and activated by pushing the correct button. For example, pressing 'Load' after switching in data will assert that data on the data bus, and also write the data into the SRAM, or EEPROM, depending. The BUSRQ line will be attached to a swtich, as will the RESET, and WAIT lines, so I can stop the processor, disconnect it from the bus, and then program the SRAM. Also, the panel needs to display the address and data on 7-segment displays -- this has actually become the hard part!There are very few 7-segment driver chips that do the full hexadecimal code. All the common ones (4056, 4511) just do 0-9 and then a few other useless characters beyond that. The chips that DO handle full hexadecimal are anywhere from $4 up to $20 a pop. I wanted to be able to control ALL the digits from one chip -- multiplex all 6 digits. The Maxim ICM7212 can handle 4 digits, and does full hexadecimal. Unfortunately, the MAX7219's I have don't do hexadecimal, which sucks as they can do 8 digits, and it multiplexes them automatically. This way I could have one micro, and one chip to handle the display side.I believe that the Ultim809 used intelligent LED displays, that could decode and display the data themselves. I have one single display that does this, but it's a really cool old HP chip and I don't want to sacrifice it. Plus I'd need five more anyway. So my dilemma is whether to go with a microcontroller design, a decoder chip design, or an intelligent display. I'm going to Toronto for a week, and I'm going to hit both Active Surplus and Sayal Electronics, so hopefully I can pick something up that will work well.My other question was is it okay to use a buffer, such as the 74241 inbothdirections simultaneously? That is, when the processor is disconnected from the bus, one 241 will buffer the data bus coming to the card, in order for it to be displayed. This is necessary for examining the contents of memory, but also for displaying what I've input after it's been asserted by the 74574. I was going to put the 74574's output back through another 74241 to buffer itbackonto the bus. When the processor is connected to the bus, this second buffer will be put in the high-impedance mode. Or is this buffer unnecessary? Does the 74HC574 buffer the output of the switches well enough to connect it directly back to the bus? Or, I could use the 74LS645's I have -- they are bus transceivers, so they buffer in both directions, though I have to read their datasheet a little better to understand if they need to be switched back and forth. I like the 74F241's because they are easy to enable and disable, and I'm pretty sure their outputs are tri-stated when they're inactive.Does this sound like a good design? I was going to take some elements of a design I saw, namely, the busses should be pulled down by resistors by default. This helps keep the bus stable. I guess they don't need to be strong pulldowns (or pull-ups, I guess), but I don't want them to be super weak, either. These would be for the switches, so that they'd keep the bus pulled low.However, on a separate issue, would it make sense to have the address and data buses pulled low through weak pulldowns to help fight noise? Does the Z80 source enough current to pull a line up that's being pulled low by say a 100k resistor or something? The reason I ask is that the bus lines slowly get longer and longer, the more things that get added to the bus. Or should I just put buffers directly beside the Z80? All the designs I've seen only use one buffer per bus, and usually that's on the 'Front Panel' interface, or sometimes when the bus jumps to another card via a ribbon cable. So far, my new design is small (I ended up ditching the huge breadboard and moved everything to a piece of stripboard, which itself will probably get ditched in the near future when I get a nice Eurocard size protoboard to work with) and I think will have very little noise. But once I move the design to a bigger board, and there's more and more things on the buses, will I need to start thinking about things like this? Eventually, there will be RAM, ROM, a UART, possibly sound and video chips, removable storage such as CompactFlash, etc etc, all connected to the data and address buses, through wires. I've been using regular 24AWG insulated red wire to make most of the connections so far.Anyway, enough for one post. Again, I really appreciate everyone's help! I will be SO excited when I enter in my first program via the switches, and then see the result in memory! Oh boy -- I'll feel like a kid who just got an IMSAI 8080 for Christmas, and sees the lights blinking for the very first time!!!Cheers everyone!

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 14, 2014, 02:22:11 am
content: Datasheet for the Z0840004 says 110ns minimum pulse width (low or high), 250ns min cycle time (i.e. 4MHz max), 2000ns max pulse width (low or high) (presumably, 250kHz minimum).At least, that's the kind I have a few of; was there a static NMOS version too? Maybe the 084s are the odd ones out, cost-reduced or something? (They still draw a whopping 200mA though...)The 84Cs specified in the same datasheet are static though.Tim

author: Simon123
author_rank: Regular Contributor
timestamp: May 14, 2014, 06:10:18 am
content: You get into halt with single byte instruction 76-hex. It also starts "doing NOPs" until you reset it or put interrupt in.I built it like thishttps://sites.google.com/site/elektronikasimon/z80-computer.

author: MrAureliusR
author_rank: Unknown
timestamp: May 24, 2014, 09:55:40 pm
content: So after my recent trip to Toronto to pick up parts and stuff, I've come a lot further on the front panel. I've been labouring over it for hours at a time, and I feel like I should have more done, but I'm trying to go slowly and do everything 'right' so everything 'works' when it's done.Here's a look at everything from the front (I've added more since I took this photo yesterday):The board on the right is the "input" board, which takes the switches and button presses and sends them onto the bus, and the left board is the "output" board, which takes whatever is on the bus and displays in on 7-segment displays.Here's the back, and a newer one of the front:

author: KD0RC
author_rank: Regular Contributor
timestamp: May 25, 2014, 05:22:33 pm
content: Another thought on front panels is the one from the HeathKit H8. Although designed for the 8080, it worked great with the Z80. In the day, I upgraded mine from the original 8080 board to a Z80 board that came with a better front panel monitor (did things in hex instead of that goofy split octal...). Find a schematic for that and you will likely get some good ideas for yours. The firmware was all out in the open, so you would not have to reinvent that unless you are after total DIY.

author: rob77
author_rank: Super Contributor
timestamp: May 26, 2014, 09:24:15 am
content: @ dajt - re: flaky when soldered. it reminds me the time when i was interfacing an 32k SRAM to an AVR 8515. i had a similar flaky behavior when soldered - the issue was a short address latch enable pulse for the latch i used - solution was a 33pF capacitor soldered between ALE and ground... maybe your breadboard parasitic capacitance is the reason why it works on the board but flaky when soldered@ retrolefty - sure i remember those undocumented codes - i was using them whenever possible because i found it to be cool back in those timesregarding the clock - i do remember some replica Z80 CPUs produced over here (eastern block at that time) which were not static, so probably there were more of those replicas produced all over the world

author: dajt
author_rank: Contributor
timestamp: May 26, 2014, 10:09:19 am
content: Thanks Rob77. Did the cap hold the line low while it was charging?I let the magic smoke out of the Nano, so development is halted for a while. It's happened a couple of times now, when I have the Nano on both external 5v and USB, and the Open Bench Logic Sniffer attached too. So that's two devices on the USB bus, and external power, with all the grounds connected.It usually seemed to work okay but about 3 times lots of grey smoke came from the Nano. Looking under a magnifier it seems the diode near the USB/external power switch has burned and cracked.It's a shame. But I've just ordered a bunch of cheap Arduino Mini Pro clones to replace it so will be going again in about 3 weeks.And that's right on the heels of a cap exploding yesterday when I didn't bother to check the power I gave an LM386 amp circuit was 12V DC, rather than AC. Luckily I was looking the other way when it went off, but there was stuff everywhere.Regards,David.

author: rob77
author_rank: Super Contributor
timestamp: May 26, 2014, 10:42:37 am
content: in fact the capacitor was just deforming the raising and falling edge and therefore making the ALE pulse a tiny bit "longer". obviously it was soldered to the pins of the latch, not the MCU. so if you have latches in your design, then it's worth of checking the latching signals. Z80 got no addr/data multiplex as 8515 does, so i assume you have a different , but similar issue.

author: SL4P
author_rank: Super Contributor
timestamp: May 26, 2014, 01:55:42 pm
content: Quote from: MrAureliusR on May 12, 2014, 05:04:33 amLook for the TIL-311(decoder & display in one) they'were quite common back in the day, and are available on eBay. Not too cheap, but worth it in time saving and pleasant display.

author: Dave Turner
author_rank: Frequent Contributor
timestamp: May 26, 2014, 02:35:24 pm
content: I have a copy of the Z80-CPU Technical Manual (1976 Edition). I've scanned the AC Characteristics and the AC Timing Diagram pages. Unfortunately I can't post the the resultant 4Meg files. If they would be of interest I can email them preferably to someone who can make them available generally.

author: C
author_rank: Super Contributor
timestamp: May 26, 2014, 06:31:56 pm
content: Quote from: MrAureliusR on May 11, 2014, 06:15:38 amAfter all is done, have you thought of just how much help will a front panel for a Z80 will assist you in learning?At speed if you have leds displaying the address buss, what you will see is just a difference in the led's brightmess. You would have a ball park hint that address area is being used but not see a read or write to a specific location, it just happens to fast.Unless you have the static cmos version of the Z80 you will not be able to single step the Z80 or slow the Z80 enough to make the LED's really usable.If you are trying to learn what a Z80 instruction really does, you will not be able to see the results of most instructions do as the result of the instruction is modifying a CPU register and the status flags.When you see the nice front panel of a PDP-11 you are probably missing a very important difference between the PDP-11 and most 8 bit processors. The PDP-11 is static at the microcode level. Leaving the PDP-11's microcode clock stopped or running it a a very very slow rate is allowed. You can also see the contents of the PDP-11's internal registers at a memory location. So for a PDP-11 the front panel serves a very important part of the PDP-11 system.If you want something close to the same for a Z80, you will need to run some software on the Z80 to get it to display what is hidden inside the processor. This is the debug monitor software software that is a part these Z80 systems. Due to the large amount of information contained in the Z80's registers this is normally dumped out a serial port for display. Note that while using the monitor program debugging software the Z80 is still running.So a front panel display for a Z80 will only give you a hint that the Z80 is doing something. And note that all those LED's will be creating a LOT of RFI noise.So the LED displays will be of little help when directly connected to a Z80. The simple inverter connected to a led with a series resistor is about as cheap and easy you you can get. There is one thing here that could make things a little better. Put a Data selector in front of the inverter. This would allow you to select what is going to the display. One very nice source would be to latch what captures what is written to an output port or memory location.So how could you boot strap up a Z80 to the level where the monitor program will be able to assist. If you look at the Z80's instruction set you will see that an instruction of 00 hex is a nop. If the Z80 gets a 00 on the data buss during M1 the Z80 will do a NOP Instruction which has a side effect of increasing the PC register by 1. The Z80 will do a loop of M1 cycles( a read) of all memory addresses( 0000 hex - FFFF hex -0000 hex and repeat). This loop will make it easer to test that memory select decoders are functioning. An M1 read is very close to what is needed to read the monitor program from an eerom.Now if you still want a front panel instead of or in addition of dumping the data out a serial port you could have the monitor program output the data to some data latches that is then is displayed on the front panel.C

author: retrolefty
author_rank: Super Contributor
timestamp: May 26, 2014, 06:58:15 pm
content: CQuoteUnless my memory is completely shot, I seem to recall that even from the initial release from Zilog, all Z-80s are fully static and can work at any speed to rated full speed?The fact that the chip supports unlimited wait states and DMA requests seems to me that single stepping is certainly possible?I believe that only if the design is utilizing external dynamic memory, which is dependent on the Z-80's automatic memory refresh, would stopping/single stepping the CPU clock be an issue.

author: Dave Turner
author_rank: Frequent Contributor
timestamp: May 26, 2014, 09:56:23 pm
content: QuoteThe original Z80s were fully static though I understand some later clones are not. External circuitry was required to refresh any dynamic RAM thus is practically independent of the Z80 itself.Note that while the clock can be easily single stepped one needs to be aware that the number of clock cycles required to complete an instruction is instruction specific.

author: dajt
author_rank: Contributor
timestamp: May 26, 2014, 09:57:20 pm
content: Re displaying hex digits on a 7-seg display I found it easiest to just define the "font" in a variable and use that to decide which LEDs to switch on for the various digits. Then I could just use the MAX7219 to handle the driving, while telling it which LEDs to use rather than using it's decoding mode.I had a cursory look around for an IC which did hex, but I already had the MAX7219.Added:As noted above, the Z80 allows any number of wait states, which I tested the other day while reading the address bus. As soon as /RD or /WR went low I asserted /WAIT until I'd read and displayed the address and this worked well. The LA showed the Z80 waiting for me.For single stepping, /M1 could be used to stop before each instruction is executed. As soon as /M1 is asserted, assert the /WAIT line until a button press to continue.How about sending the Z80 bus drivers to Z while it was waiting and allowing the supervisor MCU to read and interpret the address the Z80 it was looking at? This would give you the next instruction to be run.But as also mentioned bus sniffing only gives addresses and data bus values, there is a lot going on other than that.Regards,David.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 26, 2014, 11:23:04 pm
content: The Z084000x for example are not static. I have a few, authentic Zilog.Tim

author: MrAureliusR
author_rank: Unknown
timestamp: May 27, 2014, 02:44:41 am
content: All the Z80's that I've worked with have been static -- they're all the Z84C, so the CMOS versions. I've got 13 more on the way from Hong Kong. (Long story -- I bought 3, forgetting I had bid on a 10-pack, and then won the 10-pack, so soon I'll have more Z80's than I know what to do with).Quote from: C on May 26, 2014, 06:31:56 pmIn response to that post, I really don't want to sound rude, but I'm not a TOTAL idiot. I do have quite a bit of experience with electronics. I am quite clear on the differences between static and non-static Z80s -- obviously a processor running at full speed won't give you anything meaningful over the LEDs.My goals for creating a front panel were to be able to enter data manually into RAM, and then single step. Or, alternatively, run the program at full speed, then stop and examine memory locations. Plus, I also use z80-mon on Linux to emulate the programs I've been writing. And, to top it all off, I've been reading"How To Program the Z80" by Rodnay Zaksand I've also got another one, Programming the 8080 and Z80, on the way from Amazon. I believe that building and using a front panel can teach you a LOT about how microprocessors work. Entering the code by hand, and then single stepping the processor through the program, examining everything as you go... I mean, watching stuff on the data and address buses, plus all the signals coming from the Z80, tells you everything that is going on.I've been missing some ideas from both the Altair and IMSAI front panels -- I didn't think to include a "Deposit Next" or "Examine Next" button. I have Address Up, Address Down, Load (equivalent to Deposit), and Examine. Plus all the switches, and also Bus Request switch, and Reset.For those who are interested, or have DipTrace, I can upload the schematic of what I'm building. Or I might be able to export it to PDF.On the topic of 7-segment displays, the answer seems to have come in the form of the Intersil (now second sourced by Maxim) ICM7218. It supports hexadecimal, and can display to 8 different 7-segment displays at once. And even though it's relatively pricey (in singles) it's definitely worth it, as it replaces many other chips. I'm using it with an ATmega32A to interpret the address and data buses and then send the data to the ICM7218 to be displayed. I know, using a microcontroller is kind of cheating a bit, but really, displaying the data and address buses is secondary to my goal of getting a running system, so it's not that big of a deal for me. I just needed to get it up and running so I can start playing around with lights and switches.Last night, after some more testing, I think everything on the input side of the panel is working!! The only problem is that I used a 74LS00 for the NAND gates, but one of the gates needs to have 4 inputs, and tying two of the outputs together clearly does not work. So I'm a bit stumped as to what to do. Should I take those two outputs, and then put them through another gate? The logic is essentially, if any of the outputs goes low, I want the output to go high, which is exactly what a NAND does. I was thinking, if I put the two outputs through a NAND, and then through an inverter, wouldn't that be the correct logic? Anyway, I've got to think about that one a bit, and draw it out on paper. I don't really have room to add more chips, and I don't want to use all 4 gates on the one chip just for a single function (I need another 2-input NAND in another place).Thanks everyone for all your info and suggestions. Once it's up and working I'll be making some videos about what I've learned, and I'll probably post links here.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 27, 2014, 03:24:49 am
content: NANDs and NORs obviously can't be stacked (like AND, OR and XOR can), you need two ANDs and a NAND or the inverse, two active-low ORs and an active low-input OR. Um... just draw it out, easier than describing..Or otherwise, just a N-input unit.Tim

author: rob77
author_rank: Super Contributor
timestamp: May 27, 2014, 08:26:25 am
content: a nasty hack how to get more inputs on a nand gate, is to add a pull-up to the input and add some low forward voltage diodes to it's inputs . anodes on the gate input and kathodes are your separate multiple inputs. it works because during log Hi there is no current flowing, during log Lo there is current flowing out from the input (the added diodes in forward) .but of course i would rather buy a 4 input nand - that's the right way how to do it.regarding stacking gates - you can do that but you need a variety of gate types to achieve the desired logic function - but be aware that you might run into timing issues because of that stacking.

author: rob77
author_rank: Super Contributor
timestamp: May 27, 2014, 08:45:05 am
content: one picture is better than 100 wordsof course it won't work in high fan-out scenarios - because output of the previous stage must be able to hardly pull down the cathode to have a log 0 on the nand or inverter input.

author: MrAureliusR
author_rank: Unknown
timestamp: May 31, 2014, 08:12:31 am
content: So everything on the switches side is working great. Now I'm trying to develop the code for the bus reader and display.As mentioned before, I figured the easiest way to do it was to buffer the buses, then put them directly into three of the four 8-bit ports on an ATmega. I found that the MAX7219 has a "no decode" mode that allows you to make whatever shape you want, so I'm using that now. This makes things easier as now all I need is MISO, MOSI and SCK going to it.However, I seem to be losing my mind. This is such simple code that I could have written it back when I first started learning C for AVR yet for some reason it's glitching to all hell. Add to that my AVR Dragon being on the blink (so no debug) and I'm frustrated.I'll attach the code. Note that the _delay_us() commands in the SPI commands are just there as debug tools. Normally I'd be using the correct while(!(SPSR & (1<<SPIF))).The symptoms are: upon power-on, and with none of the code commented out, the ATmega correctly calls the setupSPI() routine. It then correctly does the first half of the routine (as I've been using my scope to manually decode some of the data). So it sets all the registers within the MAX7219 correctly. After that, everything goes NUTTY. Even when I comment out the getBuses() routine and leave in the "Set display to all Fs" in the setupSPI routine, it still takes off running like a bee-stung horse. It literally PACKS the SPI bus with random data, even when I put delay_ms() statements in strategic places. There are no loops except for in the main() function, so I don't understand what the hell it's doing. I've used SPI a million times -- usually it's the bus that gives me the least trouble. Usually it's I2C that gives me trouble...Anyway, I know the code itself might not help anyone to help me, but for now it's all I can do. I can post some logic analyzer video of the problem if anyone thinks it'll help...

author: MrAureliusR
author_rank: Unknown
timestamp: May 31, 2014, 08:15:12 am
content: Quote from: rob77 on May 27, 2014, 08:26:25 amThat's a cool idea! I didn't think of that. Instead, I switched the LS00 to an LS20, a 4-input dual NAND chip. I'm using one half for the LS193 decoding, the other half will be used as a 2-input NAND for another purpose (by tying two inputs high). I knew it'd be easier if I swapped them, but I was just dreading trying to pull the chip out from under a million wires. But I did it.Thanks for the tip, though, I'll definitely try that.I really need to switch some of my chips to HC...

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 31, 2014, 09:58:05 am
content: Optimization settings..??Tim

author: Dave Turner
author_rank: Frequent Contributor
timestamp: May 31, 2014, 04:38:53 pm
content: While not the answer to your problem I'd consider using the 'switch' statement rather than multiple 'if's if possible. It is more efficient, requiring less compares.

author: MrAureliusR
author_rank: Unknown
timestamp: June 01, 2014, 09:22:48 am
content: Yeah, I usually use switch statements too. I had some reason for not using them here, but it was late and it was probably my brain playing tricks on me.I'll check the optimization settings as well. I'm almost considering using learning how to use PICs because all my Atmel gear is crapping out on me. Is there a JTAG debugger for Microchip parts?

author: Dave Turner
author_rank: Frequent Contributor
timestamp: June 01, 2014, 09:44:31 am
content: I could see timing being an issue possibly. If you remember let us know, I'd be interested in the logic.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 01, 2014, 03:28:04 pm
content: Quote from: Dave Turner on May 31, 2014, 04:38:53 pmTwo notes: 1. I haven't looked at the specific code example above; 2. I haven't looked at a typical (e.g. GCC) implementation of the structure in question, either.That said,It's worth noting that AVR does indirect addressing rather inefficiently; using the pointer itself is as quick as anything, but it takes a lot of math and bounds checking to set up a pointer to a jump array (which is, AFAIK, the typical implementation of a 'switch' statement). Whereas simple comparisons are only a couple clock cycles (one to load the constant (the.. er, comparand?), another to perform the comparison, and a branch or skip to do the actual conditional). The array method is O(1) while the chained-ifs method is O(N), but by definition that's only important for large N. I would guess for N < 5 or so, the chained-ifs will be better.YMMV. If you have to put something like this in a time-critical inner loop, do check the assembler output to see if it makes sense or not.Tim

author: MrAureliusR
author_rank: Unknown
timestamp: June 01, 2014, 11:46:09 pm
content: My brain is collapsing into a black hole. Seriously. This is an epic frustration. I can't think of simpler code, but I can't seem to implement this.I'm seriously looking at using the PIC's I have laying around. I've never really ever used a PIC before, though I do have a few of them, and I do have MPLAB installed on my Windows install. I have one of the imitation PicKits (which has worked fine whenever I've had to use it) and I also have a MiniPro with the ICSP header installed, so programming the things shouldn't be a problem. I just don't want to have to learn a whole new chip just for this one application... *sigh*.However, I've wanted to learn how to use MPLAB for a while now, and C is C is C, so it can't be THAT hard. That said, I just wish this damn code would work! I've tried it with an ATmega32A, an ATmega644, and an ATmega1284 (which are almost identical, besides the flash capacity -- I just wanted to rule out faulty chips), and the results are all crazy crap. So it must be my code, but I really can't see why...Does anyone have any good "learning PIC" resources?EDIT: I just noticed that I have two or three PIC18F4450s, which have USB built-in... hmm. That could be handy later on...

author: jamesglanville
author_rank: Contributor
timestamp: June 05, 2014, 07:08:27 am
content: Have you considered just getting some test code written using the arduino libraries? It wouldn't take much time to do and you would be able to rule out any hardware bugs. Just a thought, it's what I do when I get stuck.