Older blog entries for Svartalf (starting at number 28)

28 Sep 2003 (updated 22 Jul 2004 at 21:00 UTC) »
DRI Project

Still having fun trying to make a working PPC version of the modules, etc. from the CVS to help Mike Phillips test the PPC version of Soul Ride.

Ballistics

It's READY for beta testing. We're picking testers right now. If you've got a PII-350 or better with at least a Radeon or GeForce card, pop on over to Linux Game Publishing and sign up to be a beta tester and register for this game's test. (Especially if you've got a Radeon or if you've got a routable IP address to be able to host multiplayer sessions over the Internet.). Pre-orders with ANY reseller will be given a beta slot automagically upon notification and proof thereof.

Right now, I'm working on trying to make a PPC version happen (Minimum requirements are shaping up to be G4, Radeon, etc.)- it's compiling cleanly, but not entirely happy w/me. Some endian-ness probably missed when we made the pass through the code to make it compile correctly for PPC.

As a consequence of my experience with OpenPlay, we (Linux Game Publishing) are probably going to champion a fork of the codebase in question, as while the Darwin project has kindly hosted the CVS, they don't seem to be willing to take on anyone to manage OpenPlay and don't seem to be interested in accepting patches from anyone(There's several patches, LGP's included, that fix broken Linux support, bring some nice functionalities that are present in DirectPlay (that end up making OpenPlay largely better than the same...) that they just won't check up on and integrate in the source tree.). Either that, or we're going to modernize Dan Kegel's ANet (also known as Activision's ActiveNet) library and move foward with it. OpenPlay's more "ideal" once it's cleaned up some because it's in use by developers. ANet's attractive because it works (although a bit tough to use) and powered no less than 20 games, some of which were on Linux courtesy of Loki in it's heyday- but it's long in the tooth, so to speak, and it sort of shows right at the moment. Another upshot of the ANet code is that there's lobby/tracker server code that works cross-platform already in hand. With OpenPlay, we'd have our work in that regard cut out for us.

Disciples 2

What? Another project? Doesn't he have enough? Well, I'm stalled on quite a few of the ones I already have- too many distractions in my life right now that disquiet the mind, lack of funds to carry things forward at all, and so forth... The work I'm doing for LGP that I've done up to this point has the best potential for a financial and career payoff of all the projects I've got on my plate and actually seems to be clearing my thoughts up some. So, when they offered me the opportunity to help work to get Disciples 2 finished while we're in beta with Ballistics I was interested and accepted the responsibility of Lead Developer for the port. So far, nothing more to report on that front as I'm setting up to be able to work on the project right now.
30 Jul 2003 (updated 22 Jul 2004 at 20:57 UTC) »

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

Tux-Tag:

The chip I thought was going to work isn't suitable to task because it's not really a modulator (which is what they claimed it was...)- I didn't get a schematic worked up for the pack link with it like I promised in the last entry. However, I did come up with a simple ASK modulated scheme (400kHz carrier) that uses very few parts- while it's peak data rate is something like 2400 baud, it's more than adequate because you don't need more than an 8-bit stream for most of the game variations (8-bits provides some error correction and allows for up to 64 players on a team...) at 300 baud, the data format and rate for the original Photon system gun packs. At 300 baud, you have an atomic sample rate just under 3/10ths of a second. For the same data format, 2400 baud provides a responsiveness of 7/100ths of a second. The original Photon design was a little laggy- but for the most part, you didn't notice it in game play.

Right now, I can't test my design properly- and I can't afford to buy the few parts that I need to do so. I'm not going to just place the schematics up unless they're verified as working. Yes, I know I've been promising this for some time. For that, I apologize- I've been under a little stress for the past two years which has been a very constant distraction for me. As soon as I can assemble a test rig, I promise I'll get schematics up and event handling code for the basic framework of the system.


Utah-GLX:

I came up with a patch for Mach64 DMA support, unfortunately, I hadn't the time or the setup to properly integrate and test the code- nor has anyone currently working in the project gotten around to doing it either. Currently, they're in the middle of a re-work to support the latest Mesa version, etc. I've just about gotten a setup back up and running for doing the work to the glx-xf4 branch so that people will at least have SOMETHING to use (And, so I can do a comparison between the performance of the current Utah-GLX version and the still in CVS version of the DRI driver for Mach64...). However, since my time is currently devoted mostly to finding a job and trying to get Ballistics done so we can go to beta with it, it may be a bit before this actually happens.


DRI Project

