16-bit 1802 hybrid?
- I've been noodling around an idea for running two 1802 chips as quasi-parallel processors where one is dedicated to the upper byte of 16-bit operations and the other to the lower byte. The idea is to use the MSB processor (in most cases) to do the fetches of real 8-bit opcodes, while the LSB processor gets fed either the same or suitably altered opcodes.
As I see it, it's a matter of finding an efficient external way to keep track of what the DF value is for the LSB for instructions that can change it -- adds, subtracts, and rotates -- and then fiddling with the relative clock phases of the MSB and LSB processors so that for those DF-modifying instructions are completed in the LSB chip before allowing the MSB chip to complete the equivalent operation.
The "easiest" cases are the add and subtract instructions. The LSB performs these instructions with little or no modification, and an external DF flip-flop -- call it DFL -- acts as a carry-in to the MSB chip. Now, getting that carry bit into the MSB processor is a bit more involved.
I've considered several options, but the simplest seems to be an 8-bit presettable UP/DOWN counter with a tristate register. The counter gets the B-register add/subtract value from memory, then, depending on DFL and the instruction being executed is incremented, decremented, or left unchanged before being switched onto the MSB processor data bus, whence the MSB chip completes its execution.
Shift instructions might require as little as keeping track of the MSB and LSB bits of both D registers, provided a clever way can be thought of to sneak those values into their proper destinations to make the two D registers behave as if they are part of a 16-bit + carry bidirectional shift register.
Anyway, that's as far as I've managed to blue-sky this idea.
- David Keith wrote:
> Just a quick reply, use an internal freq doubler...That could work. Though I think they found it simpler to just run the
oscillator at a high enough frequency so simply dividing it down was
William Donnelly wrote:
> That quoted comment doesn't really make sense to me. if theAs many things as possible are done in parallel. In most cases, this is
> instruction cycle is 8, how does it do all of the other things it needs to
> do, like getting the value(s), etc., and then storing the results, as
> well as perform an 8 x 1-bit ALU. It looks like you need more cycles.
easy, like loading all 16 bits of a register at once. In other cases,
they can be allowed to overlap. For example, if we tell the ALU to add
- The Fetch cycle (8 clock cycles) gets the instruction.
Aha; it is ADD.
- The Execute cycle (8 clock cycles) puts the memory address
out on the bus, and sets /MRD low to read. The byte
won't be back from memory until the end of this cycle.
- The *next* Fetch cycle (8 clock cycles) begins. While it
is getting the next instruction, the ALU has all 8
clock cycles to serially add D and the memory byte.
- The next Execute cycle thus begins with the ALU result
complete and available for use.
8 clock cycles is enough to add two 8-bit binary numbers with a 1-bit
serial adder, because it can do it during the Fetch time of the
Ring the bells that still can ring
Forget your perfect offering
There is a crack in everything
That's how the light gets in.
-- Leonard Cohen, from "Anthem"
Lee A. Hart, http://www.sunrise-ev.com/LeesEVs.htm