Older blog entries for Svartalf (starting at number 16)

Ahh... Someone IS listening afterall... A friend from a previous job put me in touch with his employer as a possible candidate for future openings there- made my day. If you DO know of a job where they could use a developer of embedded systems, device drivers, etc. please send them my way.

On other topics, new year, a setback, some new progress. I had bits and peices of code in place for the DMA portions of the RagePRO DRI driver for a while now, but nothing concrete and usable- I'm finding a little more time now and I expect to be pushing a CVS update in the RagePRO branch shortly (Hopefully within the next week or so if things keep up the way they have been...). Also of note is the design specs becoming available for the Ronja IR wireless link. Either unit could well be a good modulation scheme, etc. for the IR subsystem for Tux-Tag and I'm evaluating the possible use of either the Metripolitan or Loopipe versions right now. In any case, that's moving forward again as well.

That'd be the progress...now, for the setback...

NBCI, formerly known as XOOM, for some inexplicable reason chose to discontinue their free hosting service (I understand this part) but didn't tell anyone about the change. While it wasn't much, I would like to have had the opportunity to change the content over (I had my online copy of my resume there amongst other things- it'd been nice for me to have had some warning...)- but, alas, they had other ideas for all of this. So, for right now (and maybe indefinitely) it's housed at svartalf.freeshell.org- not too bad once you either get ZMODEM working over telnet (I had to use Virtmodem under Linux- nice little application by the way...) or pay them the one-time fee of $38US for standard FTP, etc. access to the shell account. There is a $1 fee to authenticate the basic shell access (because some twit used the site to attack others with...) but that's okay- $1 for 100Mb isn't a bad deal and I plan on giving them more per year to ensure continued operation.

[This blog entry has been deleted for personal and business reasons- be CAREFUL of what you blog, as it can be embarassing or cause problems down the line... :) ]