Having fun trying to make a working PPC version of the modules, etc. from the CVS to help Mike Phillips test the PPC version of Soul Ride that is about to be released- nice little product. On a slightly different subject, I've gotten all my chipset documentation from out of storage and I examined the details on how the SiS 6326 and Trident Cyberblade are programmed for 3D. While neither of them are stellar performers, they should be able to do some of the older titles, etc. and there's no reason why we shouldn't have support in DRI. No guarantees (as I said earlier, my time's a little overbooked right now...) but I should be starting on a little something shortly- if only in the hopes of maybe attracting a little bit of recruiting attention my way from NVidia, ATI, 3DLabs, or Tungsten Graphics.


Intelogis Passport

Sidelined for now. I intend on re-working the driver code to work with the 2.4.X printer device framework proper and to provide a 2.6.X driver- but it's going to be a while as it's not high priority. Anyone that has problems with the current iteration for 2.4.X should contact me with what's wrong with the driver.


Ballistics

Yes, I know this isn't an Open Source project. However, because I don't have a .plan somewhere right now (and I am using and extending FOSS to make it happen...) I'm going to keep putting updates here for now. Anyhow, Ballistics is coming along nicely- many of the pieces are in place and when we turn off the debugging aids, it runs smooth as glass. We don't know when the Beta is going to be starting- there's still some things outstanding that need to be resolved (like network support being ported and tuned- my task of the next couple of weeks...) so it's going to be a little while longer yet.

7 May 2003 (updated 7 May 2003 at 05:02 UTC) »
Tux-Tag:

Found some components that will help out with the IR subsystem design. I'm working out schematics right now. Hopefully, I'll come up with something usable that is useful for more than just a pack to pack link. On a side note, what I've seen of IRDA's specs, it's amazingly thin- no apparent modulation to prevent IR trash from confusing things. I guess that's "okay" for the proximity that you're supposed to be operating the devices at- I'd feel better about something a little more robust (I mean, remotes at least use 36-38kHz ASK modulation...)
6 May 2003 (updated 6 May 2003 at 06:04 UTC) »

Plugged in the code for the DMA fix for RagePRO chips under Utah-GLX. Compiles fine on my main machine. Unfortunately, the machine with the RagePRO is at the house and I was down at the In-laws' house. I plan on testing the code tomorrow sometime and if it passes muster, I'm going to push it up to the CVS repository.



Went digging in the storage space for my copy of the Trident info- didn't find it. Having over half of your house packed up just sucks. If it's not somewhere in the house, I guess I'll re-download the info from my source (VIA...) and print off the pertinent pages since it's only something like 10-20 pages worth of info. On first blush, the CyberBlade is not unlike the Voodoo 3 in the way it's used. MMIO with a RAM based FIFO to handle the overflow when the chip's main FIFO is full. (The SiS 6328 was programmed the same way- if it weren't for my not having one of those anymore I'd be working on that one too...)

What possesses sites to insist on using broken Javascript, etc.? FlipDog is a jobhunt site that went to a Javascripted engine framework for placing job searches. The problem is, when you go to the site with Mozilla comes up with the following:

*** NOTICE *** This site contains programming that requires a different version of your Netscape browser. FlipDog.com currently supports Netscape 4 (versions 4.07 to 4.79).
What is this junk ? Netscape 4 of all things- that's so old and unused as to be worthless.

Money, money, money... Supposed to see some funds by the end of the week. Not the funding round- just some funds to prop us all up until the funding round actually begins (which is purportedly still on track- we'll see...). I can only hope.
2 May 2003 (updated 6 May 2003 at 05:33 UTC) »

Just now looking at the work needed for the DMA patch for Utah-GLX. It's actually rather simple (a one-liner in the right place...)- I should have something worked up shortly. Once I've done that, I think that sometime next week I'll go over to the storage space, dig out my Trident documentation and maybe start the work on a possible DRI type driver for my laptop. I've got very little better to do right at the moment- and while it won't put money in my pocket, it might get me noticed again and it'll definitely help get my mind off of my woes.

I was skimming the phazzar discussion list (Phazzar is another attempt to make a next generation Photon system...) and read an article from a fairly reliable source that the original Photon system used a 300 baud IR system initially and then a 1200 baud system. This translates into a single byte code (probably w/parity to do a little error checking) for the individual pack. I was going for overkill (part of the reason for the delay on Tux-Tag was that I was looking for high-speed IR operation, the higher, the better.) when I really ought to have been gunning for dead simple. Given that this is the case, I could make a case for the most bog-simple emitter/detector design and expect it to work like a gem. I also found out that the central computer would poll periodically for scoring info from the pack- apparently, the packs would hold onto who was "hit" by the gun and upload the bad news to the central server, which would then tell the packs in question that they'd been hit and to act accordingly. I think I can do better on both counts (I ought to be able to do better- it's amazing how primitive these systems actually are...) and do it pretty economically. I hope to be drawing up plans for the gun, pack emitters, etc. shortly and start into coding- again, like the almost dead website says, no promises- yet.

