|
The parts with the staggered pins that I recall are the 6511Q's. They did, indeed, have the 650x core shared by other Rockwell members of the family.
I've been fiddling with a 650x-core for about half a year now, though not very intently. I'm trying to find a way to operate the device at something approximating the maximal frequency at which the device will go without using so much of its resources that there isn't room for sufficient I/O to make it useful. I'm seriously looking at adding an I/O instruction pair, e.g. IN and OUT, in order to save on subsequent decoding.
For those thinking along similar lines, I'd point out a few things that will expedite visualization of the core.
1. DATA PATHS - if it's not totally obvious to everyone already, one of the main advantages of the 650x architecture is that it can be implemented without the wide synchronous counters that many other processors have. This is because the ALU is used to operate on the addresses as well as the data. That way, while data is being move via the bus, arithmetic on the PCH, PCL, ADDRESS-BUS-HIGH, and ADDRESS-BUS-LOW as well as the index registers can be accomplished in time to be used during the next Phase-One cycle, when they're used. Further, data operations are only performed on one register at a time, you can add memory to A and A to memory, but not A to SP or Y to PCH. If you count cycles and consider the data routing around an 8-byte register set, not including the bus registers, but certainly including A, X, Y, SP, PCH, PCL, S, and an Impending Operand register for holding the last data from the bus, it's easy to visualize that as an 8x8 ram with two tristate buffers on its outputs leading to an adder/subtractor. likewise, it's easy to visualize, in parallel with that adder/subtactor, a large multiplexer capable of accomplishing the shift and rotate instructions, inserting as well as modifying the carry where necessary.
(2)In the interest of speed, it's likely an implementation in fairly fast CPLD or FPGA would probably use a multiple-clock processor cycle, thereby allowing the entire ALU to be halved in size, speeding it up and allowing it to be used twice rather than once. This also leaves room for shortening some of the instructions' execution times as opportunity avails itself. The address and the data execution engines will be different, somewhat, but not terribly so. The operands, either data or addresses, as suggested above, will always flow through the ALU, even when it does nothing to them. Since that is the case, the current PCL will flow through the ALU, being incremented on its way, and the PCH, likewise flows through the ALU if it needs incrementing. Of course it flows in either case, but the carry into the ALU determines whether it is incremented. Normally the carry to the ALU is true for the low byte, and is only true for the case in which the carry from the incrementation of the low byte was true.
I don't wish to contaminate the pool of thought which goes into such an effort with too much of my own influence, but it's good to remember that the reason the 650x was such a success is because it was thrifty and efficient with its resources. It used a complex resource (the ALU) throughly, in order to make large gates for a set of 8-bit registers configured as settable UP-counters (lotsa gates!) threby making the register set trivial as RAM.
The ALU had to have six or so levels of logic, so it couldn't be much faster than it already was. To avoid the added delay of relatively long synchronous counters, the designers decided simply to use RAM registers. Consequently, the processor cost less than a third of what any other processor had cost at its introduction. This was because the silicon was small.
If you want to consider this approach to making your own 650x core with an eye to adding fairly standard peripheral functions later on as well, I'd recommend you download the ALTERA MaxPlus-II v9.6, which includes support for VHDL, VERILOG, AHDL (their own HDL), and also provides a decent schematic capture package. It has simulation and extensive library component support, making it pretty easy to realize your own designs in "ISP" (in-situ-programmable) devices available at reasonable prices.
You can start small with the old "classic" devices, e.g. EP3xx, 6xx, 9xx, etc, if the programming hardware is avialable to you, or start out with the 3xxx or 7xxx series, both of which are programmable in-situ (or IN-SYSTEM, as the marketing guys like to say) via a well documented cable you can either buy or make, of which there are three versions.
XILINX has a free and downloadable "web-pack" which allows you to develop for their CPLD's (inexpensive and available through DigiKey, while you're getting used to the technology. These are all, by the way, reprogrammable, so using dense packages doesn't have to be a killer. Lattice/Vantis has several design suites available at no cost. They have a really comprenensive range of small to medium devices, essential for learning about the technology, though only some are suitable for a complete CPU.
ATMEL makes a line of parts also suitable for CPU's and other applications, tough their offering in the software department is not entirely complete, requiring third-party software components to make a complete package. They do offer the ABEL-HDL software for their smaller devices, however.
CYPRESS has a low-cost suite which supports either VHDL or VERILOG and is available bundled with a cable, CPLD, and a prototype board with one of their CPLD's on board. It's quite large and suitable for small CPU's, Disk COntrollers, all manner of COMM circuits, etc. It's a good enough buy that I even have one.
If you attack and execute this project you're guaranteed to be smarter than you are today when you're done.
Tally Ho!
Uli
|
|
Login
Register
FAQ
Search
