Kestrel 8K Finished!

[kc5tja]

GARTHWILSON wrote:

SPI can be used for all kinds of things although it will be kind of slow for some bus uses, especially if you have to bit-bang it for lack of hardware. Even the bit-banging is easy though, and you could hang several SPI's on a single VIA. As long as you have connectors to interface a VIA to the outside world, SPI can be implemented without advance planning.

I wonder how hard it'd be to build an SPI interface with discrete logic? I'll have to play with that idea. I certainly don't need it right away of course; but, if I ever put an FPGA in a future Kestrel, it would certainly be worth-while.

Quote:

You can load a set of 74xx161's for the counters and have them increment automatically with each access. What you're describing sounds very much like a parallel extension bus I devised (PXbus) for my "next computer" which has been extremely slow in coming partly since upgrades on the old one have breathed new life into it. Since then I have mostly scrapped the PXbus idea for several reasons, including size, the quantity of hardware required and the need to have it simple enough to complete within my lifetime , and that in spite of how attractive it looks, I find that I have not really needed the PXbus in my scores of workbench-computer projects over the 13 years of use since it existed in its original version.

I'm seriously considering adding a bus like this in the Kestrel then, in both directions. It's actually VERY close to how the IPL circuit currently works (indeed, I can re-use the same PXbus hardware to IPL the system with. Hardware re-use is good). It probably would be only one or two slots of this nature though, as I'm primarily interested in this kind of interface for computer low-overhead networking applications, video, and audio interfaces.

SPI could handle the remainder of the I/O functionality. SPI can go pretty fast -- tens of megabits per second -- that's competing with 10-base-T. I suspect that there really isn't anything preventing the basic SPI concept from going hundreds of Mbps either, except for basic expectations of the slave hardware.

I'm even toying with a means by which SPI devices can master its own bus too using a PCI-like REQ#/GNT# interface. If you want the bus, assert REQ#. If GNT# is not asserted, you are a slave device. If GNT# is asserted, you are now a master. GNT# is qualified by REQ#, so you can never be a master without having REQ# asserted concurrently.

Quote:

There are four modes (mode 0 through mode 3) but I think mode 3 is a lot more common than the others. The modes have to do with the clock polarities. It's quite simple though-- set the desired device's select line low and clock the serial data in and out (simultaneously). How you feed instructions, addresses, and data to the device, and what the output means, will depend on the device and will be in the data sheet.

How does a piece of hardware know what mode it's operating in? How does the master know? Does it set the clock polarity *prior* to asserting the SS# signal? Then, how does it negotiate on what edge the data is clocked in? I've not found any documentation on any of this, except for the existance of the four modes.

