A Commodore 64 Is Still Being Used to Run an Auto Shop in Poland | Hacker News Reader

A Commodore 64 Is Still Being Used to Run an Auto Shop in Poland

sploid.gizmodo.com

237 pointsInsanity198 comments

The day that the C64 will break, they have to migrate to a “modern” solution that requires 10 Ghz CPUs with 1024 cores, 20 TB of RAM, that will be running on NodeJS that will have have a MongoDB database for transaction and that will communicate with a VBA script running on the same host in a virtual machine with Windows 2016 through Redis running in a container thanks to Kubernetes.

And they'll be lucky to get uptime upwards of 80%. And only lose 1% of their customers' data.

Seriously, old software wasn't necessarily better (I well remember the old Mac system bomb dialogues!), but it certainly was leaner and forced not to be so complex.

Modern """""""enterprise""""""" solutions in a nutshell.

Just throw in a shitty call-home activation DRM scheme and an authorisation server with 50% uptime too.

Modern """""""enterprise""""""" solutions in a nutshell.

lul. My Java project with a bunch of maven dependencies and a slightly unwieldy number of superfluous classes doesn't have anything on modern startup's tech fetishism to over-complicate operating a website "at scale" these days.

Funny days, when modern web development turns out to be more bloated than Enterprise Java solutions.

Its depressing.

When the hell did it become normal to suck down 3mb of javascript and poke an API just to display some otherwise static text on a webpage.

When Ads became a thing. Most of that 3mb is 3rd party ad scripts and analytics trackers.

Basically - when it became obvious that people wouldn't pay for content and companies had to monitize the users.

It's lame, but.. well... suggestions?

Make content that is worth paying for

Give me a way to pay for arbitrary content in a browser that works everywhere.

Even when publishers do people don't want to pay for it. This has happened time and time again.

Also because paying for content is ugly, hard, and not easy online. Subscriptions are clunky and micropayments have never taken off.

Trust me, It is much more worse when you combine enterprise java with modern web.

I was always under the impression that java would kinda self-implode when it was put together with the modern web.

Even if that were the case, how would you even notice? The modern web is an ongoing implosion.

And that will come with an expensive yearly renewable cloud subscription ...

Divided on ten plus micro services that all need their own keep alive scripts.

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

This is where the "computer" should be replaced by the "appliance". Simple raspberry machines in rugged enclosures running ONE piece of simple software off flash cards. If it breaks it's a matter of either just inserting the backup flash card (because the old one died) or worse case replacing the raspberry inside the box. Either way it's dirt cheap.

The shop can easily be given 3 raspberries and a dozen flashcards when the system is first installed, for almost no money. Even if the software vendor is out of business when it breaks in 10 years, they are good to go in no time at all. Any auto mechanic can swap the raspberry inside the case in 10 minutes and be up and running again.

Don't you run into limitations of raspberry's real time capabilities with a task like this? A REAL, microcontroller based, appliance, which is connected through a serial port to any PC, would be more suitable.

Yeah it depends on the task in question but I was thinking in general- Appliances should look and work as such.

The most important thing though is getting rid of the PC where it isn't necessary and making the whole thing an appliance. Otherwise the PC will be the weakest link in the system. It can be replaced but it's expensive and cumbersome (updates, security, etc) if all you want is the appliance for balancing axles.

I doubt there are any difficult hardware requirements for a task like this, if it's like balancing wheels it's no harder than (slow) analog sampling. I have done it with a cheap analog io card on a 386 with DOS for regular auto shop balancing.

Year ago there were still many POS (point-of-sale) computers at retail stores running with "Subiekt 4" in my town in Poland. I even saw one in supermarket.

DOS program from 1995. http://www.netsetup.pl/s4/img/Image2.gif Connected to old EPSON parallel-port dot matrix printer (those printers were still surprisingly expensive).

I remember editing "Subiekt 4" to change VAT tax from 22% to 23%. 22% tax was hardcoded. Over years there were many more tricks to keep it running, for example "Hyperthreading disabler" program.

Year ago they were still running it in Dosbox but now it's migrated to "Subiekt GT".

I prefer old DOS program because it was easier to copy, just xcopy program folder to pendrive. New version uses MSSQL, and you have to reinstall and activate online. And database sometimes breaks.

> I prefer old DOS program because it was easier to copy, just xcopy program folder to pendrive. New version uses MSSQL, and you have to reinstall and activate online. And database sometimes breaks.

That's why I absolutely love SQLite. You get all the benefits of relational databases while still keeping data in plain files and not having to install system-wide stuff.

When it doesn't matter, like probably with the inventory of a small grocery, SQLite can be a beauty

SQLite is more tested (as in code tests) than most other databases. Its downside is that you can essentially only use it from one app at a time, and not over a network.

Also, it is safer than writing to your own files. It has tests for probably all the ways that writing to files can break. So if local state needs to be maintained/changed and written to disk it is great. https://www.sqlite.org/testing.html

Subiekt 4 is based on FoxPro database, it can be used over network simply by mounting SMB network share.

Just click "Share this folder" in Windows and run the same executable on another computer.

Indeed, I was responding to GP's assertion that SQLite is only for data you don't care about.

Copy-pasting one of the replies from the page:

Reminds me of something my mom did a few weeks ago. She got a scam call from some guy saying he was with Microsoft and he detected a virus on her computer. (First clue it was a scam? They have an iMac. Why would Microsoft be calling?)

My mom started playing dumb and saying, “You mean my Commodore has a virus?”

“What?”

“Yes! I have a Commodore 64!”

“Uh..Do you have Windows?”

