Assembler/machine language, hardware:  30 years C/C++:  24 years Delphi Pascal:  12 years EMBEDDED SOFTWARE: Wrote numerous microcontroller real-time interrupt-driven systems of considerable size and complexity in assembler and C language with multiple stacks and task switching, usually supporting the two or more lines of text in (Loveshaw) industrial printers, but also to execute other system tasks — that is, custom RTOSs. Most projects included a user interface conducted in the background, from RS232 terminal to PC CRT to bubble keyboard/LCD. The systems were low-rent single-CPU systems that printed and also talked to the operator, often concurrently. HARDWARE: I am adept at bringing microcontroller-based gadgets to life; finding/fixing hardware flaws, figuring-out operation (or not) from schematics, and writing/integrating firmware into hardware design — and modifying and creating hardware designs. ... Many of my h/w designs wound-up in production, including a DMA PC card. DEBUG: I have years of experience with chip-level PC-based debugging and the older ICE equipment — including the design and fabrication of my own 8048 device (cp/m version around 1985) — logic analyzers, oscilloscopes, and other test/debug equipment, including the soldering iron. ASSEMBLY LANGUAGE / C: I am highly skilled in assembly language for several microprocessors including the Zilog Z80 and EZ80, Intel 8048, 8088 et al, Motorola/Freescale 68HC11 — I wrote a 68HC11/8048/80C166 macro assembler / linker / cross reference package which I have used for years in production work — and the Microchip PIC. I am equally accomplished in C language/embedded C language, using it extensively on PC-, 68HC11- and, most recently, EZ80-based projects, as well as for numerous PC utilities. C++, OBJECTIVE C(++): I’m familiar with Borland’s C++Builder, also Microsoft Visual Studio 2008 and Macintosh Xcode. ... I’ve written code that compiles in Windows (Visual Studio, C++ Builder and MinGw GNU g++) and the Macintosh (the up-to-date X10.4 g++ — command line and Xcode), including an actual make file that works in both systems! (See my Mac password program ipw, my C++ ini file demo project, and a discussion of Microsoft’s NET flavor of C++.) DELPHI PASCAL: I’ve used the Delphi RAD programming environment since 1996 for numerous utilities and printer-control programs, including SQL projects, and a TCP/IP client/server PC product. Also see my reflections on Delphi class assignment, and my vast OwenShow Windows / Linux project.... *NIX: I probably know enough to be dangerous on the Linux/Mac/Unix command-line. DOCUMENTATION: I speak, read, and write English well, and have created extensive documentation and manuals, including illustrations. As opposed to most programmers, I like to comment code. See my owenhelp project, and the OwenShow help. BACKUP: I don’t lose source or documentation; over the years, I’ve generated numerous backup CDRs, zip and other disks, tapes, diskettes, thumb drives, and I’ve preserved and used detailed records — source, operator manuals, graphics — from as long ago as 1985. EDUCATION: BS in Computer Science, New York State Regents External Degree Program, 1984. This institution, now known as “Excelsior” college, probably still provides access to no-classtime all-test (GREs etc.) degree certification, at www.excelsior.edu. IQ: 131 — at least according to the Tickle online test, which I took after the Monster job site goaded me. Tickle also said Your Intellectual Type is Visionary Philosopher. This means you are highly intelligent and have a powerful mix of skills and insight that can be applied in a variety of different ways. Like Plato, your exceptional math and verbal skills make you very adept at explaining things to others — and at anticipating and predicting patterns. Then they offered to sell me a report that would tell me more....

