Yup. October 1968 I was introduced to an IBM 1130 and I went nuts. I took IBM's four volume programmed learning course for Fortran IV and did nothing but study it for three full days. And then I began writing code, catching on very quickly. My brain was apparently designed for this. Soon after I became interested in "machine language" that some talked about. Fell in love with that too and it became my favorite way to write software. Still is.

It became clear to me that learning algorithms was key so for years, that's what I did. I turned myself into an algorithm encyclopedia, which served me ever since. I got hold of the source to IBM's SSP (Scientific Subroutine Package) and struggled through studying the nuts and bolts of it. Truth be told, it was the SSP that led me much deeper into math than I had ever gone before. What's an eigenvalue? What's a Fourier Transform? What's a Taylor Series. Then I learned how an APL interpreter worked from the guy who wrote the one that ran on Sigma-7s and Sigma-9s. Then compilers. Then I was faced with creating high resolution plotter graphics. And I learned how databases work, ISAM, HIDAM, etc. Then Knuth's books came out and I absorbed them like a sponge. Then I met Keith Kiyohara who taught me how to write operating systems, multitasking, task scheduling, something I've use many times since in applications ranging from games to process control. On and on. That's pretty much how it went. Lol.

For some reason, today, the excitement of those days is gone. Much of the excitement from the beginning up through the early 90s came from figuring out how to push machine to deliver the highest performance possible. Computers have become so extremely fast with almost infinite resources, it's not fun anymore. It used to be that running a 2000 point cross-correlation would take some time. You could watch the computer hunker down and crunch on it for a while. Today, the same task runs instantly. Hit Enter and it's back at the command prompt as though nothing had happened. "Oh, crap, there's a bug." But wait, there's the result file, and it's correct. Wut?

Maybe I should have migrated into the field of weather modeling or other field that's challenging for today's machines.

Yeaaah. I love real-time programming, especially in machine language.

Hmm, your comment about APL is very interesting. You know, that idea might actually fly today. One of the things that attracts me to Julia is that it was designed, from the start, for supercomputing. Julia achieves something I never would have dreamed possible, which is automatic scaling to utilize all processing power available, however many cores, however many GPUs. Given that this is possible, maybe APL could be a language that could do this.

Julia has been adopted for use in all future weather modeling software worldwide. The Federal Reserve uses it for all it's modeling software. And the scaling technology actually works. How it works I'd like to know. Lol.

This ability was demonstrated nicely early last year. With the Covid pandemic getting underway, Oak Ridge announced that they would make Summit available for work on combating Covid. Microbiologists said, hmm, you know, it would be extremely useful if we could create a database of every protein the Covid genome can code for. So, they wrote a program in Julia to do this by brute force, debugged it on a laptop, and sent it to Oak Ridge. At Oak Ridge, they launched it on Summit. Within a minute it had propagated throughout the machine, which brough a petaflop of compute power to bear. Eight days later, they had their database. This is what Julia can do.