“Well, of course! I can look through them and see the birds outside! My cats LOVE my windows...But I don’t let them up by my computer after someone told me that computers have mice.”

“Uhm...Ma’am...Is there someone else there?”

“Nope! Just me, my 12 cats, and my 4 dogs!”

The guy hung up on her at that point. :)

Good on your mom. I am always curious about these scam call centers. How do they staff up? Do they place an ad in the paper? Are the people who make these calls normal folks like you or I who wake up in the morning, commute to the office, sit in a cubicle and make these calls?

Normal folks wouldn't do jobs involving trickery.

"Normal" is culturally-defined.

Wait, what about fraudulent "financial advisors" that will happily trash you for some extra profit? Wells Fargo? Just the semi-recent stuff...

Ugh, what did Wells Fargo do?... Oh, fantastic, now I have to go see if I have any accounts I didn't open. I wonder if I'll ever see the day where I'm sold off to some random company and find out they're actually running an honest business with quality products.

The accounts were all closed within two weeks. That was enough to get employee bonuses though.

You realize you're writing that in a forum where half the companies are financed by advertising...?

Is scamming advertising?

No, you've got your Venn circles reversed. Advertising is a subset of scamming, not the other way around. There's plenty of scams that don't involve advertising; just look at Wells Fargo.

Imagine their mindset. They may have the attitude that their work is fun.

Do they actually have call centers? I always assumed it was just one or two people trying to sound like they were in a call center.

I always imagined it's kind of a secret evil promotion. If someone is really pushy in their standard advertisement out-calls, someone else comes to them "psst, you wanna know where the real money is?..."

It doesn't seem all that hard to imagine. I'd guess the people applying might not know at first that the call center job they're applying for will be for a scam, and then when they find out, they have to decide how badly they need a paycheck.

I once read an article describing a full-blown callcenter for scam calls operating out of Brazil. I guess that with the right connections, it's not that hard to hire a couple of people willing and able to do that kind of thing.

Forward all scam calls to Lenny: https://www.youtube.com/user/ToaoDotNet/videos

Thank you, Thank you! I'd never heard of this before.

That's freaking awesome!

The latest one goes on for more than an hour, and he actually has the telemarketer reminiscing facts he told him about his third eldest daughter Laurissa, right before a duck attacks! The poor guy's starting to sound very tired, but that's only 7 and a half minutes into the hour-long phone call! [1]

[1] https://youtu.be/D-RAlSGWQlI?t=7m32s

This demonstrates how small most computing requirements are. Bigger faster systems to do what? Store an address book? Calculate taxes? Print invoices? Most of our computing needs could be performed by a small embedded computer no greater than a raspberry pi.

Even Raspberry Pi is an overkill. Look at with what we did tasks in 90's and we had it all good. Now look at RPi3 specs for example.

I see people complain about the low power of the Pi3...then I think about how I went through college with a slower computer than that, and how the people over the previous 30 years had even slower machines to use (if they had their own personal machine at all).

What you can do with a couple MHz and a few hundred KB of memory is great, given a little ingenuity. Of course, you aren't going to do real-time face recognition on something like that, but 99% of what we need to do is just fine with 0.1% of the performance.

Or the Arduino versus what we had with our 8-bit computers.

At the very least, the Raspberry Pi has a much lower power footprint, so even it's overkill, it's still probably better than a C64, at least in this one particular case.

That said, I think the C64 thing is pretty neat, so I can't really knock it.

I came to realize that Raspberry Pi would be a "supercomputer" to run Xerox PARC, ETHZ and DEC research OSes.

So if we are still playing catch up with those environments, is just because the industry at large lacks the political agenda to push forward such technologies, and nothing to do with technical capabilities.

I wonder what would happen if we could build a time machine and send a bunch of RPis back in time to Silicon Valley in the 1970s, along with all the specs for how to build more of them (though this would be a lot of information since it requires fairly modern semiconductor manufacturing processes).

I wouldn't be surprised if a micro-controller, if it had enough RAM, would be good enough for a ton of tasks we use desktop computers for.

> I wouldn't be surprised if a micro-controller, if it had enough RAM, would be good enough for a ton of tasks we use desktop computers for.

I remember - way, way back - using a graphics editor app on a computer with the following specs: 3.5 MHz, 8 bit, 48 kB RAM. It was not more complex than Microsoft Paint, but it worked.

So, yeah, microcontrollers nowadays were considered computers at some point in the past.

Not really.

The CPU part of a microcontroller, sure. But a microcontroller is more than just a computer: it's specifically designed for controlling things, and as such ahs a lot of extra parts added on which you would not normally find on a general-purpose computer or CPU/microprocessor. Things like comparators, timers, GPIO (general-purpose input/output) pins, A/D and D/A converters are common on uCs, and these days they frequently have industrial data buses added in too, like CAN (usually used in cars). These of course could all be added to a general-purpose computer, but in a uC, they're all built right onto the chip, and are accessible right at the register level instead of having to communicate over a general-purpose bus to some external module.

But if you meant to say that a modern microcontroller is as powerful as a full-fledged "computer" from the 80s, that's definitely true, and really a big understatement as many modern microcontrollers have rather powerful ARM or PowerPC CPU cores and are far more powerful than your typical 1980s microcomputer. uCs these days span an incredible range, from tiny PICs with a few hundred words of flash and a few dozen words of RAM, running at 1MHz, up to very powerful 64-bit SoCs (systems-on-chip) running at well over 1GHz.

I hear some people still use these things:

https://en.wikipedia.org/wiki/HP_95LX

