Electronic – Randomization of events in old hand-held games

digital-logicrandom number

I have very little background on electronic design.

After studying a bit on how pseudo-random number generators work on general purpose computers, I became curious on how old hand-held games (like the Mattel Electronics series) randomized the events occurring in the game. As far as I know, many of them didn't utilize microprocessors at all.

Did they occupy a pseudo-random number algorithm implemented with basic electronic components, or are there ways of producing random-like numbers with basic electronic components? If such ways exist, why are they not available on our general purpose computers?

The main reason for my question stems from the need to seed the random number generator. Those primitive handheld games didn't seem to have a clock or something that could act as a seed (or perhaps they had a seeding counter running even if the game was turned off but connected to the battery?)

Best Answer

From the older machines that I have looked at, often a clock was kept running via a small cell battery. And the time on that clock at start up was checked and used for various calculations. I'll try to dig up a concrete example when I get home from work!

Edit:

One common way of implementing this was through the classic 555 timer chip, circia 1971 (Either the IC or designing one with electronic components) An explanation of the chip can be found here:

http://en.wikipedia.org/wiki/555_timer_IC

This chip can typically be found in any hobbyists toolbox, but how do we use this chip to generate random numbers? The short answer is that we cannot, we must use this in conjunction with other coutning circuits etc. While today these can be found in convenient IC packages, they can be recreated with common components. I tried to prepare a good example, but managed to find a much better one online! An example of such can be found/explained here:

http://www.engineersgarage.com/electronic-circuits/random-number-generator-using-7-segment-display

Hope this helps! :)

Related Solutions

Electronic – Why old PMOS/NMOS logic needed multiple voltages

The 8080 used nMOS-only technology (no CMOS = pMOS and nNMOS). When you use nMOS (or pMOS) devices only, you have a couple of choices to build a logic inverter cell (see chapter 6.6 in this document, my answer borrows heavily on this source):

nMOS transistor and pull-up resistor. Simple, but not good on an IC because the resistor would take up a lot of space on the silicon.
nMOS transistor and a second, saturated nMOS transistor in place of the pull-up resistor. Not bad, but the high-level output voltage will stay one threshold voltage V_GS,th below the supply voltage. (Note: V_GS,th is the voltage between a FET's gate and source that will just turn on the FET.)
nMOS transistor and a second, non-saturated (= linear) transistor in place of the pull-up resistor. High-level output voltage will swing all the way to V_DD, but this comes at the extra cost of an additional voltage V_GG with V_GG > V_DD + V_GS,th. This is the reason for the +12 V rail.
nMOS transistor with a second, depletion-mode n type transistor in place of the load resistor. No additional supply rail needed, but the technology is more sophisticated because two differetly doped transistors need to be made on the same chip.

It seems that the 8080 uses option number 3.

The reason for the negative rail (-5 V) could be the bias needed for a cascode configuration. This would increase switching speed at the cost of an additional supply rail. I can only guess here because I have not found any sources telling me that the 8080 really uses cascode-connected stages. Covering the cascode would be another story; this configuration is used for linear amplifiers, logic switches, level-translators or power switches.

How Verilog decides upon simultaneous events

The Verilog standard guarantees that all events within a begin..end block scheduled for the same simulation time will be processed in the order they are declared. Other than in this specific scenario every other event may be taken out of the queue in any order.

With this said, any behavior can be expected because both events are scheduled for the same simulation time in different code blocks. Nevertheless, the behavior you have is what is generally accepted as correct, because data is not sampled in the same simulation time where it is generated.

Things you could do to improve predictability:

Generate your clock using a blocking assignment.
```
always #10 clk = ~clk;
```

Generate stimuli on clock events.

initial
begin
    repeat (2) @(posedge clk)
        x <= 1;
end

This coding will, in general, guarantee that the RTL simulation will behave as the final gatelevel netlist without requiring data delays. In an RTL simulation, data must not be generated and sampled in the same simulation time.

Best Answer

Related Solutions

Electronic – Why old PMOS/NMOS logic needed multiple voltages

How Verilog decides upon simultaneous events

Related Topic