APL is a wonderful way to express mathematical problems. (Ignoring that it's indecipherable to anyone but the original author 😉 I wonder if an interpreter could be developed to convert APL into Julia code.

Well, you're right in there with me, maybe six years behind. I was fortunate to be in the middle of the age of huge mainframes and got the opportunity to use them. It appears you got into it at the dawn of microprocessors, and minis, which is what came immediately after. Only a ten percent difference in time scale. 😉

From the late 70s, into the 90s, most of my work involved what you mention in your other comment -- eproms, 8080, TMS-1000, 6800, 6809, COPS-400, Z-80, many others. I was a hardware guy from before my programming days, digital, analog, discretes. All that came together through the 1980s and 90s. In the 70s, I became clever with digital signal processing, which also playing into all kinds of unlikely things.

It's all about synthesis. (Literally and figuratively.)

Whether it's targeting software for air to ground missile, sounds for a video game, building a world record setting (at the time) e-beam lithography machine, cleaning up signals in a security system, doing seismic imaging for oil exploration, synthetic aperture medical imaging, it's all the same stuff to me. Everything, every trick and technique in analog and digital hardware and software cross-pollinates. That's serious fun for me. An algorithm I developed for making a certain sound in a video game comes in handy later for identifying the infrared signature of a tank hiding behind foliage. It's all the same stuff.

Yep, I hear all that. Pushing the limits on the IBM 370/168 sometimes resulted in core dumps that would take a whole box of 132 column printer paper. Jeez. At least we recycled it, even then. And then, it was poring over this ridiculous listing, all in hex, and highlighting instructions and making notes. This is how you did a "trace".

Unfortunately, although it was educational, I was using the PL/I Optimizing Compiler, which was sort of alpha or beta test level. The compiler had bugs.

So a coworker and I would attack this box sized listing plus two microfiche readers on a table. We had the complete source to the operating system OS Version 21 and the source to the optimizing compiler. It would sometimes take two or three days to isolate the problem. We'd then report the bug in detail to the PL/I compiler's development team, which was in England, and develop a workaround that wouldn't trigger the bug. (We never expected to get a fix out of the team in England so we didn't waste time with them.) Nor do I remember ever signing up to be an alpha tester for their fucking compiler. But, there I was. We used it instead of the F compiler because we needed the speed and advanced features.

The system operators hated us because we used so much CPU time and because the optimizing compiler was like Microsoft code. It broke rules and "abused" the operating system like a tool, not the other way around. It was not "well-behaved". So when the presumptuous optimizing compiler crashed it sometimes took the whole machine down with it, crashing a half dozen jobs for other customers and knocking the 40 or so time-sharing users offline. Kind of like Microsoft apps using secret unpublished functions in Windows.

But I was a young hotshot and didn't give a shit. I had a job to do. I wasn't well-liked and didn't care...except when somebody had a nitpicky bug in their pages of JCL that they couldn't find. I had a knack for finding JCL bugs very quickly so they'd come to me.

I have good memories of that time. Others might have a different point of view. Lmao.

I love your comment. We could talk for hours about this.

Same here. When I walk past the federal courthouse here I chuckle because I can see the stuff I designed from the mid 80s to mid 90s right there, where the Marshals let themselves into the secure parts of the courthouse. Still there, still running, with a measured, not calculated MTBF of 430,000 hours. You just have to want to and be willing to spend the few extra bucks and careful design to make it happen. Every federal courthouse, FBI facility, evidence rooms, and the Whitehouse are secured by systems that a great engineer, Gerald Hammond, and I designed and I wrote the software for. I won't win a Nobel prize for it, but I know, and that's all that matters to me. Yes, NSA as well, and all the other 3-letter agencies, and more, use these same systems today. For the NSA to accept them, they put these systems through every imaginable attack scenario they could think of. They passed with no changes. They work, they do everything you could possibly want. You'll find them at Sandia controlling access to nukes, and on every "boomer". They are built on Z-80 processors. At the time, we determined that the Z-80 was the architecture most likely to have the longest lifespan, and we were right. The Z-80 is a brilliant design and is ubiquitous. Weird as it seems, one of my design goals in the 80s that I set forth was that I wanted systems that Russians (during the Cold War) could buy and maintain without difficulty. You can still buy Z-80s anywhere in the world for cheap. It's a macrocell you can drop into any logic design you want still today.

Each product contains the same code. At the time I left in 1996, it came to 225,000 lines of Z-80 assembly code. No one has yet discovered a bug, and I'm confident no one ever will. I'm notorious for writing bug-free code that works first time. It's a thing for me that doesn't result from genius but from meticulous work and always assuming that something will fail. What can fail? If this failure occurs, how does the software react? How about this failure and that? Graceful recovery from failure is an obsession of mine and it's always served me well. I'm big on watchdog timers, stack level detectors, etc. The software is constantly watching itself. Obviously, there was the temptation to put backdoors into the system. There are lots of ways this could have been done. But I refused. I said, if I can break into this system, then it's useless. So I closed every imaginable loophole. What I didn't know at the time I was designing these things was the microscopic analysis these systems would be subjected to by NSA. Then, I was glad I'd chosen the right path. There are no backdoors and I can't break it. Maybe there's a really smart person who can break it but NSA apparently doesn't think so.