I played around with one recently and it's a pretty cool little device.

The modern version of this is something with a big dumb GUI that is trivial to train on. A CLI or text only approach is going to take longer to learn and be comfortable with. I get TCP/IP with modern stuff which allows me monitoring, remote access, remote upgrades, etc. We also get standardization. Windows/Linux and USB aren't going anywhere anytime soon and even if they do we can emulate x86 systems in a hypervisor. If your ancient non-x86 system dies you either get lucky on ebay or you don't.

I also can't casually send the customer a text telling them their car is ready or have my supervisor look at my metrics on what I'm doing with the machine. Or a million other things on these old systems. Or you can, sorta, by shoehorning in garbage like analog modems and swapping out floppies all the time, but who wants to do that?

I think young people tend to fetishize old tech because they weren't there when it was used. Floppy failures were common, IRQ issues, programs taking down the entire OS, no real security, and "the computer" was something the specialist at your shop took days of training to learn how to use and when he wasn't there "the computer" was useless. Now its been vastly democratized and has higher levels of ease of use. That comes at the cost of complexity.

>A CLI or text only approach is going to take longer to learn and be comfortable with

I disagree. I once worked on a telephone switchboard, using a old text based interface and a specially designed keyboard with dedicated buttons for all the functions. It took a few minutes to learn what the buttons did. Everything was fast and responsive, and there were no distractions on screen.

I later worked there again after they had "upgraded" to a modern Windows based system. This was far more difficult and slower to use and it did nothing the old system couldn't. Training somebody to push a dedicated button is easier than training somebody to use a GUI. Look at the interfaces people use at fast food restaurants. There's a huge array of dedicated buttons, and it takes very little skill to operate. The only advantage of GUIs over dedicated hardware UIs is lower cost.

Well, the real advantage is the button can change or you can add more buttons trivially. Compare the on-screen dialer and keyboard of the iPhone to the old school 9-digit keypad. The former is superior for most use cases.

Also you can abstract away your GUI interface with a hardware button if preferred. I'm using a hardware keyboard to type this for example, even though this computer has a touch screen. I have this flexibility and customization options that the old school approach didn't really have.

Do haptic feedback mean nothing these days?

I can't type shit on any OSK without looking at the keys, or being supported by some spellchecker. But i can type this without looking down because i know when i hit a key etc.

Let me put it like this:

  productivity
      ^
      |                          old, complicated     /-
      |                               tools       /---
      |                                       /---
      |                                    /--
      |                                /---
      |                            /---
      |                        /---
      |                     /--
      |                 /---
      |             /---        /-------------------------
      +----------/--------------           modern, pretty
      |      /---                              "tools"
      |  /---
      |--
      ---------------------------------------------------->
                                              experience

The modern trend of dumbing down interfaces (which is primarily happening in the markets where you sell apps by how pretty they are, not how useful) indeed makes it easier to learn them - at the cost of making the application less functional, and less useful overall.

> and "the computer" was something the specialist at your shop took days of training to learn how to use and when he wasn't there "the computer" was useless

You say as if this was a bug. It's a feature. This is the fact for any kind of complex, powerful tool - whether it's a combine harvester or furnace or industrial laser cutter - takes traning to use to its full power. Making software easy to use fully from the get-go only means making it not do much.

> Making software easy to use fully from the get-go only means making it not do much.

False dichotomy. It is absolutely possible to write modern mass-market software and also offer complex functionality that wouldn't be needed by the average user. It is good practice from a UX perspective to avoid surfacing advanced features unless the user is actively looking for them (in your example, that's the experienced user).

I like the graph, though.

> Making software easy to use fully from the get-go only means making it not do much.

Back before people started spreading wrong ideas like this, we had things like HyperCard, which were both easy-to-learn and extremely powerful.

Now we don't, because people like you seem to think the entire concept is impossible. It's not. It never was.

>I think young people tend to fetishize old tech because they weren't there when it was used. Floppy failures were common, IRQ issues, programs taking down the entire OS, no real security, and "the computer" was something the specialist at your shop took days of training to learn how to use and when he wasn't there "the computer" was useless.

You sound young to me. Back in the 80s, computers were quite reliable, they just couldn't do that much. Floppies were extremely reliable; they had to be because the computers back then ran entirely on floppies. Only really expensive computers had hard drives until the very late 80s. It wasn't until the mid/late 90s that floppy drives became unreliable, because everyone stopped using them for anything except Windows drivers and the manufacturing of them (both drives and disks) went to low-cost areas and the quality went down the tubes. IRQ issues were a problem with DOS and Windows machines with ISA cards; before that on things like C=64s, there was no such thing. Security wasn't a problem back then, because no one was connected to a network; the best they had was telephone modems to connect to Compu$erve or BBSes. Viruses started becoming a real problem when everyone moved to DOS and downloaded stuff from BBSes. Back in the Apple ][ and C=64 days, security was unnecessary. Even over on the Internet-connected UNIX side (something mainly only used by college people, not by people with C=64s), security didn't become a big issue until Morris's worm in 1988.

As for CLI taking longer to learn, perhaps, but I remember office secretaries using DOS just fine, unlike these days where everyone has no clue what to do with a command line and is terrified of it. They might not have done really advanced stuff, but learning a few DOS commands like COPY and MOVE and DEL really isn't that hard for someone with half a brain.

As for "standardization", I don't know where you get that idea. Tons of people are having all kinds of problems with their Windows software not working on Windows 10, older peripherals not working on Win10, etc. How long did it finally take us to have some standardization on the web, after dealing with IE6 for so long? We didn't have these problems back in the text-only days. And again, over on the UNIX side, they had much better attempts at standardization with the X protocol, which allowed remote GUI access between completely different UNIX OSes, in the 80s. It took ages for anything similar to arrive on Windows machines.

