Older blog entries for Svartalf (starting at number 35)

I'm convinced.

The current means for providing AMD64 32-bit support within a 64-bit Linux environment is a BAD thing.

Split directories, one set for 32-bit (/lib, etc.) and one set for 64-bit (/lib64, etc.). It confuses the hell trying to make a cross-compile setup. It leaves it open for you to miss libraries on either side, causing you to not be able to do the stated thing, run 64-bit binaries alongside 32-bit ones. And it confuses the hell out of each and every automake setup.

We all need to really, REALLY re-think this idea. There's a need/desire for someone to run 32-bit applications- but this isn't the way to do this. Do I have answers for this? Not yet- I've not had the time to think about it seriously.

Here's a little gem of wisdom that I wish other coders and developers would figure out:

Pointer Values != DWORDs

Reinterpreting them to DWORDs causes no end to problems. Yes, on a 32-bit platform, they're DWORDs. On a 16-bit or 8-bit, they're not- they can either be DWORDs or WORDs depending on architechture. On a 64-bit machine, they're QWORDs. If you want to make a handle, in other words, an opaque pointer, declare a typedef for void * and go to town. If you're recycling something that was intended for use with DWORDs or INT32s to handle indexing or tracking pointers, you might want to take the time to think about and re-think your design to use the right data types.

These are the same silly things that I saw with migrating DOS applications to Windows. It's the same silly things I saw with migrating Win16 to Win32 applications.

It's so easy to write code in a manner to avoid this stuff, I guess that I'm amazed that I keep finding gems like this in modern code.

I just thought I'd make an entry for this. I just found out (it's apparently not hit Slashdot or any of the other regular sites...) that SuSE is offering the base distribution for download without install support, etc. Better yet, I've found a mirror that appears to provide AMD64 versions of the ISO's. Guess I'll be testing SuSE in another day or so- hopefully, they've done a little better job in handling the issues I outlined in my previous diary entry.

A comment on things Athlon 64-ish...

I've been tinkering around a little further with Mandrake 9.2 AMD64 and it's definitely "okay". The install made it feel a little rougher around the edges than I thought, but there's still some issues that are lingering that I'm not 100% sure they're Mandrake's, but not having any other reference (Gentoo was an interesting failed 1st and 2nd attempt. Maybe three tries is the charm, but I'm not sure about it at this point. Pretty damn complex setup if you ask me...) I can't say either way. Boils down to how they accomplished 32 and 64-bit support all in the same runtime environment. They have seperate /lib and /lib64 directories for all .a's and .so's on the system. What's more obnoxious is that your source builds can't assume where the libraries are- they have to dynamically choose the right one, and at least Mandrake opted to not have all of the development or runtime binaries for some libraries in 32-bit (which is the assumed pathway based on them placing all the 32-bit stuff in /lib, /usr/lib, etc.). A good example of this is Source Navigator. It will not build in the Mandrake AMD64 world without some hacking of the makefiles in the source tree so that the thing will find the available (64-bit only) X11 development stuff.

This has me wondering if supporting 32-bit in this manner is really worth it. Stuff's breaking unpleasantly because of the way they made it all work. While I admit it relegates the AMD64 to the same role as the PPC if you went nothing but 64-bit, it might be better for everyone involved as it would be exactly like everyone expects things to be.

Well, things have changed, hopefully for the better.

I have a job as a contractor for Texas Instruments. It's not for what I should be getting as a contractor with the years of experience I have- but, it's pretty much guaranteed money for the next 6 months at a rate that'll help get me back on my feet well enough.

The previous employer's morphed into just business partners working on some important projects after hours while they get their house in order. When it's all said and done, I'll be a part owner in the reorganized company if they get their funding (which will actually be some small recompense for all the agony they put me through these past two years)- IF they get their funding. The projects and the potential contracts lined up, plus the fact that they're still paying me a salary even though I'm on a contract elsewhere has me still talking to them at this point.

Athlon64. 64-bits. Nice. If you're wondering what I'm prattling on about, someone gifted me with an Athlon64 to do some work on their behalf. It's nice. It's pretty fast. Mandrake 9.2 for AMD64 is okay, but it's really rough around the edges for a release candidate. SuSE appears to currently be the way to go, but I don't have budget for a copy of Professional (Which, I believe is the only version set up for AMD64 right at the moment...) and they want $1500 for a developer relations arrangement (definitely NOT in the budget, either for me or for LGP...). So, that's kind of out of the question. Gentoo's an option, but I've not gotten around to doing the deed on another partition of the main HD yet.

On a slightly different note, I got a reminder about living for the moment today. Someone rear-ended me as I was getting on to I-35E in Lewisville. Pretty hard, in fact. Had the experience of being put in a cervical collar and put on a back board and carted off to the hospital in an ambulance. Nothing to speak of wrong with me that they can see, thankfully. It could have been worse. It was the, "it could have been worse" that kept going through my head- trouble has a way of finding you and you never know when your time is up.

At approximately 6:30 this evening, my father finally passed on to the Lord.

I'll miss you a lot Dad.

I wish I had good news to report, but October's not playing out well either.

It's with deep sadness, that I publicly announce that my beloved Father suffered a cardiac arrest on last Saturday evening, sometime around 9:10 or so. While the paramedics arrived quickly, they couldn't get a good solid rhythm in his heart for some 6+ minutes after they had arrived (3 minutes after his breathing had stopped)- this means he was anoxic (I used to make jokes about holding one's breath and Anoxia being a hell of a way to go- I doubt I'll ever do that again...) for some 9 or so minutes. We just pulled him off the ventilator last night after determining that there was no possibility of any substantive recovery from the coma he was in- he has not passed on yet, but it's only a matter of time. I have the joy of stating that we DID have a good relationship and his last two weeks of what was his normal life was a happy time. He had all of his immediate family present and spending the entire day with him on his 62nd birthday. He spent the entire following week with his grandchild (my nephew...) and his wife. His last day was spent tinkering around with the various and sundry stuff he'd accumulated over the years and having fun and laughter with his wife while watching Trading Spaces on TV. When he actually passes, I think I'll be putting up a memorial page on my website- whether or not anyone cares, I think everyone ought to know a little more about one of the men that helped make me who and what I am in this day and age.

Cherish the time you have on this earth with the people you love and care about- life's far, far too short to be spent merely existing. Plan for the future, but live for the moment.

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.

[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.

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...)