Maker Pro
Maker Pro

How does Floating MOSFETs in a PROM actually create a group of instructions?

M

Mr. J D

How does the Floating MOSFET array in a PROM turn into a group of
instructions? I mean, you burn the "fuses" allowing for either a 1 or a
0 on each MOSFET, but how does this in turn, turn into a, do this if
this does that. Whats actually occuring?
 
B

Bill Beaty

Mr. J D said:
How does the Floating MOSFET array in a PROM turn into a group of
instructions? I mean, you burn the "fuses" allowing for either a 1 or a
0 on each MOSFET, but how does this in turn, turn into a, do this if
this does that. Whats actually occuring?

You mean, "How do computers work?"

:)

It's actually possible to make a primitive computer from nothing but a
bunch of PROMs and parallel latches. For example, get some 16-bit
PROMS with 16 address lines (having 64K words of storage). Bring all
the PROM data lines out to a 16-bit latch, then connect the sixteen
latch outputs back to the PROM address lines.

Now whenever you send a clock pulse to the latch, it grabs the bit
pattern which is currently on the PROM data lines and uses it to point
to the address of a different PROM memory location. But what's coming
out of the PROM data lines? You'll have to burn something there before
you start! In each PROM memory location you manually enter some data
which determines the next memory location to be accessed. Depending on
what you store in the PROM, you can make a counter which counts up. In
location zero you put "0001," in location one you put "0002," etc., so
each location will force the device to jump to the next higher one. Or
make a counter which counts down, or one which skips all over the
place. The contents of each PROM location can make the current address
skip around to any location desired, in any pattern.

So with just a PROM and a latch, you've made a programmable counter.
The whole device together is called a "state machine."

Next add some more PROMs in parallel so you have 32 bits of output
instead of 16. Hook the new PROM to the same address lines. You can
put anything you want in the other 16-bit data locations. Now, as you
pulse the latch and the address skips around to different values as
before, you can make the new data lines put out bit patterns, or
pulses, etc. Hook them up to control some other devices. Now you've
got a programmable counter which has 64K different states, and each
state can spit out 16 control lines which can put out any bit pattern
you want.

But this device would just spit out data in an unvarying sequence, like
a music box or player piano. Right... so we need to add some inputs.
What if we used 128K PROMS instead of 64K? And what if we used the
seventeenth data line as an input? We could make that extra input do
nothing: just take the 64K data contents made earlier, and copy it into
the upper 64K of address space in the 128K PROM. Now the seventeenth
address line does nothing, since you'd select the same data regardless
of whether it was high or low. But next... in some memory locations we
could write different data. If we did this, then when the PROM was in
one of those states, it would respond to the extra input line and do
one of two different things. We could make it go into a different
pattern of jumps. Or we could keep the jumps the same, but have it
spit out a different data word depending on whether this new input was
high or low. Or do both.

Doesn't this seem wasteful though? To get just one input line, we've
doubled our memory from 64K words to 128K words. And most of the PROM
contents are duplicated in the high and low areas. Yet this PROM can
be programmed to do mildly interesting things with its 64K worth of
counter, and with its one input and 16 output lines. So we ignore the
huge redundancy of memory. Or at least tolerate it.

Now suppose we make the PROM memory eight times larger, so it now has 3
new input lines for a total of 4. LOTS of redundant or empty memory,
eh? But ignore that, because we've just made a primitive controller, a
"state machine" with 4 inputs and 16 outputs.

Next, connect some of those outputs to control an 8-bit latch, and call
this an "accumulator." Use other outputs to command some data
selectors to steer the accumulator to an 8-bit adder and back to the
accumulator. Use other outputs to talk to a RAM memory with an address
latch, a stack control system, other latches (called "registers,") and
all sorts of other stuff. The PROM-based state machine is now the
heart of an 8-bit microprocessor.

I hear that the old 6502 chip used in Apple II computers was just such
a device. It had a PROM which was mostly full of empty locations or
redundant data, while using some of its data lines as "next address"
locations, other data lines as control lines for CPU internals, and
using extra address lines as inputs.
 
P

Paul Hovnanian P.E.

