To go into more detail: in Unix there is a function named fork() which tells the OS, “duplicate this process”. It returns a value telling the given process whether it’s the original process (“parent”) or it’s the “child” process. Normally, the parent goes on to do different stuff than the child. But if a programmer put such a call inside an infinite loop, and didn’t check the return value, then the number of processes would grow exponentially, eventually running up against either the user limit or the kernel limit.
It could be done that way, but it will be much easier for the OP to get an 80s PC that isn’t running a multi-processing OS.
The most sophisticated OS for personal computers in the 80s had to be AmigaOS. It had to be ten Moores ahead of everyone else.
In that case, have the protagonist load Windows on the machine.
According to Wikipedia, SCO released Xenix for the IBM PC in September 1983.
Sure. But he’ll have an easier time finding an IBM PC clone running MS-DOS or an early version of Windows, or a PET among many more. But if can get Xenix installed along with the rest of the software needed to create his app, then sure, he could do it. He could get 8 and 16 bit machines that ran multi-threaded CP/M clones also.
Per the OP, this is all just in a story. He’s not putting this together in real life.
What?!?! We did all the feasibility studies, cost-benefit analyses, developed an implementation plan, and now he’s not going ahead with the project?!?! Someone from sales get down there and talk to this guy. Find out why he changed his mind. Maybe we should lower our prices? I hope he isn’t going with the geeks from some other message board, they’ll never get it right.
OK, the distillation of quite a bit of what has gone before might get you there.
There are a few assumptions here. So, you want what we usually call an embedded computer - you suggest a wall hanging with display. And stupid '80s level. So, something like a 6502 would be perfect. Pretty correct for the time. I don’t know if you want to make this custom made or off the shelf, but one could imagine an artwork that would have been pretty wild for the time being a big electronic sign with a small computer controller. These will typically be really stupid. Forget operating systems, they had none. Load the code and go. Typically blow the program into a EEPROM.
So, how about a nice problem for it? It is a display, so how about have it visually solve the Towers of Hanoi? Has a nice spiritual flavour. You could have the system designed so that you could have a input device that sets the height of the towers and the speed at which it does the solution - so from a human followable pace where the disks move at a pace the eye can follow, to a pace where about the only thing you see are the towers getting bigger and smaller.
So, want a totally plausible issue with the program? The 6502 has a limited stack size. The Towers of Hanoi is recursive. If you set the tower height too large it will run out of stack. This can plausibly cause any amount of grief in the code. It could crash and the program stop, it could reset, and start from the beginning, it could scramble various bits of the program and the display go nuts for a brief while before the things either stops or resets. There is a plausible case where the stack wraps around, but this causes the program to get stuck in an intermediate loop of moving the towers that it never breaks out of.
Given the story (of dubious provenance) of the Towers of Hanoi involves the bringing about of the end of time once a set of towers of 64 high are completed you have a neat underpinning story.
However it takes 2[sup]65[/sup] moves to complete this, so the sun will be long cold before even a 6502 can perform the task, let alone the monks of the story. But asking the computer/display/exhibit to even start a 64 high tower would probably crash a 6502 with a stack overflow before it got too far into the problem (it would of course crash with lower height towers too, but 64 is the magic one for bringing about the end of time).
There are still a heap of assumption I’m making, so it still may not fit your needs, but the thought occurred to me in an idle moment, so I thought I’d share.
Maybe this is off topic as I didn’t destroy a computer but…
I had some fun in the late 70’s at college with a IBM 360 mainframe. The University just bought a page printer about the size of a dishwasher that was fed by a huge box of continuous sheets of paper.
The printer was an upgrade from a line printer which was slow as it was really just a high speed mechanical typewriter. This was a really high speed mechanical typewriter that could print a whole page in one shot.
I wrote a continuous loop program from a terminal, while watching into the huge glass enclosed computer room, that told the printer to print every character it could onto every single character space.
When the printer tried to print over 500 characters in every space on each page simultaneously it literally started jumping across the computer room.
I watched the poor computer room guy try to wrestle the thing down , but it was too late. It was completely ruined. I saw smoke coming out of it and promptly left.
Of course I used a hacked professors account to do this (he gave me a bad grade once.) I don’t think the term hacker was coined yet, buy that was my hobby. The IBM guys flew in the next day and removed it. It wasn’t replaced for a semester.
BTW, I wrote the program in FORTRAN.
Does it need to be a math problem? Those old computers/operating systems had no protection from one program accessing another’s memory. IIRC any old program could change the memory space of an OS process, instant lock-up (not permanent, just until you restart the computer.)
Just as a side note about the 6502 processor. It uses a minimal register architecture and the 8 bit stack pointer usually isn’t used for higher level processing. Anything compiled from a high level language, or just designed for heavy stack usage would emulate a conventional stack, or the code would create stack frames in conventional memory that are linked to form a conventional stack logically.
This is EXACTLY what I was trying to find. Thank you so much, I will probably have some questions to clarify this later. For now though how far do you think the 6502 could get at full speed and how long (in human time) before it crashed? Plausibly, like an hour, or more like 10 hours? It would always crash at the EXACT same move for the exact same reasons, wouldn’t it?
It was considered great fun to write a program that played music on the printer. Specific series of letters being fired with specific pauses. I can clearly remember being in the computer room at UT Austin, working as an operator, when someone fired up one of those programs and the printer started playing “Saints Come Marching In”. Needless to say, they used up a lot of paper real quick.
It’s not the processing of the problem that takes the time, it’s the graphic display. You could make it take as long as you want.
The execution speed of the machine can vary wildly depending upon how it is programmed (ie in assembler, compiled high level language, interpreted language) and how much work it must do to control the display, you could easily get a plausible difference of a thousand to one in speed depending upon these questions, so you can probably make the technical choices fit your story’s needs. The pacing item of the design will be the time you want a move to take.
The towers need 2[sup]n[/sup] -1 moves to solve, where n is the height. How long you want the move to take will depend upon the desires of the visual design of the display. A second is a good start if you want to see the disks move individually. So a tower of 16 high would take 18 hours to solve at this rate. You can tweak things from there.
It will be deterministic, so yes, it will crash identically each time. (There are always exceptions to this - a bit of uninitialised memory or a timing related component can make the behaviour either more messy, or actually non-determinisitc, but the safe assumption is that it is deterministic - unless you need to not to be.
But if you avoid recursion, you could write a Towers of Hanoi solver that won’t crash the system.
To be clear, though, solving the Towers of Hanoi requires recursion. It’s just that there are ways of expressing that recursion which won’t crash 1980s-style [del]death[/del] microcomputers.
Recursion is simply an easy way of replicating a context frame. You could effect it with a dynamic array (or even a static one, since you already know how deep you will need to go) of context frames, where you shift the frame pointer or index and copy in a simple loop. Recursion is just a more elegant looking way to do it.
That and some other solutions are not substantially different from recursion since they maintain a logical stack and have the same storage requirements. There are rule based solutions that don’t require any more storage than that required to represent the current state of the disks on the towers. Each move would take longer to compute, but you wouldn’t run out of memory unless you picked some absurd number of disks, and then you’d know that immediatly before making any moves. Of course the recursive solutions could also figure how much memory they need before starting, or just check memory as they run. If you want to intentionally crash a computer you have to do some senseless things.