While some may know this as I've not really kept it secret, I started my professional career as a electronics/computing hardware engineer. I built and designed access control and magnetic stripe equipment. These devices were based on the 6800/6803 embedded 8-bit micro-controllers. Even while working on Turbo Pascal/Delphi/RAD Studio, I've continued to enjoy firing up the soldering iron, grabbing a handful of components and made stuff.
For a long time, the hardware side of the software business has been somewhat isolated. For the most part, pure software companies only dealt with hardware that was standard off-the-shelf or was derived directly from the same. However, within the last 6+ years, and especially within the last 3, the rising up of the "maker" culture has been one of the most interesting developments in the overall technology sector I've seen since the late 70's and into the mid 80's. In many ways, this movement, which unlike the 70's and 80's, is far more diverse.
Not only is this whole new segment diverse in terms of the kinds of projects, but also diverse in the kinds of participants. No longer are there only classical electronic/electrical engineers working in this space, but all manners of art and science practitioners are also heavily impacting it. For instance, some of the "wearables" technology started out as art students merely wanting a way to light-up their avant-garde fashion design. Others are using technology for "kinetic sculptures". They learned simple programming techniques and enough electronics to wire up a few LEDs and buzzers to a small microcontroller. This world is so much more accessible than when I was spending my summers at the local library or Radio Shack. I can only imaging the trouble I'd have gotten into had the Internet been available back then... On second thought, I'd probably have blown myself up :).
Throughout my software career, I've called on my hardware experience and interests to help inform how I design and build software. Most software developers I've encountered have enough knowledge and understanding of how the hardware operates to be very effective developers. However, I also think that you can never have too much knowledge and understanding of the system for which you're developing code. Knowing how the hardware is put together and built, can sometimes lead to interesting software solutions. In fact, this very thing is another development I've seen in the industry as well... replacing hardware with software. In fact, "software" is used to develop a lot of hardware these days. VHDL is one such example where hardware is described using a form of software. This code is then compiled and then "programmed" onto the physical device. This code can also be used to automate the creation of a custom integrated circuit. In fact, nearly all integrated circuits are designed with some form of VHDL or another.
I've worked on several personal projects over the last few years that I plan to use this blog to describe and document. Look out for information on the following:
- Ballistic Chronograph
- Using the toner-transfer process to create custom PCBs
- Hacking a cheap laminator used for the toner-transfer process
- Building a 2'x4' gantry CNC mill
- Converting CNC mill to a 3D printer
- Building a custom 3D printer extruder/heated bed controller
- Making a variable speed spindle with an RC brushless DC motor
- Tachometer and controller for the spindle
- Using LinuxCNC
- Converting a toaster oven to a reflow oven.
- Arduino
- Atmel Atmega328p, Atmega32u4 in TQFP
- Intel Galileo & Edison
- Raspberry Pi
- Photon by Particle.io
- PCB prototyping services, such as OSHPark.com
Sometimes I may use Delphi in these projects and sometimes other tools and languages. For instance, I used Python on Linux to create a simple GUI application that monitors and controls the 3D printer extruder/heated bed controller.
I also came from a hardware background, originally in purpose designed logic, then later with Z80 and Z8/Super8. If you know the Z8/Super8, you will understand why I was immediately drawn to the Atmel chips. So many registers, and fast context switches! Great stuff. But by the late seventies, the hardware designs were becoming unwieldy, and it was clear that micros would be the way to go. I was mostly working in assembler, and dabbling with early 8-bit C compilers. Then TP1.0 on CP/M came along, and changed my world.
ReplyDeleteI'm also a bit of a hardware hacker, mostly around Amateur Radio. I participated in a club build of a software-defined-radio decoder and RF-input-signal-conditioning board, which our club built together. It was my first attempt at surface mount electronics, previously I had only done stuff with prototype and wire-wrap, and dead-bug construction, and a tiny bit of 1980s style through-hole DIP packaged semiconductor projects. I wonder why you want to convert a toaster oven to a reflow oven when you can buy a tolerably good one with a nice temperature ramp/soak controls, from China, via Ebay, for about $200 US.
ReplyDeleteWarren
+Warren, Because I'm a hardware hacker... Why spend $200 when I can spend $250 and do it myself ;-)? And at the same time learn something. It is never really about the end result with me. It is about the process in getting there. If the end result can also help with subsequent projects, all the better. After all, I'm also a tools guy... hardware and software.
ReplyDelete+Bill, Yes, I remember the Z8! I remember when it was launched. There was a lot of buzz around it. I taught myself assembler with the Z80 when I was about 12 on the TRS-80. I used to go into school an hour early so I could spend that time on the only computer I had access to.
ReplyDeleteNo, that was me! Z80 on TRS-80 Model III, when I was 12 or 13! With a cassette loader. Program Assembler, assemble, run, crash, reload the entire Assembler from tape, alter code, assemble, crash, reload the entire Assembler from tape. Then it was 2015.
DeleteI was using the Model 1... I would ride my bike to the nearest Radio Shack during the summer. The sales folks at the RS had no clue what to do with it, so they just let me sit there and program it. It got to the point where my mother would call the store and tell them to send me home :).
DeleteGoodness gracious, the Model 1! Had the Sinclair ZX-80 before the TRS. Also a Z80, but the screen shook so much at each key press, it was a seizure inducing device. Remember getting that Z-80 Assember course in a binder...and a book by Rodnay Zaks...
DeleteMy first was an IMSAI 8080 which I built. My first RAM card was a 4K static. This was 1976. Paper tape and an ASR-33. I did buy a ZX-80, but after a day, shipped it back for a refund. It was too strange to have any application for me, and I had by then a Z80 with 64K of RAM and 4 disk drives (8"). By 1983, I was running a bank switching Z80 at 6MHz with 192K of RAM and the TPA was 63K. I had three 64K static RAM cards, an 8 channel serial card, and a pretty clever EPROM burner with a control program written in TP. The RAM and serial cards were designed by an old buddy and me, and built by a small company up near Mt. Loma Prieta.
DeleteMy text editor of choice was Electric Blackboard, form Santa Cruz Software. Pretty heavyweight for those days. Used virtual memory, so could edit any file that could fit on a disk.
As a 17yo I spent one Summer of 1978 in my small country town sitting in the Chemist shop (and Radio Shack outlet) programming the ONLY computer in town ... told the Mayor not to bother with the 16k version as the 4k was more than enough memory ... fail
DeleteYes, I also had a ZX-81 that I saved and saved and saved to buy... I bought it as a kit with the 16K memory module. Then proceeded to modify it by adding 2K of static RAM internally which could then be used to remap the character generator. I then programmed it using manually assembled code. I would write all the mnemonic instructions onto grid-lined paper... then looked up each instruction op-code, leaving room for going back to "fixup" jump offsets... I did this to build a simple assembler... in assembler.
DeleteAround 1985, Xerox flooded the surplus market with the remnants of the failed Xerox 820, which was a CP/M system based on the Ferguson Big Board design. I purchased a functional, populated motherboard along with a couple of blank, high quality glass-epoxy boards. They looked like this: http://maben.homeip.net/static/s100/xerox/photos/Xerox%20820%20Motherboard.jpg
DeleteI built several of these systems up, replaced the WD1771 SSSD floppy controller with a WD1793 floppy controller on a special daughter board that plugged into the WD1771 socket. The WD1793 daughter board came with a new set of BIOS roms.
This allowed any combination of 5.25" and 8" floppy drives, in SSDD or DSDD. I had 3 8" Shugart SA901 drives for which I created a special adapter board to convert to use the 50pin SA801 interface... Eventually I found some SA801 surplus logic boards and replaced the SA901 boards with the SA801 versions. Reliability was increased. I also had one 80track DSDD 5.25" floppy... I could store more on that drive that two of the 77 track 8" drives, although the 8" drives were faster (spinning at 360 rpm instead of 300).
I merely upgraded the ZX-80 to the 81 by replacing its ROM and adding that 16K pack. The extending of the (6502) Assembler I did for the Acorn BBC B, by printing out its entire OS EPROM code, "fixup" jump offsets and just patching a lot of in-place code. So then I had a 6502C Assembler that would work on the 6502C processor extension. In those days one could be in control of and grasp entire systems. Today a mere phone is a trillion times more complicated. :)
Delete+Allen, I was not (cough) as young when I grabbed the Z8. The most complex design I did with it was a two processor solution to managing a VTR in an editing environment. One CPU controlled the VTR (RS-422), and the other was a SMPTE time code reader/writer. They cooperated on search, so the controller passed controller would determine by the time code how far it needed to go, and therefore what speed, and how many different speeds to use. The reader would search to target 1, and tell the controller to drop to the next speed. New intermediate target and repeat. A ballistic search with minimal overshoot, and surprisingly quick to debug. Whew! With Z8 and Super*, I did almost everything in interrupt handlers, and used the register block switch to quickly change context. Took a bit of getting accustomed to, but it was a slick way to handle real-time.
ReplyDeleteI learned a lot about concurrent programming by doing similar things... although I didn't really identify it as such. Looking back, the concepts are all the same. I eventually learned that the main program loop would have to have "critical sections" around certain bits of code to ensure consistency... In those days a "critical section" was simply disabling and enabling interrupts.
DeleteIn my case, the routines were fast enough that I could use a very simple strategy for enabling and disabling the interrupts. The toughest part was coupling the two processors, which I attempted to do using a rather poorly documents "feature." After about three days of failing to get any sense out of it, despite having a buddy inside Zilog, I switched to handling the interaction on my own code, without the feature.
DeleteFun times, especially with some of the things we needed to do then, and the constant pressure to keep it fast on a slow clock.