Sources for 8b TTL keyboards (Keytronics)

Tony Duell wrote: If the pre-written item is untested or buggy, I agree, all bets are off. My concern is the nature of this group. Not to play stereotype, but I consider the folks on this list the "mentors" of today's developer and hardware engineer. As an Architect in a Fortune 500 company, I see many developers come into our environment and promptly start wreaking havoc by writing their own solutions for things already available: * They feel their code is "great" and so much better than an established solution. This is very often wrong, so wrong. Ironically, this is less of an issue with young programmers and more of an issue with more experienced staff. Yes, some apps are horrid, but in this environment, it's often better to demand better quality from the vendor than try to re-implement and support an internal app. * They don't want to learn how to use an established app. In my opinion, the quality of a developer is his willingness to understand an environment he/she did not create. Rewriting just to avoid learning about something is truly a poor developer trait. * The feel the established application offers too much functionality, and it would be better to implement a simpler solution. This one can be debated, but often projects grow to expect more functionality, so implementing a simplier solution can provide disastrous in the longer term as the rewritten code must either be massively modified to add the more complex features, or the code must be excised and the original prewritten code hooked into the application. * "Not Invented Here" syndrome. Sigh. For my part, I beg those on the list to consider their positions. While I will pay well for a developer who has the knowledge to implement his/her own application, I value more the developer who chooses to write his own solution as a last resort, after evaluating all of the other options first. As a mentor in my own right, I try to relate this position on any who ask. Now, while the idea of implementing an assembler to learn the insides of the CPU hold merit in my opinion, I still think it is a slippery slope. Support can be an issue, especially if you give the code to someone else and then lose interest. Doing this denies an established project the resources of a great developer (the GCC team could use some good assembler/compiler developers to push that platform ahead for all of us), and unless your syntax is exactly the same as the established tools, your source code can't be directly compiled/assembled on other tools, which could deny others a chance to re-use your code. I know it all makes sense from your point of view, but I'd ask that you at least consider my viewpoint. I see it from the other side, where the tools get into the hands of people who cannot support them, or staff who use the development as a reason to justify their internal development. I know, it sucks to be looked up to by others, but it happens. It's a huge responsibility thrust onto many on this list. If you want to respond that your comments are only for hobby stuff or personal stuff, I'm all for that, if you note that consistently. I do that at times ("Yeah, I'll whip up something here, but this really should use App X to do it right. Do NOT do this at work!") Jim -- Jim Brain, Brain Innovations (X) brain at jbrain.com Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times! Home: http://www.jbrain.com