My early interest in electronics (1970's) was in stereo and amateur radio, not computers.  Remember the line in the movie "Pirates of Silicon Valley" where the executive, puzzled and tapping his pencil on the desk, said slowly, "What would the common man want with a computer?"  (They must have had some good laughs making the movie.)  Back then, computers were rare, huge, and expensive, and people who worked with them seemed next to God or something.

I've been inactive in amateur radio since 1984, but I've maintained my license in case I'd want to make my own radar or missile-guidance system to take out an ice-cream truck or something exciting. 🤣

I got mildly interested in computers when I wanted to do audio and RF circuit calculations that took thousands of iterations.  I got a TI-58c programmable calculator (shown at right) in Dec '81.  The next year, I took a microcomputer class with AIM 65 computers, and a FORTRAN IV class which required doing our practice on the school's IBM 360 mainframe computer.  You'd transfer your hand-written program onto cards at a big card-punch machine so the dresser-sized card reader could accept it, then rubber-band the cards together with a paper having your account number and put it in a cubby, and come back two hours later for a printout of all the reasons it wouldn't run. 🤣  I hadn't heard of Forth yet; but by then, the boys who had access to an Apple or TRS-80 or similar were using BASIC, and assembly if they were more adventurous; but the school was behind the times.  It reminds me of the 1969 movie "The Computer Wore Tennis Shoes" where Medfield College was given its first computer, free, because the computer (apparently a Burroughs B205) was already so outdated.

I worked at TEAC in Southern California in '82-83, repairing semi-pro tape recorders.  There were about 120 employees, and only one computer in the building, occupying its own special holy room, off limits to all but two or three priests, and all the sales and accounting people had terminals hooked into it.  It was only for data processing, not at all for embedded control which would soon become my greatest interest.  By that time some of the tape recorders I worked on there had microcontrollers (with bugs), although microcontrollers were definitely not ubiquitous yet.

A friend had an HP-41cv programmable calculator with powerful (albeit slow) I/O; but I didn't initially think I could justify the expense to get one myself.  When I worked in applications engineering in '84-85 at a VHF/UHF power transistor manufacturer, having an ultra-portable hand-held unit to control repetitive processes with the lab equipment became quite attractive, and the HP-41 calculator fit the bill.  It could be taken from your desk to your workbench and back, much more easily than laptops (which didn't really exist yet), and it was easier to program than the bigger options.

In 1986 I was the only engineer working at a much smaller company, and having gotten an HP-41cx by then (shown above), I set up our first automated testing of products with it.  The program I wrote for it was 20 pages of keystroke programming, and accessed a half-dozen files.  Here's a bit of what it looked like, with comments added.  I hope your monitor doesn't wrap the lines.

 90  LBL 04        \ Numeric label.  Alphanumeric labels are allowed too, but they're less efficient in this case.
 91  FC? 10        \ If it was testing the right earphone before (indicated by Flag 10 being Clear),
 92  "0046"        \ then connect the left instead.  This string of digits (as text) is a command to the Cytec relay box.
 93  "├01471145 "  \ Add to string: Disconnect +13V from DMM line, and connect microphone DC voltage line to DMM line.
 94  7
 95  SELECT        \ Now select the Cytec relay unit to talk to (whose address is #7 on the HPIB bus).  It has 128 relays.
 96  OUTA          \ OUTput the Alpha register (now containing the text string of digits formed above) to it.
 97  22
 98  SELECT        \ Now select the DMM (digital multimeter) to talk to (whose address is #22 on the bus),
 99  IND           \ and INput a Decimal number from it, which from previous set-up, makes it take a voltage reading and send it.
100  STO 17        \ STOre it in register 17.
101  FIX 02        \ Put the display mode in FIXed-point, showing two decimal places.
102  VIEW X        \ Put the resulting reading in the display.  It is also stored and will be printed later if operator chooses.
103  "01451142"    \ Disconnect the mic DCV line from the DMM and connect the mic plug tip voltage (for push-to-talk test).
104  7             \                                                  (The string of digits is a command to the relay box.)
105  SELECT        \ As above, select the Cytec relay box to talk to.
106  OUTA          \ Like line 96.  The string in line 103 gets sent to the relay box.
107  22
108  SELECT        \ Select the DMM again.
109  IND           \ Like line 99.  Get mic plug tip voltage to check for shorts to center ring or ground.
110  STO 14        \ STOre the voltage in register 14.
111  9
112  X<Y?          \ Is 9V less than the tip voltage?  (ie, is the tip voltage over 9V?)
113  GTO 05        \ If so, skip the problem message and go down to label 05.  Normally it's at the voltage of the 13V power supply.
114  SF 08         \ Set Flag 08, signaling a problem.
115  FS? 09        \ Is Flag 09 Set?  A "yes" mean it's in printout mode and should not stop with each problem but rather continue,
116  GTO 05        \ and skip the problem message in the display.  (Resume down at label 05, and print all test results at the end.)
   <snip>
137  22
138  SELECT        \ Get ready to talk to the DMM again.  (22 is the bus address of the DMM.)
139  "ACV;R,5,.02" \ Tell it to get ready to measure AC voltage with a maximum of 5V input and give .02% (1mV) precision
140  OUTA          \                                                         (This sets the range and number of digits.)
   <snip>
150  9
151  SELECT        \ Get ready to talk to the signal generator (which is at address 9 on the bus).
152  CLRDEV        \ CLeaR DEVice (like a software reset).
153  INSTAT        \ INput STATus to clear any error conditions that may exist.
154  "A.05P1I"     \ Set Amplitude of signal generator to .05V (50mV) and enable output.  The "I" makes it go ahead and execute
155  OUTA          \                                    the command string.  (Frequencies and amplitude adjustments come later.)

My 41 was getting used all the time for production testing, so I got myself an HP-71B hand-held computer (shown at right).  One thing I got for it right away was the Forth module.  Unfortunately the manual assumed that the user was already experienced in Forth and only needed to know the peculiarities of this machine which had a 4-bit data bus and 20-bit address bus and 64-bit registers.  At the same time, I got Leo Brodie's book "Starting Forth," and unfortunately it assumed you had something to practice on.  So they were left pointing at each other.  I did manage to get going though.  It was a rather poor Forth; but since it was Forth, I was able to extend and improve it a lot, and even speed up built-in words without resorting to assembly language.

Although I thought Forth was great, I initially thought there was no way to do certain things in it.  As I gained experience, I found that not only was there a way, it was a super elegant way—it's just that it didn't initially meet the eye.  There are tons of those.  Those solutions tend to be non-obvious, because instead of being canned and advertised or even put in a manual, it's just that the tools are there waiting for you to do things with them that perhaps no one else has done or even thought of.  There's a flexibility there that I have not seen in any other language.

   
Of a later set of automated test equipment I designed, built, and programmed there (shown at right), there were initially supposed to be seven sets, so "rack-and-stack" IEEE-488 equipment would then be too expensive, especially if a deal turned sour and one of our Korean suppliers kept our hardware (which did happen later).  So since the programming and design time could be amortized over plenty of sets if we made our own, that's what we did.  STD bus (which stands for "simple to design," not "standard") was chosen for its low cost and wide range of available boards, and I designed several more custom boards.  The computer board used a 6502, and I programmed it in Forth.

There was a ton of wonderful IEEE-488 test equipment to drool over in the thick, hard-bound Hewlett-Packard catalog that came out every year.  I couldn't afford it, but it didn't take a genius to see the possibilities with making my own computer and rigging up inexpensive substitutes with A/D and D/A converter ICs, relay outputs, etc..  Soon I wanted microsecond control of the pins, something I couldn't get with the HP-41 or 71 (even programming them in assembly), and I was dreaming of something like my workbench computer.  Although my first one (1985) worked, it was far bigger and more complex than it needed to be, and wasn't much good for anything.  I did learn a lot about what would be good though.

I had a couple of false starts on making a nicely packaged workbench computer with an ABS plastic box that could be thrown in the attaché case, then in just one week in 1992, built the original form of the 6502 workbench computer I use now.  Every few years, I've added something to it.  It has proved incredibly valuable for controlling experiments and processes on the workbench, trying new ICs we would put in products, and programming PIC microcontrollers for several products.  It actually has a 65802 now, not 65c02, and I developed my bank-0-only '816 Forth on it.

I've only developed one product to sell which ran Forth, a gizmo for track sprinters and hurdlers to train with, to measure their acceleration through the first 10 meters, 20 meters, etc..  The other dozen products I've brought to market (mostly in aircraft communications, and one semi-medical device) had PIC16 microcontrollers which didn't have the resources to run Forth.  But around 2012 I implemented Forth-like program flow control structure macros which dramatically increased my productivity in, and enjoyment of, assembly language.  Such an improvement!  I wish I had done it 25+ years earlier!

Today I use Forth on my home-made workbench computer for controlling experiments, taking data, generating signals, programming PIC microcontrollers, etc..  I use the workbench computer as kind of a Swiss army knife of the workbench.  The link tells what it is, what's on it, how it's controlled, things I've done with it, etc..  I've mostly been using it in 65c02-emulation mode since I use a lot of applications I wrote many years ago for the '02 Forth.  I do have the 65816 Forth working.  It could stand some more testing, and I need to work further on the documentation, because I want to package it with small computers for computer education.  There are dozens of very inexpensive and powerful SBCs on the market, but they mostly have too many layers of software isolating the student from the bare metal.  Even USB is impenetrable by the non-computer-engineer, USB 2.0 having a spec sheet of 650 pages!  As a result, we're training paint-by-number people!  Where are the real engineers going to come from in 10 or 20 years??  The 65xx processors are easy to understand in both software and bus structure, easy to build with, easy to program in assembly language, and I can add Forth as more than just a monitor but also a powerful programming language.

   
(and there are more pictures of the workbench computer at the link).

See the list of my articles that are on this website and 6502.org.  Ones that are at least partly related to Forth are:

• unsigned division of a 32-bit dividend by a 16-bit divisor, resulting with a 16-bit quotient and a 16-bit remainder, presented for the 65C02 (with changes for use on 6502) and 65816, with notes of interest to Forth users.  Corrects a bug in the public-domain 6502 Forth division UM/MOD.
  
  
• unsigned multiplication (on forum), with 16-bit factors and 32-bit result, correcting a bug in the public-domain 6502 Forth multiplication UM*, as with the division article above.  Faster methods are offered in the comments, but they have not been tested thoroughly.
  
  
• D< bug in common Forths, plus a fix (on forum)
  
  
• Servicing interrupts on a 6502 in high-level Forth, with zero overhead!  Actually, the interrupt-service code is started even sooner than it would have started if it were inlined code instead of interrupt code, because NEXT is shorter for heading into the ISR than it is for getting to the next instruction in the regular Forth code.
  
  
• large look-up tables for hyperfast, accurate, 16-bit fixed-point/scaled-integer math, with explanations.  In the extreme cases, the look-up can be nearly a thousand times as fast as actually calculating the function, and it will be accurate to all 16 bits.  No interpolation needed.  The article on the front page of the section also shows how even without using the tables, scaled-integer math is very capable of doing things that most people think you can't do without floating-point.  (Notice I did not say "fixed-point," which is a limited subset of scaled-integer.)  There's further discussion on it in the RPN operations chapter of the stacks treatise.  In the early years, Forth always encouraged doing arithmetic in scaled-integer, and it's still relevant for processors that don't have hardware floating-point support.
  
  
• Forth-like program structures in 65c02 and PIC16 assembly language, using macros.  These have been wonderful to work with.  I wish I had done them 25+ years earlier.
  
  
• simple methods of doing multitasking without a multitasking OS  The last 40% of the page has extended examples of my Forth-like program flow control structures implemented in 6502 assembly language through the use of macros.
  
  
• My problem with the C programming language (with comparisons to Forth)
  
  
• treatise on 6502 stacks (plural, not just the hardware stack that 6502 puts in page 1), starting with the basics and working its way up, including virtual stacks, stack addressing, passing parameters, inlined data, RPN, synthesizing instructions, self-relocatable code, local variables, recursion, compiling or assembling program structures by using stacks, and more, in 19 chapters plus appendices.
  
  
• 32-bit DO LOOP & related words in 6502 ITC Forth (and wow does it ever take a lot of instructions to do it on an 8-bitter!)