dwarman

"not a game" - well, he certainly hid this well behind a playful and enthusiastic way of teaching, as when he was our Props of Matter lecturing prof at Birkbeck College in the early 70's. And very effective too, not that I followed the Physics path beyond that (the siren call of computers was stronger for me).

murders, pl

I spent many happy years making the Z80 dance, from Summer 1976 through Spring 1989, architecting and writing statistical multiplexors at MICOM Communications in LA. Micro 800 line. That is a Hard Real Time application, and the hardware for the first model was only 4KROM and 4KRAM. I made one Z80 do what the competition (CISCO) swore required 5, and laughed discreetly at us, but it worked, sold out the bottom end market from under them, and suddenly we had a runaway and I got an excellent team to buttress and ultimately take over the baton from me. I would dream in Z80 ASM in those days.

The Z80 had two hardware features that made it possible, and that nobody here has mentioned yet:

1: two sets of working registers, with a one byte instruction to toggle between them. I instruction cyclke to context switch between application and interrupt handlers. Only the TI 9900 came close with its in-RAM working register sets.

2: hardware vectored interrupt dispatch, fully suppported by theor accompanying peripheral line. Just a few clocks from raising an interrupt to executing the first line of code (typically switch context then ...) of not only the device but it's reason for interrupt code. No code wasted interrogating bitfields and scanning registers. 2 usecs interrupt response time. Faster than an Intel i960 with its 50MHz clock, that came along later.

My Lua system uses MOP too, though I never heard that term before. And structured pipes. I like it and wrote it for a dataflow bsased event driven system.

I still use a version of FORTH as an embedded debug tool, have done for several different CPU architectures over the years. I wrote some extensions that help to offset the "double edged sword with no handles" danger, such as local methods, call/return prototypong (basically formalize=ing the conventional word definition comment, which I also snag as is into definitions as a help string) that garuntees stack frame handling on entry and exit. Also wrote an auto-translater for C wrappers of function calls and struct definitions to get symbolc interaction with the code being debugged. Really speeds up behavioral debugging (Real Time systems have to be runnig to diagnose, not halted and flayed open on the operating table like breakpoint debugging does).

I'll echo the observation: datacomms protocol parsing and generation are nothing but state machines.I started in that domain back in 1973 or so, and some configurations - statistical multiplexors for example - may be running upwards of 34 FSM's concurrently and independently. And that with a mix of multiple instances of one protocol. So I developed a cooperative multitasking pattern that ran on a virtual OS scheduler. Indeed in some systems it was the real OS. State variable is a function pointer to a function that returns its own protoype function pointer. Arguments include event, plus data plus state context. Supports submachines too. Still using it. No switching complex stack contexts, runs fast.

Forgive me, but I recall, with some decades of practice, a major point in FORTH is that one constructs a vocabulary and syntax specifically for solving the problem at hand. Compiler primitives are just as first class as regular word (aka function) definitions, including how to compile itself as well as what to do when executed (DOES> keyword, which can itself be redefined). FORTH may have a clunky and primitive reputation, but it seems to me it qualifies as a programmable programming language.

Started in 1967, in support of my job as commissioning technician (bean counter title - I was only 19 and no degree) at Elliott Brothers Elstree on their 4100 mainframe computers production line. Did hardware design and supporting software/firmware for a decade before switching primary job to RTOS's and firmware. Still employed. I've posted my general CV elswhere here.

Don has the longest run though.

50 years. Somewhat different to most. Mixed hardware/firmware/software, niche talents matched to niche markets. And practically all self-taught. Along the way got a BS and most of an MS in CS but none of it was applicable to my career, nor required for it, except the one class I keep alive was the FSM class. Perfect for Hard Real Time Event Driven applications. My metier. Almost all of the 50 years qualifies as nostalgia, even current, because it has all been fun, all been coninuous learning, all been continuous invention, and except for some esoteric math in my current Audio DSP path there has never been a book about it.

1967-9 accidentally hired at Elliott Automation UK as comissioning technician, finding bad wires/doa components in their 4100 series mainframes as they came to the end of the production line, prep for shipping. Completely discrete hand built machines, right down to hand-woven 48K x 24b main magnetic core memory. No prior experience outside of hobby electronics, only 19, CS did not exist then. This experience probably seeded all my first principles of computing, I had to teach myself in intimate detail how a room sized computer works, and how to program it. Both good and bad.

1969-71 (I know, by decade, but my trajectory does not fit decades easily) design engineer at an EG&G UK subsidiary called Nuclear Measurements. Another accident. Made instrumentation for the two main Nuclear Fusion labs Daresbury and Culham. Got to climb around inside the Zeta Pinch 1MF capacitor and the Tokamac. By chance visited a PCB layout researcher using my old 4130 with vector graphics, thesis on rats nest automatic layout techniques.

