The collected works of canavan - Page 3

If you're in Berlin, you could post one cable to me (I'm in Cologne), and I'll be glad to measure it, post the results and send it back to you. PM me for my postal address.
I used to use a Fuel V12/V10 with the MLA, and that worked well enough with the stock .vfo. I think there's an option somewhere in the menu that needs to be set / adjusted to get a proper 16:10 picture. I'm mostly using a Pixelink box now, which is working flawlessly for digital (DVI) signals.
It's actually supposed to be std::sort(), I'm not sure why the compiler or linker fails to properly use it. A cheap workaround would be to sabotage the detection of HAVE_STD_SORT in configure (or the resulting config.h), so that xpdf 3.03 will fall back to the behaviour of 3.02 and just use qsort.

If you're going to make a nekoware package of 3.03, please include the attached desktop icon and rules. For the unlikely case that you don't know how to install them from the .idb, check my neko_nonpareil or neko_xclip packages, I think they have more or less the correct exitop() tag() and removeop() rules.
I already have two installations of usr/bin/acroread on my system, xpdf and gsview (the former actually won).. I don't think you can reliably rename previously installed files during the installation of packages. I would assume that you can override file type rules just by specifying new rules that match the same files later. the order should be given in /usr/lib/filetype/Makefile and is (in /usr/lib/filetype) local install system default. I files in local don't override the rules in install, default should work.
I have no idea what exactly is going on regarding the sort problem, or how to solve it. C++ has a feature called mangling, where the compiler will encode the required types of parameters in the symbol name in the .o file. It looks to me like the mangled types are too specific, so that the linker doesn't find anything that matches (or maybe the compiler fails to generate a function stub with those types).. The missing symbols are internal helper functions for the sort(); function in <algorithm> fofi/FoFiTrueType.cc. This may just as well be some more modern C++ construct than MipsPro supports, or just plain a gcc-ism.
To get the correct fonts, you may either have to install additional cygwin packages (there should be some 75dpi and 100dpi standard fonts) or copy some files over from you IRIX box and add the appropriate paths with "xset +fp". Check the available fonts with xlsfonts, I'd guess that you only have the built in fixed font.
I've just uploaded an easy to install tardist to /incoming, you can get it from
http://www.canavan.de/neko/neko_addtobg-1.0.tardist until it is moved to /beta. Is there any way to specify filenames with spaces in ~/.backgrounds? I had hoped that just changine [email protected] to "[email protected]" might fix any problems, but it's the syntax of ~/.backgrounds that finally prevents filenames with spaces to work. I've tried various mixes of single and double quotes, as well as backslashes so far, without any usable results.
...
Concerning templates, I usually use bitmaps, displayed with imagemagick or xv at a suitable size, and flip between iconsmith and the template with Alt+F3.

