The collected works of cybercow - Page 2

Is nice to see a forum member taking a piece of a pie ;) Keep the good work!

Well, when my former company tok the "all should go mobile" hype that was spreading around 2009-10, i was forced to jump "into the fire" in less time as possible. The first moment i was introduced (in deep) to Apple technologies was at WWDC10 in SF. I was really amazed of the community that was so pumped up with all that shinny and buzzwordish stuff, jingling around with all those iPhones and iPads and shiny applications ... The thing that shocked me the most was the amazing developer support we got downstairs in the workshops ... From the surface scratching of basics to the most complex stuff like graphics and advanced OpenGL programming for games .... for every geek there was an support person that answered all smart and dumb questions you thrown at them ...

Coming back form WWDC10 and calming down, i was in the moment to write first lines ... in those moments i wish i never sign myself to the mobile department :mrgreen: I had some C and C++ background, but Objective-C was really something new for me. With the help of really extensive help and examples library i was able to go steps up every day and relatively quick.

The thing that bothered me the most was the "manual" idea of memory management. Those retains and releases got me shizling crazy so much i wanted to pull my hair out. You don't own the object don't release it .... or if you take ownership of the object take care to release it properly, those words seems really easy to understand on paper, but when you do it in practice and without experience you can end with an really ugly and nice memory leaking piece of code :)

I was so afraid that my app will crash, umm not crash .... that the phone will explode ... i ran Instruments after every few lines of code i wrote, to see if i had memory leaks. That was scary, tedious and somewhat weird experience.

The two most important things concerning generic Objective-C concepts, that i learned at WWDC was, 1. Use the (Cocoa) frameworks, like Apple said - we built those frameworks for you (and obviously from a team of top-end coders), so don't reinvent the wheel 2. Don't extend everything and with this statement go to the point 1. That helped me a bit, and after some time of adaptation i was able to do something useful with all this nice development ecosystem ...

Image Image Image
... and take care that if you preffer thinkering with IRIX in late / night hours - which has a special magic attraction at least for me, powering on anything bigger than an Indy / O2 will / can produce strange reactions on your housemates faces, varyng from simple and innocent arguing up to total and delibered anti-you revolution :)
@Nyebodnye just watching your signature, with all those Max Impact's, and all those TRAM's there's no fear of having cold next Winter, just saying :idea: :mrgreen:
Image Image Image
Quite surprisingly no one mentioned the real classic , i think i spent many hours, days and nights flying above flat shaded grounds, quite rudimental, real retro slam back, but fun == endless.. any standard Irix instalation includes it, watch for the demos app group.

Then you have CertainImpact, WWII or I? planes simulation, it can be found on Indigo2 Impact demo cd. Find my channel on youtube, some time ago i did a short clip of it.

Then somewhere down the road i catched up also a F-18 demo, you could fly and fire rockets, but no cockpit view, only arcade - like outside view. Also had a clip of it, but can`t really remember where i digged the installation.

Then if memory serves me right i`m 99% sure i saw also A-10 flight sim on Irix running somewhere, some long time ago.

As for cars You have those boxed fun ones running as Inventor game demos :)
This is quite interesting topic, and quite intesting question. I'm intersted also in emulating sgi mips/irix, and when i have time i'm doing a lot of research and learning about from the available documentation and existing projects.

If you take for example one simple scale from 1 - 1000, where 1 is the first step in the process of writing some immaginary sgi/irix emulator, and step 1000 is a fully functional one, where all functionalities that you are emulating are working like expected 99% of the time - the moment when you will start to concern about the amount of available RAM - will possibly be - step 1001.

Then, if step 1 is today, make the step 1000, five to ten years later in time, and even that is optimistic. When you will be starting with the immaginary step 1001, you should have learned already everything about MC1 - the heart of Indigo/Indy class machine, demuxes, gio bus, dma and interrupt mappings and maskings. .. and so on and so on. .. that task with that knowledge in that time scale will take possibly few months.

One interesting trivia for the end... from the moment you press the power button of your favoured sgi machine to the moment you see the login screen, there are aprox. half billion (500 000 000) instructions executed this to happen :) and there you are, only at the doors of the endless irix univerese. ..
Sorry for my ignorance if somebody already mentioned, but there is neko-qcad right there for download, nekoware version of QCad, it is quite fine to work with, i did my house electrical installation project redoux with it and it clapped well on indigo2. Is 2D only.
I work with both mercurial and git, they're almost the same from user perspective, for eg. I miss something like git stash on hg, for those nice moments when you screw all things up, and reseting to head would make them even worse.
Image Image Image
Being late to the cooler party. There are several versions of the Indy R5000 180Mhz SC module. I don't know the exact serials, but you will know the difference in general by looking the edge of the aluminium cooler box. If it has a fan - or is supposed to have one - the cooler is shorter and it doesn't fit the cpu area. If you look at it from top, the cooler is inset at least few mm and the edge of the cpu is clearly visible. If you have the non-fan version (like i do) the aluminium box fits the whole cpu area - or even overlaps it, and in general the aluminium box is a bit higher than the actively cooled box. Strange enough, both versions have the 2 pin fan headers (or only vias) - so possibly even the passive version can be retrofitted to drive a small fan.....
mapesdhs wrote: I don't aim them at hobbyists. ;) I currently act as support for a couple of airforce training setups where they're still used.

Pity it isn't possible to respin the tech in a modern shrunk process, stick it on a single chip card (but with the same I/O ports), allow
for Max + many options. Oh well.