1971-5 Another poach, this time into data communications world. I'll note here that although I was then a hardware nut, programming computers is always an essential skill to have. And also in those days of really tight resources, doing it efficiently was default, whatever Tony had to say about premature optimization - the code has to at least fit before it can be made to work. In this phase I even had to design and write an ASM a custom computer a bit more featured than a Z80, only in SSI 7400 series TTL. And in 8008 days, no Z80 when I started.

Still a big-eyed kid, somewhat bemused that folks wanted me to actually pay me to do all this learning. Learning that even today seems to be missing from CS/CE, at least as I can tell from graduate hires since then even up to today. Got very good at "Making it up as I went". There was no book, really, for what I was having to produce.

1975-89 moved to sister company in LA - poached again - got even deeper into data comms, designing Statistical Multiplexors and protocols for University time share computer centers. Employers made their $Ms but neglected to mention stock options to me. OTOH as a founder and tech lead I had a blast, and seeded a great dev lab culture around me, many of whom are still in touch.

1989-97 This was a really fun time; I and buddy did our own start up (Lone Wolf Technologies) based on a mission critical deterministic protocol we had dreamed up and a product using it to network MIDI synthesizers and controllers in large venues and pro studios. Moto 68HC11 box did 4 ports, glass fiber networking physical layer allowed up to 2 Km separation, multiple boxen, each with a mirrored virtual 16x2 config LCD onto the network as a compound entity (edit any box from any box), full soft topology routing and filtering and remapping. Yet more learning OTJ, and inventing. And the customer base was, well, rarified. Herbie Hancock, ELP, INXS, that rarified. Not actually a Good Thing as it transpired. No volume. But oh what fun. Then Paul Allen invested. A long story not for here. But moved us all to Seattle.

1998-9 designed a FPGA for autonomous isochronous multi-medial FireWire transport (AFAIK the only one that did not funnel channel data through the CPU). Was missing hardware, this was an intense but ultimately successful gig, eventually made its way back into music world as control surface driver/interface.

2000-7 Second time Lone Wolf, soon renamed SingleStep, designing a graphical programming/delivery platform aimed an large scale network management. Again great OJT learning and invention but customer base not so much fun.

2008-present now this one is a fun employer with a fun product. Not just fun to my nerd core - fun is their product. I refer to Nintendo. Worked on Audio engines for WiiU and Switch.

The two big gaps: "Consulting Years". Nail biting, more like. No nostalgia for those.

So, not your typical career path. No front end / back end / full stack crowded job market. I'd have been out of that and unemployable probably 20 years ago if that were the case.

Native WinAmp has two dropin extension systems. The one everybody seemed to use was MilkDrop, but they also had AVS (Advanced Visualization Studio), for which I wrote a bunch of extensions about a decade ago. These included several composition dlls (multi-lane video pipes, MIDI control, joystick control, 30 sec rolling video recorder/playback) and also a number of effects (image animations, placers, blenders, oscillators). This made for a very engaging interactive experience, especially flying through using the joystick to control pretty much any set of parameters. Turns out the visualizers have hidden strange attractors that never appear when just using passive mode. That was in XP, I have waiting a Windows 7 build TODO.

I'm semi-guessing the browser re-implementation does not support these. Pity.

I used Lua 5.2 (with 5.1 compatibility enabled) to embed in a C framework for building and executing data flow graphs. I implemented C .h header to JSON and back, and also an API wrapper generator, which really helped things along. The basic features include: co-operative FSM scheduler (using coroutines for sleep etc), structured FSM Engine, structured data pipes (stucture defined in C headers and piped in binary, but to Lua they look just like Lua tables syntactically), Event generation and propagation mechanism, ability to record and play back data pipe streams, fine grained MIDI parser and generators, and a bunch of other details. The embedding mechanism is generalised, and so there is alongside the Lua scripting a similarly complete FORTH drop in language, for those who might be interested. I think it's a pretty neat system, and works quite well.

The system had some turbulence during its inception in a now defunct very small company, but it all reverted to me. I would like to get it up on Github before I pass on (fairly soon, I fear), but need help fixing all the file headers, and some minor bugfixing. Volunteers? I have a minimal html description file if you'd like. But a build help file is needed.

There is another kind of acoustic delay line that was used in late 50's - early 60's that used nickel strips and took advantage of magnetostrictive property of Ni. I'm calling it acoustic because the memory was in the form of a compression wave propagated from driving magnet to sensing coil, then regenerated. Elliott Brother's 803 series computers used these for the CPU registers.

