AngeTheGreat's Engine Simulator: Procedurally Generating Audio Using a Real-time Fluid Simulation (Technical Breakdown)
359 karma · joined May 27, 2015
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.
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.
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)
I'm asking because of reaperducer's comment from just a week ago: https://news.ycombinator.com/item?id=18086566
At least some of the file headers say 2+, the readme says 3.0+, but this note was added after the fork, with commit https://github.com/daviddurand/iText-4.2.0/commit/312abf7b12... so it may be in error?
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?
Hence the "AI" (and collision detection?) doesn't work correctly.
https://github.com/gavanw/voxelquestiso/issues/10
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.
LN
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 :(
each letter is one hex digit.
GG CODE: ghi-jkl-mno
Address = lijk XOR 0xF000
Data = gh
Compare = mo ROTATED right by 2, and the result XOR by 0xBA
Mystery value = n
Codes can be 6 or 9 digits long, 6 digits if the compare value feature is not used.
The game genie can only modify addresses in the 0000-7fff range, meaning it cannot modify on-cart ram banked in the a000-bfff area (the later datel action replay, however, can modify this and other ram areas, using a periodic interrupt and swapping out the interrupt vectors for its own)
Mystery value has a min of 0, never greater than 7? this was apparently, from what I remember from the usenet leak, intended to thwart games which would checksum their roms before starting, but seems to me to have little practical use, and I'm not even sure how it worked if it worked at all, it may have restored the original value if it saw an access to rom 'mystery value' bytes away from the value being changed by the code within a certain number of cycles, or something like that.
The compare value is so that the game genie can selectively patch values in banked rom gameboy games which have multiple rom pages appear at certain addresses due to mapper chips, in which case it will only replace the value at said address if the compare value matches.
LN
LN
That power supply may have failed decades ago. Was the machine known working when it was last powered up?
Is there any way you could build a rig to test each 4116 chip, or a rig you could plug each board into which would supply proper voltages (in the correct bring-up and bring-down order, because 4116 drams are weird like that) for the dram, and do a pattern test on the entire board all at once?
Personally I don't like 4116 drams at all because they're very unreliable. (4164s are far superior in this regard.) See the PARC notes on bitsavers re: the notetaker project, the notetaker test systems were frequently out of commission due to failed 4116 dram chips, or running with one or more chips dead and the ECC constantly correcting the errors.
LN
If the Alto2 has 128KiW of dram, and the drams used are old tms4108 chips(I'm not actually sure about this, they may be even older), and there are 18 or 19 bits of ram per word (16 bits plus 3 parity/ECC? Again, not sure.), then there could be as many as 304 chips to replace (or at the very least, to pull and test each one and replace the bad ones).
Fortunately, if they used triple-voltage (5v, 12v, -5v) 4108 or 4116 drams, you can replace those chips with the 5v-only 4164 chip by bending 2 pins upward on the 4164 and soldering a wire to another pin. This isn't "period accurate" but should work to replace a few bad chips until working ICs can be found.
See http://picmania.garcia-cuervo.net/recursos/redpicdatasheets/...
LN
Is the entire useful concept patented at this point?
Also, drop by on Freenode #VoxelQuest sometime. We're still hanging around in there.