6 hours ago there was a [post to the original story] (https://news.ycombinator.com/item?id=12603909). That HN article was LATER marked dupe by THIS gizmodo repost.

This is essentially the opposite of what I'd expect to happen.

And that original story is better, with more details.

Older usually means simple and simple is usually more reliable than complex. Think about it for a moment — these guys don't have a problem with auto-updates, viruses, or network intrusions.

As I write this, I'm looking with growing trepidation at the menus on my new TV, especially the "Anti-Virus" section. Seriously?

> Older usually means simple and simple is usually more reliable than complex.

Well said.

> As I write this, I'm looking with growing trepidation at the menus on my new TV, especially the "Anti-Virus" section. Seriously?

I remember various cheap movies in which a comptuer virus could in some way jump over to a human host. We're - slowly but surely - doing this to physical world now. I can't wait for the smart chair, that is connected to the cloud to give me fitness stats (in reality it's connected so that the company can try and monetize your sitting patterns[0]), and that will end up being used to pwn your local network and clear your bank account.

Fun times.

[0] - also literally bringing your butt to the cloud, without the need for cloud-to-butt browser extension.

> I'm looking with growing trepidation at the menus on my new TV, especially the "Anti-Virus" section.

Some of those "smart" TVs even have a camera and microphone. Your TV could be spying on you. Isn't that nice?

That's pretty much straight out of Orwell's 1984.

1984's technology has pretty much become a joke at this point.

Who cares about your TV watching you when you broadcast your every move all day long, your spending habits are tracked and analyzed, and a passive global actor could turn your phone mic on just about any time?

https://www.cnet.com/news/samsung-changes-smarttv-privacy-po...

Well, you bought it.

My TV is a dead-simple Panasonic with absolutely no brains or smarts at all-- any smart things it does are provided by the Xbox One or Roku attached to it-- I saved money and ended up with a product that doesn't require the use of anti-virus software.

McLaren needs a 20-year-old Compaq laptop to maintain its F1 supercar

http://www.theverge.com/2016/5/3/11576032/mclaren-f1-compaq-...

McLaren decided to standardize on a conditional access card for security, which made sense back then, but it used a pcmcia interface. None of these are dealbreakers but it runs DOS which doesn't have modern drivers for USB adapters or new laptops.

I imagine they could fix this in a variety of ways, but probably don't care and the number of old HP laptops compatible with this system vastly dwarf the number of F1's made, so there will never be a worry about not having one. Nor is this laptop customer facing, so its low priority to make it "look good." I also imagine booting up a hypervisor environment and dealing with dongles and adapters might be annoying/too technical/too buggy for the mechanics to have to deal with when they just want to work on a car and have an old but fool-proof laptop with almost no wear and tear ready to go.

Could one run DosBOX or similar and have the host system pass-through PCMCIA (connected via a USB adapter or some such)?

My experience with passing through peripherals to VMs is that often it doesn't work very well.

Earlier this year, I was doing some embedded systems work. The board could send serial data to the computer as a USB CDC device.

It wouldn't work at all in Windows, or a Linux VM in Windows, as Windows wouldn't even recognise the device.

So I suspect that it may not be as easy or as cheap to use DosBox or a VM as it is to just use old laptops.

I was shocked when I read this a while back. I'm surprised they haven't changed the interface at least once.

McLaren knows the full specification of the interface, has gobs of engineering talent, and customers that wouldn't bat an eye at tens of thousands of dollars in "upgrade costs" to maintain their cars. It seems like something that would be right in their wheelhouse.

I tune Porsches that require windows xp machines with an Rs232 port. I just buy a couple from ebay and keep stock of old parts (mostly old IBM t-series).

I would imagine that VirtualBox + USB<->RS232 adapter would do the trick. Did you tried that.

Doesn't work as well as it should for some reason. I've began to reverse engineer the software to try and port it to something newer. We could also buy newer ECUs but then we lose years of tuning.

Reminds me of a admin/support story from a university i ran into.

Apparently one day the person was called on to look at a computer over at the physics department.

When he got there, he found it to be a 486 running DOS hooked up to some particle sensor or other.

The reason it had not been replaced, beyond the cost and the year needed to ensure that the new sensor gave comparable results to the old one, was that DOS gave them direct access to the hardware, while Windows had too many layers of indirection.

I am dabbling in changing my ECU map on my turbodiesel BMW and I specifically decided on not doing a Windows VM (the tuning software requires it for upload), because I am worried of timing issues when flashing the ECU via the cable. I did not make this choice randomly; in the past I've also had issues with USB timing issues through VirtualBox on interfaces that required very precise timing and had a serial conversion to an older circuit board.

Wow, that has my story beat. A few weeks ago I was shopping at a football (soccer) gear shop and the man running it rang me up on a computer he’s had since 1994. I want to say it was a Packard Bell, but I’m not sure about that. He had to manually type in the product code of each item I bought, and then printed out a receipt on a dot-matrix printer. Then he swiped my credit card on his iPhone to complete the transaction.

Wow. They should totally rewrite everything in React.

What are you, a luddite? It's Rust for everything now.

Ah, yeah. I forgot what week this was.

Wait, did I miss the rewrite in Go?

We were too busy with the Haskell port to let you know. Sorry.

Jeez, why don't they just rewrite it in Brainfuck.

Nah, fam, it would be so much more efficient to write it in Elixir

I'm going retro and writing this in Prolog. I'm so over these modern languages.

I think I should just go back to QBASIC.

Why stop there? Why not lisp?

You can even keep the Commodore!

https://www.c64-wiki.de/index.php/PROLOG_64 https://www.c64-wiki.de/index.php/LISP

please. go is so Q1/2016

No you write it in Rust but cross-compile into Go.

I'm porting llvm to 6502 assembly language so we can do this on the target.

D best language

Don't forget about decoupling it into microservices.

Surprised nobody's mentioned the filter manufacturer in Conroe, TX that was still using an IBM 402 and punched cards as recently as three years ago.

http://www.chron.com/news/article/xx-4459714.php

https://www.youtube.com/watch?v=pxCZ35y3O04

I tried powering up some of my old 20-30 year old computers I'd stowed in the basement. Only one of them booted up, the rest had various POST failures, some even would make snapping noises and emit smoke. Older mechanical parts like drives have grease in them which dries out and the moving parts freeze together.

I suspect it is the result of bad capacitors that decay over time, but nevertheless it is disappointing.

BTW, I've found that throwing a hard disk drive in a drawer as a backup doesn't work very well. If it's never powered up for a few years it'll not power up anymore.

The only solution that has worked for me is to recopy the backups every few months at least. I've never had CD/DVD rot, but the capacity it too low to use them as backups.

I also just buy new drives every couple of years or so and copy everything forward. Some of my older drives are not even recognized by modern BIOSes.

They mention this phenomenon often on the RCR podcast http://rcrpodcast.com/ the problem tends to be the power supplies going wrong, causing surges that fry the computers. New modern power supplies for old computers is their recommendation, rather than risk using the old supply and damaging good hardware. Too late now though!

That's good to know, but as you say, too late :-(

A lot of banks still use COBOL systems from the 70ies in their backend stack[0]. It might be the same issue with this small C64 for business: "Never touch a running system"

[0]: http://www.bankingtech.com/375941/cobol-bank-it/

I love this, here is a straightforward technology getting the job done! Too many sophisticated and advanced solution are being built for no reason.

Commodore 64 software is still being developed quite actively by hobbyists, in the form of demoscene productions:

http://www.pouet.net/prodlist.php?platform%5B%5D=Commodore+6...

I recommend anyone curious about retrocomputing to watch a few demos --- it can be quite surprising to see what can be done on hardware orders of magnitude less powerful than available today.

Impressive.

Most impressive.

:-D

(sorry, watched Empire again recently and couldn't resist)

Many shops/stores in Poland still use applications written for DOS for item management and stuff. Sometimes they get an upgrade, meaning they get a Windows install with the application running in DOSBox.

Commodore 64C rather than the plain old 64 I think. Still very impressive! How on earth is that disk drive still working!?

Mechanics around here are quite resourceful and either know electronics or know somebody who knows it. I would bet the floppy drive got repaired several times.

The drive has probably been re-aligned several times by now, they were never that good. The rubber band on the drive motor probably needed replacing too.

Older disk drives are considerably easier to fix, what often fails are the mechanical parts usually springs, gears or drive bands.

And even when you do have a solid state component failure those are usually fairly easy to diagnose and repair since they are all made out of pretty big discrete components.

Not that long ago you could still easily fix a motherboard, these days it's a royal pain with everything being integrated and with 8 or even 10 layer boards the power planes are usually inaccessible to users, and signal integrity is so critical that you can't even rebuilt the vast majority of traces reliably.

10 years ago you could easily replace the power distribution system on a motherboard and even a large part of the chips, I've managed to replace the network chipset on a few motherboards when it blew out because some genius plugged a hot POE ethernet cord into it and the magic smoke came out.

Other than that replacing caps was a pretty standard procedure for reviving old motherboards, even that these days is considerably harder.

The drive for our old C64 developed a thing fairly early on where some spring or other near the back would get out of alignment and the head would stop reading. It basically just needed to be poked back into place with a fingertip, but you had to open up the casing to do it.

After repeated repair requests from frantic seven-year-olds, Dad cut a hole in the back of the drive just big enough to poke the blunt end of a pencil through so we could fix it ourselves. I learned to detect the subtle change in the drive's whirr when it was out of alignment, to distinguish that from any of the other things that could go wrong (corrupt disks, usually).

Disk drive? How is the PSU still working? Some C64 PSUs has pretty low lifespans.

Not to be too nitpicky, but it is not used to run "the auto shop".

It is essentially part of a drive shaft balancing machine. We should think of it as the embedded controller and display of the machine to understand why nobody would replace it while it is still working.

And I'm sure there are plenty of old machines around where some electronics inside are literally or very similar to general purpose computers of the era. But often the physical integration into the machine hides this.

Nevertheless impressive this thing is still running!

There's a liquor store in Washington that was still using C128s for their POS system as recently as a year or so back. They had a couple of spares stashed on the top shelf.

Go there, get a photo (or a couple) and post it here ! It would be very interesting to see what software they use.

The Commodore 128 had two processors, a 8502 and a Z80, and could run in C128, C64 or CP/M modes. The Z80 was used in CP/M mode. It would be interesting to see which mode the software runs in. I know there is still a POS system for the Commodore 64 sold and supported.

I don't think they're still there, at least run by the same people. That store got sort of flattened by the Wa State liquor reconfiguration, where Costco and the grocery stores can now sell hard alcohol.

(FWIW, it was the one in the back of Langley Village, on Whidbey Island).

A local chain whose computer rebooted showed it to be using IBM's OS for POS. Last copywrite was 1999. I found out that it was an customized version of Concurrent DOS.

https://en.wikipedia.org/wiki/Concurrent_DOS

Its history is quite amusing compared to some other OS's with better design. Last I heard was that the company's bigger stores upgraded to Fujitsu Linux (???) that runs that DOS system in an emulated or extended way. The backend is SCO Linux and mainframes. The self-checkouts, per the techs, run on Windows Embedded for GUI, the DOS thing emulated in there somehow, and a connection to backends.

It's clear they keep going out of their way with more complex designs and configurations to prevent replacing that relatively-simple DOS app. Hilarious.

I still have a Commodore 64 with its original box and booklet (which includes lessons in programming with BASIC).

Ah the memories. From memory, and obviously we are going back a long time here, there was a program in there which you could write to make it sound like a baby was crying ( it kind of did), and another where you could design a sprite ( a hot air balloon ? ) and move it around the screen.

It all seemed rather complicated to me at the time and couldn't imagine how people were writing whole games using it. Years later you realise it was even more complicated as most games were written in assembly.

The sprites...! Now there's a blast from the past - I've spent a good amount of time learning how to "draw" sprites with BASIC.

I've got mine setup at work in the meeting room

http://mos6581.com/pictures/commodore-64/desk.jpg

I keep my IBM PC setup at home

http://mos6581.com/pictures/5170-canvas/DCSF0009.jpg

Awesome - I used to have the disk drive and drawing pad ("KoalaPad")[0], but, unfortunately, those were thrown out a long time ago.

[0] https://en.wikipedia.org/wiki/KoalaPad

You've really looked after those computers — nice job :)

Oooh, leaf-spring or micro-switch Competition Pro?

I loved my leaf-spring one, it was built like a tank. When friends destroyed their Quickshot IIs in Daley Thompson's Olympic Challenge, mine just kept on trucking :)

Its leaf-spring, personally I find them a bit unresponsive compared to the micro-switch models.

Oh, sure, I probably pulled that thing apart several times over its life-span, but I loathed the clicking and lack of reliability of the micro-switch based sticks.

Is that a PC XT? Did they come with a 3.5" drive or did you replace the older ones?

Its a PC AT, which came with a 5.25" drive, but I swapped it for a smaller one for the sake of practicality.

In practise I transfer all software and data to it over FTP.

http://www.brutman.com/mTCP/

I do to. Box is in ill repair and I'm pretty sure I wouldn't want to plug the power supply into an outlet. Oh and last I recall, one of the chips had gone bad (kernal chip maybe) on it. But, I still have it! :)

My uncle still does inventory for his business (small dancewear retailer) on an Apple II. I believe he recently "upgraded" to the IIgs because he started having trouble getting parts.

In the late nineties I used to work at a Quasar centre (a type of laser tag), and the control system was a two-up DOS display built out of ASCII characters.

Even then, we joked about how old the computer was (a 386 IIRC, a long time back now). It still strikes me that while the hardware in the packs failed pretty often, I can't recall a single crash in that software the entire time I worked with it.

I suspect in retrospect it was statically linked with few to no dependencies, which probably helped a lot.

EDIT: I'm even older than I realized. Shit.

Funny thing with the quote from Commodore USA's Facebook page. These guys are irrelevant to Commodore 64's other than having bought rights to use the name... :P Weird also how their Facebook page is still active, but their website and forum is defunct with no effort made to clarify their situation with their founder deceased since 2012.

There was a similar case of an Amiga used to control GRPS heat and AC in a school: http://woodtv.com/2015/06/11/1980s-computer-controls-grps-he...

Don't change a working system.

I glued a raspberry pi to the back of an old vga monitor I use in the garage to look up stuff on the tubes while pottering. There is no reason why that setup won't still be going strong in 20 years, no moving parts, passive cooling. Very much the same for the commodore I recon.

The tubes of course will move on tech-wise while the pi will get a few years of updates before 2030's firefox is a bit to far for a 2005 arm processor. Another 10 years may pass before a significant number of sites becomes inaccessible on a 10 year old browser. And then it will still be useful as a commodore emulator.

Probably a lot of spaghetti code doing those calculations. Time for a rewrite! ;)

I wouldn't even be sure about that. I could just be a simple formula with a couple of lines of Basic. But all the prompts are using the right terminology (and language), the output is just as you need it and no one ever wrote a version that runs on something else. If it ain't broken...

Homecomputer programming was just so very accesible. I'm reminded of "Why Johnny can't code"

http://www.salon.com/2006/09/14/basic_2/

It would be nice to hear more details because there's some discussion around how to replace this technology. An alternative perspective is to ask how much longer will this technology need to run? At what point will the equipment used to balance the drive shafts no longer be necessary because the older vehicles are no longer road worthy? Sure, I'm assuming this setup is for older vehicles, and that's why I'd like to hear more info, but the point is to not simply think about replacing an existing technology when it's better to let it run it's course.

Balancing driveshafts is a very current procedure. The vast majority of cars still use driveshafts today. And it's difficult not to use a computer to balance them.

In this case, they just use a C64. If it ain't broke, don't fix it, right?

When it does eventually stop working (give it another decade or so), they can probably just buy another C64.

And then after that one dies, probably, cars will no longer require driveshafts. But who's to say; the prevalence of oil has survived much longer than many expected.

I wonder if there's a local computer shop that supports their computing needs, like repairing the C64.

The waste and exaggeration in computers is astounding. We're driving SUVs when we could be biking.

It seems like there might be some sort of a market for a very simple computer that had every piece of the puzzle well documented and straightforward. Maybe even have just about everything visualized so you can see what is going on with your IO ports, interrupts, etc.

Unfortunately it seems computers just got more complex and less transparent, but with modern technology I would think you could take a step back and make things much more transparent.

ironically, it seems whatever function this C64 does isn't well-documented so it can't be easily ported to another platform. :)

