The collected works of ShadeOfBlue - Page 2

That is the wrong FS type
IRIX CD's use EFS.

How about disassembling the PROM, rewriting the CPU initialization code and then reassembling it?

Try "chkconfig xinerama on" (you may have to use the -f option if it complains). By enabling xinerama, the two displays will act as a single large display
This can have some weird side effects if one head supports texturing and the other doesn't, though.

[I've split this topic from this thread ]


Finally got some more hobby time, so I've glanced through the specs for the parallel port and the Flash chip and I've come up with a rather clunky design

Five 74HCT374 latches (three for the address bus [24-bit], one for the data bus [8-bit], one for control lines [8-bit]), one 74HCT138 decoder (for controlling the clock inputs on the latches) and one 74HCT257 mux (for reading the data from the flash chip, 4 bits at a time).
The lines from the parallel port will have 4.7kOhm pullups and additional 33Ohm series resistors on the 8 data and 1 strobe line (for termination).

If all SGI's had bidirectional parallel ports, the design would have been simpler. Also, for programming just EEPROM's, a different design using a few 74HCT4040 counters would do the job instead.

I don't intend to include a 12V programming mode, since I don't have any chips to test this with.

The voltage regulator, overvoltage protection + fuse will be on a separate board (I plan on reusing it for other projects).
I will include test points for measuring voltage with a DMM or a scope and also a pin header with the addr+data+ctrl lines (for making custom socket adapters or viewing the signals on a logic analyzer).
[/mental core dump]

Now I only need to draw a schematic, order the parts and build it
Does anyone know of any good schematic drawing programs for IRIX?

Thanks, this looks interesting, but I got the impression that it's for designing chips rather than circuit boards

I've done some googling and found xcircuit , which seems to do what I need for now. There's even a slightly older version in Nekoware, I'll give it a try.

You could also try resetting Safari with the "Reset Safari..." option from the Safari menu.

PCB compiles OK with MIPSpro 7.4.4, although only the GTK version, the Motif one looks broken.
I haven't really tried compiling the rest of the gEDA suite, the integration between schematics and PCB design looked a bit clumsy to me.

I currently build all prototypes on perfboards (since they haven't been that complex to need a PCB so far ), so xcircuit should do for now, but I've got some larger projects planned (a Motorola 68HC000-based system and later [much later ] an IDT R3052E-based system [the R3052E is a MIPS-I CPU with MMU]) -- I will look into compiling the entire suite and making a Nekoware package then. Since this is just a hobby, it may take a while to get to that


That would be great
I had a nice 2ch 50MHz scope, but the sweep unit broke down, so I'm having it repaired. I've also recently obtained a nice 80-channel logic analyzer (Tektronix 3001GPX).


Done

What about kicad ? It looks like it has better integration and all the prerequisites are already in Nekoware.


I'll take a look at it either on Wednesday or over the weekend. If it compiles cleanly, I can probably put together a tarball for installation under /opt/geda and a proper Nekoware package sometime later.
If everything goes according to plan, I will test it by drawing the schematics for this parallel port programmer with it.


It can only analyze digital signals, though
A scope is still invaluable for checking for ripple on the power supply lines and odd analog glitches.

I bought it about two weeks ago, I paid less than 180 EUR (including shipping) and it came with manuals, probes/pods, keyboard, software ...
It's even got an RS232 port for connecting it to a computer (then you can either use it as a dumb terminal or for file transfer [e.g. to send collected data to the computer or to receive symbol definitions, etc.]).

Not yet, I intend to compile both kicad and gEDA and then decide which one I like better.


Thanks, that's very kind of you
It looks like I'm going to have to race canavan for this privilege, though


Building digital circuits is fun
The US eBay has lots of logic analyzers to choose from... just make sure you buy one that comes with the pods, as they are often very expensive on their own. The HP/Agilent units have all the documentation available online as well as the operating system software. Tektronix doesn't have that for their older models -- some manuals can be found as PDF scans and some units, like the 1241, have the software in a ROM. I intend to image the floppies that came with my 3001GPX and put them up somewhere (I doubt Tektronix would mind, this device is obsolete in their eyes).


Quite possible
I then researched the various models a bit and decided on either this one or the HP 16500A (with the 100MHz card). This one showed up sooner and it was too good a deal to pass up.


My primary goal is to create a couple of primitive computers from scratch (at least one with a 68k and one with a MIPS CPU I mentioned before), but I've also been thinking of taking up reverse engineering, although I need to get some IC clips/grabbers before I can do that.
Now I can also properly debug the BCM912500A boards I have and find out why they're rebooting at memory initialization.


The schematics should be finished within a week, then I will need about a day to build it and write a sample app which makes patterns on the busses, so I can verify it works. Writing an app that can flash EEPROMs should be simple then, Flash ROMs will take some more time.
I intend to start writing AT29C010A support first, but other chips should be compatible as well, since the flashing procedure is most likely standardized.



I get the same thing when compiling with the legacy configure scripts included in the package -- I will try lowering the optimization level later (although I think that won't help, the error is probably caused by odd syntax -- finding and rewriting the offending line will probably do the trick).

I've also built PCB with the GTK frontend this morning (builds nicely with -Ofast=ip35 and -IPA, seems to run properly) -- should I learn how to make Nekoware packages now, or wait till the rest of the gEDA suite is built, so we can make one large package with all the components?

It looks like it crashes in include/board_item_struct.h, at the closing '};' of the enum Track_Shapes
I pin-pointed it to that location by putting '#warning ...' lines before and after '#include's and structures.
One line above the enum declaration is an include for the boost library, so maybe that has something to do with it.

This looks like a really weird compiler bug, so I'm not sure where to proceed from here (a gcc build perhaps?).

I've focused my attention on compiling gEDA now and I'm currently stuck at libguile 1.8.7, which has an odd error in a switch() statement... I'll see if 1.9.4-alpha is any better (otherwise I'll convert the switch into a series of if-else's).

OK, I'll help out with the porting then and leave the packaging to canavan, since he has more experience with this


I did think of that solution... A bit-shifter based programmer would have been more portable, but probably much slower, whereas a microcontroller based programmer would need to be programmed somehow [most modern ones let you do this via the serial port as well, but you need the software to do it]).


Regarding libguile: I've fixed the problem (only needed a few extra #ifdefs here and there), onward to other prerequisites
Here's the patch:

I usually read (or at least skim through) every new post, haven't seen any spam lately

+1

I agree. Also, there's already a 'ctorrent' in Nekoware -- if it was illegal, it wouldn't be there
NASA, for example, had some really huge satellite imagery of the Earth available for download via torrents.

Porting libtorrent/rtorrent topic split off on request.

There is no excuse for putting .exe at the end of UNIX executable names

This will also return directories and other files which happen to have the executable bit set (e.g. shared libraries, scripts, ...).

This will still return shared libraries and other files with the exec bit set

I considered all these options before posting my version with 'file', which returns only actual executables (and possibly shell scripts, depending on the version of the 'file' program used).

Try replacing '#include <stdint.h>' with '#include <inttypes.h>'.

-12V is most likely only used on the PCI-X slots, for backward compatibility with conventional PCI. Probably none of the PCI-X cards supported in the I-Brick actually use the -12V rail.

I wouldn't run it like this for too long, though. Once you can smell something burning, it's already too late

Sorry, I should have been more specific. Standard PCI slots supply various voltages on different pins.
There's a pin that supplies -12V, along with a few pins for 12V, 5V and 3.3V (see this page for a full pinout).
PCI-X was designed to be backward compatible with the PCI specification, so they kept the -12V pin, even though most modern cards have no use for it. In the past, the -12V rail was used for some communication cards.


If it uses -12V, then yes. But it probably doesn't use -12V
The documentation for the card should list how many amps it draws on the various rails; if that list doesn't include the -12V rail, then the card doesn't use it.


If anything on board used -12V, it would have fried by now, so as far as that goes, it's probably ok
However, it's still possible that the chip responsible for generating -12V might fail completely and cause a short circuit.
It's best to play it safe, I-bricks are still quite expensive and replacing the broken chip could be the cheapest solution, but not if the chip takes something else with it.

Good to see it's working


Connecting the I-brick's NUMAlink cable to the other C-brick should get rid of the "no I/O" error and allow it to boot (you may need to delete /etc/ioconfig.conf and reboot).
Then you can try reseating the CPUs and RAM in the C-brick that's reporting the exception.

Looks OK.


It works just fine, my Origin's I-brick is connected to two C-bricks and it works without any problems.


Yes


It's most likely in there, yes. Try 'printenv' in the command monitor to see all the NVRAM variables.