Hmmm. I created a system I called Sub-Machines back in the 80's too, though it never occurred to me that anyone else might be interested in it. I was particularly focussed on data communications protocol state machines. I could launch and detach, launch and camp (block), and launch and continue with other business until notified of a submachine's completion. Such notifications could also wake up camped super-machines. I could also get progress notifications bubbling back up. Worked a treat. To make it work I also had to create a co-operative function based multi tasking scheduler. It was very fast, and I still use it to this day. Part of the speed is not having to save context on every task switch. Takes planning though, unlike the lazy while(true) thread loops invented for junior programmers and used today way too much. But no real hardship when dealing with event driven systems, where each event has usually pretty short computations. Much easier to get true Hard Real Time systems to meet their targets.

I see they re-invented asynchronous logic, such as Chuck Moore's chip today uses, for their digital fabric.

Still have ny HP41C, with XMEM etc, but no longer carry it with me since i41CX came out for the iOS devices. Inludes all the rom extensions too. When I get the energy the system is for sale - printer needs new batteries, card reader needs TLC or replacing. I also had but sole an HP16 programmers calculator, since there is also now an iOS (and OS X) version. PRG 16C. My first was a Bowen around 1964/5, then an HP 35 in 73?. Sharp made what is likely the first BASIC programmabe (actually they labelled it, I recently found several OEMs of it) that really impressed me. I have no idea what happened to mine. Also have still a Radio Shack Programmer's calculator.

100 ms max lag is maybe OK for human vision, but you need to be down below 25 msecs between action and accompanying audio, or between action and video and audio. The human ear is much more sensitive to the time domain than the eye.

It's doable but hard. A game can be unplayable until the lags are under control, and only then can they become fun and immersive. Assume the game itself has that potential. But don't release until then.

Beyond this, I have no comment about the game itself.

"That which _can_ be configured _must_ be configured. Corr: defaults aren't.