I guess it's a question of "do you want to port the code or the platform" :)

I seem to recall reading that the original IBM PC was still in use at United States National Weather Service outposts. Why fix it if it isn't broken?

Because if it breaks, there are no spare parts, the people that maintained the system are long gone and the software that it ran probably does not run on a modern computer/OS.

There are some old servers at my work.

The oldest box I've personally seen runs Windows 3.1 it is a specialized measurement instrument (Microwave radar) with a hardware card that runs in an ISA slot.

There are also a fair number of RS/6000 Unix boxes which are getting pretty long in the teeth.

For spare parts I've heard sometimes engineers buy things like Scsi hard disks off of ebay.

Btw, there's first video: http://www.trojmiasto.pl/wiadomosci/Warszatat-samochodowy-za...

It's been about five years since I bought this laptop (refurbished ThinkPad) and I'm sure I'll be using the same laptop another five years down the road. Many people are still using relatively old hardware and it meets most or all of their needs.

At least you don't need to worry about them fixing something that doesn't need fixing.

Are there any real-time operating systems out there currently that both run on modern hardware (maybe a raspberry Pi) and offer a simple programming option (not necessarily Basic, but something similarly approachable)?

This is irresponsible. That machine has been out of support for decades. I bet it's hacked and contributing every bit of its 1 MHz to a massive DDoS.

