Good news – America's nuke arsenal to swap eight-inch floppy disks for solid-state drives The US Strategic Automated Command and Control System (SACCS) has reportedly replaced the ancient eight-inch floppy disks it uses to store data on the US nuclear arsenal. Defense news site C4ISRNET today cites officers from the Air Force 595th Strategic Communications Squadron – the unit that actually manages the system – in …
I think an RPi with a $5 plastic case and a 32Gb SD card would work...
You could even run SIMH to simulate the minicomputer. I think it does those old IBM minis (it does PDPs and VAXes and HPs and some IBMs). Just copy all of the software off of the old box [make backups naturally], image the hard drives [if there are any], put them on the RPi, and voila!
All for the cost of one night of binge-drinking [if you don't binge too hard, that is]
/me recently grabbed an RPi off of the shelf at the client office, where lots of RPis are being used for embedded things, and made a test web server out of it. $5 plastic case, a power supply, and some network cabling and it's a perfect little test server for web things. Port forwarding and a DNS record complete the picture.
Simpler and cheaper is a Mid Range PIC Micro with an SD Card slot. The connector wires direct to chip which can use an RS232 adaptor for its HW UART. JAL and maybe C have the libraries.
Actually emulating the floppy port isn't that hard either and possible with PIC.
I wonder why the 8" drive never replaced with a 3.5" drive? Maybe hard sectored rather than soft. SOME 8" drives do work on a floppy port for 3.5" drives just with an adaptor cable. Bit late now to put a 3.5" drive so it may indeed be a USB memory stick on new HW using a serial interface. The midrange PIC 18Fxxxx can be a USB slave emulating a USB stick (just USB A connector and a capacitor needed), not so easily a USB host, but using SD cards, PCMCIA and IDE storage directly has been done.
... if it still works, and does exactly the job it was designed to do?
As a side note, almost all of my 242,944 byte 8" IBM floppies[0] are still read/writeable, so one certainly can't fault the longevity of the technology ... only half inch tape has been more reliable over the long haul.
[0] Yes, I know, mine are consumer-grade[1], not the hush-hush "nuke" version. Nonetheless ...
[1] For values of "consumer" that equals "early '70s Fortune 150 only", for $$ reasons if nothing else ...
you also need to consider operational sustainability, i.e. is there a ready supply of replacement units, components and/or parts to keep the drives and disks operational, and the organisational knowledge and skills to make robust repairs or replacements?
At some point the costs of repair will outweigh the costs of upgrading, probably due to part scarcity, when the cupboard full of spare drives is empty. Disks wear out, and I assume 8" floppies are no longer being made.
I suspect that if I have enough replacement units (NOS drives, sealed in the original boxes, plus cabling to match, along with unused stepper motors, read/write heads, and other hardware) to last well into the next century, the USAF isn't lacking in that department.
The repair and/or replacement documents are quite robust. If you've ever dealt with military repair manuals, you'll know what I'm talking about.
Brand new 8" floppy disks are still available, if you know who to ask. I see you can still get 'em on ebay, if you don't have industry sources. The USAF can still order them direct from IBM.
Yes, at some point the costs of repair will outweigh the costs of upgrading. I totally agree! But that point is not yet here, IMO. My gut feeling is that the only reason they are "upgrading" is because some suit somewhere wants to see all the current data in situ over the Internet using their GAO approved Pentium running Win95 and IE 4.X ...
... by cleaning out eBay? I jest; they're probably not even mil-spec.
Is there even a 8" Diskette U.S. Strategic Reserve?
Also, I'm assuming with drills and readiness checks the USAF is burning through their spares cupboard at a vastly greater rate than you are. I'm sure the manuals are great, but there's probably still a finite supply of mil-spec disk controller ICs left in operable condition.
Given the risks involved and the lead times to implement and test replacements, my gut feeling is if they're doing this upgrade well before the cost equalisation point is reached, it's because in this case, it's nuclear weapons, rather than a purely commercial enterprise, like a bank.
The thing is, things only stop being manufactured when people stop buying them. With military spending patterns it's entirely possible that it's economically sound to keep a production line going just for the USAF. In that case, they never need to go out of production and therefore the kit never needs upgrading.
So what? Fixing those boards isn't exactly rocket surgery[0]. I've been doing it at home for over forty years. In a pinch, I could probably breadboard one up in a day or so ...
[0] Actually, come to think of it, it is ... I guess rocket surgery isn't all that difficult after all :-)
No need to keep manufacturing this particular kit. IBM has warehouses full of spares (I've seen them), with aging US military systems being pretty much the only customers these days. IBM's inventory should last many more decades, at a guess at least tripling the current lifespan.
The cost of carrying inventory of obsolete parts is huge which just raises the price of those parts every year. Big retailers such as Walmart are masters of return per unit area of shelf space. If something isn't generating a certain amount of money per square centimeter of store shelf, it's replaced by something that is or a new product will be tested.
How much building maintenance would be going on for a warehouse full of decades old tech? Is the roof in good nick or will it cave in the next time it rains or snows. If the collapse destroys the last remaining stock of some part, there will need to be a scramble to make some more or once systems in the field need that part, they'll have to be taken off-line pending upgrades. That could be years of red tape to make happen. In the mean time, there's a silo or complex that is off-line in the case of strategic weapons. I'm ok with that, but a government won't be.
> The thing is, things only stop being manufactured when people stop buying them.
Or rather when potential customers are no longer willing to pay a price sufficient to keep the manufacturing facility profitable.
Given a declining customer count and an increasing manufacturing cost (those machines have their own legacy challenges), eventually you hit the "uneconomic" point.
"you also need to consider operational sustainability"
This is one reason why SIMH exists. Already mentioned but I'll mention it again:
a) Raspberry Pi 3B+ with simple plastic case.
b) SIMH
c) image the drives and set it all up on the RPi with a 32Gb SD card (high reliability version) running Raspbian or a compatible version of Devuan
Good for another 10-20 years.
And once you've imaged all of the storage and copied it onto an SD card in a format that's easily read by other computers, you can make backups (etc.) and make sure that the stuff gets archived properly.
I remember old 8" floppies from the 70s, using DEC equipment. At SJSU they had these hard-sectored floppies and these "slap on" peripherals that plugged into a Teleray (serial) terminal. By sending control character sequences you could move the heads around, read/write, etc.. I wrote an assembly language program that actually WORKED to store stuff on disk, gave it to the school. The grad student who wrote the previous one (in RSTS/E BASIC) was a complete DUFUS and that program failed if there was any kind of system load at all [he told the drive "send it all" nevermind buffer overruns and errors]. Mine dealt with that and used the RSTS interrupts so you could access the entire file system, as any decent system-type application should. Anyway, long time ago, but memories have re-surfaced. I've also been toying with SIMH for fun, so there ya go. Old computers can be fun toys like old cars, old radios...
One typical gummint-style cockup though - SJSU had one PDP that was a stand-alone that had 3 disk drives on it, same 8" floppies, except the format was INCOMPATIBLE with the ones connected to the serial terminals. So there was no way to put files on it from the mini system or 'state network' system. When it came to data interchange, it was pathetic. That was the 70's for ya. Networking was just being invented. One prof had ARPANET access. That was it. Had to dial in with a phone modem, too.
True, we do have a throwaway culture but I'd like to think that if there's a machine out there tracking the world's deadliest arsenal there's a ready supply of parts. The last thing I'd like to consider is your average Ops dept personal phoning their manager on a 3am callout saying the missle tracking system is offline 'cos there's no replacement PSU in the storage cupboard!
This post has been deleted by its author
Hey, that's unfair! It wasn't four zeros, it was eight, that's almost twice as secure!
It wasn't all of the US's nuclear codes either, just the launch code for their Minuteman missiles, allegedly because SAC resented JFK's instruction that they had to take steps to make non-authorised launches more difficult.
The USAF denies that any of it's launch codes were ever 00000000, but they're not necessarily being entirely truthful...
Trust the USAF's side of the story, or trust the word of a single crank who makes a better than good living singing to the choir in the "Nukes Bad!" drama? Decisions, decisions ... We know the military practices presumed security, but single cranks don't exactly have a good track record in the truth department.
Gut feeling? They are both lying. The code probably wasn't 00000000, but it probably was something fairly easy to remember. But really, who cares at this point, nearly half a century later? Except a guy selling books, that is. And his credulous fans, of course.
This post has been deleted by its author
What I love is that in the USA they have safeguards upon safeguards now. This follows the two man rule concept. So two of the four missile command bunkers have to agree a valid launch code has been received. There are two USAF personnel in each so that's four people who have to agree to launch the ICBMS under their control. One person cannot turn both launch keys simultaneously in a bunker (due to distance) and would need the key of the other officer before doing so. The keys are in a safe which requires both officers to access etc.
Before an SLBM launch can occur both the captain and executive officer must agree they have a valid EAM ordering the release of weapons. They also have their keys in in safes (one each) which are required to launch. Supposedly in some cases the EAM contains part or all of the combination for the safes.
That's before we discuss Permissive Action Links etc. If you want to hear a USAF EAM listen to the HFGCS on Shortwave for a while and you'll be in with a chance. Or even rarer the Skyking messages that override EAMs. EAMs explained
In the UK if the Captain and Executive Officer just decide to launch the missiles they can. We do have a world renowned Submarine Command Course AKA the Perisher though. The US have started sending officers on this course such is the quality of it.
"The last thing I'd like to consider is your average Ops dept personal phoning their manager on a 3am callout saying the missle tracking system is offline 'cos there's no replacement PSU in the storage cupboard!"
I'd be quite surprised if they allowed their spares count to get that low before replacing/building more spares or putting in a new system. You simply don't allow a critical system to run out of spares before you have a new system in place.
You don't do any government contract work, do you?
Funding, RFQ's, supplier qualification, budget earmarks/allocations, yadda yadda tie up stuff all of the time. This is mainly due to some sound bite rich topic of the day keeping politicians from paying attention to their real work. Think the witch hunt of President Trump and the battle of Brexit. Those two things are sidetracking everything else that must get done. Like approved budgets so there is money to purchase or move spares. I've worked on projects where there was no money to move physical items from one location to the next. There was money for payroll to do the work. We could even order parts. Just no money for freight. These things were too big to stick in the post.
"there's better technology"
Better than something that has worked perfectly for forty years?
"that is cheaper"
Undoubtedly. But is cheaper always ever better?
"and will last longer."
Assumes facts not in evidence. In fact, I suspect quite the opposite is true.
New requirements are that it must have virus protection and recent contracts state that can only be supplied by Microsoft. Therefore, they have to get a Microsoft Windows box and because of that it also needs to be on the Internet for updates for both the OS and the virus protection. What could possibly go wrong?
I worked for a council whose councillors didn't trust magnetic storage and insisted on paper print-outs of everything that was stored in the council basement. All the print on the paper had faded to unreadable. It was basically a bonfire in waiting.
My mum worked at the government computer centre that printed giros for folk on benefits. The programmers printed me a picture of Snoopy in xxxx's when I was six. That was the coolest thing ever when you were six in the early 1970s.
I grew up in an era where we had constant nightmares because we were '7 minutes to midnight'. We are now 2 minutes to midnight and nobody seems to care.
In the ‘70s India and Pakistan didn’t have nuke. NK didn’t have nukes. I don’t think Israel had nukes or they were brand new. The Soviet Union was intact and in control of its borders and installations. Uncle Sam’s command and control worked better as well.
When it’s just the two nuclear behemoths and maybe the Chinese detente can work and be shown to be working. Remember Uncle Sam and Uncle Joe docked spacecraft (inter-operable docks) and exchanged flags in orbit. Things could thaw. Control was in evidence.
Now things are much more potentially fluid and hair trigger. Israel keeps saying it will ‘not allow’ Iran to get nukes. Iran builds bunkers inside mountains in response. I wouldn’t trust the Israelis not to go there. Especially with Bibi in charge beholden to the ultras. Clinton might just have invaded NK or ramped things up really high if she had beaten Trump.
2 minutes to midnight seems right to me.
You don't seem to be so afraid of the NK and Chinese nukes as you are of other countries. The leaders of NK have got to top the list of crazies who might pull the trigger. If Iran got them, I suspect they'd use a cats paw to denoate it somewhere rather than being seen to lauch a rocket with a nuke on it and risk WW3.
Incorrect, bob. 64-bit Linux uses 64-bit time_t ... I predict that twenty years from now, all "modern" systems will have been using it for at least 5 years, probably 10 or more (assuming the argumentative set shut up and get to work on the problem. Big assumption, I know ...).
The biggest problem is embedded systems. I don't know about all y'all, but I tend to use kit until it wears out. That's part of the reason I restore and drive old cars, their computers aren't susceptible to this problem. Most cars being purchased today will have a conniption fit on 19 January 2038.
I've never heard of Y3K in this context.
"Incorrect, bob. 64-bit Linux uses 64-bit time_t ... I predict that twenty years from now, all "modern" systems will have been using it for at least 5 years, probably 10 or more "
Yes, but I was shocked to read, just within the last year or 2, someone went over the Linux kernel time handling code, only to find that the system would lock solid when the real time clock rolled over. Quite a few RTCs roll over in 2038, and the code that was put in around 1999 to supposedly handle this only handled a few uses of the timer while not handling others at all. So, for example, a call to get the current time would handle the rollover and work fine; but a timer put in 1/10th of a second before rollover, to fire a few 10ths later, for instance, would never fire since the clock rolled back to zero. It all used 64-bit time_ts internally but the hardware would let it down.
----
but a timer put in 1/10th of a second before rollover, to fire a few 10ths later, for instance, would never fire since the clock rolled back to zero.
----
This is opposite to my experience with early Linux. I was astonished when reading the Linux drivers docs to see that in the example you mentioned, the time would fire instantly, since a timer scheduled to fire after the rollover would be "wrapped" to be _far_ in the past and so need immediate attention. I went in to ask my boss (who had been porting Linux to a MIPS-based system) if this was the actual behavior. He assured me it was, as he had discovered because that system was 32-bit and had a 1kHz timer. The symptom is that whenever the current time (in timer intervals, aka 1/Hz, not seconds) wraps, _all_ the timers would fire. This will at the very least cause a dramatic pause, and quite possibly crash.
In one of those odd coincidences, as we were discussing this issue a Win95 box on the next bench went TITSUP. The soon-released analysis/patch indicated that it was essentially the same issue, exacerbated by having a 16-bit timer (time within day), and mitigated by having an 18Hz timer interrupt. (or some such, I don't do DOS). Possibly also mitigated by being just one hiccup among the herd. :-)
I'm sure that the entire collection of floppies could be stored on a minimum sized solid state disk but the older technology is probably a lot more resistant to radiation than a flash memory. Old, clunky technologies tend to be reliable which is why many years ago a project I was working on for BTI required all source code to be submitted on paper tape -- or rather mylar tape -- since it was the only medium that was guaranteed to stay readable for decades.
Dissing COBOL misses out the rather important place this language has in data processing. There was a time before computers were generally available when database records were stored on punched cards with data processing involving sorting cards, merging data and accumulating and tabulating information. The tabulators and sorters were electromechanical. (For an eye opener rummage around youTube for a film about Premium Bonds and ERNIE -- the original ERNIE seems to be an indirect stepchild of Bletchley Park.) All early business computers did was put this dataflow into the computer, more or less, with COBOL being used to specify each operation. I've noticed that modern programming seems fixated on presentation, making the interface look sexy, rather than workflow, but maybe that's my imagination. Anyway, just because its 'old' doesn't mean it doesn't work, its just that now we've got much faster systems and vastly more storage to work with. (So we can do a Premium Bond run in a bit less than a week.....)
They exist. Disk images stored on a USB thumb drive, read by the emulator firmware and presented to a motherboard via one of a number of legacy hardware buses. These are used to 'keep alive' some rather expensive machine tools with controllers and floppy drives when those drives become scarce. Many (hundreds) of disk images can be stored on one USB drive and selected with simple front panel buttons and readouts.
Custom firmware could be produced for the drive emulator that support encrypted disk images on the USB drive, preventing an unauthorized unit from being read. And this could be done transparently from the point of view of the Series/1 host.
What they generally do now is have a device that uses USB or SDcard to store the disk images, plugs straight into the floppy cable; it's real jankey since it's pretending to spin a motor, keep track of a "head" spinning over the "disk", and sending FM pulses down this cable at the rate a read head would be reading the data off the physical spinning floppy disk. But... apparently they work great.
Side note, you know how those 3.5" floppies are a bit higher desnity, and hold somewhat more data than a 5.25"? Apparently 3.5" drives originally were duplicating some 8" disk formats (in terms of number of tracks and sectors per track), intentionally with the idea that a 3.5" floppy drive could be a drop-in replacement for an 8". Never heard of anyone replacing an 8" with a 3.5" though.
Might need some customization; I'm pretty sure the stock "USB to floppy" presents a fixed set of tracks and sectors per track (like probably just 1.44MB and 720KB 3.5" and 1.2MB and 360K 5.25" floppies). But there's probably just a table in there that can be adjusted for whatever tracks and sectors you want.
Actually was the IBM AT 1.2 MB high density floppy that was a drop-in for 8-inches floppy.
Tricks were made go get a sort of retrocompatibility with 360K drives, even having a variable speed motor, but normally a 360 K floppy written on an AT was difficult to read on an XT.
Some manufacturers, namely Olivetti made a 720K 5 1/4 inch floppy that was the base for the 3,5 inch format. The M24 had a special version of MSDOS to handle them, but anyway the M24 wasn't a 100% IBM clone.
"possibly even an OS with the networking protocols removed."
I've done that with an RPi for customer requirement. Dev RPi system has ssh and ether/wireless, let's say, but the ones going out in the field disable both wireless and wired networking. Not too hard to do, well documented for the RPi.
Yeah I keep suggesting this don't I? An RPi Model 3B+ running SIMH with all of the old drives imaged and stored on a 32Gb "high reliability" SD card. backups to USB drive plugged in on occasion.
Seriously, I never saw a 8" floppy in those games, let alone a quest regarding them. Just like i miss a quest regarding the Selectron Tube, which you have to fix be refilling with neon gas or else megaton is gone (or won't be gone, whichever side you play)... https://en.wikipedia.org/wiki/Selectron_tube .
+++WELCOME TO NUKE TRACKER+++
+++HOSTILE LAUNCH DETECTED+++
+++WOULD YOU LIKE TO TRACK LAUNCH - Y / N+++
"Y"
+++PLEASE ENTER DISC 2+++
*familiar whirring clicking noises*
+++LAUNCH TARGETED ON [WASHINGTON]+++
+++WOULD YOU LIKE TO LAUNCH COUNTERMEASURES - Y/N+++
"Y"
+++PLEASE ENTER DISC 7+++
+++DRIVE NOT READY ERROR+++
+++OUT OF CHEESE ERROR+++
"cannot be accessed with conventional network protocols, adding extra layers of security to the program"
If that's the only thing that stops people connecting random computers to the internet, then they have much bigger problems and should have responsibility for a bunch of nukes removed from them immediately.
"Can't be connected to the Internet, period."
Unless someone manages to switch one of those solid state drives with one containing its own processor and wireless communications. It may present itself to the IBM Series/1 as an 80K floppy. Meanwhile, it is sending copies of data files off site.
There is a USB cable coming on the (dark) market with these capabilities.
We were talking about the old technology, Paul.
And good luck unscrewing panels to swap your cable in the new version (whatever it actually is). Methinks you'll be looking at the dangerous end of a gun if you even try without a security clearance, a secured buddy hanging on to the other handle of the screwdriver, and another pair of secured folks to make sure the paperwork is being properly followed.
I've been looking at some old RT11 code for SIMH PDP-11, trying to fix Y2K on the version I've gotten ahold of [which won't accept dates after 1999, though RT-11 has a way of supporting it, this software won't accept it]. In any case, going over old DEC code written by old-school coders from the 70's, I frequently run into mind-boggling methods that can only be called "clever" because I'm _SURE_ that when it was written, it saved one or two machine words of storage, and beers were chugged in celebration.
(but going over it 40 years later to see what it does, so I can fix it, without ANY comments in the source code that I have, is MIND BOGGLING)
So yeah, "modern IT managers" and their "modern script kiddie contractors" just couldn't do it. They'll need OLD FARTS like me.
"I frequently run into mind-boggling methods that can only be called "clever" because I'm _SURE_ that when it was written, it saved one or two machine words of storage, and beers were chugged in celebration."
Oh yes, absolutely. When RAM was scarce and at a premium, and system speed was relatively slow, saving a clock cycle here and a byte/word there was vital, no matter the cost to the elegance of the program or the hit the documentation might take.
My first hands-on experience where I knew the specs was with a Commodore PET 8KB, original "chiclet" keyboard. I have no idea what the ASR33 teletype was connected to at the other end of the acoustic modem that we first got our hands on at school. Either way, fitting a useful program and it's data in was sometimes challenging. That PET was where I first realised machine code was way more fun than BASIC and allowed for far more "tricks" to optimise for speed and space used.
We're pretty sure that just means a 4GB thumb drive, but it could be anything: use your imagination.
I'm imagining a DNA-based storage system, where new staff are injected with the appropriate virus to update ones DNA to encode the requisite information into the DNA. Then to upload into the system, insert male plug into female socket and, err, unload.
(Don't complain, you gave leave to use my imagination!)
Incorrect, bob. (D)ARPANET was originally designed by, intended for, and used by grad students (and the odd professor (some were decidedly odd!)) researching networking. The MILnet came along later. Yes, (D)ARPA money funded it, but there was absolutely zero (D)ARPA oversight in the early days.
What exactly is on these disks, that fits nicely in (multiples of) 80k? Data or executables?
My guess would be targetting data as that only needs to be coordinate strings, and you could fit a lot of those in 80k.
If that's the case, then of course the young suits would want to be able to update them across t'internet, to keep up with the Glorious Leader's momentary changes in foreign policy. By the time you've dug the 8" floppies out, worked out which one needed updating, edited the contents, re-saved it, scribbled on the sticky label and put it back in the safe, the list of Great Enemies would have changed again.
Icon, obvs...
"What exactly is on these disks, that fits nicely in (multiples of) 80k? Data or executables?"
Data. In plain ASCII (or EBCDIC or whatever encoding the system uses), 4KB is about an A4 page of data, so an 80KB disk can hold about 20 pages of text. Using simple compression (not much RAM or CPU power in this system), that could be doubled.
I always wondered what was to be gained by launching in response to an incoming attack.
Sure, the *threat* (and capability) to do so is a deterrent, but once the button has been pushed, is there really anything to be gained?
A warning for "next time" seems like a rather weak argument, for reasons which should be obvious.
// what other icon?
The theory is that if you have the capability to launch a response, the initial attack would never occur in the first place. That is all.
Note that neither side launched. What seems to be missing in all the hand-wringing is that it actually worked as a form of détente. We are still here, aren't we?
We are still here, aren't we?
Maybe not really. Maybe we are in that astronomically extremely unlikely wheeler-multiverse corner where humanity didn't nuke itself? That would explain why everything is getting weirder and weirder - every time humanity nukes itself everything become a lot more unlikely!
Assuming you are still alive anyway.
Personally, I would much prefer to have my enemy still alive and around to take over and rebuild my home then knowing that there is no one left to help. I'd rather have bread lines and rationing than living in a nuclear hell scape. IF anything, the enemy just lost a bunch of power now that they no longer have an enemy of their own to protect their people from (Its been my experience that governments retain power by scaring the people into believing that they are the only thing holding the enemy at bay)
Besides, the enemy has a beef against my government, not me. Once my government is gone, there is no reason for the enemy to continue fighting.
Can't run roughshod over that which doesn't exist. Nuclear strike isn't about claiming territory or other spoils of war. It's about removing the "enemy" (and the horse he rode in on, the saddle he sat on, etc.) from the picture.
That's why the neutron bomb scared so many people. It was designed to get rid of the human part, and leave the "stuff" alone, to be looted at leisure later.
Well, yes and no.
Neutron Bombs were primarily developed as a defensive weapon. Essentially a nuclear weapon that could be safe (er, a very bir er!) to use over western Germany to stop a conventional assault by the soviet union in a manner that firstly, could be argued as not constituting an offensive "First use" (Since we were bombing our own territory, not the Soviet Unions) and secondly, did not reduce the territory we were defending to an apocalyptic waste land. Neutron Bombs are actually quite small in nuclear terms at their optimum yield point. Anything much over 7 Kt or so and the advantage of the enhanced radiation bit is lost to general heat flash and blast.
I have always felt that this is NK's game, which is why all their test yields to date, even the claimed thermonuclear ones, are right in the ball part for a neutron Bomb. NK does not have any territorial interests beyond SK, their only other military position is that of defence. Neutron Bombs tick the box for both objectives. From an offensive position NK is not going to nuke LA or Tokyo.
They might however launch half a ton of builders sand into LEO/Whatever. That would be my main concern regarding their "Offensive" long range/orbital rocket capability.
Will this run on Hercules-390 on a Raspberry Pi ? Would probably be faster and easier route to hardware replacement.
But IBM would have a legal fit, then try to persuade USG to upgrade to a z15 that uses 0.01 of a single core for the app.
Of course hardware replacement wouldn't have all the latest must-have buzz-words, like micro-service etc
I'm with the folks that say they should keep those old systems. The repairability of those old systems is almost infinitely greater than the repairability of modern stuff.
The reliability is typically much greater as well. I'm no expert, but I believe that the failure rate of integrated circuits increases with the density of the circuitry. Things like stray cosmic rays do little to an ancient chip with huge transistors, but can subtly impair the functioning of a modern high-density chip. Sure, the new ones typically have error correction, but the very fact that they need that says something. Also, the error correction is all a probability thing - you can't repair *all* errors.
Do those old chips not have modern equivalents? I recall a multitude of audio etc circuits from the 70's based round the LM741 chip. These are currently available from RS @ around 5 for £3, Unless they were bizarre bespoke ones, I would have thought many/most even, popular basic chips from the 70's would still be available.
We're pretty sure that just means a 4GB thumb drive, but it could be anything: use your imagination.
Too new. I'm thinking more PCMCIA based flash storage, MAYBE compact flash. The military already has experience with this on airplane dataloaders. And it's a proven technology, been around since the early 90's. You can use up to the full FAT16 file space on a PCMCIA card, or the full FAT32 on a compact flash!
I recently recently replaced a 486SX board in a CNC milling machine with a 486DX one.
It was still booting from a 3.5" floppy (connected via an ISA I/O card) because previous attempts to get it to boot from a 2GB CF card connected via an IDE to CF adapter had failed.
Then I realised it was because DOS v7 FDISK could only see 504MB of the 2GB CF card even though I could put in hard drive User Type 47 parameters in the BIOS to define a 2GB drive.
Once a put in numbers to keep it below 504MB, it started booting fine. The whole OS easily fits on a 1.44MB 3.5" floppy and user programs tend to be less than a few KB, so the loss of usable capacity isn't a problem.
My point is, a 4GB drive/card may be "too big" for older systems to handle without careful consideration / testing of any workarounds employed to get it working.
Plus Flash memory loses data from charge leaks over time if not powered up. Not a problem for magnetic media, though magnetic media does have its own longevity issues.
Back in the '80s I was working for DEC UK special systems. We were approached by MOD to replace the TU58 tape boot devices, used in their on ship VAX systems. I had a prototype 3.5 inch floppy drive sent over from the US and then build a z80 based interface that emulated a tu58, to drive the 3.5 inch floppy.
We fitted this to a prototype system and demonstrated it to MOD. They considered it for a few months but came back to us to say that they didn't consider the 3.5 inch floppy mainstream, and felt it wouldn't catch on.
So hence somewhere in my loft is one of the original prototype 3.5 inch floppy drives plus z80 controller.
Out o'curiosity, why didn't you just sell 'em the RQDX controller and RX50 drives?[0] DEC was already shipping those in the early '80s, at least to (some) .mil contracts ... In addition to the floppies, they would also support MFM hard drives. QBUS, UNIBUS and OMNIBUS were all supported. I had (Beta) installations at SLAC, LLNL, Sandia, Ames and JPL in late '81/early '82ish ... Today, I have a PDP11 running RT11 booting off a ginormous 152 Meg Maxtor XT-2190 (DEC "RD54").
Note to anyone picking up this thread in the future: The easiest way I know to format a MFM drive for use with the RQDX series is to use the ROM formatter built into the VS2000. See http://vaxarchive.org/hardware/vs2000/ for more. Good luck finding a VS2000 ...
[0] Note that I did not then, and still do not, think that DEC's decision to use a non-industry standard floppy format was a good idea. Looking back, that was probably the beginning of the end.
Modern tech has rare earth magnets everywhere. They're in purses, laptop lids, wallets, headphones, and an endless number of gadgets and toys. Old floppies were sensitive to old ceramic magnets and they don't stand a chance near a modern rare earth magnet. They also hate dust, bio-anything, solvents, smoke, low humidity (ESD), high humidity (sticking), too little lubricant, too much lubricant, bending, heat, UV, pressure, and sitting for too long in one place. Floppy drivers can compensate for a spot of fading media but I've never seen one report that it's doing it or try to refresh the media (I modified the Apple ][ RWTS to do this). SSD replacements might be difficult but imagine all of the complicated protection measures that become unnecessary for a critical component.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
