Seems there's a buncha business software from Back In The Day, that runs on those quaint old minicomputers: PDP-11, VAX, HP-3000, and so on.
(HP-3000? Which generation? I seem to recall there was a total architecture change in the 80s. The one I hacked on in high school was a stack machine, and I think the newer ones are RISC or something...?)
Anyway: someone's gone and written emulators and is offering use of them as a cloud service.
Many years ago, I had the notion of implementing a PDP-11 CPU as a VHDL learning project. I subsequently switched to learning Verilog instead, did a few FPGA projects... and still haven't done that PDP-11, let alone the DEC-10 that's also on the "somebody oughtta do this" list.
Seriously, though: a fairly cheap FPGA these days should be capable of handling any of the old 16-bit architectures, much faster than the original hardware. Add an SDRAM chip and a microSD socket, and you've got a complete PDP-11, Nova, Eclipse, HP-3000, TI-990, etc., all in a business-card-sized form factor. If you want to run a timesharing service on it, you'll need a much bigger board to handle all the connectors. And, of course, a 9-track controller/formatter can be shoehorned into the same FPGA, but the connector for the drive (never mind the drive itself) will dwarf your actual computer.
And then there's the problem of getting ahold of the antique operating system of a long-defunct company... and permission to use and/or distribute it.
Still, it's a cool possibility. Maybe, In My Copious Free Time, I should design the hardware and create a couple of example legacy CPUs, plus the supporting cores for a typical application or two (e.g., making an SD card look like an array of DG disk drives). Probably needs a (yuck) ball-grid package and many-layer board, just because FPGAs with lots of logic don't tend to be offered in QFPs. So, keep the expensive board as compact as possible, and have fine-pitch stacking headers for a cheap, 2-layer I/O board?
And that way you could own your legacy solution, and have a bunch of spares in a shoebox in the office supply closet!
(Now I'm thinking back to the MicroVAX a former employer rented from one of the other employees, and the way it'd load its microcode from a little tape cartridge. Cute! But now the tape cartridge would be a little flash chip, and the process would take hundreds of milliseconds instead of a few minutes.)
Update: Foo. Don't have a handy source for 18- or 36-bit-wide DDR SDRAM. There's a 16Mx18 RLDRAM part, which I guess would do the job, but the supply appears to be drying up. Oh, well. If I really thought there was a market for the dingus, I guess I could call around to memory vendors.
Update 2: The heirs of Sir Henry Ninebit-Byte will be relieved to learn that Cypress Semiconductor is still making synchronous SRAM chips in 9, 18, and 36 bit widths, with capacities up to several Mobies on a single chip. A 4-Moby part runs about $50 in onesies; not bad. And... these things are fast enough that an 18-bit, or even 9-bit, memory bus would probably outrun the CPU (and would most assuredly outrun one of the originals).
Man... I remember the days of 1024-bit RAM chips. With microsecond cycle times.
Earlier this week, XBradTC linked to an interesting vid on DIY radar.
Which stirred up the ol' creative juices. I hate presentations in video format; much prefer text + drawings so's I can skip back & forth easily, and the vid is in tl;dw territory at the moment, but I downloaded a copy and skimmed through, and it reminded me of some things I'm sure I knew back in the '90s, but had somehow forgotten.
Like, the easy way to get range is with linear chirps and interference-frequency measurement, rather than trying to do direct time measurement between two detector outputs (with the attendant requirement for very short pulses, if you're trying to measure smallish distances).
Modest-range radar had crept into my mind a couple of years ago, in connection with the problem of trying to put a plane on a runway blind. (Gee, what happened a couple of years ago that would bring up such thoughts?) Augmented GPS will get X and Y close enough for a plane that's much smaller than what the runway was designed for, but accurate Z is a major headache. Integrating GPS and a short-range radar altimeter to get the last couple hundred feet with sub-foot resolution? Well, it might just work.
Not that there's much prospect of actually making a product of that (despite my having a totally cool, as well as blindingly obvious, UI concept). Between regulatory issues and potential liability, I rather suspect it's a non-starter.
Still, various ideas are now rattling around in my head (and competing with all the other ideas I haven't been having time for). Maybe next year, if I manage to relocate to a place where I'd have a proper workshop and lots of tinkering space, I'll turn some of them into products, or at least subsystems for sale.
Just got a cool-new-products email from one of the Euro-component companies.
Attention-grabbing: a 1" square by very flat SMT lithium cell, 0.7AH, for powering those tiny IoT thingies when it's dark.
So I click, then click through to a distributor: $28 each in quantities of 250. Eek?
Really, now. What "just because it's cool" IoT gadget can you sell at a price consistent with a $28 battery?
We need cheaper energy-storage devices! (Yeah, rather bulkier no-name Chinese lithium cells of similar capacity, intended for use in toys, can be had for under $5 in modest quantities... but apart from the bulk, I'd be concerned about long-term reliability.)
We also need cheaper radio modules. Incorporating an OEM ZigBee module is another market killer, partly because ZigBee is such a big (and subject to licensing) protocol.
Maybe I should dust off Bluebird. My prototypes, several years ago, worked fine, and a transmit-only module drew right around 1µW in standby mode (ready to wake up if an input changed state, so suitable for applications such as motion sensors and doorbell buttons). Never got to the FCC certification stage, but that should be a no-brainer. A super-low-standby-power transmitter module, and a fairly-low-power transceiver module, range of 100 feet or so indoors, provided as little boards with certification? Product idea! (Actually, it might make more sense just to make the transceiver module and have a mode-select pin; TX-only can be slightly smaller and cheaper, but starting with a single hardware article cuts NRE, low-volume manufacturing costs, logistical headaches, and so on. It would also need to incorporate the functionality of a planned-but-never-prototyped third module, the hub.)
Product concept: Helicopter Parent. It's a quadrotor that follows your daughter around and keeps an eye on her.
With the optional shotgun attachment, it becomes the Chaperone Drone. (Maybe also a pheromone sniffer unit?)
For positive tracking, the subject should be wearing a transponder. Maybe in a locking collar.
No need to build the actual product, just some props for the promotional vid. Basically, a couple of quadrotors, one with a pan/tilt camera mount, plus a toy shotgun (lightweight plastic) and an adapter to hold it in the camera mount.
Cast... need the kid (maybe two, ages 15 and 18), Mom (perky helicopter-parent type), several leering boys (maybe one group of high-school seniors and one of college sophomores), and of course the Voice-Over.
Location: has to look like a school. Also has to be a place where something that looks like an armed drone won't trigger a total freak-out.
Laundry machines that send a message to your phone when they're done (or in the event of a load imbalance, or other anomaly).
Not so much for home; that'd be more of an IoT thing, with status available through the household network. For laundromats, guest laundry at motels, and such.
Maybe use NFC to send the phone number. (If done right, this could discourage pranking.) Better still, combine with pay-by-bonk.
(Not that I use pay-by-bonk, nor even have it enabled. I haven't even looked at Google Wallet lately, aside from noting that, when I set it up years ago, I seem to have used a credit card which is now long defunct. Is there even a way to set it up with a modest cash balance and no associated credit card?)
If you're out and about, and every so often check your smartphone to see what WiFi networks might be in range, you'll occasionally see an unsecured access point with a name that sounds remarkably like a wireless printer.
Obviously, What The World Needs Now is a smartphone app that, when the phone isn't connected to WiFi, looks for unsecured, default-printer-named access points, figures out approximately what model of printer it's looking at, and sends a print job.
Just a couple of throwaway ideas, being as how I don't have the connections to get them into production... and, hey, maybe they exist and I just haven't seen them.
I've got a double-walled (so, somewhat insulated) plastic cup with its own swirly straw. It has a standard-sized base, to fit a standard automotive cup holder. So far, so good. But! Being regular-soda-sized on the outside, it's quite small on the inside, so filling it with ice & water in the morning doesn't keep me supplied with cold sippin' water for the day... not even to lunchtime. How about making these things in large & jumbo sizes, keeping the standard base dimensions?
Relatedly: is anyone making a car with Peltier modules in the console cupholders? Wouldn't it be nice to have the ability to keep drinks cold, or hot, or one of each? If automotive consoles were of standardized dimensions, this could be an aftermarket item, but I fear it really needs t be a factory goody.
Thing about random numbers is, they don't necessarily look random. Ask a true random-number generator for a 4-digit random number, and 0000 is just as likely as any other.
But 0000 isn't a random-looking number. 3586 is a random-looking number.
So, to generate random-looking decimal numbers... for starters, the first digit can't be zero. It just can't. Or maybe it could be zero, but with a low probability. Then, repeated digits are bad. So:
Start with 10 bins, representing digits 0 through 9. Bin 0 gets maybe a 2% probability, and 1 though 9 get 10.889% each. For each digit in the result, pull a digit out of a bin according to current probabilities, then take some of the probability from that bin and distribute it evenly among the others.
This should result in numbers that look nicely random, despite being considerably less random than really random numbers.
Has someone already done this? I dunno. I haven't done my homework. I'm just being random, or at least random-looking.
Reading a novel, which I'll probably review after I finish it.
Has a lab explosion, which doesn't quite follow the trope of "experiment blows up, inventor killed, all notes lost, subplot wrapped up neatly." But it calls the trope to mind.
And I think back to the early days of my stint in Corporateland, and my thought that there really should be a system for keeping electronic lab books. At the time, this would have involved a Java client, and all the awkwardness that entails; in the modern world of HTML5 and such, all the client-side stuff could be handled in the browser proper.
And it would enable project-level lab books with multiple engineers participating, and that kind of good stuff.
The original concept involved keeping the data in-house, on the corporate server. But... why not (along the lines of paid repository hosting) have a lab-book hosting service, at a site entirely separate from anyone's lab? With some sort of off-off-site backups, of course.
And: another note for the open-source not-LabVIEW that I keep meaning to write (or any such thing that anyone is writing): include the capability of streaming results directly to a server, whether on- or off-site. Preferably, have some way to integrate with an on-line lab-book system.
So, when the lab blows up, or burns down, or is devoured by the Great Old Ones... all the notes are stored safely on a server in a distant location, along with data up to the final moment.
As a service, this would require some policy options, such as a designated heir to the project, release to public if the owner doesn't check in for some specified interval, etc. Just so the work isn't permanently lost when an experiment in applied theology unexpectedly succeeds.