(mine, inspired by WIndows 1.0 and it's only got worse since).

7 am shift change. Unless you are my mon who had me at 11:30 pm.

Even earlier: I implemented a Statistical Multiplexor - 8 async serial users muxed over a single 9600 Bd synchronous line - on a Z-80 with 4K RAM and 4K ROM. In 1977. Garunteed correct data delivery over lines as noisy as 1x10^3 BERT. A datacomms protocol that can do that is not a trivial beastie. The only technique that let me fit it in was state machine. It was the start of a very successful product line. I live by FSMs ever since. Software and FPGAs. And I agree about the OO cruft. I just use a function for each state and execute to completion. Perfect for event driven systems, which datacomms are a prime example. And very lightweight. In High level world, this needs a language with functions as first class objects. I have other useful representtions too. My favorite table based form is very handily implemented in Lua, should anyone be interested in seeing it.

There was a lot of collateral damage too, small firms hitchng their wagons to FW tubed out, or pre-93 developing alternatives to USB for the same ends (just bad timing). It was up-front expensive, and while technically superior to USB addressed primarily issues that were rooted in processor speeds of the time. If you could make the silicon. I have stories if interested.

Correct me if I'm wrong, but I seem to be the only person here to have weathered the entire evolution from 8008 on, for a living not as a hobby (though is both for me).

I am possibly approaching Senior Curmidgeon status, but I mean well. Even the early chips definitely required RTFM and some serious visualization chops, there are millions of bad and very bad things in a random poke, those two help you probe their borders instead of blue screening your brain. I see examples of ignoring both boasted about here. It's not lame to study before committing, and the needed info has never been secret. Please forgive me this, if you feel targeted. I am 70 years old, and am still doing this shit, on modern multicore 64 bit architectures, and would not be here without doing what I say. RTFM, run code in your head, when you got both start runnin the real thing. Short term nor for the impatient, but long term?

I wrote in ASM up to i286, and always had the specifications handly. Never poke around randomly executing nonsense code. Too easy to trash your HD, if you had one. Or find the real "Halt and Catch Fire". Messy. The books were easily avaiable, back to way before even the 4004, no excuse for not using them to run your probes in the virtual model of the chip implanted in your head from reading that book. The first experiments should then be in areas of confidence with valid data and no addressing violations. Steps, not f*it leaping off a cliff into clouds.

8080 was the last small space part, with only a total addressable 64K. I consider it the root of all evil, as it were, because it set the parameters for 64K limited program. All else flows from there because of the decision to maintain backward binary compatibility. So it was wrapped in redirectors and segment registers in an expanded 1M space, without any security or permissions management. Which would cost peanuts, a flag and some specific address decoder disables. Simple days.

I often took advantage of COM runtimes in those days. Often, and actually most usefully, without a DOS or RTOS between me and the metal. It was trivial to write a serial interface COM loader, and drop my FORTH into it for itelligent debugging. Or anything else, investigative or command.

The freedom started to go away with extra wrappers in 80286, which among other things intoduce "Real" and "Protected" execution modes, plus some extended native addressing modes. Starting to grow up, can still run 8008 COM code, but in that mode it sees only COM compatible register set, and has no access to the execution mode flag. Much "safer", sorta. Except still gets the 32 bit 808x indirect instruction address modes, if invoked in Real Mode.

Heard about "non-modal design"? 68000 got much closer. Every additional wrapper introduces large arrays of data re-routing and management logic. Needs a restart in design and philosopy. dropping COM support hardware and only allowing virtual machines to play is today's answer, getting closer, and much safer. And as core counts go up, have only latest clean architectures run on most cores, no wrappers, and a dedicated legacy core. Or chip. with FPGGA run time loadable architecture for that, agan no wrappers. But it may alreadt be too late. Too much investment that may get broken in amusing ways.

After the i286, the i386 on on to the present have foccussed more on speed and size of, and access to, Protected mode, runtimes, sharing memory, and verious support tricks. All carefully avoiding disturbing the ability to run by now ancient OS utities, buried deep in the underground of the OS. till WinNT, Win32, and the Pentium etc IIRC. Though I swear I still see several in the procces list on W7.

We built relay computers in HS in the early 60's. There was this street in London: Lisle St, in the Soho district. One could buy surplus PO 3000 multi-pole relays there real cheap - up to 10 pole IIRC. These were the relay type used on the Post Office Telephone exchanges, pre-electronics (up to #5?). In 66 I also discovered a recently published book by Russian authors: "Introduction to the Theory of Finite Automata" by Trachtenbrot and Kobrinskji https://g.co/kgs/EqZYC2 which taught me the formal of the topic using relay logic. I believe the robustness of Russian space tech was due to use of relays as well as tubes. That book gave me my career, effectively; turned out to be equally appropriate for electronic logic circuitry.

There's an old iOS App called Vtrace been doing this for years. Interesting to see toures from my home to a destination 10 miles away bouncing all overr the country several times. Not promising for when I need a short round trip time for musical collaborations.

thereby demonstrating just why she laughed. That R who yelled "Liar" at Obama? crickets.

creak. 69 here, still employed and coding etc, started in 1967, spent too many years having to make it up as I went along to specialize. If anything that specialty might be embedded systems, but not only. I would definitely guess my demographic is small. I find SO sometimes useful where my Google-fu fails me, but every so often I also get to ask the developer of the language/whatever directly instead. We're all about that age now, and it's a small and shrinking community.

The issue becomes really serious when playing 96 audio files simultaneously. As in: game audio or multitracking DAW (where 24 or more would be recording at the same time, not merely playing back). Every cycle counts there, any cycle not moving audio is a wasted cycle. Indeed, turns out (surprised me when I moved into this field), audio of any paralellism is the hardest Hard Real Time process in a computer audio system, or a game console, or pro audio mixing desks and synth racks. The human ear is the most time critical of our senses; you can drop a video frame and harly anyone notices, but everyone bitches about a dropped audio frame.

ps: this stuff is also achieved in iOS devices. Mind-blowing as that may seem.

pps: just playing audio files is not, in general, latency sensitive, so larger buffers can mask more egregious cycle wasting in the setup and other overhead. Playing sound effect files (gunshots, squealing tires, etc) is however latency sensitive, and there can be many at the same time, so there we shoot for smaller buffers and pay more attention to overhead reduction. In both cases, however, we never start outputting from a buffer that is not filled. Cacheing issues mostly, and also scheduling. Usually that is shared memory, even core to core dual cache shared, with the audio handled in its own subsystem, so there are some very subtle issues at the extremes we work in.

(I'll leave the Monster cable manutroversy out of it here:)

Why do they cakl it a jet? all I see are bunches of small ducted fans. And it's electric powered.

Audiobus provides State Saving, have you tried that? Feed it into AUM for IAA, AU, and their state gets saved, plus the routing and mixer setup.

Not watched the video, but hate to tell you, they are designed by visual thinkers. Linearization comes after the fact; one has to be able to visualize the operation of the logic networks etc during the design - and debug - processes. Things happen in parallel a lot inside a computer, no way is linear thinking going to create that. Validate, yes, but not create.

At least, that's my experience, not just of myself but of a number of the early inventors of these things that I happen to bump into a few times a year. Those still surviving that is.

Actually there is, in the (stated in the movie) supposition that what you can think about is bounded by the language you think with. Corr.: learn a different langauge, change how your brain processes your experience. So learning Heptapod changes your sensation of time, because time is a fundamental component of the language. Note how her future experiences become more detailed, less fragmented, and more focussed on "current" context, as she learns more about thinking in Heptapod. Not just revealing it to us, the audience: showing its progressive revelations to her. And then she writes the book on it, for the rest of us. And thus closes the loop.