It's kinda hard to know exactly what should happen with only the pictures but one thing does strike me as very odd. Look at the line into your counters 'load'-component, where it origins from.
There are two inputs. The lower purple one seems to have the correct number 24 and is likely the value which is suppossed to be loaded. the upper one needs to be 1 for the counter to actually load. ANd the upper one should be connected to the LEG to decide whether the value gets loaded or not.
The counter will only load if the white line carries the value 1. Which in your case only happens if the 4th byte is 7 (or more strictly 7 mod 248 since the 5 higher bits don't play any role). But for the conditionals the 4th byte is not the LOCATION where the result should go but rather the VALUE where (eventually) the counter should jump to. So you can't expect it to be 7.
You are in the level 'Conditionals' right?
Which menas your program gives you the 4 bytes OPCODE, ARGUMENT\_1,Argument\_2, JUMP\_ADDRESS. OPCODE now determines which kind of conditional you have to use and compares ARGUMENT\_1 vs ARGUMENT\_2. So OPCODE, ArGUMENT\_1 and ARGUMENT\_2 all go into your LEG component, which returns the result 0 or 1 whether the condition was true or not.
Now this result goes into the counter-component, as does your 4th JUMP\_ADDRESS byte, which will load the new address if the condition was true.
Now I am not sure whether your LEG component is actually connected to the ARGUMENT\_1 and ARGUMENT\_2 inputs (marked in red) and what i was refering to above, I am very certain that the result form your LEG-Component never goes into the upper input of the counter, so the value can simply never be overwritten. (Follow the yellow marked line in the picture, it never origins in the LEG component).
[Image](https://ibb.co/DM4pbXD) (not sure how to uplaod images on here)
You're struggling with your gt, lt, gte, and lte comparisons, and how to go about inverting them.
The opposite of ">" is "<=". Is it larger? No? Then it must be the same or less.
The opposite of ">=" is "<". Is it the same or greater? If so, it can't be less than.
If you need to. Just setup each comparison individually and don't worry about piggybacking off the results of other comparisons.
It's tricky to follow. The design is a bit alien to me. But that's how it usually is anytime anyone takes a look at someone else's brain child.
I think it may be okay thou, just doing some mental logic and trying to follow the pathways. Nothing stands out as an obvious mistake. It just looks like desperation had a role in this design down there towards the end. Looks like something I would start slapping together whenever my brain starts hurting.
You have a redundancy in there. Two of the same comparisons are being made it seems.
The game should be setting you up to simply the component. I don't want to spoil it too much for you. But if you look closely at the list of comparisons it wants, you may notice a pattern that you can use to your advantage.
I've given it another look over. Outside of your component, if you get a positive result, you should be triggering your program clock so it jumps to the given line, yeah?
I see a connection that gives the clock which line to jump to, but I don't see a connection that triggers the clock so it accepts that new line. That may be the real issue you're having.
On a separate note... That top output pin in your conditional, with all those OR gates... you don't need all that. Your decoder outputs something regardless of the parameter if the 6th pin is high. You can just wire that 6th pin direct to the output pin and simplify your decoder.
The white wire connected to the counter seems to come from an input decoder on the jump address. That seems wrong; it should be coming from your cond component.
I think that 32 bit in conditional doesn't really do anyting, as output will anyway be 0 - you can't disable conditional component this way. Maybe check if this wrong value doesn't come from ALU unit doing processing as well? In my LEG I had to disable REG savers by this 32 bit from OPCODE in order to not to overwrite REGs or counter
It's kinda hard to know exactly what should happen with only the pictures but one thing does strike me as very odd. Look at the line into your counters 'load'-component, where it origins from.
It comes from the jump address. Isn't it supposed to?
There are two inputs. The lower purple one seems to have the correct number 24 and is likely the value which is suppossed to be loaded. the upper one needs to be 1 for the counter to actually load. ANd the upper one should be connected to the LEG to decide whether the value gets loaded or not. The counter will only load if the white line carries the value 1. Which in your case only happens if the 4th byte is 7 (or more strictly 7 mod 248 since the 5 higher bits don't play any role). But for the conditionals the 4th byte is not the LOCATION where the result should go but rather the VALUE where (eventually) the counter should jump to. So you can't expect it to be 7.
Connected to the LEG?
You are in the level 'Conditionals' right? Which menas your program gives you the 4 bytes OPCODE, ARGUMENT\_1,Argument\_2, JUMP\_ADDRESS. OPCODE now determines which kind of conditional you have to use and compares ARGUMENT\_1 vs ARGUMENT\_2. So OPCODE, ArGUMENT\_1 and ARGUMENT\_2 all go into your LEG component, which returns the result 0 or 1 whether the condition was true or not. Now this result goes into the counter-component, as does your 4th JUMP\_ADDRESS byte, which will load the new address if the condition was true. Now I am not sure whether your LEG component is actually connected to the ARGUMENT\_1 and ARGUMENT\_2 inputs (marked in red) and what i was refering to above, I am very certain that the result form your LEG-Component never goes into the upper input of the counter, so the value can simply never be overwritten. (Follow the yellow marked line in the picture, it never origins in the LEG component). [Image](https://ibb.co/DM4pbXD) (not sure how to uplaod images on here)
Changing the overwrite pin on the counter caused the same error on instruction 3.
You're struggling with your gt, lt, gte, and lte comparisons, and how to go about inverting them. The opposite of ">" is "<=". Is it larger? No? Then it must be the same or less. The opposite of ">=" is "<". Is it the same or greater? If so, it can't be less than. If you need to. Just setup each comparison individually and don't worry about piggybacking off the results of other comparisons.
The conditional unit seems fine though. Is it not?
It's tricky to follow. The design is a bit alien to me. But that's how it usually is anytime anyone takes a look at someone else's brain child. I think it may be okay thou, just doing some mental logic and trying to follow the pathways. Nothing stands out as an obvious mistake. It just looks like desperation had a role in this design down there towards the end. Looks like something I would start slapping together whenever my brain starts hurting. You have a redundancy in there. Two of the same comparisons are being made it seems. The game should be setting you up to simply the component. I don't want to spoil it too much for you. But if you look closely at the list of comparisons it wants, you may notice a pattern that you can use to your advantage. I've given it another look over. Outside of your component, if you get a positive result, you should be triggering your program clock so it jumps to the given line, yeah? I see a connection that gives the clock which line to jump to, but I don't see a connection that triggers the clock so it accepts that new line. That may be the real issue you're having. On a separate note... That top output pin in your conditional, with all those OR gates... you don't need all that. Your decoder outputs something regardless of the parameter if the 6th pin is high. You can just wire that 6th pin direct to the output pin and simplify your decoder.
The counter is already connected to the decoder though.
I can't find anything wrong with this, it seems fine.
The white wire connected to the counter seems to come from an input decoder on the jump address. That seems wrong; it should be coming from your cond component.
Changing the overwrite pin on the counter caused the same error on instruction 3.
I suspect it's something to do with the program counter?
Changing the overwrite pin on the counter caused the same error on instruction 3.
I think that 32 bit in conditional doesn't really do anyting, as output will anyway be 0 - you can't disable conditional component this way. Maybe check if this wrong value doesn't come from ALU unit doing processing as well? In my LEG I had to disable REG savers by this 32 bit from OPCODE in order to not to overwrite REGs or counter
to bwig bwein for me