Display would be insane... Like 4x4 LCRY. Maybe 4x4 display RAM? So you prepare the image (16 pixels is image? lol) and display it at once. We could even make games, hell slow but not every game has to be arcade action oh oh oh.

In the case of display, I'm thinking of the idea that a command could be added that very quickly reads the RAM starting at a specified address and outputs 8 consecutive bytes to the display. Else an LED matrix like display would do for some simple PONG like games as the paddles and ball only need an X and Y value. But sadly tpt isn't nearly fast enough to simulate multiplexing multiple independent images onto an LED matrix.

 

Anyways, I've finally figured out that after all of these days seeing people absurdly concise multiplication programs, it turns out that they aren't insanely advanced and that people aren't hiding an amazingly efficient multiplication algorithm that I could never understand but that really, all they do is use a for loop structure to add the first operand by the first operand's initial value by a certain number of times equal to the second operand! voOov

 

Anyways, the advantage is that it can handle any 8 bit value under the condition that the result isn't greater than 255. The disadvantage is that the processing time is highly variable and impractical when handling larger numbers. Imagine that our computers had to loop an entire program 1 billion times when multiplying 1 times 1 billion in comparison to only 32 loops when multiplying two 32 bit numbers. So in the case of long multiplication algorithms, they are good in that the processing time is quite fixed in that anything times 0 would take the shortest and that anything times B1111 would take the longest in which the first operand has no effect on the time.

 

So happy machine programming everyone!

8 bytes? You mean 8x8 display or pixels with some colors or something?

Yay for xor, a universal gate. That means the machine can now do subtraction.

 

EDIT: I was thinking of NOR, not XOR. NOR and NAND are the only two universal ones.

It could before... It'd be just a complicated thus very sloooow algorithm. You just count how many 1s does it take for the second number to reach the first. It'd break on A < B, but still. And IF EQUAL is basically XOR, isn't it?

One thing I learned was to add a number to the 2s complement of the second number in order to get the difference. The only required addition which may have been mentioned was an additional NOT gate in order to invert the second operand. All you need to get the 2s complement of a number is the number inverted added to one. So A + !B + 1 is the same thing as A - B. The carry defines whether the number is positive or negative. An example is 0 minus 1. 2s complement of 0001 is 1110 + 1 = 1111. 0 + 1111 = 1111. Since there is no carry it is understood that it is negative. 0001 plus 1111 (1 minus 1) gives you 0000 with a carry. Hence it is a positive number.

 

The A minus B function could simply invert B, feed both A and B to the ALU then use a fixed buffer to add a one.

But we don't have NOT... :/ Btw, I didn't know that A + not B + 1 is A - B... How to prove this?

@Ferne (View Post)

NOT is A XOR 0xFFFFF..... so we do have a form of not.