1984-2009: Loveshaw (ITW) Mostly designing large character ink jet printing (industrial marking) and labeling systems for Loveshaw (a unit of Illinois Tool Works) including software, hardware, and PC Windows programs to control the systems through serial ASCII link languages I designed. The devices print dot-matrix patterns up to 32-dots high, consisting of letters, numbers, bar codes, and user-specified graphics patterns. Loveshaw thrives in a competitive market with exceptional support including my rapid turn-around time on software projects — days and hours, rather than the typical months and years. RECENT ACTIVITIES include endless (and gratifying!) maintenance of the 68HC11-based products leavened by occasional adventures, most recently in Basic language with the Qlarity G55 terminal. The G55 provides a handy controller for various Loveshaw gadgets, including third-party printers used with the company’s labeler. It supports an RS232 interface, still common (and cheap) in industrial environments, which is used in my application to provide utility features. The (free!) PC-based programming environment is reassuringly / alarmingly familiar to those of us who have used Visual Basic, Delphi etc.: you get to “paint” the GUI, and then write bits of Basic code to string it all together and actually do something. ... And it often works! THE Z80 YEARS: When I arrived at Loveshaw in 1984 I took over a Z80 assembly language printer project with a bubble QWERTY keyboard and 2-line LCD screen. I typed the assembler code into a CP/M Kaypro microcomputer from printed listings, because of complex difficulties with the previous developer. The design used 556 timers for the central ink valve timing, controlled by thumb wheel potentiometers on the front panel. This was odd, since the design included a Zilog CTC “Counter Timer Circuit” LSI chip with four digital timers. Two of these were wasted on product delays — the interval from photocell trigger to printing; which were set by yet more thumb wheels — I think one timer was used for baud, with one left over. I did a redesign with the CTC doing the valve timing, and everything else in software — which is why the Deity created microprocessors! ... I found only a few cuts and jumpers made it work right, suggesting the design may have lost its way somewhere along the road. This system went on to many glorious permutations over many years, including two advanced CRT terminal versions. Supporting these products were PC control programs — first, simple command-line / character-based, and then Windows 3.1, where I ingeniously reused existing C-language code from the character-based effort via a DLL and coroutines. In this and most of the subsequent printers, a single embedded CPU supports real-time printing via interrupts, + implements the user interface (print message composition, menu features) in the background. In the late 80s, the company entered the 8088 / 68HC11 era: we built a 6811 version of the Z80 product, and then a more elaborate 8088-based system. I wrote a lot of embedded 8088 code, much of it in C + a good deal of assembler, including coroutine code for multitasking, and created various programs to provide PC access to both the 6811 and 8088 designs. Both units used industrial bubble keyboard / LCD handheld units. The 6811 won — the hardware design was simpler/cheaper, particularly after the handheld was “absorbed” into the main chassis. Numerous variations on this basic printer continue to this day, ranging from 5 dot single-head machines up to 6 heads, + newer technology higher-resolution 32-dot devices. I’ve diverged the software to follow the hardware models — but the basic code is fairly common to everything. Along the way, to avoid the endless struggles typical with cross-assemblers, I wrote my own. ... I wrote Windows programs for the printers, supporting message edit/change and other features, including graphics: the letters in a printer graphics font are replaced with images loaded from the PC program which, as shown here, used standard Windows “BMP” graphics files. I created an industrial RS422 network for the 6811 design, allowing multiple printers to connect to a single PC with longer cable runs and less cable, and also alleviating the then-limited supply of PC serial ports. And starting with the 6811 design, I created multi-language “localization” interfaces, in the most elaborate case providing utility software to allow customization by others.

LABELS: In 1999, Loveshaw acquired label technology and “microcontrollered” the hardware. I converted analog/digital circuitry (four dual 1-shots, some 40xx CMOS and a few transistors) to 6811 software, using only schematics — I tried lighting-up the card, but it didn’t seem to help much.... I translated one-shot logic to elaborate 6811 timer macros, with values based on the resistors/capacitors in the schematic. The potentiometers in the schematic became software menu items which the operator can easily adjust without a little screwdriver, and numerous other enhancements have been added — which of course is the whole point of the conversion. Heroic measures used to debug the labeler include the plastic purple box in the picture, which simulates the numerous inputs on the system. ... Because I’m lazy, I contrived a “FAKE” conditional that does that sort of thing in software. The software macros encapsulating input/output and delays look like ApSolenoidOn waitms ApplSolenoid ApSolenoidOff A variable-to-menu macro system made setting-up the timing and other variables a matter of making entries in a table like dataApplyPrint macro ;def, min, max makevar ProductDelay,defPD,0,BigMax makevar ApplSolenoid,200,50,20000 which were translated into variables for the execution logic, and entries in a menu for the operator. Then I wrote the Windows program for the system which, along with saving and restoring timing / variable setups, could also document / emulate logic event sequences, for debug / verification during system design and test.

The eZ80 is a contemporary Zilog microcontroller — and an antique vacuum tube. ... The Zilog product has its nostalgic ways: you can run your old CP/M programs in binary Z80 mode, but there’s also a more plausible modern style where all the original Z80 16-bit registers magically become 24-bits wide; + the eZ80F91 comes with 256 kilobytes of flash ROM, ethernet support, timers, 32-bits of general-purpose i/o, uarts, and more. ... In the illustration, I’ve persuaded Zilog’s demo board to talk to an LCD I lashed-up. The tricky part: the eZ80 is a 3.3 volt part, but cheap LCDs are definitely 5 volts — so I interfaced the LCD with general-purpose i/o bits, and minimized the required bits via the LCD’s 4 bit mode. I can do this because (1.) the eZ80 happily tolerates 5 volts on inputs; it’s a feature; and (2.) the LCD sees a “high” for the 3 volts or so the eZ80 emits. So everybody’s happy! If I really liked 5 volts, I suppose I could connect an all 5-volt system to the eZ80 bus, including the LCD — but the Zilog prototype gadget I use wouldn’t like that, already equipped as it is with 3.3 volt memory and other devices which don’t have the eZ80 5-volt input tolerance feature.... ... Then in a burst of enthusiasm, it occurred to me things could go faster if I didn’t have to use the admirable/free but slow/cranky Zilog C-language compiler to concoct the user interface, but instead enlist the space-age (© 2000) Borland C++Builder environment in the cause — and so I did! I compiled the numerous existing C files in a Builder project along with some mixed C/C++ emulation code. ... And it did speed things up, as well as providing a PC “demo” version of the interface for the client....