Your story about the phone call is really cool. I love it.

I suspect your work was in fields more sophisticated than mine. Mine was very down to earth, haha. Mine was more along the lines of who are you? Are you supposed to be here at this time? Are you supposed to be accompanied by another person? Who is that person? Are they supposed to be here? Are the two of you authorized to be here at this time? How much do you weigh? How much does the other guy weigh? Do your fingerprints match with who you say you are? Are you here by choice or are you being coerced in any way? You can tell me secretly without anyone knowing. Etc., etc. Interesting stuff to work out. Fun days those were.

I know that my systems have saved lives, prevented rapes, put criminals in prison. So that adds to it having been a worthwhile effort.

Our "secret weapon" was our patented scrambling keypad, the Hirsch keypad. It scrambles the digits on every use and has a very narrow restrictor plate so that only the person using the keypad can see the digits. All aspects of the keypad can be programmed for whatever level of security desired. With a scrambling keypad, I can watch you enter your code and learn nothing. This technology makes all kinds of things possible. To signal duress, just change the last digit of your code to the duress digit, which can be programmed to any number. The "who are you" question is determined by your code, which is always secret. Since the digits are (true) randomized each time the keypad is used, wear patterns cannot be discerned from the keypad.

Our main marketing point was that knowledge-based identification was more secure than any token-based approach. Cards can be copied. Keys can be copied. People can be physically forced to submit to a retina scan. A person can be killed, their hand chopped off, and shoved into the fingerprint reader. (All these things have happened). But knowledge-based is harder to defeat. No system can be completely bulletproof but ours came the closest and still does. For ultra-high security, you can combine this with weight sensing, plus a card, plus a fingerprint, and get close enough that the TLA's all went for it and still do. If you want to launch a nuke from a Boomer, or access the warheads stored in the mountains behind Sandia Labs, or in the mountain at Nellis, you have to pass through a Hirsch security system first.

Voting is an interesting problem that I've never given any thought to until now. How do you identify a random person off the street to a secure system. Nothing comes to mind, just now. Hmm.

Yeah. I don't even want to know how much typing I've done. I've been an inveterate writer since I was ten years old. My first purchase with my own money was a used Royal electric typewriter. (I had been using an old Underwood.)

I chose the Z-80 for long product life. The limited memory was a problem so I solved it with a paging scheme with 16k chunks and an extremely fast macro assembler that I wrote in C that handled the paging requirements automatically. (Fast and powerful assemblers is one of my specialties). There's a fixed 16k block of ROM, a pageable 16k block, a fixed 16k block of RAM, and pageable blocks of RAM. There are also expansion cards to increase memory some more for very large user databases, and other functions. The Z-80's block I/O instructions are used for these expansion bus transfers.

Each system can support up to 16 keypads. The proprietary serial communication protocal is also handle by the Z-80 by bit-banging. For this, the Z-80 is provided with a 4,100 Hz interrupt, which is used for the bit banging and also establishes the system's real-time timebases at 128, 32, 8, and 1 Hz, which are implemented by means of software interrupts. It's all real-time programming. Each system must control as many as 72 relays to control access points, locks, etc. It also supports up to 16 analog alarm inputs, which use DSP tricks to extend what is possible for an alarm input and to immediately detect tampering by anyone who isn't knowledgable about how the system works and has the equipment to defeat it. The 16 alarm inputs can read 3 contacts each. So there are 48 inputs in all. Alarm inputs are fed with a current source and read with an A/D converter.

Most of the products have 256k of ROM on an easily changed cartridge equipped with a 37-pin D-connector. Some have 512k. This way, software upgrades are easily sent to customers. The code that runs in those machines is about 225,000 lines of Z-80 assembly, designed to detect and take care of upgrades, of course.

The systems supports six languages, English, German, French, etc. for programming (via the keypad) and output on a printer. The systems can, of course, be networked and controlled from a central computer.

One Z-80 chip does all that.

