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.

...

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.

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)?

Please post the output of

Then try

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.

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.

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.

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.

cube is here:
http://canavan.de/neko/neko_cube-2005-08-29.tardist
it may need some of those:
http://canavan.de/neko/neko_sdl_mixer-1.2.12.tardist
http://canavan.de/neko/neko_sdl_image-1.2.12.tardist
http://canavan.de/neko/neko_sdl_ttf-2.0.11.tardist
http://canavan.de/neko/neko_sdl_net-1.2.8.tardist

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.

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?

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.

Premium does not imply 8.0 of whatever they are (probably ns):