Mr. J D said:
How does the Floating MOSFET array in a PROM turn into a group of
instructions? I mean, you burn the "fuses" allowing for either a 1 or a
0 on each MOSFET, but how does this in turn, turn into a, do this if
this does that. Whats actually occuring?

All uP instructions are nothing more than data. The processor just
fetches bytes at the instruction pointer location and interprets them as
instructions. Same as reading executable instructions from RAM, but with
microcontrollers the program doesn't change. So its just burned into a
PROM (or an EPROM, or other non-volatile memory).
 
J

Jeff Higgins

Mr. Bill Beaty said:
You mean, "How do computers work?"

:)

It's actually possible to make a primitive computer from nothing but a
bunch of PROMs and parallel latches. For example, get some 16-bit
PROMS with 16 address lines (having 64K words of storage). Bring all
the PROM data lines out to a 16-bit latch, then connect the sixteen
latch outputs back to the PROM address lines.

Now whenever you send a clock pulse to the latch, it grabs the bit
pattern which is currently on the PROM data lines and uses it to point
to the address of a different PROM memory location. But what's coming
out of the PROM data lines? You'll have to burn something there before
you start! In each PROM memory location you manually enter some data
which determines the next memory location to be accessed. Depending on
what you store in the PROM, you can make a counter which counts up. In
location zero you put "0001," in location one you put "0002," etc., so
each location will force the device to jump to the next higher one. Or
make a counter which counts down, or one which skips all over the
place. The contents of each PROM location can make the current address
skip around to any location desired, in any pattern.

So with just a PROM and a latch, you've made a programmable counter.
The whole device together is called a "state machine."

Next add some more PROMs in parallel so you have 32 bits of output
instead of 16. Hook the new PROM to the same address lines. You can
put anything you want in the other 16-bit data locations. Now, as you
pulse the latch and the address skips around to different values as
before, you can make the new data lines put out bit patterns, or
pulses, etc. Hook them up to control some other devices. Now you've
got a programmable counter which has 64K different states, and each
state can spit out 16 control lines which can put out any bit pattern
you want.

But this device would just spit out data in an unvarying sequence, like
a music box or player piano. Right... so we need to add some inputs.
What if we used 128K PROMS instead of 64K? And what if we used the
seventeenth data line as an input? We could make that extra input do
nothing: just take the 64K data contents made earlier, and copy it into
the upper 64K of address space in the 128K PROM. Now the seventeenth
address line does nothing, since you'd select the same data regardless
of whether it was high or low. But next... in some memory locations we
could write different data. If we did this, then when the PROM was in
one of those states, it would respond to the extra input line and do
one of two different things. We could make it go into a different
pattern of jumps. Or we could keep the jumps the same, but have it
spit out a different data word depending on whether this new input was
high or low. Or do both.

Doesn't this seem wasteful though? To get just one input line, we've
doubled our memory from 64K words to 128K words. And most of the PROM
contents are duplicated in the high and low areas. Yet this PROM can
be programmed to do mildly interesting things with its 64K worth of
counter, and with its one input and 16 output lines. So we ignore the
huge redundancy of memory. Or at least tolerate it.

Now suppose we make the PROM memory eight times larger, so it now has 3
new input lines for a total of 4. LOTS of redundant or empty memory,
eh? But ignore that, because we've just made a primitive controller, a
"state machine" with 4 inputs and 16 outputs.

Next, connect some of those outputs to control an 8-bit latch, and call
this an "accumulator." Use other outputs to command some data
selectors to steer the accumulator to an 8-bit adder and back to the
accumulator. Use other outputs to talk to a RAM memory with an address
latch, a stack control system, other latches (called "registers,") and
all sorts of other stuff. The PROM-based state machine is now the
heart of an 8-bit microprocessor.

I hear that the old 6502 chip used in Apple II computers was just such
a device. It had a PROM which was mostly full of empty locations or
redundant data, while using some of its data lines as "next address"
locations, other data lines as control lines for CPU internals, and
using extra address lines as inputs.
Well done! A most gracious reply. Thank you. JSHiggins
 
Top