The collected works of dexter1 - Page 11

We're fine, but with grey beards, grown up kids and a bit more fat around the waist.

I have finished the dual neko_openssl and neko_openssh packages. Sorry for taking so long, but life got in the way and i probably made every packaging mistake i could make: especially the neko_openssh helper scripts needed testing and updating. And i included the compile fix for the elliptic curve bug i found previously.

openssl: http://www.nekochan.net/nekoware/dual-m ... 2l.tardist
openssh: http://www.nekochan.net/nekoware/dual-m ... p1.tardist
You also need zlib: http://www.nekochan.net/nekoware/dual-m ... .8.tardist

This way i can finally get rid of the ancient IRIX openssh and openssl packages.

Be warned that openssh defaults have changed significantly:

- There is no more support for ssh1 and rsa1

- ssh-dss keys are deprecated and access with these keys will be refused by the sshd server. If you have such a key you can re-enable it in sshd_config with
- By default, root will not be able to login. If this is required, change to in sshd_config

- UseDNS is set to no to solve delays coming from name resolves. This can cause problems if public-key entries in ~/.ssh/authorized_keys with 'from=' fields have a dns name. Switch to ip-addresses seems to quick-fix this.

Happy ssh'ing and let me know if there are any problems. So far, X11 and agent forwarding and sftp server usage seems to be working.

There also is one hint in the manual page of 'mipscheck':

Irinikus wrote: The R8000 seems to be an interesting chip!

Except that it is not actually a chip but a processor board with two MIPS CPU's, cache and glue logic. Have a look at

That is a picture of an actual R8000 processor board.

I would seriously like to have a system with one installed someday.

Well, an R8000 certainly isn't a boring system and they can be a bit temperamental. Also they are rare: You find them only in Indigo2 systems (IP26) and Onyx/Challenge (IP21) desksides and rackmounts. The prefix "Power" is commonly used for these systems.

Irinikus wrote: If I manage get it, I will install it in an Indigo2 Impact machine, when I eventually acquire one.

Alas, you cannot "sidegrade" an R10000 Indigo2 Impact (IP28 motherboard), or an R4400 Indigo2 (IP22 motherboard) for that matter, with an R8000 CPU-card. The motherboard must be an IP26 a.k.a. "Teuton" and its PROM revisions only support pre-Impact graphics such as Newport(XL) and Express(XZ/Extreme)

Irinikus wrote: I suppose that I can install the motherboard and CPU my current Indigo2 then.

Yes and that's pretty much it. The Power Supply is relatively interchangeable between R4K systems and R8K, see http://www.oocities.org/siliconvalley/h ... upply.html

The rest can be swapped over from the R4K Indigo2. Don't forget to handle the R8000 CPU carefully, since it's sensitive to static discharge. Oh and make sure you secure the R8000 CPU correctly on the motherboard with all screws in place, since the standoffs provide power and ground to the module, see viewtopic.php?f=14&t=16726745&p=7351542&hilit=miod+r8000#p7351542

khalidschofield wrote: Anyway install CPAN worked. My SSL module won't build probably because SSL is broken on the box.

I've revisited this problem today since we have proper openssl alternatives now:
Brent Canavan and i have made new packages for neko_openssl and i could successfully build Net-SSLeay-1.81 aka Net::SSLeay as a prerequisite for IO::Socket::SSL

CPAN module is really backwards when it comes to building modules from C libraries installed on the system, because the inclusion of nonstandard header and library location is apparently not standardized in itself and depends on how people have coded it inside Makefile.PL
I also have the feeling that the CPAN module and its shell does not incorporate environments from the parent tcsh or ksh. I tried all sorts of things like CPATH, CFLAGS, --incpath, -I, INC="-I<path" and whatnot.

So i pulled the sources and compiled it manually via this recipe:


With "gmake install" as root it should put the module into the site specific portion of nekoware perl

I'm not sure if you still need this, but i think it's good for some folks who have this problem in the future.

Now, back to Python!

