Gigantic Solutions for Small Businesses

Portfolio of Programming Work

This page represents an assortment of programming projects intended to illustrate our depth and breadth of programming knowledge and capability. Our ability to take on projects that sometimes involve languages that we may not necessarily have direct experience coding with is a testament to our expert understanding of software systems, general principles and applications. It is our belief that at its core, software development is the same no matter what the language is—language is just semantics which can be referenced in a book. Of course there are those optimal tricks and idiosyncrasies that are specific to each language and platform, but what we don't know, we learn. What we learn, we learn to our fullest capacity. This is what true engineering is all about: venturing into new territory.


Powis Printer


The Powis Printer is a "spine printer" for books like these 8.5"x11" ones that have been bound with Super Strips from Powis Parker
www.powis.com

For the Powis Printer project, we were charged with taking an existing revision A product and giving it a facelift to revision B. The product itself is a 24-pin dot matrix printer with a unique feed and drum mechanism which moves the target print surface across the print head. The print surface itself is a specially designed, adhesive-backed strip of paper or other composite material used for document binding. Thus the Powis Printer is also referred to as a "spine printer" as it effectively allows you to print on the spine of a book before the book is bound.

The rev. A product consisted of the printer mechanism, an internal electronic microcontroller board, a separate keyboard console with a 2x40 character LCD display interfaced over RS232 with a standalone internal PIC controller, and all the firmware needed to operate both devices embedded within. The printer's microcontroller board uses a Motorola 68332 microprocessor with PROM-based firmware storage, EEPROM based parameter storage, and two RS232 ports, one of which is dedicated to the console interface. The second RS232 port was used to run a PC-based application which could send graphical print jobs to the printer to counter the console interface's text-only limitations.

Super Strips come in assorted materials and colors. Foil printing cartridges have varying ability to "stick" depending on strip material properties and printhead pin-firing characteristics.
What we accomplished was nothing short of breathing new life into an aging beast. The firmware core written in ANSI-C was more than 400,000 lines of code. We started by analyzing the existing code and identifying points of interest as pertained to the new features we were to add. The first thing we did was create a memory-management scheme for the EEPROM data space with dynamic allocation support to oust the old fixed layout. We then created LZW compression software in ANSI C and embedded the compression side into a Windows-based "wizard" type GUI application and the decompression side into the printer's firmware. With a little bit of tweaking, we could read in a bitmap from disk on the PC, compress it, upload it over RS232 to the printer, allocate EEPROM storage space and store it under a user-defined label. Then in subsequent console-based print jobs, the bitmap could be referenced by name on the LCD screen, downloaded from the EEPROM and decompressed and included into an otherwise text-only print job. Thus was born "logo support" for the Powis Printer.

During our work with the printer we added a number of other capabilities. We created a new, multi-line console-based document editor that behaves more like a PC-based text editor. We added variable printhead pin-firing timing capability for testing print heat and force characteristics of new types of foil "inks." We also revamped the entire console-based menu system in order to more effectively organize all the new features into the interface. All in all, this was an indispensably valuable development experience that we are proud to have participated in.


Promise FloppyMax & EIDEMAX II


The FloppyMax and EIDEMax boards were nearly identical save for address space and PROM BIOS code.
www.promise.com

The FloppyMax controller board was Promise Technology's answer to the upcoming Ultra High density (UHD) 120MB floppy drives that were soon to hit the market. The ATAPI-based magneto-optical drives were comparable in specification and performance to Iomega Zip100 drives that were also hitting the streets in ATAPI form. We were tasked with writing a new software BIOS to live within the FloppyMax's PROM chip that would support the LS-120 and Iomega Zip100 series drives and provide boot capability. Indeed, by the time we were finished, we were able to completely boot Windows `95 from a diskette.

Some of the challenging aspects of this project included:
    • Making code compatible with standard BIOS and O/S practices for hand-shaking, identity, memory allocation, and interrupt handling
    • Implementing a complete int 13h handler including all extended int 13h LBA functions to interface with up to two devices
    • Implementing a complete working interface to ATAPI devices starting from the ATAPI protocol specification itself and general knowledge of ATA interfacing
    • The entire BIOS interface was coded in 80x86 assembly language with very little 386+ code being employed in an effort to maintain 286 compatibility

In the end, the FloppyMax was a hit. We participated in an international developer's forum related to ARMD and UHD devices and consulted on some issues with the early devices pertaining to boot, response and latency times, etc. The forum seemed to appreciate the efforts being put forth by Promise to bring boot capabilities to the device at a BIOS level. The FloppyMax device was eventually embraced by such companies as Dell Computers who to this day have information pertaining to the product on their website. It was a tremendously enjoyable project that gave us the opportunity to use sophisticated ATA-based signal analyzers, software ICE systems for troubleshooting I/O on system level calls at boot time, and gave us access to prototype equipment which enabled project completion before the drives themselves were available to the public.

The EIDEMAX II was the first Plug & Play ISA board manufactured by Promise Technology.
The next project with Promise Technology was the EIDEMAX II disk controller. A 16-bit PnPISA (Plug-n-Play) board with two ATA ports capable of handling two ATA or ATAPI devices each, it was required for the card's PROM BIOS code to provide boot capability similar to that of the FloppyMAX. The BIOS was further required to implement the PnPISA specification for allocation of resources including ROM BIOS memory address, I/O port ranges, and IRQ settings. Though some pieces of code could be borrowed from the FloppyMAX project, it was nearly a complete rewrite with having to add all the support code for device I/O on large hard drives which at the time were just breaking 12GB with Quantum's "BigFoot" series.

And so again, starting from the industry standard specification documents once again, we set about creating an interface to ATA drives, to PnPISA system BIOS calls, for boot capability and for extended Int 13h support for LBA on large drives—all in 16 bit 80x86 assembly language. Once the base code was complete, we wrote benchmarking and DVT/EVT test tools to verify that the code could bring the drives and 16 bit bus performance thresholds to as near the theoretical maximums as possible. The EIDEMAX II's PROM BIOS even took over control over the primary & secondary ATA ports on the motherboard in order to add large drive support capability to those drives as well. This meant our BIOS was in control of up to 8 large disks at any given time. At one point we tested this with eight 12GB drives and ended up with nearly 100GB of combined storage on one small computer—we had no idea what to do with all that disk space! Once again, Promise had a hit on their hands that would add a whole new level of upgrade capability to PnP 486 owners who needed more disk space.