Oh karp, I'm at the bottom of the list.... I mean, I should give an update... it has been a while, since I've started the closed beta program.
1. I've gotten better at hand soldering the CPLD. Thanks to Ralph for seeding that thought a year ago... As I've tried to use the toaster oven technique to bake 4 at a time, I end up taking at least 6 hours per board. If I hand solder, I can fix as I go, and test for bridges as I go, and it just works when I'm done.
2. I think we've chased one of the ghosts out of my protocol between the TIPI board and the Raspberry PI. The PI is always a wildcard here since the GPIO timing is always irregular at the speed I'm trying to drive. We were having enough data messaging trouble that I spent the last two weeks looking at how it was done yesteryear... I wanted to add error detection to that interface, but anything that required the TI to execute an extra instruction was going to slow down my overall transmission rate significantly. Then I discovered why parity was so popular... My TIPI board is basically 4 select-able shift registers from the RPi's point of view. That's like an XT or PS/2 keyboard protocol... present a bit, then clk to signal the bit is available, then wait an agreed upon minimum time. repeat 8 times to send a byte. Adding a parity bit in the CPLD turned out to be so popular they have xor8 units built in, just waiting for me to want to do that. So the 9900 doesn't have to participate in the parity dance. And we keep our speed. In the process, of fixing this, parity errors don't appear to be happening at all anymore. I had one, but in developing the fix for that, I may have fixed another timing issue, and now the thing is stupid stable.
It is stable enough now that we are getting far enough without frustration to test more software.
I need to get this fix out to the rest of my beta-testers, which requires reprogramming the CPLD ( I didn't build in any dynamic approach to that ) so I have to recall the devices.
We also had gremlins at Greg's revealed today, in the form of a angry speech synthesizer in the middle. Crash crash crash on his system. Remove the speech synthesizer, and it became much more reliable. not 100% yet. But that could still be his 4A. Or it could be another ghost of of a gremlin that was fed after midnight... Building for old stuff... a mixed bag at best.
I am trying to figure out how to proceed into an open beta or release. Once we are confident in the CPLD fixes, we have upgrade mechanisms for the PI, and you'd need eprom erasers and programmers (or a surplus of eproms) to take updates to the DSR ROM. Given the free space in the DSR ROM, I could see the software side of this never being 'finished'... In fact, I'd hope it never is, and keeps evolving with new creative ideas. The software on the PI side is also easy to extend, and several classes of extension can be added without having to touch the DSR (such as the mechanisms ElectricLab used for multiplayer Combatti, which have been incorporated and upleveled to BASIC without a change to the DSR.)
So, can the community handle the concept that if they buy a TIPI, they are buying my time and materials for the little board, which is only a small part of TIPI. The rest of TIPI being the open-source project that will always be incomplete in one aspect and amazing in another ( at least to me )... ?