I think there still is and will be a market for systems with as few resources as possible, as long as they meet most computing needs.

It survived a flood, but how it survived all that industrial dust for so many years?

It's a Commodore 64. It has no moving parts (I assume the disk drive isn't ever touched) and the CPU doesn't really produce enough heat for cooling to be an issue.

The story would be perfect if it were an original C-64 instead of the C-64C redesigned variant.

So many auto shops/machine shops would be lost without access to older computers. So much equipment needs to be plugged into parallel ports.

"If it works, why muck with it?"

Or new computers with $20 parallel port/serial PCIe cards...

Good luck getting old applications requiring ancient OSes to work on those.

Run them in a VM? Guess that would be complicating things?

I think the initial setup would complicate things, but if setup correctly couldn't it just be an icon that boots up the VM or set the VM to start up on boot in batch script?

Yes - I mean WHY would you buy another computer, interface card, setup a VM, move everything over, test, make sure everything is compatible.... if the current offline system with its software works just fine?

Because doing all of that while the current system is still working is much easier than trying to do it after the old system has failed.

You can still buy most components for the C64, and failing that, there are a number of FPGA systems that reimplements it, as well as the C64 Reloaded reimplementation by Individual Computers [1] who have also licensed the Commodore name and is about to produce replacement cases.

Odds are that you'll still be able to replace a C64 with pretty much cycle exact replications long after you'd need to scramble for replacement for your current PC hardware...