Wow, excellent Work!

This looks like it's on par with the emulation in MAME. You have confirmed my assessment of Qemu as the best platform to start this project. MAME is old school C and too dense with macros to develop fruitfully. Folkerts MIEP, another emulator, has some interesting code and a MIPS3 engine from scratch, see https://github.com/flok99/miep and https://www.vanheusden.com/miep/

SCSI emulation of the wd33c93 can be problematic, but i believe the amiga 3000 has relatively complete wd33c93 support, see http://eab.abime.net/showthread.php?t=67211&page=2
I am planning to look at their code. Apparently scatter-gather doesn't work in the MAME driver but is functional in theirs.

So the image is from an indy? I gather you haven't implemented a framebuffer and REX3 support since that would explain why it fails to find a video device.
I have other images available, i can probably also make a 6.2 Indy image and a 6.5 Challenge S image, once my second SCSI2SD has arrived.

As for DMA, i assume you have programmed DMA either in a separate thread, or you are performing 'atomic', i.e. one byte, transfer per cycle in a function called from the main emulation cycle.
Do make sure you correctly identify that some DMA registers are being copied upon initialisation and start of the DMA transfer. I've told this to Folkert and that part of the code is correct, but he got the DMA initialisation unfortunately wrong.
I have some DMA transfer code which i can show you that fixes the init .Let me know if you want to see it.
As soon as time permits i'll be revisiting indy emulation, which will be somewhere next month.

Do you have a github repo of your code by any chance?

jaggies wrote: I don't have any graphics at this point. The priority is IRIX, then networking. Once I have networking working, it should be fairly straight forward to do remote-display until I figure out the graphics hardware.

The Seeq8003 network interface with the GIO bus is handled by the HPC3 along with the PBUS and the SCSI channel(s). It looks like there are code examples on the net describing the interface to it, but emulation might be nontrivial.

Because documentation on the graphics engine is sparse, I think direct hardware emulation will never happen in a meaningful way.

Oh, i beg to differ. The documentation of the Indy at https://www.linux-mips.org/wiki/IP22 is quite complete. All the custom onboard and Newport ASICS, except the HAL2 sound chip and the VINO video module, is well documented via released internal documents from SGI engineers themselves.
The main Newport graphics interface with the GIO bus is the Raster Engine chip REX3 and is documented at ftp://ftp.linux-mips.org/pub/linux/mips ... y/rex3.pdf
You will find the rest of the Newport graphics components on that site as well.

I found a bug in my DMA code over the weekend where, as you suggest, the registers need to be preserved across transfers. If you assume the hardware does the simplest thing (leaving the registers untouched), it's usually right But software needs to actively preserve them. In this case the current count needs to be preserved across invocations.

Yes, a DMA transfer is time-limited to a number of GIO bus cycles. It will stop at certain intervals to allow the MC3 and CPU to handle interrupts. The DMA engine can even issue interrupts on its own when it encounters a problem.

Looks like IRIX will set up the full DMA chain (say a 256kB block) and then do two 128kB transfers. Ordinarily, the hardware would just handle this since the wd33c93 would stop once each transfer is complete. Initiating a second transfer presumably lets the DMA continue. It's kind of hard to tell based on looking at my logs.

This could actually be the result of the DMA engine being time-limited and returning GIO bus control to the MC3 after a certain time, handle interrupts (probably from the wd33c93 or network or PBUS), and resume DMA transfer again.

I haven't uploaded this to github yet because the code is in pretty rough shape. I'm patching a rather old version of QEMU (2014) and the code is quite messy at this stage. First step is to understand what's going on.

There are many people knowledgeable about the innards of an Indy on this forum and we're still running IRIX on these systems on a daily basis. So ask anything and don't hesitate to call for help.

I found the NetBSD source quite handy for understanding the hardware. They seem to know at least a few of the hardware tricks.

The linux port of the Indy in 2.6 kernel is also pretty good. They have drivers for the analog part of the indy sound chip i haven't seen elsewhere.