There is still a bit of a mystery going on.. As the only change in the current code was to tristate LDS,UDS,RW on BGACK. Now the cpu does that itself anyway, but obviously routing those lines via the pld has improved things. I can only think that the delay is helping solve the issues. So I will try delaying the signals more tomorrow when I get home and see if TOS 206 boots at 50mhz...
As to why the TOS version matters is a bit odd. I'm going on the thought that 206 uses BERR in the start up code somewhere which 104 isn't doing. Also emutos still doesn't start but that reports bus error.
My next thought is the CPU tries to terminate the berr , but then re-reads berr from glue and tries to repeat the cycle causing the error. So I suspect berr does work, but the cpu tries the cycle twice and screws up causing the berr to appear its not worked.. Matter of perspective I guess..
Problem is, berr is based on the glue running 8mhz. So with the speed of the cpu running at 50mhz it could see berr several times. Which is my best guess to what is going on. Of course the system all works when running at 8mhz, so there is no fault anyway, its relating to fast cpu only.
The only possible solution I see is to run the CPU at 8mhz during a berr cycle. Now I got my new board built I can add in the clock switching .. I just need to tag a berr wire to the pld to switch to 8mhz

I guess ultimately I need to sync berr via the pld as well...
So a lot more tests to do.. At least the end of my booster research is finally looking like the end is near! So I need to prove the idea, then start on version 3 of then board.. Maybe that will be closer to a final design!