The Database / Delphi Connection: I enhanced my Delphi Windows printer-control program with a database-recall feature, using MySQL + the excellent DirectMySQLObjects to access the database from the Delphi program.... In the illustration, window (a) is the main window of the printer control program. The automation feature in window (b) — as shown more-or-less on the form — has been configured with the “$:database” key word; the desired host, table, password, etc. information is provided in the program’s INI file under the section heading “[adbase]”. In the arbitrary syntax of the feature, the database section is followed by a scanner and one or more printers. The information the automation feature will act upon will be provided by the first “p:” specification, a “p:scanner”, an imaginary “printer” whose attributes are found in the INI file under “[printer:scanner]”. Here this scanner controls a single printer “p:com1”. The INI specifications for the scanner configure it as a file-based protocol instead of an actual device, so the demonstration program shown in window (c) (which could be any software capable of creating a file) can function as an “imitation scanner”. It has just sent the unimaginative bar code “3” in this fashion, and the automation feature used the code to recall printer text from a particular row in a database, as indicated by the caption after “most recent activity” in window (b).

The specified row in the database table contains two fields, “action” and “info” (in addition to the barcode index value) which tell the automation feature what to do — in this case load the specified text into the printer. An alternate action might recall a specified message from the printer’s built-in store; or load a disk file of messages into the printer, and then recall one of them.