The FTI Editor comes with two functions I've been missing in Iconsmith: nameing parts and the capability to move them up and down in steps, instead of just all the way to the top or bottom. What I'm still missing is a function to snap to intersections of lines, and a function to turn closed polygons back into open ones (although the latter is easy with a text editor...)
kubatyszko wrote: It also makes me wonder what is the second power socket for - it's not soldered anywhere, but I checked and the respective pins are short with the same pins in the working one...
(for a moment I thought that may have been direct 5V input - but it doesn't seem so)..
I'd suspect the second socket was intended to use one power supply for the monitor and the adapter, with just a cable between the multilink and the screen.
neko_sqlite3-3.7.10.tardist is in /incoming - it works for me with nekoware firefox.
You patch is way better than mine, but how do you configure/compile the whole thing without CC complaining
Code:
cc-1035 CC: ERROR File = /usr/include/stdint.h, Line = 5
#error directive:  This header file is to be used only for c99 mode
compilations

#error This header file is to be used only for c99 mode compilations
^

My inelegant but working neko_pixie tardist is in incoming, just help yourself to the dist files etc. if you want to make a better .tardist.
Which version of firefox are you using, and do you have any LD_LIBRARY_PATH (possibly with N32 somewhere) set (you shouldn't, any nekoware package that requires it is broken and should be fixed)?
I've rebuilt with bplaa.yai's patch in the meantime. A new neko_pixie-2.2.6.tardist is in /incoming. To test, grab an example .rib file from http://www.renderpixie.com/pixiewiki/Ex ... B_Examples and drop it on rndr in the Applications page of Icon Catalog. You may have to set PIXIEHOME=/usr/nekoware/lib/Pixie (or whatever may be the correct value...) in your environment.
Please post the output of

Code: Select all

ls -l /usr/nekoware/lib/libsqli*
ldd /usr/nekoware/lib/firefox-2.0.0.22pre/firefox-bin
LD_LIBRARYN32_PATH=/usr/nekoware/lib/firefox-2.0.0.22pre ldd /usr/nekoware/lib/firefox-2.0.0.22pre/firefox-bin
LD_LIBRARY_PATH=/usr/nekoware/lib/firefox-2.0.0.22pre ldd /usr/nekoware/lib/firefox-2.0.0.22pre/firefox-bin

Then try

Code: Select all

LD_LIBRARY_PATH=/usr/nekoware/lib/firefox-2.0.0.22pre /usr/nekoware/lib/firefox-2.0.0.22pre/firefox-bin
First of all, use "snapshot" to take screenshots. Since you're apparently getting the "Atomic operations are not supported on this system, consider leaving a note in Sourceforge about your platform" message, you need to upgrade. re-download neko_pixie from beta and install that.
Knowing the pinout will at least let you know that nothing is going to catch fire due to the substitute cable. Considering that most of the candidates are rather short, we may be lucky and get away with a less than optimal replacement.
Cave story needs some work, since it doesn't support MSB Audio (it defaults to AUDIO_S16, which is LSB and bails out if it doesn't get what it asks for, which it doesn't with RAD or MAD, maybe something else works), and it's not finding some sound files (pxt/fx01.pxt - pxt/fx75.pxt), and music initialization fails. http://canavan.de/neko/nx-1003-irix.tar.bz2
I only really wanted two, but ebay doesn't let me bid anyway:
http://www.ebay.com/itm/380434659284
regarding the Emitter, you may be able to build your own, a simple one should be possible with only a few components, i.e. 2 555 timers and a few transistors, IR diodes etc. If my analysis is correct, you just need a 50us IR pulse when the 3d Sync signal goes down, and a 125us pulse when it goes up. Using a microcontroller to enable adjustable delay by +- a few microseconds would be nice, especially negative "delays" would be useful to prevent the top of the screen from darkening in some modes.
Image
Image
Image
Code:
1920*1200*60 = 138240000
1920*1080*60 = 124416000
1920*1200*50 = 115200000
2*138 is too close to 290 million pixels per second (i.e. more than that when including the "housekeeping" stuff), if 2x124 works, so should 2x115. It's likely that 55Hz, or even something closer might work as well.
Apparently there are multiple versions of the "normal" firmware for the SD-M1401, as well as a flashing tool available:
http://backfire.rpc1.org/tsstcorp/index ... =SD-M1401/
Do you have the SGI firmware somewhere, so we can SGI-ify our drives?
An Implementation of getopt_long is part of gnulib http://www.gnu.org/software/gnulib/MODULES.html#module=getopt-posix . I usually just copy the source files into a suitable directory and add them to the list of .c-Files in the Makefile.
The Joybus board is likely 4 layer, but that's probably for EMC, not due to the complexity. I'm certain that all the Nintendo-specific ICs are also found either in the controllers or on cartridges (BU9850 e.g. on Super Mario 64). I actually wanted to have mine x-rayed to help in reverse-engineering it, but I missed the opportunity to have that done. If anyone wants to spend an afternoon at my desk probing my joyboard, you're welcome to visit me near Cologne.

Image
Image
Image
Image
Image
My Ultra64 has never been used, it's still as it came from SGI - I think those wire wrap fixes can be seen on other examples as well, so they may be standard for 2.0 boards.

reverse-engineering such a board isn't easy, but entirely possible.

Here's a photo instead of the scans of the joybos board, with light at an angle, the inscriptions on U1 + U2 are actually readable. I think U2 is the same as U8 in a real N64, I don't see any equivalent for U1. The FIL coils(?) should be recyclable as well as some of the caps since they should be basically equivalent on the joybus board and the Ultra64.

You can use geda-gaf and PCB, conveniently provided in nekoware (possibly beta) to design your replacement board.
Image
That would mean that the JoybusBoard should more or less directly patch through the Joypad data lines to the RJ plugs, and therefore one should be able to just cut off the N64 plug of a Joypad and crimp on an RJ connector. That should be good news for anyone who's looking for a Joyboard.

It turns out that that is indeed the case. Pin 1 + 4 of both "left" and "right" Socket pairs are all connected together and lead to pins 2, 8, 14, 20, 26 on the ribbon cable connector. Pin 2 of "left" is connected to 6, 3 to 10. Pins 1-6 on the ribbon cable connector go straight to 1-6 on an RJ12,7-12 connect to the next RJ12 etc. That's an "interesting" choice, because JP1 needs to be connected to both the first and second RJ12 connector, and JP2 connects to both the second and third.

Code: Select all

JP1
1  2,8,14,20,26
2  6
3  10
JP2
4  2,8,...
5  12
6  16
JP3
1  ...
2 18
3 22
JP4
4  ...
5  24
6  28
You shouldn't solder but crimp new plugs (note the plural) onto the gamepad cable after cutting off the old connector. . Re-read my last post on the previous page for the pinout, be sure to compare the pin numbers given with the photos I've posted. The only components on the Joyboard in the signal path are the FILT-inductivities. Since those are not duplicated on the Ultra64 board, you may want to add something equivalent to a modified Gamepad it the N64 has them as well.
So what I expect is that the "controllers for U64 dev board" are different from consumer controllers by bringing the send,receive,and clock signals out directly without 1-wire encoding, i.e. they are simpler than the consumer controllers by missing that component.

No, they should be the same, except maybe for some passive filtering stuff on the cable and the different plug.

I only see diodes D1 + D2 on the Joybus Board, I'd be surprised if they had anything to do with the 4 Joypad ports.
The SGI Screenshots don't look IRIXy enough. If your app supports Xresources (it should), try setting the following resourced (prefixed by gXipmsg or whatever it's using as an internal name). Use xrdb -merge to merge your new resources with those already set at the start of your session.

Code: Select all

*schemeFileList:        SgiSpec
*useSchemes:            all
*useEnhancedFSB:        True
*sgiMode:               true
I can't compile it in IRIX 6.5.30, I'd guess that my Motif headers are too old, because XmCHARSET_TEXT isn't defined anywhere in /usr/include or its subdirectories, including Xm. Which packages from what CD do I have to install to compile gXipmsg?

Code: Select all

cc   -g -c appIcon.c
cc-1020 cc: ERROR File = appIcon.c, Line = 139
The identifier "XmCHARSET_TEXT" is undefined.

text = (char *) XmStringUnparse (xstr_list[mIdx], NULL,XmCHARSET_TEXT, XmCHARSET_TEXT,NULL, 0, XmOUTPUT_ALL);
^

cc-1020 cc: ERROR File = appIcon.c, Line = 139
The identifier "XmOUTPUT_ALL" is undefined.

text = (char *) XmStringUnparse (xstr_list[mIdx], NULL,XmCHARSET_TEXT, XmCHARSET_TEXT,NULL, 0, XmOUTPUT_ALL);
^

cc-1020 cc: ERROR File = appIcon.c, Line = 165
The identifier "XmCHARSET_TEXT" is undefined.

text = (char *) XmStringUnparse (xstr_list[mIdx], NULL,XmCHARSET_TEXT, XmCHARSET_TEXT,NULL, 0, XmOUTPUT_ALL);
^

cc-1020 cc: ERROR File = appIcon.c, Line = 165
The identifier "XmOUTPUT_ALL" is undefined.

text = (char *) XmStringUnparse (xstr_list[mIdx], NULL,XmCHARSET_TEXT, XmCHARSET_TEXT,NULL, 0, XmOUTPUT_ALL);
^

4 errors detected in the compilation of "appIcon.c".
gmake: *** [appIcon.o] Error 2

Code: Select all

# /usr/Motif-2.1/lib/mksymlinks


That one actually helps, and gXipmsg compiles. thanks.
The ADA8824 used with the sonic cards is a different model than the one usually used with the Discreet setups. All the Discreet manuals I've seen so far only mention connecting the ADAT model(s) or the ADA8824 with a RAD card or the onboard RAD audio of an Octane. Some of the Sonic Solutions ADA8824 are easy to spot on photos, as they are blue, while the other models (both the Discreet ones with RS232 control ports and the normal ones with MIDI control) are whitish anodized aluminum. The sonic solution ADA8824 are sometimes dirt cheap on ebay, as nobody wants them. Apparently, you can't convert the ADAs from one version to another due to firmware and/or other differences.

See also this thread: viewtopic.php?f=4&t=11968
The real problem is that "standard" FAT16 supports only 2GB. For anything larger, you'd have to use FAT32, which IRIX doesn't support. The 64k clusters I mentioned are non-standard and don't work for either IRIX or my Canon 40D.
Indeed, the 195MHz is the minimum for an R10k O2 to reliably capture video, according to e.g. Alexis Cousein:
http://groups.google.com/group/comp.sys ... 093dbed7b0

I think I still have a spare 195MHz CPU somewhere in a drawer, you can have it for 10 EUR plus shipping from germany...
Premium does not imply 8.0 of whatever they are (probably ns):

Code: Select all

Bank 0 contains 1024 MB (Premium) DIMMS (enabled)
Bank 1 contains 1024 MB (Premium) DIMMS (enabled)
Bank 2 contains 1024 MB (Premium) DIMMS (enabled)
Bank 3 contains 1024 MB (Premium) DIMMS (enabled)
Bank 4 contains 1024 MB (Premium) DIMMS (enabled)
Bank 5 contains 1024 MB (Premium) DIMMS (enabled)
Bank 6 contains 1024 MB (Premium) DIMMS (enabled)
Bank 7 contains 1024 MB (Premium) DIMMS (enabled)

Code: Select all

EEPROM     JEDEC-SPD Info           Part Number        Rev  Speed  SGI
---------- ------------------------ ------------------ ---- ------ --------
DIMM 0     7F94FFFFFFFFFFFFB30B680D SM57228DSGI100C2   00FF   8.0  N/A
DIMM 2     7F94FFFFFFFFFFFF5548501D SM57228DSGI100C2   00FF   8.0  N/A
DIMM 4     CE000000000000000CB84D00 M3 46L2820DT2-CA0   2D   10.0  N/A
DIMM 6     CE0000000000000027AA2E00 M3 46L2820BT1-CA0   0B    8.0  N/A
DIMM 1     7F94FFFFFFFFFFFFD548501D SM57228DSGI100C2   00FF   8.0  N/A
DIMM 3     7F94FFFFFFFFFFFF9548501D SM57228DSGI100C2   00FF   8.0  N/A
DIMM 5     CE000000000000000CB34D00 M3 46L2820DT2-CA0   2D   10.0  N/A
DIMM 7     CE0000000000000028561500 M3 46L2820BT1-CA0   0B    8.0  N/A
What kind of hardware are you using (it worked pretty well in stereo, fullscreen at 1024x768 on a 400MHz V6 Octane)? Do you have consistent bugs with the sky, or only in specific places if you look exactly straight ahead?

The two main problems with darkplaces I currently know of are that the screen stays black on O2s, and that the stereo 3d projection is vomit inducing, since I can't fuse the weapon models.
Good to hear that gnome is still compileable. Any chance you could provide updated nekoware packages, or at least document the autoconf or compiler flag magic you had to conjure up?
The times when you could damage your monitor with an out-of-spec signal should be long over. It was back in the times when voltages were proportional to the input frequency that a monitor would just fry itself when given a signal with too high a frequency - that was back when a "multisync" CRT was high tech.

Any TFT monitor (but possibly not a separate panel) should know precisely when it can display a signal and when it can't.
If conflicts did not display anything when you installed the package first, and you did not set rulesoverride, then the package does not explicitly specify that dependency and may be buggy in this regard. Apparently, firefox only has neko_gettext neko_glib1 and neko_libiconv as prereqs, which is obviously not enough. For all packages where this is the case, the only thing you can do to get the package running is to install the libraries by hand.
If you're compiling 4.7.? anyway, could you please make nekoware packages? It's only a tiny bit of additional work, aside from building with a different prefix ( /usr/nekoware/gcc-4.7) and runing find /usr/nekoware before make install and another find and a script afterwards, it's really just writing the releasenotes...