Nothing is really happening on the Ballistics front right now- worrying more about some of my Open Source projects. I looked at the sound code and might have some traction on that front shortly. If I do, I'll have something to demo at the presentation I plan on giving to NTLUG in the near future.

Again, there's been some delays, as you can see. I don't have much to blame the delays for my projects on other than my state of mind brought about by me still not finding a job elsewhere and my current so-called employer's still not having any money to pay me with. Yes, you read that quite right. No money so far as I can tell. The current story now from the VC is May 9th. Supposedly it's a done deal at this point and it's just a matter of logistics- somehow, I don't believe them anymore unless I see it. If we don't see some money real quick all my jockying to keep everything is going to be for naught and I'm going to end up in a worse position than I would have been in had I not tried to fight to keep the house, etc.

Do you know of anyone with an open software engineering position? Why don't you send them my resume for review. I'm really good with system level apps, network apps, device drivers, and general consumer apps- on both Windows and Linux. I promise I won't get in anybodys way (much...).

22 Apr 2003 (updated 22 Apr 2003 at 03:56 UTC) »

Wow...I'm putting an actual regular diary entry in for a change. A lot of things to talk about- but I'll try to keep it brief...

VC money's s'posed to be this week- signs are such that if it doesn't happen this week, it'll be next for the bridge and perhaps even better yet, the first installment of actual funding. I'm still going to believe it only when I see it- but like I said last week, I think the worst part may be finally over- one way or another.

I haven't heard from the company I interviewed with- but it's very probably too soon for that anyway. I suspect if I'm going to hear anything it'll be by around Friday.

If you're in Texas, there's THREE very important pieces of legislature being discussed in Austin. SB 1579, HB 2121, and SB 1116. SB 1579's a bill we in the state of Texas want, the other two are something we don't want- SB 1579's the bill requiring Open Source to be considered for use in IT projects, the other two are the Texas versions of the so-called S-DMCA bills that RIAA is trying to foist off onto us. Slashdot, the EFF, and others are covering this in much, much more detail, but suffice it to say, it's come time for all the tech crowd to get involved with this stuff if they're not already so.

Got more work done on Ballistics. I'm thinking I might tackle the sound support next because it'll be more impressive for the demo for NTLUG that Michael Simms gave me the green-light on.

Didn't get the patch done for Utah-GLX- ended up doing other work on other things. I plan on tinkering w/it after I verify the tuning work I just did on Ballistics.

Well, boys and girls, it's another fun-filled blog/diary entry for moi- hey, I didn't take more than a couple of months from the last one this time (a definite improvement...)!

Well, guess what, I didn't lose the house- yet. Seems there's some legal angles that I hadn't exploited, so we're still here- for now. But, keeping it (and a few other things...) is contingent on my getting a new job or the current one getting the VC money. Why, you might ask, am I even putting up with these people? Because up until October of last year, I at least had health insurance (More on that one in a little bit...) and I was getting more money than unemployment would have paid for longer- it was just inconsistent. That, combined with this sudden and largely complete discontinuance for any hiring in the industry because of the Internet Bubble bursting, has kept me where I am. Having said all of this, there may be light at the end of the tunnel and it's not the oncoming train. It looks like in 5 or less business days, the VC's going to actually get us our bridge funds as an advance on the first installment of our multiple millions they're funding us. (Please note: I did indicate that it was a crapshoot in the last entry as to when- that was nearly TWO months ago. Waiting for VC's to get their collective act together sucks bigtime...) Couple that with the very real prospects of a new job elsewhere (I recently interviewed with a major corporation that was interested in doing embedded Linux related development- they seemed to be fairly interested in my working for them. I'm not counting my chickens, but it looks good from where I'm standing right at the moment...) and things are possibly looking up for a change.

If you don't have health insurance, you may want to go way, way out of your way to get it however you can possibly do so. At the end of last month, my wife was admitted on an emergency admit to the local hospital for extreme abdominal pains. 3 days in the hospital with nothing more than an IV so that her GI tract would settle down. Her last unemployment check saw to it that we were ineligible for any financial assistance from the county or state. The total bill so far: $10k and rising. Thankfully, we've worked out a solution to the bill and everything will end up okay in the end. Keep the bill in mind, though- you will not be able to work things out everytime like we did with this little visit and you'll be stuck trying to figure out how in the hell to pay it.

