It's maybe not the best name for it, byte counter, but I had to come up with something... At the opcode it latches the number of bytes (data) to fetch until the next opcode, so it will be 0 when the opcode is latched in, and nonzero otherwise.

This is how the processor knows, which one is the opcode.

As it's written, the number of "operands" is latched in from a ROM (the array) of 256x2 bits, but that would be really wasting of resources, as it can be cut down to some random logic; but for now, I am happy with the array.

It could be either a reloadable (down)counter, or maybe even a parallel loaded shiftregister.

I am aware of the fact that some instructions will require more ticks than the number of bytes is, so then the program counter will have to stall for a couple of ticks - I already started to add something like "tick counter" but then thought that that would be too big a step at once, so that one will come later.

---
There is also some more infrastructure added. I now try to organise the "tick" so, that the signals and buses are set first, and the latches are updated then. I know this should involve more precise timing, but let's be happy with the simple one for now.

It's also time to fill our code ROM somehow - simply, a binary file is loaded from zero, the name of the file is given as a parameter when the program is run.

The current source will always be at the same place as mentioned above, but I also keep the backups; I will keep the list of them at http://www.efton.sk/my51/ (there is also a RSS feed there if anybody is interested).

Enjoy... and comment...

JW