dwarman · HackerTrans

"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).

dwarman

8 anni fadiscuss

murders, pl

dwarman

8 anni fadiscuss

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.

dwarman

8 anni fadiscuss

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.

dwarman

8 anni fadiscuss

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).

dwarman

8 anni fadiscuss

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.

dwarman

8 anni fadiscuss

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.

dwarman

8 anni fadiscuss

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.

dwarman

8 anni fadiscuss

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.

dwarman

8 anni fadiscuss

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.

dwarman

9 anni fadiscuss

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.

dwarman

9 anni fadiscuss

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.

dwarman

9 anni fadiscuss

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.

dwarman

9 anni fadiscuss

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

dwarman

9 anni fadiscuss

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.

dwarman

9 anni fadiscuss

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.

dwarman

9 anni fadiscuss

"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).

dwarman

9 anni fadiscuss

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

dwarman

9 anni fadiscuss

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.

dwarman

9 anni fadiscuss

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.

comments