Z80 8 bit Microprocessor and Arduino Mega

My first computer was a ZX81, and as child I always wanted to make my own computer. However I always found writing software easier, and moved away from electronics to software. The Arduino rekindled some of that delight in physically making things,
so I started to wonder if an Arduino could help me understand how old 8-bit processors work, and kickstart the process of building one.

I bought two Z80s from RS Components, and after realising I was going to need a lot more digital pins than the Uno provides, an Arduino Mega. The video below shows my set-up running in test mode, which I reset at the beginning. The LEDs in the bottom right are power (green), clock (yellow) and reset (red). The reset blinks 3 times, to clear the Z80 program counter and probably it's registers. I read somewhere that 3 times was better than just once, but I'll play around with that to see if it's true.
The strip of LEDs at the top left are the low bytes of the address bus. The yellow is the 1's and the red the 128. Oddly once I hit 128 in the PC unexpected things start to happen. The LEDs at the top right are memory request (blue), read data (red) and write data (yellow).

When the processor is reset, it's also fed 0's on all of its data lines. This means that when the program counter requests each instruction, it gets a NOP  (no operation). This causes the program counter to increase by one, hence the address bus counts up in binary. Right now all the Arduino Mega is doing is monitoring the address lines and outputting the result to the serial monitor. This works, and proves at least that the Arduino is capable of limited support of the Z80, as well as making me more happy that I probably should be. One thing to love about the Z80 is that the clock signal can be manual, you can literally step through the instruction processing.

I've uploaded the very basic code to GitHub here.

The next step is to make the software recognise the memory request & read data signals to provide instructions, effectively working as a ROM. The after support RAM and IO. I plan to use a small Arduino controlled OLED display to act as an output for now. No idea about input though!

Death to the P1!

I often hear developers and product owners talk about all the P1 issues on the storyboard or in the backlog. They need to stop it. It is only the order of the backlog that matters. Having stories that appear to equal importance confuses the developers and encourages management to think teams can work on many parallel work streams. Worse, cynical programmers will laughingly say ‘everything is a P1, except for the other stuff which we’ll never do anyway’ and they are often right. If work isn’t worth doing soon, it shouldn’t be at eye level for the teams, so calling a bunch of stories low priority will sound their death knell.

Product owners can steer themselves, and stakeholders towards lean and agile productivity by avoiding talking about buckets of priorities. It’s hard of course, especially with product work that spans multiple teams, instead talk about how stories, features or epics relate to each other. ‘Is getting the biplane flying more or less important right now than the catch the pigeon feature?’

Probation periods or punishment periods?

Having changed jobs I'm currently in a probation period. I have, for a time, lost many of the advantages of full time employment I previously had, and it feels like a punishment for exiting my last employment. Recent family events have made me think quite hard about things like fitness, healthcare and pensions, none of which I'm entitled to during my 6 month probationary period.

I can, grudgingly, understand that the notice period is short during this period but withholding employee benefits feels like mixture of punishment and old fashioned 'you should be grateful for a job' thinking. When you're trying to hire clever, in-demand individuals who want to work in autonomous teams where their contribution and commitment is valued, you need to reflect those qualities in how the company treats its those new employees day one.

And as my friend Ian Cackett pointed out, it actually shows you're not confident enough in your hiring procedure to trust that you've made a good hiring decision. That makes me nervous about the company. Have you hired badly in the past and don't think you've fixed that yet? So actually, who should be sitting on the naughty step? 

Agile : ideal or ideology?

The word ideology has a string of negative connotations. It’s used to describe nightmare government regimes, disastrous processes and blind loyalty. When I first thought about writing this article I wanted to describe Agile as an ideology, but swiftly realised that would worked against what I was trying to communicate. So, I’m turning to the word ‘ideal’. The Oxford English dictionary defines it thus,

adjective

• satisfying one’s conception of what is perfect; most suitable:the swimming pool is ideal for a quick dip, this is an ideal opportunity to save money
• [attributive] existing only in the imagination; desirable or perfect but not likely to become a reality:in an ideal world, we might have made a different decision
• representing an abstract or hypothetical optimum:mathematical modelling can determine theoretically ideal conditions

noun

• a person or thing regarded as perfect:you’re my ideal of how a man should be
• a standard or principle to be aimed at:tolerance and freedom, the liberal ideals

Which sounds like a good thing. Agile is an ideal. It is not a process, and just following Agile methodologies will not be satisfactory to those that think of Agile as an ideal. Many of the Agile ceremonies are easy. It’s easy to run 15 minute daily stand-ups and it’s easy to have a retrospective every two weeks and pick apart the low level details of the completed sprint, but neither of those things are going to make a team Agile. The tragic beauty of Agile is that even doing just those things will improve most software teams performance, and will convince managers and other stakeholders that they are a successful Agile organisation. They probably aren’t but they have benefited from it already. The issue is that the steps they have to make to become Agile are hidden to them, they don’t know they haven’t reached it. It's fearful for them too, as it relinquishes micro-management for unproven quality gains. The problem comes when the Scrum team starts ‘grokking’ Agile, while their managers see it at best as another process and at worst just another fad. It’s understandably tough for management who are above the day to day to understand that Agile is an ideal, as they aren’t seeing it every day, and I suspect Agile courses rarely effectively teach that side of it. However once the box is opened for developers they'll want in, they want to embrace Agile and they’ll move further away from the managements worldview, causing friction and probably leading to dissatisfaction.

It means those dev managers who see Agile as an ideal have to go to their CEO and say ‘this is what we are striving for, you’re going to need to understand it and embrace it, but I think you're going to love the results.’ That takes bravery.

‘Agile’ Bob Hartman, who trained me and my original teams in Agile effectively said ‘the harder the project, the more you must strive to be Agile in it’s execution’ and it was great advice. My advice is, if you are thinking of moving to Agile, and you’re a small or mid-sized company, you’ll need to train everyone who sits in the tree above the developers too, or expect the developers to seek greener pastures where Agile is seen as an ideal and not just a word. When I interview developers, and increasingly QA they often ask, how Agile are you? And sometimes they tell me they want to leave their existing organisation to go somewhere 'more Agile'.