Quote:
I've seen the 28-pin green Textool and Textool(like) ZIF sockets on Mouser for $15 each. Now I would have thought this was THE most expensive until I saw some ARIES ZIF sockets. Even more expensive. About 2x the cost at $30 each, but it is a non-stocked item at Mouser.
Wow that's a lot!! I've never paid anywhere near that much, but maybe we're losing the economy of scale with less thru-hole prototyping and hobbyist construction now than there was years ago.
Quote:
I feel pretty confident about the memory and adressing logic and timing.
Have you checked the bus loading? I haven't looked up the data on the 74F stuff, but it looks to me like you have an awfully heavy bus load.
Quote:
I need a very simple video interface, old school 6545 video IC's I understand. SPI is totally foreign to me, but it seems like it's the norm for displays nowadays. Should I commit to learning the SPI interface? Would it be fast enough to display 8-bit data acquired <5MHz?
The
6545 was never made in the bus speeds you want, so you wouldn't be able to interface one directly unless you slowed the clock way down every time you wanted to address the 6545.
SPI can commonly transfer up to around 50 megabits per second in each direction, both directions at once, although we will have to wait for Daryl's 65SPI chip for speed anywhere near that. [
Edit: It's available at
http://sbc.rictor.org/65spi.html.] Otherwise you'll have to bit-banging through a VIA, or, maybe use a parallel slave port on a microcontroller that also has an SPI port. SPI is quite simple, and, since it's serial, will be a lot less work to wire up than a parallel port. And by the way, bit-banging is much, much easier and faster to do on SPI than it is on RS-232, since RS-232 is
asynchronous and therefore has stringent timing requirements. Don't confuse them just because they're both called "serial." There's a big difference. SPI has three bussed signal lines (four if you count an interrupt line): the clock line (always controlled by the master), MOSI (Master-Out/Slave-in), and MISO (Master-in/Slave-out), and then each slave has its own select line. The select line is the only one that's not bussed. Inactive SPI outputs are high-impedance. Since SPI doesn't have any bi-directional lines, level-translation (like 5V to 3V and vice-versa) is easy. The easiest way to get familiar with SPI might be to choose some kind of simple SPI part like a port expander (GPIO) or digital pot, and look at the data sheet and do a small project to make it work.
The
65SIB (serial interface bus) we've been talking about in other topics is just a way to connect a string of up to seven external SPI (and similar) devices in kind of a daisy chain, with a single pin-header ribbon connector on the controller and two on each device. It's primarily a definition of the connector to make peripheral designs and hardware somewhat portable between forum members. The main limitation to speed will usually be the 6502/816 master, and otherwise the individual devices and line length. The order of the wires in the connector ribbon is specifically arranged for good transmission over the ribbon cable. (Every signal line is next to a ground or virtual ground line.) 65SIB carries power too, so projects that don't use a ton of current won't need their own source of power (although they will need an onboard regulator). Interrupts are supported. 65SIB is not really 65-family-specific, just a 6502.org project. It was intentionally designed so a single port on the master could simultaneously accommodate a wide range of serial ICs from SPI to Microwire to 74HCxxx dumb shift registers for I/O, but also allow autoconfiguration of custom intelligent devices without putting the intelligence requirement on all devices. Non-intelligent ones simply won't respond to or be affected by autoconfiguration-type operations. The seven-device limitation can be exceeded by adding intelligent hubs. 65SIB is very simple to get basic operation from, but also allows much more sophisticated operations for those who want to delve into it that far. I need to write up a spec. sheet for the basics to post on this site, and kc5tja will be developing the autoconfiguration protocol when he has hardware to debug it. (That's my understanding anyway.) At this point the only thing here to refer to is the forum topic where we developed it, which is a lot to read through even if you only read the last half. I was also thinking about making some PC boards available to speed up the construction at the connectors and make them more suitable for fast slew rates.
As for
video, There are some graphics LCDs with SPI, and you might even find ones with built-in controllers to take certain commands to for example draw vectors, arcs, etc. without your main processor having to figure out which dots to turn on. Most intelligent modules can do the text (so you just tell it where to start and what to write and it figures out the rest), but the graphics commands would be beyond that.
Other popular, inexpensive synchronous serial interfaces: (Note: even though one company or another started a particular interface, there are many companies that make devices for it. For example, SPI is Motorola's baby, but lots of companies make SPI parts.)
Microwire is National Semiconductor's baby and is very similar to SPI.
I²C is Philips' baby. It uses only two signal lines, one for clock and one for data. Both are bi-directional, so you can even have more than one master, and they can arbitrate who gets control of the bus. Instead of having an individual select line for each device, every transaction starts with an address, and all devices listen for their address and respond only if it is called. Having only two wires makes for even a lot less wiring work than SPI, but its passive pull-up requirement on bi-directional lines and its open-drain outputs put quite a lid on the speed compared to SPI. (400kbits/second is a common limit.) There are two-wire interfaces that are not particularly called I²C but are still the same thing.
1-Wire is Dallas' baby and is even slower than I²C (but taking it too far, if you ask me). It's a little more complex since the one wire handles bidirectional clock
and data, telling the difference through timing requirements, so I think you have to really hate wires to drop from I²C or other two-wire interface (TWI) down to 1-Wire! It is more appropriate for slow things like a temperature sensor. Sometimes power is on the one wire too.
SMBus is basically I²C with time-out limits on devices that can tell the controller to wait because they're not ready to take more data yet. (Many I²C devices don't support that clock-stretching "wait" feature anyway, so although I've never used SMBus, I expect that for a lot of applications there would be no difference between SMBus and I²C.)
There are good Wikipedia write-ups on these.
Login
Register
FAQ
Search
