As I have reported in the previous post, I have loaded an example binary into the "rom", and started to step through it, observing the program counter, the latched-in byte just fetched from the "rom", and the "byte counter" after each tick (there is a printout provided for this).

As could be expected, the program counter is one address in advance of the fetched byte: when the fetched byte is from address N, the program counter contains N+1 after the tick - in this way, the next byte is fetched while the previous is being decoded or processed otherwise. So, this works OK.

However, I have problem with the "byte counter" - it starts wrong. I even increased the number of ticks while reset is active to 3, but that won't help. Below is the printout of the first few ticks:

PC:0000 code_byte:02 bytes count:0
PC:0000 code_byte:02 bytes count:0
PC:0000 code_byte:02 bytes count:0
PC:0001 code_byte:02 bytes count:2
PC:0002 code_byte:00 bytes count:1
PC:0003 code_byte:03 bytes count:0
PC:0004 code_byte:75 bytes count:0
PC:0005 code_byte:81 bytes count:2
PC:0006 code_byte:09 bytes count:1
PC:0007 code_byte:12 bytes count:0
PC:0008 code_byte:00 bytes count:2
PC:0009 code_byte:98 bytes count:1
PC:000A code_byte:E5 bytes count:0

Execution starts after the 3 active reset ticks, in 4th line, where the bytes count should be still zero, indicating "this is opcode". Apparently, the algorithm, "load new value when it's zero, decrement otherwise", does not work after reset (which zeroes the latch itself). In this way, the first opcode, 02 (=LJMP) is being seen as data; and the byte fetched from address 0002, 03, which in fact is part of the LJMP's address, is seen as opcode! It sort of resynchronises afterwards, but it went already wrong...

The solution might be in setting the reset value of "bytes counter" to 01. In that way, after releasing the reset, the counter would decrement to zero which is the expected value.
However, I used a different trick - I don't allow the value fetched from rom to be latched in during reset, rather, I force 00 (= NOP) there. This really has the required effect, and I expect less problems with this approach.

---

It is funny that a problem with reset has been encountered so early, but this is sort of the things I wanted to experience anyway. It also shows how important a proper reset really is - if the reset pulse is too short, in case of more complex sequential logic, it can really go wrong (even after previous proper reset).

The "fixed" source is at the usual place. A few steps show that it is OK now:

PC:0000 code_byte:00 bytes count:0
PC:0001 code_byte:02 bytes count:0
PC:0002 code_byte:00 bytes count:2
PC:0003 code_byte:03 bytes count:1
PC:0004 code_byte:75 bytes count:0
PC:0005 code_byte:81 bytes count:2
PC:0006 code_byte:09 bytes count:1
PC:0007 code_byte:12 bytes count:0
PC:0008 code_byte:00 bytes count:2
PC:0009 code_byte:98 bytes count:1
PC:000A code_byte:E5 bytes count:0

---
Next: I plan to implement the "tick counter", for instructions which last longer than the number of bytes; and, as a bonus, I might try to implement a simple jump (but that maybe will be step 2 and one third).

JW