The only thing I can think of that reliably covers all of these things is that you have one SPI bus dedicated per mode (e.g., to support all four modes, you'd need four SPI buses, each set to a different mode).

[GARTHWILSON]

> I wonder how hard it'd be to build an SPI interface with discrete logic?

You mean so you can just read and write whole bytes and instructions, read status, etc., instead of bit-banging? It doesn't seem like it would take much. I've always bit-banged them on 6522 pins. It's very easy to do, both in hardware and software, but you certainly won't hit 40Mb/s that way.

About SPI modes (I'll skip quoting your two paragraphs): Without looking through every datasheet I have on SPI parts again, I'll comment from memory. I really should write up a synchronous-serial primer for the primers and tutorials section though, because there's a wealth of synchronous-serial parts to be taken advantage of and most people on this forum seem to be unfamiliar with it all in spite of how easy it is.

Code: Select all

            | ck on  | ck on      (data is changed immediately
            | rising | falling        following opposite edge)
------------+--------+--------+
idle ck lo  | mode 0 | mode 1 |
------------+--------+--------+
idle ck hi  | mode 3 | mode 2 |
            +--------+--------+

Modes 0 (idle clock low) and mode 3 (idle clock high) require the data to be valid and stable before the rising clock edge. Slave parts can change the logic state of their data-out pin on the falling edge since both master and slave latch the incoming data on the rising edge and some parts can be daisy-chained. (Daisy-chained parts would all have to be connected to the same select line.) Mode 1 (idle clock low) and mode 2 (idle clock high) require data to be valid and stable before the falling clock edge. I don't really see where the difference between mode 0 and mode 3 would matter much since a possible falling edge before the first rising edge after a select line goes down is not going to confuse any parts. According to a 40-page data sheet in front of me, the Atmel Dataflash AT45DB642 8Mx8 serial flash memory (kind of small by today's standards) works in modes 0 and 3, apparently without knowing or caring which of these two modes you're using. The master still puts the first instruction bit on the data line before the first rising edge regardless, and the slave isn't going to send any data anyway until it has decoded an instruction telling it what to do. The possible exception I can think of is the situation where parts are daisy-chained, but I've never done that and I don't think all parts even can be daisy-chained. Maybe that's for something like using dumb logic shift registers like the 74HC595 (serial-to-parallel) or the 74HC165 (parallel-to-serial).

You could mix parts that work in the different modes on the same SPI, as long as you don't simultaneously select mulitple parts that are made or set to operate in conflicting modes. That would mostly mean no daisy-chaining of parts that don't all work in the same mode-- hardly a penalty! For addressing SPI parts one at a time (or one chain at a time), you would just set the master to operate in the appropriate mode for the part or chain you're about to select. If some parts can go faster than others and you want maximum speed, you would also set the clock speed appropriately before communicating with each part.

Bytes are always sent most significant bit first. All data frames are 8-bit. There is no extra acknowledge bit like I²C has, no parity, start, or stop bits, etc.. As you can see, the 6522's SR is nearly compatible with SPI modes 0 and 3. Right now I don't remember what keeps it from being 100% compatible.

Microwire is essentially SPI mode 0, except that you supposedly can't ever daisy-chain Microwire parts.

You can use the same SPI master's clock and data lines (with a pull-up on the data) for I²C too as long as you observe a few rules:
1. SPI mode must be 0 or 3, not 1 or 2 (because of rule #2:)
2. Never transition the master's data-out line while the clock is high unless you intend to produce a start or stop condition on I²C.
3. (obvious:) Don't have an SPI or Microwire select line low when addressing I²C parts.

The official spec. says I²C's clock and data lines are supposed to remain high when inactive; but in my limited experience, it simply doesn't matter what these lines do between the time a "stop" condition is generated and when the next "start" condition is generated. Maybe the idea is that low-power devices can scavenge their power from these lines between low pulses, like 1-Wire.

[kc5tja]

GARTHWILSON wrote:

You could mix parts that work in the different modes on the same SPI, as long as you don't simultaneously select mulitple parts that are made or set to operate in conflicting modes.

Based on this, then, the bus mode is therefore an intrinsic attribute of the slave device addressed, and that the different modes are there only as a concession towards chip manufacturers who find it easier to make an active-low clock in one part, and an active-high clock in another.

[GARTHWILSON]

Could be. I'd have to dig deeper to find out for sure. I've used several SPI, Microwire, and I²C parts. Although I've used a few at a time on the same interface lines, I can't claim to have used a vast array of them. But just working from the data sheets for things like waveform charts and instructions, every part I've tried has worked right on the first try, with the exception of an ST Microelectronics 24256 32Kx8 EEPROM in an 8-pin DIP which was quite a challenge but I eventually got it figured out. The data sheet omitted some info on polling for busy status at a point in the operation where they probably figured no one would ever poll; but I had my routines set up modularly in a way that it was easier to leave an unnecessary busy poll in the read instruction, and there should have been a stop condition following it, unlike the situation with a write instruction busy poll.

However, it looks like I might need to clarify that when I said "idle clock low" or "idle clock high," I meant the state when a device is not selected, since parts are edge-triggered, and the idle state only tells which edge will come first, rising of falling.

[kc5tja]

GARTHWILSON wrote:

However, it looks like I might need to clarify that when I said "idle clock low" or "idle clock high," I meant the state when a device is not selected, since parts are edge-triggered, and the idle state only tells which edge will come first, rising of falling.

OK, now I'm really confused. So we can't mix devices of various modes on the SPI bus, because some are sensitive to the CLK line even when their SS signal is negated?

[GARTHWILSON]

The SPI device is selected by its active-low (level-sensitive) chip-select input. Once it is selected, what matters on the clock line is the clock signal's edges. If the part's chip-select line is false (high), the part will ignore the clock and data lines, so you can do whatever you want with them, whether that means running them much faster for something else that can take it, or even using them for something unrelated to SPI.

Stop reading here if you don't want things confused further by the possibility of using the same clock and data lines for I²C as well.

I said above that when SPI parts' chip-select lines are false, what happens on the clock and data lines is irrelevant. That means you can often use them for I²C as well, among other things. I²C does not have chip-select lines. It is truly a 2-wire interface, having only clock and a bidirectional data line. The PC keyboard interface is almost I²C. Every I²C device, including the bus master, has an open-collector (or open-drain) data I/O line. If you want to be able to pass control around, then the clock line needs to be open-collector too, and both these lines will have pull-up resistors, typically 4.7K, to 5V. That's why I²C is often limited to only 400kbps, and sometimes as high as 1Mbps, which is much slower than SPI's maximum speeds.

Although the 6522's I/O lines are not open-drain, you can still implement I²C easily. You just leave the particular bit in the output register clear (0), and then change the corresponding bit in the port's data direction register, making it an input anytime you want to read the bit or "output" a 1, or making it an output anytime you want to pull the line down to output a 0.

What gets the I²C devices' attention is a "start" condition, consisting of a falling edge on the data line while the clock line is high. A "stop" condition consists of a rising edge on the data line while the clock line is high. With SPI modes 0 and 3, there is no reason to transition the devices' data-input line while the clock line is high, so there's no conflict here. The first byte sent after generating a "start" condition will tell the I²C devices which one is to pay attention.

SPI requires a clock line, a data line from the master to the slaves, a data line from the slaves to the master, and a select line for each slave device. Microwire parts can usually be treated as SPI mode 0, and dumb 74HCxx shift registers can often be put on the same interface. I²C has only a clock line and a bidirectional data line. SMbus is basically the same as I²C except that there are time-outs if you interrupt a data transfer for too long. I've never used it. 1-Wire is the connection miser of the bunch, but has strict timing requirements that even allow the master to provide the clock while the slave is outputting data on the same line. It's simpler than it sounds, but you do need microsecond-resolution control over when to pull the line down or let it up.

As you can see, you can make a multi-protocol serial bus that would accommodate the several synchronous-serial interfaces with a few pins of one VIA.

[lordsteve]

You guys really need to look into these beautiful babies: SX Microcontrollers. They are cheap, can be clocked to 75+ MHz (that's right), have programmable IO pins, onboard RAM, at least 2K program ROM, and the dev board is less than $100. I'm sure a homemade device programmer could be built for it.

http://www.parallax.com/sx/index.asp

I love these things. They can be utilized to supplant/enhance much peripheral functionality. They are fantasmic bitbangers. I made an 8-channel audio mixer and even a (1/5) VGA controller with one.

I have been toying with the notion of making like a memory "bridge" with the SX52 flavored device. 40 IO pins!!!

[GARTHWILSON]

Since you have some experience with them, can you outline some differences between them and the Microchip PICs for us? I've used the PICs a lot and will probably use one for microprocessor support or even I/O support for my next 65K computer; but when I last went to Scenix' website (maybe a couple of years ago), they seemed to be nearly out of business and unable to ship any real products. It was my impression that their processor core was the same decrepit thing used in the PICs (just faster), but someone said the Scenix did have a few improvements. The PICs have a MHz advantage over the 65c02/816, but they still take 4 clocks per instruction, and it takes them twice as many instructions to do a job as the 65K's do-- if the PIC can even do it at all. Having the serial ports handled in hardware would definitely give a speed advantage though. Using the PIC or SX in a parallel slave port (PSP) fashion to essentially design your own I/O IC is an attractive idea if you can get around some of the inherent limitations. (An example of the PSP limitations is that you can't just read a register directly in a single read with register-select pins like you can a 6522. You may have to see if it's still busy carrying out a previous instruction, then tell it that in the next read operation you want to read a certain RAM address, give it time to move things around, and then finally get the data you wanted. If you write to it, you may have to see if it's ready, then tell it what you're going to be writing, give it time to process that, and then do the write, etc.. It may just be easier to do the bit-banging with a 6522.) Edit, 10/19/18: Microchip's ap. note AN579, about using the PSP, is at http://ww1.microchip.com/downloads/en/A ... 00579b.pdf .

[lordsteve]

Parallax has become the master distributor for Ubicom's (formerly Scenix) SX Microcontroller line.

http://www.parallax.com

These SX devices are similar to the PIC 16C5X series. Differences include:

Faster clock speeds (75 MHz+)
Pipeline hardware for single-cycle execution (75 MIPS at 75 MHz)
More RAM (at least 128 bytes, I think)
Added instructions
An analog comparator input
Flash program memory (NOT one-time programmable)
Traditional DIP packages or surface mount
Real time clock counter (RTCC) roll over interrupt!!

That's off the top of my head. Business for these devices has been quite good from what I understand--they aren't going away anytime soon. I didn't know anything about Scenix (now Ubicom) before recently so I can't comment on that period. I believe it is virtually the same processor as the PICs.

They are master bitbangers believe me. Please have a look at parallax's web site and look at the data sheet. They aren't the perfect solution for every problem, but they're VERY useful.

[kc5tja]

I will need to evaluate them, but I was looking into using Atmel microcontrollers myself. I understand that the AVR series of microcontrollers have a substantially improved instruction set over the PIC architecture.

Although, at 75MHz, the SX microcontroller might be viable for use in producing video somehow...

[8BIT]

While developing my video project, I played with both the PIC and AVR chips. I found the PIC instruction set very limited, and as Garth mentioned, the through-put was poor. The AVR instruction set is similar to the 6502 set, which made it much easier to write assembly code for. It has a similar set of on-board peripherals as the PIC. The AVR's have bit-addressable IO instrcutions which make bit-banging a snap. The AVR's that I have used are 16MIPS/16MHz parts. They do have some 20MHz parts.

Daryl

[coredump]

I've also used both PIC and AVR chips, and I'd never use the PIC again! the AVR is just so superior. The things that really annoyed me about the PIC were the lack of registers and the need to do bank-selection of RAM. The PIC only has a single accumulator (the W register) and no index registers, whereas the AVR has 32 general purpose registers -- and us 6502 programmers know all about the importance of having plenty of registers. And I just got fed up with having to switch memory banks just to access the I/O locations on the PIC.

Plus, there's a C compiler (GCC) for the AVR (the package is called WinAVR, and it includes an Open Source chip programmer called AVRdude and a simulator called simulAVR).

[wirehead]

I'll have to second the "use an AVR" statement.

The biggest advantage to the AVR is that they built it to run C-like languages. And it's pipelined, so it gets around 1 CPI instead of the 4 CPI that you get with a PIC. So it's altogether a nice processor. I've been messing with 'em lately.

Unfortunately you can't fit forth on any of the DIP package parts. Which is quite a shame.

Really, if the AVR's not good enough for you, they are starting to come out with small, economically priced ARM microcontrollers that will leapfrog the Scenix.

I'm pretty sure that you can connect the 6522 and the AVR's USART, where the AVR's USART is slaved to the 6522 clock, as a way to avoid bit-banging on the main CPU.

[Memblers]

Sorry to go off-topic maybe a bit, but a few weeks ago I found a company that makes 6502-based microcontrollers with Flash memory (all the ones I'd seen before used mask-rom). Has anyone else heard of anything like that or used one?

I really wish I had bookmarked it.
I thought it was at umc.com (maybe not tho), but if it was I can't find it again in their maze of a website.

Also, I can't recommend a PIC over anything else, since that's all I've used. But the 18F PICs ditched almost all needs for bankswitching and also has indirect index address with the PLUSWx instruction (though that only works for RAM, table reads do the ROM). It's much better for me than PIC16, especially since I use the heck out of the 8x8 hardware multiply for my sound code, heheh.

[Wally Daniels]

Memblers wrote:

I really wish I had bookmarked it. :oops:
I thought it was at umc.com (maybe not tho), but if it was I can't find it again in their maze of a website.

Was it www.micronas.com by any chance ? Specifically the CDC 08xxE
family ?

Wally