The little bit I've done on the Ballistics port has been checked in (and revised several times...). Progress is moving along but we're delayed by things like my trying to keep a house over my head, etc.

On the front of my open sourced projects, I will be submitting a patch to the current Utah-GLX developers to fix the DMA support issue that they have with RagePRO chips because of changes made to the XAA drivers in the 4.X XFree86 releases (They adjust the FIFO buffer size settings on the chip, which doesn't seem to impact normal MMIO operation, but totally breaks DMA operation- go figure...). I plan on conducting a few basic experiments to the current DRI code on certain chipsets to see if there's not a better way of handling the security of those chips. Also on the hit parade of things planned is some research into ways to provide accelerated indirect 3D rendering- preferably within the current XFree86 (or Xwin- depends on how that fork goes down actually...) framework if at all possible. There's chipsets that while absolute peak speed is possible with direct rendering, the securing of the pathway eats any performance gains with respect to the direct operation. There's also chipsets out there that don't have any DMA operation so they gain a lot less from direct rendering.

25 Feb 2003 (updated 22 Jul 2004 at 20:55 UTC) »

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

I've done a little bit on the Ballistics port (Though not checked in yet... The team's making some pretty amazing strides- see LinuxGames for the first screenshot (BTW- we're beyond that by a long ways now...)) and I've thought a little more on the Tux Tag stuff, but most of my time is being devoted to packing up the house and putting most of the stuff in storage. Am I losing the house? Your guess is as good as mine. We've four weeks left before the official sale of the deed, my employer's about to get an emergency bridge loan from the VC that will re-establish payroll and insurance for us for long enough to count for the mortgage company (It's supposed to happen any time now, but you know how those things go...), and we've not heard the determination from the Loss Mitigation people at the mortgage company. I'm not going to wait and get blindsided- I'm packing up everything in anticipation of me having to give up or sell the house.

9 Feb 2003 (updated 22 Jul 2004 at 20:52 UTC) »

[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... :) ]

eBay.

The few things sold so far have pretty much paid for all the other future and possible sales with a bunch of change to spare. Only dismaying turn of events was the absolute lack of activity with regards to the 10 3J Tech 33.6k PC-104 modems I put up- guess I need to sell those on a different venue... (Know of anyone that needs a small quantity of PC-104 0-70deg C modems? I've got more than just a few of them available for sale...) I'm expanding the sales with a handful of premium Allwell 1030 configurations and a bunch of baseline configurations. If you're looking for a good price on a known to be working Allwell 1030 for a set-top toy or some embedded/kiosk/etc. application, look for "svartalf" on eBay- there should be at least one up for sale for a while yet.

On the DRI front, it looks to be that the other two people working on things are going to end up coding a hybrid of what I was attempting on the RagePRO driver. If it is stable and secure, it'll be faster that what I had in mind- if it's not, what I had in mind will work very well and allow for 2D DMA acceleration, etc. I plan on continuing to help/work on the RagePRO driver, but I'm going to see what I can do with the Trident support angle (since I DO happen to have those chipsets in a few things and I happen to have a register spec for the CyberBlade in the VIA chipsets...)- I've contacted Trident to become a registered developer through my employer (What do you know, they ARE useful for some things after all...) and I'm moderately hopeful I'll get some useful access in the next couple of weeks.

Tux-Tag's still kind-of stalled, but I've just about settled on a design for the pack/gun IR transponders and when I've settled on the Mark-I design proper, I'll be putting that up on the website for download. An interesting twist in the whole thing is that I could just as easily as not use a Dimm-PC or something like it for the whole thing (which lowers the price even further than the MZ-104 board...). It may be just as well, ZF-Micro seems to have a problem with their suppliers (Seems that National Semiconductor's cutting them off- unless they find another fab, etc. ZF's probably toast (which is a shame...)).

On the Intelogis front, I've pushed the hack-job I did for the 2.4 kernel support out to the site. I'm looking at what all I'll need to add interrupt driven support (If you've got an ECP port, it'll work like a champ when I'm done...) with info in hand from some of the old Intelogis/Inari staff lending a helping hand. Once I get the interrupt stuff working, I'm going to see what is needed to do byte mode instead of nybble mode like it is right now for peak performance. I've gotten a dump of what's going on with the USB interface with the SystemLink devices, but I've not had time yet to go through and reverse engineer the protocol changes to the PLX layer to make usable drivers for the new devices. I hope to do so fairly shortly.

19 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!