Progress in some areas and setbacks in others. We've gotten ATI to give access to the key players interested in working on the RagePRO driver and we've figured out what was breaking us (The 2D driver init was setting something that wasn't set in the 3.3.X drivers and was causing some off behaviors with DMA support)- so we're moving ahead with work. Manuel and Leif are working on the 2D locking and Mesa end of things while I clean up and finish the DMA implementation. I've got my build environment finally working mostly like it is supposed to be so I should be getting done with that in a week or so- so long as the distractions that are going on in my life don't cause problems. I've got work problems again- my current employer's going to be past due on wages for a month and a half as of Wednesday at midnight. Anyone know of a place that needs a senior software engineer?

I'm in a quandry- perhaps someone reading this entry can offer advice... Several individuals, myself included, are attempting to make DRI drivers for the ATI RagePRO chipset. Of them, I think I am the only one with the information to make it happen, and while I'm not under an NDA, per se, I have not been given permission to grant access to the technical data. ATI is being bull-headed where once they were nice to us- they're not giving any further access to the tech data to anyone that doesn't already have it. So, what do I do? Worse, I find out that XFree86, Inc. has made several NDA deals to get the information needed to make their drivers possible- and you have to have submitted several patches or something similar to be admitted as a member of the XFree86 project.

I find this to be more than mildly disturbing. It turns the project into nothing more than a free ride for the hardware vendors- they get drivers that they would have to do themselves (which they wouldn't have- they only have budget for Windows) and reap the benefits of the free labor.

Again, what do I do? Do I put the gory details of this up on Advogato, LinuxToday, or Slashdot? I don't know for sure- my gut level instincts is to let someone know all of the goings on for what they are; but I don't want to start another stupid flame-fest like the recent blowups with the GNOME and KDE teams.

Well, it's update time again.

I've gotten my parts in for the ELJ competition (New toys- always fun!) and I'm working on getting a decent intro to Tux-tag going on my homepages (Eventually, as the project goes on, I'll be looking at getting the project migrated over to SourceForge.)...

For those that do not know what I'm talking about, I entered a proposal for an open-sourced, scalable laser tag system (A system similar to the offerings of DarkLight, etc.- something that could be used to produce a Photon arena/game.). Simple system, but then, many embedded systems ARE simple.

As for the idea, I "blame" Howard Tayler of Schlock Mercenary fame for unkowingly putting me on this wild tangent. I was chit-chatting with him on the Schlock Mercenary strip's discussion area on KeenSpot (If you like net-comics or are curious about the net-published variety of comic strips, go hit KeenSpot you'll not be disapointed!) about...er...strategies...yeah, that's it, strategies... (Hint: you want either of us on your team, not your opponents... :-) for gameplay in laser tag arenas and afterwards I did a skimming of the systems and decided all but DarkLight was lacking in many ways and DarkLight didn't make the cut compared the the relatively primitive (Technology-wise, not gameplay, etc...) Photon, the original laser tag game, in game play, etc. So, I decided to enter the idea as a proposal (It was something I could do, do it in my spare time fairly easily, and something that I could peddle all over the place if I really wanted to.) and the rest is now history.

The premise behind the idea is to make laser tag systems to be composed of lego-like blocks of functionality to make it at least a little easier to build a good arena and set up an excellent theme for the game, etc. So many of the systems just don't allow for creative license, etc. in a game system- I want to give that to people and not keep them at ransom to do it.

On other fronts, I found out a little more about the RagePRO stuff. Busmastering seems to work fine for all the Mesa demo apps but gears and morph3d. (The problem I mention is liable to still be there for some models of PPC machines and it DOES exist for Alphas. Sorry gang, you're going to have to wait for DRI to be completed for those architechtures...) The problem seems to be a translation operation one as it's the rotation of the blue gear in gears that causes the hangs on my machine. You're welcome to try the current code- it's definitely alpha level code on PPC machines and I won't guarantee it to not melt down your hard drive, hang your Mac hard, etc. If you do brave the CVS version out there, do please let me know what the results are for any and all the apps you run so I've got a map of the gotchas- I may be able to fix them for Utah-GLX, I should be able to avoid them in the DRI driver in progress.

Well, well...

Who'd have thought that I'd win a finalist position in ELJ's contest- guess I'll have to start doing the actual work (I've a goodly amount of design work stashed in my head :-) since I just got the prize pack yesterday.

What was my proposal? Tux-tag, a scalable, open-source, open-design laser tag system.

Coming in the next day or so, the start of an official project page for Tux-tag.

Ok, I found out why the RagePRO support doesn't work right for PsuedoDMA and hangs under DMA under PPC and Alpha.

The hack that John Carmack did to get at Physical memory addresses to hand to the card for bus mastering will only work under the x86 architechture (where physical address== bus address).

Under PPC, Alpha, and others, this is not going to be guaranteed to be the case (in fact, it's guaranteed on those two platforms to be off by quite a bit!). PPC seems to work fine so long as you don't go past one descriptor. In fact, DMA "works" for any of the Mesa demos so long as it's not gears or morph3d. Texturing for those demos is toast though (because of similar problems with our assumptions) and doesn't work (times out!) for PDMA operation.

Looks like I'm going to need to work up at least a DMA helper app or a full-blown low-level driver for the RagePRO to get it there (And I do plan on doing one or the other, with leanings to the full-blown module. I think I can make it fairly secure to the point that it won't out-and-out hang a machine if someone actually managed to hook to the driver that wasn't the Utah-GLX front-end.) Work on that will begin this week-end, hopefully.

On other items in a similar vein... Utah-GLX does not do as well for some games (perish the thought...). It doesn't render right in Heretic II with the Matrox cards and it doesn't do some things right for both Matrox and RagePRO on things like Rune. If you run in software mode, the images from the game should be dog-slow but correct, just the same- it mangles the scene rendering in software only mode. I'm working on determining what gives in that regard, it's likely to be something in the GLX layer somewhere that makes some things go bogus with the G200/G400 and not the RagePRO for most things. Hopefully, I'll find an easy fix...

Which leads to the last item. Utah-GLX has several problems and bottlenecks that will take large amounts of time to fix right. It's a good make-do, but it's not where the future work needs to be. Therefore, I plan, in a couple of weeks, of halting all regular work on maintenance on Utah. I will, however, address serious, crash type bugs (such as the cross-platform stuff just not working right) for some time to come- fixes may take a while though as I will have to switch gears from doing DRI related work as they're totally different in many ways.

Arrgh... Got the G3 up.

Took 3 attempts to get it right. (And I still can't use it to do work- SuSE, in their infinite wisdom appear to have SaX updating the XFree86 config files every time that the machine comes up under runmode 3 (xdm/kdm...). This is rather annoying , to say the least, because I have to add a Module section to the config file for Utah to work.)



Anyhow, last week I've cleaned a few issues with the MGA side of UtahGLX (with plans for zooming a few more issues there and on RagePRO, before moving to DRI.)- there should be no more texture "oops" issues as I've axed the MMX "optimizations" in the pathway (the source for the optimizations is still there, it's just rather broken (doesn't work right under all cases- and can't easily be fixed to do so without throwing away the slim advantage this code has over the raw C code that does the same work...). This translates into being able to expect correct rendering on games like Heretic II (Where it would just hang (cntl-alt-bksp got you out...) on the intro animations. and if you managed to get past that, it would muck up some of the textures.). Those of you out there with G200 or G400 cards ought to give the new CVS and some of the games out there a whirl- they're working a lot better now (Though I'm sure there's still some gotchas- be aware of that!).

On a different subject, I read in the SourceForge bugbase that someone actually got the RagePRO working on an Alpha. Can't confirm that (does anyone care to loan me an Alpha machine to fiddle with this, like John C. did with the G3?) so if someone wants to brave the attempt, let the list know what the results were.

Picked up a loaner PPC machine for RagePRO work last night.

I'd like to thank John Carmack for the loan (If you've got an Intel Linux box, you might want to thank him for his help given to the Linux community (And, if you don't think he's helped- I sure didn't get the RagePRO code there, I'm just fixing and extending it!) by buying the Linux version of QuakeIII from Loki or one of the MacMillian distributed copies of Quake I or II... I'm fragbait, but I still went out of my way to get Quake III.).

I've not got it up and running right at the moment as it's got MacOS X Server running on it and I've no accounts on it- one observation, OS X is agonizingly slow booting on this machine. Something like 3-4 minutes until it comes up to the login prompt (and it's NOT a slow PPC machine...). I'm scraping up a copy of MacOS 8 or 9 for the machine so I can use BootX (It's one of the beige G3 towers...) but I've got the machine and in a week or so, I should have the thing up and shortly thereafter I should be about trying to confirm PPC DMA operation with the RagePRO and if so, why we got slower results (By about 40-60% slower than it ought to have been...) on the rendering in gears.

I've got rumors from a good source that if we have stable, fast GL support for PPC that we'd see PPC versions of many of the GL based games from Loki (it's been the lack of driver support that's been killing the PPC and Alpha versions...)- so if you can help out by braving downloading the latest Utah-GLX CVS repository and installing it on your PPC machines, it'd be welcome (Besides, shortly, I'm going to need, guinea...er...beta testers...yeah, that's right, beta testers. :-)

Got the VSBC6 code into the CVS repository on SourceForge- go and get it...