This kind of thing is, for me, maximum fun. I got hooked on enabling micros like the Z-80 with external hardware when I designed some coin-op video games around 1981. I used external logic that was "tickled" by the Z-80's address lines to create video. So the sequence of Z-80 memory accesses determined what the external logic did. Pretty weird, huh? Hahaha. This involved self-modifying code, of course, but that's okay in a device like a coin-op game, where there will be no "maintenance". When it goes out the door, it is what it is. The control code would write NOPs and Jumps into a region of RAM, then jump into it. The execution of those instructions drove the address lines (at bus speed) to "tickle" the external logic in the desired manner to generate the desired video at microsecond speed. Make sense?

This is a little weird, so if it doesn't make sense, please speak up and I'll try to explain it better.

This is why thing were SO much more fun back in the day. Twisting a 4 MHz Z-80 in such a way to make video is my idea of fun. It's impossible.

The sign in my office for many years read:

The difficult we do immediately.
The impossible takes a little bit longer.

Yes, although I understand the reasons, I still find it disgusting that the smallest Hello World program you can write is a 72k load module. Wut? This should compile to maybe 300 bytes? But hardware has leapt so far ahead that nobody cares about size anymore.

The Z-80 is really a little miracle, in my opinion. A real work of genius. Just a few thousand transistors. Today's processors are composed of several billion transistors. Mind-bending.

Yeah, the stuff I designed is complex but it has to handle a complex job. So far, so good. No bugs found yet so I don't think there are any. Lol.

An amusing thing to me is that when I first started creating these systems in the mid-1980s, the sophisticated (at the time) features I invented needed names. Those names and functionality are now standard in the industry and nobody gives them a second thought. Hah. I created those. But that's kind of the story of my life. I've done this since the 70s.

Since you are a high-level language guy, have you considered studying Julia? You might get a kick out of it. Julia is great because it absolutely not focused on "object-oriented as a religion" like some languages like C++ and Python are. Julia is a straightforward language that uses certain selective OOP techniques where they are appropriate and make things work better. Otherwise, it's procedural.

Julia has many things going for it that you may find interesting. On any platform, just install it, launch it from the command line by typing "Julia", and start in. It behaves like an interpretive language but runs almost as fast as compiled C, unlike Python. It had many other advantages and is under intense development because it's so useful and has been adopted by the Federal Reserve for econometric modeling, and many others, and has been mandated as the language required all future weather modeling software, worldwide. I don't know if you enjoy mathematics, but Julia will replace Matlab in time. It was designed with mathematicians in mind.

Yes. I've been in the computer programming biz for a long time. This is purely a subjective feeling about this. I grew up in the era where, subjectively, programming felt like forcing or tricking the machine into doing what you wanted. It was your intelligence, your genius that made it happen. And you could pat yourself on the back when you succeeded.

Programming in Julia feels completely different to me and it's changing my attitudes. Julia feels more like the language allows me to describe to the computer what I want it to do, and it then figures out the optimal way to do it given the hardware I'm using right now. So, it feels like like acrophobia sometimes. Haha.

I love machine language and I'm good at it. I'm full of tricks to get what I want. This is fun. High level languages never excited me that much, although I learned and used plenty, until C came along. I liked C because it was just one level above machine language and I could dip down to machine language at any time with the #asm directive. I love C.

With Julia, for me, the paradigm is completely different. It's the first language I've learned where I'm not motivated to learn how the internals work, how does the compiler work, what does the resulting machine code look like? I don't care because it doesn't matter unless I were to become a Julia language developer.

I think this is because Julia does more than any language I know of does. It makes optimal use of whatever hardware you're on, automatically. And, frankly, I really am not up for learning about how it does this sorcery. So, finally, I can let go of understanding how it works internally. I don't even want to know. I'll leave that up to people who know how to make it utilize all four cores on my machine, plus the GPU, without me figuring it out. And then I could email my Julia code, unchanged, to Oak Ridge, where it could be launched on Summit, and within a minute have a quarter of a million GPUs and petaflop computing power bearing down on it, without any effort on my part or those who launched it on Summit. It just works. It just runs.

I don't even want to know how that works.