Well clever though Ian. If ever, one could start with XL24 Newport, the hardware spec was more or less documemted and released for the linux world. It would be great to have even XL24 on a chip. Then ramp up with solid to max, a hell of a task. The other way would be possibly to translate GIO64 to sometihng else eg. PCI, then stick in your 10 years old nvidia ge-force and make a driver for it. The GIO64 spec was also published, but it takes a lot of aspirines to go through, i did n-time tries, but then eventually i gave up and switched on real beer, it has a better taste than the first medicine.
If you still need texturing, and you picked the Indigo2 as your choice, maybe High Impact will do, not as fast as max but still faster than solid, and can do texturing, should be budget friendlier than max, generates less heat, eats less power.
Interesting reading, i support the idea to at least barely get the power up and shutdown sequence and signals that control those procedures. My long term plan is to completely remove the old psu and put something brand new inside, although modern ATX psu's are more larger and would'n fit inside original Indigo2 casing. I investigated a bit and found new switching dc-dc step down converters from Intersil that can give needed current and voltage (solely or in bridge mode): ... dules.html

The problem with new ATX psu's is that they are putting more or less all the current in the 12V lanes, so comparing it eg. to Indigo2 impact psu that is 385W total power, one should use at least 850W modern ATX psu to get same amperage distributed (with step-down), which is not ideal from energy efficiency perspective. There are ATX 2.0 psu's that put more power in lower voltage lanes but even those require modifying output to fit Indigo2 voltages.

This is the sticker from my impact psu that died time ago, it's the newer version 060-8002-001 but not meant for dual head. Intersting enough, aside the really non standard 3.5V they needed also those darned -5V for god knows why :D
Great to know, your psu model is dual head, and according to the serial, the latest one they produced. Regarding to this: ... 01-001.pdf , one can have: Solid/Solid, Solid/High, and Solid/Maximum combination in dual head config, so i'making an dumb assumption they allocated 12 amps for the extra Solid gfx. Which again dumb guess, you can drive 2 x Solids with the less powerfull psu, possibly. So if the power eating of an Solid is ~12A, Maximum can go up to 36A, then High should be something in between like 24A, but i will measure this precisely when i start with this mod.
Ok, yesterday i had that eureka moment, after taking some time to think about some other forum posts related to other stuff, that lead me in some other mind flow direction. I don't know if this is just right but i did some conceptual analysis that could proof to be one step closer to make GIO to PCI interface. And here is my concept i did roll out just philosophically:

Phobos G100 and Phobos G130 (also G160 for I2) have at their core in fact PCI nic ic's from Digital/Intel that interface to GIO with altera ASIC's that connect to GIO bus directly. The function of altera ASIC's is to modify GIO signals to PCI logic signals, so the GIO <--> PCI interface is in fact already in there on every G100 / G130 / G160 card.

The G100 has pure PCI nic from Digital, whereas the G130 has the Intel nic that is PCI/CardBus. Both PCI interfaces are revision 2.1 which is the older PCI specification but still usable.

As i have few spare G100 cards, i would take one, desolder the network nic from it, desolder all un-needed network peripherals on the nic front-end, pull out all the nic chip pins with flat cables to custom testing board on top of it, isolate the PCI signals, solder an PCI connector, ultimately stick in some low power PCI 2.1 card eg. lan card to start with, to see if i can reach it. The hardware identification for G cards is probably stored in the altera asic, so the hardware signature will stay like that for now.

Sure this would not be a real PCI bridge with all the bells and whistles, but 1 - 1 interface, so only 1 pci card possible, with custom driver jingling, but still for some experimenting maybe more than enough.

Those would be preliminary steps, what do you guys think about this ?
ivelegacy wrote:
cybercow wrote: what do you guys think about this ?

interesting :D

here I have to play with PCI 5v @33Mhz on an Atlas board for job purposes, firmware fun, but I am planning to attach a pci-fpga board, and when I will be skilled enough It may be I will think about the Shoehorn in order to provide a few new peripherals to Octane :D

Well Ivelegacy, you're a pro :) , regarding electronics i'm just a hobbyist trying to have some fun :)

miod wrote: There's a risk that not all PCI address lines are wired, since the board was designed with the DEC chip in mind. So not all PCI devices would work.

Also, the FPGA chip might have some GIO addresses hardcoded, and would not allow more than one PCI BAR to be set (the BAR being probably initialized by the FPGA upon powerup).

Last but not least, the FPGA probably handles bus timing for DMA operations, and might not work correctly if DMA transfers from another PCI device are larger than a particular limit, or cross specific alignment boundaries.

Really appreciating your thoughts and infos. Will try to catch the problems along the way, hopefully to get some help from you experts here. All the worse that can come up is one burned Indy and a ruined G100 :)

Ok, here is the pinout of the DEC nic found in a G100. I did a quick sketchup with colored legend. From the required group everything is there, besides i'm still not sure what to do with the interrupt (int_l) pin, the PCI interface should have INT#A, INT#B, INT#C, INT#D, though they resides on the optional group. Also there is missing LOCK# signal for locked transaction also from the optional group. Still to see if everything required is wired up on the pcb.
Actually, time ago i did swapped my low end Octane2 for an 1040 STFM, octane did seat around unused and was collecting dust, now i have much more fun (also) with the Atari (the octane gone to a good collector home). Casually playing some old games (immense fun), then attached to my Korg M1 with cubase (my primary goal), gives me that 90's atmosphere i just need :D Wouldn't give away my Indigo2 and Indy for anything though.