Live data from Hacker News

Tetris-OS: An operating system that only plays Tetris

github.com

111–120 of 126 posts

Re: Tetris-OS: An operating system that only plays Tetris

#113

I wonder why the choice of SB16

Because it's widely supported by emulators, and supports the 16 bit sample size at the 48 kHz sample rate that is needed for high quality music, which is more than enough for Tetris.

The SB16 also features FM synthesis, though this program doesn't appear to use it; it rolls its own wave table method.

However, that would be a particular reason to target it specifically, rather than some more modern card that lacks FM synthesis. FM synthesis produces the signature sounds heard in 80's pop music and video games.

Re: Tetris-OS: An operating system that only plays Tetris

#114

Earlier quoted context omitted.

I don't think it is essential that there be a clear boundary between an OS and programs. For example, you can have a Smalltalk-based OS, written in Smalltalk. The OS components are simply Smalltalk classes and methods. Your programs/utilities/applications would also be Smalltalk classes and methods. There needn't be any clear boundary between the classes/methods that belong to the OS and those that belong to programs…

I like to define an OS as something that can execute arbitrary binaries. So if your hypothetical Smalltalk OS has a defined executable format that non-Smalltalk programs can compile to, I’d call it an OS. Note that this also makes for example the uppermost part of the JVM an OS by my definition. I’d argue it’s not a completely incorrect characterization.

What do you mean by "arbitrary binary"? Surely, you don't mean that absolutely any binary blob should be a meaningful executable. Because that would mean that my computer doesn't have an operating system because it's only capable of running binaries built for Ubuntu on amd64 -- if your binaries targeting BSD on ARM can be viewed as "arbitrary," then surely they shouldn't be expected to run on my pseudo-operating system.

No, every operating system that I know of makes some assumptions about the language that programs are written in. On my amd64/Ubuntu system, the language is largely specified by the processor (and, yes, has a binary format) and the programs are allowed to assume the presence of various devices, formats of various system calls, etc. Other languages are supported through a complicated system of compilers, interpreters and assemblers.

Or, coming at a different tack: does the existence of a C->Smalltalk transpiler turn the Smalltalk-based pseudo-OS into a real OS? What if the pseudo-OS doesn't ship the transpiler, and you need to run that yourself in user-space?

Re: Tetris-OS: An operating system that only plays Tetris

#115
post #68

If Tetris (with an infinite board) is Turing complete, then how about building an OS from Tetris? (It seems for certain problems it is NP-complete!) https://liacs.leidenuniv.nl/~kosterswa/tetris/tot.pdf

Turing completeness refers to a language, while NP-completeness refers to an optimization problem. So for it to be turing complete you first need to define a language based on tetris. For NP-completeness, it might just be solving the game.

Sorry to nitpick your nitpicking, but NP-completeness refers to decision problems (does there exist a solution with parameter k); optimization problems are often NP-Hard (find the minimum parameter k for which the decision problem has a solution).

Re: Tetris-OS: An operating system that only plays Tetris

#116
post #115
post #68

Earlier quoted context omitted.

Turing completeness refers to a language, while NP-completeness refers to an optimization problem. So for it to be turing complete you first need to define a language based on tetris. For NP-completeness, it might just be solving the game.

Sorry to nitpick your nitpicking, but NP-completeness refers to decision problems (does there exist a solution with parameter k); optimization problems are often NP-Hard (find the minimum parameter k for which the decision problem has a solution).

You're right, sorry about the lack of precision

Re: Tetris-OS: An operating system that only plays Tetris

#117
post #90

I was half-expecting an OS where you delete a file by completing lines with the right Tetris pieces.

How would that work? Genuinely curious, trying to visualize what you mean

Perhaps start with a set of blocks representing available resources. The 'top' equivalent could be a stream of blocks falling down the screen. Manipulate and rearrange the blocks to create new sets of blocks representing your desired function.

Deleting a file would be similar to any current GUI file manager, but with more blocks - drag file block to delete block. Opening a file with a particular program would be similar. Chaining a series of operations would be where it gets interesting. The shape of the pieces would control what can be chained together.

Re: Tetris-OS: An operating system that only plays Tetris

#118
post #111

Earlier quoted context omitted.

Also because it’s supported by QEMU.

And any emulator since 1996.

Also can be natively enabled on bare metal by DOS without additional drivers, so many audio chips support(ed) SB16 long after DOS lost popularity.

Somewhat like VESA graphics modes which are at least there if you have no vendor-specific VGA drivers.

Re: Tetris-OS: An operating system that only plays Tetris

#119

> This has only been tested in an emulator. Real hardware might not like it. ?! So this is just a stand-alone binary with an awkward loader then. The real trick (and challenge) comes when you want to run your stuff on actual bare metal.

Yeah... my biggest question is why it hasn't been tested on hardware. Dev doesn't own an x86? Also the author refers to the (raw/MBR-format) disk image twice as an "iso" which makes me shudder.

If there was a floppy-based IMG file I would try it right out on bare metal.

Re: Tetris-OS: An operating system that only plays Tetris

#120

Earlier quoted context omitted.

> It booted into its own customized version of an operating system that ran what it needed to run to make its game work well and be performant and reliable Most bootdisk-based games did not have any kind of "customized version of an operating system". They were running on bare metal. For 99% of the games, there was no abstraction/management layer between the application (the game) and the hardware nor any kind of fra…

Also if you take 1 generation step back into the 2600 or intelivision there was a very simple API they did use that was built in. It was usually little more than fill out some memory in a particular way and flick an interrupt or particular instruction and it would either run something in bios or hardware. Also many did not need much in the way of an OS as they usually just either memory mapped themselves into the add…

The Atari 2600 has no BIOS or any other built-in ROM. Maybe you're thinking of the 5200 or 7800?
Post reply on HN