Unanticipated MySQL licensing issues prompted a switch to the public domain SQLite. ... It’s true the (also public-domain) browser (http:// sqlitebrowser. sourceforge. net/) I found isn’t as cute as some of the shareware available for MySQL — but it does the job — and the control program’s behavior (i.e., as above) is unchanged. ... Along the way, I looked into the more-elaborate, BSD-licensed PostGres; which was so impressive I wrote a few Builder and Delphi demo projects....

PIC: One of the great contributions to the embedded system world is the MicroChip line of PIC chips, including the PIC16F877 which I used to create two printer accessories. The first was a port expander project, to add-on serial ports and other functionality to our basic printer design. A second project was an LCD/bubble keyboard terminal, with the goal of reducing the expense of multiple printer purchases with a single operator interface device (i.e., a separate LCD serial terminal). I found a clever keyboard scanning technique on the web: In the average keyboard scanner circuit, the square root of the number of keys + 1 or so times 2 is the number of pins needed on the microcontroller. But using the bi-directional capability of most modern microcontrollers, I could reduce that count to the square root of the number of keys times 1, plus 1 or 2 or so, + a forest of diodes and resistors — which generally are cheaper than microcontroller pins. ... Finally, in the full-service tradition I put on my techie hat and debugged a few prototypes for test.... One of the striking charms of the PICs — aside from their low-rent development equipment — is their utterly barbaric assembler language. Fortunately the MicroChip assembler has an adequate macro language, essential in such situations.

An LED sign: For that truly challenging programming experience, Adaptive Alpha signs can’t be beat. I had a 215R unit (1-line 15 red characters), but your giant LED needs can be frustrated across a virtually limitless range of forms and sizes and colors. The beauty of it all is the signs can only be controlled by a TV-style remote control, or silly proprietary software from the company + silly proprietary cables, or with your cables and an RS232 (485 etc.) control-language apparently originating during the Ottoman Empire and much-embellished since then. Verifying that a serial connection exists at all was a challenge. A demo “alphanet3.exe” crashed all the W98 and XP computers I tried. An older alphanet2demo.exe I eventually found lurking on the web worked — but probably not on XP, since it’s a Windows 3.1 kind of thing. But the program would indeed download my test message to the sign and then, as a special treat, set the sign off on a half hour adventure of fireworks and text effects, much of it moderately amusing.... The control protocol is “documented” in the vast 97088061.pdf. After the initial shock and awe, I settled for a “Sample C Program” (page 55). The protocol sequence shown there seemed to be only vaguely related to the stuff earlier in the book, and the actual C code was probably nonfunctional, but, once transferred to a working program, the sequence lit up the sign from a PC. I did have to stick in another sequence, using the page 55 outline with the text stuff replaced by an “E$” memory clear sequence I found somewhere else in the pdf. If I didn’t do that, the sign, although it’d display the new text, insisted on then immediately resuming the amusing show the alphanet2demo program set-off — and it remembers everything through power-cycles, the clever devil! ... Anyway, once I got that far, it was then just a skip and a jump and one of my printers was happily chatting with the device, and large-character printer technology took another giant LED step forward....

TCP Client Server: at the frontiers of industrial science, my client/server project brought printer control into the 90s (somewhere around 10/01) with a Win32 Delphi program + an Indy-powered TCP client / server connection. The printers themselves are stuck in the inexpensive past, with the simple RS232 or RS485 proprietary network links I designed. The new Windows + Delphi + Indy Internet components + Marshallsoft’s 32-bit serial DLL opened new vistas, supporting ethernet connections as well as USB serial (32 ports — or more!) and, with a little luck, actually running on the next operating system Microsoft© released — and, indeed, it did run without complaint on XP when it showed up — out of the box! ... On the other hand, there are now $150 industrial TCP/IP / RS232 / RS485 boxes that apparently do everything my server does — and no PC required! ... Sic transit etc.... But the Win32 program, which also supplies normal printer control functions through the usual serial link, recently only took a bit of disciplining to work OK in Vista!

My SCRAMBLE utility randomly rearranges my link modules to optimally avoid the 68HC11 B600-B7FF EEPROM hole — a discontinuity built-into the program space. ... The EEPROM could be entirely disabled, but only in a special-mode manufacturing procedure ($), a decision Motorola eventually reversed in the E-series. My linker has an option which bumps a module that might enter this forbidden zone, but that merely works and doesn’t optimize code space usage in the region. ... So I wrote SCRAMBLE, which would try random rearrangements of modules for the best fit. At first, SCRAMBLE was so optimal, it saved the bytes occupied by the EEPROM hole! — because a coincidental bug in both SCRAMBLE and my linker wouldn’t bump a module if it happened to just hit the B600 boundary (which may explain random mysterious bugs of the past). ... Astonishingly, SCRAMBLE + my linker would fill up that hole over and over again! ... It was like artificial stupidity! ... But I had told it to seek the best solution and, after all, getting 512 bytes in the forbidden EEPROM hole for free was optimal.... After I fixed both programs, the best solution is still when a module hits B600 precisely, so not a byte is wasted before the boundary, but now the linker and SCRAMBLE correctly bump the module to B800. SCRAMBLE does 100,000 iterations — about 3 seconds in 16-bit 1988 Turbo C — but the actual solution takes around 13,000 tries. ... Thank goodness for these Pentiums....

Less amusing was the “E series” imbroglio. Here I was cursing Motorola when my code would fail with their 68HC11E but not in an emulator and/or a 68HC11A — and in the end, it was all a foolish pointer! Because it worked seemingly without flaw in the emulator, I burned around 200 EPROMs and resurrected my low-rent logic analyzer + homemade software before coming to the glorious outcome illustrated here. What did I learn? (1.) Debugging software without source-level tools is unpleasant and foolish, although occasionally necessary. (2.) But I’m going to keep a logic analyzer around in case emulation doesn’t work. (3.) Don’t make stupid mistakes: at least a few days before the beautiful trace above, I should’ve known where the code was erupting. But I thought I had looked and looked and checked every inch.... In the end, it was just a stupid code error that I couldn’t see. ... And isn’t life like that?! ... We struggle and suffer, only to discover there was a simple answer before us all the time? ... When the dust settled, it seems the broken pointer was something like $0102, a location where the E-series 68HC11 has RAM and the A-series doesn’t, perhaps explaining the pathological randomness of the E-series failures — although I can’t help but feel that reading random bytes from nothing ought to have been at least as unpredictable.... Subsequently, I modified my assembler to detect suspicious absolute references — i.e. because “ldaa 20h” (load from memory location 20 hex) should almost always be “ldaa #20h” (load the constant 20 hex) — which, I hope, will tend to discourage this kind of thing....

FONTS: Two PC programs involved Windows bit-mapped “FON” files and the creation of numbers of special-purpose fonts — to emulate printing, for instance, as in the figure; for which I also wrote utility software to translate 68000 assembler font files. And of course numerous printers required font support and I wrote numerous “ascii-to-font” programs, where patterns like are converted to the bits and bytes needed by the printer.

AD-HOC Debug: I created a debugging environment for an 80C166-based (Siemens) printer with download and breakpoint features. I wrote the debugger mostly in Turbo C and wrote software to translate the output of this 8088 compiler to 80C166 assembler. In 1997, I used the Numega SoftIce tool to write a VxD (Virtual Device Driver) and Delphi program to demonstrate feasibility of manipulating DMA physical memory under Windows/W95. ... And the software is functional today! (Thursday, February 9, 2006) — under Windows 98 SE, to be sure; I gather XP might be upset.... I created hardware and software for two 68HC11-based PC cards. The first is described above; a second card did not require as high DMA performance, but involved more on-card intelligence and used 68HC11 C and assembly-language + 8048 assembly language. It included hardware / software for multiprocessor communication + coroutines, and used three PLDs.