HN user

Lord_Nightmare

359 karma
Posts10
Comments37
View on HN

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.

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.

It depends on whether it is an essential dll or an optional plugin. I probably could have phrased that better originally.

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)

Is the LGPL part of the license actually LGPL 2+, 2.1+ or 3.0+?

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?

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:

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

hunting for another copy...

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 :(

The Game genie gameboy code "encryption", if anyone cares:

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

The issue is not when you powered up the machine and the ram boards, its more whoever powered them up before you got the machine.

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

What I'm personally afraid of is that, due to the bad power supply which was repaired in restoration part 1, the wrong voltage was applied to one of the power pins of several boards full of DRAM chips, and this may have fried the entire lot of them.

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