Project List

Problem:

Obviously, magazines for the STGW-57 in the US aren't exactly cheap. On top of that, they're not optimized to feed .308 Winchester. This project looks to solve that by providing a cheaper alternative specifically tailored for .308 Winchester. According to others that have .308 conversions, 7.5x55 Swiss magazines seem to work, though I don't personally like it for a couple of reasons:

1. The taper of .308 is different than 7.5x55 Swiss.

2. The overall length of the cartridge is much shorter.

These two factors combine to make a less than repeatable presentation of the cartridge when loaded into the 7.5x55 Swiss magazine. The first problem is that the .308 is forced to follow the curvature of the magazine. The curvature of the magazine is normally dictated by the taper of the cartridge. In the case of an incorrect taper following the curvature, the cartridges aren't going to rest along each other's bodies. In this case of excessive curvature, the cartridges will pivot about their transition to the neck.

Eventually, this leads towards the feed lips of the magazine exerting most of the pressure towards the front of the body of the cartridge, and due to how the cartridge is supported, the body doesn't sit flush against the feed lips and the head of the cartridge is lower at the rear of the magazine. The severity of the angle between the body and feed lips changes depending on how many cartridges are loaded, the more loaded it is, the greater the angle. This is the first inconsistency in the presentation.

The next problem, the overall length of the cartridge being shorter, adds another layer to the inconsistency. The shorter length of the cartridge affects the presentation since the cartridge can freely slip forward changing where the bolt initially contacts the cartridge during loading. Another effect is that during the transition from the magazine to the chamber, there comes a point where the feed lips stop supporting the cartridge and the rear is free to come up and align with the chamber. If the cartridge is shorter, the feed lips should control the cartridge closer to the chamber to prevent the cartridge from flopping about and not being able to align with the chamber.

Options:

Our options fit into two main categories, modify an existing magazine or making a new magazine. Making a new magazine in a low quantity and having it be of a good quality would most likely make it very expensive due to the amount of set-up required. Next, we could try some modification to the original STGW-57 magazines, though even if that fixes all of the mechanical issues, the base magazines themselves are still expensive. That leads us to modifying another existing magazine.

When choosing a magazine, we have to look for a few properties. The front of the STGW-57 magazine suddenly narrows at the front and has a portion in the trunnion that matches. This restriction either limits our magazine selection or requires a modification to the trunnion. I'd prefer to leave the trunnion alone as much as possible, therefore the requirement of the sudden transition at the front leaves us with two main available .308 surplus magazines:

• BM-59 Magazine

• .308 galil Magazine

Comparing the two, the BM-59 magazine is more available, cheaper and upon inspection generally seems to be better built. Something about the .308 galil magazines, especially their finish, seemed chincy. Once I decided on the BM-59 magazine, I compared the dimensions with the STGW-57 magazine. I'm happy to report that they are absurdly similar. Using digital calipers I found that by comparison to the STGW-57 magazine, the width at the rear is 0.5mm less, the narrow width at the front is 0.1mm less, and front to back it's 0.3mm less. I honestly couldn't ask for a better fit. The fact they're all slightly less is good too since we can always add material if we need to, reducing a dimension is obviously quite challenging with a hollow stamping.

Solution:

So with our goal of getting the BM-59 magazine to fit, align, lock and feed in the magazine well of an STGW-57, we'll have to make a front and rear tab and attach them to the magazine. I decided welding would be the easiest option, and I made sure all cuts for the parts could be made with a 90° end mill. I thought using a dovetail cutter might be necessary but it isn't. For assembly, besides the tabs themselves, you only need a block to set the height of the rear tab. The front tab is indexed off of the existing front magazine tab. The main steps are to prep the weld areas of the magazine, align tabs, tack, and weld. You can finish the tabs and weld area however you want. I believe the BM-59 magazines are phosphated, though I'm probably just going to cold blue the tabs and weld area for corrosion resistance.

You'll also have to do something about the two rear over-insertion stops on the side of the magazine so it can fit into the STGW-57 mag-well. For the sake of several different methods being viable, I'm just going to leave that portion out of the instructions. Personally, I'm just going to cut them off as a small gap isn't going to affect function. If you'd prefer you can weld a small sheet of metal over the gaps once you cut the over-insertion stop out and chamfer the tops so it doesn't get hung up on insertion. Keep in mind you've only got 0.25mm of width you can add to each side. Alternatively, you can ignore removing them altogether and find some way to bend them back flat. Instructions for fitting and tacking is included in the third page of the combined PDF.

