My personal issue with the LLVM re-licensing and its exception clause is that it made no effort to deal with a few projects which had used the LLVM core in an LGPLV2.1 context, only those projects in a GPLV2 context.
This screwed over a few projects which are unable to re-license to an apache2-compatible license. Offhand, I believe it affected the LGPLV2.1 licensed Wine/Codeweavers win32 emulation layer for running windows 32-bit programs on a 64-bit-only mac, and affected several other programs as well.
It should be possible to run the results of Unix speak.c through a real (or emulated) Votrax Type 'n Talk unit. I know MAME has emulation of said unit, and while it isn't perfect, its pretty understandable.
I took a shot at making a modernized port of speak.c myself not long after the code was found, but it didn't get very far, sadly. I couldn't figure out an easy way of dealing with the multiple-character character constants.
There was once another sort of 'competitor' to csound called cmusic, I believe the last surviving unmaintained port of it can be found at http://yadegari.org/carl.html
I've got access to an 8" drive as well as plenty of 5.25" drives, and the hardware to do flux images. There are others with access to similar hardware. As kjs3 suggested, contacting people via the classiccmp and vcfed lists is a good idea.
The calendar view on archive.org shows the page was archived 6 times while active, but all of those copies seem to have been manually deleted from archive.org (or perhaps hidden/blacked out?), or something else weird is going on.
Yes:
The Gameboy Player for the Gamecube has a GBA processor and some glue logic inside it.
There is at least one Nintendo DS cartridge which has a bluetooth chip inside it: Pokémon: Typing Adventure/
And several Gameboy Advance cartridges in the Boktai series have a 'sun sensor' in them.
I'm sure there are other examples as well.
I was excited, but the fact that this is (well, WAS) violating the GPL by being MIT licensed was a major downer. I'd be very interested in an org-mode parser which is NOT GPL-licensed, specifically because it is effectively impossible to integrate GPL code as a plugin (unless your editor is also GPL), which was one of the stated goals of this project.
Hence, someone would have to properly clean-room reverse-engineer org-mode in order to achieve 100% compatibility, or make a somewhat-incompatible implementation based on the reference docs instead.
As I understand it, Markdown has significant limitations which org-mode doesn't have, but is under a 3BSD-style license. (It also has issues of x+1 slightly incompatible implementations)
AFAIK this is not activated by default in FF65; the about:config key for it is 'network.trr.mode'. The default is currently 0 (off). 5 is also off, but explicitly user-set to be off (opt-out). See https://wiki.mozilla.org/Trusted_Recursive_Resolver
If it was in error, does this affect any merged code pieces/PRs submitted/merged after the readme was changed, or do the license headers per-file take precedence?
Sadly, the Bradley trainer doesn't actually work properly in MAME, because the mathbox (a math accelerator circuit) in the Bradley Trainer used custom PROMs which differ from the stock Battlezone (implementing several more commands than 'stock' Battlezone does), and these were never dumped by Scott Evans.
Hence the "AI" (and collision detection?) doesn't work correctly.
The reason for this (at least as I understand it, which could very well be incomplete and/or wrong, as I have little background in dealing with shaders) is that the version on itch.io (which is compiled from source code on github at https://github.com/gavanw/voxelquestiso or https://github.com/gavanw/vqisosmall ) has a bug in (at least) one of the shaders, compiled from /src/glsl/GenerateVolume.c:
The bug (or how I understand it, which, again, could be wrong) is that that specific shader is mixing sampler2D and sampler3D uniforms, which is forbidden by the Opengl 3.3 shader spec.
The reason it works at all on NVidia cards is that apparently NVidia's shader compiler plays fast and loose with that part of the shader specification and allows mixing sampler2D and sampler3D elements, while ATI/AMD and Intel's shader compilers will fail to compile that shader.
Failure to compile the shader results in voxel quest only rendering the 'ocean' tiles, tree tiles (without lighting), and building tiles (again, without lighting), and everything else as background/sky gradient.
Someone committed a "fix" to one of the github trees which more or less patches out that shader or the offending part of it, but this just means it renders the wrong way on ALL cards, including NVidia ones.
Hopefully it will eventually be fixed properly in an opengl shader spec compliant way.
Found an intact copy: ftp://ftp.sra.co.jp/pub/lang/postscript/pdb2.1-demo.tar.gz which someone recompressed from compress to gzip at some point. The original compress archive seems to be lost except in truncated form :(