found the software failed exactly where the counter flows over from 255 to 256.
Switching from 255 to 0 means that you have 8 bits switching simultaneously. This could cause some ground bounce. If you have data/address buses in bundles of wires, try adding some ground wires in the same bundle.
Also, it's best to keep buses of like signals together, so all the data lines in a bundle, and the addresses in a separate bundle, and the control lines separate from either.
Thanks for all the analysis and advice on this folks.
@BigEd - yes I would agree that the breadboard has caused me issues from time to time. Mind you, it has been pretty reliable for more than 1 year, so I haven't had to worry about it which has allowed me to build the software side of things up. But where I have had issues in the past I found that judicious use of additional wires to get power and ground distribution has usually helped.
@Arlet - really good point about flipping from 255 to 0. As mentioned above, power and ground distribution seems to have been a thing I needed to deal with occasionally, so perhaps it is this the root cause, it certainly a logical hypothesis and the one I am going to use as the probable cause at this point.
Because I messed around with the voltage regulator, I think I have inadvertently fixed some kind of ground / power irregularity which was causing the re-producible glitching I have been seeing.
In summary, I think what I have been encountering is definitely a product of pushing the envelope in terms of what a breadboard should sensibly pushed to do - although the Vulcan project seems to be well outside of the normal 'envelope'! The next time I see this, I will be checking power and ground lines as part of the first level of investigation.
Now the idea of moving the design on to a more reliable board is attractive, but I have to say I quite like rather crazy look of the thing, but the main issue is time for me. So I would rather be playing around with new features in the software (enhance the custom BASIC I have been building, improve the OS) and some minor HW changes (e.g. I would like to look in to ROM and RAM banking). So for the moment, moving the whole design will be a future intent..
Thanks all for supporting me through this investigation, appreciate the time and interest that folks put in, it's really nice to be part of such as supportive community.
Mind you, it has been pretty reliable for more than 1 year, so I haven't had to worry about it which has allowed me to build the software side of things up. But where I have had issues in the past I found that judicious use of additional wires to get power and ground distribution has usually helped.
Well at least you can continue bending your bits as you like
But you probably know that breadboards are designed for quick and dirty setups, just to verify something that is unclear say due to poor documentation or so. These contacts are well for some days/weeks but they need to be used (aka plugged/unplugged), otherwise the contact resistance is function of time - not necessarily 255 or 256 hours
You could save some scars (from intensiv head scratching) if you switch over to pcb's
If the breadboard has been assembled for as long as a year, it's possible some connections are not so good - because pushing wires into sockets wipes clean the surfaces. So it just might be worth working your way around the breadboard, removing each wire and chip in turn and replacing it.
@GaBuZoMeu - LoL, yes I agree I am potentially just around the corner from yet another frustrating episode with my breadboard
@BigEd - I hadn't thought about that, and as GaBuZoMeu also mentions, using the connections will help to maintain the contacts. I will look at that also - great suggestion.
Thanks to for all the input, I have learnt much from your ideas and suggestions.