Downloads:

Download the files by clicking the links below or view in the frame.

Problem:

If you've got a 7.5x55 STGW-57 parts kit and a .308 barrel, you've probably noticed the problem that the end of the jacket is no longer supported by the barrel. This would be fine if the jacket were fairly rigid like a free-floated rail system, though it's a thin aluminum tube riveted to a part that is screwed onto the trunnion. This means that the front sight is free to wander with the unsupported jacket. Even if you don't plan to use iron sights, you should still fix this problem because the barrel can whip into the jacket while firing or vice-versa, which at the very least would lead to finish wear and dings.

Options:

Obviously, we want to jam something between the barrel and the jacket to align them and transfer forces between them. The easiest solution would be a split tube that butts up against the chamfers of the muzzle brake and first grenade launching ring. However, I'd like to have nothing protruding past the end of the barrel jacket. This means we need either a friction fit or to touch off of another surface to stop our sleeve from sliding forwards. While this could be made from aluminum, steel, or plastic should do the job just fine. While it should be machineable, it would probably be easiest to be 3-D printed.

First Solution:

The first thing I tried was using a wedge that when screwed closer, would open up the split ring giving a friction fit against the jacket. This ended up not being feasible due to the difference in diameter between the jacket and barrel not leaving enough room for any decent sized bolt.

Second Final Solution:

This implementation relies on using a step on the inside of the barrel jacket to interact with the chamfer on the O.D. of our part to stop the sleeve from sliding forward. I have a slot for an O-ring (115 O-ring, 11/16" I.D.) to help with both keeping it together during assembly and for better fitment between the jacket and barrel. Keeping it together during assembly is important because it has to come from behind the jacket, meaning you've got a nice ~18" narrow tube you've got to guide it down, so it's best just to let the O-ring hold it onto the barrel. You may have to experiment with the depth of the groove, though I have it set in a slight slot right now. It also doesn't need to be heat resistant since whatever material you print will be a problem before the o-ring. I intend to 3-D print this, when I do I'll update this project with what I learn from it.

To download the CAD files, click the link below:

Construction Zone, Slight update:

Well, I've got my pizza delivery tracker for the 3-D printed part.

However, I neglected that people might also want a part that takes advantage of 3-D printing specifically and that I wouldn't need this extra design to be machinable. Below you can see that design and how it relies purely on the grenade launching ring to index and would work more consistently as the depth from the jacket to ring might vary from assembly to assembly. By a quick look, you can tell getting those internal features wouldn't be easy. You could use a boring bar but I don't think it wouldn't be worth the extra effort over the other version.

Download:

I'll try to get this one printed as well and you can download the files below:

To download the PDF/CAD files, click the links below:

If you're on a desktop browser you can just use the frame below to view/download the PDF.

Disclaimer: I did not make this particular drawing/package. It was sourced from a publicly listed library for resources related to the STGW-57.

Enjoy, You Won't Find This Anywhere Else.

This is a project I've been working on for a while. Anyone that's started on this themselves has probably realized their parts kit only has the receiver pieces that are attached to the trunnions, which leaves you with a lot of missing information. It took a lot of work and researching to get all this together as well.

The receiver is fabricated from two split sections for ease of manufacture, which are plasma cut from a flat, and bent afterwards, and the trigger group wings are fit through the slots and are welded on. The most complicated section of the build is the cam surface for the ejector, which I recommend building how I have here, and welding the cam section on, otherwise you'll need some pretty specialized tooling/dies. Additionally, if you want to go the route of machining this, you'll have to build a shell around the outside to support it while machining, though with the receiver shells split, it is possible.

Sample Images

Drawing of the full assembly.

Drawing of the bent ejector side of the receiver.

Drawing of the ejector side receiver flat with bend lines.

Full Package Download

To download the PDF/CAD files, click the links below:

If you're on a desktop browser you can just use the frame below to view/download the PDF.

Problem:

I wanted a pistol grip for an AR-15, it's that simple. I do like the "Battle Grip" from HK, though I decided I wanted something a bit more unique. The pistol grip doesn't have significant stresses applied to it, it essentially just needs to survive being banged around. With that in mind, I believe it's fine to 3-D print it.

The main thing to keep in mind when designing this is to make sure you can still assemble it. This is a concern because the grip angle isn't perpendicular to the mounting surface, so the bolt that screws into the lower receiver needs room in the off-angled grip to insert through the mounting hole. You can look below to compare the angle of the grip to the mounting surface.

Solutions:

I designed two slightly different grips with the main differences being where the top of the web of your hand goes and how the top mates with the lower receiver. The flat-topped one is more faithful to the original grip and better replicates the web to trigger distance of the actual STGW-57. The one with the angled top moves your hand up a bit and looks a little less goofy when on the receiver.

Downloads:

To download the CAD files, click the links below (Images below show how they look on the receiver):

Flat Top Grip ZIP

Angled Top Grip ZIP

Reason:

I wanted a unique and interesting icon to use as a theme for this website and other related projects. I saw the Risen song theme by Terry A. Davis and was oddly impressed. While some people aren't sure who exactly made it, as the main artist hired by Terry mentioned that he didn't know who made it, I can pretty conclusively say that it was a demo made by Terry as he was very good with crediting work, so the lack of a source means it was him. Additionally, other art used on the OS that isn't made by Terry rarely has any programming attached to it, just static sprites for the most part.

What I liked about the original Risen theme was that it had smooth mesmerizing movement and simple yet sharp colors and models. Additionally, there is the probability dithering for shading that makes a look that is hard to emulate on other software. I tried using Solidworks to make a model and image editing software to emulate the dithering based on shading intensity, though I didn't like the result. Moreover, it was just a static image.

From here I decided that the best way was to simply use Temple OS. Despite having no experience with Temple OS beforehand, I was able to find plenty of help through the community (additional thanks to Matias and Rendello) that still exists around Terry and his creations. Keep in mind with all things Terry related, you need a thorough mental filter and a good understanding of what Terry ultimately stood for. To even attempt that you need a decent understanding of mental illness as well. If you don't tread lightly you're liable to adopt a more hateful than loving ideology.

The Base:

The origin of the Risen theme is in the first supplemental pack for Temple OS. The particular file is "TOSTheme.HC.Z" which is located in the Sup1Graphics folder. For official Temple OS downloads, you can visit the download page of TempleOS.org and download both Temple OS and the first supplemental pack. It's your choice which virtual machine you want to run it on, or even if you want to run it on dedicated hardware.

The basics of it are 3-D meshes that rotate in X, Y, and Z; and 2-D sprites that scale, both of which are functions of time. There's a little more nuance in drawing the birds and the scale lines, though, in respect for how long this project is and the fact I'm either not editing or not using those elements, I'm leaving those out of this project write-up. If you un-muted the video you surely heard the rather loud single instrument music. I didn't lower the volume for the sake of keeping it as similar to Terry's original work for the best representation of what TOSTheme.HC.Z is, for your "enjoyment" of course. There's also the clipping that happens when it loops; Unfortunately, I won't be going over that as I forgot how I fixed it.

My Work:

• 3-D Meshes

The first thing I decided to do was make the 3-D meshes for use in the animation. Obviously, we'll be using the built-in graphics editor to make our meshes as trying to import them is way beyond the scope of what I'm looking to do. Interestingly in TOS, the program doesn't link to a file path for the mesh that you have saved as a file elsewhere, it's actually saved and editable in the program. Terry mentioned that to use the 3-D mesh editor you need to be a glutton for punishment, though once I got the basics down it wasn't that bad; Maybe it's due to the simplicity of the meshes I made.

Sidenote, to edit an existing mesh, have your cursor selection over the text representation for the mesh you want to edit, press "ctrl+r", then on the right side of the graphics menu, then select the mesh. Now you can go on to use the left menu to edit. Even if you're making your own mesh from scratch you'll need to do this since you're human and are bound to make mistakes (Save, Save, Save!), especially when you're working with the rather finicky mesh editor.

• Code Additions

Starting out, let me post this image below for reference. It'll be nice to look back to as you're viewing the other portions of the code I'll be going over.

So I wanted to make the code somewhat my own, rather than just switch out a few assets and tweak a few variables. I decided I wanted the meshes to be animated in some way other than just rotation. Essentailly, I decided I wanted vertices to move in relation to each other during the animation and that certainly wasn't done in TOSTheme.HC.Z . After some research, I figured out a way to do it, though first, we're going to go over how it was done originally.

Basically, it defines the identity equation for the matrix sets the X, Y, and Z coordinates and its rotation in X and Z. "Sprite3" uses the modified matrix on the mesh for it to be drawn as you've defined it. Now, this was removed due to the fact I was looking to add those features I mentioned in the previous paragraph. Below you can see my iteration of it and explanation of how those features were added.

So I've cleaned it up a bit for the purposes of this write-up, I apologize that the rest of the file isn't, though the other examples of drawing the mesh are pretty much the exact same, but with the variables changed out for the defined integers for scaling and the mesh files themselves. Moving on, from the start you can see "r1" is set as a matrix. Earlier in the file "r1" was defined as a 64 bit integer string. "Mat4x4Scale" takes the r1 matrix and Petals input. The Petals input was defined as an integer earlier in the file, in this specific instance, it is 0.38, which scales the Large Petals mesh to 0.38 of its original size. This was the first thing that required "r1" to be defined by I64.

The next step is setting up the identity equation for the matrix, which lets us set its position and modify it in other ways similar to the previous example. The next three lines are defining the mesh's origin point with respect to the X, Y, and Z axis. The out of place variable in the Z axis, "GR_Z_ALL" , to my knowledge sets it above other background entities. (You can imagine the Z axis as coming out of the screen with how we have our view set.) If this isn't done there is a chance the mesh flashes in and out while being drawn.

The positioning is more or less the same except "Flower_Height" which was an additional variable I defined as a constant. The rotation is also very similar with the addition of "Z_Rot_Amt_Scale" .

The next part is the Interpolation matrix which is the main addition I made. It's the other part that required defining "r1" as a 64-bit integer string. What "SpriteInterpolate" does is draw a unit vector between each moved vertex on an edited mesh you make. You can also see that the line is referencing two different meshes, one is the original straight petal mesh while the other is a copy and paste of that mesh that I edited so that the tips of the petals were bent. To use "SpriteInterpolate", you must make the derived mesh as an edit to a copy. If this isn't done it doesn't understand what vertices you want to be linked between the different meshes. You also can't add any vertices to the edited mesh.

From there it takes a constant to place the vertex somewhere along that vector via linear interpolation. Interestingly you can use a constant greater than 1 and less than zero. I took advantage of this by using "Sin((pi*dt)/4+3*pi/2)" which dips into both the positive and negative as a function of time. This way I only needed to make 1 modified mesh, which I rotated the ends of the petals 10° about the center. When you see the animation you'll notice the tips bend both ways despite only there only being a straight petal mesh and a single bent petal mesh. The function is also timed such that the tips trail the main petals in a way that looks like they're being dragged and have mass with rigidity.

The rest of the code for the other meshes are the same for the most part. There are different constants used for the scaling of the small and large petals since they reference the same meshes. There's also 2-D text sprites for "Project-Temple" and "Project-Temple.com" that were imported as .BMP's. The process for importing .BMP's is long and annoying; I may do another write-up on that topic alone in the future, but if I haven't and you want to know how just email me.

• Minor Changes

Towards the end, I decided to change the background color to the darker "Cyan" rather than "LtCyan". A small and simple but important change. I also added my own music. I kept the same spirit by having it be a single instrument, though I opted to use a modern MIDI editor on Windows. While the grating monotone notes have a certain appeal to some, it is like nails on chalkboard to many others. If you want to have a guess at what song it is you can shoot me an email for that too.

Result:

Overall this was a fun primer for Temple OS. While nothing I did was particularly groundbreaking, it did give me experience with an obscure operating system. Merely getting aquainted with the command line, switching directories, mounting disks, moving files, editing/running programs, and other simple tasks, it was quite the adventure only having had experience with Windows beforehand. If you are even considering doing a project in Temple OS for any reason, I highly recommend it, though please do use the tour once you get it installed. In a lot of ways making/editing this program reminded me of MATLAB, which Terry does credit as having affected choices he made while developing Temple OS. I did some extra learning about C and specifically Holy C as well. In the end, I got a pretty sweet unique looking logo/theme for projects in the future, which was the initial goal I set out to do in the first place.

Downloads:

Simply click the links below to download the files. There are really only two files, one with the extension ".HC.Z" and the other with only ".HC". The ".HC" file extension is mostly editable in a .txt editor like Notepad++ while ".HC.Z" is the compressed format that Temple OS uses. Both can be imported and edited in Temple OS; However, there's the ".ISO.C" which is the disk you can mount to Temple OS to import the files from, the ".ISO.C" contains both the ".HC.Z" and ".HC".

• Project-Temple Logo Animation (.HC)
• Project-Temple Logo Animation (.HC.Z)
• Project-Temple Logo Animation (.ISO.C)

Coming Soon