[1] http://wiki.icomp.de/wiki/C64_reloaded

That's crazy when you can buy a working commodore or whatever for peanuts.

Anything with critical timing that runs over a parallel port can be very tricky to get working in a VM. It means running a realtime OS on top of a non-realtime OS, with some abstraction layers added. A C64 is very deterministic in comparison.

I've had luck getting DOSEmu to interact with parallel port hardware. Don't know how well it would work on x64 though.

Getting the hardware access to work properly (especially for systems as old as this, where I wouldn't be surprised if they do port timings by counting cycles) in a VM would be difficult. Not unsolvable, but for the engineering effort you can buy a lot of old machines as spares. (Or an FPGA-based C64 clone or something)

Apart from complicating it, we're talking about an auto shop, not a tech company. I doubt they have lots of computer engineers hanging around.

Previously: https://news.ycombinator.com/item?id=10951404

This doesn't even strike me as being all that old. I still see plenty of IBM 3270 systems in warehouses and suchlike places in the USA. Those are at least as old as a C64.

Duplicate from 14 hours ago: https://news.ycombinator.com/item?id=12601820

At first I thought it was a Commodore 128 because of its form factor. I never knew the 64 came in that form factor as well.

This post and its comments totally feels like a post from Slashdot.

Somebody in the area should offer to help them out. Someone who knew what they were doing could pretty easily suck the whole thing into an emulator, and that would keep them going probably for the next several decades, if they like, without having to worry that the hardware going out will cause them problems, or that the disks will crap out.

(I'd consider it myself but I'm about 2400 miles away.)

Since it is used for balancing, I assume it interface with some hardware. Getting the hardware to work and finding a compatible port could be difficult, unless its just serial or parallel ports

I think you might be surprised by how active the Commodore community has been. I haven't checked every possible component before writing this message but I'd bet the Commodore hardware ports are all available and can be hooked up to emulators just fine.

And you can stockpile those for not much money right now. And while they, too, will have correlated failures over the course of decades as they decay, at least it starts the clock back at 0 again.

> I'd bet the Commodore hardware ports are all > available and can be hooked up to emulators just fine.

You are aware that the C64 expansion port is actually the 6510-CPUs address and data-bus?

To properly emulate this cycle accurate in an emulator you'd have to attach about 30 I/O pins to your PC which you can update at a rate of 1MHz, with basically no latency between reads and writes, to connect external circuitry.

Even if it doesn't need realtime performance, which it might, it's interfacing with custom hardware, so it's going to be tricky to emulate. This is more the kind of thing you'd use an Arduino for. The Arduino's old-fashioned 5V IO is probably useful in this case.

You are assuming they need help. It seems to me they are doing fine.

Whatever your thing will run on, will it still work in another 30 years? Our hardware is so flaky that everyone in the industry is depreciating at 3-5 years or less. Sure, platforms can stay the same, hardware-wise, but you'd be really lucky if you can still run the same software that you did before.

And yes, you can run an emulator, but who's going to maintain the underlying platform? Is it going to be connected to the internet and be part of the next gargantuan IoT DDOS attack.

What those guys is need is another Comodore 64, brand new. It has proven it works, why change it?

We need to take a serious look at this stuff: this is what we should be doing. Not writing yet another freaking web server, but stuff that can still be operational in 30 years.

"You are assuming they need help. It seems to me they are doing fine."

Are you responsible for a production deployment of any kind? "I'm doing fine until something goes wrong" is not doing fine.

Unfortunately, merely stockpiling Commodore hardware is not a great long-term plan; the failures will be correlated. Even the ones just sitting on the shelf are decaying.

"And yes, you can run an emulator, but who's going to maintain the underlying platform? Is it going to be connected to the internet and be part of the next gargantuan IoT DDOS attack."

Why would it be?

You seem to be really, really stretching for reasons why this is a bad idea.

Pretty much guaranteed that nothing someone would build for them today would last them 3 decades. That's a lost art.

There probably exist COTS things to do exactly what they use this C64 for, used by other garages. When the day comes that this thing runs out, they can always switch to one of those. That's probably a better idea than trying to get this to work in a C64 emulator, timing issues and all.

I wish I could upvote you twice.

This is so very true, I can't think of any device that will offer them any kind of improvement over the brand new C64 scenario.

What device that is installed today will still be working 30 years from now? Maybe some appliances without moving parts? Some raspberry PIs?

The reason to get on the emulator platform is that it only needs to be something that can run an emulator and have a bit of hardware hooked up, which is nearly everything that exists today. The "nearly everything that exists today" will be easier to get a hold of, even in 30 years, than Commodore hardware.

Will it really? There are devices that refuse to setup because their activation servers went offline after a few years now.

I couldn't even setup an iPhone 5C without giving it a connection to the internet.

Just recently Individual Computer released a C64 motherboard replacement that is cycle compatible with the original, with the original IO ports etc.

On top of that there are about a dozen FPGA boards with a wide variety of C64 cores that will also give you more or less (depending on version) cycle compatibility with the C64 and varous degrees of availability of ports.

I think you underestimate how long hardware compatible with these systems will be available vs. the effort that would be involved in keeping an emulated setup working across migrating hardware and OS models and ensure the hardware interface they need keeps working for each new generation.

Your average church organ is expected to last 30 years, and large, representative instruments are expected to last hundreds. That's why the big ones are so low-tech. That's intentional.

We replaced our (digital) organ a couple of years ago. The previous one dated from 1992. People were surprised that we needed to replace it so quickly: I asked how many of them were still using an Amstrad word-processor from 1992.

On the other hand, there's plenty people who are still using a HP calculator from the same era. There's nothing inherent to computers that forces a rapid turnover. It gets really problematic when you have capital equipment with a lifetime of decades controlled by a computer that for some reason needs replacement every five years.

Organ builders have solved the problem: https://de.wikipedia.org/wiki/Orgellandschaft_Ostfriesland

I helped out a local church a few years ago that had an electronic pipe organ from approximately 1980. It wasn't digital at all, it was purely analog. Some of the keys didn't work any more, and others were out of tune. Basically, the way it worked is that every key had a whole circuit (with two key circuits per pluggable card) behind it which generated the tones; it was ridiculously inefficient. Over time, a bunch of the capacitors had gone out of spec, beyond the ability to use the potentiometers to compensate.

Not to mention that if they run it on a VM and the host crashes or becomes unusable, they lose business. It seems the C64 is robust enough for them, no need for extra layers.

What gives you the impression that they need help? Other than (potentially) the floppy drive, every other part of that computer is both more reliable (low power, low temps) and easier to repair (through hole) than anything they could get today. As an added benefit, they get security through absolute obsolescence. They should keep using what they've got until it no longer suits their needs or it becomes infeasible to keep it running.

Pretty sure they'd curse you out of the shop if you went there to propose that.. Their setup has been working for decades, it's more secure than 99.9% of systems out there, and the cost has long since amortized.

I'd be willing to bet that it will be easier to replace failing components or the whole thing to keep their system running for the next several decades than trying to keep a PC based replacement with an emulator running for the same amount of time.

You can buy entire newly built motherboards for the C64, as well as tons of spare parts and a number of FPGA reimplementations.

All/most of which are basically static, with no fans, and at least for the stuff that depends on original chips, it's pretty much indestructible.

E.g. just consider the dust, and the heat produced by most modern PCs vs. a fan-less c64 where the internals rarely get very hot. And where the components for the most part are near indestructible as confirmed by 7-8 year old me repeatedly pulling them out of their sockets helped by screwdrivers and reseating them and occasionally bending pins, without and kind of regard for static electricity; I also carried out "experiments" like moving chips between my C64, Amiga 500 and 1541 with little disregard for just how pin compatible they were. I amazingly never destroyed any of them.

In terms of the disks, you can still buy suitable floppies for backups, and you can also buy 1541 replacements that use SD cards or compact flash.

30 years from now, I bet you'll still be able to buy "C64s" in some form, while to keep a system based on a current PC it'd be hard not to get sucked into an upgrade cycle.

Reply on news.ycombinator.com