uIEC (Was: Re: Open source, stand alone, ASCII terminal project)

Alexandre Souza wrote: Well, there's another project I made: www.jbrain.com/vicug/gallery/c=key/ That does exactly that. It's where the source I earlier mentioned came from. JP Hindin can speak for the utility of the PS/2 routines, as I made him a PS/2->ASCII converter IC out of a MEGA8. I've been hard at work over the weekend demoing at WoC, so I am just now catching up. Please forgive me if I metioned something someone has alreayd mentioned. * I have paid nothing for my AVR programmer. It's a free utility (avrdude) that runs on Windows and Linux, a DB25, a 74LS244, 2 diodes, a cap, and some wire (and a perfboard). I am sure when the pics for WoC come online, someone took a picture of it, it was plugged into my laptop all day at the show. I probably will soon invest in a USB programmer, but avrdude supports those as well. * to get started in AVR, I spent $10.00 (for a couple of 40 pin ATMEGA16s). GCC was/is free, as is/was the programmer. That was my deciding factor over the PIC line, though I have nothing against the PIC. * ASM was not a singificant concern for me. While I would never want to discourage someone from building a PS/2 converter out of discrete TTL (as someone noted, you can do ANYTHING with enough NAND gates), I think it boils down to the focus area. If the PS/2 interface is the end in itself, and TTL is the preferred solution, it's the medium one should choose. But, if it's the means to the end, I'm less convinced it's the right solution. While it might be more "authentic", I worry about the project completion. If you need a PS/2 interface to run a vintage computer, it would seem to me the focus is in getting the computer running and ready to show. If so, using a uC can allow you to focus on that first. Then, later on, if you feel the uC solution is too "unrealistic", it seems better to replace it at that point with a more authentic solution. If one designs the interface correctly, one should be able to replace the "temporary solution" with a more permanent one without making any other changes. However, on the other hand, if someone has to go through the effort of designing and testing the TTL PS/2 interface, I worry that they will lose interest and the overall project will be forever incomplete. uC's allow me to make my projects "auto-updateable". When there is a new uIEC firmware available, folks can load the new code on their CF/SD cards, reboot the unit, and it updates automxatically. This gives me, the project owners, a sense of comfort that I can ship units to people who can use them now, without worrying so much a bout possible bugs. I find, with things like C=Key and uIEC, people get the big kick out of the new attached to the old. They are less interested in how the magic happens. For me, I can concentrate on the ends, not the means. At least in the CBM arena, there is ample precedent: CBM printers and many printer interfaces used 8051s and other uC solutions, even back in the day. It was very common to find a non 6502 CPU in a CBM printer interface. because CBM sourced the mechanisms from other companies and just had the stock electronics modified enough to support the IEC protocol. It stands to reason that the printer manufacturer would continue to use a favored CU/uC. -- 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